5부 24장. 멀티에이전트 협업과 역할 분담

멀티에이전트를 떠올리면 흔히 이런 장면이 먼저 그려진다. 조사 담당이 자료를 모으고, 분석 담당이 의미를 읽고, 작성 담당이 문서를 만들고, 검토 담당이 오류를 잡는다. 얼핏 보면 아주 이상적이다. 그런데 실제 시스템에서는 사람 이름표를 붙였다고 협업이 저절로 생기지 않는다. 오히려 역할은 많은데 책임은 흐리고, 서로 말을 많이 하는데 결론은 늦게 나오는 일이 흔하다.

실전에서 중요한 것은 에이전트 수가 아니다. 각 에이전트가 어디까지 책임지고, 무엇을 넘겨받고, 어떤 기준으로 다음 단계에 결과를 전달하는지가 중요하다. 잘 만든 멀티에이전트는 작은 회사처럼 보이는 시스템이 아니라, 책임이 또렷한 생산 라인에 더 가깝다.

이 장에서는 멀티에이전트를 이미 쓰기로 했다는 전제 아래, 협업 구조를 어떻게 설계해야 하는지 살펴본다. 핵심은 네 가지다. 전문화, 통신 방식, 공유 상태, 그리고 충돌 해결이다. 결국 좋은 멀티에이전트란 에이전트를 많이 두는 구조가 아니라, 서로 덜 헷갈리게 일하게 만드는 구조다.

역할은 직함이 아니라 책임의 경계다

멀티에이전트 설계에서 가장 먼저 무너지는 부분은 역할 정의다. 초보 설계에서는 리서처, 전략가, 작성자, 비평가처럼 멋진 이름부터 붙인다. 하지만 이름이 멋질수록 오히려 속기 쉽다. 진짜 중요한 것은 이름이 아니라 경계다.

예를 들어 조사 에이전트는 사실과 근거를 모으는 역할만 맡고 해석은 하지 않게 만들 수 있다. 반대로 분석 에이전트는 이미 수집된 자료만 보고 비교와 해석을 하게 만들 수 있다. 작성 에이전트는 판단을 새로 추가하지 않고, 승인된 사실과 분석만을 바탕으로 문서를 구성하게 할 수 있다. 이렇게 나누면 각 에이전트의 책임이 분명해진다.

반대로 모두가 조사도 하고, 해석도 하고, 요약도 하고, 권고안도 쓰게 만들면 어떻게 될까. 겉으로는 전문가 팀 같지만 실제로는 작은 만능 비서 여러 명이 서로의 일을 덮어쓰는 구조가 된다. 결과가 충돌할 때도 누구 책임인지 알기 어렵다.

좋은 역할 분담은 보통 다음 질문에서 시작한다.

• 이 역할이 아니면 안 되는 판단은 무엇인가?

• 이 역할이 가져야 할 도구와 권한은 무엇인가?

• 이 역할이 생산해야 할 산출물은 무엇인가?

• 이 역할이 절대로 하지 말아야 할 일은 무엇인가?

특히 마지막 질문이 중요하다. 협업은 할 수 있는 일을 적는 것보다 하지 않을 일을 선명하게 정하는 것에서 더 안정해진다.

전문화는 성격 분화가 아니라 입력과 출력의 차이에서 나온다

실무에서 에이전트를 전문화한다는 말은 종종 성격 놀이처럼 흐른다. "너는 창의적인 전략가야", "너는 엄격한 품질 관리자야" 같은 식이다. 물론 이런 힌트가 조금 도움이 될 때도 있다. 하지만 운영 가능한 구조를 만들려면 성격보다 더 중요한 것이 있다. 바로 입력, 도구, 출력 형식, 성공 기준이다.

예를 들어 브라우저 탐색이 필요한 에이전트와 코드 실행이 필요한 에이전트는 자연스럽게 전문화된다. 읽기 전용 데이터베이스에 접근하는 에이전트와 실제 시스템에 변경을 가할 수 있는 에이전트도 마찬가지다. 출력 형식이 달라도 전문화가 생긴다. 어떤 역할은 근거 표를 내놓아야 하고, 어떤 역할은 승인 요청서를 써야 하고, 어떤 역할은 최종 사용자 메시지를 작성해야 한다.

