AI가 바꾼 코드를 받아들이기 전에 검토하는 방법
Mono Code에서 변경 범위, 파일 차이, 스테이징된 내용, 테스트 증거와 남은 문제를 검토하는 템플릿과 읽기 전용 Git 명령을 소개합니다.
에이전트의 요약만 보지 말고 저장소에 실제로 있는 코드를 검토하세요. 설득력 있는 설명에도 불완전한 수정, 실행하지 않은 테스트, 무관한 편집이 함께 있을 수 있습니다. 결과를 받아들이기 전에 요구한 동작, 실제 변경, 검증 증거를 구분하세요.
Mono Code에서는 프로젝트 파일을 열고, 코딩 에이전트와 작업하고, 편집기 안에서 바로 Git 변경 사항을 볼 수 있습니다. 이 글은 끝난 작은 변경을 검토하는 방법을 다룹니다. 연결 방법은 원격 코딩 가이드를 확인하세요. 저장소와 명령은 언제나 여러분의 컴퓨터, 즉 호스트에 있습니다. Mono는 아직 출시 전이지만 대기 명단에 등록할 수 있습니다.
1. 수락 조건을 다시 적으세요
가상의 작업 양식이 공백만 있는 제목을 허용한다고 해 봅시다. 요구한 수정은 일반 제목은 유지하면서 이런 입력을 거부하는 것입니다. 패치를 보기 전에 반드시 성립해야 할 조건을 적으세요.
- 빈 제목과 공백만 있는 제목은 제출할 수 없어야 합니다.
- 일반 제목은 여전히 정상적으로 제출돼야 합니다.
- 사용자에게 유용한 검증 메시지가 보여야 합니다.
- 양식의 다른 동작은 합의한 범위 안에 있어야 합니다.
이 짧은 목록을 diff 옆에 두세요. 에이전트가 제시하는 설명에 동의하는 대신, 요구 사항으로 평가할 근거가 됩니다. 처음 요청이 모호했다면 더 넓은 구현을 받아들이기 전에 동작부터 명확히 하세요.
2. 저장소 상태를 확인하세요
호스트, 프로젝트 폴더, 브랜치를 확인하세요. 변경 파일 목록을 에이전트 작업 전에 기록한 시작 상태와 비교합니다. 같은 파일에 있다는 이유로 사용자의 기존 편집이 에이전트 작업으로 바뀌지는 않습니다.
의도한 호스트의 터미널에서 다음 읽기 전용 명령을 활용할 수 있습니다.
git status --short
git diff --stat
git diff -- path/to/file
git diff --cached -- path/to/file예시 경로는 실제 경로로 바꾸세요. 일반 git diff는 스테이징하지 않은 변경을 보여 주고, --cached는 스테이징된 내용을 커밋과 비교합니다. 추적하지 않는 파일은 별도 확인이 필요합니다. Git diff 문서가 이러한 비교를 설명합니다. 작업 트리가 깨끗해도 에이전트가 이미 커밋했는지는 알 수 없으므로, 그랬다면 관련 기록을 확인하세요.
3. 패치와 주변 코드를 읽으세요
Mono 편집기에서는 줄 옆 여백에 추가되거나 수정된 줄이 표시되고, 표시를 누르면 그 부분의 diff가 열립니다. 변경 하나를 보기에 편리한 방법일 뿐, 모든 변경을 검토했다는 증거는 아닙니다. 표시가 없거나 오래됐다고 해서 파일이 그대로라는 뜻은 아닙니다.
제목 예시에서는 검증 조건을 찾고 이후 흐름을 따라가세요. 정규화한 값을 확인하나요? 오류가 보이나요? 제출 경로가 멈추나요? 추가된 조건 한 줄만 보지 말고 호출하는 코드와 주변 흐름까지 확인하세요.
새 파일, 삭제된 코드, 의존성 변경, 무관한 서식 수정도 살펴보세요. 짧은 설명만으로 설명되지 않은 큰 diff를 정당화할 수 없습니다. 줄이 잘리거나 변경 폭이 너무 넓다면 호스트나 큰 화면으로 옮겨 정확히 읽으세요.
4. 테스트를 동작과 연결하세요
실제로 실행한 명령, 그 결과, 건너뛴 검사를 요청하세요. “테스트가 통과할 것입니다”는 예측이지 기록된 결과가 아닙니다. 전체 테스트가 통과해도 보고된 오류를 다루는 관련 사례가 필요합니다.
| 사례 | 기대하는 관찰 |
|---|---|
| 빈 제목 | 의도한 안내와 함께 제출 중단 |
| 공백만 입력 | 항목을 만들지 않고 동일하게 거부 |
| 일반 제목 | 제출이 계속 정상 작동 |
| 변경과 무관한 기존 동작 | 관련 기존 검사가 계속 통과 |
화면 안내는 수동 확인이 적절할 수 있고, 검증 규칙은 자동 회귀 테스트로 보호할 수 있습니다. 구현을 그대로 반복하는 테스트보다 변경된 동작을 보여 주는 증거를 선택하세요. 환경 때문에 테스트할 수 없다면 제한을 명시하고 어디서 보완할지 정하세요.
5. 다른 작업을 보존하면서 문제를 해결하세요
“공백 제목은 거부하지만 오류 문구가 표시되지 않는다” 또는 “이 검증 수정에 의존성 파일 변경이 필요한 이유를 설명해 달라”처럼 구체적으로 피드백하세요. 단순히 “다시 해”라고 하기보다 동작과 파일을 지목하세요.
다른 작업이 함께 있을 때 작은 불필요한 변경을 없애려고 전체 초기화나 복원 명령을 사용하지 마세요. 특정 부분의 수정을 요청하고 새 diff를 확인하세요. 수정 후에는 영향받는 검사를 다시 실행해야 합니다. 이전 성공은 나중 편집을 검증하지 않습니다.
명령 권한과 코드 수락은 별개의 결정입니다. 테스트 명령 승인이 커밋, 병합, 배포 승인까지 의미하지 않습니다. 작업 자체의 판단에는 권한 검토 가이드를 참고하세요.
6. 검토 가능한 인수인계 기록을 남기세요
짧은 메모로 결론을 기록하세요.
요구한 동작: 공백 작업 제목 거부.
검토한 파일: 실제 경로 목록.
증거: 명령, 결과, 관련 수동 확인.
열린 질문: 아직 검증하지 못한 내용.
다음 결정: 변경 수락, 수정 요청 또는 보류.커밋과 릴리스 동작은 명시적으로 결정하세요. 대화가 필요하면 Markdown으로 내보낼 수 있지만, 실제 프로젝트 파일도 보관하세요. 대화록은 논의를 기록하고, 저장소와 확인된 검사는 무엇이 달라졌는지 입증합니다.
