당신의 두 AI 에이전트는 하나의 임무를 가지고 있었습니다. 주제를 연구하고 요약문을 작성하는 것이죠. 간단하죠?
한 에이전트는 회사에 대해 Google 검색을 했습니다. 다른 에이전트도 또한 그 회사에 대해 Google 검색을 했습니다. 그러자 첫 번째 에이전트는 요약문이 틀렸다고 판단하고 다시 썼습니다. 두 번째 에이전트는 동의하지 않았고, 그것을 다시 고쳐 썼습니다. API 호출이 스물일곱 번 지나자, 당신은 3달러짜리 지폐와 ChatGPT가 무료로 제공하는 것보다 못한 요약문을 얻게 되었습니다.
이것이 바로 다중 에이전트 협업(multi-agent coordination)입니다. 이 기능에 대해 멋진 데모를 보여줄 때 아무도 경고하지 않는 부분이죠.
아무도 이야기하지 않는 문제점
다중 에이전트 시스템의 지저분한 비밀은 이것입니다: 두 개의 에이전트가 함께 일하는 것이 종종 하나의 에이전트가 혼자 일하는 것보다 더 나쁘다는 것입니다.
개별 에이전트들이 나쁜 것은 아닙니다. 그들에게 서로 발을 밟지 않도록 하는 방법을 아무도 알려주지 않았기 때문입니다.
대학에서의 조별 과제를 생각해 보세요. 똑똑한 다섯 명의 사람이 있지만, 협업은 전혀 없고, 밤 11시 59분에 충돌하는 수정 사항이 열일곱 개 들어간 하나의 Google Doc만 있는 상황. 익숙하게 들리나요?
다중 에이전트 AI 시스템도 정확히 같은 방식으로 실패합니다. Agent A가 데이터를 가져옵니다. Agent B는 같은 데이터(아무도 Agent A가 이미 했다고 알려주지 않았기 때문에)를 가져옵니다. Agent A가 응답을 형식화합니다. Agent B는 그것을 다르게 형식화합니다. 그들은 루프하고, 중복하고, 모순됩니다. 그리고 당신의 토큰 청구서는 올라가고 품질은 떨어집니다.
'에이전트만 추가하면 된다'가 함정인 이유
제안은 매혹적입니다: _
No machine learning (ML). No embeddings. No vector databases. 단지 '이 작업은 이 에이전트에게 속하며, 완료되면 끝이다'라고 명시하는 딕셔너리 하나만 있으면 됩니다.
다중 에이전트 혼란을 해결하는 세 가지 규칙
수많은 다중 에이전트(multi-agent) 설정이 꼬이는 것을 지켜본 후, 실제로 작동하는 것은 다음과 같습니다:
규칙 1: 작업 시작 전에 선점하라 (Claim before you work). 모든 에이전트는 작업을 시작하기 전에 claim_task()를 호출해야 합니다. 이미 다른 누군가가 선점했다면, 그 작업은 건너뜁니다. 중복을 완전히 제거합니다.
규칙 2: 작성자는 한 명, 독자는 다수 (One writer, many readers). 작업을 선점한 에이전트만이 결과를 작성할 수 있는 유일한 주체입니다. 나머지 모든 에이전트는 get_result()를 통해 읽기 전용(read-only) 접근만 할 수 있습니다. 충돌하는 수정은 발생하지 않습니다.
규칙 3: 과거로 돌아가지 말고, 미래로 이의를 제기하라 (Disagree forward, never backward). 만약 Agent B가 Agent A의 결과가 잘못되었다고 생각하더라도, 그것을 다시 작성하지 않습니다. 대신 '연구 개정(revision_of_research)'과 같은 새로운 작업을 생성하고, 이를 선점한 다음 개선된 버전을 작성합니다. 감사 추적 기록(audit trail)은 깨끗하게 유지되며, 실제로 무슨 일이 일어났는지 디버깅할 수 있습니다.
contract = AgentContract()
# 연구원(Researcher)이 작업을 선점하고 완료함
...
불편한 진실
대부분의 팀은 다중 에이전트 시스템 자체가 필요하지 않습니다. 잘 프롬프트된 단일 에이전트에 좋은 도구만 연결해도, 90%의 사용 사례에서는 두 에이전트가 루프 속에서 논쟁하는 것보다 항상 더 나은 성능을 보입니다.
다중 에이전트 협업(coordination)은 다음 경우에만 가치가 있습니다. 즉, 서로 다른 시스템 프롬프트, 다른 도구 세트, 또는 다른 신뢰 경계(trust boundaries)의 이점을 누릴 수 있는 작업을 실제로 가지고 있을 때뿐입니다. 만약 귀하의 '연구원'과 '작성자'가 두 개의 다른 함수 호출을 가진 단일 에이전트로 대체될 수 있다면, 그것은 다중 에이전트 문제가 아닙니다. 작업 목록을 가진 단일 에이전트를 사용하는 것입니다.
어려운 부분은 에이전트 자체가 아닙니다. 협업(coordination)입니다. 그리고 가장 좋은 협업이란 AI라기보다는 지루한 소프트웨어 엔지니어링에 훨씬 더 가까워 보입니다.
실제 운영 환경에서 협업하는 다중 에이전트 시스템을 구축해 본 경험이 있나요? 어떤 핸드오프 패턴(handoff pattern)이 도움이 되었나요? 댓글로 여러분의 설정을 공유해주세요. 특히 에이전트 수와 계약(contracts) 방식과 메시지 큐(message queues) 중 어느 것이 더 효과적이었는지 궁금합니다.