실사용 영상
--------------
LeetCode에서 문제를 풀다 보면 제출 결과만으로는 코드가 왜 틀렸는지 알기 어려울 때가 있다.
간단한 문제는 print()를 넣어 확인할 수 있지만, 연결 리스트나 트리처럼 자료구조가 복잡해지면 값이 어떻게 바뀌는지 따라가기 어렵다. 재귀 문제에서는 어느 호출부터 잘못되었는지 확인하는 것도 쉽지 않다.
VS Code에는 이미 Python 디버거가 있으니 LeetCode 코드를 복사하고 중단점을 설정하면 바로 디버깅할 수 있을 것 같았다.
그런데 실제로는 그렇지 않았다.
LeetCode 코드는 실행 프로그램이 아니다
LeetCode에 제출하는 코드는 보통 다음과 같이 Solution 클래스만 존재한다.
1class Solution: 2 def twoSum(self, nums: list[int], target: int) -> list[int]: 3 ...
프로그램을 시작하는 main()이 없고, twoSum()에 전달할 입력도 없다. 반환값을 출력하거나 정답과 비교하는 코드도 LeetCode 서버가 대신 처리한다.
따라서 이 코드를 로컬에서 실행하려면 다음 과정이 필요하다.
테스트 입력 준비 → Solution 클래스 생성 → 실행할 메서드 선택 → 매개변수 전달 → 메서드 실행 → 결과 출력
문제를 풀 때마다 이 코드를 따로 작성할 수는 없어서, 이 과정을 자동화하는 LeetCode Debugger를 만들었다.
같은 이름의 테스트 파일
먼저 풀이 파일 옆에 같은 이름의 테스트 파일을 두는 방식을 사용했다.
two_sum.py two_sum.txt
two_sum.txt에는 LeetCode 예제 입력과 출력을 그대로 작성한다.
1Input: nums = [2,7,11,15], target = 9 2Output: [0,1]
VS Code에서 two_sum.py를 열고 디버깅을 시작하면 확장 프로그램이 자동으로 two_sum.txt를 찾아 실행하는 방식이다.
테스트 파일이 없다면 다음 형태로 새 파일을 생성한다.
1Input: 2Output:
프로젝트 구조
처음에는 VS Code 확장 프로그램 하나가 모든 작업을 처리하면 된다고 생각했다.
하지만 테스트 케이스를 해석하고 Python의 Solution 클래스를 실행하는 작업까지 JavaScript에서 처리하는 것은 자연스럽지 않았다.
그래서 역할을 두 부분으로 나눴다.
VS Code 확장 프로그램 - 현재 Python 파일 확인 - 같은 이름의 테스트 파일 확인 - 디버그 실행 설정 생성 Python 런타임 - 테스트 케이스 해석 - Solution 메서드 실행 - 결과 비교
VS Code 쪽은 디버깅을 준비하고, Python 쪽은 LeetCode 실행 환경을 흉내 내는 구조다.
package.json
VS Code 확장 프로그램에서 package.json은 확장 프로그램이 제공하는 기능을 VS Code에 알려준다.
이 프로젝트에서는 다음 두 명령을 등록했다.
1LeetCode: Open Case File 2LeetCode: Debug Current Solution
명령 팔레트뿐 아니라 Python 에디터 상단에서도 실행할 수 있도록 버튼을 추가했다.
또한 leetcodeDebugger라는 디버거 타입을 등록했다.
1{ 2 "name": "LeetCode: Debug Current Solution", 3 "type": "leetcodeDebugger", 4 "request": "launch" 5}
처음에는 명령 팔레트를 통해서만 디버깅할 수 있었다. 이후 전용 디버거 타입을 추가하면서 VS Code의 실행 및 디버그 목록에 표시되고, F5로도 실행할 수 있게 되었다.
extension.js
extension.js는 VS Code와 Python 런타임을 연결한다.
디버깅을 시작하면 다음 내용을 확인한다.
현재 열려 있는 파일이 Python 파일인가? → 저장되지 않은 내용이 있다면 저장 같은 이름의 .txt 파일이 있는가? → 없다면 생성할지 확인 Python Debugger 확장 프로그램이 있는가? → 없다면 오류 안내
모든 준비가 끝나면 확장 프로그램에 포함된 Python 런타임을 임시 디렉터리로 복사한다.
그다음 debugpy가 다음과 같은 설정으로 실행되도록 만든다.
{ type: "debugpy", request: "launch", program: bootstrapPath, args: [ "--solution", solutionPath, "--case-file", caseFilePath ] }
여기서 사용자의 풀이 파일을 직접 실행하지 않는다는 점이 중요하다.
처음 실행되는 파일 = bootstrap_debug_session.py 실제로 디버깅할 파일 = 사용자의 LeetCode 풀이 파일
부트스트랩 프로그램이 사용자의 풀이 파일을 읽어 실행하고, VS Code Python Debugger는 그 과정에서 풀이 코드에 설정된 중단점을 처리한다.
내부 런타임 코드는 디버거 필터에서 제외했다. 따라서 한 줄씩 실행해도 테스트 파서 내부로 들어가지 않고 사용자의 Solution 코드를 중심으로 확인할 수 있다.
전체 실행 과정
결국 사용자가 F5를 누르면 다음 순서로 실행된다.
사용자 └─ F5 └─ VS Code 확장 프로그램 ├─ 현재 Python 파일 확인 ├─ 같은 이름의 테스트 파일 확인 ├─ Python 런타임 준비 └─ debugpy 실행 └─ bootstrap_debug_session.py └─ LeetCode Python 런타임 실행
정리하면 이 확장 프로그램은 새로운 디버거를 직접 만든 것이 아니다.
기존 VS Code Python Debugger가 LeetCode 코드를 실행할 수 있도록 중간에서 실행 환경을 준비하는 어댑터에 가깝다.
결국 F5의 의미는 다음과 같다.
현재 LeetCode 풀이와 테스트 파일을 확인하고, Python 디버거가 풀이 코드를 실행할 수 있도록 LeetCode 실행 환경을 준비하라는 뜻이다.
하지만 디버거를 시작했다고 해서 LeetCode 코드가 바로 실행되는 것은 아니다.
Solution 안에 메서드가 여러 개라면 무엇을 실행할지 찾아야 하고, [1,2,3]과 같은 입력을 실제 ListNode나 TreeNode로 변환해야 한다.
다음 글에서는 이 과정을 처리하는 Python 런타임에 대해 정리해보려고 한다.