AI에게 큰 저장소의 오류를 설명하면 관련 있어 보이는 파일을 많이 제안했다. 그중 일부는 실제 실행 경로가 아니거나 오래전에 남은 코드였다. 현재 코드만 줘도 왜 이런 구조가 됐는지는 알기 어려웠다. 질문 전에 Git 이력을 보면 탐색 범위를 훨씬 현실적으로 만들 수 있었다.
AI를 더 똑똑하게 만드는 방법이라기보다 입력할 증거를 고르는 과정이었다.
증상과 가까운 변경부터 확인했다
재현되기 시작한 시점과 관련 경로의 최근 변경을 비교했다.
git log --oneline --decorate -- path/to/example
git show --stat <example-commit>
git diff <known-good>..<current> -- path/to/example
커밋이 원인이라고 바로 단정하지 않고 변경된 계약과 함께 움직인 파일을 찾는 단서로 사용했다.
AI에는 필요한 diff만 전달했다
저장소 전체를 던지지 않고 재현 조건, 관련 diff, 호출하는 인터페이스, 기대 결과를 작은 묶음으로 만들었다. 회사명, 내부 URL, 계정, 토큰, 실제 고객 데이터는 제거하고 구조가 유지되는 예시로 바꿨다.
이 diff에서 바뀐 입력·출력 계약을 표로 만들고,
호출자가 함께 바뀌지 않은 경우의 실패를 찾아줘.
범위 밖 추측은 별도로 표시해줘.
답이 어떤 코드 줄과 증거에서 나온 것인지 요구했다.
큰 diff는 파일 역할별로 나눠 순서대로 보되 공통 모델과 계약 파일은 별도 위험 지점으로 표시했다. 서로 독립적인 변경만 병렬로 분석하고 같은 파일을 여러 흐름이 동시에 해석할 때는 결론을 다시 합쳤다.
영향 범위는 참조와 테스트로 다시 확인했다
AI가 관련 파일을 제안하면 실제 참조 검색, 빌드 대상, 플랫폼 조건을 확인했다. Git diff에 없는 생성 파일이나 설정 변경이 필요한지도 봤다. 제안된 수정 후에는 원래 증상과 반대 조건, 기존 기능을 직접 검증했다.
Git 이력은 현재 코드의 진실을 대신하지 않았다. 오래된 커밋 메시지가 부정확할 수 있어 현재 실행 경로가 최종 기준이었다.
AI 사용에도 조사 순서가 생겼다
예전에는 질문을 먼저 하고 답에 맞춰 파일을 찾았다. 이제는 증상, 현재 코드, Git 변화, 반대 가설을 작은 증거 묶음으로 만든 뒤 AI를 사용한다. 그 결과 답이 틀려도 어디서 벗어났는지 빨리 알 수 있었다.
AI가 분석 시간을 줄여 주는 건 맞지만 범위를 정하고 사실을 확인하는 책임은 남았다. Git부터 본 이유는 과거를 믿기 위해서가 아니라 질문이 현재 변경과 실제 코드에 닿게 하기 위해서였다.