← 블로그 목록

AI 코딩 오류 해결: 같은 버그가 반복될 때 원인 좁히는 순서

AI가 고쳤다고 했는데 같은 오류가 반복될 때, 화면 증상과 로그, 최근 수정 파일, 배포 환경을 기준으로 원인을 좁히는 순서를 정리했습니다.

AI 코딩에서 제일 답답한 순간은 오류가 난다는 사실보다, AI가 고쳤다고 했는데 다시 같은 문제가 나는 순간입니다.

예를 들어 이런 식입니다.

  • 버튼을 누르면 계속 흰 화면이 뜬다
  • AI가 코드를 바꿨는데 Vercel 배포는 여전히 실패한다
  • 로컬에서는 되는데 운영 주소에서만 로그인이 풀린다
  • 같은 파일을 세 번 고쳤는데 에러 메시지만 조금씩 바뀐다

이때 바로 "다시 고쳐줘"라고 하면 코드가 더 지저분해질 수 있습니다. 먼저 해야 할 일은 프롬프트를 길게 쓰는 것이 아니라, 오류가 어느 단계에서 나는지 좁히는 것입니다.

1. 어디에서만 실패하는지 먼저 나눈다

같은 오류처럼 보여도 실패하는 위치가 다르면 원인이 다릅니다. 아래 네 칸 중 어디에 표시할 수 있는지 먼저 봐야 합니다.

실패 위치먼저 볼 것
AI 미리보기에서는 보이는데 실제 사이트가 다름저장 여부, 배포된 브랜치, preview와 production 차이
로컬 개발 모드에서만 실패최근 수정 파일, 브라우저 콘솔, 상태 관리 흐름
npm run build에서 실패TypeScript 에러, import 경로, 서버/클라이언트 코드 경계
Vercel·Netlify 배포에서만 실패환경 변수, 빌드 명령, Node 버전, 외부 서비스 설정

여기서 가장 중요한 건 "로컬에서는 됩니다"라는 말만으로 끝내지 않는 것입니다. 로컬 개발 모드, 로컬 빌드, 배포 미리보기, 운영 주소는 서로 다른 환경입니다. 어느 환경에서만 깨지는지 알아야 AI가 잘못된 파일을 계속 만지는 일을 줄일 수 있습니다.

2. 에러의 첫 줄과 마지막 줄을 구분한다

배포 로그나 터미널 로그를 보면 마지막 줄이 제일 눈에 들어옵니다. 하지만 마지막 줄은 보통 "빌드가 실패했다"는 결과일 뿐이고, 원인은 그보다 위에 있는 경우가 많습니다.

먼저 이런 표현을 찾으세요.

  • Module not found
  • Type error
  • ReferenceError
  • Cannot read properties of undefined
  • Environment Variable
  • Failed to compile
  • Export encountered errors
  • 401, 403, 404, 500 같은 네트워크 응답

예를 들어 Cannot read properties of undefined는 화면 코드가 잘못됐다는 뜻일 수도 있지만, 배포 환경에 필요한 API 키가 비어 있어서 undefined가 된 것일 수도 있습니다. 그래서 에러 문장만 보지 말고, 그 에러가 로컬과 배포 중 어디에서 처음 생겼는지 같이 봐야 합니다.

3. 최근 AI가 건드린 파일을 되짚는다

AI 진단 오류가 생길 때는 보통 같은 파일을 계속 만집니다. 화면이 깨졌으니 화면 컴포넌트만 고치고, 배포가 실패했으니 package.json만 바꾸는 식입니다.

그 전에 최근 수정 내역을 이렇게 나눠보세요.

  1. 마지막으로 정상 동작하던 시점이 있었는가?
  2. 그 이후 AI가 어떤 파일을 바꿨는가?
  3. 새 라이브러리나 설정 파일이 추가됐는가?
  4. 환경 변수 이름이 바뀌었는가?
  5. 같은 코드를 여러 파일에 복사해 넣었는가?

