AI 에이전트 6명이 협업하는 법
혼자 똑똑한 에이전트 하나보다, 역할이 나뉜 에이전트 팀이 훨씬 강할 때가 많다.
나는 요즘 글을 쓰고, 리서치를 모으고, 리뷰하고, 보안 이슈를 확인하고, 실제 발행까지 이어지는 일을 혼자 직접 다 하지 않는다. 내가 운영하는 OpenClaw 팀에서 Rosie는 위임하고, Luna는 조사하고, Cheese는 쓰고, Navi는 리뷰하고, Kkami는 보안과 인프라를 본다. 여기에 실제 실행 흐름을 물고 가는 메인 오케스트레이션까지 붙으면 비로소 “에이전트 하나”가 아니라 “일하는 팀”이 된다.
중요한 건 사람 조직도를 그대로 흉내 내는 게 아니다. 누가 무슨 일을 잘하는지보다, 어떤 패턴으로 협업시키는지가 먼저다. 멀티에이전트는 모델 수가 아니라 운영 프로토콜에서 성패가 갈린다.
단일 에이전트가 금방 막히는 이유
처음에는 나도 단일 에이전트로 거의 모든 걸 처리하려고 했다. 실제로 짧은 작업은 그렇게 해도 된다. 그런데 운영이 길어지면 금방 한계가 보인다.
첫째, 컨텍스트가 너무 무거워진다. 리서치 맥락, 사용자 의도, 초안 상태, 리뷰 기준, 발행 규칙, 보안 제약까지 한 에이전트 머릿속에 다 넣으려면 결국 잡음이 많아진다.
둘째, 실패 원인 분리가 어려워진다. 결과가 이상할 때 그게 모델 문제인지, 리서치가 빈약한 건지, 승인 흐름이 빠진 건지, 실행 권한이 잘못 열린 건지 구분이 안 된다.
셋째, 병렬화가 안 된다. 내가 블로그 초안을 다듬는 동안 리서치와 리뷰와 인프라 점검이 따로 굴러가야 하는데, 단일 에이전트 구조에서는 그게 자연스럽지 않다.
그래서 멀티에이전트의 핵심 가치는 “더 복잡한 걸 한다”가 아니라 복잡성을 분리한다는 데 있다. 역할을 나누면 성능이 좋아지는 것보다 먼저, 운영이 설명 가능해진다.
내가 실제로 쓰는 4가지 협업 패턴
멀티에이전트 구조를 보면 그럴듯한 다이어그램이 먼저 떠오르는데, 실제로 중요한 건 패턴이다. 지금 내가 자주 쓰는 건 크게 네 가지다.
1. 위임형: Rosie가 방향을 잡고 나머지가 움직이는 구조
가장 자주 쓰는 패턴은 위임형이다. Rosie가 오케스트레이터처럼 방향을 정하고, 각 전문 에이전트에게 일을 분배한다. 이 구조의 장점은 책임 경계가 매우 분명하다는 점이다.
예를 들어 블로그 한 편을 만든다고 하면 Rosie가 먼저 “무슨 글을 왜 지금 써야 하는지”를 정리한다. 그다음 Luna가 리서치를 붙이고, Cheese가 초안을 만들고, Navi가 표현과 논리의 어색한 부분을 잡고, Kkami가 기술적 위험이나 보안 포인트를 본다.
이 구조는 특히 품질 통제에 강하다. 누가 최종 판단자인지가 선명하기 때문이다. 대신 단점도 분명하다. Rosie가 병목이 되면 전체가 느려진다. 그래서 위임형은 방향이 중요한 작업에 좋고, 작은 반복 작업에는 과할 수 있다.
2. 파이프라인형: 조사 → 초안 → 리뷰 → 발행
이건 가장 이해하기 쉬운 구조다. 입력이 한 단계씩 앞으로 흐른다. OpenClaw에서 내가 콘텐츠 파이프라인을 돌릴 때 자주 쓰는 방식이다.
- Luna가 조사한다
- Cheese가 초안을 쓴다
- Navi가 리뷰한다
- Rosie가 승인한다
- 실행 에이전트가 발행한다
이 방식의 장점은 디버깅이 쉽다는 점이다. 어디서 멈췄는지 바로 보인다. 반대로 단점은 한 단계가 막히면 전체가 멈춘다는 것이다. 그래서 파이프라인형은 SLA가 중요하고 단계가 분명한 작업에 잘 맞는다.
블로그, 콘텐츠 승인, 정기 발행처럼 “흐름”이 중요한 작업은 파이프라인형이 가장 안정적이다.
3. 토론형: 답 하나보다 판단 품질이 중요할 때
모든 작업을 직렬로 흘릴 필요는 없다. 어떤 건 처음부터 여러 관점을 같이 붙이는 편이 낫다.
예를 들어 전략 문서나 제품 포지셔닝처럼 실수 비용이 큰 작업은 토론형이 좋다. 서로 다른 에이전트가 독립적으로 판단한 뒤, 최종 오케스트레이터가 정리하는 구조다. 이건 비용이 더 들고 느리지만, 편향이 줄고 리스크 검토가 강해진다.
실제로 Luna가 시장 신호를 가져오고, Cheese가 메시지화하고, Navi가 과장 여부를 잡고, Kkami가 기술 현실성을 붙이면 혼자 썼을 때보다 훨씬 단단해진다.
4. 이벤트형: 사람이 안 불러도 후속 작업이 이어지는 구조
가장 운영다운 패턴은 이벤트형이다. 어떤 상태 변화가 일어나면 그 다음 에이전트가 자동으로 반응한다.
예를 들어 포스트가 발행되면 요약 보고가 남고, 특정 리뷰가 끝나면 다음 단계가 열리고, cron이 실패하면 진단 루틴이 붙는다. 이건 그냥 자동화처럼 보이지만 사실은 멀티에이전트 운영의 핵심 패턴이다.
여기서 중요한 건 비동기 설계다. correlation id, retry, dead-letter, idempotency 같은 개념을 안 챙기면 나중에 운영이 엉킨다. 멀티에이전트는 대화형 UX만 생각하면 안 되고, 결국 메시지 기반 시스템처럼 봐야 한다.
내 팀 기준으로 보면 역할은 이렇게 나뉜다
이론보다 실제 사례가 더 중요하니까, 내가 지금 굴리는 팀 기준으로 단순하게 적어보면 이렇다.
Rosie: 위임형 리더
Rosie는 사람으로 치면 팀장에 가깝다. 모든 걸 직접 하지는 않지만, 지금 무엇이 중요한지 정하고 누구에게 일을 넘길지 판단한다. 멀티에이전트에서 제일 흔하게 필요한 역할이 이런 오케스트레이터다.
Luna: 리서치 전담
Luna는 트렌드, 경쟁사, 리서치 문서를 모아온다. 이 역할이 없으면 팀 전체가 빈약한 전제로 움직이기 쉽다. 멀티에이전트에서 리서치는 선택이 아니라 입력 품질 관리 장치다.
Cheese: 콘텐츠와 메시지 전환
나는 Cheese를 콘텐츠 에이전트로 쓰고 있다. 리서치를 가져와서 블로그 초안, 포스트, 라우팅 페이지, 메시지 프레임으로 바꾸는 역할이다. 이 단계가 있어야 조사 결과가 실제 산출물로 바뀐다.
Navi: 리뷰와 품질 게이트
Navi는 표현, 논리, 코드 리뷰, 과장 여부를 잡는다. 멀티에이전트에서 리뷰 에이전트가 없으면 팀은 빨라질 수는 있어도 신뢰는 잃기 쉽다.
Kkami: 보안과 인프라
Kkami는 이 구조에서 가장 운영적인 역할이다. auth profile drift, fallback 붕괴, rate limit, 경로 오류, 보안 이슈 같은 건 보통 콘텐츠 에이전트가 해결할 수 있는 문제가 아니다. 멀티에이전트가 production-ready가 되려면 이런 역할이 반드시 필요하다.
실행/오케스트레이션 레이어
마지막 하나는 특정 이름의 에이전트보다 실행 레이어에 가깝다. cron, sessions_send, 상태 파일, 승인 흐름, 후속 작업 연결 같은 것들이다. 이건 겉으로 잘 안 보이지만, 실제 팀을 팀처럼 보이게 만드는 층이다.
실무에서는 패턴보다 운영 체크리스트가 더 중요하다
패턴을 아는 것만으로는 부족하다. 실제로 굴리면 결국 아래 같은 체크리스트가 훨씬 중요해진다.
1. 누가 최종 승인권자인가
리서치와 초안과 리뷰가 다 있어도 최종 승인권자가 없으면 파이프라인은 중간에서 흔들린다. 특히 외부 발행이나 코드 변경은 반드시 승인 경계가 있어야 한다.
2. 에이전트마다 보는 정보 범위가 다르다
모두에게 같은 컨텍스트를 다 주면 낭비가 심하고, 반대로 너무 적게 주면 질이 떨어진다. 멀티에이전트의 성능은 모델 크기보다 누가 무엇을 보게 할지 설계하는 능력에 크게 좌우된다.
3. 동기/비동기를 섞어야 한다
빠른 응답이 중요한 건 동기형이 편하지만, 장시간 작업이나 배치 처리는 비동기 메시지 기반이 낫다. 전부 동기로 만들면 병목이 생기고, 전부 비동기로 만들면 추적이 어려워진다.
4. 로그와 메모리를 남겨야 한다
멀티에이전트는 한 번 잘 돌아가는 것보다, 다음에도 같은 품질로 다시 돌 수 있어야 한다. 그러려면 상태 파일, 메모, 결정 로그, 실패 원인이 남아야 한다. 나는 이걸 남기지 않으면 결국 팀이 아니라 매번 새로 시작하는 챗봇 무리라고 생각한다.
5. 로컬 운영은 생각보다 강하지만, 생각보다 귀찮다
OpenClaw처럼 로컬에서 팀을 굴리면 신뢰 경계가 분명하고, 실행 흐름을 직접 볼 수 있고, 커스터마이징도 쉽다. 대신 auth 관리, cron 실패, fallback 경로, config drift 같은 운영 문제가 계속 생긴다. 이걸 감당할 준비가 없으면 로컬 멀티에이전트는 금방 피곤해진다.
그래서 요즘 내가 중요하게 보는 건 단순한 역할 분담이 아니다. 결국 멀티에이전트의 경쟁력은
- policy-safe execution
- auditable memory ops
- local-first trust boundary
이 세 가지를 얼마나 운영적으로 설계했는가에 달려 있다.
결론: 6명을 만든다고 팀이 되는 건 아니다
멀티에이전트 시스템을 처음 만들면 자꾸 역할표부터 그리게 된다. 리서치 에이전트, 작성 에이전트, 리뷰 에이전트, 보안 에이전트, 퍼블리셔 에이전트. 물론 그것도 필요하다.
그런데 실제로 굴려보면 더 중요한 건 조직도가 아니다. 핸드오프 규칙, 승인 경계, 실패 처리, 로그, 메모리, 실행 정책이다. 나는 지금도 OpenClaw 팀을 굴리면서 이걸 계속 고치고 있다. 에이전트 수를 늘리는 건 쉽다. 팀으로 만드는 건 그다음 문제다.
결국 내가 내린 결론은 단순하다.
멀티에이전트의 핵심은 역할 분담이 아니라 운영 프로토콜이다.
그래서 앞으로도 나는 “에이전트를 몇 개 붙였나”보다 “이 팀이 얼마나 신뢰 가능하게 협업하나”를 더 중요하게 볼 생각이다.
2026-04-14
댓글