9강. 디버거 기초: 로그만으로 찾기 어려운 문제를 추적하기

?1. 이번 강의에서 해결할 문제

로그를 여러 줄 추가해도 어느 호출에서 값이 잘못됐는지 알기 어렵습니다. 같은 입력에서 실행을 멈추고 변수와 Call Stack을 확인합니다.

✓2. 학습 목표

✓이 강의를 마치면

• Breakpoint, Step Over, Step Into와 Call Stack을 설명합니다.
• 프로젝트 실행을 위한 최소 launch.json을 작성합니다.
• 기대값과 실제값이 처음 달라지는 지점을 찾습니다.

◇3. 핵심 개념

Debugger는 실행 중인 프로그램에 연결해 특정 줄에서 멈추고 변수, 식과 호출 경로를 관찰합니다. VS Code의 Debug 설정은 Workspace의 .vscode/launch.json에 저장할 수 있지만 언어·Debugger마다 type과 속성이 다르므로 공식 설정 문서와 언어 확장 문서를 확인합니다.

용어	무엇을 확인하는가
Breakpoint	선택한 줄을 실행하기 직전의 값과 흐름
Step Over	현재 줄을 실행하되 호출 함수 안으로 들어가지 않음
Step Into	호출한 함수 내부 첫 줄로 이동
Call Stack	현재 줄까지 어떤 함수들이 호출됐는지

최소 사례에서 calculateScore(100, -2)의 기대 정책이 “음수 배율 거부”라면 단순 출력 0만으로는 왜 0이 됐는지 알기 어렵습니다. safeMultiplier 줄에 멈추면 입력 -2가 Math.max를 거쳐 0이 되는 순간을 확인할 수 있습니다.

✎4. 단계별 실습

JavaScript · 파일 경로: src/app.js

시작 전 상태: D:\Dev\productivity-lab을 VS Code로 열고 node --version, Test-Path .\src\app.js를 확인합니다. launch 설정의 program이 실제 파일을 가리켜야 합니다.

src/app.js

function calculateScore(baseScore, multiplier) {
  const safeMultiplier = Math.max(0, multiplier);
  return baseScore * safeMultiplier;
}

const result = calculateScore(100, -2);
console.log({result});

JSON · 파일 경로: .vscode/launch.json

.vscode/launch.json

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "node",
      "request": "launch",
      "name": "Debug productivity lab",
      "program": "${workspaceFolder}/src/app.js",
      "skipFiles": ["<node_internals>/**"]
    }
  ]
}

PowerShell · 실행 위치: D:\Dev\productivity-lab

node .\src\app.js

예상 결과: 일반 실행은 { result: 0 }을 출력합니다. Breakpoint에서는 baseScore=100, multiplier=-2를 보고, Step Over 뒤 safeMultiplier=0을 확인합니다. Call Stack에는 calculateScore와 이를 호출한 최상위 실행 맥락이 나타납니다.

→5. 도구와 설정이 동작하는 이유

launch.json은 어떤 실행 파일과 소스를 Debugger가 시작할지 재현합니다. Breakpoint에서 프로그램이 멈추면 변수의 현재값과 호출 경로를 코드 변경 없이 관찰할 수 있습니다.

값 흐름은 인자 100·-2 → 매개변수 → safeMultiplier 0 → 반환값 0 → result입니다. 정책을 “음수면 오류”로 바꾸기 전에는 이 관찰과 요구사항을 분리해 기록해야 합니다. Debugger는 증거를 보여 주지만 올바른 정책을 대신 결정하지 않습니다.

!6. 자주 하는 실수와 해결법

!자주 하는 실수

• Breakpoint를 너무 많이 둠: 기대값이 갈리는 경계부터 시작합니다.
• Watcher에서 상태를 바꾸는 식 실행: 처음에는 읽기 전용 식만 평가합니다.
• 다른 언어의 launch type 복사: 현재 Debugger 공식 속성을 확인합니다.
• Debugger 관찰만 하고 재현 입력 미기록: 실행 명령과 입력을 버그 보고에 남깁니다.

✎7. 직접 실습

✎직접 실습

실습 목표

같은 함수에 세 입력을 주고 기대값과 실제값이 처음 달라지는 줄을 Debugger로 찾습니다.

시작 전 상태

일반 실행 결과와 launch 설정의 파일 경로를 확인합니다. Breakpoint는 safeMultiplier 계산 줄 하나에서 시작합니다.

1단계: 따라 하기

입력 (100, -2)로 멈춰 매개변수, Step Over 뒤 지역 변수, 반환 직전 값을 차례로 기록합니다.

2단계: 입력 바꿔 보기

multiplier를 2, 0, -2로 바꾸고 표에 기대 result·실제 result·처음 달라진 줄을 적습니다.

3단계: 직접 적용

runBattle() 함수가 calculateScore()를 호출하게 한 단계 감싸고 Step Into와 Call Stack으로 호출 순서를 확인합니다. 로직 수정은 원인이 확인된 뒤 최소 범위로 합니다.

4단계: 스스로 확인

• 실행 명령과 입력을 함께 기록했나요?
• Watch에는 값을 바꾸지 않는 식만 넣었나요?
• 처음 잘못된 값이 만들어진 줄을 찾았나요?

막혔을 때

증상	확인·해결
Breakpoint가 회색	launch의 program·source map·실행 파일을 확인합니다.
멈추지 않음	해당 줄이 실제 입력에서 실행되는지 일반 로그로 확인합니다.
변수가 안 보임	올바른 Stack Frame을 선택하고 변수 범위를 확인합니다.

?8. 이해 점검 질문 3개

?이해 점검

1. 출력은 0인데 음수 배율이 어느 줄에서 바뀌는지 모릅니다. Breakpoint와 Step Over를 어디에 사용하겠나요?
2. 같은 계산 함수가 여러 곳에서 호출될 때 문제를 만든 호출 경로는 어떤 창에서 확인하나요?
3. 팀원 컴퓨터에서만 다른 파일을 실행할 때 launch 설정의 어떤 값과 작업 공간 기준을 비교해야 하나요?

■9. 핵심 요약

■핵심 요약

Debugger는 같은 입력의 실행을 멈추고 변수와 호출 경로를 관찰합니다. 최소 launch 설정과 재현 입력을 함께 기록해 추측보다 증거로 원인을 좁힙니다.

§10. 다음 강의 연결

실행을 멈춰 값과 호출 순서를 관찰했습니다. 다음 강의에서는 매번 Debugger를 붙일 수 없는 실행에서도 필요한 맥락을 남기는 로그를 설계합니다.