에이전트 파이프라인이 망하는 건 설계를 몰라서가 아니다

멀티에이전트 파이프라인을 설계할 때 대부분의 팀은 무엇을 해야 하는지 이미 알고 있다. Validation Gate, Checkpoint, Plan-and-Execute, HITL. 문제는 이것들을 언제 넣고 언제 빼야 하는지, 그리고 잘못 넣으면 어떻게 더 나빠지는지를 모른다는 데 있다.

1. 검증 게이트는 추가할수록 좋은가

직관적으로는 그렇다. 각 단계 출력을 검증하면 오류가 다음 단계로 넘어가지 않는다. 그런데 실제로는 게이트 자체가 새로운 실패 지점이 된다.

게이트는 두 방향으로 실패한다. False negative — 잘못된 출력을 통과시킨다. False positive — 맞는 출력을 막는다. LLM-as-Judge 기반 게이트는 특히 후자가 문제다. Judge 모델의 편향이 곧 게이트의 편향이 되고, 특정 출력 패턴을 체계적으로 차단한다. 같은 모델로 생성하고 같은 모델 계열로 평가하면 이 편향이 더 강해진다.

게이트를 추가해야 하는 조건은 두 가지다.

다음 단계가 잘못된 입력을 스스로 감지할 수 없을 때. 다음 에이전트가 어떤 입력이 들어와도 그럴듯한 출력을 내놓는다면, 오류는 조용히 통과된다. 이 지점에 게이트가 필요하다.

이후 액션이 되돌리기 어려울 때. 외부 API 호출, DB 쓰기, 이메일 발송 직전이라면 비용이 높은 검증도 정당화된다. 반대로, 이후 단계에서 언제든 수정 가능한 중간 결과물이라면 게이트를 건너뛰는 게 낫다.

두 조건 중 하나도 해당하지 않는다면, 게이트는 비용만 추가하고 실패 표면만 늘린다.

2. 재시도는 의미론적 실패를 고치지 못한다, 오히려 강화한다

API 오류에 재시도가 효과적이기 때문에, 팀은 같은 패턴을 모든 실패에 적용하는 경향이 있다. 그런데 의미론적 실패 — 형식은 맞지만 내용이 틀린 경우 — 에 재시도를 걸면 상황이 나빠진다.

LLM은 같은 프롬프트에 같은 오류를 반복할 가능성이 높다. 더 나쁜 경우, 재시도 결과를 컨텍스트에 추가하면 모델은 이전 잘못된 출력을 참조 지점으로 삼아 다음 시도를 "개선"한다. 오류가 반복되는 것이 아니라 정교해진다.

실패 유형을 구분하지 않고 재시도를 설계하면 결국 이런 라우팅 표가 필요하다.

실패 유형	재시도 효과	올바른 전략
일시적 (rate limit, timeout)	효과적	지수 백오프 + max_retry 상한
반복적 서비스 불능	효과 없음, 비용 누적	서킷 브레이커 + 폴백
의미론적 (환각, 잘못된 추론)	역효과 가능	프롬프트 변형 또는 모델 교체
묵시적 (목표 이탈, 루프)	감지 자체가 문제	Trajectory 감시 에이전트

특히 묵시적 실패는 재시도 전략 자체가 의미 없다. 시스템이 태스크를 완료했다고 판단하고 있기 때문이다. 이 유형은 별도의 감시 레이어가 없으면 재시도 조건 자체가 발동되지 않는다.

3. Plan-and-Execute는 계획이 틀렸을 때 더 위험하다

Plan-and-Execute가 ReAct보다 긴 체인에서 안정적인 것은 맞다. 그런데 이 구조의 핵심 전제는 초기 계획이 충분히 옳다는 것이다.

계획이 틀렸을 때 문제는 ReAct보다 커진다. ReAct는 매 스텝마다 방향을 조정할 수 있지만, Plan-and-Execute에서 Executor는 잘못된 계획을 충실히 수행한다. 그리고 계획 수준의 오류는 각 Executor 단계의 로그에서 보이지 않는다. 개별 실행은 성공이지만 전체 방향이 틀렸다.

