AI가 파일을 너무 많이 고칠 때, 초보가 3분 만에 막는 5줄 프롬프트

버튼 문구 하나를 바꿔 달라고 했는데 AI 코딩 도구가 파일 8개를 고치겠다고 하면 그대로 맡기기 어렵습니다. 설정 파일이 바뀌고, 새 패키지가 추가되고, 원래 문제와 상관없는 컴포넌트까지 손대면 초보자는 다음 오류가 어디서 시작됐는지 잃어버립니다. 이때 필요한 것은 더 긴 설명이 아니라 수정 범위를 다시 잠그는 3분 루틴입니다.

Tap to zoom

developers.openai.com의 OpenAI 프롬프트 엔지니어링 문서는 모델에게 정체성, 지시, 예시, 맥락을 주는 구조를 안내합니다. 코딩 요청도 같습니다. "고쳐줘"라고만 쓰면 AI는 문제를 해결하기 위해 넓게 움직일 수 있습니다. 반대로 파일, 금지 항목, 검증 조건을 적으면 작업 범위가 작아집니다.

먼저 변경 파일 수를 보고 멈출지 정합니다

AI가 수정안을 내기 시작했거나 이미 코드를 바꿨다면 첫 질문은 "맞게 고쳤나"가 아닙니다. 먼저 몇 개 파일이 바뀌었는지 봅니다. Git을 쓰는 프로젝트라면 아래 명령으로 파일 목록을 확인합니다.

git diff --name-only

아직 저장 전이거나 에디터 안에서만 수정안을 보는 중이라면 변경될 파일 목록을 먼저 읽습니다. 작은 UI 문구, 단일 오류, 한 컴포넌트 수정인데 파일이 4개 이상 바뀌면 바로 다음 수정을 맡기지 않습니다. 이 기준은 절대 규칙이 아니라 초보자용 멈춤 신호입니다.

먼저 아래 세 줄을 채웁니다.

원래 요청:
바뀐 파일 수:
관련 있어 보이는 파일:

예시는 이렇습니다.

원래 요청: 로그인 버튼이 눌리지 않는 문제 수정
바뀐 파일 수: 8개
관련 있어 보이는 파일: app/login/page.tsx, components/login-form.tsx

이 세 줄이 없으면 AI에게 다시 물을 때도 범위가 넓어집니다. 지금은 좋은 설계보다 관련 없는 변경을 멈추는 것이 먼저입니다.

새 패키지와 설정 변경은 따로 허락하게 만듭니다

초보자가 가장 많이 흔들리는 지점은 새 패키지 설치와 설정 파일 변경입니다. package.json, next.config.*, tsconfig.json, .env*가 바뀌면 원래 문제보다 영향 범위가 커질 수 있습니다. OpenAI Codex CLI 문서는 Codex CLI를 터미널에서 실행하며 선택한 디렉터리의 코드를 읽고, 바꾸고, 실행할 수 있는 코딩 에이전트로 설명합니다. 로컬 파일을 바꿀 수 있는 도구라면, 바꿔도 되는 파일과 안 되는 파일을 사용자가 먼저 정해야 합니다.

아래 문장을 재지시 앞부분에 붙입니다.

새 패키지 설치, 설정 파일 변경, 폴더 구조 변경은 먼저 제안만 하고 적용하지 마세요.

이 문장은 AI를 못 믿겠다는 뜻이 아닙니다. 초보자가 원인을 추적할 수 있는 범위를 지키는 장치입니다. 특히 배포 오류, 타입 오류, 버튼 클릭 오류처럼 한 증상을 고치는 작업에서는 새 패키지부터 넣으면 원인이 더 흐려집니다.

Tap to zoom

다음 파일이 바뀌면 한 번 더 확인합니다.

tsconfig.json의 strict 옵션을 낮추거나 package.json에 새 라이브러리를 넣는 수정은 빨라 보일 수 있습니다. 하지만 지금 문제를 직접 고친 것이 아니라 검사 기준이나 도구 구성을 바꾼 것일 수 있습니다.

5줄 프롬프트로 수정 범위를 다시 잠급니다

AI에게 다시 요청할 때는 긴 사과나 배경 설명이 필요 없습니다. 아래 5줄만 채워도 충분합니다.

