DDD는 훌륭한 디버거였는데, 현대판 디버거는 어떤 모습이어야 할까?

• HN에서 "옛날 DDD(Data Display Debugger) 같은 그래픽 디버거의 현대판이 있었으면 좋겠다"는 질문이 올라왔고, 꽤 깊이 있는 토론이 이어짐

"Xcode Metal API 디버거를 CPU 디버거로 가져오고 싶다"

• 한 개발자가 Xcode의 Metal API 디버거를 이상적인 모델로 꼽음. 의존성과 데이터 플로우를 실제 그래픽 UI로 시각화하고, 데이터를 hex 덤프가 아니라 이미지나 3D 메시로 볼 수 있는 게 핵심
• CPU 쪽에서 어려운 이유: GPU API는 데이터 포맷과 의존성을 추론할 수 있는 시맨틱이 풍부한데, CPU 코드는 그런 맥락이 부족함. "프로그래밍 언어에서 디버거로 더 풍부한 디버그 정보를 터널링하는 방법"이 핵심 과제
• Dear ImGui 같은 라이브러리로 앱 내부에 실시간 디버깅 UI를 직접 만드는 중간 지대도 있음. 게임 개발에서는 이미 매우 흔한 패턴

타임 트래블 디버거에 대한 논의

• rr 같은 타임 트래블 디버거 (record/replay) 얘기도 나옴. 이전 상태로 되돌아가고, 스냅샷 찍고, "상태 포크"를 탐색하고, 라이브 에디팅/핫 코드 리로딩까지 되면 개발과 디버깅이 하나의 워크플로우로 합쳐질 수 있다는 비전
• 반론도 있음: 분산 시스템에서 가장 어려운 버그는 재현 자체가 안 됨. 라이브 디버거 아래서 재현해야만 쓸 수 있는 도구는, 가장 어려운 문제에 가장 강력한 도구를 못 쓰게 되는 아이러니가 있다는 지적

AI 에이전트가 디버깅을 바꿀 수 있을까?

• 한 의견이 흥미로움: AI 에이전트 시대에 디버깅은 "수사(investigation)" 관리가 될 수 있다는 거임
  • 관리 단위는 "수사" (= 에이전트)
  • 주요 인터페이스는 리치 채팅 (코드, 데이터 포맷팅 포함)
  • 핵심 산출물은 코드가 아니라 "단서(clues)"와 "증거(evidence)"
  • 이론과 증거 조각을 관리하는 게 이미 전통적 디버깅의 핵심인데, 에이전트가 이걸 명시적 프로세스로 만들어줄 수 있다는 아이디어

기타 흥미로운 포인트들

• "printf 디버깅은 소스 코드가 있는 프로그램에서만 가능함. 디버거는 이미 실행 중인 프로그램, 다른 머신의 프로그램, 바이너리만 있는 프로그램까지 관찰하고 제어할 수 있음" — 디버거를 전문 기술로 대우해야 한다는 주장
• FoundationDB의 테스팅 프레임워크 접근법도 언급됨: 싱글스레드 + 멀티프로세스, 프로덕션 assert, 인메모리 링 버퍼 바이너리 로그 등으로 소프트웨어 자체를 디버깅 가능하게 만드는 방식
• 임베디드 쪽에서는 Scrutiny Debugger 같은 도구도 있음. 인스트럭션 트레이스로 타겟에서 실행된 모든 명령을 호스트로 보내는 방식
• 퍼저(fuzzer)와 디버거를 결합해서 "프로그램의 상태 A에서 상태 B로 전이하는 입력을 자동으로 찾는 도구"를 만들 수 있지 않을까 하는 아이디어도 나옴