Plan-and-Execute를 선택하기 전에 확인해야 할 조건이 있다.

도메인이 충분히 예측 가능한가. 실행 중에 계획을 무효화하는 외부 상태 변화가 자주 발생하는 도메인이라면, 사전 계획보다 즉흥 조정이 더 유리하다.

계획의 품질을 검증하는 단계가 있는가. Executor가 시작하기 전에 Planner의 출력을 독립적으로 검토하는 과정이 없다면, 잘못된 계획이 전체 체인을 오염시킨다.

계획 이탈을 감지하는 메커니즘이 있는가. 실행 중에 현재 진행이 초기 계획과 얼마나 일치하는지 주기적으로 확인하는 구조가 없다면, 드리프트를 늦게 잡는다.

이 세 가지를 갖추지 않은 상태에서 Plan-and-Execute를 쓰면, 실패 탐지가 ReAct보다 오히려 늦어진다.

4. 태스크를 잘게 쪼갤수록 정렬 실패가 늘어난다

분해 단위를 작게 가져가면 각 에이전트의 역할이 명확해지고 테스트하기도 쉽다. 그런데 경계가 늘어날수록 에이전트 간 계약 불일치가 생길 지점도 늘어난다.

경계 하나마다 세 가지 암묵적 계약이 있다. 입력 스키마, 추상화 수준, 그리고 실패했을 때의 기대 동작. 이 셋이 맞지 않으면 B 에이전트는 A의 출력을 자기 방식으로 해석하고 진행한다. 개별 에이전트는 정상인데 파이프라인이 어긋나는 이유다.

1,600개 이상의 멀티에이전트 실행 트레이스를 분석한 MAST 연구에서 가장 빈번한 단일 실패 원인이 에이전트 간 정렬 실패였던 것도 이 때문이다. 경계 수는 정렬 실패 가능성과 선형 비례한다.

분해 수준 결정 기준은 이렇게 단순화할 수 있다. 독립적으로 테스트 가능하면서, 인터페이스 계약이 명시적으로 정의 가능한 최소 단위가 적정 분해 수준이다. 이보다 작으면 경계 비용이 실행 비용보다 커진다.

5. 체크포인트 단위는 재실행 비용으로 결정한다

"단계마다 저장하라"는 원칙은 맞다. 그런데 무엇을 저장하고 어느 단위로 저장할지는 재실행 비용을 보고 결정해야 한다.

체크포인트가 너무 세밀하면 두 가지 문제가 생긴다. 저장 비용이 실행 비용을 초과할 수 있다. 그리고 상태가 너무 많아지면 어떤 체크포인트가 "신뢰할 수 있는 복구 지점"인지 판단하기 어려워진다.

기준은 이렇다. 해당 단계를 다시 실행하는 비용이 체크포인트를 저장하는 비용보다 높을 때 저장한다. LLM 추론, 외부 API 호출, 수 분이 걸리는 배치 처리가 여기 해당한다. 단순한 포맷 변환이나 필터링은 다시 실행하는 게 저장하는 것보다 빠를 수 있다.

그리고 복구 시에 중요한 것이 하나 있다. 복구 지점으로 사용하는 참조는 반드시 절대적이어야 한다. 상대 참조(HEAD~1)는 중간 상태가 바뀌었을 때 다른 지점을 가리키게 된다. 복구라고 생각하고 실행했는데 다른 상태로 진입하는 원인이 여기서 나온다.

6. HITL은 넣을수록 좋지 않다

HITL은 안전망처럼 보이기 때문에 팀이 리스크를 느낄 때마다 넣으려는 유인이 생긴다. 그런데 HITL이 많아지면 두 가지 문제가 생긴다.

첫째, 운영자 피로다. 검토 요청이 너무 자주 오면 사람은 내용을 보지 않고 승인한다. HITL이 있는 것처럼 보이지만 실질적으로는 없는 것과 같다.

둘째, HITL 자체가 병목이 된다. 빠른 처리가 필요한 파이프라인에서 사람의 응답을 기다리는 시간은 전체 레이턴시를 지배한다.

