에러 로그 AI 수정 프롬프트, 코딩 오류 질문을 5줄로 줄이는 법

에러 로그가 길게 뜨면 가장 빠른 행동은 전체를 복사해 AI에게 붙여 넣는 일처럼 보입니다. 하지만 로그만 던지면 AI는 어떤 화면에서 문제가 났는지, 사용자가 무엇을 기대했는지, 어떤 파일을 건드려도 되는지 추측해야 합니다. 그 결과 원인은 맞게 짚어도 수정 범위가 커지거나, 테스트 없이 고쳤다고 말하는 답이 나올 수 있습니다. 먼저 에러 로그를 5줄짜리 수정 지시서로 바꾸면 AI가 헤매는 시간이 줄어듭니다.

OpenAI Help Center의 프롬프트 작성 안내는 지시문을 앞에 두고 맥락과 원하는 출력 형식을 구체적으로 나누라고 설명합니다. Codex CLI 문서도 로컬 디렉터리 안에서 코드를 읽고, 바꾸고, 명령을 실행할 수 있다고 안내합니다. 그래서 코딩 질문은 "이 에러 고쳐줘"가 아니라 "어디에서 재현되고, 어떤 결과가 나와야 하며, 무엇으로 검증할지"까지 들어가야 합니다.

에러 로그는 원인이 아니라 증거입니다

로그는 중요한 증거지만 작업 지시서는 아닙니다. 예를 들어 TypeError: Cannot read properties of undefined라는 문장만 보면 원인은 여러 갈래입니다. 데이터가 늦게 도착했을 수도 있고, 필드 이름이 바뀌었을 수도 있고, 조건부 렌더링이 빠졌을 수도 있습니다. AI에게 로그만 주면 이 갈래 중 하나를 추측해 고칩니다.

먼저 로그를 아래 5줄로 나눕니다.

목표: {무엇이 정상으로 작동해야 하는가}
재현: {어떤 화면이나 명령에서 어떤 순서로 문제가 나는가}
실제 결과: {에러 로그 핵심 5줄과 화면 증상}
제한 조건: {바꾸면 안 되는 파일, 새 패키지 금지, 디자인 유지}
검증: {실행할 명령이나 수동 확인 절차}

이 형식은 AI에게 정답을 강요하는 문장이 아닙니다. 추측할 범위를 줄이는 입력 양식입니다. 특히 제한 조건과 검증이 빠지면 AI는 문제를 넓게 고치거나, 검증하지 못한 채 완료처럼 말할 수 있습니다.

붙여 넣을 첫 프롬프트는 로그보다 상황을 먼저 둡니다

에러 로그를 붙여 넣기 전 첫 문장을 작업 지시로 시작합니다. 그다음 상황을 적고, 마지막에 로그를 붙입니다. OpenAI의 프롬프트 안내가 말하는 것처럼 원하는 맥락과 출력 형식을 구체적으로 주면 결과를 비교하기 쉬워집니다.

아래 코딩 오류를 고쳐 주세요. 먼저 원인 후보를 2개 이내로 좁힌 뒤, 가장 작은 수정안부터 제안해 주세요.

목표: {정상이라면 어떤 동작이 되어야 하는지}
재현: {명령, 화면, 클릭 순서}
실제 결과: {사용자가 본 증상}
제한 조건: {바꾸면 안 되는 것}
검증: {npm run test, npm run build, 브라우저 확인 등}

에러 로그:
{에러 로그 핵심 부분}

출력 형식:
1. 원인 후보
2. 수정할 파일
3. 수정 내용
4. 검증 방법
5. 아직 확인하지 못한 위험

여기서 핵심은 로그 전체를 길게 넣기보다 핵심 부분을 먼저 넣는 것입니다. 파일 업로드나 긴 문서 입력은 계정, 기능, 사용량에 따라 제한이 있을 수 있으므로 help.openai.com의 파일 업로드 안내처럼 한 번에 넣을 수 있는 자료가 항상 무제한이라고 보면 안 됩니다. 비밀키, 고객 정보, 토큰이 섞인 로그는 먼저 지우고 넣어야 합니다.

재현 단계가 없으면 AI는 파일을 넓게 뒤집니다

AI 코딩 답변이 엉뚱해지는 흔한 이유는 재현 단계가 빠지는 것입니다. "빌드가 깨진다"는 말은 너무 넓습니다. 대신 어떤 명령을 실행했고, 몇 번째 단계에서 멈췄는지 적어야 합니다.

빠진 정보	AI가 추측하는 부분	넣을 문장
명령	어떤 환경에서 실패했는지	`npm run build에서 실패했습니다.`
화면	어떤 사용자 흐름인지	`로그인 후 설정 저장 버튼을 누를 때 발생합니다.`
기대 동작	무엇을 성공으로 봐야 하는지	`저장 후 토스트가 뜨고 같은 페이지에 남아야 합니다.`
실제 결과	화면 증상과 로그의 연결	`버튼을 누르면 화면은 멈추고 콘솔에 아래 로그가 나옵니다.`

