- Published on
소프트웨어 디버깅 도구 2026 완벽 가이드 - gdb · lldb · rr · Pernosco · Replay.io · ASan · Valgrind · eBPF · perf · 타임트래블 디버깅 심층 분석
- Authors
- Name
- Youngju Kim
- @fjvbn20031
프롤로그 — 2026년에도 printf는 무패다, 그러나 옴니션트 디버거가 모든 것을 바꿨다
2026년의 디버깅에 관한 가장 솔직한 문장 하나로 시작하자. printf는 여전히 무패다. 분산 시스템 어딘가에서 NaN이 튀어나오거나 Kubernetes 파드가 알 수 없는 이유로 OOMKill 되면, 우리는 일단 로그 한 줄을 박는다. 컴파일러 베테랑이든 시스템 엔지니어든 마찬가지다.
그런데 동시에, 2026년은 옴니션트(omniscient) 디버깅의 시대다. Pernosco는 한 번 녹화한 실행을 통째로 시간 축에서 재생한다. Replay.io는 브라우저 세션을 클라우드에 저장해 React 컴포넌트의 모든 상태를 뒤로 감는다. rr 8.0은 멀티스레드 레코딩을 정식 지원하고, Microsoft TTD는 Windows에서 프로덕션 덤프를 시간 역방향으로 걷는다. "버그를 재현할 수 없다"는 변명은 점점 들어주지 않는 문화가 자리잡았다.
이 글은 세 축을 한 번에 본다.
- 고전 인터랙티브 디버거 — gdb, lldb, WinDbg, Delve, py-spy, Visual Studio
- 타임트래블·레코드 리플레이 디버거 — rr, Pernosco, Replay.io, RevDeBug, TTD, IntelliTrace, Firefox WebReplay
- 동적 분석·관측 — ASan, UBSan, TSan, Valgrind, Helgrind, Callgrind, Dr.Memory, perf, FlameGraph, eBPF, strace, JFR, async-profiler, OpenTelemetry
마지막으로 AI 디버깅(Cursor의 Debug 모드, GitHub Copilot Debug, Devin)이 어디까지 왔는지, 한국·일본의 디버깅 문화는 어떻게 다른지 정리한다.
한 줄 요약: "버그를 재현할 수 있다면 거의 다 끝난 것이고, 재현할 수 없다면 녹화하라." 이 두 문장이 2026년 디버깅 도구 선택의 90%를 결정한다.
1장 · 디버깅의 세 가지 철학 — printf, 인터랙티브, 타임트래블
먼저 도구 이름을 외우기 전에, 세 가지 디버깅 철학을 분리해야 한다.
| 철학 | 핵심 행위 | 대표 도구 | 비용 | 강점 |
|---|---|---|---|---|
| Printf 디버깅 | 코드에 출력문을 삽입하고 재실행 | printf, console.log, tracing!, slog | 0에 수렴 | 어디서나 작동, 분산 시스템 OK |
| 인터랙티브 디버깅 | 실행 중인 프로세스에 붙어 중단점·관찰 | gdb, lldb, WinDbg, Delve, Chrome DevTools | 중간 | 깊은 상태 검사, REPL |
| 타임트래블 디버깅 | 한 번의 실행을 녹화해 시간 축으로 이동 | rr, Pernosco, Replay.io, TTD, IntelliTrace | 큼 | Heisenbug, 비결정성 정복 |
세 철학은 배타적이 아니라 보완적이다. 2026년의 시니어 엔지니어는 셋 다 능숙해야 한다. 다만 비용과 효과의 곡선이 다르다.
- printf는 "정보가 0개일 때" 최고다 — 어디서 실패하는지조차 모를 때.
- 인터랙티브는 "재현이 쉬울 때" 최고다 — 한 줄로 재현되는 단순 NPE.
- 타임트래블은 "재현이 어려울 때" 최고다 — 1000회 중 1회 발생하는 데이터 레이스.
2장 · gdb — GNU 디버거, 35년의 표준
GDB(GNU Debugger)는 1986년 Richard Stallman이 시작한 이래 C/C++/Rust/Go/Ada의 사실상 표준이다. 2026년 시점 GDB 16.x가 안정 버전이며, DWARF 5 디버그 정보, Python 16 스크립팅, Ada/Rust/Fortran 표현식 평가, multi-target 디버깅, non-stop mode, reverse execution 까지 지원한다.
# 가장 자주 쓰는 흐름
gcc -O0 -g3 -fno-omit-frame-pointer -o prog prog.c
gdb ./prog
(gdb) break main
(gdb) run arg1 arg2
(gdb) next # 한 줄 실행
(gdb) step # 함수 내부로
(gdb) print *ptr # 값 출력
(gdb) backtrace # 스택 보기
(gdb) watch counter # counter가 바뀌면 멈춤
(gdb) rwatch shared_x # 읽힐 때 멈춤
(gdb) info threads
(gdb) thread 3
(gdb) continue
GDB의 잘 안 알려진 무기는 reverse execution 이다. record full 또는 record btrace로 명령 추적을 녹화한 뒤 reverse-continue, reverse-next, reverse-finish 로 시간을 거꾸로 걷는다. 이것이 rr이 인기를 끌기 전부터 있었던 "원조 타임트래블"이다. 다만 오버헤드가 크고, x86_64에 한정되며, 멀티스레드에 약하다.
또 하나의 무기는 gdbserver 와 multi-target. 임베디드 보드의 gdbserver에 붙어 호스트 GDB가 ARM 바이너리를 디버깅하는 워크플로우가 대표적이다. 2026년에는 RISC-V 보드, Zephyr RTOS, ESP32 디바이스에서 흔하다.
3장 · lldb — LLVM 진영의 모던 디버거
LLDB는 LLVM 프로젝트의 디버거로, Apple이 macOS·iOS의 Xcode에 통합하면서 사실상 Apple 플랫폼의 표준이 됐다. 2026년 기준 LLDB 19.x가 최신이며 Swift·Rust·C++ 표현식 평가, JIT 기반 식 실행, Python 자동화, DAP(Debug Adapter Protocol) 서버 모드 가 강점이다.
clang -O0 -g -o prog prog.c
lldb ./prog
(lldb) breakpoint set --name main
(lldb) run
(lldb) frame variable
(lldb) thread backtrace
(lldb) expression -- some_func(42)
(lldb) memory read --size 4 --format x --count 16 $rsp
(lldb) breakpoint set --file foo.c --line 120 --condition 'i > 1000'
gdb와 lldb의 가장 큰 차이는 명령 문법과 확장 언어다. lldb는 명령 자체가 동사-목적어 형태로 더 길지만 일관적이고, Python으로 매우 깊이 확장된다. Apple Silicon ARM64 디버깅, iOS Sim 디버깅, Swift 타입 시스템 평가는 lldb가 압도적이다.
VS Code와 Xcode는 모두 lldb를 DAP 로 감싸 GUI에 노출한다. 사용자는 lldb의 명령을 직접 모르고도 중단점·watch·step over를 누른다. 그러나 어려운 버그가 오면 결국 디버그 콘솔에서 expression을 직접 친다.
4장 · rr — Mozilla가 만든 결정론적 레코드 리플레이
rr(record and replay)은 Mozilla의 robert.ocallahan, kyle.huey가 2014년에 공개한 오픈소스 도구다. 핵심 아이디어는 한 줄로 요약된다.
rr record ./prog
rr replay
rr record 는 프로세스의 시스템 콜, 시그널, 비결정성 소스(rdtsc, 스레드 스케줄링 등)를 모두 가로채 디스크에 적는다. rr replay 는 그 기록을 가지고 같은 명령 시퀀스를 결정론적으로 재현한다. 그 위에 GDB 호환 인터페이스가 얹혀 있다.
rr replay -- -ex 'break crash_function'
(rr) continue
(rr) reverse-continue
(rr) reverse-next
(rr) checkpoint
(rr) restart 1
rr의 마법은 reverse-continue. 충돌점에서 거꾸로 돌리면, 어떤 변수가 언제 잘못된 값으로 바뀌었는지 추적할 수 있다. 그래서 "use-after-free", "데이터 레이스 후 한참 뒤 충돌", "메모리 코럽션의 진짜 원인" 같은 문제에 압도적으로 강하다.
제약도 분명하다. x86_64 Linux 한정, performance counter (PMU) 필요, AVX-512 같은 일부 명령어 미지원, 싱글 코어 직렬화로 인한 약 1.5~3배 오버헤드. 2026년 시점 rr 8.x는 Intel CPU에서는 거의 완벽하지만, AMD Zen5 일부 모델·Apple Silicon에서는 작동 불가다.
5장 · Pernosco — 옴니션트 디버깅의 클라우드 구현
Pernosco는 rr의 공동 창시자들이 만든 상용 서비스다. 핵심 아이디어는 "rr 레코딩을 클라우드에 업로드하면, 우리가 그것을 시간 축 데이터베이스로 인덱싱해 돌려준다"는 것이다.
전통적인 디버거에서 우리는 한 시점에서 멈추고, 변수를 보고, 다시 다음 시점으로 간다. Pernosco는 모든 시점이 동시에 존재한다. UI에서 변수를 클릭하면 그 변수가 평생 가졌던 모든 값과 변경된 위치가 즉시 나온다. 함수에 들어간 모든 호출, 모든 인자, 모든 리턴값을 한꺼번에 볼 수 있다. 이것이 "omniscient"의 뜻이다.
| 항목 | gdb + record | rr | Pernosco |
|---|---|---|---|
| 녹화 | 가능, 단일 프로세스 | 가능, x86_64 Linux | 가능 |
| 시간 역방향 | 가능, 느림 | 가능, 빠름 | 즉시, 모든 변수 |
| 멀티스레드 | 약함 | 좋음 | 매우 좋음 |
| 공유 | 트레이스 파일 | 트레이스 파일 | 한 URL로 팀 전체 |
| 비용 | 무료 | 무료 | 유료(엔터프라이즈) |
Pernosco가 풀어준 가장 큰 문제는 버그 트라이지의 비동기화다. 엔지니어 A가 버그를 만나면 rr로 녹화해 Pernosco에 올린다. 엔지니어 B는 자기 노트북에서 URL만 열면 같은 실행을 본다. 같은 시간대에 같은 자리에 있을 필요가 없다.
6장 · Replay.io — 브라우저 시대의 타임트래블
Replay.io는 같은 철학을 JavaScript·브라우저·React 에 적용한 도구다. Mozilla DevTools의 원작자들이 만들었고, 2026년에는 React, Next.js, Cypress, Playwright와 깊이 통합돼 있다.
작동 방식은 이렇다. 개발자가 Replay 브라우저(Firefox·Chromium 포크)로 사이트를 열고 녹화 버튼을 누르면, 모든 DOM 이벤트·네트워크·콘솔·React 컴포넌트 상태가 클라우드에 적힌다. 그 URL을 동료에게 보내면 동료는 자기 머신에서 같은 실행을 시간 축으로 본다.
- 콘솔 로그를 미리 시간 축에 박는다 —
console.log가 아니라 "print statement at this point"를 UI에서 추가하면 클라우드가 그 시점의 값들을 계산해 돌려준다. - React DevTools의 모든 컴포넌트 상태를 임의의 시점에서 본다 — 렌더링 N번째와 N+1번째에서 props가 어떻게 바뀌었는지 직접 비교한다.
- CI 통합 — Cypress·Playwright 테스트가 실패하면 Replay 녹화가 자동으로 첨부된다.
이것이 의미하는 바는 크다. 프론트엔드에서 "내 컴퓨터에선 안 되는데"를 영원히 끝낼 수 있다.
7장 · WinDbg Preview와 Time-Travel Debugging (TTD) — Windows의 답
Windows 진영의 답은 WinDbg Preview(2017년 첫 공개, 2026년 Microsoft Store 정식판)와 그 위의 TTD(Time Travel Debugging)다. TTD는 tttracer.exe 로 프로세스를 녹화해 .run 파일을 만든다. WinDbg Preview가 그 파일을 열면 g-(go backward), t-(step backward), p-(next backward) 같은 명령으로 시간을 거꾸로 걷는다.
0:000> g
Breakpoint 0 hit
0:000> p- ; 한 줄 뒤로
0:000> g- ; 충돌 이전으로 계속
0:000> dx -r1 @$curprocess.Threads
TTD의 강점은 프로덕션 친화성이다. 운영 중인 Windows 서버에서 한 시간짜리 트레이스를 녹화해 USB로 빼낼 수 있다. 약점은 Windows·x64에 한정된다는 것과 트레이스 파일 크기가 매우 크다는 것이다.
Visual Studio IntelliTrace(Enterprise SKU 한정)는 .NET 진영의 같은 기능이다. .NET 9/10 코드에서 함수 호출 단위로 "역사적 디버깅"을 한다. 이벤트 기반이라 매 줄을 녹화하지는 않지만, 콜 트리를 거슬러 올라가는 용도로는 충분하다.
8장 · RevDeBug · Firefox WebReplay — 그 외 타임트래블 가족
- RevDeBug는 .NET·Java·JavaScript에 코드 인스트루멘테이션으로 타임트래블을 제공하는 상용 도구다. CI에서 실패한 테스트의 마지막 N분을 자동 녹화해 PR에 첨부하는 기능이 강력하다.
- Firefox WebReplay는 Mozilla가 2019년에 시도했다가 중단했고, 이후 Replay.io 팀이 사실상 그 정신을 이어받았다. 현재 Firefox 자체의 WebReplay는 부분적으로만 살아 있다.
- Cisco Joulescope는 엄밀히 디버거가 아니라 마이크로암페어 단위 전력 측정기지만, IoT/펌웨어 디버깅에서 "이 줄 이후 평균 전류가 5mA 증가했다"는 종류의 버그 추적에 결정적이다. 시간 축 데이터라는 의미에서 타임트래블의 한 변종이라 부를 만하다.
9장 · AddressSanitizer · UBSan · ThreadSanitizer — 컴파일러가 도와주는 동적 분석
AddressSanitizer (ASan) 은 Google이 2012년 공개한 컴파일러 기반 메모리 오류 검출기다. LLVM과 GCC 양쪽에 들어 있고, 2026년에는 MSVC까지 정식 지원한다. 컴파일 시 플래그 한 줄을 추가하면 모든 메모리 접근에 그림자(shadow memory) 검사가 삽입된다.
clang -O1 -g -fsanitize=address -fno-omit-frame-pointer -o prog prog.c
./prog
==12345==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000000010
READ of size 4 at 0x602000000010 thread T0
#0 0x401234 in main /home/x/prog.c:42:5
freed by thread T0 here:
#0 0x4af8f0 in free
#1 0x401111 in main /home/x/prog.c:39:5
검출 대상은 heap buffer overflow, stack buffer overflow, global buffer overflow, use-after-free, use-after-return, use-after-scope, double-free, memory leak(LeakSanitizer 결합 시). 오버헤드는 약 2배 메모리, 1.5~3배 CPU 정도라 단위 테스트와 CI에서 상시 켜두는 것이 표준이다.
자매 도구도 같은 인프라를 쓴다.
- UndefinedBehaviorSanitizer (UBSan) —
-fsanitize=undefined. 정수 오버플로, 정렬 위반, null 포인터 역참조, shift 오버플로 등 UB를 잡는다. - ThreadSanitizer (TSan) —
-fsanitize=thread. 데이터 레이스를 잡는다. happens-before 알고리즘 기반. - MemorySanitizer (MSan) — 초기화되지 않은 메모리 사용을 잡는다. 라이브러리 전체를 MSan 빌드해야 해서 적용 비용이 크다.
- HWASan — ARM64의 하드웨어 태그 메모리 기능을 활용해 ASan 오버헤드를 1.2배 수준으로 낮춘다.
10장 · Valgrind와 그 가족 — 가상 머신 위에서 모든 것을 본다
Valgrind는 1999년 Julian Seward가 시작한 도구로, 사용자 프로세스를 가상 머신 위에서 실행해 모든 메모리 접근을 가로챈다. 이름이 같은 프레임워크 안에 여러 도구가 있다.
| 도구 | 기능 |
|---|---|
| Memcheck | 메모리 오류, 누수 |
| Helgrind | POSIX 스레드 데이터 레이스 |
| DRD | 또 다른 데이터 레이스 검출기 |
| Callgrind | 콜 그래프 + 명령어 카운트 |
| Cachegrind | 캐시 시뮬레이션 |
| Massif | 힙 프로파일링 |
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./prog
==12345== HEAP SUMMARY:
==12345== in use at exit: 24 bytes in 1 blocks
==12345== total heap usage: 3 allocs, 2 frees, 96 bytes allocated
==12345==
==12345== 24 bytes in 1 blocks are definitely lost in loss record 1 of 1
==12345== at 0x4C2BBAF: malloc
==12345== by 0x4006A8: leak_func (leak.c:7)
Valgrind vs ASan 트레이드오프 는 2026년에도 흥미롭다.
| 항목 | Valgrind/Memcheck | AddressSanitizer |
|---|---|---|
| 재컴파일 필요 | 불필요 (바이너리 그대로) | 필요 |
| 오버헤드 | 약 20~50배 | 약 2~3배 |
| 검출 범위 | 매우 넓음(uninit, 미세 누수) | 매우 깊지만 스택/힙 위주 |
| 멀티스레드 | 약함 (Helgrind는 별도) | 좋음 |
| 외부 라이브러리 | 그대로 검사 가능 | 라이브러리도 ASan 빌드 권장 |
| 플랫폼 | Linux 위주 | Linux/Mac/Windows |
원칙은 단순하다. 소스가 있고 CI가 있다면 ASan, 남이 만든 바이너리만 있다면 Valgrind.
Dr.Memory는 Valgrind 정신을 Windows·Linux에 동등하게 가져온 도구로, MSVC 빌드된 바이너리에 강하다. AppVerifier는 Windows 내장의 비슷한 도구다.
11장 · perf와 FlameGraph — 리눅스 성능 디버깅의 황금 콤보
성능 문제는 디버깅의 별종이다. "충돌은 없는데 느리다"가 가장 잡기 어려운 버그다. Linux에서는 perf(linux-tools)와 Brendan Gregg의 FlameGraph 가 사실상 표준이다.
# CPU 프로파일 99Hz로 60초 채집
perf record -F 99 -g -p <PID> -- sleep 60
perf report --stdio | head -50
perf script | flamegraph.pl > flame.svg
perf script | flamegraph.pl이 만드는 SVG는 한 줄 요약하면 "어디서 CPU 시간을 다 쓰는지 한눈에"다. 시니어 엔지니어가 30초 만에 핫스팟을 찾는 도구로 자주 쓰인다.
perf의 확장도 함께 봐야 한다.
perf stat— 명령 한 번의 PMU 이벤트(IPC, cache miss, branch miss) 요약perf c2c— 캐시-투-캐시 false sharing 검출perf lock— 락 컨텐션perf mem— 메모리 접근 샘플링
2026년에는 perf 가 eBPF 후술 도구들에 일부 자리를 내줬지만, 여전히 "처음 들어가는 문"이다.
12장 · eBPF · bpftrace · BCC · Tetragon — 커널이 디버거를 품다
eBPF(extended Berkeley Packet Filter)는 2026년 가장 변혁적인 디버깅·관측 인프라다. 사용자가 작성한 작은 프로그램이 커널 내 안전한 VM에서 실행되며, 어떤 함수든 진입·종료를 가로채 데이터를 사용자 공간으로 전달한다.
# 어떤 프로세스가 어떤 파일을 여는지 30초간 본다
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_openat {
printf("%s %s\n", comm, str(args->filename));
}'
# 시스템 전체 read() 지연 분포
sudo bpftrace -e '
tracepoint:syscalls:sys_enter_read { @start[tid] = nsecs; }
tracepoint:syscalls:sys_exit_read /@start[tid]/ {
@ns = hist(nsecs - @start[tid]);
delete(@start[tid]);
}'
위 도구 가족을 정리하면 이렇다.
- bpftrace — DTrace 스타일 원라이너. 가장 빠르게 한 줄 답을 얻는다.
- BCC(BPF Compiler Collection) — Python/C 기반의 더 큰 도구 모음.
tcpconnect,execsnoop,opensnoop같은 즉시 쓸 수 있는 도구가 100개 넘게 들어 있다. - Tetragon — Isovalent의 보안·관측 도구. eBPF로 컨테이너 안의 시스템 콜·파일 접근·네트워크 호출을 정책 기반으로 잡아낸다.
- Pixie(NewRelic 인수) — Kubernetes 클러스터를 eBPF로 자동 관측.
eBPF의 진짜 장점은 프로덕션 안전성이다. 커널 모듈처럼 panic을 일으키지 않는다. verifier가 무한 루프, 잘못된 메모리 접근을 컴파일 단계에서 차단한다. 그래서 "프로덕션에서 디버그 코드를 켤 수 있는 거의 유일한 방법"으로 평가받는다.
13장 · strace · ltrace · dtrace — 시스템 콜 레벨 디버깅
eBPF가 모든 곳에 깔리기 전까지, 그리고 깔린 뒤에도 strace는 여전히 일급 시민이다. "프로세스가 뭘 하고 있는지 1분 만에 알아야 할 때" 가장 빠른 도구다.
# 시스템 콜 모두 추적
strace -f -o trace.log ./prog
# 특정 호출만 + 시간 측정 + 인자 디코딩
strace -e openat,read,write -T -tt ./prog
# 이미 떠 있는 PID에 붙기
sudo strace -p 12345 -e network
ltrace는 같은 일을 라이브러리 호출(libc, libssl 등) 수준에서 한다. dtrace는 Solaris 출신으로 macOS에 살아남았고, Linux의 eBPF·SystemTap·LTTng 가 같은 영역을 더 강력하게 점유했다.
여기서 자주 잊는 트릭. strace -c는 "어떤 시스템 콜에 시간이 가장 많이 갔는가"를 요약해 준다. CPU 프로파일보다 빠르게 I/O-bound 여부를 판별하는 방법이다.
14장 · JFR · async-profiler · py-spy · Delve — 언어별 디버거
언어 런타임마다 특화된 디버깅 도구가 따로 있다.
- JFR(Java Flight Recorder) — JDK에 내장된 항상 켜둘 수 있는 프로파일러. 오버헤드 약 1%.
jcmd <pid> JFR.start한 줄이면 시작. - async-profiler — JFR의 한계를 보완하는 오픈소스. native stack까지 잡는다. Linux에서 perf_events와 결합.
- py-spy — CPython 프로세스에 ptrace 또는 process_vm_readv로 붙어 GIL을 멈추지 않고 스택을 샘플링한다. 프로덕션에서 안전하다는 점이 강력.
- py-buggy — 인터랙티브 디버깅 모드를 IPython 위에 얹은 모던 PDB 대안.
breakpoint()를 더 풍부하게. - rust-gdb / rust-lldb / lldb-rust — Rust 표준 배포에 같이 오는 래퍼.
Vec<T>,Box<T>,Result같은 타입을 사람이 읽을 수 있는 형태로 출력한다. - Delve (dlv) — Go의 사실상 표준 디버거.
dlv debug,dlv attach <pid>,dlv test. goroutine 단위 디버깅이 강점. - Bytecode Alliance debugging tools — WebAssembly 디버깅 인프라. wasm-debug, wasmtime의
-Dgdb-server, Component Model의 trace 도구가 점차 표준화된다.
# Go 디버깅 흐름
dlv debug ./main.go
(dlv) break main.handleRequest
(dlv) continue
(dlv) goroutines
(dlv) goroutine 17
(dlv) stack
(dlv) locals
(dlv) print req.Body
15장 · Chrome DevTools · React DevTools — 프론트엔드 디버깅의 표준
브라우저 디버깅은 별도 우주다. Chrome DevTools는 2026년에도 사실상 표준이고, Firefox DevTools, Safari Web Inspector가 그 뒤를 따른다.
핵심 패널만 정리하면 이렇다.
- Sources — 중단점, 조건부 중단점, 로그포인트(
console.log없이 일시적 로그), Workspace 동기화로 디스크에 바로 저장 - Performance —
performance.mark와performance.measure로 사용자 정의 타임라인 - Memory — 힙 스냅샷 + 비교 + retainer 트리. 누수 추적의 표준
- Network — HAR export, throttling, override(응답을 임의로 가짜 데이터로 교체)
- Application — IndexedDB, Service Worker, Storage 검사
- Recorder — 사용자 액션을 녹화해 Playwright/Cypress 스크립트로 변환
React DevTools는 이 위에 컴포넌트 트리, props/state, Profiler를 얹는다. 2026년에는 React Compiler가 자동으로 메모이즈하면서 "왜 리렌더 됐는가"의 분석이 더 중요해졌고, React DevTools Profiler의 Why did this render? 패널이 표준 답이다.
브라우저 디버깅의 가장 큰 변화는 9장에서 본 Replay.io의 시간 축 통합이다.
16장 · 커널 디버깅 — kgdb · crash · KASAN · KCSAN
커널은 별종이다. 일반 디버거를 그대로 쓸 수 없다. 2026년 Linux 커널 디버깅 도구는 다음과 같이 분화돼 있다.
- kgdb — 커널 자체에 GDB stub. 시리얼/네트워크로 다른 머신의 GDB와 연결.
- kdb — 커널 콘솔에서 기본 디버거. 시리얼 케이블과 함께.
- crash(by Red Hat) — vmcore 덤프 분석 도구. 패닉이 난 뒤 사후 분석.
- drgn — Meta가 만든 파이썬 기반 커널·코어덤프 분석기. 커널 자료구조를 파이썬 객체로 노출.
- KASAN(Kernel AddressSanitizer) — ASan을 커널에 적용. 커널 use-after-free, out-of-bounds를 빌드 옵션으로 잡는다.
- KCSAN(Kernel Concurrency Sanitizer) — 커널의 데이터 레이스 검출.
- KFENCE(Kernel Electric-Fence) — 샘플링 기반 메모리 안전 검사. 프로덕션에 켜둘 수 있을 만큼 가볍다.
- ftrace — 커널 내부 함수 추적. perf와 함께 가장 많이 쓰임.
eBPF가 커널 디버깅의 많은 영역을 잠식했지만, "커널 자체가 죽었을 때"는 여전히 crash + drgn + vmcore의 조합이 정답이다.
17장 · Heisenbug와 재현성 — 디버깅의 진짜 적
Heisenbug는 "관찰하면 사라지는 버그"라는 농담이다. 디버거를 붙이면 안 나고, 프린트를 박으면 안 나고, ASan을 켜면 안 난다. 이런 버그가 진짜 어려운 이유는 비결정성 때문이다.
비결정성의 원천을 분류하면 이렇다.
| 원천 | 예시 | 대응 도구 |
|---|---|---|
| 스레드 스케줄 | 데이터 레이스 | TSan, Helgrind, rr |
| 메모리 할당 위치 | UAF에서 새 객체가 같은 주소에 | ASan, hardened allocator |
| 외부 시간/난수 | time(), rand(), rdtsc | rr (모두 녹화) |
| 네트워크 지연 | RPC 타이밍 | Replay.io, OpenTelemetry |
| 하드웨어 비결정성 | rdtsc, cache miss | rr (rdtsc 가로채기) |
이 모든 원천을 녹화 후 재생 으로 결정론적으로 만든다는 것이 rr·Pernosco·TTD·Replay.io의 공통 가치 제안이다.
또 하나의 해결책은 Property-based testing + fuzzing. AFL++, libFuzzer, Honggfuzz, Atheris(Python)가 자동으로 입력을 변형하며 충돌을 유발한다. 충돌이 생기면 그 코퍼스(corpus)를 가지고 재현 가능한 단위 테스트를 만든다.
18장 · 프로덕션에서 디버깅하기 — 관측 가능성과의 경계
"내 노트북에선 안 되는 버그"가 프로덕션에서만 난다면 어떻게 해야 하는가. 2026년의 답은 두 갈래다.
- 관측 가능성(Observability)으로 충분한 단서를 모은다 — OpenTelemetry trace, structured logs, RED 메트릭, 분산 컨텍스트 전파. Datadog, Honeycomb, Grafana Tempo, Jaeger.
- 프로덕션에 안전한 디버그 채널을 둔다 — eBPF/bpftrace로 라이브 추적, async-profiler로 1% 오버헤드 프로파일, JFR을 24/7 켜두기, py-spy로 GIL을 멈추지 않고 스택 샘플링.
OpenTelemetry 와 디버거의 관계는 직교(orthogonal)다. OpenTelemetry는 "어디서 느린지, 어디서 에러가 나는지" 까지 알려준다. 그 뒤로는 디버거의 영역이다. 좋은 시스템은 둘 사이를 매끄럽게 연결한다. 예를 들어 OpenTelemetry trace ID를 코어 덤프 파일명에 박아두면, trace에서 본 인스턴스의 덤프를 정확히 집어낼 수 있다.
가장 강한 패턴은 Pernosco 스타일의 프로덕션 녹화 + 비동기 분석이다. 일부 회사는 rr 녹화를 카나리 호스트에 항상 켜 두고, 충돌이 나면 자동으로 Pernosco에 업로드한다.
19장 · 도구 비교표 — 한눈에 보는 2026 디버거 지형
+----------------+-----------+----------+-----------+------------+-----------+
| 도구 | 플랫폼 | 녹화 | 역방향 | 멀티스레드 | 가격 |
+----------------+-----------+----------+-----------+------------+-----------+
| gdb | Linux/Mac | record | yes(소) | 약함 | free |
| lldb | All | - | - | 보통 | free |
| WinDbg+TTD | Windows | tttracer | yes | 좋음 | free |
| rr | Linux x64 | 강력 | yes | 좋음 | free |
| Pernosco | Cloud | rr 기반 | yes(즉시) | 매우 좋음 | 유료 |
| Replay.io | Browser | 강력 | yes | n/a(JS) | 유료 |
| IntelliTrace | Windows | yes | yes(이벤트)| 보통 | VS Ent. |
| RevDeBug | .NET/JVM | yes | yes | 좋음 | 유료 |
| Delve | Linux/Mac | - | - | 좋음 | free |
| py-spy | All | sampling | - | 좋음 | free |
| Chrome DevTools| Browser | - | - | n/a | free |
+----------------+-----------+----------+-----------+------------+-----------+
이 표의 가장 큰 메시지는 "하나로 다 못 한다". C++ 서버는 rr+ASan, .NET 데스크탑은 WinDbg+TTD, 프론트는 Replay.io, Go 마이크로서비스는 Delve + Datadog, Python 데이터 파이프라인은 py-spy + JFR-equivalent.
20장 · AI 디버깅 — Cursor, Copilot Debug, Devin이 바꾼 것
2026년에 가장 빠르게 변하는 영역이 AI 디버깅이다.
- Cursor AI Debug — 에디터 안에서 디버거를 자동 제어한다. "이 테스트가 왜 실패해?"라고 물으면 자동으로 breakpoint을 걸고, 실행하고, 변수를 살피고, 가설을 세워 답한다.
- GitHub Copilot Debug — Copilot이 디버거의 첫 번째 손가락이 됐다. 충돌 스택을 붙여 넣으면 가능한 원인 3개와 다음 조치를 제시한다.
- Devin / Replit Agent — 자율 코딩 에이전트는 "버그 → 가설 → 수정 → 테스트 → PR"을 통째로 시도한다. 작은 버그에서는 종종 작동한다.
- Pernosco Copilot — Pernosco가 자체 LLM을 결합해 "이 변수가 0이 된 이유"를 시간 축에서 자동으로 거꾸로 추적해 자연어로 설명한다.
AI 디버깅이 잘하는 영역과 못하는 영역은 분명히 나뉜다.
| 잘하는 영역 | 못하는 영역 |
|---|---|
| 스택 트레이스 해석 | 도메인 지식이 깊게 필요한 비즈니스 로직 |
| 일반적 NullPointer 류 | 동시성 미묘한 데이터 레이스 |
| 코드 스타일 / 작은 typo | 외부 시스템과의 상호작용 |
| 단일 함수 안의 알고리즘 버그 | 마이크로서비스 사이의 분산 트랜잭션 |
2026년의 현실적 결론은 "AI는 디버거의 가장 빠른 손가락이지, 디버거 자체는 아니다" 이다.
21장 · 한국 엔지니어 커뮤니티의 디버깅 문화
네이버·카카오·라인·쿠팡·배민(이른바 네카라쿠배), 그리고 토스·당근·삼성·LG의 디버깅 문화에는 몇 가지 공통점이 있다.
- 사내 APM과 사내 디버거 — Pinpoint(NAVER), Scouter, NAVER FE-news에서 자주 언급되는 사내 RUM, 카카오의 분산 트레이싱, 라인의 Promgen 같은 도구들이 OpenTelemetry 이전부터 진화했다.
- 사내 빌드된 ASan/UBSan CI 파이프라인 — C++ 비중이 큰 게임 회사(넥슨·NC·스마일게이트)에서는 빌드 봇에 ASan/TSan이 상시 켜져 있다.
- 장애 회고와 포스트모템 문화 — 토스, 우아한형제들, 카카오의 공개 장애 회고 글이 한국 엔지니어링 블로그의 명물이다. "재현 가능한 단위 테스트로 끝맺기"가 표준 패턴이다.
- Kubernetes 기반 운영과 eBPF 도입 — 쿠팡의 Cilium 도입, 카카오의 eBPF 보안 사례가 2024~2026년에 공개됐다.
- 사내 LLM 디버깅 어시스턴트 — 네이버 HyperCLOVA X, 카카오의 KoGPT 기반 사내 코드 도우미가 디버깅 페어 역할을 한다.
한국 커뮤니티의 강점은 포스트모템의 공개성과 구체성이다. "왜 이 변수가 null이었는지"를 회사 블로그에 공개하는 문화가 상대적으로 강하다.
22장 · 일본 엔지니어 커뮤니티의 디버깅 문화
일본은 다른 결을 가진다.
- 라이브 디버깅 발표 문화 — Builderscon, JAWS, Rust.Tokyo, RubyKaigi, JJUG CCC, PyCon JP에서 "실제로 무대 위에서 디버깅하는 세션"이 빈번하다. 매년 RubyKaigi에서는 ruby/debug 메인테이너가 라이브 데모를 한다.
- ruby/debug, rdbg, debug.gem — Ruby 3.x 표준 디버거를 만든 Koichi Sasada(SmartHR/유한)가 만든 시리즈가 일본 Ruby 생태계의 디버깅을 단단히 했다.
- JVM 기반 대기업 — 라쿠텐(Rakuten), LINE Yahoo, SBI, 메루카리(Mercari)에서 JFR + async-profiler 활용이 깊다. 메루카리의 SRE 블로그는 perf/FlameGraph 사례를 꾸준히 공개한다.
- 로컬 C++ 임베디드 디버깅 깊이 — 소니, 캐논, 키엔스, 파나소닉의 임베디드 팀이 gdb + JTAG + Lauterbach TRACE32 조합으로 깊은 디버깅을 한다.
- PFN과 Preferred Networks — Python·CUDA·머신러닝 디버깅에서 NVIDIA Nsight, py-spy, torch.profiler를 깊게 쓴 사례가 풍부.
문화적으로 일본은 "재현 가능한 작은 예제(MCVE)와 깔끔한 패치"를 매우 중시한다. 오픈소스에 보고하는 버그 리포트의 품질이 평균적으로 높기로 유명하다.
23장 · 디버깅 워크플로우 레시피 — 상황별 도구 매칭
마지막으로 실전 매칭표.
| 증상 | 1차 도구 | 2차 도구 | 3차 도구 |
|---|---|---|---|
| C++ 서버가 가끔 SEGV | gdb core file 분석 | ASan + 재시도 | rr 녹화 |
| Linux 머신이 가끔 멈춤 | dmesg, journalctl | bpftrace 시스템콜 분포 | crash + drgn |
| Node 서버가 메모리 누수 | Chrome DevTools 힙 스냅샷 | clinic.js heap | jemalloc heap profile |
| React UI가 가끔 잘못 그림 | React DevTools Profiler | Replay.io 녹화 | console.log 시계열 비교 |
| Python 잡이 느려짐 | py-spy top --pid | cProfile + snakeviz | scalene |
| Go 서버 goroutine leak | pprof goroutine | dlv trace | OpenTelemetry trace |
| JVM이 GC pause로 끊김 | JFR 한 시간 녹화 | async-profiler alloc | GC log + GCViewer |
| Windows .NET 충돌 | WinDbg + TTD | IntelliTrace | dotnet-dump |
| Linux 커널 패닉 | crash + vmcore | drgn | KASAN 빌드 재현 |
| WebAssembly 무한 루프 | wasmtime --dbg | wasm-debug | rr (host 측) |
이 표를 외울 필요는 없다. 다만 "증상에 맞는 도구를 모르고 있다는 사실 자체를 인지하라" 가 시니어와 주니어를 가르는 가장 큰 차이다.
24장 · 2030년의 디버깅 — 어디로 가는가
마지막 장은 짧은 전망이다.
- 레코드 리플레이가 IDE 기본이 된다. VS Code의 "Record this run" 버튼이 표준이 될 가능성이 높다.
- AI가 가설을 세우고 디버거가 실행한다. Cursor·Devin이 시범으로 보여준 패턴이 IDE 기본 기능으로 들어온다.
- eBPF가 OS 추상화를 갈아엎는다. 모든 관측·디버깅이 커널 레벨에서 통합되고, 컨테이너 안에서도 안전하게 호스트를 본다.
- 하드웨어 디버그 채널이 부활한다. Intel Processor Trace, ARM CoreSight ETM은 PMU 기반 rr·Pernosco의 핵심 인프라가 됐고, RISC-V는 처음부터 이를 표준에 넣고 있다.
- WebAssembly 디버깅이 1급 시민 이 된다. Component Model의 trace 표준이 정해지면 wasm 모듈도 시간 축으로 본다.
- "녹화 없는 디버깅은 옛날 일" 이라는 농담이 진지해진다.
가장 큰 변화는 문화일 것이다. 2026년에는 "재현 안 됨"이 종종 받아들여진다. 2030년에는 그 말이 "녹화를 안 했다"의 동의어가 된다.
25장 · 마무리 — 도구가 아니라 마음가짐
이 글이 25장에 걸쳐 한 일은 결국 도구 목록을 나열한 것이다. 그러나 디버깅의 본질은 도구가 아니다.
좋은 디버깅의 마음가짐은 다음과 같다.
- "내가 틀렸을 것" 을 기본 가설로 둔다. 컴파일러가 아니라 내 코드를 의심하라.
- 재현 가능한 가장 작은 예제 를 만든다. 재현되는 순간 절반은 끝났다.
- 이론을 세우고 그 이론을 죽이려고 노력한다. 확증 편향을 피하는 유일한 방법이다.
- 로그를 잘 남기는 것은 미래의 자신에게 보내는 편지다. 구조화된 로그·트레이스·메트릭이 6개월 뒤의 당신을 살린다.
- 녹화하라. 비용이 떨어졌다. 변명이 없다.
도구는 가설을 검증하는 손가락이고, 마음가짐은 가설을 세우는 머리다. 둘 다 갖춰야 비로소 버그 앞에서 떨지 않는다.
References
- GNU GDB Documentation — https://sourceware.org/gdb/current/onlinedocs/gdb/
- LLDB Project — https://lldb.llvm.org/
- rr Project — https://rr-project.org/
- Pernosco — https://pernos.co/
- Replay.io Docs — https://docs.replay.io/
- Google Sanitizers — https://github.com/google/sanitizers
- Valgrind Project — https://valgrind.org/
- Dr.Memory — https://drmemory.org/
- Brendan Gregg — Linux Performance — https://www.brendangregg.com/linuxperf.html
- bpftrace — https://bpftrace.org/
- BCC — https://github.com/iovisor/bcc
- Tetragon — https://github.com/cilium/tetragon
- OpenTelemetry — https://opentelemetry.io/
- Microsoft WinDbg + TTD Docs — https://learn.microsoft.com/windows-hardware/drivers/debugger/time-travel-debugging-overview
- Java Flight Recorder Docs — https://docs.oracle.com/javacomponents/jmc.htm
- async-profiler — https://github.com/async-profiler/async-profiler
- py-spy — https://github.com/benfred/py-spy
- Delve — https://github.com/go-delve/delve
- drgn — https://github.com/osandov/drgn
- Linux Kernel Sanitizers — https://docs.kernel.org/dev-tools/kasan.html