디버거를 덜 사용하고 디버깅으로 더 많이 배우세요
Source: Dev.to
Background
지난 프로젝트에서 나는 대규모 복합 전문가 시스템을 작업했다. 디버거를 사용해 버그를 조사하는 것이 여러 이유로 어려웠다. 우리가 교체하려는 실제 시스템으로부터 실시간 데이터를 받았기 때문에 트래픽이 많았고, 단일 요청을 따라가기가 문제가 되었다.
버그가 클라이언트 측에 있을 때는 디버깅이 더욱 힘들었다. 클라이언트는 Eclipse RCP 기반의 커스텀 Java 프론트엔드였으며, 우리는 해당 기술에 대한 경험이 제한적이었다. UI 로직이 다수의 Java 코드와 XML 파일에 숨겨져 있어 디버거로 실행 흐름을 추적하기가 어려웠다.
A New Debugging Strategy
나는 디버거로 코드를 한 줄씩 밟는 대신 신중한 로깅에 의존하는 다른 접근 방식을 채택했다. 핵심은 디버깅 세션을 시작하기 전에 실제로 배우고 싶은 것이 무엇인지 스스로에게 묻는 것이다.
Step 1: Define What You Need
- 확인하고 싶은 변수를 식별한다.
- 그 변수 값의 어떤 속성이 중요한지 결정한다.
“한 번 살펴보자”는 막연한 마음가짐으로 디버거를 실행하는 대신, 코드를 읽어도 문제가 무엇인지 전혀 감이 잡히지 않을 때만 세션을 연다.
Step 2: Add Targeted Log Statements
- 식별한 변수들의 값을 로그에 남긴다.
- 정보를 읽기 쉽게 만드는 어떤 형식이든 선택한다.
- 타임스탬프를 포함한다 – 디버거에서는 보기 어려운 타이밍 문제를 진단하는 데 매우 유용하다.
Step 3: Use a Temporary Commit
새 로그 문을 포함한 임시 커밋(짧은 기간 동안만 유지되는 변경)를 만든다. 이 버전을 테스트 환경에 배포하고 실제 데이터를 주입한 뒤 로그를 수집한다. 조사가 끝나면 메인 브랜치에 병합하기 전에 임시 커밋을 제거한다.
Analyzing the Logs
로그를 확보하면 다음을 할 수 있다:
- 데이터를 프로그램matically 파싱하고 분석한다.
- 분석 결과와 원시 데이터를 팀원과 공유한다.
- 분석 코드를 함께 포함시켜 다른 사람이 재현하거나 확장할 수 있게 한다.
이 접근 방식은 디버거 세션이 끝나면 사라지는 지식이 아니라, 디버깅 지식을 영구적으로 남긴다.
When a Debugger Is Still Useful
코드가 실행 흐름을 전혀 알 수 없을 때는 디버거가 여전히 유용하다. 예를 들어, 일반적인 메커니즘에 의존해 있어 단순히 읽는 것만으로는 이해하기 어려운 경우다. 이런 상황에서는 디버거를 사용해 관련 클래스와 제어 흐름을 찾아낸 뒤, 더 깊은 분석을 위해 다시 로깅으로 전환한다.
Conclusion
디버거 중심의 워크플로우에서 로그 중심으로 전환하면서 시스템 동작을 훨씬 더 잘 이해하게 되었고, 인터랙티브 디버깅에 대한 의존도도 줄어들었다. 아직 로그를 활용한 디버깅을 시도해 보지 않았다면, 이 전략을 한 번 적용해 보라. 디버깅 세션이 더 의도적이고 구조화되며 공유하기 쉬워질 수 있다.