방금 요청은 [원래 문제] 하나만 고치는 작업입니다.
수정 가능 파일은 [파일 경로 1], [파일 경로 2]까지로 제한해 주세요.
새 패키지 설치, 설정 파일 변경, 폴더 구조 변경은 적용하지 말고 필요하면 이유만 제안해 주세요.
먼저 수정 계획을 3줄로 쓰고, 제가 승인한 뒤 코드 변경안을 주세요.
수정 뒤 확인 명령은 [npm run typecheck 또는 npm run build] 하나로 끝내 주세요.

실제로는 이렇게 바꿉니다.

방금 요청은 로그인 버튼 클릭이 동작하지 않는 문제 하나만 고치는 작업입니다.
수정 가능 파일은 app/login/page.tsx, components/login-form.tsx까지로 제한해 주세요.
새 패키지 설치, 설정 파일 변경, 폴더 구조 변경은 적용하지 말고 필요하면 이유만 제안해 주세요.
먼저 수정 계획을 3줄로 쓰고, 제가 승인한 뒤 코드 변경안을 주세요.
수정 뒤 확인 명령은 npm run typecheck 하나로 끝내 주세요.

여기서 핵심은 수정 가능 파일과 승인 전 계획입니다. cursor.com의 Cursor 에이전트 베스트프랙티스 글도 에이전트에게 검증 가능한 목표와 올바른 변경 여부를 판단할 신호를 주라고 설명합니다. 초보자에게 그 신호는 파일 제한, 금지 항목, 확인 명령입니다.

이미 많이 바뀌었다면 diff를 요약시킵니다

AI가 이미 여러 파일을 바꾼 뒤라면 바로 "되돌려줘"라고 쓰기 전에 무엇이 바뀌었는지 요약시킵니다. Git을 쓴다면 먼저 통계를 봅니다.

git diff --stat

그리고 AI에게 아래처럼 묻습니다.

아직 코드를 더 바꾸지 마세요.
현재 diff를 파일별로 요약해 주세요.
각 파일을 원래 요청과 직접 관련, 간접 관련, 관련 낮음으로 나눠 주세요.
관련 낮음 파일은 되돌려도 되는 후보로 표시해 주세요.

이 단계에서 중요한 것은 정답 찾기가 아니라 분류입니다. 직접 관련 파일만 남기고, 나머지는 되돌릴 후보로 빼야 다음 요청이 작아집니다. 분류 없이 다음 수정을 맡기면 변경 범위는 더 커집니다.

파일이 너무 많이 바뀐 상태에서는 아래 기준으로 멈춥니다.

이 기준은 숙련자를 묶기 위한 규칙이 아닙니다. 초보자가 원인 추적 능력을 잃지 않기 위한 안전장치입니다.

다음 요청은 확인 명령 하나로 닫습니다

수정 범위를 줄였으면 마지막 줄에는 확인 명령을 넣습니다. 프로젝트마다 다르지만 보통 아래 중 하나를 고릅니다.

npm run typecheck

npm run build

npm test

명령을 하나만 고르는 이유는 AI에게 성공 기준을 분명히 주기 위해서입니다. 확인 명령이 없으면 "수정했습니다"라는 문장으로 끝날 수 있습니다. 확인 명령이 있으면 결과가 실패했을 때 다음 질문도 짧아집니다.

마지막 재지시 문장은 이렇게 닫습니다.

변경 뒤에는 npm run typecheck 결과를 기준으로 성공 여부를 판단해 주세요.
명령이 실패하면 추가 수정 전에 실패 로그 첫 20줄을 먼저 설명해 주세요.

오늘 남길 결과물은 완벽한 프롬프트 기술이 아닙니다. 변경 파일 수를 보고, 새 패키지와 설정 변경을 멈추고, 5줄 프롬프트로 수정 범위를 잠그고, 확인 명령 하나로 닫는 습관입니다. 이 네 가지가 있으면 AI 코딩 도구가 넓게 움직여도 사용자가 다시 작업 범위를 잡을 수 있습니다.

참고 출처

• OpenAI Developers, Prompt engineering: https://developers.openai.com/api/docs/guides/prompt-engineering
• OpenAI Developers, Codex CLI: https://developers.openai.com/codex/cli
• Cursor Blog, Best practices for coding with agents: https://cursor.com/blog/agent-best-practices