즉, 전문화는 프롬프트 안의 캐릭터에서 나오기보다 서로 다른 책임, 도구, 제약, 결과물에서 나온다. 이 차이가 선명할수록 협업은 강해지고, 차이가 흐릴수록 에이전트는 서로 대체 가능해져서 굳이 여러 개 둘 이유가 줄어든다.

역할을 나누는 세 가지 기준

멀티에이전트 협업은 보통 세 가지 기준으로 나뉜다. 첫째는 기능 기준이다. 조사, 분석, 작성, 검토처럼 작업의 성격이 다를 때 이 방식이 잘 맞는다. 둘째는 자원 기준이다. 어떤 에이전트는 검색 도구를 쓰고, 어떤 에이전트는 내부 시스템만 읽고, 어떤 에이전트는 코드 실행 환경을 쓰는 식이다. 셋째는 위험 기준이다. 읽기만 하는 역할과 실제 변경을 수행하는 역할을 나누는 것이다.

실전에서는 이 세 기준이 섞인다. 예를 들어 고객 환불 자동화 시스템을 만든다고 해보자. 주문 정보 확인 에이전트는 내부 시스템 읽기 권한만 가지고, 정책 판정 에이전트는 환불 규정만 해석하고, 실행 에이전트는 승인된 경우에만 실제 환불 API를 호출한다. 여기에 애매한 사례를 사람에게 넘기는 승인 에이전트가 더해질 수 있다.

이 구조가 좋은 이유는 단순하다. 역할이 많아서가 아니라, 위험과 책임이 정확히 분리되기 때문이다.

협업 구조는 대화보다 계약에 가깝다

사람은 협업을 대화로 이해하지만, 시스템은 협업을 계약으로 설계해야 한다. 에이전트끼리 자유롭게 길게 대화하게 만들면 처음에는 똑똑해 보인다. 그러나 곧 문제가 생긴다. 같은 정보를 반복하고, 이전 합의가 흐려지고, 누가 최종 결정을 내렸는지 모르게 된다.

그래서 멀티에이전트의 통신은 가능하면 자유 대화보다 정해진 메시지 형식에 가까워야 한다. 이 메시지에는 최소한 다음 요소가 들어가는 편이 좋다.

• 작업 목적

• 입력 데이터

• 제약 조건

• 기대 출력 형식

• 확신 수준 또는 불확실성 표시

• 후속 조치 필요 여부

예를 들어 조사 에이전트가 분석 에이전트에게 결과를 넘길 때, 긴 산문만 던지는 것보다 "핵심 사실", "출처 여부", "확인되지 않은 추정", "추가 조사 필요 항목"으로 나눠 보내는 편이 훨씬 안정적이다. 그래야 분석 에이전트가 무엇을 사실로 받아들이고 무엇을 보류해야 하는지 분명해진다.

쉽게 말해 멀티에이전트 통신은 회의실 수다보다 택배 상자에 붙는 송장에 더 가깝다. 무엇이 들어 있고, 어디로 가며, 어떤 주의가 필요한지가 적혀 있어야 한다.

언제 직접 대화시키고, 언제 중앙을 거치게 할까

멀티에이전트 구조를 짤 때 자주 나오는 질문이 있다. 에이전트들이 서로 직접 이야기하게 할 것인가, 아니면 항상 중앙 조정자를 거치게 할 것인가.

정답은 하나가 아니다. 다만 원칙은 있다. 결정권이 중요한 정보일수록 중앙을 거치게 하고, 단순 교환 정보일수록 직접 주고받게 하라는 것이다.

예를 들어 조사 에이전트가 분석 에이전트에게 "이 수치는 최신 버전이 아니다" 같은 보충 설명을 전달하는 정도는 직접 통신으로도 괜찮다. 하지만 실행 여부를 바꾸는 판단, 승인 상태를 바꾸는 정보, 최종 사용자에게 나갈 메시지 초안 같은 것은 중앙 조정자나 명시적 승인 단계를 거치는 편이 안전하다.

중앙을 거치면 느려질 수 있지만 추적이 쉬워진다. 직접 통신은 빠르지만 상태가 분산되기 쉽다. 따라서 고위험 작업일수록 중앙 조정형이 낫고, 저위험의 반복적 데이터 교환은 제한된 직접 통신이 효율적이다.

