리트코드 스터디 도우미

DaleStudy 리트코드 풀이를 찾고, 작성하고, 테스트하고, 제출하는 일을 VS Code 안에서 이어갑니다.

이 확장의 목표는 DaleStudy/leetcode-study 스터디 저장소를 더 쉽고 빠르게 사용하는 것입니다. 75개 문제를 주차별로 탐색하고, 내 풀이 파일을 관리하고, Python 코드를 로컬에서 테스트한 뒤 주차별 PR로 제출할 수 있습니다.

설치 · 빠른 시작 · 상세 사용법 · 설정 · 로컬 개발

문제 목록과 풀이 및 제출 상태를 보여 주는 리트코드 스터디 도우미 화면

설치

사용하는 에디터에서 확장 프로그램 보기를 열고 리트코드 스터디 도우미를 검색해 설치합니다.

VS Code: Visual Studio Marketplace에서 보기
Cursor·VSCodium 등 Open VSX 사용 에디터: Open VSX에서 보기

검색 결과에 바로 나타나지 않으면 정확한 확장 ID를 입력하세요.

@id:alphaorderly.leetcode-study-helper

무엇이 편해지나요?

작업	확장에서 할 수 있는 일
문제 찾기	75개 문제를 주차·난이도·풀이 여부로 묶고 제목 검색과 미푸시 필터를 제공합니다.
풀이 관리	닉네임에 맞는 풀이를 열고, 없으면 선택한 언어로 새 파일을 만들며, 여러 언어 풀이도 나란히 보여 줍니다.
문제 확인	현재 풀이에 대응하는 LeetCode 본문과 예제를 사이드바에서 확인하고 문제 페이지로 이동합니다.
Python 테스트	저장하지 않은 코드와 여러 `Solution` 구현을 선택해 68개 지원 문제의 로컬 테스트를 실행합니다.
제출	선택한 풀이만 `week-XX` 브랜치에 커밋하고 push, PR 진행 상태를 하나의 흐름으로 보여 줍니다.
포크 동기화	안전 조건을 확인한 뒤 공식 `main`을 병합하고 `origin/main`까지 동기화합니다.

빠른 시작

저장소 준비부터 첫 제출까지 순서대로 따라 하면 됩니다. 각 단계의 자세한 설명과 예외 상황은 상세 사용법을 보세요.

0. 저장소 준비

DaleStudy/leetcode-study를 포크하고 로컬에 클론한 뒤, problem-categories.json과 문제 폴더가 있는 저장소 루트를 에디터로 엽니다. 폴더를 열지 않았거나 빈 폴더라면 사이드바의 포크 만들기 → 내 포크 클론 버튼이 같은 과정을 안내합니다.

git clone https://github.com/<github-id>/leetcode-study.git
code leetcode-study

1. 닉네임과 기본 언어 설정

활동 표시줄에서 리트코드 스터디 도우미 아이콘을 선택하고, 제출 파일명에 쓰는 닉네임과 새 풀이에 사용할 언어를 고른 뒤 적용을 누릅니다. 적용하면 설정 영역이 한 줄로 접힙니다.

닉네임 study-user와 Python 3를 선택하고 적용하는 과정

닉네임은 파일명의 첫 번째 점 앞부분과 대소문자까지 정확히 비교합니다. 예를 들어 study-user는 study-user.py와 일치하지만 Study-User.py와는 일치하지 않습니다.

2. 문제 찾기

제목 검색, 풀이 있음 / 풀이 없음 필터, 주차 / 난이도 묶음을 조합해 필요한 문제만 남깁니다.

3. 풀이 만들기

문제 카드를 누르면 내 풀이를 엽니다. 풀이가 없으면 문제-폴더/닉네임.확장자 파일을 만들지 확인한 뒤 에디터에서 열고, 현재 문제 보기 탭에 LeetCode 본문과 예제를 표시합니다.

Two Sum 카드를 눌러 two-sum/study-user.py를 만들고 문제 본문을 확인하는 과정

4. 로컬 Python 테스트

풀이를 작성하고 현재 문제 보기 하단의 테스트 실행을 누릅니다. 저장하지 않은 코드도 바로 실행하며, Solution 구현이 여러 개면 줄 번호로 실행 대상을 고릅니다.

