• 「단 한 명의 슈퍼 에이전트」가 엔터프라이즈에서 실패하는 3가지 이유
• 오케스트레이터(Orchestrator)・태스크 에이전트(Task Agent)・스페셜리스트 에이전트(Specialist Agent)의 역할 분담
• 실제로 기능하는 3가지 연계 패턴 (순차·병렬·감시)
• 아키텍처와 거버넌스(Governance)에 대한 구체적인 적용 방법

경영론이 아니라, 시스템 설계・API・권한・감사・운영의 관점에서 실무에서 사용할 수 있는 판단 기준을 제공합니다.

경리 팀이 결산을 서두르고 있다. 데이터는 ERP, 스프레드시트, 이메일 스레드에 흩어져 있다. 분개 이상 분석, 미완료 대조, 세무 정책 확인…….

「AI에게 시키자」라는 이야기가 나왔을 때, 가장 먼저 생각해야 할 질문은 「어떤 모델을 사용할 것인가」가 아니다.

**「어떤 종류의 에이전트가 필요한가」**이다.

그리고 그 답은 거의 항상 「단 한 명의 슈퍼 에이전트」가 아니다.

송장 예외 처리를 예로 들어보자. 문서 판독, 데이터 추출, 발주 대조, 구매 정책 확인, 승인 필요 여부 판단, 에스컬레이션(Escalation)──이것들을 단 한 명의 에이전트에게 몰아넣으면 스코프(Scope) 정의가 불가능해진다. 기술적으로는 작동한다. 하지만 테스트·설명·감사를 할 수 없다.

「이 에이전트는 분석만 하는가, 실행도 하는가」 「도구를 스스로 선택할 수 있는가」 「처리 순서를 바꿀 수 있는가」. 규제 대상 영역에서는 이러한 질문들을 모호하게 둘 수 없다.

출력이 좋지 않았을 때, 원인이 「태스크 분해 오류」 「도구 선택 실수」 「세무 규칙 오해석」 「데이터 추출 실패」 중 무엇인지 특정할 수 없다. 역할이 분리되어 있다면 평가는 외과적으로(Surgical) 수행할 수 있다.

가장 실용적인 사고방식은 에이전트 시스템을 팀으로 파악하는 것이다.

이것은 단순한 용어가 아니다. 복잡성을 줄이고 제어 가능성을 높이는 설계 도구이다.

오케스트레이터는 워크플로우(Workflow)를 조정한다. 큰 목표를 받아 실행 가능한 단계로 분해하고, 순서를 정하며, 적절한 에이전트나 도구를 선택하고, 진척을 감시하며, 예외를 처리한다.

구매 프로세스라면: 「요청 유형 분류 → 카테고리 정책 확인 → 벤더 검증 → 승인 경로 결정 → 발주서 작성 또는 에스컬레이션」.

오케스트레이터의 가치는 구매 전문 지식이 아니라, 「누구에게 무엇을 의뢰할지」를 알고 있다는 점에 있다.

오케스트레이터는 자유도가 높은 만큼, 명확한 경계가 필요하다.

정책 엔진 (Policy Engine): 허용되는 액션을 정의 -
도구 액세스 제한 (Tool Access Restriction): 호출할 수 있는 API·도구를 제한 -
승인 포인트 (Approval Point): 인간이 개입해야 할 지점을 명시 -
관측 가능성 (Observability): 모든 단계를 추적(Trace) 가능하게

제약 없는 오케스트레이터는 정책 위반 경로를 선택하거나, 부적절한 도구를 호출하거나, 에스컬레이션해야 할 상황에서 끊임없이 재시도(Retry)를 반복한다.

태스크 에이전트는 「단일하고 명확한 작업」에 특화된다. 송장 판독, 발주와 입고의 대조, 서포트 티켓 요약. 스코프가 좁기 때문에 구축과 테스트가 용이하며, 많은 엔터프라이즈 프로그램에서 첫 번째 프로덕션 투입 대상이 된다.

스페셜리스트 에이전트는 도메인 지식을 더욱 심화한다. 세무 스페셜리스트는 거래의 VAT 처리를 확인한다. 컴플라이언스 스페셜리스트는 지출 정책과의 정합성을 체크한다. 법무 옵스(Legal Ops) 스페셜리스트는 계약 조항의 일탈을 탐지한다.

