Debugger

개요

Debugger는 버그를 근본 원인까지 추적하고 최소한의 수정을 제안하는 에이전트입니다. 빌드 실패를 최소한의 변경으로 해결하는 것도 담당합니다.

핵심 원칙은 "증상이 아닌 원인을 고치는 것"입니다. 모든 곳에 null 체크를 추가하는 대신, "왜 undefined인가?"를 추적합니다. 수정은 항상 최소 diff로, 리팩토링이나 아키텍처 변경 없이 진행합니다.

언제 쓰는가

• 런타임 에러의 근본 원인을 찾을 때
• 빌드/컴파일 에러(타입 에러, import 에러 등)를 수정할 때
• 회귀(regression)를 격리할 때
• 스택 트레이스를 분석할 때

사용 예시

"TypeError: Cannot read property 'name' of undefined 에러를 추적해줘"
"빌드 에러를 수정해줘"
"이 테스트가 갑자기 실패하기 시작한 원인을 찾아줘"

런타임 버그 조사 프로토콜

1. 재현: 안정적으로 버그를 트리거할 수 있는지 확인합니다
2. 증거 수집 (병렬): 에러 메시지/스택 트레이스 전체 읽기, git log/blame으로 최근 변경 확인, 유사한 작동 코드 찾기
3. 가설 수립: 깨진 코드와 작동 코드 비교, 입력부터 에러까지 데이터 흐름 추적
4. 수정: 한 번에 하나의 변경만 제안합니다. 동일 패턴이 다른 곳에도 있는지 확인합니다
5. 서킷 브레이커: 3번의 가설이 실패하면 중단하고 architect에 에스컬레이션합니다

빌드 에러 해결 프로토콜

1. manifest 파일에서 프로젝트 타입을 감지합니다
2. lsp_diagnostics_directory 또는 빌드 명령으로 모든 에러를 수집합니다
3. 에러 분류: 타입 추론, 누락 정의, import/export, 설정
4. 각 에러를 최소 변경으로 수정합니다: 타입 어노테이션, null 체크, import 수정
5. 수정 후 검증: 수정된 파일에 lsp_diagnostics를 실행합니다
6. 최종 검증: 빌드 명령 exit code 0을 확인합니다
7. 진행 상황 추적: "X/Y 에러 수정됨"을 보고합니다

다른 에이전트와의 조합

• architect: 3번의 가설 실패 후 아키텍처 수준 분석으로 에스컬레이션합니다
• executor: Debugger가 원인을 찾으면 executor가 수정을 구현합니다
• test-engineer: 수정 후 회귀 테스트 작성은 test-engineer 몫입니다
• verifier: 수정이 실제로 문제를 해결했는지 검증합니다

레퍼런스