Two Sum 풀이를 작성하고 로컬 테스트 80개를 모두 통과하는 과정

5. 주차별 제출

문제 카드에서 커밋에 추가한 풀이만 제출 대상이 됩니다. 제출 탭에서 작성 중 → 커밋 준비 → push 필요 → PR 진행 → 병합 완료 흐름을 확인하며, 주차 커밋 시 week-01 형식의 브랜치를 자동으로 준비합니다.

커밋 준비부터 PR까지 이어지는 주차별 제출 화면

PR이 병합되면 다음 주차 준비로 다음 주차를 시작하고, 공식 저장소가 앞서 있으면 포크 동기화로 맞춥니다. 테스트 실패 화면, 카드 아이콘, 포크 동기화 조건은 상세 사용법에서 화면별로 확인할 수 있습니다.

핵심 기능

문제 탐색과 풀이 파일

problem-categories.json과 문제 폴더를 감지해 문제를 주차별·난이도별로 정리합니다.
제목 검색, 풀이 있음·없음, 미푸시 필터로 필요한 문제만 남깁니다.
닉네임과 기본 언어를 기준으로 기존 풀이를 열거나 새 제출 파일을 만듭니다.
같은 문제의 여러 언어 풀이, 다른 참여자의 무작위 풀이, Algodale 정답 링크를 제공합니다.
풀이 삭제와 Markdown을 제외한 제출 파일의 마지막 줄바꿈 일괄 정리를 지원합니다.

현재 문제와 Python 테스트

풀이 파일을 열면 LeetCode 문제 본문, 예제, 제약과 주제 태그를 표시합니다.
저장하지 않은 현재 에디터 코드도 테스트하며 여러 Solution 구현을 개별 선택합니다.
typing, array, bisect, collections, functools, itertools, heapq, math 등 일반적인 LeetCode Python 환경을 먼저 import합니다.
실행은 신뢰된 워크스페이스에서만 가능하고 10초 후 종료되며 출력은 1MB로 제한됩니다.

테스트 데이터는 newfacade/LeetCodeDataset의 고정 리비전 215604aeed660029df7de2fea5a4d7b6ed476a08에서 추출했습니다. 현재 스터디 75문제 중 68문제를 지원하며, 결과는 LeetCode의 공식 실행 또는 제출 결과가 아닙니다.

주차별 제출과 포크 동기화

문제 카드에서 직접 커밋에 추가한 풀이만 스테이징합니다.
동기화된 main에서 주차 커밋을 만들면 week-XX 브랜치를 안전하게 생성하거나 기존 브랜치를 검증해 재사용합니다.
활성 주차의 커밋, push, 열린 PR과 병합 상태를 단일 레일 그래프로 보여 줍니다.
여러 주차나 풀이 외 파일이 섞이면 자동 진행하지 않고 먼저 정리할 내용을 안내합니다.
안전한 상태에서 공식 main을 병합하고 포크의 origin/main에 push합니다. 내 풀이만 수정된 경우에도 동기화를 시도하며, 풀이 외 변경은 제출 탭에서 되돌릴 수 있습니다.
PR 병합 후 다음 주차 준비에서 작업을 보존하고 main 생성·추적 설정·동기화·풀이 이동을 처리합니다. 원격 주차 브랜치가 삭제되어도 복귀할 수 있고, 충돌·재시도·원본 복원·보관함을 확장 안에서 사용할 수 있습니다.
rebase, force push, 자동 stash를 사용하지 않으며 충돌 시 merge를 중단합니다.

제출 기능은 origin의 fetch·push URL이 동일하고 GitHub에서 DaleStudy/leetcode-study의 포크로 확인된 저장소에서만 활성화됩니다.

알아둘 점