실무 감각으로 말하면 이렇다. 잡담은 자유롭게, 결정은 기록되게 만들어야 한다.

공유 상태는 많을수록 좋은 것이 아니다

멀티에이전트가 어려운 가장 큰 이유 중 하나는 상태다. 여러 역할이 함께 일하면 모두 같은 정보를 보면 좋을 것 같지만, 실제로는 그 반대인 경우가 많다. 모든 상태를 모두에게 열어주면 각 에이전트는 불필요한 정보에 끌려가고, 오래된 상태를 잘못 읽고, 서로 다른 버전을 기준으로 판단하게 된다.

그래서 공유 상태는 넓게 열기보다 층을 나누는 편이 좋다. 보통은 세 층으로 생각하면 설계가 쉬워진다.

첫째는 전역 상태다. 사용자 요청, 전체 목표, 완료 조건, 현재 단계 같은 시스템 공통 정보가 들어간다. 둘째는 작업 상태다. 특정 하위 과업의 입력, 진행 상황, 중간 결과, 재시도 기록이 들어간다. 셋째는 역할별 로컬 상태다. 각 에이전트가 잠시 들고 있는 메모, 임시 계획, 작업 중간 흔적이 여기에 해당한다.

핵심은 모든 상태가 같은 중요도를 가지지 않는다는 점이다. 전역 상태는 신중하게 관리해야 하고, 작업 상태는 재현성과 복구를 위해 남겨야 하며, 로컬 상태는 필요 이상 공유하지 않는 편이 낫다. 사람 팀도 모두의 머릿속 생각을 실시간으로 공유하지는 않는다. 대신 일정표와 문서와 승인 기록만 맞춘다. 에이전트 협업도 비슷하다.

공유 상태를 설계할 때 꼭 필요한 것

공유 상태를 저장만 해서는 부족하다. 멀티에이전트에서는 상태의 내용만큼이나 상태의 성질이 중요하다. 최소한 다음 항목은 분명해야 한다.

• 누가 이 상태를 읽을 수 있는가

• 누가 이 상태를 바꿀 수 있는가

• 마지막으로 누가 언제 갱신했는가

• 이 값이 확정인지, 초안인지, 추정인지

• 충돌이 생기면 무엇이 우선하는가

예를 들어 가격 정책 판단 결과가 있는데, 조사 에이전트는 이를 수정할 수 없고 정책 판정 에이전트만 갱신할 수 있게 만들 수 있다. 또 실행 상태는 오직 오케스트레이터나 승인 시스템만 변경하게 설계할 수 있다. 이렇게 해야 "누가 최신 진실의 원천인가"가 분명해진다.

멀티에이전트에서 공유 상태는 공용 화이트보드가 아니라 권한이 있는 문서 시스템에 가깝게 다뤄야 한다.

충돌은 예외가 아니라 기본값이다

여러 에이전트가 협업하면 충돌은 특별한 사건이 아니다. 오히려 아주 정상적인 일이다. 조사 에이전트 둘이 서로 다른 사실을 가져올 수 있고, 분석 에이전트와 정책 에이전트가 같은 자료를 다르게 해석할 수 있고, 작성 에이전트가 사용자 친화성을 높이려다 법무 에이전트의 보수적 표현과 부딪힐 수 있다.

문제는 충돌 자체가 아니라, 충돌을 어떻게 다루기로 했는지가 미리 정해져 있느냐다. 충돌 정책이 없으면 시스템은 셋 중 하나로 흐른다. 첫째, 마지막에 말한 에이전트가 이긴다. 둘째, 중앙 조정자가 임의로 덮어쓴다. 셋째, 아무도 책임지지 못한 채 애매한 결과가 나온다. 셋 다 좋지 않다.

좋은 협업 구조는 충돌을 미리 예상하고 해결 규칙을 둔다. 사실 충돌과 해석 충돌을 구분하는 것만으로도 많은 문제가 풀린다. 사실 충돌은 원자료 재검증으로 돌아가야 한다. 해석 충돌은 기준과 우선순위 문제이므로 판정 권한을 가진 역할이 결정해야 한다. 표현 충돌은 최종 사용자 경험과 규정 준수 사이의 균형을 정하는 단계에서 조정해야 한다.

즉, 충돌 해결은 감으로 하는 화해가 아니라 종류별 처리 절차가 있어야 한다.

