혼자 일하다 보면 어느 순간 이런 욕심이 생깁니다. "AI 하나로 이만큼 되면, 열 개 띄우면 열 배 되는 거 아냐?" 저도 그 생각을 했습니다. 그래서 실제로 역할을 나눠서 여러 개를 돌려봤습니다. 콘텐츠 담당, 코드 담당, 브라우저 조작 담당, 리뷰 담당. 결과부터 말하면 어떤 일은 확실히 좋아졌고, 어떤 일은 오히려 하나로 할 때보다 나빠졌습니다. 그리고 요금은 정직하게 늘었습니다.
2026년 AI 업계의 화두가 딱 이 지점입니다. "더 똑똑한 에이전트 하나"에서 "여러 에이전트를 어떻게 팀으로 묶느냐"로 논의가 넘어왔거든요. 그런데 대부분의 글이 대기업 아키텍처 얘기라, 혼자 일하는 사람 기준으로는 감이 잘 안 옵니다. 그래서 오늘은 제가 직접 굴려보고 정리한 1인 창업가용 멀티 에이전트 기준선을 공유합니다.
멀티 에이전트가 뭔지부터 — "직원 여러 명"이 아니라 "일 쪼개기"
멀티 에이전트 오케스트레이션은 쉽게 말해 이렇습니다. 오케스트레이터(관리자 역할 AI)가 큰 일을 받아서 조각으로 쪼개고, 쪼갠 조각을 서브 에이전트 (실무자 역할 AI) 여럿에게 동시에 던진 뒤, 각자 결과를 가져오면 오케스트레이터가 합쳐서 최종 결과를 만듭니다. 업계에서는 이걸 팬아웃(fan-out) 패턴이라 부릅니다. 회사로 치면 팀장이 일 나눠주고 팀원들이 각자 하고 팀장이 취합하는 구조 그대로입니다.
여기서 오해하기 쉬운 게 있습니다. 에이전트를 늘리는 건 "직원을 늘리는 것"이 아니라 "일을 병렬로 쪼개는 것"입니다. 그래서 애초에 쪼개지지 않는 일이면, 사람을 늘려도 아무 소용이 없습니다. 오히려 방해가 됩니다.
숫자로 보면 — 효과도 진짜, 비용도 진짜
Anthropic이 자사 리서치 기능을 만들면서 공개한 내용이 참고할 만합니다. 리드 에이전트 하나가 계획을 세우고 서브 에이전트 3~5개를 병렬로 띄운 뒤 결과를 합치는 구조인데, 내부 평가에서 단일 에이전트 대비 90.2% 더 나은 성능을 냈습니다. 대신 토큰을 일반 대화의 약 15배 씁니다. 그리고 성능 차이의 80%가 "토큰을 얼마나 썼느냐"로 설명된다는 결론도 나왔습니다. 즉 멀티 에이전트가 잘하는 이유의 상당 부분은 그냥 돈을 더 쓰기 때문입니다.
반대편 사례도 있습니다. AI 코딩 도구 Devin을 만드는 Cognition은 2025년 6월 "멀티 에이전트를 만들지 마라"는 글로 유명해졌습니다. 에이전트 사이를 오갈 때 맥락이 새거나 중복되고, 실패는 대부분 그 인수인계 구간에 숨어 있다는 주장이었습니다. 그런데 이 회사는 2026년 3월 여러 Devin을 관리하는 코디네이터 기능을 내놨습니다. 입장이 바뀐 게 아니라, "맥락이 쌓이면 집중력이 떨어진다"는 문제를 격리로 푸는 게 맞다고 인정한 것에 가깝습니다.
정리하면 업계 결론은 "좋다/나쁘다"가 아니라 "쪼갤 수 있는 일이냐" 한 줄입니다.
그래서 몇 개까지? — 제가 쓰는 3가지 기준
기준 1. 2~4조각으로 쪼개지면 나눠라, 8~10조각이 필요하면 다시 생각해라. 일을 독립적인 2~4개로 나눌 수 있을 때는 멀티 에이전트가 품질에서 이깁니다. 그런데 8~10조각 이상으로 쪼개야 하는 일은, 조율 비용이 이득을 잡아먹어서 차라리 긴 맥락을 가진 에이전트 하나가 더 빠르고 결과도 낫습니다. 저도 "이왕 하는 거"라며 잘게 쪼갰다가, 서로 다른 방향으로 작업해 놓은 결과물을 제가 손으로 붙이고 있는 상황을 만든 적이 있습니다.
기준 2. 조각끼리 서로 눈치를 봐야 하면 쪼개지 마라. 이게 제일 중요합니다. 나눈 작업들이 서로의 결정을 알아야 하는 일이라면 — A가 정한 톤을 B도 따라야 하고, B가 만든 구조 위에 C가 올라가야 하는 일이라면 — 그건 애초에 나누면 안 되는 일입니다. 코딩처럼 앞뒤가 촘촘히 얽힌 작업에서 멀티 에이전트 효과가 잘 안 나는 이유가 이겁니다. 반대로 "이 주제로 자료 5개 찾아와" 같은 리서치는 서로 몰라도 되니 병렬이 훌륭하게 먹힙니다.
기준 3. 결과 가치가 요금보다 클 때만 띄워라. 15배라는 숫자를 잊으면 안 됩니다. 매일 반복하는 루틴 작업에 멀티 에이전트를 붙이면 월말에 놀라게 됩니다. 저는 "한 번 잘 나오면 오래 쓰는 결과물" — 리서치, 시장 조사, 여러 후보안 비교 — 에만 병렬을 씁니다. 매일 도는 정형 작업은 단일 에이전트에 절차서(SOP)를 물려주는 쪽이 훨씬 쌉니다.
아트고메에 실제로 어떻게 적용했나
제 구조를 그대로 공개하면 이렇습니다. 콘텐츠 자동화(매일 도는 일)는 단일 에이전트 + 상세 절차서입니다. 카드뉴스·릴스·블로그는 순서가 정해진 반복 작업이라 병렬로 얻을 게 없습니다. 여기에 여러 에이전트를 붙였을 때 얻은 건 "톤이 제각각인 결과물 세 개"였습니다. 리서치/후보 조사는 병렬입니다. 뉴스 후보를 카테고리별로 나눠서 동시에 훑는 건 서로 몰라도 되는 전형적인 팬아웃 작업이라, 여기서는 확실히 빠르고 품질도 좋습니다.
코드 작업은 기본은 하나입니다. 대신 "작성"과 "리뷰"는 분리합니다. 같은 에이전트에게 자기 결과물을 검수하게 하면 자기 논리에 갇힙니다. 리뷰어는 앞의 대화 맥락을 모른 채 결과물만 보는 게 오히려 낫습니다. 이건 조각을 나눈 게 아니라 관점을 나눈 것이라 예외적으로 잘 먹힙니다. 브라우저·화면 조작은 그 일만 하는 별도 에이전트입니다. 이건 성능 문제가 아니라 권한 문제입니다. 실제 계정을 만지는 권한은 최대한 좁은 방에 가둬두는 게 안전합니다.
패턴이 보이시나요. 제가 에이전트를 나눈 기준은 "많이 굴리면 좋으니까"가 아니라 ① 서로 몰라도 되는가 ② 관점이 달라야 하는가 ③ 권한을 격리해야 하는가, 이 셋 중 하나였습니다.
시작하는 분께 — 오늘 당장 할 수 있는 것
거창한 세팅 필요 없습니다. 순서는 이렇게 잡으세요. 1) 먼저 하나로 끝까지 해보세요. 단일 에이전트로 안 되는 일이 멀티로 마법처럼 되는 경우는 거의 없습니다. 대부분 지시가 부족한 겁니다. 2) "이 일을 서로 모르는 두 사람에게 시켜도 되나?"를 물어보세요. 답이 '된다'면 나누고, '안 된다'면 그냥 하나로 가세요. 3) 나눴다면 합치는 사람을 반드시 두세요. 병렬 작업의 실패는 대부분 각자의 결과물이 아니라 합치는 구간에서 납니다.
마치며
혼자인데 팀처럼 일한다는 게 결국 이런 겁니다. 사람 수를 늘리는 게 아니라, 일의 성격을 정확히 보고 나눌 것만 나누는 것. AI를 동업자로 쓰기 시작하면 "AI를 몇 개 쓰느냐"보다 "무엇을 나눌 수 있는 일로 볼 수 있느냐"가 실력이 됩니다. 저는 계속 굴려보고, 망가지는 것까지 그대로 기록하고 있습니다. 이런 1인 AI 회사 운영의 시행착오를 처음부터 끝까지 정리한 게 「AI 회사를 만들었습니다 -실전편-」입니다.
작성: Art Gourmet