생성형 AI 도구를 활용하여 작성 및 편집된 노트입니다.
IBM·버클리의 IT-Bench·MAST로 본 엔터프라이즈 에이전트 실패 원인
최근 IBM과 UC Berkeley가 “왜 기업용 에이전트가 현장에서 자주 무너지는가”를 IT-Bench와 MAST(멀티에이전트 실패 분류체계)로 진단했다는 소식이 나왔습니다1. 핵심은 단순히 모델 성능이 부족해서가 아니라, 여러 에이전트가 협업할 때 생기는 설계·소통·검증의 틈이 실패를 만든다는 점입니다. 이 글에서는 MAST를 중심으로, 멀티에이전트 시스템(MAS)이 왜 흔들리는지와 실무에서 줄이는 방법을 정리해볼게요.
MAST가 알려주는 ‘실패의 지도’: 설계·정렬·종료
MAST는 멀티에이전트 실패를 “에이전트를 늘렸는데 왜 더 불안정해졌지?”라는 질문에 답하려고 만든 체크리스트에 가깝습니다. 특히 실패가 많이 나는 구간을 세 덩어리로 나누는데, 첫째는 요구사항과 시스템 설계 문제(가장 큰 비중), 둘째는 에이전트 사이의 엇박자, 셋째는 검증과 종료(끝맺음) 문제입니다2.
현장에서 가장 자주 보는 장면은 ‘역할 붕괴’입니다. 예를 들어 리서치 담당이 갑자기 실행 결정을 내려버리거나, 실행 담당이 스스로 범위를 넓혀 다른 팀의 작업까지 건드립니다. 여기서부터는 사람 팀에서도 사고가 나듯, 에이전트 팀도 연쇄적으로 꼬입니다. 또 하나는 ‘반복 루프’인데, 이미 끝낸 단계를 계속 되풀이해 토큰과 시간을 태우고 결국 목표를 놓칩니다2. 마지막으로 ‘기억 소실’도 흔합니다. 대화 히스토리가 길어지며 중요한 전제가 뒤로 밀리고, 어느 순간 처음부터 다시 시작하는 듯한 행동을 하죠.
“에이전트 수를 늘리면 좋아진다”는 착각과 17배 증폭
멀티에이전트는 원래 “나눠서 정복(divide and conquer)”이 매력입니다. 하지만 잘못 나누면 “나눠서 사고(divide and confuse)”가 됩니다. 최근 연구 흐름에서도 ‘가방에 에이전트만 잔뜩 넣는 방식(bag of agents)’은 오히려 오류가 크게 증폭될 수 있다고 경고합니다. 한 분석에서는 이런 무구조 협업이 최대 17.2배 오류 증폭으로 이어질 수 있다고 소개합니다3.
왜 이런 일이 생길까요? 메시지가 손에서 손으로 옮겨갈 때, 작은 환각이나 누락이 “사실”로 굳어지기 때문입니다. 리서치 에이전트가 애매하게 말한 문장이 실행 에이전트에게는 확정된 요구사항처럼 해석되고, 그 결과물이 다시 검증 에이전트의 ‘표면적 체크’를 통과해 버리면, 시스템은 틀린 답을 완성품처럼 종료합니다. 즉, 멀티에이전트의 적은 ‘모델’보다 ‘핸드오프’입니다.
에이전트가 망하는 진짜 지점: 메시지 인수인계(Edge)
실패를 “에이전트 내부”가 아니라 “에이전트 사이 연결(엣지)”에서 보자는 주장도 힘을 얻고 있습니다. AgentAsk라는 연구는 협업 실패의 상당수가 메시지 인계 구간에서 생기는 네 가지 문제—정보가 비어 있음(Data Gap), 신호가 오염됨(Signal Corruption), 지시 대상이 흐려짐(Referential Drift), 능력 한계(Capability Gap)—로 설명합니다4. 요지는 간단합니다. 제대로 묻지 않아서 망한다는 것.
사람 팀은 애매하면 묻습니다. 하지만 에이전트는 종종 ‘그럴듯하게 진행’해버립니다. 그래서 실무적으로는 “질문을 잘하는 모듈”이 의외로 강력한 안전장치가 됩니다. 예를 들어 실행 전에 “성공 조건이 뭐야?”, “필수 입력이 빠졌어. 무엇을 확인할까?” 같은 최소한의 확인 질문만 강제해도, 폭발적인 연쇄 오류를 끊는 데 도움이 됩니다4.
시사점: 엔터프라이즈 에이전트 성공률을 올리는 4가지 습관
첫째, 멀티에이전트는 ‘구성도’가 제품입니다. IBM이 정리한 것처럼 MAS는 여러 에이전트가 서로의 목표·메모리·계획을 고려하며 협력할 때 의미가 있고, 그때부터 통신 구조(중앙집중/분산/계층형 등)가 품질을 좌우합니다5. 즉 “몇 명이냐”보다 “누가 누구에게 무엇을 어떤 형식으로 보고하냐”가 먼저입니다.
둘째, 역할 문장을 길게 쓰지 말고, 산출물 정의를 짧게 박으세요. “리서치해줘” 대신 “출처 3개, 상충점 1개, 결론 1문장”처럼 결과물을 못 박으면 역할 이탈이 줄어듭니다.
셋째, 검증은 ‘컴파일 체크’가 아니라 ‘비즈니스 조건 체크’여야 합니다. MAST가 지적하는 것처럼 검증 에이전트가 형식만 확인하면, 틀린 방향의 완성도를 높이는 꼴이 됩니다2. 종료 조건(언제 멈추나)도 같이 적어두면 무한 루프를 줄일 수 있어요.
넷째, “애초에 단일 에이전트로 70~80점 나오는 일”은 멀티에이전트가 독이 될 수 있습니다. 협업 오버헤드와 문맥 오염이 이득을 갉아먹기 때문입니다. 멀티에이전트는 정말로 분업이 필요한 복잡 작업, 그리고 검증 가능한 워크플로우에서만 쓰는 게 안전합니다.
참고
1IBM and UC Berkeley Diagnose Why Enterprise Agents Fail Using IT-Bench and MAST
2Why do Multi Agent LLM Systems Fail? The Scaling Myth Exposed
3Why Your Multi-Agent System is Failing: Escaping the 17x Error Trap of the “Bag of Agents”