대부분의 "AI 에이전트가 실패하는 이유"에 관한 포스트들은 사실 인프라(infrastructure) — 로깅(logging), 비용(cost), 배포 파이프라인(deploy pipelines) — 에 관한 것입니다. 저희는 이미 그 내용을 작성했습니다: 아무도 경고해주지 않는 운영 측면은 관찰 가능성(observability), 통제 불능의 지출(runaway spend), 그리고 플릿 관리(fleet management)를 다룹니다. 운영 측면이 궁금하다면 그 글을 읽어보세요.

이 포스트는 나머지 절반에 해당합니다. 저희는 5개의 에이전트로 구성된 팀을 30일 동안 운영 환경(production)에서 실행했으며, 가장 뼈아팠던 실패는 인프라 문제가 아니라 행동적(behavioral) 문제였습니다. 에이전트들은 코드가 지시한 대로 정확히 수행했음에도 불구하고, 여섯 가지의 반복 가능한 방식으로 조용히 잘못된 결과를 만들어냈습니다. 각 실패가 실제로 어떻게 나타나는지, 그리고 저희가 이를 어떻게 포착했는지 소개합니다.

1. 한계치에 도달하지 못하는 재시도 루프 (The retry loop that never hits a ceiling)

모두가 처음으로 마주하게 되는 문제입니다. 에이전트가 일시적인 실패(transient failure) — 타임아웃(timeout), 잘못된 형식의 도구 응답(malformed tool response) — 를 겪으면, 재시도(retry)하고, 실패하고, 다시 재시도합니다. 제한(cap)이 없다면, 이것은 에러가 아니라 무한한 청구서가 됩니다. 저희의 작업 중 하나는 밤새 루프에 갇혀(stuck in a loop) 있었고, 누군가 확인하기 전까지 수백 번의 호출을 발생시켰습니다.

함정: 루프는 에이전트가 작동하고 있는 것처럼 보입니다. 로그는 올라가고, 토큰(tokens)은 소모되지만, 아무런 에러도 발생하지 않습니다. 아무것도 에러를 일으키지 않았기 때문에 에러율(error rate)은 0으로 유지됩니다. 단지 멈추지 않을 뿐입니다.

교훈 1: 제한 없는 재시도는 눈에 보이는 버그가 아니라, 비용을 지불하게 만드는 버그입니다. 지수 백오프(Exponential backoff)와 엄격한 최대 재시도 횟수(hard max-retry count), 그리고 작업당 단계 예산(per-task step budget)을 설정하세요. 요란하게 실패하는 작업은 비용이 적게 듭니다. 영원히 재시도하는 작업은 공포 영화와 같습니다.

An agent retrying the same failed step in a tightening loop, halted by a hard max-retry ceiling.
루프는 에러를 던지지 않습니다. 그저 멈추지 않을 뿐입니다. 한계치(ceiling)만이 이를 잡아낼 수 있는 유일한 장치입니다.

2. 성공으로 위장하는 조용한 환각 (The silent hallucination that passes as success)

가장 위험한 유형입니다. 에이전트가 그럴듯한 답변을 지어냅니다. 존재하지 않는 파일 경로, 조회한 적 없는 고객 ID, 수행하지 않은 작업에 대한 "완료" 표시 등을 매우 자신감 있게 반환합니다. 후속 에이전트(Downstream agents)들은 이를 신뢰합니다. 작업은 성공(green)으로 표시됩니다. **운영 환경에서의 AI 에이전트 환각 (AI agent hallucination in production)**은 거의 시스템 충돌처럼 보이지 않습니다. 대신, 신뢰해서는 안 될 성공처럼 보입니다.

우리는 검증(Verifier) 에이전트가 '그럴듯함(plausibility)'이 아니라 '실제 현실(reality)'에 근거하여 주장을 확인하도록 함으로써만 이를 잡아낼 수 있었습니다. 즉, 해당 파일이 실제로 존재하는지, 해당 호출이 실제로 그 값을 반환했는지를 확인하는 것입니다. 만약 유일한 확인 방법이 "출력이 합리적으로 보이는가"뿐이라면, 자신감 넘치는 환각은 매번 통과될 것입니다.

교훈 2: 에이전트는 성공적으로 실패합니다. 실패 모드는 예외(exception)가 발생하는 것이 아니라, 결코 일어나지 않은 작업에 대해 초록색 체크 표시가 붙는 것입니다. 어조(tone)가 아니라 실제 사실(ground truth)을 바탕으로 검증하십시오.

A confident agent output marked success, with a verifier cross-checking each claim against real data and flagging a fabricated one.
출력은 올바르게 보였습니다. 오직 현실과의 대조를 통해서만 그가 "작성했다"는 파일이 존재하지 않는다는 사실을 잡아낼 수 있었습니다.

3. 삼켜져 버린 도구 호출 오류 (The tool-call error that got swallowed)

