멀티 에이전트 시스템을 구축하며 겪은 5가지 실수, 여러분도 아마 겪게 될 겁니다
i made these 5 mistakes while building my multi-agent system, You probably will too
핵심 요약
AI 에이전트의 실패 원인은 모델이 아니라 잘못된 검색과 접지(grounding) 부족에 있다는 경험담입니다.
- 검색 최적화 — 단순 유사도 검색 대신 하이브리드 검색과 문맥 순위 지정이 필수임
- 근거 기반 답변 — 답변의 근거를 찾을 수 없을 때는 에이전트가 답변하지 않도록 제한해야 함
- 에이전트 실패 원인 — 모델 자체의 문제보다 데이터 연결과 검색 과정의 오류가 주된 원인임
- 성능 지표 개선 — 답변 근거를 강제함으로써 에스컬레이션 비율을 낮추고 고객 만족도를 높임
방금 고객 지원 에이전트 작업을 마쳤음. 솔직히 말해서, 꽤 오랫동안 나도 결국 모델이나 프롬프트, 아니면 프레임워크 문제 탓을 하게 될 줄 알았음. 하지만 오랫동안 작업해 본 결과, 결정적인 요인은 그런 게 아니라 모든 것을 연결하는 방식과 검색(retrieval)이라는 확신이 들었음. 아키텍처 다이어그램상으로는 깔끔해 보이지만, 실제 운영 환경에서는 정말 엉망이 되거든. 임의의 사용자 질문이 임의의 데이터에 부딪히면, 단순한 유사도 검색에 의존할 경우 잘못된 문맥을 가져오게 됨. 그리고 무서운 점은 그 답변이 여전히 그럴듯하게 들린다는 거지.
그래서 나는 프롬프트에 집착하는 걸 서서히 멈추고 검색에 훨씬 더 많은 시간을 쏟았음. 하이브리드 검색, 문맥 순위 지정, 증거 태깅이 일상이 됐지. 그런 것들이 없으면 에이전트는 결국 환각(hallucination)을 일으키며 지원 업무를 악몽으로 만들어버림. 이런 접지(grounding) 확인 절차들을 귀찮아서 안 했더니 내 멀티 에이전트 LLM은 계속 실패했음.
1/ 커버리지 비율. 검색된 문맥이 실제로 관련이 있는 빈도는 얼마나 되는가?
2/ 증거 정렬. 모든 답변을 뒷받침하는 텍스트로 추적할 수 있는가?
3/ 최신성. 6개월 전에 보관된 문서가 아니라 최신 문서를 가져오고 있는가?
4/ 노이즈 필터링. 거대한 문서 속에 파묻힌 관련 없는 덩어리들을 무시할 수 있는가?
5/ 에스컬레이션 임계값. 모르는 척을 멈추고 대화를 사람에게 넘겨야 할 때를 알고 있는가?
투자자 중 한 명이 흥미로운 규칙을 만들었음. 답변의 근거를 찾을 수 없으면 에이전트는 답변할 수 없다는 규칙이었지. 그 결정 하나가 에스컬레이션을 40% 줄였고 고객 만족도(CSAT)를 두 자릿수만큼 끌어올렸음. 문제는 이런 시스템을 많이 다룰수록 AI 에이전트가 모델 때문에 실패한다는 생각이 점점 줄어든다는 거야. 대부분의 경우 에이전트는 애초에 제대로 접지(grounding)되지 않았기 때문에 실패함.