HITL이 실질적으로 의미를 갖는 조건은 세 가지다.

액션이 되돌리기 어렵거나 외부에 영향을 준다. 이메일 발송, 계약서 제출, 결제 처리 같은 경우다.
에이전트의 판단 신뢰도가 일정 기준 이하로 떨어졌다. Confidence score나 trajectory divergence가 임계치를 넘었을 때다.
처음 보는 입력 패턴이다. 학습 데이터나 이전 실행에서 본 적 없는 케이스다.

이 세 조건 중 하나도 해당하지 않는다면, HITL은 비용만 추가하고 실질적 안전은 제공하지 않는다.

7. 컨텍스트 압축은 정보 손실이다, 관리 방식이 아니다

긴 체인에서 컨텍스트가 무거워지면 "요약해서 압축하면 된다"는 접근이 자연스럽게 나온다. 그런데 요약은 항상 손실이다. 문제는 압축 시점에 어떤 정보가 이후에 필요해질지 알 수 없다는 것이다.

실제로 자주 발생하는 패턴이 있다. 5단계에서 압축할 때 7단계에서 다시 필요한 컨텍스트를 날린다. 7단계 에이전트는 이 정보가 없다는 사실을 모르고 추론을 진행한다. 오류가 생기는데 원인이 5단계 압축이었다는 것은 로그를 역추적해야 알 수 있다.

컨텍스트 관리의 더 나은 접근은 압축이 아니라 외부화다. 중요한 상태는 압축하지 말고 외부 메모리에 명시적으로 저장한다. 이후 단계가 필요할 때 조회할 수 있게 한다. 무엇이 현재 컨텍스트 안에 있는지가 아니라, 무엇이 조회 가능한지가 기준이 되어야 한다.

그리고 컨텍스트를 외부화할 때 중요한 부분이 있다. 저장된 정보에 신뢰도와 출처를 함께 기록해야 한다. 외부 메모리에 오염된 정보가 들어가면, 이후 모든 단계가 오염된 사실을 조회 가능한 진실로 취급한다.

결국 어디서 시간을 써야 하는가

이 모든 결정의 공통점이 있다. 신뢰성을 높이는 데 쓸 수 있는 자원은 한정되어 있고, 그 자원을 어디에 집중하느냐가 실제 결과를 만든다.

경험적으로 투자 대비 효과가 높은 순서는 이렇다.

에이전트 간 계약 명시화. 인터페이스 스키마, 추상화 수준, 실패 동작을 명시적으로 정의하는 것이 가장 싸고 효과가 크다. 대부분의 정렬 실패는 이 계약이 암묵적이라서 생긴다.

되돌리기 어려운 액션 앞 게이트. 모든 단계에 게이트를 넣는 것이 아니라, 이후에 수정이 어려운 단계 앞에만 넣는다. 비용 대비 리스크 감소가 가장 크다.

실패 유형별 복구 라우팅. 단일 재시도 정책이 아니라, 실패 유형을 먼저 분류하고 유형에 맞는 전략을 선택하는 라우팅 테이블을 갖는다.

Trajectory 수준 감시. 개별 단계 로그가 아니라, 전체 실행 경로가 초기 의도와 얼마나 일치하는지를 주기적으로 확인하는 레이어다. 묵시적 실패는 여기서만 잡힌다.

더 좋은 모델, 더 정교한 프롬프트, 더 많은 검증 게이트보다 이 네 가지를 먼저 갖추는 것이 실제 파이프라인 신뢰성에 더 크게 기여한다.

참고

Why Do Multi-Agent LLM Systems Fail? — MAST (arXiv:2503.13657)
Detecting Silent Failures in Multi-Agentic AI Trajectories (arXiv:2511.04032)
Plan-and-Act: Improving Planning for Long-Horizon Tasks (arXiv:2503.09572)
Advancing Agentic Systems: Dynamic Task Decomposition (arXiv:2410.22457)
Towards a Science of AI Agent Reliability (arXiv:2602.16666)