워크스페이스 루트에는 유효한 problem-categories.json과 대응하는 문제 폴더가 하나 이상 있어야 합니다.
제한 모드에서는 목록 조회만 지원합니다. 파일 생성·삭제·수정, 로컬 테스트, Git 작업에는 워크스페이스 신뢰가 필요합니다.
새 풀이와 제출 파일은 문제 폴더 바로 아래에서 관리하며 같은 이름이나 대소문자만 다른 파일을 덮어쓰지 않습니다.
Git 상태는 현재 브랜치의 upstream을 기준으로 계산합니다. 확인할 수 없는 정보는 추측하지 않고 상태 확인 불가로 표시합니다.
문제 본문은 LeetCode의 비공식 GraphQL API에서 불러옵니다. 네트워크 오류나 Premium 비공개 본문은 LeetCode 페이지에서 확인해야 합니다.
다른 참여자 풀이를 처음 열 때, Algodale 정답 링크를 열 때마다 정답 노출 여부를 확인합니다.
ListNode, TreeNode, Node, NestedInteger처럼 문제별 구조가 필요한 Python 객체는 자동 선언하지 않습니다.

조건별 대응 방법은 문제 해결을 참고하세요.

설정

설정	기본값	설명
`leetcodeStudyHelper.nickname`	빈 값	제출 파일에서 찾을 닉네임입니다. 영문·숫자·하이픈을 사용할 수 있으며 대소문자를 구분합니다.
`leetcodeStudyHelper.preferredLanguage`	`python3`	새 풀이 파일을 만들 때 사용할 언어와 확장자입니다.
`leetcodeStudyHelper.pythonExecutable`	`python3`	Python 테스트에 사용할 실행 파일 또는 절대 경로입니다.
`leetcodeStudyHelper.telemetry.enabled`	`false`	기능 사용 통계를 PostHog US에 전송할지 선택합니다. VS Code 사용 통계 설정도 허용되어야 합니다.

설정은 전역으로 저장되어 다른 LeetCode Study 워크스페이스에서도 동일하게 사용됩니다.

사용 통계

사용 통계 수집은 기본적으로 꺼져 있습니다. 배포된 확장에서 수집 설정을 선택하지 않은 채 확장 사이드바를 열면 동의 모달을 표시합니다. 설정 패널의 사용 통계 체크박스나 leetcodeStudyHelper.telemetry.enabled에서 언제든 변경할 수 있습니다. 수집 선택은 닉네임·언어 설정과 독립적으로 저장합니다. 안내를 닫으면 수집하지 않음으로 저장하며, 설정 항목을 삭제하면 다시 안내합니다.

동의한 경우 무작위 설치 식별자, 확장·에디터 버전, 기능·문제·주차·언어와 실행 결과를 PostHog US에 보냅니다. 닉네임, 코드, 파일 경로, 저장소 URL, 커밋·브랜치·PR 정보나 원문 오류는 보내지 않습니다. VS Code 사용 통계를 끄면 대기 이벤트도 폐기하며, 개발 실행과 자동 테스트에서는 실제 사용 통계를 전송하지 않습니다.

이벤트·집계 기준과 개발자 운영 설정은 사용 통계 문서, 전체 수집 속성은 telemetry.json에서 확인할 수 있습니다.

로컬 개발

Node.js 24.18.0과 Yarn Classic 1.22.22를 사용합니다.

nvm use
yarn install
yarn compile

주요 검증 명령은 다음과 같습니다.

yarn format:check
yarn docs:check
yarn lint
yarn typecheck
yarn test:unit
yarn test:integration
yarn test

통합 테스트는 .tmp에 격리된 멀티 루트 워크스페이스를 만든 뒤 @vscode/test-electron으로 실행합니다.

PostHog 연결 확인은 yarn telemetry:check로 명시적으로 실행합니다. 이 명령은 environment: development가 붙은 telemetry_connection_test 이벤트 하나를 US 프로젝트에 전송합니다. 고정된 테스트 ID만 사용하며 사용자·풀이·저장소 정보는 보내지 않습니다. 확장 활성화나 일반 검사에서는 실행하지 않습니다. 공용 HTTP 전송기를 사용하며, 성공 출력은 서버의 요청 수락을 뜻합니다. 실제 수신은 PostHog 이벤트 화면에서 확인합니다.

최소 지원 버전의 통합 테스트는 기본 검사 후 yarn test:prepare:integration으로 작업 파일을 다시 준비하고 node scripts/run-vscode-test.mjs --code-version 1.100.0으로 실행합니다.

코드 편집 규칙

