AI 코딩 에러 해결 공식 — 막힐 때마다 써먹는 3가지 패턴

게시일 2026-04-28수정일 2026-04-28

AI에게 에러를 보냈는데 왜 또 에러가 날까

AI 코딩 도구를 처음 사용할 때 가장 당황스러운 순간은 에러가 반복될 때입니다. "에러 고쳐줘"라고 메시지를 보내면 AI가 수정 코드를 줍니다. 그대로 붙여 넣으면 새로운 에러가 납니다. 다시 보내면 또 다른 수정 코드가 옵니다. 이 과정이 5번 이상 반복되면 "AI가 코딩을 못 하는 건가?"라는 의문이 생깁니다.

원인은 AI의 능력이 아니라 에러를 전달하는 방식에 있습니다. AI는 제공된 정보 범위 안에서만 추론합니다. 에러 메시지 한 줄만 보내면 AI도 그 한 줄로만 판단합니다. 이 글에서는 에러를 AI에게 전달할 때 반복 시행착오를 줄이는 3가지 패턴을 소개합니다. "AI 바이브코딩(AI Vibe Coding)"—AI를 대화 상대로 삼아 함께 코드를 만들어가는 방식—에서 실제로 검증된 접근법입니다.

개념 정의: 에러 해결 패턴이란

에러 해결 패턴이란 AI에게 에러를 전달할 때의 구조화된 방식을 말합니다. 무작정 에러를 붙여 넣는 것과 패턴을 적용해 전달하는 것의 차이는, 같은 에러를 한 번에 해결하느냐 여러 번 반복하느냐로 나타납니다.

핵심 전제는 하나입니다. AI는 탐정이 아닙니다. 단서를 적게 줄수록 추측이 늘어납니다. 단서를 정확히 줄수록 원인 파악이 정밀해집니다. 3가지 패턴은 모두 "AI에게 적절한 단서를 주는 방법"에 관한 것입니다.

원리·구조: AI가 정확한 답을 내놓는 조건

AI 언어 모델은 주어진 텍스트를 바탕으로 가장 확률이 높은 다음 텍스트를 생성합니다. 에러 메시지만 받으면 해당 에러의 일반적 원인 중 확률이 높은 것을 제안합니다. 실제 코드, 스택 트레이스, 라이브러리 버전 같은 맥락 정보가 추가되면 확률 계산의 기준 자체가 달라집니다. 범용 답변에서 이 코드에 맞는 답변으로 좁혀지는 것입니다.

이를 정보 경계(Information Boundary)라고 부를 수 있습니다. AI는 제공된 정보의 경계 안에서만 추론합니다. 경계가 좁으면(에러 한 줄) 추론 공간이 넓어져 빗나갈 확률이 높습니다. 경계가 넓으면(코드 + 에러 + 환경 정보) 추론 공간이 좁아져 정확도가 올라갑니다. 아래 3가지 패턴은 이 정보 경계를 효과적으로 확장하는 방법입니다.

패턴 1 — 에러 원문 + 코드 맥락 함께 전달하기

가장 흔한 실수는 에러 메시지만 보내는 것입니다. 예를 들어 Python에서 다음 에러가 발생했다고 가정합니다.

TypeError: unsupported operand type(s) for +: 'int' and 'str'

이 메시지만 보내면 AI는 일반적인 원인 목록을 나열합니다. 실제 코드를 보지 않았기 때문에 구체적인 수정 위치를 특정하지 못합니다.

올바른 전달 방식

에러 메시지, 발생 위치(스택 트레이스), 관련 코드 블록을 함께 붙여 넣습니다. 아래가 표준 형식입니다.

다음 에러가 발생했습니다. 원인과 수정 방법을 알려주세요.

[에러 메시지]
TypeError: unsupported operand type(s) for +: 'int' and 'str'

[발생 위치]
File "main.py", line 12, in calculate_total

[관련 코드]
def calculate_total(price, tax_rate):
return price + tax_rate

이 형식으로 전달하면 AI는 price와 tax_rate 중 하나가 문자열임을 즉시 파악하고, float(tax_rate) 변환이 필요하다는 정확한 수정을 제안합니다.

패턴 2 — 해결 전에 원인부터 묻기

에러가 나면 반사적으로 "고쳐줘"를 요청합니다. 그런데 원인을 이해하지 못한 채 수정 코드를 적용하면, 같은 유형의 에러가 다른 위치에서 반복됩니다.