재현 단계는 길 필요가 없습니다. 같은 문제를 다시 만들 수 있을 정도면 충분합니다. AI에게도 이 정보가 있으면 로그를 코드 전체의 문제로 보지 않고 한 흐름의 문제로 좁혀 볼 수 있습니다.

검증 명령은 마지막 부탁이 아니라 작업 기준입니다

코딩 수정에서 가장 위험한 답은 "고쳤습니다"로 끝나는 답입니다. 사용자는 실제로 통과한 명령이 무엇인지 알아야 다음 행동을 정할 수 있습니다. Codex CLI처럼 로컬 디렉터리에서 코드를 읽고 명령을 실행할 수 있는 도구를 쓸 때도, 어떤 명령을 확인해야 하는지 먼저 적어 두면 보고서가 선명해집니다.

아래 문장을 프롬프트 끝에 붙입니다.

수정 후 아래 순서로 검증해 주세요.
1. 관련 테스트가 있으면 먼저 실행해 주세요.
2. package.json에서 lint, test, build 명령을 확인하고 가능한 범위에서 실행해 주세요.
3. 실행하지 못한 명령은 이유를 적어 주세요.
4. 실패한 명령이 있으면 로그 핵심과 다음 수정 방향을 분리해 주세요.
5. 완료 보고에는 바뀐 파일, 실행한 명령, 남은 위험만 적어 주세요.

검증 명령을 모를 때는 AI에게 찾게 하면 됩니다. 다만 "알아서 다 해줘"라고 쓰면 범위가 넓어집니다. "package.json에서 가능한 명령을 찾고, 관련 있는 것부터 실행해 달라"고 쓰면 수정 범위와 검증 범위가 동시에 좁아집니다.

결과가 빗나가면 전체 질문을 다시 쓰지 않습니다

첫 답이 마음에 들지 않을 때 새 질문을 처음부터 다시 쓰면 같은 실수가 반복됩니다. 증상별로 수정문만 붙이는 편이 빠릅니다.

나온 결과	다시 붙일 수정문
관련 없는 파일을 많이 바꿈	`이번 오류와 직접 관련 없는 변경은 되돌리고, 최소 파일만 바꾸는 수정안을 다시 제안해 주세요.`
원인 설명만 길고 코드가 없음	`설명보다 실제 수정이 필요합니다. 수정할 파일과 변경 내용을 먼저 제시하고 검증 명령을 붙여 주세요.`
테스트 없이 완료라고 함	`완료라고 말하기 전에 실행 가능한 검증 명령을 실행하거나, 실행하지 못한 이유를 분리해 주세요.`
새 패키지를 추가함	`새 패키지 없이 현재 의존성 안에서 해결하는 대안을 먼저 제안해 주세요.`
로그를 잘못 해석함	`아래 로그에서 파일 경로, 줄 번호, 에러 메시지를 먼저 분리한 뒤 다시 원인을 좁혀 주세요.`

이 수정문은 AI를 더 강하게 재촉하는 말이 아닙니다. 빠진 기준을 다시 넣는 말입니다. 원래 프롬프트의 5줄 중 어느 줄이 비었는지 보고 그 줄만 보강하면 됩니다.

오늘 쓸 수 있는 에러 로그 질문표를 저장합니다

에러 로그를 AI에게 붙일 때는 코드보다 먼저 기준을 붙입니다. 아래 양식을 저장해 두고 {} 안만 바꾸면 됩니다.

아래 오류를 가장 작은 범위로 고쳐 주세요.

목표: {}
재현: {}
실제 결과: {}
제한 조건: {}
검증: {}

에러 로그:
{}

요청:
- 원인 후보를 2개 이내로 좁혀 주세요.
- 관련 파일과 수정 이유를 분리해 주세요.
- 새 패키지나 큰 구조 변경이 필요하면 먼저 이유를 설명하고 멈춰 주세요.
- 검증 명령을 실행하거나, 실행하지 못한 이유를 적어 주세요.
- 마지막에는 바뀐 파일, 검증 결과, 남은 위험만 요약해 주세요.

AI가 코딩 문제를 잘 풀게 만드는 첫 단계는 더 긴 로그를 붙이는 일이 아닙니다. 목표, 재현, 실제 결과, 제한 조건, 검증을 먼저 나누는 일입니다. 다음에 에러가 뜨면 로그를 바로 붙이지 말고 이 5줄을 먼저 채웁니다. 그러면 AI의 첫 답부터 수정 범위가 좁아지고, 다시 묻는 횟수도 줄어듭니다.

에러 로그만 붙이면 AI가 헤매는 이유, 수정 지시 5줄로 줄이는 법