에이전트 오케스트레이션: 한 사람에서 팀으로

AI에게 실제 업무를 맡기고 있는 팀이라면 이런 상황을 마주할 것입니다.

동료의 AI들이 작성한 요구사항과 결과물을 모은 문서를 받아 보면, 길고 복잡한 경우가 많습니다. 분량이 많음에도 불구하고 결정의 근거와 작업 이력은 빠져 있고, 알아듣기 어려운 용어는 설명 없이 쓰여 있어 결론적으로 동료에게 설명을 요청합니다.

몇 년 전만 해도 AI는 질문 하나에 답 하나를 돌려주는 도구였습니다. 지금은 한 사람이 글을 쓰는 에이전트, 코드를 고치는 에이전트, 자료를 찾는 에이전트를 ‘동시에’ 부립니다. 한 사람이 해낼 수 있는 일의 양은 눈에 띄게 늘었습니다. 그런데 팀 전체의 효율성이 그만큼 증가했는지는 다시 한 번 따져봐야 합니다.

이 글은 여러 AI에게 일을 나눠 맡기는 방식, 곧 오케스트레이션이 어떻게 바뀌어 왔는지부터 정리합니다. 이어서 지금 남은 문제가 왜 사람과 사람 사이에 있는지 살펴보고, 그 사이에서 Riido가 하는 일을 소개합니다. 끝에는 쓰는 도구와 상관없이 팀에서 작게 시도해 볼 수 있는 가이드를 붙였습니다.

1/ 오케스트레이션이 걸어온 길

오케스트레이션은 AI에게 일을 나눠 맡기고, 그 결과를 모아 하나로 잇는 일입니다. 이렇게 일을 맡아 스스로 처리하는 AI를 에이전트라고 부릅니다. 지난 몇 년 동안 이 방식은 크게 세 단계를 거쳤습니다.

첫째, AI 하나가 스스로 일했습니다(2023). 목표만 주면 AI가 다음 할 일을 스스로 정해 실행했지만, 사람의 승인 없이 작동시키면 같은 일을 되풀이하는 구조가 발견됐습니다.

둘째, AI 여럿이 역할을 나눴습니다(2023~2024). 기획, 개발, 검토 역할을 AI들에게 나눠 맡기기 시작했습니다. 그러나 UC 버클리 연구진이 실행 기록을 분석해 보니 같은 단계를 되풀이하거나 언제 끝낼지 모르는 등 실패가 많았습니다.

셋째, 한 사람이 여러 AI를 동시에 부립니다(2025~). Claude Code나 Codex가 나오면서 한 사람이 AI 여러 개를 동시에 돌리는 방식이 흔해졌습니다. 2026년 2월 Claude Code는 여러 AI가 할 일 목록을 함께 쓰며 서로 메시지를 주고받게 하는 기능을 실험으로 내놓았습니다.

여러 AI에게 작업을 분배하는 방법이 늘 좋은 결과를 가져오는 것은 아닙니다. Google Research가 AI 구성 180가지를 비교한 연구에서, 재무 분석처럼 여러 갈래로 나눌 수 있는 일은 AI 여럿을 한 AI가 조율하는 구조가 AI 하나보다 80.9% 나은 결과를 냈습니다. 반면 순차적으로 진행되어야 하는 작업에서는 시험한 모든 다중 AI 조율 구성 방식이 AI 하나보다 39~70% 나빴습니다.

Anthropic의 실험도 비슷한 장면을 보여 줍니다. 연구진은 Claude 16개에게 C 언어 컴파일러를 함께 만들게 했습니다. 컴파일러는 사람이 쓴 프로그램을 컴퓨터가 실행할 수 있는 형태로 바꿔 주는 프로그램입니다. 그런데 리눅스 운영체제의 핵심인 커널처럼 큰 프로그램을 컴파일하는 단계에서 16개가 모두 같은 오류 하나에 매달렸고, 서로 고친 내용을 덮어썼습니다. 정답을 알고 있는 기존 컴파일러를 기준으로 일을 파일 단위로 다시 쪼갠 뒤에야 나눠서 일할 수 있었습니다. 두 실험 모두 AI의 수보다 일을 나누는 방식이 결과물에 영향을 미쳤습니다.

2/ 지금은 한 사람이 AI 팀을 거느립니다

세 번째 단계에 진입하며 AI를 잘 쓰는 사람의 하루는 팀장의 하루와 비슷해졌습니다. 일을 분할해 여러 AI에게 분배하고, 각 결과를 모으고, 기준에 맞는지 검토합니다. 새 기능을 하나 만든다면 한 AI는 화면을 고치고, 다른 AI는 서버 코드를 바꾸고, 또 다른 AI는 테스트를 씁니다. 사람은 세 결과를 합친 뒤, 기능이 처음 의도대로 동작하는지 확인합니다.

