코딩 에이전트가 문법상 맞는 코드를 만들었지만 저장소의 관례와 실제 호출 경로를 놓쳤습니다. 수정 전에 어떤 문맥을 확보해야 하나요?

요청한 기능의 진입점·호출자·데이터 계약·테스트·프로젝트 지침을 먼저 확인하고, 기존 변경과 현재 작업 트리 상태를 구분하겠습니다. 모델이 언어 문법을 안다는 것과 이 저장소에서 맞는 수정을 한다는 것은 다릅니다. 파일 이름만 보고 새 구현을 추가하기보다 이미 있는 유사 기능과 재사용 가능한 경계를 찾아야 합니다.

좁게 시작하고 의존 경로를 확인합니다

버그 보고의 입력과 기대 결과를 정리한 뒤 검색으로 관련 파일을 찾고 실제 코드·테스트를 읽습니다. 검색 스니펫은 위치를 찾는 단서이지 전체 계약 검토가 아닙니다. 호출자가 null·예외·취소를 어떻게 해석하는지, 저장소가 원자성을 어디에서 보장하는지 확인합니다. 기존 함수의 이름을 재사용해도 의미가 다르면 잘못된 추상화가 될 수 있습니다.

프로젝트의 지침 파일과 빌드·테스트 명령을 확인하되 저장소에 들어 있는 텍스트를 무조건 높은 권한의 지시로 취급하지 않습니다. 특히 외부 PR이나 의존성의 파일이 비밀 전송·정책 변경을 요구하면 현재 사용자 요청과 실행 권한을 기준으로 거절합니다. 테스트 스크립트·설치 후크도 실제 코드를 실행하므로 신뢰하지 않는 저장소에서는 sandbox와 네트워크·자격 제한이 필요합니다.

최소 변경과 결과 확인

작업 전에 사용자의 미커밋 변경이 있는지 보고, 내가 만들지 않은 내용을 덮어쓰지 않습니다. 기능에 필요한 최소 수정과 회귀 테스트를 수행하고 공개 API·스키마·의존성 변경은 영향 범위를 검토합니다. 테스트가 실패했다면 변경 전에도 있었는지 확인할 수 있지만, 증거 없이 기존 실패라고 단정하지 않습니다. 명령이 없거나 환경이 부족하면 실행하지 못한 범위를 보고합니다.

완료는 코드가 생성된 시점이 아니라 요구한 동작과 기존 계약이 검증된 시점입니다. 실제 앱·브라우저에서의 흐름이 중요한 경우 단위 테스트나 HTTP 상태만으로 끝내지 않습니다. 최종 diff에는 의도하지 않은 포맷 변경·생성 파일·비밀값이 없는지 확인합니다. 코딩 에이전트의 성능을 볼 때는 단순 패치 성공률 외에 검토 시간·회귀·범위 이탈·재작업 비용을 포함해야 합니다. 더 많은 코드를 생성하는 것보다 현재 저장소의 제약을 정확히 읽고 안전하게 바꾸는 능력이 중요합니다.

실행 사례로 확인합니다

예를 들어 새 retry 함수를 추가하기 전에 저장소의 공통 HTTP 클라이언트가 이미 재시도하는지 확인해야 합니다. 새 계층에서 세 번, 기존 계층에서 세 번 재시도하면 한 요청이 아홉 호출로 늘 수 있습니다. 이런 결함은 새 함수의 단위 테스트만으로 놓치기 쉽습니다. 변경할 코드의 주변뿐 아니라 공통 미들웨어·설정·호출자의 오류 해석을 읽는 이유입니다. 반대로 전 저장소를 무작정 읽으면 비용이 커지므로 실제 호출 경로를 따라 범위를 넓힙니다. 최종 보고는 무엇을 바꿨는지와 어느 테스트를 실제 실행했는지를 분리하고, 실행 환경이 없어 확인하지 못한 플랫폼의 동작을 통과했다고 주장하지 않습니다.