대형 C/C++ 프로젝트에서 디버깅이 늦어지는 이유는 실행을 멈추고 상태를 살피는 시간만이 아니다. 바이너리를 링크하고, 큰 디버그 정보를 처리하고, 디버거가 읽을 수 있는 형태로 준비하는 과정도 개발자의 대기 시간을 만든다. EpicGames의 RAD Debugger 프로젝트는 이 흐름을 디버거 하나의 문제가 아니라 도구체인 전체의 문제로 바라본다.
RAD Debugger는 네이티브 user-mode 그래픽 디버거이며 멀티프로세스 디버깅을 지원한다. 다만 현재 지원 범위는 로컬 Windows x64와 PDB 기반이고, 프로젝트는 알파 단계다. README는 사용법 문서가 아니라 기술 개요라고 명시하므로, 실제 사용 절차는 릴리스에 포함된 별도 문서를 확인해야 한다. Linux 네이티브 디버깅과 DWARF 지원은 현재 기능이 아니라 향후 계획이다.
구조의 중심에는 RAD Debug Info, 즉 RDI가 있다. 디버거는 툴체인이 기본 생성하는 PDB를 직접 사용하는 대신 자체 포맷으로 변환해 읽는다. 변환 도구 `radbin`은 기존 디버그 정보에서 RDI를 만들고, RDI 내용을 텍스트로 덤프할 수 있다. 프로젝트에는 RDI를 구성하고 직렬화하는 라이브러리도 개발 중이다. 이 선택은 포맷을 통일하고 처리 과정을 프로젝트가 통제할 여지를 주지만, 변환 경로와 포맷 자체를 함께 성숙시켜야 한다는 부담도 동반한다.
RAD Linker는 이 설계를 빌드 단계까지 이어준다. x64 PE/COFF 바이너리용으로 대형 링크 프로젝트를 겨냥하며, 표준 PDB 생성에 더해 RDI를 네이티브로 만들 수도 있다. 디버깅 직전에 PDB를 RDI로 변환하는 과정을 줄이는 것이 그 연결의 실질적인 이점이다. README에 따르면 디버그 정보가 여러 기가바이트인 테스트 사례에서 링크 시간이 50% 빨라졌다. 이는 프로젝트가 제시한 테스트 결과이며, 다른 코드베이스나 하드웨어에서 같은 개선을 기대할 근거로 일반화해서는 안 된다.
도입 판단에는 제한 사항도 중요하다. RAD Linker는 링크 타임 최적화를 아직 지원하지 않는다. 큰 페이지 메모리는 추가로 링크 시간을 줄일 수 있지만 기본 비활성화돼 있고, 일반 Windows 환경에서는 메모리 단편화를 빠르게 일으켜 재부팅이 필요할 수 있다고 README가 경고한다. 프로젝트도 Docker나 VM처럼 링크 뒤 환경을 초기화할 수 있는 경우에만 사용을 권한다.
따라서 이 프로젝트의 매력은 성능 숫자 하나보다 설계의 연결성에 있다. 디버거가 소비하는 포맷을 정하고, 변환 도구와 링커가 그 포맷을 함께 다루게 해 링크부터 디버깅까지의 비용을 줄이려 한다. Windows x64 대형 프로젝트라면 실제 빌드에서 링크 시간과 디버거 준비 시간을 각각 측정해 볼 만하다. 다만 알파 단계, 제한된 플랫폼 지원, LTO 부재를 감안해 기존 파이프라인을 대체하기보다 검증 가능한 범위에서 평가하는 편이 타당하다.