AI 에이전트가 실패하는 방식은 생각보다 몇 가지로 수렴합니다. 목표가 넓어 끝을 모르는 경우, 검증 없이 자기 보고만 믿는 경우, 맥락이 넘쳐 앞을 잊는 경우, 도구를 잘못 고르거나 없는 도구를 지어내는 경우, 그리고 같은 실패를 종료 조건 없이 반복하는 경우입니다. 대부분의 사고는 모델 성능이 아니라 이 다섯 가지 구조적 결함에서 나오며, 각각은 설계 단계에서 막을 수 있습니다.
패턴 1 — 목표가 넓어 끝을 모른다
가장 흔하고 가장 비싼 실패입니다. "이 코드베이스를 개선해라", "시장을 조사해라" 같은 목표는 완료 조건이 없습니다. 에이전트는 언제 멈춰야 할지 모르므로 계속 무언가를 하고, 결과물은 넓고 얕아집니다.
증상은 알아보기 쉽습니다. 실행 시간이 회차마다 크게 달라지고, 같은 목표를 두 번 돌렸을 때 완전히 다른 결과가 나옵니다. 산출물이 요청하지 않은 것까지 포함하고 있다면 거의 확실합니다.
대응은 목표를 완료 조건으로 바꿔 쓰는 것입니다. "개선해라" 대신 "테스트가 모두 통과하는 상태에서 이 함수의 중복 호출을 제거해라"처럼 판정 가능한 형태로 적습니다. 범위를 좁히는 구체적인 방법은 작업 지시서 쓰기에서 다룹니다.
패턴 2 — 검증 없이 자기 보고만 믿는다
에이전트는 "완료했습니다"라고 보고하는 데 매우 능숙합니다. 문제는 그 보고가 실제 결과와 무관하게 생성될 수 있다는 점입니다. 모델은 작업의 성공 여부를 관찰한 것이 아니라, 성공 보고문을 그럴듯하게 만들어 낸 것일 수 있습니다.
이것이 환각의 가장 위험한 형태입니다. 사실을 틀리게 말하는 환각은 읽으면 알아챌 수 있지만, 하지 않은 일을 했다고 말하는 환각은 실제로 결과물을 열어보기 전까지 드러나지 않습니다. 그리고 그 보고가 다음 단계의 입력이 되면, 잘못된 전제 위에서 나머지 작업이 진행됩니다.
대응은 모델 바깥에 검증을 두는 것입니다. 파일이 실제로 생성되었는지, 테스트가 통과하는지, 반환값이 기대한 형식인지를 코드가 확인합니다. 완료 보고를 어떻게 확인할지는 AI 완료 보고 검증하기에서 자세히 정리했습니다.
패턴 3 — 맥락이 넘쳐 앞을 잊는다
에이전트가 오래 돌수록 대화 기록은 계속 쌓입니다. 그런데 모델이 한 번에 볼 수 있는 양은 컨텍스트 윈도우로 제한되어 있습니다. 한도를 넘으면 앞부분이 잘려 나가고, 잘려 나간 부분에는 대개 원래 목표와 초기 제약이 들어 있습니다.
증상은 특징적입니다. 초반에는 지시를 잘 지키던 에이전트가 후반에 갑자기 규칙을 어깁니다. 하지 말라고 한 것을 하고, 이미 끝낸 작업을 다시 하고, 목표와 무관한 방향으로 흘러갑니다. 사람이 보기에는 "말을 안 듣는 것"처럼 보이지만 실제로는 지시가 시야에서 사라진 것입니다.
대응은 세 가지입니다. 매 회차의 전체 출력을 그대로 쌓지 말고 요약해서 넣습니다. 목표와 제약은 매 회차 앞부분에 다시 넣습니다. 그리고 장기 작업이라면 에이전트 메모리처럼 대화 기록 바깥에 상태를 저장하는 구조를 씁니다. 프로젝트 규칙을 파일로 고정하는 방법은 CLAUDE.md 작성법을 참고하시면 됩니다.
패턴 4 — 도구를 잘못 쓰거나 없는 도구를 지어낸다
에이전트가 도구를 쓸 때 나타나는 실패는 세 갈래입니다. 존재하지 않는 도구를 호출하려 하거나, 있는 도구에 잘못된 인자를 넘기거나, 상황에 맞지 않는 도구를 고릅니다.
세 번째가 특히 조용히 지나갑니다. 검색으로 확인해야 할 것을 기억에서 답하거나, 읽기만 하면 되는 상황에서 쓰기 도구를 부르는 식입니다. 호출 자체는 성공하므로 오류가 나지 않고, 결과만 잘못됩니다.
대응은 도구 설명을 사람이 아니라 모델 기준으로 다시 쓰는 것입니다. 함수 호출 정의에서 각 도구가 "언제 써야 하는지"와 "언제 쓰면 안 되는지"를 함께 적습니다. 도구 수를 줄이는 것도 효과가 큽니다. 선택지가 스무 개일 때보다 다섯 개일 때 정확도가 눈에 띄게 올라갑니다. 되돌리기 어려운 도구에는 가드레일을 걸어 사람 확인을 받게 합니다.
패턴 5 — 같은 실패를 종료 조건 없이 반복한다
검증에 실패하면 다시 시도하도록 만들어 놓았는데, 몇 번 만에 멈출지를 정하지 않은 경우입니다. 에이전트는 같은 방법으로 같은 실패를 반복하며 토큰과 시간을 소모합니다.
원인은 대개 실패 정보가 다음 시도에 전달되지 않는 데 있습니다. "실패했으니 다시 하세요"만 전달하면 모델은 같은 계획을 다시 세웁니다. 무엇이 왜 실패했는지를 함께 넣어야 다른 시도를 합니다.
대응은 두 가지를 함께 두는 것입니다. 최대 시도 횟수를 정하고, 실패 사유를 다음 회차 입력에 포함시킵니다. 그리고 한도에 도달했을 때는 조용히 끝내지 말고 "왜 멈췄는지"를 사람에게 넘깁니다. 실패를 성공처럼 반환하는 것이 반복 자체보다 위험합니다.
증상만 보고 어느 패턴인지 가려내려면?
실패를 만났을 때 다섯 개 중 무엇인지 빨리 좁히는 것이 중요합니다. 로그에 남는 증상과 패턴은 대체로 다음과 같이 대응합니다.
| 눈에 보이는 증상 | 의심할 패턴 | 먼저 확인할 것 |
|---|---|---|
| 실행 시간이 매번 크게 다르다 | 1 (범위 폭발) | 목표에 완료 조건이 있는가 |
| 완료라는데 결과물이 없다 | 2 (자기 보고) | 코드가 결과를 확인하는가 |
| 초반엔 잘하다 후반에 규칙을 어긴다 | 3 (맥락 초과) | 회차별 입력 길이 추이 |
| 오류 없이 결과만 엉뚱하다 | 4 (도구 오용) | 어느 도구를 골랐는지 로그 |
| 같은 오류 메시지가 반복된다 | 5 (무한 반복) | 실패 사유가 다음 회차에 전달되는가 |
가장 헷갈리는 조합은 2와 4입니다. 둘 다 오류 없이 잘못된 결과가 나오기 때문입니다. 구분하려면 도구 호출 로그를 보면 됩니다. 호출 자체가 없었다면 2번이고, 호출은 있었는데 엉뚱한 것을 골랐다면 4번입니다. 이래서 회차별 도구 호출 기록이 남아 있어야 합니다. 기록이 없으면 다섯 패턴 중 무엇인지 추측할 수밖에 없습니다.
다섯 패턴을 한 번에 줄이는 습관
각 패턴마다 대응이 다르지만, 설계 단계에서 세 가지를 적어 두면 다섯 개 모두가 눈에 띄게 줄어듭니다.
| 적어 둘 것 | 막아 주는 패턴 |
|---|---|
| 완료 조건 (참·거짓으로 판정되는) | 1, 2 |
| 중단 조건 (최대 시도 횟수와 중단 사유) | 5 |
| 권한 범위 (읽기·쓰기·되돌리기 어려운 행동) | 4 |
여기에 매 회차 맥락을 요약해서 넣는 습관을 더하면 패턴 3까지 덮입니다. 세 줄을 먼저 적는 것이 실패를 사후에 디버깅하는 것보다 훨씬 저렴합니다. 기본 설계 순서는 AI 에이전트 시작하기에서 확인하실 수 있습니다.
FAQ
-
Q. 더 좋은 모델을 쓰면 이 실패들이 사라지나요?
- A. 줄어들지만 사라지지는 않습니다. 다섯 패턴 중 목표 모호성·검증 부재·종료 조건 부재는 모델이 아니라 설계의 문제이므로, 모델을 바꿔도 그대로 남습니다.
-
Q. 어느 패턴부터 손봐야 하나요?
- A. 패턴 2입니다. 검증이 없으면 나머지 실패가 언제 일어났는지조차 알 수 없기 때문입니다. 검증을 붙여 실패가 보이기 시작한 뒤에 나머지를 순서대로 다루면 됩니다.
-
Q. 에이전트를 여러 개 쓰면 서로 검증해 주지 않나요?
- A. 부분적으로만 그렇습니다. 검증 역할을 맡은 에이전트도 같은 다섯 패턴에 똑같이 노출되며, 특히 자기 보고 문제는 그대로 남습니다. 여러 개를 쓰는 경우의 운영 방법은 멀티에이전트 운영법에서 다룹니다.
정리
- 에이전트 실패는 대개 다섯 가지입니다 — 범위 폭발, 자기 보고, 맥락 초과, 도구 오용, 무한 반복.
- 가장 위험한 것은 하지 않은 일을 했다고 보고하는 패턴 2입니다. 검증을 모델 바깥에 두는 것으로 막습니다.
- 후반에 갑자기 지시를 어기기 시작한다면 맥락 초과를 먼저 의심하세요.
- 도구는 적을수록 정확해집니다. "언제 쓰면 안 되는지"를 설명에 함께 적습니다.
- 완료 조건·중단 조건·권한 범위 세 줄을 먼저 적으면 다섯 패턴 대부분이 사전에 걸러집니다.