AI 코딩 수정이 더 망가질 때, 3분 만에 되돌리는 5줄 프롬프트

AI에게 “고쳐줘”라고 했더니 오류 하나는 사라졌는데 화면이 더 깨지거나, 파일이 여러 개 바뀌고, 원래 어디가 문제였는지 흐려지는 순간이 있습니다. 이때 초보자가 가장 많이 하는 실수는 바로 한 번 더 “다시 고쳐줘”라고 묻는 것입니다. 그러면 AI는 방금 만든 수정안을 기준으로 또 추측하고, 작은 오류가 구조 변경으로 커질 수 있습니다.

필요한 것은 큰 Git 강의가 아닙니다. 먼저 3분 동안 수정 루프를 멈추고, 바뀐 파일을 보고, 되돌릴 파일을 하나만 고르는 루틴입니다. developers.openai.com의 OpenAI 프롬프트 엔지니어링 문서는 원하는 결과를 얻기 위해 목표와 지시를 명확히 적는 방식을 강조합니다. AI 코딩에서도 같은 원리가 적용됩니다. “다시 고쳐줘”보다 “무엇을 되돌리고, 무엇은 유지할지”를 먼저 정해야 합니다.

1분째에는 새 수정 요청을 멈추고 diff부터 봅니다

AI 코딩 도구는 코드를 읽고 바꾸고 실행할 수 있습니다. github.com/openai/codex의 OpenAI Codex README도 Codex CLI를 로컬 컴퓨터에서 실행되는 코딩 에이전트로 설명합니다. 그래서 편리하지만, 초보자에게는 AI가 바꾼 범위가 보이지 않으면 위험합니다. 다음 질문을 하기 전에 먼저 바뀐 파일 목록을 봅니다.

git diff --stat
git diff --name-only

git-scm.com의 git diff 문서 기준으로 git diff는 현재 작업 트리의 차이를 비교할 때 쓰는 Git 명령입니다. 여기서 파일이 한두 개면 아직 통제 가능한 상태입니다. 그런데 오류 하나를 고치려 했는데 package.json, 설정 파일, 페이지 파일, 컴포넌트 파일이 한꺼번에 바뀌었다면 바로 다음 수정 요청을 하지 않습니다.

초보자 기준으로 먼저 볼 것은 세 가지입니다.

원래 오류에 나온 파일이 실제로 바뀌었는지 봅니다.
새 파일이나 새 패키지가 생겼는지 봅니다.
화면과 관련 없는 설정 파일이 같이 바뀌었는지 봅니다.

이 단계의 목적은 잘잘못을 따지는 것이 아닙니다. 지금 AI가 문제를 작게 고쳤는지, 아니면 작업 범위를 넓혔는지 확인하는 것입니다.

2분째에는 한 파일만 되돌릴지 고릅니다

바뀐 파일 목록을 봤다면 바로 전체를 지우지 않습니다. git-scm.com의 git restore 문서 기준으로 git restore는 작업 트리의 경로를 특정 기준 상태에서 복원하는 명령입니다. 초보자에게는 “전체 되돌리기”보다 “한 파일 되돌리기”가 안전합니다.

예를 들어 원래 오류는 app/page.tsx였는데 AI가 next.config.js까지 바꿨다면, 먼저 설정 파일을 되돌릴 수 있습니다.

git restore next.config.js

이미 스테이지에 올린 파일이라면 다음처럼 스테이지에서 먼저 내릴 수 있습니다.

git restore --staged next.config.js

반대로 git reset --hard는 조심해야 합니다. git-scm.com의 git reset 문서에서 --hard는 작업 트리 파일을 덮어쓸 수 있는 모드로 설명됩니다. 초보자가 이 명령을 복사해서 쓰면 방금 저장한 코드까지 한 번에 사라질 수 있습니다. 그러니 처음 3분 루틴에서는 전체 초기화가 아니라 파일 단위 복원을 우선합니다.

3분째에는 재실행 결과를 붙여 AI에게 다시 묻습니다

되돌릴 파일을 고른 뒤에는 같은 명령을 다시 실행합니다.

npm run build

또는 처음 실패했던 명령을 그대로 다시 실행합니다. 결과가 좋아졌는지, 같은 오류인지, 다른 오류로 바뀌었는지를 기록해야 합니다. 이 기록이 있어야 AI가 방금 수정의 어떤 가정이 틀렸는지 볼 수 있습니다.