팀장이 하는 일을 조금 더 나눠 보면 네 가지입니다. 일을 어떻게 나눠 맡길지 정하고(분담), 누가 어디까지 했는지 지켜보고(트래킹), 앞의 결과를 다음 일에 이어 붙이고(병합), 끝난 결과가 쓸 만한지 확인(검토)합니다. AI가 늘어나면 이 네 가지에 드는 시간도 함께 늘어납니다. AI 팀을 혼자 운영/관리할 때는 필요한 정보와 문맥이 한 사람의 머릿속과 한 대의 컴퓨터 안에 있어서 크게 어긋나지 않습니다.

Riido를 만드는 저희 제품팀은 디자이너 한 명과 개발자 네 명, 모두 다섯 명입니다. 5명이 9주 만에 Riido를 다시 만든 이유에서 소개했듯이, 하나의 팀 기준으로 직원 5명과 함께 일하는 AI는 평균 30개입니다.

다섯 명의 사람과 서른 개의 AI를 둘씩 짝지으면 생길 수 있는 관계는 595개입니다. 물론 모든 쌍이 대화할 필요는 없습니다. 그렇지만 실제로 정보가 오가는 경로를 보면 사정이 다릅니다. 내가 구축한 AI 팀에서 각 AI는 내가 교통정리를 하지만, 동료의 AI와의 연결에서는 동료와 나를 거쳐야만 정보가 이어집니다. 사람과 사람 사이의 연결은 10개뿐입니다.

업무 관리 도구의 일부는 진행 중인 작업에 AI를 배정할 수 있게 됐습니다. 그래도 대부분의 AI는 여전히 한 사람에게 종속되어 업무를 담당하고, 여러 AI를 조율하는 도구는 필요한 정보를 한 사람의 범위(컴퓨터, 대화 세션 등) 안에 저장합니다. 앞에서 본 Claude Code의 기능도 할 일 목록과 팀 설정을 그 기능을 실행한 사람의 컴퓨터에 저장합니다. GitHub의 연구 조직 GitHub Next의 연구원 Maggie Appleton은 2026년 발표에서 지금의 코딩 AI 도구를 모두 “싱글 플레이어 인터페이스”라고 불렀습니다. 혼자 하는 게임처럼 만들어져 있다는 뜻입니다. 그래서 한 사람의 AI 팀이 아무리 커져도, 다른 사람의 AI 팀과 만나는 지점은 여전히 사람입니다.

3/ 다음 과제는 AI 팀장들 사이의 협업입니다

AI를 활용하는 구성원들이 팀으로 일한다면, 내 AI의 결과뿐 아니라 동료의 AI가 만든 결과까지 이어받아야 합니다. 이때 사람과 사람 사이에서는 네 가지 요소에서 자주 문제가 발생합니다.

나누기(누가 무엇을 맡을지): 같은 일을 두 사람의 AI가 동시에 진행하면 결과가 충돌합니다. 컴파일러 실험에서 AI 16개가 같은 오류에 몰린 것처럼, 같은 일을 여럿이 따로 하게 되는 낭비 현상은 실제 개발에서도 나타납니다. AI가 수정한 코드를 프로젝트에 통합시키기 위해 GitHub에 올린 요청 3만 3천여 개를 분석한 2026년 연구에서, 합쳐지지 못한 요청 600개를 골라 이유를 살펴보니 23%는 같은 변경이 이미 올라와 있던 경우였습니다.

보기(지금 누가 무엇을 하고 있는지): 내 AI가 무엇을 하는지는 내 화면에서 보이지만 동료의 AI가 무엇을 하고 있는지는 동료에게 물어봐야 알 수 있습니다. 서로의 진행이 실시간으로 동기화되어 있지 않으면 같은 일을 겹쳐 하거나 이미 끝난 일을 모르고 기다리게 됩니다. 개발자의 AI가 아직 기능을 고치고 있는데 마케터의 AI가 그 기능을 소개하는 글을 먼저 써 버리면, 둘 중 하나는 다시 해야 합니다.