yarn format으로 소스·테스트·개발 스크립트·웹뷰 CSS와 개발 설정을 정렬합니다. Prettier는 100자 줄 길이, 공백 2칸, 작은따옴표, 세미콜론, 후행 쉼표와 LF를 사용합니다. 100자는 줄바꿈 기준이며 긴 문자열을 강제로 분할하지는 않습니다. VS Code에서 권장 확장인 Prettier - Code formatter를 설치하면 지원 언어는 저장할 때 정렬됩니다. yarn test는 포맷 검사부터 실행합니다.

데이터셋, 테스트용 풀이 원본과 생성 파일은 자동 포맷에서 제외합니다. Python 실행기는 별도 포매터 없이 4칸 들여쓰기를 유지합니다. src/**/*.ts와 scripts/**/*.mjs의 클래스·함수·타입·인터페이스, 생성자·메서드·접근자와 함수를 담은 변수에는 한국어 JSDoc을 작성합니다. 공개 여부와 관계없이 적용하며, TypeScript 타입을 반복하기보다 전제조건, 부수 효과, 실패·취소 시 동작을 설명합니다. 일반 데이터 필드·상수와 익명 콜백은 각 선언의 설명이나 주변 구현으로 맥락을 전달합니다. Python에서는 docstring을 사용합니다.

주석은 처음 읽는 사람이 다음을 판단할 수 있도록 작성합니다.

클래스: 누가 사용하고, 어떤 상태를 소유하며, 언제 구독·타이머·프로세스를 정리하는가?
비동기 작업: 중복 요청을 공유하는가, 다음 실행으로 모으는가? 취소 후 결과는 어떻게 되는가?
파일·Git 작업: 읽기만 하는가, 저장·브랜치 전환·push도 하는가? 실패하면 무엇이 남는가?
상태·반환값: undefined는 대상 없음인가, 조회 실패인가? 오류를 던지는가, 표시 상태로 반환하는가?

@param에는 타입만으로 알 수 없는 옵션·단위·전제조건을, @returns에는 취소나 대체값의 의미를, @throws에는 호출자가 처리해야 할 실패를 설명합니다. 단순한 순수 함수는 짧게 설명하되, 복잡한 작업은 단계와 그 순서를 지켜야 하는 이유까지 적습니다. 예를 들어 “Git 상태를 확인합니다”보다 “원격 조회 중 바뀐 HEAD와 origin을 쓰기 직전에 다시 확인합니다. 앞선 검증을 재사용하면 다른 커밋이나 저장소에 쓸 수 있습니다”가 유용합니다.

yarn docs:check는 TypeScript 구문 트리를 읽어 설명이 없는 선언의 파일·줄·이름을 보고합니다. 빈 주석이나 태그만 있는 주석도 실패로 처리하며 yarn test에 포함됩니다. 이 검사는 주석 누락을 방지하므로, 설명이 실제 동작과 일치하는지는 코드 리뷰에서 확인합니다.

폴더 구조

src/
├── extension.ts                # 확장 활성화와 명령 등록 진입점
├── application/
│   ├── studyController.ts      # 설정과 사용자 명령 조율
│   └── sessions/              # 현재 문제 선택·실행, 저장소 갱신 수명 관리
├── domain/
│   ├── problems/              # 카탈로그 해석과 정답 링크 규칙
│   ├── solutions/             # 닉네임·언어·풀이 선택·줄 끝 보정 규칙
│   └── study/                 # 스터디 주차와 공식 문제 이슈 매핑
├── infrastructure/
│   ├── git/
│   │   ├── gitStatusService.ts # Git 상태 조회와 제출 작업 연결
│   │   ├── vscodeGit.ts       # 내장 Git 확장 API와 저장소 이벤트
│   │   ├── refRelation.ts     # HEAD와 ref의 관계 조회
│   │   └── submission/        # 제출 검증·브랜치 작업·이력 조회·상태 조립
│   ├── github/                # 인증, GitHub API와 PR 작성 링크
│   ├── leetcode/              # 문제 API와 포함된 테스트 데이터 읽기
│   ├── python/                # Python 프로세스 실행과 취소
│   └── workspace/             # 저장소 탐색과 풀이 파일 입출력
├── shared/
│   ├── contracts.ts           # 확장과 웹뷰가 공유하는 스냅샷·메시지 계약
│   └── async/                 # 버전 캐시와 지연 작업 도구
└── webview/
    ├── host/                  # VS Code 웹뷰 제공자와 메시지 중계
    ├── views/                 # 문제 목록·현재 문제·제출 화면
    ├── components/            # DOM 도구·아이콘·공통 컨트롤
    ├── state/                 # UI 상태 타입과 표시 조건 계산
    ├── main.ts                # 브라우저 메시지 수신과 UI 상태 복원
    └── render.ts              # 화면 영역 구성과 부분 갱신

