2026. 6. 17.
AI가 에러 로그만 보고 엉뚱한 파일을 고칠 때, 5줄로 범위 좁히는 법
에러 로그만 붙였더니 AI가 관련 없는 파일까지 고치려 한다면 목표, 재현, 실제 결과, 제한, 검증을 먼저 적어 수정 범위를 좁혀야 합니다. 바로 복사할 5줄 요청문과 빗나간 답을 고치는 재지시문을 제공합니다.
저장 버튼을 누른 뒤 TypeError가 떴고, 에러 로그 전체를 AI에 붙였습니다. 그런데 답변은 저장 화면과 관계없는 파일까지 바꾸자고 합니다. 에러 메시지만으로는 정상 동작, 재현 순서, 건드리면 안 되는 범위를 알 수 없기 때문에 AI가 빈칸을 추측한 결과입니다.
다음 요청에서는 로그보다 먼저 목표, 재현, 실제 결과, 제한, 검증을 한 줄씩 적습니다. 이 다섯 칸은 정답을 보장하는 공식이 아니라, AI가 확인할 범위와 사용자가 판단할 성공 기준을 맞추는 입력표입니다. 첫 답이 빗나가도 질문을 모두 다시 쓰지 않고 빠진 칸만 보강해 재요청할 수 있습니다.
에러 로그보다 먼저 채울 5칸
OpenAI의 ChatGPT 프롬프트 안내는 큰 작업에서 목표, 맥락, 출력, 경계를 필요한 만큼 넣으라고 설명합니다. 특히 바뀌면 안 되는 사항은 경계로 적고, 중요한 결과에는 마지막 확인을 요청하라고 안내합니다. 코딩 오류 질문에서는 이 원칙을 아래 다섯 칸으로 바꾸면 됩니다.
목표: {정상이라면 무엇이 되어야 하는가}
재현: {어떤 명령·화면·순서에서 오류가 나는가}
실제 결과: {화면 증상 + 에러 메시지 핵심}
제한: {바꾸면 안 되는 파일·동작·의존성}
검증: {통과해야 할 명령 또는 화면 확인}
에러 고쳐줘는 실패 여부만 전달합니다. 반면 다섯 칸은 어디서 실패했고 무엇을 성공으로 볼지 함께 전달합니다. 제한에 새 패키지 추가 전 멈추기를 쓰고, 검증에 npm test와 저장 화면 재확인을 쓰면 완료 보고를 비교하기도 쉬워집니다.
그대로 복사할 수정 요청 프롬프트
아래 요청문을 복사한 뒤 {}만 바꿉니다. 로그는 지시문 뒤에 놓고, 처음부터 프로젝트 전체를 붙이지 않습니다.
아래 코딩 오류의 원인을 확인하고 가장 작은 수정 범위부터 제안해 주세요.
목표: {정상 동작}
재현: {명령·화면·클릭 순서}
실제 결과: {화면 증상과 핵심 에러}
제한: {바꾸면 안 되는 파일·동작, 새 패키지 추가 여부}
검증: {테스트·빌드·수동 확인 절차}
에러 로그:
{비밀 정보와 무관한 반복 줄을 지운 핵심 로그}
먼저 답할 내용:
1. 원인 후보를 2개 이내로 적기
2. 추가로 확인할 파일과 그 이유 적기
3. 가장 작은 수정안 제안하기
4. 실행한 검증과 실행하지 못한 검증 나누기
5. 남은 위험 적기
AI에게 더 넓은 코딩 과제를 처음 맡기는 단계라면 작업 범위를 먼저 잠그는 5줄 요청문을 함께 씁니다. 지금 원고의 프롬프트는 이미 발생한 오류의 재현과 수정 범위를 좁히는 데만 집중합니다.
재현과 검증은 짧아도 다시 따라 할 수 있게 씁니다
재현은 긴 개발 일지가 아닙니다. 다른 사람이 같은 실패를 다시 만들 수 있을 정도면 됩니다. 빌드가 안 돼요 대신 Node 22에서 npm run build를 실행하면 73%에서 멈추고 아래 TypeError가 납니다처럼 명령, 시점, 증상을 붙입니다.
검증에는 희망 결과가 아니라 확인 행동을 적습니다. 잘 작동하는지 봐 주세요보다 npm test 실행, npm run build 실행, 저장 버튼 클릭 후 성공 알림 확인이 낫습니다. 실행할 수 없는 검증은 성공처럼 쓰지 말고 실행하지 못한 이유를 따로 보고하게 합니다.
| 빈칸 | 너무 넓은 표현 | 범위를 좁히는 표현 |
|---|---|---|
| 목표 | 저장이 되게 해 주세요 | 저장 뒤 성공 알림이 뜨고 같은 페이지에 남아야 합니다 |
| 재현 | 버튼을 누르면 오류가 납니다 | 로그인 후 설정에서 저장 버튼을 누르면 오류가 납니다 |
| 실제 결과 | 작동하지 않습니다 | 화면이 멈추고 콘솔에 아래 TypeError가 납니다 |
| 제한 | 알아서 고쳐 주세요 | API 응답 형식과 디자인은 바꾸지 마세요 |
| 검증 | 확인해 주세요 | 관련 테스트와 빌드를 실행하고 결과를 적어 주세요 |
답이 빗나가면 전체 질문 대신 빠진 칸만 보강합니다
OpenAI의 같은 안내는 첫 프롬프트가 완벽할 필요가 없고, 응답을 본 뒤 필요한 변경이나 빠진 출처를 후속 메시지로 추가할 수 있다고 설명합니다. 첫 답이 빗나갔다면 다섯 칸 중 비어 있던 기준을 찾습니다.
| 나온 답 | 붙일 재지시문 |
|---|---|
| 관련 없는 파일을 많이 바꾸려 함 | 이번 오류 재현 경로와 직접 관련 없는 변경은 제외하고, 필요한 파일과 이유를 먼저 적어 주세요. |
| 설명만 길고 수정안이 없음 | 원인 후보를 2개 이내로 줄이고 가장 작은 수정안과 검증 방법을 먼저 보여 주세요. |
| 테스트 없이 완료라고 함 | 완료 판단을 멈추고 실행한 검증, 실패한 검증, 실행하지 못한 검증을 나눠 주세요. |
| 새 패키지를 바로 추가함 | 새 의존성 없이 해결할 대안을 먼저 검토하고, 꼭 필요하면 이유와 영향 범위를 적은 뒤 멈춰 주세요. |
| 로그 해석이 엇나감 | 파일 경로, 줄 번호, 첫 오류 메시지를 분리한 뒤 추가로 필요한 맥락만 요청해 주세요. |
수정 뒤에는 AI가 만든 diff를 그대로 쓸지 멈출지 가르는 검수 프롬프트로 바뀐 파일과 남은 위험을 확인할 수 있습니다. 미확인 검증이 남았으면 배포 완료로 보지 않습니다.
로그를 넣기 전 비밀 정보와 입력 범위를 확인합니다
OpenAI API의 프롬프트 엔지니어링 안내는 관련 맥락이 응답을 제한하는 데 도움을 주지만 모델이 다룰 수 있는 컨텍스트는 유한하다고 설명합니다. OpenAI 파일 업로드 FAQ도 파일 크기, 토큰, 업로드 빈도, 저장 공간에 제한이 있으며 제품과 요금제에 따라 조건이 달라질 수 있다고 밝힙니다.
따라서 로그가 길다고 전부 붙이는 것이 정답은 아닙니다. 먼저 첫 오류, 파일 경로, 줄 번호, 바로 앞뒤 맥락을 남깁니다. 비밀키, 토큰, 쿠키, 개인정보, 고객 데이터, 비공개 저장소 내용은 조직 정책을 확인하고 마스킹합니다. 더 많은 코드가 필요하다면 AI가 필요한 파일과 이유를 먼저 말하게 합니다.
다음 오류가 뜨면 로그 창에서 바로 복사하기 전에 다섯 줄을 채웁니다. 오늘 할 일은 목표·재현·실제 결과·제한·검증을 저장한 템플릿 하나를 만드는 것입니다. 이 표가 있으면 첫 요청과 재요청에서 같은 성공 기준을 유지할 수 있습니다.
참고 출처
다음으로 읽을 기사
같은 흐름으로 이어 읽기 좋은 기사만 추려 보여줍니다.
첫 번째 댓글을 남겨보세요.
여러분의 생각이 다른 독자에게 도움이 됩니다.
댓글 0
이 글을 읽은 독자들의 생각을 나눠보세요.