잇기(결과와 함께 이유를 넘기는 일): 동료의 AI가 만든 결과를 내 AI가 이어받으려면, 결과는 동료와 나를 차례로 거칩니다. 이때 결과는 넘어오지만, 왜 그렇게 했는지와 무엇을 해 봤다가 그만두었는지는 중간에 누락되기 쉽습니다. 예를 들어 동료의 AI가 뉴스레터 초안을 쓰면서 아직 출시하지 않은 기능 하나를 일부러 내용에서 제외했다고 가정해 봅시다. 그 이유는 대개 본인만 알 것입니다. 결과만 받은 내 AI는 누락 사항으로 인지하고 그 기능을 다시 뉴스레터에 넣을 수도 있습니다.

확인하기(누가 결과를 볼지): AI는 결과를 빠르게 산출하지만, 그 결과(산출물)를 쓸지 말지는 사람이 정해야 합니다. 앞의 연구에서 코드 병합 요청 중 합쳐지지 못한 요청 가운데 38%는 사람이 제대로 리뷰하지 못한 채 닫혔습니다. 코드가 제대로 작동하는지 자동으로 확인하는 검사에서 실패한 경우(17%)보다 훨씬 많았습니다. 더불어, 결과를 누가 언제 확인할지 정해 두지 않으면, AI가 일한 만큼 확인할 일이 사람 앞에 쌓입니다.

네 가지 모두 혼자 일할 때는 비교적 쉽게 풀립니다. 내가 나누고, 내가 보고, 내가 병합하고, 내가 확인하면 되기 때문입니다. 사람이 둘만 되어도 이 일들은 대화와 메신저, 회의로 넘어갑니다.

💡 에이전트가 늘어날수록 에이전트 사이를 이어 주는 사람에게서 병목 현상이 일어납니다.

4/ Riido가 하는 일

Riido에서는 각자 쓰던 AI를 팀이 함께 보는 작업에 연결하고, 팀원으로 등록한 AI를 에이전트라고 부릅니다. 에이전트에게 맡긴 요청과 결과, 그 뒤에 오간 답글이 동료의 기억 대신 작업 기록에 남습니다. 10월 22일에 출시한 AI Agent와 11월 5일 업데이트로 지금 할 수 있는 일은 다섯 가지입니다. 다음은 이해를 돕기 위해 마케터 한 명과 개발자 한 명이 11월 뉴스레터를 함께 준비하는 상황을 예로 들겠습니다.

쓰던 AI를 그대로 팀원으로 등록합니다. Riido 데스크톱 앱에 각자 컴퓨터의 Claude Code나 Codex를 등록하면, 쓰던 기억과 설정값을 지닌 채로 에이전트로 들어옵니다. 실행은 각자의 컴퓨터에서 합니다. 예시에서는 마케터가 초안을 쓸 Claude Code와 검토를 맡길 Codex를 함께 등록하고, 개발자는 자신의 Codex를 등록합니다. 에이전트마다 설정 탭에서 이름, 모델, 지침을 바꿀 수 있어서 어떤 기준으로 일할지 미리 알려 줄 수 있습니다. GitHub, Figma, Slack에서 생긴 변경사항도 작업에 연결됩니다.

사람에게 맡기듯 맡기면, 에이전트가 작업 주변의 맥락까지 읽습니다. 작업에서 담당자를 배정하듯 에이전트를 고르거나, 댓글에서 @로 부르면 일이 맡겨집니다. 에이전트는 작업 본문과 댓글은 물론 상위 프로젝트와 목표, 하위 작업, 연결된 작업과 미팅까지 읽고 일을 시작합니다. 마케터가 '11월 뉴스레터 초안' 작업을 맡기면, 에이전트는 이 작업이 속한 프로젝트와 목표, 연결된 '릴리즈노트 확정' 작업, 연결된 주간 회의 내용까지 함께 읽습니다. 무엇을 읽었는지는 답변 아래 「조회한 자료」에서 확인할 수 있습니다. 때문에 에이전트가 어떤 자료를 읽고 썼는지 사람이 따라가 볼 수 있습니다.

에이전트끼리 일을 넘깁니다. 다른 역할이 필요하면 에이전트가 함께 일할 에이전트를 직접 찾아 요청합니다. 요청받은 에이전트는 같은 대화에 들어와 앞선 맥락을 그대로 이어받고, 오간 내용은 모두 댓글로 남습니다. 예시에서는 초안을 쓴 마케터의 Claude Code가 마케터가 함께 등록해 둔 검토용 Codex에게 확인을 부탁하고, 검토한 에이전트가 고칠 점을 댓글로 남깁니다. 사람이 중간에서 결과를 옮겨 적지 않아도 검토가 이어집니다.