단위 테스트는 test/unit/ 아래에 소스의 영역별 경로를 따릅니다. 웹뷰 동작 테스트는 test/webview/, VS Code 통합 테스트는 test/integration/, 테스트용 저장소 원본은 test/fixtures/에 둡니다. 개발·검사 스크립트는 scripts/, 확장에 포함하는 데이터·Python 실행기는 resources/, 스타일·이미지는 media/에 둡니다.

도메인 규칙과 공통 계약은 VS Code·Node·DOM API 없이 사용합니다. 실행 흐름은 application/, 외부 시스템과 파일 접근은 infrastructure/에 추가합니다. webview/host/는 확장 호스트에서, 나머지 웹뷰 코드는 브라우저에서 실행합니다.

주요 모듈 책임

영역	책임
`StudyController`	설정·사용자 명령 처리와 저장소·현재 문제 세션 연결
`RepositoryRefreshSession`, `CurrentProblemSession`	파일 감시와 갱신 요청 조율, 문제 로딩·Python 분석·실행 취소
`GitStatusService`, `SubmissionStatusReader`	Git 이벤트·인증 관리와 로컬·원격 제출 정보 조회
`SubmissionHistory`, `submissionSnapshot`	커밋 이력 읽기와 입출력 없는 표시 상태 조립
`SubmissionActions`	제출 작업의 검증·실행 순서
`SubmissionGuards`, `SubmissionBranches`	저장소·이력 검증과 공식 main 동기화·주차 브랜치 전환
웹뷰의 `state/`, `views/`	화면 표시 조건·문구 계산과 단계별 DOM 생성

웹뷰 메시지와 스냅샷 계약은 src/shared/contracts.ts에 있습니다. 화면의 제출 가능 여부는 표시용 정보입니다. Git 쓰기는 네트워크 조회·브랜치 전환 후에도 실제 상태, index, HEAD와 origin을 다시 확인해야 합니다. 시점이 다른 검증을 중복으로 보고 합치지 않습니다. 현재 문제의 부분 갱신은 관련 없는 목록과 제출 입력 DOM을 교체하지 않습니다.

처음 읽는 개발자를 위한 순서

src/extension.ts에서 확장 활성화와 명령·뷰 등록을 확인합니다.
src/shared/contracts.ts에서 화면 상태와 양방향 메시지를 읽습니다.
StudyController에서 관심 있는 사용자 명령을 찾습니다. 파일 탐색·갱신은 RepositoryRefreshSession, 현재 풀이·실행은 CurrentProblemSession으로 이어집니다.
Git 제출은 SubmissionActions의 공개 메서드에서 시작해 검증·브랜치 작업으로 내려갑니다. 표시가 이상하면 SubmissionStatusReader와 submissionSnapshot부터 봅니다.
화면은 webview/main.ts → render.ts → 해당 views/ 순서로 읽습니다. 버튼 비활성 조건과 표시 문구는 대응하는 state/ 모델에 있습니다.

확장 호스트에서 application, infrastructure, webview/host가 실행됩니다. 브라우저에서 실행되는 나머지 웹뷰는 VS Code API를 직접 호출하지 않고 메시지를 보냅니다. Python 실행기는 별도 프로세스이며 stdin/stdout의 JSON으로 확장 호스트와 통신합니다.

주요 실행 흐름과 지켜야 할 순서

초기 목록과 Git 후속 조회

flowchart TD
  A[확장 활성화와 웹뷰 ready] --> B[StudyController.getState]
  B --> C[RepositoryRefreshSession 전체 탐색]
  C --> D[파일 목록 먼저 게시]
  D --> E[웹뷰 state 메시지와 목록 렌더]
  C --> F[Git 후속 조회]
  F --> G{조회 기준 배열이 현재 배열인가?}
  G -->|예| H[Git 상태 결합 후 게시]
  G -->|아니오| I[옵션 복구 후 최신 목록 재조회]
  I --> F
  H --> E