GitHub를 쓰고 있다면 diff를 보는 것이 가장 빠릅니다. 저장소가 없다면 AI가 마지막으로 출력한 코드, 수정한 파일명, 바꿔달라고 한 프롬프트라도 남겨두는 게 좋습니다. 오류 해결은 "현재 화면"보다 "언제부터 깨졌는지"가 더 중요할 때가 많습니다.

4. AI에게 다시 시키기 전에 물어볼 질문

AI에게 바로 코드를 고치라고 하기보다, 먼저 원인 후보를 나누게 만드는 편이 낫습니다. 아래처럼 물어보면 불필요한 수정이 줄어듭니다.

text
이 에러를 바로 수정하지 말고 원인 후보를 먼저 나눠줘.
1. 코드 문제인지, 환경 변수/배포 설정 문제인지 구분해줘.
2. 가장 먼저 확인해야 할 로그 한 줄을 알려줘.
3. 수정 전에 내가 확인해야 할 파일이나 설정을 목록으로 적어줘.
4. 확실하지 않은 추측은 추측이라고 표시해줘.

이렇게 물었는데도 AI가 원인 설명 없이 코드를 크게 갈아엎는다면 멈추는 편이 좋습니다. 그 상태에서 계속 진행하면 원래 문제는 그대로인데 임시 방어 코드만 늘어날 수 있습니다.

5. 문의할 때는 이 정도만 적어도 충분하다

개발자에게 맡길 때 완벽한 문서를 만들 필요는 없습니다. 대신 아래 여섯 가지가 있으면 바로 원인을 좁힐 수 있습니다.

  • 문제가 보이는 URL
  • 어떤 버튼이나 동작을 했을 때 오류가 나는지
  • 로컬, 미리보기, 운영 배포 중 어디에서 나는지
  • 에러 메시지 첫 줄 또는 배포 로그 첫 에러
  • AI가 마지막으로 수정한 파일이나 요청 내용
  • 어디까지 되면 해결이라고 볼 수 있는지

예시는 이렇습니다.

text
Vercel 운영 주소에서만 로그인 후 새로고침하면 로그아웃됩니다.
로컬에서는 유지됩니다. 마지막으로 AI가 auth 관련 코드를 수정했습니다.
브라우저 콘솔에는 401이 보이고, Vercel 환경 변수에는 SUPABASE 관련 키를 넣어둔 상태입니다.
로그인 상태가 새로고침 후에도 유지되면 해결입니다.

이 정도면 "코딩 오류 해결"이라는 넓은 요청이 아니라, 실제로 확인 가능한 작업이 됩니다. API 키나 비밀번호 값은 보내지 말고, 어떤 이름의 환경 변수가 있는지만 알려주면 됩니다.

정리

AI 코딩 오류가 반복될 때는 "한 번만 더 고쳐달라"보다 아래 순서가 더 빠릅니다.

  1. 어느 환경에서만 실패하는지 나눈다
  2. 로그의 첫 번째 의미 있는 에러를 찾는다
  3. 마지막으로 정상 동작하던 시점과 수정 파일을 확인한다
  4. AI에게 바로 수정이 아니라 원인 후보 분류를 시킨다
  5. 같은 파일을 세 번 이상 고치면 멈추고 재현 단서를 정리한다

오류 해결은 운이 좋으면 한 줄로 끝납니다. 하지만 같은 문제가 반복된다면 이제는 코드보다 진단이 먼저입니다. 지금 깨진 화면, 첫 에러 한 줄, 마지막 AI 수정 내역만 있어도 원인을 훨씬 좁힐 수 있습니다.

관련 글: 바이브코딩 수정 비용은 어떻게 정해질까, Vercel 배포 후 흰 화면이 뜰 때 확인할 7가지, AI 코딩 에이전트가 고치지 못하는 버그의 3가지 특징

오류 원인 진단

AI가 같은 파일만 계속 고친다면 오류 원인부터 다시 나눠보세요

화면 주소, 에러 첫 줄, 최근 AI 수정 내역, 배포 로그를 기준으로 코드 문제인지 설정 문제인지 먼저 좁혀봅니다.

코딩 오류 진단 요청하기