이때 붙여 넣을 프롬프트는 길 필요가 없습니다.

AI 수정 후 프로젝트가 더 망가졌습니다.

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

되돌린 파일:
[git restore로 되돌린 파일명]

다시 실행한 명령과 결과:
[명령어와 새 오류]

요청:
새 코드를 만들지 말고, 방금 diff 기준으로 원래 문제와 무관한 변경을 먼저 골라 주세요.
유지할 변경 1개, 되돌릴 변경 1개, 다시 확인할 명령 1개만 알려 주세요.

이 5줄 프롬프트는 AI에게 “더 많이 고쳐라”가 아니라 “변경을 분류하라”고 시킵니다. 초보자에게 필요한 것은 다음 대규모 수정이 아니라 작업 범위를 다시 줄이는 일입니다.

되돌리면 안 되는 파일도 먼저 표시합니다

모든 변경이 나쁜 것은 아닙니다. AI가 실제 오류 파일을 잘 고쳤는데, 옆의 설정 파일만 불필요하게 바꿨을 수도 있습니다. 그래서 되돌리기 전에 “유지 후보”와 “되돌림 후보”를 나눕니다.

아래처럼 적으면 판단이 쉬워집니다.

유지 후보:
- 오류 메시지에 나온 파일
- 내가 요청한 기능과 직접 연결된 컴포넌트
- 테스트나 빌드를 통과시키기 위한 작은 수정

되돌림 후보:
- 요청하지 않은 새 패키지
- 이유 없이 바뀐 설정 파일
- 원래 문제와 관계없는 스타일 전체 변경
- 새 폴더 구조나 대량 이동

AI에게도 같은 기준을 줍니다.

아래 diff를 보고 유지 후보와 되돌림 후보를 나눠 주세요.
기준은 원래 오류 해결과 직접 관련이 있는지입니다.
되돌림 후보는 파일명과 이유만 말하고, 아직 새 수정 코드는 쓰지 마세요.

이 요청은 코드를 못 믿겠다는 말이 아닙니다. 코딩 도구를 안전하게 쓰기 위한 브레이크입니다. AI가 만든 결과물을 검토 대상으로 바꾸면, 초보자도 “그냥 붙여 넣기”에서 벗어날 수 있습니다.

저장 전에는 네 가지만 확인합니다

AI 수정이 더 망가졌던 경험이 있다면 저장 전 체크를 짧게 고정해야 합니다.

git diff --name-only에 낯선 파일이 있는지 봅니다.
원래 오류와 관련 없는 설정 변경이 있는지 봅니다.
새 패키지 설치가 필요한지 봅니다.
같은 명령을 다시 실행했을 때 오류가 줄었는지 봅니다.

이 네 가지를 확인하지 못했다면 다음 수정 요청을 넣지 않습니다. 특히 초보자에게는 코드가 많아지는 것보다 “되돌릴 수 있는 상태”를 유지하는 것이 더 중요합니다.

오늘 남길 결과물은 되돌림 프롬프트 하나입니다

지금 AI가 만든 코드가 더 망가졌다면, 먼저 아래 네 줄만 채웁니다.

바뀐 파일:
유지할 파일:
되돌릴 파일:
다시 실행할 명령:

그 다음 5줄 프롬프트를 붙이면 됩니다. 오늘의 목표는 모든 Git 명령을 외우는 것이 아닙니다. AI 수정 루프가 커지기 전에 멈추고, 바뀐 파일을 보고, 한 파일 단위로 되돌릴 수 있는 상태를 만드는 것입니다. 이 습관이 생기면 “AI가 고쳤는데 더 망가졌다”는 순간에도 다음 행동이 보입니다.

참고 출처

OpenAI Prompt engineering guide: https://developers.openai.com/api/docs/guides/prompt-engineering
OpenAI Codex README: https://github.com/openai/codex
Git diff documentation: https://git-scm.com/docs/git-diff
Git restore documentation: https://git-scm.com/docs/git-restore
Git reset documentation: https://git-scm.com/docs/git-reset

AI 수정이 더 망가질 때, 3분 만에 되돌리는 5줄 프롬프트