AI에게 일을 맡길 때 가장 먼저 나오는 말은 대개 이렇습니다.
“이거 처음부터 끝까지 다 해 줘.”
처음에는 실제로 그렇게 하는 편이 편합니다. 자료를 찾고, 내용을 정리하고, 글을 쓰고, 파일로 저장하는 일까지 한 번에 요청하면 AI가 꽤 많은 일을 해냅니다. 저도 한동안은 한 명의 AI를 유능한 만능 직원처럼 생각했습니다.
그런데 업무가 조금만 복잡해지면 금방 한계가 보입니다. 조사와 작성이 섞이고, 검토해야 할 사람이 초안까지 다시 만들며, 한 단계의 오류가 다음 단계로 조용히 전달됩니다. 한 사람이 모든 일을 할 때 생기는 문제와 꽤 비슷합니다.
지난 글에서 에이전트의 실행 루프를 살펴봤다면, 오늘은 그 다음 질문으로 가 보겠습니다.
“에이전트가 한 명이 아니라 여러 명이라면, 일을 어떻게 나눠야 할까?”
Grok Bot, Hermes Agent, n8n, OpenClaw를 차례로 떠올려 보면 이 질문에 대한 답은 단순히 “에이전트를 많이 띄우자”가 아닙니다. 핵심은 역할, 인계, 병렬성, 통제 지점을 설계하는 데 있습니다.
1. AI 팀은 에이전트를 많이 켜는 일이 아니다
사람 팀을 생각해 보면 팀원 수가 많다고 일이 저절로 빨라지지는 않습니다. 기획자가 조사 결과를 받지 못하고, 작성자가 어떤 자료를 믿어야 할지 모르며, 검토자가 초안의 배경을 다시 묻는다면 사람만 늘었을 뿐입니다.
AI 팀도 똑같습니다.
사용자 목표
→ 총괄 에이전트가 과업 분해
→ 조사·작성·검토 에이전트에 역할 배정
→ 독립 작업은 병렬 실행
→ 결과를 공통 형식으로 인계
→ 검토 에이전트와 사람이 품질 확인
→ 총괄 에이전트가 최종 결과 조립
여기서 팀을 만드는 이유는 모델이 부족해서가 아닙니다. 하나의 에이전트가 동시에 모든 역할을 수행하면 무엇을 조사했고, 무엇을 추론했으며, 무엇을 검토하지 않았는지가 흐려지기 때문입니다.
아키텍처 교훈 ① 멀티에이전트의 출발점은 에이전트 수가 아니라, 서로 다른 책임을 분리하는 일이다.
2. 먼저 역할부터 나눈다
복잡한 업무에서 제가 가장 먼저 나누는 역할은 다음 다섯 가지입니다.
| 역할 | 주요 책임 | 결과물 |
|---|---|---|
| 오케스트레이터 | 목표를 쪼개고 순서·담당·완료 조건을 관리한다 | 작업 계획과 상태 |
| 리서처 | 원문 자료와 데이터를 찾고 조건을 기록한다 | 근거 목록과 조사 메모 |
| 작성자 | 확인된 자료를 정해진 형식의 초안으로 바꾼다 | 초안 또는 변경안 |
| 비평가·검토자 | 누락, 모순, 과장, 형식 오류를 찾는다 | 검토 의견과 보류 항목 |
| 기록자·전달자 | 결과와 로그를 저장하고 다음 단계로 넘긴다 | 버전, 인계 기록, 보고서 |
이 표에서 중요한 점은 한 에이전트가 여러 역할을 맡을 수 있다는 것입니다. 작은 업무에 다섯 개의 프로세스를 띄울 필요는 없습니다. 다만 역할을 분리해 두면, 같은 에이전트가 일을 하더라도 지금 어떤 모자를 쓰고 있는지를 명확히 할 수 있습니다.
예를 들어 “특허 관련 자료를 조사해 블로그 글로 정리해 줘”라는 요청을 한 덩어리로 실행하는 대신 다음처럼 나눌 수 있습니다.
- 오케스트레이터가 주제·독자·마감·분량을 확정한다.
- 리서처가 원문과 공개 자료를 모으고 출처와 날짜를 남긴다.
- 작성자가 자료와 편집 원칙에 맞춰 초안을 만든다.
- 비평가가 사실과 추론을 구분하고 과장된 표현을 표시한다.
- 사람이 외부 공개 여부와 최종 문장을 승인한다.
역할 분담은 문장을 잘 쓰게 만드는 장치라기보다, 책임이 어디에 놓이는지를 보이게 하는 장치입니다.
3. 네 가지 도구를 같은 잣대로 비교하면 놓치는 것이 있다
Grok Bot, Hermes Agent, n8n, OpenClaw를 비교할 때 “어느 것이 더 똑똑한가?”부터 묻기 쉽습니다. 하지만 이들은 모두 같은 층의 제품이 아닙니다. 여기서는 전체 기능이나 순위를 비교하는 것이 아니라, AI 팀을 설계할 때 읽을 수 있는 대표 축을 나란히 놓아 보겠습니다.
| 사례 | 아키텍처에서 두드러지는 축 | 잘 맞는 문제 |
|---|---|---|
| Grok Bot | 역할별 전문 에이전트와 단계별 게이트 | 조사·분석·보안 검사를 분리해야 하는 업무 |
| Hermes Agent | 범용 런타임, 기억·스킬·MCP, 하위 에이전트 위임 | 한 에이전트가 여러 채널과 도구를 이용하는 장기 작업 |
| n8n | 시각적 워크플로, 조건 분기, 결정적 자동화와 AI의 결합 | 정해진 절차 안에 AI 판단과 사람 승인을 넣는 업무 |
| OpenClaw | Gateway를 중심으로 채널·도구·스킬을 묶는 실행면 | 여러 대화 채널에서 하나의 개인·팀용 보조자를 운영하는 환경 |
Grok Bot은 이 글에서 공개 제품의 기능표라기보다, 원천 메모에서 다룬 역할 기반·게이트 기반 설계 사례로 읽는 편이 정확합니다. 반면 Hermes Agent는 공식 문서에서 기억과 스킬, MCP, 하위 에이전트의 병렬 작업을 범용 런타임의 구성요소로 설명합니다. n8n은 기존 워크플로 안에 AI Agent를 넣거나 여러 전문 에이전트를 연결하는 방식이 강점이고, OpenClaw는 Gateway를 통해 세션·도구·채널을 한곳에서 다루는 구조를 강조합니다.
이 차이를 모르면 n8n으로 모든 자율성을 만들려 하거나, 반대로 자율형 런타임에 고정된 절차를 억지로 심으려 할 수 있습니다.
아키텍처 교훈 ② 도구 비교의 기준은 기능 개수가 아니라, 그 도구가 팀의 어느 역할과 어느 통제 지점을 맡는가다.
4. 오케스트레이션에는 세 가지 기본 모양이 있다
순차형: 인계가 명확한 파이프라인
가장 이해하기 쉬운 구조입니다.
조사 → 요약 → 작성 → 검토 → 승인
앞 단계의 결과가 다음 단계의 입력이 되므로 인계가 쉽습니다. 대신 앞 단계가 늦어지면 전체가 기다려야 합니다. 법률·특허 자료처럼 근거를 차례로 확인해야 하는 업무에 잘 맞습니다.
병렬형: 독립된 조사를 동시에 실행
서로 의존하지 않는 일은 동시에 처리할 수 있습니다.
┌→ 국내 자료 조사 ─┐
주제 분해 ───┼→ 해외 자료 조사 ─┼→ 통합·검토
└→ 기존 글 중복 점검 ┘
병렬 실행은 시간을 줄여 주지만, 결과를 합치는 비용이 생깁니다. 조사자마다 용어와 출처 형식이 다르면 통합 단계에서 다시 정리해야 합니다. 그러므로 병렬화 전에 공통 출력 형식과 종료 조건을 정해야 합니다.
감독형: 총괄 에이전트가 전문 에이전트를 호출
사용자는 한 곳에서 요청하지만, 뒤에서는 총괄 에이전트가 적절한 담당자를 선택합니다. n8n의 매니저 에이전트와 하위 에이전트 구성, Hermes Agent의 위임 패턴을 이런 관점에서 읽을 수 있습니다.
이 구조는 편리하지만 총괄 에이전트가 잘못된 담당자를 고르면 전체가 틀립니다. 따라서 “누구에게 맡겼는가”와 “왜 그 담당자를 골랐는가”를 로그로 남겨야 합니다.
5. 병렬 실행은 빠르지만, 공통 상태를 조심해야 한다
에이전트 여러 명을 동시에 실행하면 무조건 빨라질 것 같지만, 실제 병목은 공통 상태에서 자주 생깁니다.
- 두 에이전트가 같은 파일을 동시에 수정한다.
- 서로 다른 출처를 같은 사실로 합친다.
- 한 에이전트가 만든 임시 판단을 다른 에이전트가 확정 사실로 읽는다.
- 실패한 작업과 완료된 작업을 구분하지 못한다.
그래서 병렬 작업의 공유물은 가능한 한 작게 만들어야 합니다. 완성된 문서 전체를 서로 덮어 쓰게 하는 대신, 각자 다음 형식의 결과만 반환하도록 하는 식입니다.
작업 ID:
담당:
상태: 완료 / 보류 / 실패
확인한 자료:
핵심 결과:
불확실성:
다음 담당자에게 필요한 입력:
이렇게 하면 에이전트끼리 긴 대화를 주고받지 않아도 됩니다. 사람 팀의 회의록이나 이슈 티켓처럼, 짧고 구조화된 인계물이 전체 팀의 기억이 됩니다.
6. 자율성의 크기보다 관문 위치가 중요하다
AI 팀을 만들면 “그럼 어디까지 알아서 하게 둘 것인가?”라는 질문이 바로 따라옵니다. 저는 이를 하나의 자율성 슬라이더보다 다음과 같은 관문으로 보는 편이 낫다고 생각합니다.
자료 조회
→ 내부 초안
→ 파일·워크플로 변경
→ 검토·테스트
→ 사람 승인
→ 외부 게시·발송·배포
조회와 초안은 비교적 자동화하기 쉽습니다. 반면 외부 게시나 고객 전달처럼 되돌리기 어려운 출구에는 사람의 승인을 둬야 합니다. n8n이 말하는 결정적 로직과 human-in-the-loop도 결국 같은 방향의 설계입니다. OpenClaw처럼 메시징 채널과 호스트 도구를 연결하는 시스템에서는 특히 누가 요청을 보냈는지, 어떤 도구가 호스트에서 실행되는지를 함께 확인해야 합니다.
자율성은 에이전트에게 모든 일을 맡기는 정도가 아닙니다. 안전하게 자동화해도 되는 구간을 넓히고, 위험한 구간 앞에서는 멈추게 하는 능력에 가깝습니다.
7. 특허 업무에 AI 팀을 대입해 보면 역할이 선명해진다
특허 선행기술 조사를 가상의 AI 팀으로 나누면 다음처럼 볼 수 있습니다.
사용자: 조사 목적·범위 입력
↓
총괄: 검색 과업과 분류 기준 확정
├─ 검색 담당: 공개 자료와 원문 후보 수집
├─ 서지 담당: 번호·날짜·문헌 관계 정리
├─ 비교 담당: 구성요소별 대응과 차이 초안
└─ 품질 담당: 누락·중복·근거 부족 표시
↓
사람: 관련성·법적 의미·보고서 외부 전달 승인
이 구조에서 검색 담당이 법적 결론까지 내리게 하면 역할이 섞입니다. 비교 담당의 분석을 원문 그 자체처럼 저장해도 안 됩니다. 총괄 에이전트는 각 결과에 원문, 분석, 보류라는 상태를 붙여 최종 보고서에 전달해야 합니다.
AI 팀은 사람을 없애는 구조가 아니라, 사람이 모든 반복 작업을 직접 하느라 정작 중요한 판단을 놓치지 않게 하는 구조입니다. 전문 에이전트가 늘어날수록 사람의 역할은 사라지는 것이 아니라 범위 확정, 위험 판단, 최종 승인 쪽으로 이동합니다.
8. 시작은 다섯 줄이면 충분하다
거대한 멀티에이전트 플랫폼부터 만들 필요는 없습니다. 반복 업무 하나를 골라 다음 다섯 줄을 먼저 적어 보면 됩니다.
목표: 최종적으로 무엇을 만들어야 하는가?
역할: 어떤 책임을 누구에게 나눌 것인가?
인계: 각 역할은 어떤 형식으로 결과를 넘길 것인가?
검증: 어떤 조건을 통과해야 완료인가?
관문: 어떤 행동 앞에서 사람이 승인할 것인가?
그 다음 도구를 고릅니다. 절차가 정해져 있고 분기와 로그가 중요하면 n8n 같은 워크플로 계층이 어울릴 수 있습니다. 여러 채널과 장기 실행이 중요하면 Hermes Agent나 OpenClaw 같은 런타임을 검토할 수 있습니다. 보안·분석 단계가 업무의 핵심이라면 Grok Bot처럼 역할과 게이트를 먼저 그리는 편이 맞습니다.
도구를 먼저 고르고 역할을 끼워 맞추면, 아키텍처가 제품의 기본값에 끌려갑니다. 반대로 역할과 관문을 먼저 정하면 제품이 바뀌어도 업무의 중심은 남습니다.
마치며
한 명의 AI가 여러 일을 해내는 장면은 인상적입니다. 그러나 실제 운영에서는 “얼마나 많이 한 번에 해냈는가?”보다 어떤 역할이 어떤 근거를 바탕으로 다음 역할에 무엇을 넘겼는가?가 더 중요합니다.
AI 팀의 핵심은 에이전트를 복제하는 일이 아닙니다.
- 일을 책임 단위로 나누고
- 독립된 일만 병렬화하고
- 인계 형식을 고정하고
- 공통 상태를 통제하며
- 외부 실행 앞에 승인 관문을 두는 것
이 다섯 가지가 갖춰질 때 AI 팀은 단순한 데모가 아니라 운영 가능한 오케스트레이션이 됩니다.
다음 글에서는 이렇게 나뉜 에이전트 팀이 참고할 기억과 지식을 어디에 둘지 살펴보겠습니다. 대화 기록, 사람의 지식 노트, 검색용 인덱스, MCP를 모두 ‘기억’이라고 부르면 편하지만, 그 순간 원본과 가공본의 경계가 흐려지기 때문입니다.