이어지는 요청은 앞선 대화를 기억합니다. 에이전트가 남긴 결과 아래 답글로 요청을 이어가면, 새 대화를 열지 않고 같은 대화 안에서 처리합니다. 그래서 에이전트는 앞서 나눈 이야기와 작업 과정의 기억을 유지하는 상태로 일합니다. "두 번째 문단을 더 짧게"처럼 짧게 요청해도 앞의 맥락을 다시 설명하지 않아도 됩니다. 나중에 개발자가 작업을 열면 결과와 함께 어떤 요청과 수정이 오갔는지 볼 수 있어서, 마케터에게 묻기 전에 작업에서 먼저 확인할 수 있습니다.

진행은 한 곳에서 보고, 확인은 사람이 합니다. 에이전트에게 일을 맡기면 진행 표시가 나타납니다. 에이전트 상세 페이지에서는 진행 중인 작업과 대기 순서, 지난 작업 기록을 볼 수 있고, 참여자 필터에서 에이전트를 고르면 그 에이전트가 참여한 작업만 모아 볼 수 있습니다. 작업의 활동 탭에는 에이전트의 실행 기록과 실패 사유가 남습니다. 에이전트끼리는 한 작업 안에서 의견을 주고받고, 작업을 완료로 바꿀지는 담당자가 정합니다.

앞에서 말한 네 가지로 다시 보면 이렇습니다. 나누기에서는 누가 어떤 작업을 맡았는지 보이는 작업배정이, 보기에서는 진행 현황 표시와 에이전트 상세 페이지, 참여자 필터가, 잇기에서는 작업에 남는 대화와 맥락이, 확인하기는 담당자가 맡습니다.

예시로 돌아가 봅시다. 마케터의 Claude Code가 쓴 초안과 읽은 자료, 검토용 Codex가 남긴 의견, 마케터가 남긴 수정 요청이 모두 '11월 뉴스레터 초안' 작업에 남습니다. 다음 달 뉴스레터를 맡은 사람은 이 작업을 열어 지난번에 무엇을 왜 정했는지부터 볼 수 있습니다. 새 작업에 이 작업을 연결해 두면, 그 사람의 에이전트도 함께 읽고 시작합니다.

5/ 팀에서 먼저 해 볼 일

쓰는 도구와 상관없이, 여러 사람이 AI와 함께 일하는 팀이라면 아래부터 시작해 볼 수 있습니다.

• 맡긴 일을 모두가 보는 곳에 남깁니다. AI에게 일을 맡겼다면 무엇을 누구의 AI에게 맡겼는지 팀이 함께 보는 곳에 적어 둡니다.
• 같은 일은 한 번만 맡깁니다. 같은 일을 두 AI가 동시에 하지 않도록 한 곳에서 작업 분배를 하고, 이미 누가 하고 있는지 먼저 확인합니다.
• 순서가 중요한 일은 나누지 않습니다. 앞 단계의 판단이 뒤 단계에 영향을 주는 일은 한 AI가 처음부터 끝까지 맡는 편이 낫습니다. 앞의 Google 연구에서도 순차적으로 진행되는 일에서는 여러 AI에게 분배하는 것이 AI 하나가 작업하는 것보다 나빴습니다.
• 결과와 함께 이유를 남깁니다. 무엇을 왜 정했는지(결정 과정), 무엇을 해 봤다가 그만뒀는지(실험 과정)를 결과 옆에 적어 둡니다. 이어받을 사람과 AI가 같은 시행착오를 되풀이할 일이 줄어듭니다.
• 정한 내용을 AI가 읽을 수 있는 곳에 남깁니다. 회의에서 결정된 사항이 메모지에만 적혀 있으면 AI는 그 결정을 모릅니다. 결정과 기준을 작업이나 문서처럼 AI가 읽을 수 있는 곳에 남겨 둡니다.
• 완료 기준과 확인할 사람을 먼저 정합니다. 무엇이 완료되면 끝인지, 누가 검수/검토할지를 일을 맡기기 전에 적어 둡니다. 작업에 적어 둔 기준은 그대로 AI가 읽는 지시가 됩니다.

하나의 AI에게 지시할 때부터 한 사람이 AI 팀을 이끄는 때까지 몇 년이 걸리지 않았습니다. 그동안 AI가 혼자 해낼 수 있는 일은 크게 늘었습니다. 이제 남은 일은 저마다 AI 팀을 가진 사람들이 서로의 결과를 이어받는 방법입니다. 저희는 그 방법의 첫걸음이 사람과 AI가 같은 작업에서 함께 일하는 것이라고 생각합니다.

쓰던 Claude Code나 Codex를 팀원으로 연결해 보고 싶다면 Riido 데스크톱 앱에서 시작할 수 있습니다.