전체 탐색 중 다시 요청하면 진행 중인 Promise를 공유합니다. 문제별 탐색은 루트·slug별로 공유합니다. Git 조회는 실행 중 들어온 요청과 강제 조회 옵션을 누적해 다음 회차까지 처리합니다. 이 세 가지 정책은 같지 않습니다. 갱신 결과는 새 스냅샷으로 게시하며, 배열 참조는 진행 중 Git 조회가 오래된 기준을 사용했는지 판별하는 데도 쓰입니다.

현재 풀이의 분석과 실행

flowchart TD
  A[편집기 선택 또는 문서 변경] --> B[기존 분석 취소와 필요한 실행 취소]
  B --> C[마지막 변경 350ms 후 Python 분석]
  C --> D[후보와 실행 가능 상태 게시]
  D --> E[사용자가 후보 실행]
  E --> F[테스트 데이터와 현재 소스 준비]
  F --> G[Python 실행]
  G --> H{취소되지 않았고 같은 파일인가?}
  H -->|예| I[실행 결과 게시]
  H -->|아니오| J[이전 결과 폐기]

문제 설명은 slug별로 보관하지만 분석·실행은 풀이 URI에 귀속됩니다. 결과 게시 조건과 제어기 정리 조건은 다릅니다. 이전 작업이 끝나도 새 작업의 AbortController를 지우면 안 됩니다. 입력 준비 실패는 명령 오류로 전달하고, 실행 중 실패는 후보를 보존한 러너 오류로 표시합니다.

Git 제출

flowchart TD
  A[웹뷰 제출 명령] --> B[컨트롤러의 화면 상태 사전 확인]
  B --> C[실제 Git 상태와 포크 신원 검증]
  C --> D[제출 범위와 주차 검증]
  D --> E[필요한 브랜치 전환 또는 원격 조회]
  E --> F[쓰기 직전 실제 상태 재검증]
  F --> G[commit 또는 push]
  G --> H[표시 상태 다시 조회]

위 그림은 공통 흐름입니다. 각 명령의 실제 조회·검증 순서는 SubmissionActions에 있습니다. 네트워크 조회와 브랜치 전환 사이에 상태가 바뀔 수 있으므로, 비슷해 보이는 검증도 실행 시점이 다르면 유지합니다. 포크 동기화 push가 실패하면 로컬에 남은 병합 결과를 보존하고 복구 안내를 반환합니다. 가독성 개선을 위해 검사나 Git 작업을 병렬화하지 않습니다.

표시 상태를 해석할 때

상태	의미와 주의점
`checking`	아직 조회·분석 중입니다. 이전 표시 데이터가 함께 남아 있을 수 있습니다.
`unknown`	파일의 반영 상태를 판단할 근거가 없습니다. 미제출로 확정한 상태가 아닙니다.
`unavailable`	조회 실패 또는 실행 불가입니다. Git 조회에서는 이미 확보한 로컬 이력을 보존할 수 있습니다.
`unsupported`	지원하는 포크 등 필요한 대상 조건을 만족하지 않습니다.
`blocked`	제출을 막는 사유가 계산되었습니다. `blockedReason`의 우선순위를 유지해야 합니다.
`ready`	해당 단계의 데이터가 준비되었습니다. 화면의 ready는 Git 쓰기 승인을 뜻하지 않습니다.

풀이의 pushed는 현재 upstream 기준이고, merged는 공식 저장소 반영 여부를 나타내므로 같은 뜻이 아닙니다. completed도 정답 통과가 아니라 내 풀이 파일 존재 여부입니다. 자세한 필드 의미와 선택적 값의 부재 조건은 shared/contracts.ts에 설명되어 있습니다.

VSIX 만들기

yarn package:vsix

모든 검사와 테스트가 성공하면 .artifacts/leetcode-study-helper.vsix가 생성됩니다. VS Code의 Extensions: Install from VSIX... 명령으로 설치할 수 있습니다.

라이선스

MIT 라이선스로 배포합니다. 이 프로젝트는 LeetCode 또는 DaleStudy의 공식 제품이 아닙니다.