2026. 6. 17.
AI가 고친 코드 그대로 써도 될지 불안할 때, diff 검수 프롬프트 6단계
AI가 코드를 고쳤다고 해도 바로 적용하기 불안하다면 바뀐 파일, diff 이유, 테스트 결과, 남은 위험을 한 번에 확인하는 검수 프롬프트가 필요합니다.

AI가 코드를 고쳐 줬는데 그대로 저장해도 되는지 멈칫할 때가 있습니다. 에러는 사라진 것 같지만 다른 파일이 같이 바뀌었는지, 테스트는 실제로 돌렸는지, 화면에서는 같은 문제가 반복되는지 확인하지 않으면 다음 문제가 더 커질 수 있습니다. 이럴 때 필요한 것은 더 긴 질문이 아니라 AI가 만든 변경 사항을 검수하게 만드는 짧은 프롬프트입니다.
developers.openai.com의 Codex CLI 문서는 Codex가 선택한 디렉터리에서 코드를 읽고, 바꾸고, 실행할 수 있는 로컬 코딩 에이전트라고 설명합니다. 같은 문서에는 코드 리뷰, 이미지 입력, 웹 검색, 승인 모드 같은 작업 방식도 함께 안내되어 있습니다. help.openai.com의 프롬프트 작성 가이드는 지시를 앞에 두고, 원하는 출력 형식과 맥락을 구체적으로 적으라고 권합니다. 코딩 검수 프롬프트도 같은 원리로 작성하면 됩니다. 먼저 무엇을 확인할지 지시하고, 그다음 diff와 테스트 결과를 어떤 형식으로 보고할지 정해야 합니다.
고친 코드보다 바뀐 이유를 먼저 확인해야 합니다
초보자가 AI 코딩 결과를 볼 때 가장 놓치기 쉬운 부분은 “문제가 해결됐는가”보다 “왜 이렇게 바뀌었는가”입니다. 버튼이 눌리게 됐다는 결과만 보면 괜찮아 보이지만, 실제 변경이 입력 검증을 건너뛰었거나 상태값을 억지로 고정했을 수도 있습니다. 그래서 첫 검수 질문은 코드 품질 평가가 아니라 변경 이유 확인이어야 합니다.
아래 프롬프트를 AI가 코드를 수정한 직후에 붙여 넣습니다.
방금 만든 코드 변경을 적용하기 전에 검수해 주세요.
1. 바뀐 파일 목록을 먼저 보여 주세요.
2. 각 파일에서 무엇이 바뀌었는지 한 줄로 설명해 주세요.
3. 이 변경이 원래 요청을 어떻게 해결하는지 연결해서 설명해 주세요.
4. 요청과 직접 관련 없는 변경이 있으면 따로 표시해 주세요.
5. 테스트나 빌드를 실행했다면 명령과 결과를 적어 주세요.
6. 아직 확인하지 못한 위험이 있으면 숨기지 말고 적어 주세요.
출력 형식:
- 바뀐 파일:
- 변경 이유:
- 관련 없는 변경:
- 실행한 검증:
- 남은 위험:
- 적용해도 되는지 판단:
이 프롬프트의 핵심은 “적용해도 되는지 판단”을 마지막에 두는 것입니다. 판단을 먼저 물으면 AI가 결론부터 낸 뒤 근거를 맞추려 할 수 있습니다. 파일, 이유, 검증, 위험을 먼저 나누면 결과를 읽는 사람이 확인할 지점이 보입니다.
diff를 설명하게 하면 숨은 변경을 줄일 수 있습니다
AI에게 “괜찮아?”라고 묻는 것보다 “diff를 기준으로 설명해 달라”고 묻는 편이 낫습니다. diff는 변경 전후가 함께 보이는 단서이기 때문에 AI가 막연한 설명만 늘어놓기 어렵습니다. 특히 초보자는 코드 전체를 읽기보다 어느 줄이 왜 바뀌었는지 먼저 봐야 합니다.
아래 기준으로 diff를 검토해 주세요.
검토 기준:
1. 삭제된 줄이 기능을 깨뜨릴 가능성이 있는지
2. 추가된 줄이 원래 요청과 직접 연결되는지
3. 예외 처리나 빈 값 처리가 빠지지 않았는지
4. 기존 함수 이름, 파일 구조, 스타일을 불필요하게 바꾸지 않았는지
5. 테스트가 변경 내용의 핵심 동작을 확인하는지
답변은 표로 작성해 주세요.
열은 "확인 항목 | 발견 내용 | 조치 필요 여부 | 이유"로 맞춰 주세요.
모르는 부분은 추측하지 말고 "확인 필요"라고 적어 주세요.
이 문장을 붙이면 AI가 “수정 완료”라는 말로 끝내기 어렵습니다. 삭제된 줄, 추가된 줄, 예외 처리, 스타일 변경, 테스트 범위를 나누어 봐야 하기 때문입니다. 사람이 모든 코드를 이해하지 못해도 “관련 없는 파일이 바뀌었다”거나 “테스트가 핵심 동작을 못 본다”는 신호는 잡을 수 있습니다.
테스트 결과를 말로 믿지 말고 명령으로 받습니다
AI가 “테스트를 통과했습니다”라고 말했을 때 가장 먼저 볼 것은 실제 명령입니다. npm test, npm run build, pytest, go test ./...처럼 프로젝트에 맞는 명령이 있어야 합니다. 실행하지 못했다면 못한 이유도 결과에 포함되어야 합니다.
검수 프롬프트에는 아래 문장을 넣어 둡니다.
검증 결과를 아래 형식으로 다시 정리해 주세요.
실행한 명령:
결과:
실패했다면 실패한 줄:
성공했다면 무엇을 확인한 성공인지:
실행하지 못한 명령:
실행하지 못한 이유:
수동으로 확인해야 할 화면이나 동작:
이 형식은 AI에게 성공과 미실행을 분리하게 만듭니다. “빌드는 통과했지만 브라우저에서 버튼 클릭은 확인하지 못함”처럼 남은 확인이 보이면 사용자는 그대로 배포하지 않고 다음 행동을 정할 수 있습니다.
초보자에게 필요한 검수 기준은 다섯 가지면 충분합니다
처음부터 보안, 성능, 아키텍처, 테스트 전략을 모두 따지면 검수가 다시 어려워집니다. 코딩 초보자가 AI 수정 결과를 볼 때는 다음 다섯 가지만 먼저 확인해도 실패 확률이 줄어듭니다.
| 검수 기준 | 확인할 질문 |
|---|---|
| 요청 반영 | 내가 부탁한 문제가 실제로 해결됐는가 |
| 변경 범위 | 요청과 상관없는 파일이 바뀌지 않았는가 |
| 기존 동작 | 원래 되던 흐름을 깨뜨릴 가능성은 없는가 |
| 검증 결과 | 테스트나 빌드가 실제로 실행됐는가 |
| 남은 위험 | AI가 확인하지 못한 부분을 표시했는가 |
이 표를 그대로 프롬프트에 넣어도 됩니다.
다음 다섯 기준으로 이번 코드 변경을 검수해 주세요.
1. 요청 반영: 원래 요청이 실제로 해결됐나요?
2. 변경 범위: 요청과 관련 없는 파일이나 동작이 바뀌었나요?
3. 기존 동작: 원래 되던 기능을 깨뜨릴 가능성이 있나요?
4. 검증 결과: 어떤 테스트나 빌드가 실행됐고 결과는 무엇인가요?
5. 남은 위험: 아직 사람이 직접 확인해야 할 부분은 무엇인가요?
각 항목을 "통과 / 확인 필요 / 위험" 중 하나로 표시하고, 이유를 한 문장으로 적어 주세요.
중요한 점은 “위험”이라는 단어를 넣는 것입니다. AI는 문제를 해결했다는 흐름으로 답을 마무리하기 쉽습니다. 남은 위험을 별도 항목으로 만들면 확인하지 않은 부분을 감추지 않고 드러내게 됩니다.
결과가 불안하면 전체를 다시 시키지 말고 위험만 줄입니다
AI 결과가 마음에 들지 않을 때 처음 요청부터 다시 쓰면 같은 실수가 반복됩니다. 이미 만든 변경을 기준으로 위험만 줄이는 후속 프롬프트가 더 빠릅니다. 아래 문장을 사용하면 됩니다.
이번 변경을 처음부터 다시 만들지 말고, 위험한 부분만 줄여 주세요.
조건:
- 원래 요청과 직접 관련 없는 변경은 되돌려 주세요.
- 새 패키지는 추가하지 말아 주세요.
- 기존 파일 구조와 함수 이름은 가능한 유지해 주세요.
- 테스트가 없다면 최소한 어떤 수동 확인이 필요한지 적어 주세요.
- 변경 후 다시 바뀐 파일과 남은 위험을 보고해 주세요.
이 프롬프트는 AI에게 재작성보다 축소를 요구합니다. 코딩 초보자에게는 큰 리팩터링보다 작은 수정이 확인하기 쉽습니다. 적용 전에는 바뀐 파일 수가 줄었는지, 테스트 결과가 새로 붙었는지 다시 봅니다.
오늘 저장해 둘 최종 프롬프트입니다
아래 블록 하나만 저장해 두면 됩니다. AI가 코드를 고친 직후 붙여 넣고, 복사 버튼으로 그대로 가져가면 됩니다.
방금 만든 코드 변경을 적용하기 전에 검수해 주세요.
목표:
내가 요청한 문제가 실제로 해결됐는지 확인하고, 관련 없는 변경과 남은 위험을 분리하고 싶습니다.
검수 기준:
1. 바뀐 파일 목록을 보여 주세요.
2. 각 파일의 변경 이유를 한 줄로 설명해 주세요.
3. 원래 요청과 직접 연결되지 않는 변경을 표시해 주세요.
4. 삭제된 줄이나 추가된 줄이 기존 동작을 깨뜨릴 가능성이 있는지 봐 주세요.
5. 실행한 테스트, 빌드, 린트 명령과 결과를 적어 주세요.
6. 실행하지 못한 검증이 있으면 이유와 수동 확인 방법을 적어 주세요.
출력 형식:
- 바뀐 파일:
- 요청 반영 여부:
- 관련 없는 변경:
- 실행한 검증:
- 실행하지 못한 검증:
- 남은 위험:
- 사람이 직접 확인할 것:
- 적용 판단:
모르는 내용은 추측하지 말고 "확인 필요"라고 적어 주세요.
AI 코딩 결과를 믿을 수 있게 만드는 방법은 더 강한 표현을 쓰는 것이 아니라 확인 순서를 고정하는 것입니다. 바뀐 파일, 변경 이유, 검증 명령, 남은 위험을 매번 같은 형식으로 받으면 초보자도 코드 적용 전 멈춰야 할 지점을 찾을 수 있습니다. 다음에 AI가 코드를 고쳤다고 말하면 저장 버튼을 누르기 전에 이 검수 프롬프트를 먼저 붙여 넣습니다.
참고 출처
다음으로 읽을 기사
같은 흐름으로 이어 읽기 좋은 기사만 추려 보여줍니다.
첫 번째 댓글을 남겨보세요.
여러분의 생각이 다른 독자에게 도움이 됩니다.
댓글 0
이 글을 읽은 독자들의 생각을 나눠보세요.