중요한 것은 「똑똑함」이 아니라, 지식의 범위가 좁고 엄선되어 있다는 것이다. 엔터프라이즈에서는 「이 에이전트는 송장이 허용 범위 내에 있는지 여부만 체크한다」라는 명확한 제약이 신뢰의 기반이 된다.

선형 워크플로우(Linear Workflow)용. 온보딩, 송장 처리, 표준적인 서비스 요청. 각 에이전트가 단계를 완료하고 결과를 다음으로 전달한다. 단순하고 감사 가능하며, 비즈니스 측에서도 이해하기 쉽다.

여러 관점에서의 동시 평가가 필요한 경우. 계약서 초안을 법무, 리스크, 재무, 컴플라이언스(Compliance)의 각 전문가에게 동시에 전송한다. 오케스트레이터(Orchestrator)가 통합 요약본을 생성한다. 크로스 기능적(Cross-functional) 리뷰를 가속화하지만, 상충하는 결과에 대한 조정에는 규율이 필요하다.

액션 실행 전에 검증 레이어(Verification layer)를 추가한다. 결제, 마스터 데이터 변경, 신용 판단, 인사 기밀 작업에 필수적이다. 오케스트레이터가 체크를 조정하고, 인간 또는 제어 에이전트가 승인한 후 실행한다. 신뢰성은 높지만, 사이클 타임(Cycle time)은 길어진다.

흔한 실수: 항상 가장 자율적인 패턴을 선택하는 것. 그렇지 않다. 프로세스의 특성에 맞춰야 한다.

• 안정적·고빈도 → 순차적 (Sequential)
• 다각적 관점 필요 → 병렬적 (Parallel)
• 고위험·규제 대상 → 모니터링 (Monitored)
• 프로세스가 완전히 결정론적 (Deterministic) → 애초에 에이전트 패턴이 불필요. 기존의 워크플로우 자동화로 충분

ID·인가(Authorization)·관측 가능성(Observability)은 역할별로 분리해야 한다. 오케스트레이터에게 태스크 에이전트(Task Agent)와 동일한 권한을 부여해서는 안 된다.

오케스트레이터: 가장 엄격한 감시가 필요함. 처리 순서의 선택, 액션 결정권을 가지기 때문.
태스크 에이전트: 제한된 자율성으로 운영 가능.
스페셜리스트 에이전트 (Specialist Agent): 지식 소스와 정책에 대한 추가적인 거버넌스(Governance)가 필요.

• 오케스트레이터가 늘어남 → 프로세스 소유자, 에이전트 감시자, 정책 설계자, 예외 관리자로서의 인간이 필요
• 태스크 에이전트가 늘어남 → 수동 실행에서 모니터링·예외 처리·지속적 개선으로 업무가 전환

조직은 이러한 역할의 전환에 대비해야 한다.

오케스트레이터는 정말로 필요한가?

단일하고 좁은 태스크라면 강제하지 않는다. -
조정과 실행을 분리하라

단일 에이전트에게 워크플로우 관리, 도메인 지식, 실행 능력을 모두 몰아넣지 마라. -
스페셜리스트 에이전트가 필요한 영역을 특정하라

세무, 컴플라이언스, 법무, 구매 정책──전문성이 높은 영역은 스페셜리스트에게 맡긴다. -
패턴은 프로세스 특성에 따라 선택하라

시스템의 자율성 수준이 아니라, 프로세스의 안정성·리스크·규제 요건에 따라 판단한다. -
오케스트레이터에만 추가적인 가드레일(Guardrail)을 설정하라

툴 액세스, 에스컬레이션(Escalation) 조건, 승인 지점, 로그 취득은 태스크 에이전트보다 엄격하게 관리한다.

오케스트레이터와 태스크 에이전트의 차이는 기술적인 각주가 아니다. 엔터프라이즈가 신뢰하고, 통제하며, 확장할 수 있는 AI 시스템의 기반이다.

이를 잘못 설계하면, '너무 커서 신뢰할 수 없는 에이전트' 혹은 '너무 많아서 협업 모델이 없는 에이전트' 중 하나가 된다.

올바르게 설계한다면, 명확한 역할과 경계를 가지며, 매니저가 언제 개입해야 하는지 알고 있는, 최고의 인간 팀처럼 기능하는 디지털 팀을 얻을 수 있다.