- AI 하나에 모든 일을 맡기는 것은 직원 한 명에게 다섯 자리를 맡기는 것과 같습니다. 무언가 잘못되면 어디서 틀렸는지 찾을 수 없습니다.
- 여러 개로 나눈다면 일을 나눠 주고 결과를 모으는 "팀장"이 있어야 하고, 무엇을 누구에게 넘기는지 분명히 적은 인계서가 있어야 합니다. AI끼리 알아서 이야기하게 내버려 두면 안 됩니다.
- 기준은 AI가 몇 개인지가 아니라 일이 고객에게 닿을 때까지 끝까지 처리되는지입니다. 나눴는데 더 안전해지지도, 점검하기 쉬워지지도 않는다면 나눌 필요가 없습니다.
기존 웹사이트와 앱은 어디에서 멈춰 있을까
고객 전화를 받고, 견적서를 만들고, 재고를 확인하고, 작업을 검토하고, 할인을 승인하는 일을 한꺼번에 맡은 직원 한 명을 떠올려 보십시오. 일이 적은 날에는 해낼 수도 있습니다. 하지만 무언가 잘못되면 어느 단계에서 틀렸는지 따라가기 어렵고, 한 곳을 고치면 전체가 흔들리니 아무도 그 사람의 일하는 방식에 손대려 하지 않습니다. 모든 일을 혼자 떠안은 AI도 똑같은 문제를 겪습니다.
모든 일을 맡은 에이전트 하나는 프롬프트가 커지고, 점검하기 어려우며, 필요 이상으로 많은 도구에 접근합니다. 그렇다고 오케스트레이터(Orchestrator) 없이 에이전트를 여러 개로 나누면 답이 중복되고 결과를 책임지는 주체가 사라집니다.
기업이 에이전트 하나에게 문서 읽기, 계획 수립, 시스템 연동, 품질 검사, 승인을 한꺼번에 맡기면 컨텍스트는 길어지고 권한은 넓어지며, 결과가 틀렸을 때 원인을 찾기 어렵습니다. 팀은 프롬프트를 계속 덧붙이다가 결국 아무도 손대지 못하는 상태에 이릅니다. 지시 하나가 여러 역할의 동작에 영향을 주기 때문입니다.
멀티 에이전트 플랫폼(Multi-agent Platform)은 책임, 도구, 데이터, 평가 방식이 실제로 다를 때 역할을 나눕니다. 에이전트마다 제한된 일을 받고, 정해진 계약(Contract)에 따라 결과물을 다음 에이전트에 넘깁니다. 조율 담당, 분석가, 실무자, 검토자가 있는 팀과 비슷하며, 최종 결과를 책임지는 사람은 여전히 따로 있습니다.
| 기존 방식 | 새로운 AI 제품 방식 |
|---|---|
| 챗봇 하나가 모든 부서의 질문에 답하거나, 서로 연결되지 않은 봇 여러 개를 운영 | 매니저 에이전트가 일을 나누고, 역할에 따라 전문 에이전트를 도구로 호출하거나 인계(Handoff)하며, 결과를 모으고, 가드레일을 점검하고, 단계별 실행 기록(Trace)을 남김 |
여러 에이전트는 자유로운 메시지를 주고받는 대신, 프로그램이 검증할 수 있는 작업 상태(Task State)와 계약으로 연결되어야 합니다. 도구 게이트웨이(Tool Gateway)가 역할별 권한을 확인하고, 통합 실행 기록 덕분에 팀은 결과물이 어떤 에이전트와 데이터를 거쳤는지 볼 수 있습니다.
기업이 쓸 수 있는 새로운 기능
해법은 실제 팀처럼 꾸리는 것입니다. 조사, 계획, 데이터 수집, 실행, 검토를 맡는 사람이 각각 있고, 그 위에 과제를 받아 일을 나눠 주고 결과를 모으는 팀장을 한 명 둡니다. 대표가 화면에서 봐야 할 것은 지금 일이 어디까지 왔는지, 누가 맡고 있는지, 데이터가 어디서 왔는지, 어느 지점에서 대표의 승인을 기다리는지입니다. 모든 것을 뒤에 감춘 채팅창 하나로는 이것을 볼 수 없습니다.
프로젝트의 모습
플랫폼에는 목표를 받아 작업을 쪼개고 조사, 계획, 데이터, 운영, 검토 같은 전문 에이전트에게 나눠 주는 오케스트레이터가 있습니다. 사용자는 계획, 진행 상태, 데이터 출처, 승인 대기 지점을 볼 수 있어야 하며, 모든 작업을 대화창 하나 뒤에 숨겨서는 안 됩니다.
주요 기능
뒤에서 돌아가는 기술
개발팀 참고 · 시스템 구조
시스템에는 Orchestration Layer, State Store, Event/Job Queue, Tool/API Gateway, Identity, Policy, Observability가 필요합니다. Agent마다 작업에 따라 다른 모델을 쓸 수 있지만, Output은 다음 단계로 넘기기 전에 Schema와 Evaluation을 통과해야 합니다. Contract 없이 Agent끼리 자유 형식 메시지를 주고받으면 점검과 복구가 어려워집니다.
효과와 알맞은 시점
역할을 나누면 권한을 제한하고, 부분별로 테스트하고, 전체에 영향을 주지 않고 에이전트 하나만 바꿀 수 있습니다. 서로 다른 지식이나 시스템이 필요한 여러 단계의 업무에 알맞습니다. 워크플로 하나로 해결되는 짧은 업무에는 맞지 않는데, 복잡도와 비용, 인계에 드는 시간이 효과보다 클 수 있기 때문입니다.
- 전문 에이전트(Specialist Agent)는 역할에 맞는 지식과 도구만 씁니다.
- 매니저 오케스트레이션(Manager Orchestration)은 결과를 모으고 최종 답을 책임집니다.
- 인계(Handoff)는 적절한 시점에 전문 담당이 대화를 이어받게 합니다.
- 실행 기록과 평가(Trace/Evaluation)로 어느 에이전트가 어디서 잘못 판단했는지 확인합니다.
가상 사례
실제로 쓰이는 모습
가장 쉽게 떠올릴 수 있는 예는 지금 여러 부서를 거쳐야 끝나는 일입니다. 대형 고객에게 보낼 견적 제안을 준비하는 일이 그렇습니다. 요청 내용을 읽는 사람, 지난 자료를 찾는 사람, 가격을 산정하는 사람, 보내기 전에 검토하는 사람이 모두 필요합니다.
신제품 출시 요청을 시장 조사 에이전트, 콘텐츠 에이전트, 운영 에이전트가 나눠 맡습니다. 계획을 모으고 의존 관계를 확인하고 예산 건을 사람에게 올려 승인받는 일은 매니저 에이전트가 합니다. 모든 시스템에 권한이 있는 에이전트는 없습니다.
가상 사례로, 입찰(Tender) 제안서 준비는 접수 에이전트가 요구 사항을 정리하는 데서 시작합니다. 조사 에이전트는 승인된 자료실에서만 검색하고, 솔루션 에이전트는 자사 역량을 요구 사항과 연결합니다. 가격 계산 도구가 가격을 산정하면, 검토 에이전트가 제안서의 주장과 빠진 부분을 확인한 뒤 결재권자에게 올립니다.
가격 데이터가 준비되지 않으면 오케스트레이터는 그 흐름만 멈추고 나머지는 계속 진행하게 합니다. 검토자가 주장을 고치면, 시스템은 어느 에이전트가 어떤 출처로 그 내용을 만들었고 어떤 계약을 거쳐 넘겼는지 기록합니다. 그래서 팀은 문제가 모델에서 생겼는지 인계 과정에서 생겼는지 짐작하지 않고 잘못된 지점을 고칠 수 있습니다.
Least-capability Agent
에이전트마다 역할을 해낼 수 있는 최소한의 도구와 데이터만 줍니다.
권한을 넓게 줄 때보다 피해가 줄고 평가도 명확해집니다.
범위, 위험, 성과 측정 방법
가장 주의할 점은 AI가 여러 개라는 사실 자체가 성과는 아니라는 것입니다. 나눌수록 일을 잘못 넘길 수 있는 지점이 늘고, 속도는 느려지고, 비용은 커집니다. 그러니 일이 고객에게 닿을 때까지 끝까지 처리되는 경우가 얼마나 되는지 하나만 물으십시오. 나눠도 이 점이 나아지지 않는다면 아직 나눌 때가 아닙니다.
에이전트 수는 KPI가 아닙니다. 처음부터 끝까지 완료된 비율(End-to-end Completion), 인계 실패, 사람이 바로잡은 횟수, 도구 오류, 비용, 복구 시간을 측정하고, 최소 권한 원칙(Least Privilege)으로 권한을 제한하십시오. 작업 상태를 책임지는 주체 없이 에이전트들이 메시지만 주고받는다면, 에이전트 하나일 때보다 위험은 커지고 디버깅은 어려워집니다.
멀티 에이전트는 지연 시간, 비용, 장애 지점을 늘립니다. 역할과 권한이 실제로 다를 때 쓰고, 아키텍처를 최신처럼 보이게 하려고 쓰지는 마십시오.
개발팀 참고 · 기술 지표
추적할 지표: End-to-end Success, Handoff Error, Tool Rejection, Cost per Outcome, Trace Coverage
- Discover: 실제 업무를 따라가며 일반 사례와 예외 사례를 모읍니다.
- Assist: AI가 초안을 쓰거나 추천하고, 통제는 사람이 계속 맡습니다.
- Act: 테스트 세트를 통과한 뒤 도구(Tool)를 하나씩 엽니다.
- Scale: 모니터링, 대체 경로(Fallback), 비용, 책임자가 갖춰지면 확대합니다.
인계 실패가 많거나, 지연 시간이 쌓이거나, 전체 작업 상태를 책임지는 사람이 없다면 에이전트 수를 줄여야 합니다. 역할을 합치거나 일부 단계를 결과가 확정적인 규칙이나 도구로 바꾸면 대개 시스템을 관리하기 쉬워지고 더 믿을 만해집니다.
BUSINESS & PRODUCT READINESS
에이전트는 복잡해 보이려고가 아니라 책임이 실제로 다를 때 나눕니다
AI를 하나 더 들이기 전에 할 일은 새 직원을 뽑기 전에 하는 일과 같습니다. 이 자리가 어떤 일을 맡고, 어떤 데이터를 쓸 수 있으며, 누구에게 일을 넘기고, 누가 검토하는지 종이에 적어 보십시오. 적어 보니 두 자리가 모든 항목에서 같은 일을 한다면, 두 자리가 필요하지 않다는 뜻입니다.
책임 분담표(Responsibility Matrix)를 만드십시오. 어떤 에이전트가 어떤 입력을 받고, 어떤 도구를 쓰고, 어떤 형식으로 결과를 넘기는지, 누가 검토하고 누가 최종 결과를 책임지는지 적습니다. 두 에이전트가 같은 데이터, 도구, 기준을 쓴다면 나눌 필요가 없을 수도 있습니다. 멀티 에이전트는 비용과 장애 지점을 늘리므로 권한, 전문성, 평가 면에서 나눌 이유가 있어야 합니다.
인계 계약(Handoff Contract)을 설계해 넘길 맥락, 빼야 할 내용, 제한 시간(Timeout), 오류 책임자를 정하십시오. 에이전트 단위와 처음부터 끝까지의 전체 흐름 단위 모두에서 실행 기록과 평가를 갖추고, 동시 실행 수와 비용에 한도를 두십시오. 시스템은 사람이 계획을 볼 수 있게 하고, 영향이 큰 흐름은 멈출 수 있게 해야 합니다.
모든 역할의 입력, 출력, 도구, 데이터, 권한, 평가, 책임자를 담은 책임 분담표를 만드십시오. 두 에이전트가 같은 데이터, 도구, 기준을 쓴다면 하나로 합쳐야 하지 않는지 물어보십시오. 나누는 것은 위험을 줄이거나 점검 능력을 실제로 높일 때만 의미가 있습니다.
현재 여러 역할의 전문가가 있고 인계 지점이 분명한 업무 프로세스에서 시작하십시오. 처음에는 에이전트가 한두 구간만 돕게 하고, 공유 작업 상태(Shared Task State)와 사람의 승인 단계를 함께 둡니다. 실행 기록과 복구가 제대로 작동하면 그때 병렬 처리나 자율성을 넓힙니다. 데모 한 번에 많은 에이전트로 이뤄진 팀을 선보이는 것으로 시작해서는 안 됩니다.
최종 결과는 어느 에이전트가 책임지는가
이 에이전트를 왜 따로 나누는가
최소한의 도구 권한은 무엇인가
인계가 실패하면 누가 이어받는가
에이전트 팀을 사람 팀처럼 꾸리기: 역할, 권한, 팀장을 분명하게
DNA Maker는 에이전트 상자를 여러 개 그리는 대신 업무 프로세스와 책임을 정리하는 워크숍(Process/Responsibility Workshop)으로 시작합니다. 대화와 결과를 누가 통제해야 하는지에 따라 매니저가 에이전트를 도구로 쓰는 방식(Manager-as-tools)과 인계 방식(Handoff) 가운데 하나를 고르도록 돕고, 도구별로 사람의 승인과 가드레일을 정합니다.
저희는 계획, 도구 호출(Tool Call), 인계, 오류가 보이는 흐름 프로토타입을 만들어 업무 책임자가 점검하게 합니다. 그다음 평가 세트로 세부 작업과 최종 성과를 모두 측정해, 여러 에이전트가 에이전트 하나보다 정말 나은지 증명합니다.
DNA Maker는 고객의 실제 업무 프로세스를 바탕으로 에이전트별 책임, 인계 계약, 사람의 통제 방식을 설계합니다. 일반 워크플로를 쓸 지점, AI가 맡기 좋은 지점, 결과가 확정적인 도구여야 하는 지점을 골라내고, 상태, 대기열, 권한, 감사 기록을 거슬러 확인할 수 있도록 아키텍처를 짭니다.
개발 범위에는 오케스트레이터, 전문 에이전트, MCP/API 도구, 작업 콘솔, 평가, 관측 기능(Observability)이 들어갈 수 있으며, 업무 흐름 하나와 미리 합의한 장애 시나리오에서 출발합니다. 매주 여러 팀 사이에서 일을 넘겨야 하는 업무가 있다면 실제 산출물과 대기 지점을 가지고 오십시오. 멀티 에이전트가 맞는지, 워크플로가 맞는지, 둘을 섞은 시스템이 맞는지 함께 판단하겠습니다.
개발팀 참고 · 저희가 맡을 수 있는 개발 범위
DNA Maker는 Agent Platform, Orchestrator, Specialist Agent, MCP/API Integration, Permission, Trace, Evaluation, Cost/Latency Monitoring을 개발할 수 있으며, 업무 상황에 따라 Tool과 Agent를 켜고 끌 수 있는 Admin 화면도 함께 만듭니다.
업무 프로세스에 여러 역할의 전문가가 있고 일을 넘길 때 맥락이 사라진다면, 저희가 에이전트 책임 지도(Agent Responsibility Map)를 만들고, 최종 결과의 책임은 사람에게 둔 채 흐름 하나를 시험해 보도록 돕겠습니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
멀티 에이전트 시스템의 조율자, 인계, 권한, 실행 기록을 설명하는 용어입니다. 역할마다 범위와 통과 기준이 실제로 있는지, 아니면 도식 위에 이름만 여러 개 적혀 있는지 확인할 때 쓰십시오.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Orchestrator | 에이전트의 작업 순서를 조율하고 결과를 모으는 제어 장치. 계획과 전체 상태를 책임지지만 모든 권한을 직접 쥐지는 않으며, 도구마다 해당 작업의 권한을 따로 확인하는 구성 요소 | 매니저 에이전트가 전문 에이전트를 호출합니다. | 최종 성과는 누가 책임집니까? |
| Handoff | 제어권을 다른 에이전트에 넘기는 일. 받는 쪽이 바로 판단할 수 있도록 사실, 근거, 이미 시도한 것, 넘기는 이유까지 함께 전달하는 것이 좋은 인계 | 환불 건을 환불 에이전트에 넘깁니다. | 어떤 맥락을 넘기고, 무엇을 빼야 합니까? |
| Agent as Tool | 매니저가 통제권을 유지한 채 에이전트에게 세부 작업을 맡기는 방식. 전문 에이전트를 입력과 출력이 분명한 도구처럼 호출하도록 감싸서, 통제하기 어려운 에이전트 간 대화를 줄이는 설계 | 조사 에이전트가 결과를 매니저에게 보냅니다. | 세부 결과는 합치기 전에 어떻게 검증합니까? |
| Least Privilege | 필요한 최소한의 권한만 주는 원칙. 해당 작업과 해당 기간에 꼭 필요한 권한만 주어, 지시가 잘못되거나 데이터가 범위를 넘어 쓰일 때의 피해를 줄이는 방식 | 콘텐츠 에이전트는 데이터를 읽을 수 있지만 이메일은 보내지 못합니다. | 역할이 바뀌면 권한을 다시 검토합니까? |
| Tracing | 시스템의 처리 순서와 도구 사용을 남기는 기록. 입력, 모델, 프롬프트, 도구, 출력, 시간, 비용을 연결해 팀이 원인을 찾고 회귀 테스트(Regression Test)를 만들 수 있게 하는 것이 좋은 트레이스 | 흐름이 어느 단계에서 실패했는지 확인합니다. | 트레이스 데이터는 안전하게 보관되고, 얼마 동안 남습니까? |
더 읽을거리(원문 자료): https://openai.github.io/openai-agents-js/guides/multi-agent/