AI가 만든 코드가 안 돌아갈 때 30초 오류 프롬프트

AI 코딩 도구로 만든 코드가 한 번에 실행되지 않으면 초보자는 두 가지로 흔들립니다. 하나는 "내가 뭘 잘못했지"라는 불안이고, 다른 하나는 AI에게 바로 "고쳐줘"라고 다시 맡기고 싶은 마음입니다. 그런데 이 상태로 질문하면 AI는 오류가 난 위치보다 새 코드를 더 많이 만들거나, 이미 맞는 파일까지 바꿀 수 있습니다.

Tap to zoom

이 상황에서 필요한 것은 긴 디버깅 이론이 아닙니다. 먼저 30초 안에 오류를 묶는 방식입니다. 작업 목적, 오류 전체, 관련 코드, 실행 환경만 제대로 주면 AI는 추측을 줄이고 실제로 멈춘 지점부터 볼 수 있습니다.

먼저 마지막 줄이 아니라 첫 오류 줄을 잡습니다

터미널이 길게 빨갛게 보이면 마지막 줄만 복사하기 쉽습니다. 하지만 마지막 줄의 exit code 1이나 Command failed는 결과일 때가 많습니다. nodejs.org의 Node.js 문서에서도 0이 아닌 종료 코드는 일반적으로 실패를 뜻하지만, 그 숫자만으로 원인은 알 수 없습니다. 원인은 보통 그 위쪽에 있는 첫 오류 줄, 파일 경로, 줄 번호, 모듈 이름에 있습니다.

30초 루틴의 첫 행동은 단순합니다.

1. 실패한 명령어를 확인합니다.
2. 빨간 오류가 처음 시작된 줄을 찾습니다.
3. 그 줄 위아래 10줄을 함께 복사합니다.
4. 파일 경로와 줄 번호가 보이면 따로 적습니다.

예를 들어 npm run build가 실패했다면 npm run 자체가 문제가 아닐 수 있습니다. docs.npmjs.com의 npm 공식 문서 기준으로 npm run <script>는 package.json에 적힌 스크립트를 실행하는 명령입니다. 그러니 AI에게는 "npm이 안 됩니다"보다 "이 프로젝트의 build 스크립트를 실행했더니 아래 파일에서 이런 오류가 납니다"라고 줘야 합니다.

30초 오류 묶음은 네 칸이면 충분합니다

AI에게 다시 물을 때는 긴 사연보다 네 칸이 더 잘 먹힙니다. 초보자에게 필요한 프롬프트는 아래 형태입니다.

작업 목적:
나는 지금 [무엇을 만들거나 고치려는지] 하고 있습니다.

실행한 명령:
[터미널에 입력한 명령어]

오류 전체:
[첫 오류 줄부터 위아래 10줄]

관련 코드:
[오류에 나온 파일 경로와 해당 함수/컴포넌트 코드]

실행 환경:
프레임워크: [예: Next.js, React, Node.js]
패키지 매니저: [예: npm]
최근에 바꾼 것: [파일명 또는 기능]

요청:
원인 후보를 3개로 좁히고, 가장 먼저 확인할 파일 1개와 최소 수정안을 알려주세요.
전체 코드를 새로 만들지 말고 변경해야 할 부분만 보여주세요.

이 프롬프트의 핵심은 "전체 코드를 새로 만들지 말라"는 마지막 문장입니다. AI가 문제를 크게 해석하면 작은 오류도 구조 변경으로 번질 수 있습니다. 반대로 변경 범위를 제한하면 지금 멈춘 위치를 먼저 보게 만들 수 있습니다.

관련 코드는 오류에 나온 파일부터 붙입니다

초보자가 자주 하는 실수는 프로젝트 전체를 설명하려고 하는 것입니다. 처음에는 전체 구조보다 오류에 나온 파일 하나가 더 중요합니다. 오류 메시지에 app/page.tsx, src/components/Form.tsx, lib/api.ts 같은 경로가 보이면 그 파일의 관련 함수나 컴포넌트만 붙입니다.

관련 코드가 너무 길면 이렇게 잘라서 줍니다.