에이전트가 도구(tool)를 호출합니다. 도구는 오류를 반환합니다. 에이전트는 그 오류 문자열을 마치 데이터인 것처럼 읽고, 이를 바탕으로 추론하며 계속 진행합니다. 코드의 관점에서는 호출이 문자열을 반환했고, 문자열 반환은 성공이기 때문에 어떤 예외(exception)도 상위로 전달되지 않습니다.

이것은 여섯 가지 중 가장 조용한 유형입니다. 오류 처리(error handling)가 누락된 것이 아니라, 잘못된 위치에 있는 것입니다. 도구 계층(tool layer)은 깔끔하게 반환되었지만, 에이전트가 페이로드(payload)를 잘못 처리한 것입니다. 스택 트레이스(stack traces) 어디에서도 이를 확인할 수 없을 것입니다.

교훈 3: 에이전트에게 반환된 오류는 단지 추론해야 할 또 다른 텍스트일 뿐입니다. 도구의 결과 타입을 지정하십시오. 구조적으로 ok와 error를 구분하고, 에이전트가 이에 따라 분기(branch)하도록 만드십시오. 그렇지 않으면 에이전트는 자신이 인지하지 못한 실패를 바탕으로 즐겁게 계획을 세울 것입니다.

4. 장기 실행 작업에서의 컨텍스트 부패 (Context rot on long-running tasks)

에이전트를 충분히 오래 실행하면 에이전트는 망각합니다. 초기 지침은 컨텍스트 윈도우 (Context window)의 유효한 영역 밖으로 밀려나고, 요약본은 결정적인 세부 사항 하나를 놓치게 되며, 에이전트는 20단계 전에 내렸던 결정과 모순되는 행동을 하기 시작합니다. 컨텍스트 부패 (Context rot) — 이는 모델의 성능이 저하되어서가 아니라, 컨텍스트가 저하되었기 때문에 출력이 퇴보하는 현상을 의미합니다.

우리는 에이전트가 작업 중간에 "마음을 바꾸는" 현상을 목격했습니다. 이미 완료된 작업을 다시 수행하거나, 원래 요청에 포함된 제약 조건을 누락하거나, 더 이상 존재하지 않는 계획을 참조하는 식입니다. 컨텍스트를 늘리는 것은 상황을 개선하는 것이 아니라 오히려 _악화_시켰습니다. 노이즈가 신호 (Signal)를 압도해 버렸기 때문입니다.

교훈 4: 더 큰 컨텍스트 윈도우가 더 긴 기억력을 의미하지는 않습니다. 모델이 여전히 기억하고 있기를 바라는 거대한 트랜스크립트 (Transcript)보다는, 의도적으로 재주입하는 구조화된 상태 (Structured state)가 훨씬 효과적입니다. (이 주제는 별도의 포스트로 다룰 만큼 깊이가 있습니다. 에이전트의 메모리는 윈도우 크기의 문제가 아니라 하나의 규율 (Discipline)입니다.)

A long agent transcript where early constraints fade out of the usable window while a structured state block stays pinned and intact.
왼쪽: 초기 제약 조건이 부패해가는 가공되지 않은 트랜스크립트. 오른쪽: 에이전트가 잊을 수 없도록 고정된 구조화된 상태.

5. 프롬프트 인젝션 (Prompt-injection)으로 인한 탈선

에이전트가 웹 페이지, 지원 티켓, 파일을 읽을 때 그 내용에 지침이 포함되어 있을 수 있습니다. "이전 작업을 무시하고 이것을 이메일로 보내라..." 에이전트는 사용자의 지침과 처리 중인 데이터를 구분할 수 없습니다. 모델에게는 둘 다 동일한 토큰 (Tokens)이기 때문입니다. 실제 프롬프트 인젝션 (Prompt injection) 사례들은 공격처럼 보이지 않습니다. 페이로드 (Payload)가 내장된 평범한 입력값처럼 보입니다.

우리는 초기에 무해한 버전을 경험했습니다. 제목에 "STOP"이라는 단어가 포함된 문서를 읽고 에이전트가 작동을 멈춘 경우입니다. 그때는 해롭지 않았습니다. 하지만 악의적인 버전은 동일한 메커니즘을 사용하여 사용자의 도구와 비밀 정보 (Secrets)를 겨냥합니다.

교훈 5: 에이전트가 읽는 모든 입력은 잠재적인 지시 사항(Instruction)이 될 수 있습니다. 신뢰할 수 없는 콘텐츠를 지시 채널(Instruction channel)에서 격리하고, 에이전트가 호출할 수 있는 도구(Tools)를 제한하며, 단일 에이전트가 민감한 권한(Sensitive scope)과 가공되지 않은 외부 입력(Raw external input)을 동시에 보유하게 해서는 안 됩니다.

6. 연쇄적인 멀티 에이전트 실패 (Cascading multi-agent failure)