두 단계로 나누기

1단계 — 원인 파악: "이 에러가 왜 발생하는지 설명해줘."

2단계 — 수정 요청: "그렇다면 이 코드에서 어떻게 수정하면 되는지 알려줘."

아래 예시를 살펴봅니다. JavaScript에서 다음 에러가 발생했다고 가정합니다.

Cannot read properties of undefined (reading 'map')

바로 "고쳐줘"를 요청하면 AI는 옵셔널 체이닝(?.map) 또는 초기값 설정(|| []) 중 하나를 제안합니다. 어느 쪽이 맞는지 알 수 없습니다.

반면 "왜 발생하는지 설명해줘"를 먼저 요청하면, AI는 해당 변수가 undefined인 시점과 이유를 분석합니다. API 응답이 늦는 타이밍 문제인지, 데이터 구조 자체가 잘못된 것인지 파악한 뒤 적절한 수정을 선택할 수 있습니다. 이 순서가 중요한 이유는 같은 증상이라도 원인에 따라 수정 방법이 완전히 달라지기 때문입니다.

패턴 3 — 범위 좁히기: 최소 재현 코드 만들기

실무 코드는 복잡합니다. 수백 줄의 코드를 통째로 붙여 넣으면 AI도 어디서 에러가 발생하는지 찾기 어렵습니다. 이럴 때 사용하는 방법이 최소 재현 코드(MRE, Minimum Reproducible Example)입니다. MRE란 에러를 재현할 수 있는 가장 짧은 코드 조각을 말합니다.

MRE 만드는 3단계

1단계: 에러가 발생하는 함수 또는 블록만 따로 분리합니다.
2단계: 해당 블록이 동작하기 위한 최소한의 데이터(변수, 입력값)만 남깁니다.
3단계: 이 최소 코드가 단독으로도 같은 에러를 재현하는지 확인합니다.

예를 들어 React 컴포넌트 전체에서 에러가 난다면, 관련 state와 렌더 로직만 20줄로 추출해 AI에게 전달합니다. 전체 코드 300줄 대신 20줄을 보내는 것입니다.

// MRE 예시
import React, { useState } from 'react';

function ItemList() {
  const [items, setItems] = useState(null);
  return (
    <ul>
      {items.map(item => <li key={item.id}>{item.name}</li>)}
    </ul>
  );
}

이 코드만 보면 items의 초기값이 null이어서 .map을 사용할 수 없다는 원인이 즉시 드러납니다. 초기값을 []로 바꾸면 해결됩니다. MRE는 작성하는 과정 자체가 에러의 원인을 스스로 발견하게 만드는 효과도 있습니다. 300줄 코드를 20줄로 줄이는 과정에서 원인을 스스로 찾아내는 경우가 적지 않습니다.

판단 기준: 언제 어떤 패턴을 쓸까

에러 메시지는 있지만 어느 코드 줄인지 모를 때 → 패턴 1(에러 원문 + 스택 트레이스 + 코드 함께 전달)
같은 유형의 에러가 반복될 때 → 패턴 2(원인 먼저 이해, 수정은 나중)
코드가 복잡하고 AI 응답이 계속 빗나갈 때 → 패턴 3(MRE로 범위 축소)

세 패턴을 조합할 수도 있습니다. 복잡한 코드에서 에러가 났다면 패턴 3으로 범위를 먼저 줄이고(MRE 작성), 패턴 1 형식으로 전달한 뒤, 패턴 2 순서대로 원인 파악 후 수정을 요청합니다.

반면 이 패턴들이 효과를 내지 못하는 경우도 있습니다. AI가 학습하지 않은 라이브러리 버전, 또는 환경 설정(OS, 패키지 버전 충돌)에서 발생하는 에러는 AI 단독으로 해결하기 어렵습니다. 이 경우에는 공식 문서나 GitHub Issues를 우선 확인하는 것이 빠릅니다.

3가지 패턴의 핵심은 하나입니다. AI에게 정보를 충분히, 정확하게 전달할수록 답의 정확도가 올라갑니다. 에러 해결에 익숙해졌다면, 에러가 발생하기 전에 AI와 코드를 설계하는 단계로 넘어갈 수 있습니다. 관련 글: AI 바이브코딩으로 첫 스크립트 만들기 — AI와 함께 처음 코드를 작성할 때의 구체적인 대화 흐름을 다룹니다.