AI 코딩 검수 프롬프트, 배포 전 확인하는 6줄 체크리스트

AI에게 코딩을 맡기면 가장 불안한 순간은 코드가 나온 뒤입니다. 화면은 그럴듯해 보이는데 실제로 테스트를 통과했는지, 엉뚱한 파일이 바뀌었는지, 배포하면 깨질 부분이 남았는지 알기 어렵습니다. 코딩사관학교 초보자에게 필요한 것은 “한 번 더 잘 만들어줘”가 아니라 결과물을 검수하게 만드는 짧은 요청문입니다.

developers.openai.com의 Codex CLI 문서는 Codex가 선택한 디렉터리 안에서 코드를 읽고, 바꾸고, 실행할 수 있는 로컬 코딩 에이전트라고 설명합니다. 같은 도메인의 프롬프트 엔지니어링 문서도 코드 작업에서는 도구 사용 지침과 테스트, 검증 기대치를 분명히 쓰라고 안내합니다. 그래서 AI 코딩 요청은 “만들어 줘”에서 끝나면 안 됩니다. 결과를 받은 뒤에는 “무엇을 바꿨고, 무엇으로 확인했고, 무엇이 아직 위험한지”를 다시 물어야 합니다.

바로 붙여 넣을 6줄 검수 프롬프트

아래 요청문은 AI가 코드를 만든 직후에 붙여 넣습니다. 핵심은 새 기능을 더 시키는 것이 아니라, 이미 한 작업을 증거 중심으로 정리하게 만드는 데 있습니다.

방금 만든 코드를 배포 전 기준으로 검수해 주세요.

변경 파일: 실제로 수정한 파일과 각 파일의 역할을 표로 정리해 주세요.
핵심 동작: 사용자가 어떤 행동을 하면 어떤 결과가 나와야 하는지 3줄로 적어 주세요.
실행 명령: 가능한 lint, test, build 명령을 찾고 실행한 결과를 적어 주세요.
화면 확인: 직접 확인해야 할 정상 상태와 실패 상태를 나눠 주세요.
남은 위험: 확인하지 못한 부분, 추측한 부분, 사용자가 봐야 할 부분을 분리해 주세요.
다음 요청문: 실패가 있으면 그대로 다시 붙여 넣을 수정 프롬프트를 작성해 주세요.

이 프롬프트는 AI를 의심하기 위한 문장이 아닙니다. 초보자가 결과물을 판단할 수 있게 만드는 최소 보고서입니다. 코드가 좋아 보여도 실행 명령이 비어 있거나 남은 위험이 “없음”으로만 끝난다면 아직 확인할 것이 남았을 수 있습니다.

변경 파일을 먼저 보면 범위가 보입니다

AI가 만든 결과에서 가장 먼저 볼 것은 코드 자체가 아니라 파일 목록입니다. 작은 버튼 수정이라고 요청했는데 설정 파일, 라우팅 파일, 스타일 전체가 바뀌었다면 결과가 맞더라도 검토 부담이 커집니다. 반대로 필요한 파일이 전혀 바뀌지 않았다면 설명만 하고 실제 수정을 놓쳤을 수 있습니다.

보고 항목	초보자가 볼 것	다시 물을 문장
수정 파일 수	요청보다 범위가 넓어졌는가	왜 이 파일이 필요했는지 한 줄씩 설명해 주세요.
새 파일	기존 파일 수정으로 충분했는가	새 파일 없이 해결하는 대안이 있는지 알려 주세요.
설정 변경	배포나 실행 방식이 바뀌었는가	설정 변경의 영향과 되돌리는 방법을 적어 주세요.
의존성 변경	새 패키지가 들어갔는가	새 패키지 없이 가능한 방법을 먼저 제시해 주세요.

파일 목록은 코드를 몰라도 확인할 수 있습니다. “회원가입 버튼”을 고쳤는데 데이터베이스 설정이 바뀌었다면 이유를 물어야 합니다. AI가 합리적인 이유를 설명할 수도 있지만, 설명 없이 범위가 커지는 작업은 다음 오류를 만들기 쉽습니다.

실행 명령은 성공과 실패를 같이 받아야 합니다

AI에게 검증을 맡길 때는 성공한 명령만 받으면 부족합니다. 실패한 명령, 실행하지 못한 명령, 수동으로 확인해야 할 상태를 같이 받아야 합니다. 프로젝트마다 명령은 다르지만, AI에게 먼저 찾게 할 수 있습니다.

package.json이나 프로젝트 문서를 확인해서 가능한 검증 명령을 찾아 주세요.
실행한 명령은 성공/실패로 나누고, 실패한 경우 마지막 오류 줄과 다음 수정 방향을 적어 주세요.
실행하지 못한 명령은 "왜 못 했는지"와 "대신 무엇을 확인했는지"를 분리해 주세요.

이 요청을 넣으면 “완료했습니다”라는 한 줄 보고를 줄일 수 있습니다. 초보자는 테스트 이름을 몰라도 됩니다. 대신 AI에게 명령을 찾게 하고, 실행 결과를 표로 받으면 됩니다.

