이 기사에서는 프로그래밍을 배울 때, 언어 지식과 병행하여 디버거 (Debugger) 사용법을 조기에 익혀야 하는 이유를 정리합니다.

이전에 공개했던 「프로그래밍 언어보다 먼저 디버거 사용법을 익히자」를 현재의 생각에 맞춰 다시 정리한 내용입니다.

실무에서는 새로운 코드를 작성하는 시간뿐만 아니라, 기존 코드를 읽고, 원인을 조사하며, 영향 범위를 확인하는 시간이 길어집니다. 문법을 알고 있더라도 실행 중인 값이나 처리 흐름을 확인할 수 없다면, 모르는 코드를 이해하는 것은 어렵습니다.

디버거를 사용하는 목적은 버그를 고치는 것만이 아닙니다. 코드가 실제로 어떻게 움직이고 있는지 확인하고, 추측을 사실로 바꾸는 것입니다.

처음부터 모든 기능을 익힐 필요는 없습니다. 우선 다음 4가지만으로 충분합니다.

• 브레이크포인트 (Breakpoint)
• 스텝 실행 (Step Execution)
• 변수 확인
• 콜 스택 (Call Stack)

브레이크포인트는 지정한 행에서 프로그램을 멈추는 기능입니다. 멈춘 시점의 값, 어떤 분기를 통과했는지, 어디서 호출되었는지를 확인할 수 있습니다.

스텝 실행은 처리를 조금씩 진행하는 기능입니다. 메서드 (Method) 안으로 들어가기, 다음 행으로 진행하기, 호출한 곳으로 돌아가기 등의 조작을 구분해서 사용합니다.

변수 확인에서는 인수 (Argument), 반환값 (Return Value), 필드 (Field), 조건식의 값을 봅니다. "이 값일 것이다"라고 생각하는 것이 아니라, 실제 값을 확인하는 것이 중요합니다.

콜 스택은 현재 처리에 이르기까지의 호출 이력입니다. 문제의 행뿐만 아니라, 왜 그 행에 도달했는지를 추적할 수 있습니다.

예를 들어, thirdMethod에 브레이크포인트를 설정한다고 가정해 봅시다.