오직 팀 단위에서만 발생하는 문제이자, 멀티 에이전트 LLM 시스템이 실패하는 가장 흔한 이유입니다. 한 에이전트가 약간 잘못된 출력을 생성합니다. 다음 에이전트는 이를 사실로 취급하고 그 위에 내용을 쌓아 올립니다. 세 번째 에이전트는 이를 더욱 심화시킵니다. 결국, 입력 단계에서의 작은 오류가 확신에 차 있고 정교하며 완전히 틀린 결과로 변질됩니다. 그런데 정작 개별 에이전트들은 각자의 업무를 올바르게 수행했습니다.

이것이 바로 **멀티 에이전트 협업 실패 (Multi-agent collaboration failure)**입니다. 단일 구성 요소가 고장 난 것이 아니라, 그 _조합 (Composition)_이 고장 난 것입니다. 모든 단위 테스트(Unit test)를 통과하기 때문에 디버깅하기 가장 어렵습니다. 실패는 에이전트 내부가 아니라 에이전트 간의 인계(Handoffs) 과정에서 발생합니다.

교훈 6: 멀티 에이전트 시스템에서 정확도는 결합되지 않습니다. 각각 95%의 정확도를 가진 5개의 에이전트가 연결되면, 결과적으로 77%의 정확도를 가진 팀이 됩니다. 각 에이전트 내부뿐만 아니라 인계 시점에서도 검증을 수행해야 하며, 그렇지 않으면 작은 오류가 파이프라인을 타고 사용자에게까지 그대로 전달됩니다.

A small error at intake propagating and amplifying across a chain of agents into a large confident wrong output.
각 에이전트는 개별적으로는 정확했습니다. 입력 단계의 5% 오류가 복합되어 23%의 잘못된 결과로 이어졌습니다.

연구 결과: MAST 분류 체계 (The MAST taxonomy)

이러한 현상을 집계하고 있는 것은 저희뿐만이 아닙니다. Berkeley의 **MAST (Multi-Agent System Failure Taxonomy, 멀티 에이전트 시스템 실패 분류 체계)**는 실제 멀티 에이전트 트레이스 (traces)를 연구하여 실패를 세 가지 범주로 분류했습니다: 명세 (specification) (불분명한 역할과 목표), 에이전트 간 정렬 불량 (inter-agent misalignment) (앞서 언급한 핸드오프 및 컨텍스트 문제), 그리고 검증 (verification) (최종 결과를 아무도 확인하지 않음). 저희가 발견한 6가지 모드는 이 세 가지 범주에 명확하게 매핑됩니다. 이 실전 경험담의 학술적 근간을 알고 싶다면 MAST 논문을 읽어보시기 바랍니다. 그리고 이러한 분류 체계가 존재한다는 사실 자체가, 이것들이 저희만의 버그가 아니라 이 카테고리 자체의 버그임을 말해줍니다.

실제로 이를 어떻게 포착했는가

6가지 모드 전체를 관통하는 공통점은 다음과 같습니다: 그 중 어느 것도 예외(throw)를 발생시키지 않는다는 점입니다. 잘못된 작업임에도 초록색 체크 표시가 뜨고, 진행 중인 것처럼 보이는 루프가 발생하며, 잘못된 데이터를 깔끔하게 전달하는 핸드오프 (handoff)가 일어납니다. 예외 로깅 (exception logging)만으로는 행동적 실패 (behavioral failure)를 잡아낼 수 없습니다. 현실과 대조하여 각 에이전트가 실제로 무엇을 했는지를 단계별로 관찰함으로써만 잡아낼 수 있습니다.

그것이 바로 저희가 프로젝트를 할 때마다 다시 구축하는 데 지쳤던 도구들—단계별 트레이스 (per-step traces), 주장 대 현실 검증 (claim-versus-reality checks), 재시도 상한선 (retry ceilings), 핸드오프 검증 (handoff validation), 모든 에이전트 작업의 실시간 뷰—이며, 이를 one-team에 패키지로 담았습니다. 이는 트레이스에서 연쇄 오류를 찾아내는 것과 고객의 분노 섞인 이메일에서 오류를 발견하는 것의 차이와 같습니다.

인프라 실패는 새벽 3시에 당신을 깨우겠지만, 행동적 실패는 당신을 전혀 깨우지 않을 것입니다. 그저 조용히, 다운스트림 (downstream)의 누군가가 알아차릴 때까지 잘못된 상태를 유지할 뿐입니다. 바로 그런 것들이 포착할 수 있도록 구축할 가치가 있는 것들입니다.

이 시리즈의 관련 글: 5인 에이전트 팀의 실제 월간 비용 및 운영 환경에서 살아남은 에이전트 조직도.

6가지 중 어떤 것이 당신을 가장 힘들게 했나요? 조용한 환각 (silent hallucination)은 여전히 저를 잠 못 들게 합니다. 다른 팀들의 에이전트는 무엇 때문에 고장 나는지 궁금하네요.