초보자가 AI 코드 저장 전 보는 3분 검토 7가지

AI 코딩 도구가 화면을 고쳐 준 것처럼 보여도 바로 저장하거나 커밋하면 안 되는 순간이 있습니다. 버튼 색 하나를 고쳐 달라고 했는데 설정 파일이 바뀌고, 오류 한 줄을 고쳐 달라고 했는데 새 패키지가 추가되는 경우입니다. 초보자에게 필요한 것은 긴 코드 리뷰가 아니라 저장 전 3분 동안 변경 범위를 확인하는 루틴입니다.

Tap to zoom

이 루틴의 목적은 AI를 의심하는 것이 아닙니다. 내가 요청한 문제를 해결한 변경과, 지금 저장하면 다음 오류가 될 변경을 나누는 것입니다. developers.openai.com의 OpenAI 프롬프트 엔지니어링 가이드는 원하는 결과를 얻으려면 지시와 출력 형태를 명확히 해야 한다고 설명합니다. AI 코딩에서도 같은 원리가 적용됩니다. 저장 전에 변경 범위를 말로 정리할수록 다음 지시가 짧아집니다.

첫 30초에는 바뀐 파일 수부터 봅니다

처음 볼 것은 코드 내용이 아니라 파일 목록입니다. git-scm.com의 Git 공식 문서에서 git status는 작업 트리와 스테이징 영역의 상태를 보여 주는 명령입니다. 초보자는 먼저 아래 명령으로 AI가 손댄 범위를 봅니다.

git status --short
git diff --name-only

파일이 하나나 두 개라면 아직 판단하기 쉽습니다. 그런데 간단한 UI 수정 요청 후 package.json, 설정 파일, 라우트 파일, 여러 컴포넌트가 동시에 바뀌었다면 저장 전에 멈춰야 합니다. 이때는 코드가 맞는지보다 "내 요청보다 넓게 바뀌었는지"가 먼저입니다.

30초 안에 아래 네 칸을 채웁니다.

원래 요청:
바뀐 파일 수:
내가 예상한 파일:
예상 밖 파일:

예상 밖 파일이 있으면 바로 커밋하지 않습니다. AI에게 "이 파일도 왜 바뀌었는지 설명해 달라"고 먼저 묻는 편이 안전합니다.

다음 1분에는 diff에서 세 줄만 읽습니다

git-scm.com의 git diff 문서는 이 명령이 작업 트리, 인덱스, 커밋, 파일 사이의 변경 내용을 보여 준다고 설명합니다. 초보자가 모든 줄을 완벽히 읽을 필요는 없습니다. 저장 전에는 세 가지만 보면 됩니다.

git diff --stat
git diff

첫째, 삭제 줄이 너무 많은지 봅니다. 둘째, 요청하지 않은 새 import나 새 패키지 이름이 들어왔는지 봅니다. 셋째, 환경변수나 인증 관련 이름이 바뀌었는지 봅니다. 이 셋 중 하나가 보이면 "작동하는 것 같다"는 느낌만으로 저장하지 않습니다.

예를 들어 로그인 버튼 문구를 고쳐 달라고 했는데 인증 로직 파일이 바뀌었다면 다시 질문해야 합니다.

방금 변경에서 내 원래 요청과 직접 관련 없는 부분을 골라 주세요.
파일별로 유지 후보와 되돌림 후보를 나누고,
새 코드는 아직 쓰지 말고 이유만 말해 주세요.

이 프롬프트는 AI에게 추가 수정을 시키는 문장이 아닙니다. 변경을 분류하게 만드는 문장입니다. 초보자는 여기서 통제권을 되찾습니다.

Tap to zoom

2분째에는 요구사항과 맞는지 7가지를 체크합니다

저장 전 체크리스트는 길면 쓰지 않게 됩니다. 아래 7가지만 봅니다.

이 표에서 두 개 이상 막히면 저장을 늦춥니다. 특히 새 패키지와 환경변수 변경은 초보자가 그냥 받아들이기 쉽지만, 배포 실패나 보안 노출로 이어질 수 있습니다. 이 글은 보안 감사를 대신하지 않습니다. 다만 저장 전 의심해야 할 지점을 보이게 합니다.

3분째에는 같은 명령을 다시 실행합니다

코드가 눈으로 맞아 보여도 실행 확인이 빠지면 검토가 끝난 것이 아닙니다. 처음 실패했던 명령이나, 화면을 확인한 명령을 다시 실행합니다.

npm run build
npm run typecheck
npm run test

프로젝트마다 스크립트 이름은 다릅니다. 먼저 package.json의 scripts를 보고 실제 있는 명령만 씁니다. 명령이 없다면 개발 서버를 켜고 바뀐 화면을 다시 봅니다. docs.github.com의 GitHub Docs도 풀 리퀘스트 리뷰에서 커밋, 변경 파일, diff를 함께 검토한다고 설명합니다. 혼자 작업할 때도 같은 순서로 보면 됩니다. 파일 목록, diff, 실행 결과가 한 세트입니다.

실행 결과를 AI에게 다시 줄 때는 아래처럼 짧게 씁니다.

저장 전 검토 결과입니다.

원래 요청:
[한 문장]

바뀐 파일:
[git diff --name-only 결과]

다시 실행한 명령:
[명령어]

결과:
[통과 또는 새 오류]

요청:
저장해도 되는 변경과 보류할 변경을 나눠 주세요.
보류할 변경은 파일명, 이유, 확인 명령만 알려 주세요.

이렇게 물으면 AI가 곧장 새 코드를 만들기보다 현재 변경을 판단하게 됩니다.

저장해도 되는 상태는 한 문장으로 설명됩니다

초보자가 저장 전에 마지막으로 볼 기준은 단순합니다. "무엇을 고치기 위해 어떤 파일이 바뀌었고, 어떤 명령으로 확인했다"를 한 문장으로 말할 수 있어야 합니다.

예시는 이렇습니다.

로그인 버튼 문구를 바꾸기 위해 app/login/page.tsx만 수정했고,
npm run build로 확인했습니다.

반대로 아래처럼 말이 길어지면 아직 저장하지 않는 편이 낫습니다.

버튼을 고치다가 설정도 바뀌고 패키지도 추가됐는데,
왜 그런지는 잘 모르겠지만 화면은 일단 뜹니다.

AI 코딩은 빠르게 만드는 도구지만, 저장 버튼을 누르는 사람은 여전히 사용자입니다. 오늘 남길 결과물은 완벽한 코드 리뷰가 아닙니다. 아래 7줄을 채운 뒤 저장하는 습관입니다.

원래 요청:
바뀐 파일:
예상 밖 파일:
큰 삭제:
새 패키지:
다시 실행한 명령:
저장 판단:

이 7줄을 채우면 AI가 만든 코드를 그냥 믿는 상태에서, 내가 검토하고 다음 지시를 고르는 상태로 이동합니다.

참고 출처

• Git status 공식 문서: https://git-scm.com/docs/git-status
• Git diff 공식 문서: https://git-scm.com/docs/git-diff
• GitHub Docs, pull request 변경 검토: https://docs.github.com/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests
• OpenAI Prompt engineering guide: https://developers.openai.com/api/docs/guides/prompt-engineering