무슨 일인가요
한 개발자가 Windows에서 네이티브 프로그램이 죽었을 때 남는 크래시 덤프를 분석하는 사후 디버거 ForensicDbg를 만들어 공개했어요. x64와 x86 프로그램을 대상으로 하고, 이름에 '포렌식'이 들어간 것처럼 이미 죽어버린 프로세스의 흔적을 뒤져서 원인을 찾는 데 초점을 맞춘 도구예요.
이게 왜 눈여겨볼 만하냐면요, Windows 네이티브 크래시 분석은 실력 있는 C++ 개발자들 사이에서도 '아는 사람만 아는' 영역이거든요. 도구는 오래전부터 있었지만 진입 장벽이 높아서, 실제로는 덤프 파일이 도착해도 열어볼 엄두를 못 내는 팀이 많아요. 이 영역에 새 도구가 나온다는 것 자체가 반가운 일이에요.
이게 뭐냐면: 사후 디버깅과 크래시 덤프
디버깅은 보통 두 가지로 나눠요. 하나는 라이브 디버깅인데, Visual Studio에서 중단점 걸고 한 줄씩 실행하는 그거예요. 프로그램이 살아있는 동안 들여다보는 방식이죠. 다른 하나가 사후 디버깅, 영어로 post-mortem debugging이에요. 프로그램이 이미 죽은 뒤에 남은 흔적을 분석하는 거예요. 비행기 사고 나면 블랙박스를 회수해서 마지막 순간에 무슨 일이 있었는지 복원하잖아요. 그 블랙박스에 해당하는 게 크래시 덤프예요.
크래시 덤프는 프로그램이 죽는 순간의 메모리 스냅샷이에요. 그 순간 각 스레드가 어떤 함수를 실행 중이었는지, CPU 레지스터에 뭐가 들어있었는지, 어떤 DLL이 로드돼 있었는지가 담겨요. Windows에서는 크게 두 종류가 있는데, 스택과 핵심 정보만 담은 미니덤프는 몇 MB 수준이라 사용자 PC에서 서버로 보내기 좋고, 프로세스 메모리 전체를 담은 풀덤프는 수 GB까지 커지지만 힙 안의 데이터까지 볼 수 있어요. 프로그램이 죽으면 Windows Error Reporting이 자동으로 덤프를 만들어주기도 하고, 앱이 직접 MiniDumpWriteDump API를 호출해서 남기기도 해요.
덤프를 열면 뭘 봐야 하나
덤프를 열었을 때 가장 먼저 필요한 게 심볼이에요. 컴파일된 바이너리에는 함수 이름이 없어요. 그냥 주소만 있죠. 이 주소를 사람이 읽을 수 있는 함수 이름과 소스 파일의 몇 번째 줄인지로 바꿔주는 게 PDB 파일이에요. 빌드할 때 나오는 그 파일이요. 그래서 크래시 분석의 첫 번째 규칙은 '릴리스 빌드마다 PDB를 반드시 보관하라'예요. 이걸 안 해두면 덤프는 그냥 숫자 덩어리가 돼요. Windows 자체 DLL의 심볼은 Microsoft 심볼 서버에서 자동으로 받아올 수 있고요.
그다음이 스택 언와인딩이에요. 죽은 시점의 함수에서 거슬러 올라가 누가 누구를 호출했는지 복원하는 건데, 이게 x64와 x86에서 꽤 달라요. x64는 바이너리 안에 언와인드 정보가 표준으로 들어있어서 비교적 안정적으로 복원되지만, x86은 프레임 포인터 생략 같은 최적화 때문에 스택이 엉망으로 보이는 경우가 많아요. 그래서 x86까지 제대로 지원한다는 건 생각보다 손이 많이 가는 일이에요.
크래시 유형도 몇 가지 패턴이 있어요. 가장 흔한 건 예외 코드 0xC0000005, 접근 위반이에요. null 포인터를 따라가거나 해제된 메모리를 건드렸을 때 나요. 스택 오버플로우는 재귀가 폭주했을 때, 힙 손상은 버퍼를 넘어서 쓴 뒤 한참 뒤에 엉뚱한 곳에서 죽는 식으로 나타나서 가장 골치 아파요. 경험 많은 사람은 예외 코드와 스택만 봐도 대충 감을 잡는데, ForensicDbg 같은 도구는 이런 판단을 도구 쪽에서 먼저 해주려는 방향으로 보여요.
업계 맥락: WinDbg의 그늘 아래
이 분야의 절대 강자는 Microsoft의 WinDbg예요. 덤프를 열고 !analyze -v 한 줄만 치면 크래시 원인 후보를 뽑아주고, 명령어 수백 개로 메모리를 샅샅이 뒤질 수 있어요. 최근에는 WinDbg가 새 UI로 바뀌면서 접근성이 나아지긴 했지만, 여전히 명령어를 외워야 하는 도구라는 본질은 그대로예요. Visual Studio도 덤프를 열 수 있어서 익숙한 화면에서 스택을 볼 수 있지만, 깊이 파고들기엔 부족할 때가 많고요.
수집 쪽에서는 Google의 Crashpad와 Breakpad가 오랫동안 표준처럼 쓰였고, Sentry나 BugSplat 같은 서비스는 덤프를 받아서 심볼 처리까지 자동으로 해주는 파이프라인을 제공해요. 리눅스 세계라면 core dump를 gdb로 여는 것이 같은 역할이죠. ForensicDbg는 이 중에서 '수집' 쪽이 아니라 '분석' 쪽, 그중에서도 WinDbg보다 낮은 진입 장벽을 노리는 위치로 보여요. 이런 도구가 살아남으려면 결국 WinDbg가 자동으로 못 잡아내는 경우를 얼마나 잘 설명해주느냐가 승부처가 될 거예요.
한국 개발자에게 주는 시사점
게임 클라이언트, 데스크톱 앱, 드라이버, 언리얼이나 유니티 네이티브 플러그인처럼 Windows에서 C++로 뭔가를 만드는 분들에게는 직접적으로 유용한 이야기예요. 웹 개발자라도 Electron 앱의 네이티브 모듈이 죽거나, Node.js 애드온이 문제를 일으키면 결국 여기로 오게 돼요.
도구를 쓰기 전에 먼저 해둘 게 있는데요, 사용자 PC에서 덤프가 자동으로 남도록 WER 로컬 덤프 설정을 하거나 앱에 덤프 생성 코드를 넣어두고, 릴리스 빌드의 PDB를 버전별로 보관하는 파이프라인부터 갖추는 거예요. 이 두 가지가 없으면 아무리 좋은 분석 도구가 있어도 열어볼 덤프가 없거나 열어도 읽을 수가 없어요. 그리고 새 도구를 평가할 때는 자기 팀의 실제 덤프 몇 개를 WinDbg의 분석 결과와 나란히 놓고 비교해보는 게 가장 빨라요.
정리
한 줄 정리: 크래시 덤프는 죽은 프로그램의 블랙박스이고, PDB 보관과 덤프 수집만 갖춰두면 사후 분석 도구가 진짜 힘을 발휘해요.
여러분 팀은 프로덕션 크래시를 어떻게 잡고 있나요? 덤프를 모으고 있는지, 아니면 사용자 재현 제보에 의존하고 있는지 궁금해요.
🔗 출처: Hacker News