Next.js 프로젝트라면 nextjs.org의 Error Handling 문서처럼 오류가 어느 경계와 파일에서 처리되는지도 함께 보는 편이 좋습니다. 초보자 단계에서는 이 문서를 전부 외우기보다, 오류가 난 파일과 그 파일을 감싸는 페이지 또는 컴포넌트를 함께 붙이는 정도면 충분합니다.

관련 파일: app/page.tsx
오류 위치: 24번째 줄 근처
아래는 해당 컴포넌트 전체입니다.

[코드 붙여넣기]

타입 오류라면 TypeScript 설정도 도움이 됩니다. typescriptlang.org의 TypeScript 문서에서 설명하는 noEmit 옵션은 타입 검사를 하되 JavaScript 파일을 출력하지 않게 할 때 쓰입니다. 프로젝트에 npm run typecheck 같은 스크립트가 있다면, 빌드 전에 타입 오류만 따로 확인할 수 있습니다. 다만 스크립트 이름은 프로젝트마다 다르므로 먼저 package.json의 scripts를 봐야 합니다.

AI 답변은 바로 붙이지 말고 변경 범위부터 봅니다

AI가 수정안을 주면 바로 복사하기 전에 세 가지를 확인합니다.

Tap to zoom

1. 수정 파일이 오류에 나온 파일과 연결되어 있는지 봅니다.
2. 삭제되는 코드가 너무 많지 않은지 봅니다.
3. 새 패키지 설치나 환경변수 추가를 요구하는지 봅니다.

오류가 한 줄인데 AI가 파일 세 개를 새로 만들라고 하면 다시 물어보는 편이 낫습니다. 이렇게 요청합니다.

수정 범위가 너무 큽니다.
지금 오류를 해결하기 위한 최소 변경만 다시 제안해 주세요.
새 파일 생성, 패키지 추가, 전체 구조 변경은 하지 말고
오류가 난 파일 안에서 먼저 고칠 수 있는 방법을 보여주세요.

이 질문은 AI를 부정하는 말이 아닙니다. 코딩 도구를 잘 쓰는 사람일수록 AI에게 넓은 권한을 주기 전에 변경 범위를 좁힙니다.

같은 오류가 다시 나면 재현 결과를 붙입니다

AI가 준 수정안을 적용했는데 같은 오류가 다시 나면 "아직 안 됩니다"라고만 말하지 않습니다. 수정 전후를 구분해 줘야 합니다.

방금 제안한 수정안을 적용했습니다.
변경한 파일: [파일명]
다시 실행한 명령: [명령어]
결과: 같은 오류가 납니다 또는 오류가 바뀌었습니다.
새 오류:
[새 오류 전체]

이번에는 이전 답변의 가정 중 틀렸을 가능성이 있는 부분을 먼저 짚어 주세요.

이 문장이 중요한 이유는 AI가 방금 했던 추측을 다시 점검하게 만들기 때문입니다. 사람 디버깅도 마찬가지입니다. 첫 가정이 틀렸으면 다음에는 새 정보를 기준으로 원인 후보를 줄여야 합니다.

오늘 남길 결과물은 오류 묶음 하나입니다

지금 바로 할 훈련은 작습니다. 실행이 실패한 프로젝트 하나를 열고, 아래 네 줄을 채우세요.

작업 목적:
실행한 명령:
첫 오류 줄:
관련 파일:

여기까지 채우면 이미 막연한 질문에서 벗어난 상태입니다. 그다음에 전체 프롬프트를 붙이면 AI는 "어디가 문제인지 모르겠다"가 아니라 "이 파일의 이 오류부터 보자"는 방향으로 답하기 쉬워집니다.

참고 출처

• npm run-script 공식 문서: https://docs.npmjs.com/cli/v10/commands/npm-run-script
• Node.js process exit codes: https://nodejs.org/api/process.html#exit-codes
• TypeScript noEmit 옵션: https://www.typescriptlang.org/tsconfig/noEmit.html
• Next.js Error Handling 문서: https://nextjs.org/docs/app/getting-started/error-handling