충돌 해결 규칙은 미리 정해 둬야 한다

실전에서 쓸 만한 방법은 의외로 단순하다. 먼저 충돌 유형을 나눈다. 사실 충돌, 계산 충돌, 정책 충돌, 우선순위 충돌, 표현 충돌처럼 분류할 수 있다. 그다음 각 유형마다 누가 최종 판정자인지 정한다.

예를 들어 사실 충돌은 원본 수집 책임자가 다시 확인하고, 정책 충돌은 정책 판정 에이전트나 사람 승인자로 넘기고, 표현 충돌은 최종 응답 합성기가 조정하도록 만들 수 있다. 계산 충돌은 코드 실행 결과나 검증 도구를 우선하도록 할 수 있다.

이런 규칙이 있으면 에이전트가 서로 다른 결과를 내도 시스템은 덜 당황한다. 충돌은 실패가 아니라, 오히려 품질을 높이는 점검 지점이 된다. 사람 팀에서도 의견 차이가 문제라기보다, 의견 차이를 정리하는 방식이 문제인 것과 같다.

최종 결정권은 반드시 적게 가져가야 한다

멀티에이전트를 복잡하게 만드는 또 하나의 원인은 결정권 분산이다. 모두가 의견을 낼 수는 있어도, 모두가 최종 결정을 내리게 해서는 안 된다. 그러면 시스템은 끝없이 논의하거나, 우연히 먼저 말한 쪽이 결론이 된다.

그래서 설계 단계에서 정해야 한다. 어떤 에이전트는 정보를 제공하고, 어떤 에이전트는 평가만 하며, 어떤 에이전트만 상태를 바꾸고, 어떤 단계에서만 사람 승인으로 넘어가는지를 정해야 한다. 특히 외부 시스템 변경, 금전 이동, 고객 통보, 정책 해석 같은 민감한 결정은 더더욱 그렇다.

가장 단순한 원칙은 이것이다. 관찰하는 역할은 많아도, 확정하는 역할은 적어야 한다.

예를 들어 코드 변경 자동화 시스템이라면 정적 분석 에이전트, 테스트 설계 에이전트, 보안 검토 에이전트는 모두 의견을 낼 수 있다. 하지만 실제로 패치를 저장소에 반영하는 권한은 실행 에이전트 하나만 가지게 해야 한다. 그리고 그 실행 에이전트조차 특정 조건이나 사람 승인을 통과해야만 행동하게 만들 수 있다.

실제 구조 예시: 출시 검토 멀티에이전트

신제품 출시 검토 시스템을 생각해보자. 이 시스템은 시장 자료, 정책 제약, 내부 준비 상태, 법무 검토를 함께 봐야 한다. 여기서 흔한 실수는 에이전트를 많이 만드는 것이다. 그러나 실제로는 네 역할 정도면 충분한 경우가 많다.

첫 번째는 조사 에이전트다. 외부 자료와 내부 문서를 읽고 사실을 구조화한다. 두 번째는 판정 에이전트다. 출시 기준표에 따라 가능 여부와 리스크를 평가한다. 세 번째는 문서화 에이전트다. 승인 회의용 요약안을 만든다. 네 번째는 승인 게이트다. 애매하거나 위험한 항목을 사람에게 넘기고, 승인된 경우에만 상태를 확정한다.

이 구조에서 중요한 것은 에이전트 수가 아니라 흐름이다. 조사 에이전트는 해석하지 않고, 판정 에이전트는 새 자료를 뒤지지 않으며, 문서화 에이전트는 정책을 새로 정하지 않는다. 승인 게이트는 의견을 쓰지 않고 상태만 바꾼다. 역할이 이렇게 딱딱 잘려 있으면 충돌이 생겨도 어느 층에서 해결해야 할지 보인다.

실제 구조 예시: 고객 지원 멀티에이전트

고객 지원에서는 멀티에이전트가 특히 유혹적이다. 문의 분류, 계정 조회, 정책 확인, 응답 작성, 감정 완화 표현까지 나누고 싶기 때문이다. 하지만 이 역시 역할을 선명하게 나누지 않으면 오히려 답변이 흔들린다.