public class CallStackExample {
public static void main(String[] args) {
firstMethod();
...

정지했을 때, 콜 스택에는 대략 다음과 같은 순서로 표시됩니다.

thirdMethod
secondMethod
firstMethod
...

이를 보면 thirdMethod가 어디서 호출되었는지를 코드 전체를 검색하지 않고도 파악할 수 있습니다.

기존 시스템에서는 동일한 메서드가 여러 화면이나 배치 (Batch)에서 호출되는 경우가 있습니다. 예상치 못한 경로로 호출되지 않았는지 확인하려면 콜 스택이 유효합니다.

디버깅에서 자주 발생하는 문제는 "최종적인 값은 이상하지만, 어디서 바뀌었는지 모르는" 문제입니다.

이 경우에는 값을 설정하는 메서드나 대입 위치에 브레이크포인트를 설정합니다. setter가 있는 코드라면, setter는 유력한 확인 지점입니다.

public class User {
private String name;
public void setName(String name) {
...

setName에서 정지하면 다음을 확인할 수 있습니다.

• 전달된 name이 올바른가
• User가 예상한 인스턴스 (Instance)인가
• 어떤 처리가 setName을 호출했는가
• 그 호출이 예상한 조작 경로인가

값이 이상해진 이후의 처리를 계속 추적하는 것보다, 값이 변하는 경계에서 멈추는 편이 조사 범위를 좁히기 쉽습니다.

단, 빈번하게 호출되는 setter에 무조건적인 브레이크포인트를 설정하면, 몇 번이고 멈추게 되어 조사가 어려워집니다. 그럴 경우에는 특정 값일 때만 멈추는 조건부 브레이크포인트 (Conditional Breakpoint)를 사용합니다.

모르는 기능을 조사할 때는 처음부터 모든 코드를 읽으려 하지 않는 편이 진행하기 쉽습니다. 다음 순서로 확인합니다.

• 화면 조작, API, 배치 등 조사할 입구를 하나 정한다
• 입구 또는 중요한 분기에 브레이크포인트를 설정한다
• 인수와 조건식을 확인한다
• 처리가 어떤 메서드로 진행되는지 추적한다
• 값이 변하는 지점과 외부 연동의 경계를 확인한다
• 콜 스택으로 호출한 곳으로 돌아간다

예를 들어 "저장했을 터인 값이 화면에 반영되지 않는다"라면, 다음 순서로 확인합니다.

• 버튼의 이벤트 (Event)가 발생하고 있는가
• 리퀘스트 (Request)에 기대한 값이 들어있는가
• 서버 측은 값을 받고 있는가
• DB 갱신 시의 값은 올바른가
• 레스폰스 (Response)에는 갱신 후의 값이 들어있는가
• 화면 측의 상태는 갱신되고 있는가

한 번에 모든 것을 확인할 필요는 없습니다. 값이 올바른 지점과 이상한 지점의 경계를 찾아내면 조사 대상을 좁힐 수 있습니다.

학습용 작은 프로그램에서는 자신이 작성한 코드를 위에서부터 순서대로 읽을 수 있습니다. 하지만 실무에서는 다음과 같은 조건이 겹칩니다.

• 코드 양이 많다
• 여러 사람이 변경하고 있다
• 호출 경로가 여러 개 있다
• 설정이나 DB 데이터에 따라 동작이 변한다
• 프레임워크 (Framework)나 라이브러리 (Library)의 내부 처리가 있다

이 상태에서 코드 검색과 육안 확인만으로 원인을 찾으려 하면 시간이 오래 걸립니다. 디버거 (Debugger)를 사용하면 실제로 통과한 경로와 그때의 값을 확인할 수 있습니다.

언어의 문법은 중요합니다. 하지만 모르는 프레임워크 (Framework)나 레거시 코드 (Legacy Code)에 들어갔을 때, 처음부터 모든 것을 이해할 필요는 없습니다. 우선 실행하고, 멈추고, 값과 콜 스택 (Call Stack)을 확인하십시오. 이러한 진행 방식이 있다면 이해를 위한 발판을 마련할 수 있습니다.

생성형 AI (Generative AI)에게 버그 상담을 할 때도, 실행 시점의 정보가 있으면 조사를 진행하기가 훨씬 수월해집니다.

"저장할 수 없습니다"라는 말만으로는 후보가 너무 넓습니다. 다음과 같은 정보가 있으면 문제를 좁히기가 쉬워집니다.

• 재현 절차
• 에러 메시지와 스택 트레이스 (Stack Trace)
• 기대값과 실제값
• 문제가 발생하는 직전의 분기 조건
• 정상적으로 동작하는 케이스와의 차이점

이것들은 디버거 (Debugger)나 로그 (Log)를 통해 확인한 사실입니다. AI가 원인을 맞히게 하기 위해서가 아니라, 가설을 검증할 수 있는 재료를 늘리기 위해 공유하는 것입니다.

AI의 답변을 시도할 때도 수정 전후로 브레이크포인트 (Breakpoint)를 사용하여 값과 경로가 어떻게 변했는지 확인합니다. 제안된 코드가 동작하더라도, 왜 고쳐졌는지를 설명할 수 있는 상태로 만들어 두는 것이 중요합니다.

평소 개발 시 다음과 같은 연습을 반복하면 사용법이 몸에 익습니다.

• 작은 로직에 브레이크포인트 (Breakpoint)를 설정하기
• 실행 전, 인자 (Argument)와 반환값 (Return Value)을 예상하기
• 실행하여 실제 값을 확인하기
• 콜 스택 (Call Stack)으로 호출 측 확인하기
• 예상과 달랐던 이유를 코드로 확인하기

에러가 발생했을 때만 사용할 필요는 없습니다. 정상적으로 동작하는 로직을 따라가다 보면 브레이크포인트 (Breakpoint)나 스텝 실행 (Step Execution) 조작에 익숙해지고, 이상 발생 시 어디를 봐야 할지도 알게 됩니다.

처음에는 기존 코드의 일부를 하나 골라 입력부터 출력까지 따라가는 것만으로도 충분합니다. 어려운 버그를 해결하는 것보다, 실행 중인 사실을 확인하는 습관을 만드는 것을 우선시하십시오.

디버거 (Debugger)는 버그를 고치기 위한 도구만이 아닙니다. 기존 코드를 읽고, 실행 경로와 값을 이해하기 위한 도구입니다.

우선 브레이크포인트 (Breakpoint), 스텝 실행 (Step Execution), 변수 확인, 콜 스택 (Call Stack)을 사용할 수 있도록 하십시오. 그 후에 값이 변하는 지점이나 처리의 경계를 확인할 수 있게 되면, 모르는 코드라도 조사를 진행하기가 쉬워집니다.

프로그래밍 언어 학습과 병행하여 빠른 단계부터 디버거 (Debugger)를 접해 두면, 코드를 읽는 힘, 버그를 조사하는 힘, 생성형 AI (Generative AI)에 상황을 전달하는 힘을 종합적으로 키울 수 있습니다.