AI 코딩 결과를 변경 파일, 실행 명령, 화면 확인, 실패 수정으로 나누는 흐름

화면 확인은 정상 상태와 실패 상태를 나눕니다

코딩 결과는 빌드가 통과해도 화면에서 실패할 수 있습니다. 버튼이 눌리지만 잘못된 입력에서도 넘어가거나, 모바일에서 글자가 밀리거나, 오류 메시지가 보이지 않는 식입니다. 그래서 화면 확인은 정상 상태 하나만 보면 안 됩니다.

기능 종류	정상 상태	실패 상태
로그인	올바른 이메일과 비밀번호로 이동한다	빈 값, 틀린 비밀번호, 잘못된 이메일에서 메시지가 보인다
검색	키워드와 맞는 결과만 보인다	결과가 없을 때 빈 화면 설명이 보인다
저장 버튼	입력 후 저장 성공 문구가 보인다	필수값이 비면 버튼이 막히거나 안내가 보인다
목록 필터	선택한 조건만 남는다	조건을 해제하면 전체 목록이 다시 보인다

AI에게 아래처럼 요청하면 화면 확인 항목이 더 구체적으로 나옵니다.

브라우저에서 확인해야 할 상태를 표로 만들어 주세요.
각 행은 "상황, 입력값, 기대 화면, 실패하면 다시 요청할 문장"으로 나눠 주세요.
정상 상태만 쓰지 말고 빈 값, 잘못된 값, 모바일 화면에서 확인할 항목도 포함해 주세요.

초보자에게 중요한 것은 모든 테스트를 직접 짜는 일이 아닙니다. 적어도 어떤 상태를 눌러 봐야 하는지 아는 것입니다. 이 표가 있으면 AI가 만든 결과를 눈으로 확인할 수 있습니다.

남은 위험을 없애라고 하지 말고 분리해 달라고 합니다

AI에게 “위험 없게 해 줘”라고 쓰면 답이 넓어집니다. 더 나은 요청은 위험을 세 칸으로 나누게 하는 것입니다. 확인한 것, 확인하지 못한 것, 사용자가 직접 봐야 할 것을 분리하면 다음 행동이 보입니다.

남은 위험을 아래 세 칸으로 나눠 주세요.

확인 완료: 명령이나 화면으로 직접 확인한 것
미확인: 시간이 없거나 환경이 없어 확인하지 못한 것
사용자 확인: 실제 계정, 실제 데이터, 배포 환경에서만 확인 가능한 것

이 방식은 특히 배포 전 수정에서 효과가 있습니다. 로컬에서는 통과했지만 실제 결제 계정, 실제 이메일, 실제 배포 URL이 필요한 확인은 AI가 마음대로 단정하면 안 됩니다. “미확인”이라고 적히는 항목은 실패가 아니라 다음 확인 목록입니다.

결과가 불안하면 이 수정문으로 다시 좁힙니다

검수 보고서를 받은 뒤 문제가 보이면 전체 요청을 새로 쓰지 않습니다. 아래 문장 중 상황에 맞는 것만 붙입니다.

증상	다시 붙여 넣을 수정문
검증 명령을 안 돌림	완료 보고 전에 가능한 lint, test, build 명령을 다시 확인하고 실행해 주세요. 실행하지 못한 명령은 이유를 적어 주세요.
파일을 너무 많이 바꿈	이번 목표와 직접 관련 없는 변경은 목록으로 분리하고, 필요한 최소 파일만 수정하는 방향으로 다시 제안해 주세요.
화면 확인이 없음	정상 입력, 빈 값, 잘못된 값, 모바일 화면에서 확인할 항목을 표로 만들어 주세요.
새 패키지를 추가함	새 패키지 없이 해결하는 대안을 먼저 제시해 주세요. 꼭 필요하다면 이유와 영향 범위를 설명해 주세요.
실패 로그가 길다	실패 로그에서 원인으로 보이는 마지막 핵심 줄 3개만 뽑고, 다음 수정 순서를 제안해 주세요.

수정 요청은 짧을수록 좋습니다. “다시 제대로 해 줘”보다 “검증 명령을 실행하고 실패 로그 핵심 줄을 적어 주세요”가 AI에게 훨씬 분명합니다.

오늘은 코드보다 보고 형식을 먼저 고정합니다

아래 이미지를 저장해 두고, AI가 코드를 만든 뒤 6줄을 그대로 확인하면 됩니다.

변경 파일:
핵심 동작:
실행 명령:
화면 확인:
남은 위험:
다음 요청문:

AI 코딩을 잘 쓰는 사람은 첫 결과를 바로 믿지 않습니다. 바뀐 파일, 실행한 명령, 화면 상태, 남은 위험을 보고 다음 행동을 결정합니다. 오늘 AI에게 코딩을 맡겼다면 결과가 나온 직후 이 6줄 검수 프롬프트를 붙여 넣으세요. 코드 지식이 부족해도 어디를 확인해야 하는지 보입니다.

AI가 만든 코드 믿어도 될까? 배포 전 확인하는 6줄 검수 프롬프트