좋은 구조는 보통 이렇다. 분류 에이전트가 문의 유형과 위험도를 정한다. 조회 에이전트가 필요한 내부 정보를 읽는다. 정책 에이전트가 환불 가능 여부나 예외 적용 가능성을 판정한다. 응답 에이전트가 고객에게 보낼 문장을 만든다. 여기서 고위험 사례는 사람 검토로 넘긴다.

핵심은 응답 에이전트가 친절한 문장을 쓴다고 해서 정책을 바꾸면 안 되고, 정책 에이전트가 규정을 해석한다고 해서 고객 어조까지 결정하면 안 된다는 점이다. 고객 경험과 정책 준수는 둘 다 중요하지만 같은 책임은 아니다. 이를 섞으면 답변은 부드럽지만 틀리거나, 맞지만 지나치게 딱딱해진다.

멀티에이전트의 흔한 안 좋은 협업 패턴

현장에서 많이 보는 실패는 몇 가지로 반복된다. 첫째, 역할은 다르다고 해놓고 실제 입력과 출력이 거의 같다. 둘째, 모든 에이전트가 모든 상태를 읽고 수정한다. 셋째, 자유 대화를 너무 허용해서 결정 기록이 사라진다. 넷째, 충돌 해결 규칙이 없어 마지막 합성기가 임의로 덮어쓴다. 다섯째, 사람 승인과 자동 실행의 경계가 불분명하다.

이 문제들은 대부분 복잡한 기술 부족 때문이 아니다. 책임 경계가 흐리기 때문이다. 멀티에이전트가 어려운 이유는 모델이 서로 대화해서가 아니라, 누가 무엇까지 책임지는지 설계자가 애초에 모호하게 정했기 때문인 경우가 많다.

에이전트를 늘리기 전에 먼저 줄여 보라

이 장의 핵심은 멀티에이전트를 옹호하는 데 있지 않다. 오히려 이미 멀티에이전트가 필요하더라도, 그 구조를 가능한 한 날씬하게 만들라는 데 있다. 역할이 겹친다면 합쳐라. 직접 대화가 꼭 필요하지 않다면 중앙 기록을 거치게 하라. 공유 상태가 너무 넓다면 읽기와 쓰기 권한을 줄여라. 충돌 해결 규칙이 없다면 에이전트를 하나 더 추가하기 전에 판정 기준부터 정하라.

좋은 멀티에이전트 설계자는 에이전트를 늘리는 사람보다 헷갈림을 줄이는 사람에 가깝다. 시스템 안의 역할이 선명해질수록, 오히려 에이전트 수는 줄어드는 경우가 많다.

운영 가능한 협업 구조의 체크리스트

멀티에이전트 협업 구조가 제대로 잡혔는지 보려면 다음 질문을 던져보면 좋다.

• 각 역할이 해야 할 일과 하지 말아야 할 일이 문장으로 적혀 있는가?

• 역할마다 입력, 출력, 도구, 권한이 실제로 다른가?

• 공유 상태에서 누가 읽고 쓰는지 정해져 있는가?

• 충돌 유형별 해결 절차와 최종 판정자가 있는가?

• 자동 실행과 사람 승인 사이의 경계가 분명한가?

• 한 에이전트를 제거했을 때 무엇이 나빠지는지 설명할 수 있는가?

이 질문에 선뜻 답하지 못한다면, 아직은 협업 구조가 아니라 등장인물 목록에 가까울 가능성이 크다.

이번 장의 결론

멀티에이전트 협업은 에이전트를 많이 두는 기술이 아니다. 책임을 나누고, 통신을 구조화하고, 상태를 계층화하고, 충돌을 제도적으로 해결하는 설계다. 잘 만든 구조에서는 각 에이전트가 똑똑해 보이기보다 예측 가능하게 행동한다. 그리고 바로 그 예측 가능성이 운영 가능한 시스템을 만든다.

기억할 것은 하나다. 멀티에이전트의 성패는 개별 에이전트의 화려함보다, 그들 사이의 경계선에서 결정된다. 역할이 선명하면 협업은 빨라지고, 경계가 흐리면 에이전트가 늘수록 회의만 길어진다.

다음 장에서는 이제 이런 협업 구조를 더 큰 서비스 안에 어떻게 녹여낼지 살펴본다. 개별 에이전트와 협업 패턴을 이해했다면, 다음 단계는 그것을 실제 제품 아키텍처 속에 안정적으로 배치하는 일이다.