하나의 입구, 여러 도메인 에이전트: 기업 에이전트 운영 모델

기업은 에이전트에 관한 결정을 너무 일찍 양자택일로 묻곤 합니다. 모든 직원이 Slack에서 하나의 회사 공용 에이전트를 사용해야 할까요, 아니면 각 도메인이 자체 에이전트를 만들어야 할까요?

이 질문에는 서로 다른 두 가지 선택이 섞여 있습니다. 하나는 사람이 시스템에 진입하는 방식을 정하는 제품 결정입니다. 다른 하나는 인터페이스 뒤에서 업무를 나누는 엔지니어링 및 소유권 결정입니다. 회사는 하나의 어시스턴트를 제공하면서 내부적으로 여러 도구, 플레이북, 워크플로, 전문 에이전트에 작업을 라우팅할 수 있습니다. 반대로 여러 에이전트로 구성된 카탈로그를 제공하면서 모두 같은 통제 계층에서 실행할 수도 있습니다.

지속 가능한 기업 운영 모델은 신원을 인식하는 하나의 입구, 도메인이 소유하는 분산된 역량 라이브러리, 그리고 권한·컨텍스트·상태·평가·운영 소유권상 격리가 필요한 경우에만 두는 별도 에이전트입니다.

이 구조는 거대한 프롬프트도, 자유롭게 움직이는 에이전트 스웜도 아닙니다. 도메인 전문가가 업무 방식을 정의하고 공통 플랫폼이 그 업무의 실행 조건을 통제하는 운영 모델입니다.

하나의 입구가 하나의 에이전트 구현을 뜻하지는 않는다

Slack 봇, 웹 어시스턴트, IDE 패널은 직원 경험을 최적화해야 합니다. 사람에게 질문하기 전에 사내 에이전트 카탈로그부터 이해하라고 요구해서는 안 됩니다. 진입 계층은 사용자 신원을 확정하고, 업무 의도를 수집하며, 진행 상황을 보여주고, 승인을 요청한 뒤 일관된 결과 하나를 반환할 수 있습니다.

그 뒤에서 시스템은 여러 실행 경로 중 하나를 선택합니다.

employee in Slack, web, or IDE
             │
             ▼
identity-aware company assistant
             │
       intent and risk router
       ┌─────┼──────────┐
       ▼     ▼          ▼
   direct  domain     specialist
   answer  capability agent
           │           │
           └─────┬─────┘
                 ▼
       policy, budget, traces,
       evaluation, and approval

OpenAI Agents SDK 문서는 이 차이를 구현하는 두 가지 패턴을 설명합니다. manager 패턴에서는 하나의 에이전트가 전문가를 도구처럼 호출하고 최종 답변에 대한 책임을 유지합니다. handoff에서는 triage 에이전트가 대화를 전문 에이전트에 넘기고, 이후 해당 에이전트가 활성 주체가 됩니다. 또한 모든 라우팅 판단을 모델에 맡기는 것보다 코드로 오케스트레이션하는 편이 속도, 비용, 성능을 더 결정적으로 관리할 수 있다고 설명합니다. 이는 서로 다른 지능 이론이 아니라 상호작용 방식을 선택하는 문제입니다.

기업의 기본값은 하나의 입구 뒤에 manager 방식 오케스트레이션을 두는 것이 좋습니다. 전문 에이전트가 구별된 대화, 사용자 경험, 책임 경계를 가져야 할 때만 직접 handoff를 사용해야 합니다. 급여 관련 사건은 HR 에이전트임을 명확히 드러낼 필요가 있지만, 짧은 지표 조회는 대개 그렇지 않습니다.

새 에이전트를 만들기 전에 역량 단계를 구분한다

모델을 한 번 호출하는 기능까지 모두 에이전트라고 부르면 아키텍처 검토가 어려워집니다. 더 유용한 방법은 업무를 수행할 수 있는 가장 낮은 자율성 단위부터 살펴보는 것입니다.

단계	사용하는 조건	예시	주 소유자
컨텍스트	모델에 안정적인 사실이나 지침이 필요함	지표 정의, 리포지토리 규칙	도메인 소유자
도구	실시간 근거나 제한된 행동이 필요함	카탈로그 조회, 주문 조회, 티켓 생성	서비스 소유자
스킬 또는 플레이북	지식과 도구를 결합한 반복 절차가 있음	알림 조사, 실험 정리	도메인 전문가
결정적 워크플로	단계, 분기, 승인이 알려져 있음	환불 검토, 접근 요청, 출시 점검	제품 및 플랫폼 팀
에이전트	경로가 열려 있고 모델이 동적으로 계획해야 함	변화하는 근거를 탐색하는 심층 조사	에이전트 제품 팀
멀티 에이전트 실행	가치 높은 업무를 독립된 전문 작업으로 나눌 수 있음	시장과 규제를 아우르는 폭넓은 조사	오케스트레이터 소유자

Anthropic의 효과적인 에이전트 구축 가이드는 요구사항을 충족하는 가장 단순한 해법에서 시작하라고 권합니다. 코드가 경로를 정하는 workflow와 모델이 도구 사용을 동적으로 지시하는 agent도 구분합니다. 이 차이는 운영에서 중요합니다. 결정적 워크플로는 테스트, 비용 산정, 감사, 복구가 더 쉽습니다.

대부분의 도메인 기여는 도구, 스킬, 플레이북 단계면 충분합니다. 재무 전문가가 매출 변동을 조사하는 승인된 순서를 정의했다면 가치 있는 실행형 지식을 만든 것입니다. 그렇다고 별도의 메모리, 신원, 런타임을 가진 영속적인 “재무 에이전트”가 자동으로 필요한 것은 아닙니다.

모든 전문 에이전트가 분리 조건을 통과하게 한다

새 전문 에이전트는 조직도에 또 다른 부서가 있어서가 아니라 경계가 필요해서 존재해야 합니다. 다음 다섯 가지 검사가 그 차이를 드러냅니다.

권한

별도의 서비스 신원, 도구 허용 목록, 데이터 분류, 승인 체계, 거래 한도가 필요한가요? 구매 요청을 준비할 수 있는 조달 에이전트와 일반 지식 어시스턴트가 제한 없는 권한 범위를 공유해서는 안 됩니다.

컨텍스트와 데이터

일반 어시스턴트의 컨텍스트를 오염시킬 만큼 전문화된 검색 전략, 온톨로지, 프롬프트, 도구 카탈로그가 필요한가요? 별도 에이전트는 상세한 중간 작업을 격리하고 압축된 결과물만 반환할 수 있습니다. 문서 묶음 하나만 추가하면 되는 요구라면 범위가 제한된 검색 도구로 충분할 수 있습니다.

상태와 런타임

작업이 수 시간 동안 실행되고, 사람의 응답을 기다렸다 재개하며, 프로세스 장애 후 복구되거나 도메인별 사건 상태를 유지해야 하나요? 장기 실행은 별도의 런타임 신원을 정당화할 수 있습니다. 5초짜리 조회는 대개 그렇지 않습니다.

평가

성공에 별도의 합격 기준과 오류 정책이 필요한가요? 세무 분석, 장애 진단, 고객 지원, 코드 변경은 각각 올바른 결과의 정의가 다릅니다. 제안한 에이전트를 어떻게 평가할지 말할 수 있는 팀이 없다면 분리가 이릅니다.

운영 소유권

에이전트의 온콜 대응, 예산, 권한, 회귀, 폐기를 책임질 팀이 있나요? 모든 업무 흐름의 지속 가능한 답이 “AI 팀”일 수는 없습니다. 책임 소유자가 없는 전문 에이전트는 방치된 프로덕션 의존성이 됩니다.

병렬성은 여섯 번째 경제성 검사입니다. Anthropic은 자사의 멀티 에이전트 리서치 시스템이 내부 연구 평가에서 단일 에이전트 기준선보다 90.2% 높은 결과를 냈지만, 일반 채팅보다 약 15배 많은 토큰을 사용했다고 보고했습니다. 같은 보고서는 독립된 탐색 방향이 있는 breadth-first 작업, 많은 정보와 도구가 필요한 작업에 이 패턴이 적합하고 강하게 결합된 업무에는 맞지 않는다고 설명합니다. 이는 Anthropic 연구 시스템의 측정값이지 모든 멀티 에이전트에 적용되는 배수가 아닙니다.

도메인 전문가는 임의의 봇이 아니라 역량을 배포한다

프롬프트 엔지니어링과의 조직적 비유는 부분적으로 맞습니다. 초기 프롬프트 작업은 중앙 데이터 사이언스나 AI 팀이 담당하는 경우가 많았습니다. 애플리케이션이 성숙하면서 도메인 팀이 예시, 정의, 제약, 합격 기준을 더 잘 작성하게 됐습니다. 중앙 엔지니어가 모든 업무 절차를 표현할 수 없으므로 에이전트 개발도 비슷한 방향으로 갈 가능성이 큽니다.

안전하게 분산할 단위는 제한 없는 프로덕션 코드가 아닙니다. 도메인 전문가는 다음을 소유해야 합니다.

업무 의도와 완료 조건
도메인 용어, 제외 조건, 권위 있는 출처
플레이북 단계와 에스컬레이션 규칙
대표 사례와 공격적·경계 사례
평가 케이스와 기대 근거
결과 검토와 유지보수 책임

공통 플랫폼은 다음을 소유해야 합니다.

신원 전파와 서비스 자격 증명
런타임, 샌드박스, 내구성 있는 실행
도구 등록, 범위, 정책 집행
모델 라우팅, 예산, 속도 제한, 재시도
추적, 평가 파이프라인, 출시, 롤백, 폐기
도메인 자산을 배포 가능한 역량으로 컴파일하는 템플릿

보안, 개인정보, 위험 관리 팀은 위험에 비례하는 통제를 정하고 예외를 승인합니다. 모든 문구 변경을 처리하는 티켓 창구가 되어서는 안 됩니다. 위험이 낮은 읽기 전용 플레이북은 자동 검사와 도메인 검토를 적용할 수 있습니다. 영향이 큰 쓰기 역량은 더 강한 승인, 시뮬레이션, 출시 근거가 필요합니다.

LinkedIn의 Contextual Agent Playbooks & Tools, 즉 CAPT가 구체적인 사례입니다. LinkedIn은 코딩 어시스턴트를 새로 만들기보다 기존 에이전트를 보강하기로 했다고 설명합니다. CAPT는 MCP 도구와 실행형 플레이북을 공급하며, 공통 업무에는 중앙 플레이북을, 팀별 절차에는 리포지토리 로컬 플레이북을 사용합니다. LinkedIn은 1,000명 이상의 엔지니어가 500개 이상의 플레이북을 사용한다고 보고했습니다. 일반적인 분석 업무에서 질문부터 인사이트까지 걸리는 시간이 약 3배 빨라졌고, 여러 영역에서 초기 이슈 분류 시간이 약 70% 줄었다고도 보고합니다. 이는 LinkedIn 자체 측정이지만 정확한 비율과 무관하게 얻을 수 있는 아키텍처 교훈이 있습니다. 도메인 전문가는 새 에이전트 런타임을 소유하지 않고도 실행형 지식을 배포할 수 있습니다.

플랫폼을 역량 컴파일러로 만든다

유용한 셀프서비스 플랫폼은 안전한 경로를 가장 짧게 만들어야 합니다. 도메인 작성자는 템플릿에서 시작해 업무 의미와 평가 근거를 입력하고, 공통 런타임이 발견할 수 있는 등록된 역량을 전달받습니다.

예시 manifest는 다음과 같은 형태입니다.

id: revenue-variance-investigation
kind: playbook
owner: finance-analytics
purpose: explain material weekly revenue variance
riskTier: read-only
inputs:
  - metric
  - dateRange
tools:
  - metrics.read
  - warehouse.query-reviewed
outputs:
  schema: variance-report-v1
evidence:
  citationsRequired: true
limits:
  maxRuntimeMinutes: 10
  maxCostUsd: 2
evaluation:
  suite: finance-variance-v3
  minimumPassRate: 0.95
escalation:
  ownerChannel: finance-analytics-oncall

이 YAML은 특정 벤더에 종속되지 않은 설계 예시이며 A2A 규격을 구현한 Agent Card가 아닙니다. 중요한 점은 목적, 소유권, 권한, 출력, 예산, 평가, 에스컬레이션이 배포 전에 기계가 읽을 수 있는 형태로 존재한다는 것입니다.

플랫폼은 다음 golden path를 적용할 수 있습니다.

manifest와 도구 범위를 검증합니다.
고정된 런타임 및 모델 프로필에서 오프라인 케이스를 실행합니다.
지침과 의존성에서 위험한 행동을 검사합니다.
샌드박스 또는 shadow lane에 배포합니다.
결과 품질, 비용, 지연 시간, 정책 이벤트를 비교합니다.
버전이 기록된 승인과 함께 승격합니다.
사용량을 관찰하고 오래됐거나 소유자가 없는 역량을 자동으로 표시합니다.

템플릿은 위험과 업무 형태에 따라 달라야 합니다. 읽기 전용 질의응답 역량에는 출처와 인용 평가가 필요합니다. 쓰기 워크플로에는 멱등성, 미리 보기, 승인, 보상 작업, 거래 근거도 필요합니다. 장기 실행 에이전트에는 내구성 있는 상태, 취소, 체크포인트, 사람에게 넘기는 경로가 필요합니다.

모든 런타임 루프가 아니라 업무 자산을 소유한다

Hermes Agent, Deep Agents, Claude Agent SDK, OpenClaw 같은 harness 덕분에 직접 구축과 도입 사이에서 합리적인 전략을 선택할 수 있습니다. 각 제품은 에이전트 루프, 파일 시스템, 도구, 메모리, 스킬, 서브에이전트, 메시징, 승인 메커니즘을 서로 다른 조합으로 제공합니다.

Harness	유용한 출발점	기업이 추가할 경계
Claude Agent SDK	Claude Code 기반의 파일, 명령, 웹, 편집, 컨텍스트 루프를 프로그래밍 가능하게 제공	공급자 전략, 테넌트 격리, 기업 정책, fleet registry
Deep Agents	파일 시스템, 메모리, 스킬, 서브에이전트, 권한, 사람 승인을 갖춘 모델 중립적 harness	회사 신원, 도구 계약, 위험 등급, 포트폴리오 통제
Hermes Agent	메시징 게이트웨이, 도구, 스킬, 메모리, MCP, 스케줄링을 갖춘 self-hosted assistant	중앙 권한 관리, 통제된 스킬 공급망, 기업용 근거
OpenClaw	에이전트별 스킬 범위와 허용 목록을 갖춘 workspace-oriented assistant	더 강한 배포 격리, 정책 집행, 감사, 수명주기 gate

이 표는 품질 순위가 아닙니다. 공식 문서는 기능을 보여줄 뿐 기업 결과를 비교해 입증하지 않습니다. 프레임워크는 업무 제약, 지원 모델, 호스팅 조건, 격리, 관측성, 팀 언어, 전환 비용을 기준으로 선택해야 합니다.

루프 자체가 지속적인 차별점이거나 측정된 제약을 기존 선택지로 충족할 수 없을 때만 전체 런타임을 직접 구축하는 편이 좋습니다. 그 외에는 harness를 도입하거나 감싸고 회사가 일하는 방식을 나타내는 다음 자산을 직접 소유해야 합니다.

도메인 도구와 행동 계약
정책과 권한 규칙
플레이북과 평가 데이터
업무 의미와 권위 있는 출처
실행 근거, 사고, 결과 이력
이식 가능한 역량 manifest

이 경계를 지키면 모델이나 프레임워크를 바꾸더라도 회사의 운영 지식을 버리지 않을 수 있습니다.

미래의 에이전트 조직도를 책임 그래프로 만든다

에이전트 조직도는 성격이 아니라 계약을 표현할 때 유용합니다. 관리자, 분석가 같은 사람의 직책은 약한 라우팅 메타데이터입니다. 기계가 사용할 수 있는 디렉터리는 다음 질문에 답해야 합니다.

이 역량이 만들도록 허용된 결과는 무엇인가요?
누가 소유하며 에스컬레이션은 누가 받나요?
어떤 신원이 호출할 수 있나요?
어떤 도구, 데이터 등급, 쓰기 행동에 접근할 수 있나요?
어떤 입력 및 출력 스키마를 사용하나요?
비용, 지연 시간, 재시도 예산은 얼마인가요?
현재 릴리스가 통과한 평가 버전은 무엇인가요?
어떤 에이전트가 이 역량에 위임할 수 있나요?
어떤 버전이 활성, 폐기 예정, 차단 상태인가요?

Agent2Agent 프로토콜 규격은 신원, 역량, 스킬, 엔드포인트, 인증을 표현하는 Agent Card와 메시지, 상태가 있는 task, artifact를 정의합니다. 이는 유용한 상호운용성 구성요소입니다. 하지만 내부 권한, 예산, 소유권, 허용 가능한 위험을 결정하지는 않습니다. A2A는 위임을 경계 너머로 전달할 수 있지만, 그 경계가 존재해야 하는 이유는 회사가 통제해야 합니다.

디렉터리는 uses, delegates-to, approves, produces, depends-on, escalates-to처럼 의미가 명시된 edge를 가진 그래프로 모델링해야 합니다. 중앙 라우터와 결정적 위임 규칙에서 시작하세요. 평가된 후보 집합 안에서만 모델이 위임 대상을 선택하게 하세요. 에이전트가 동적으로 다른 에이전트를 고용하거나 서로 권한을 부여하는 구조로 시작해서는 안 됩니다.

현재 기업 사례는 스웜이 아니라 연합 구조를 가리킨다

DoorDash는 전문 에이전트를 발견하는 중앙 포털과 web, Slack, Cursor 통합을 갖춘 내부 플랫폼을 설명합니다. 이 아키텍처에는 공통 검색, schema-aware SQL 지원, 검증, 평가, guardrail이 포함됩니다. DoorDash는 peer autonomy로 바로 뛰어들기보다 결정적 워크플로에서 agent, deep agent, 비동기 swarm 탐색으로 발전하는 과정을 제시합니다.

LinkedIn은 보완적인 경로를 택했습니다. 기존 에이전트 클라이언트를 유지하면서 공통 계층을 통해 조직 컨텍스트, 도구, 플레이북을 배포합니다. 두 사례는 통합된 사용자 경험과 분산된 도메인 기여가 함께 존재할 수 있음을 보여줍니다.

그렇다고 모든 회사에 에이전트 marketplace가 필요하다는 뜻은 아닙니다. 작은 회사는 하나의 어시스턴트, 유용한 도구 10개, 관리되는 플레이북 5개, 평가 세트 하나로 시작할 수 있습니다. 실제로 발견과 소유권이 병목이 됐을 때 marketplace가 유용합니다. 그전에는 작은 역량 라이브러리를 큰 거버넌스 문제로 바꿀 수 있습니다.

네 단계로 운영 모델을 도입한다

1단계: 읽기 전용 입구 하나

신원을 인식하는 어시스턴트 하나를 소수의 권위 있는 읽기 도구에 연결합니다. 실제 수요가 있는 워크플로 두 개를 선택합니다. 인용, 지연 시간, 비용, 수정, 수용된 결과를 기록합니다.

종료 조건: 사용자가 선정된 업무를 완료할 수 있고, 검색 과정에서 접근 통제가 유지되며, 표본 실행을 재구성할 수 있습니다.

2단계: 도메인 역량 배포

두 도메인 팀에 도구, 플레이북, 소유자, 위험 등급, 평가 케이스 템플릿을 제공합니다. 자동 검증, 버전 관리, 리뷰 경로를 추가합니다. 런타임과 라우터는 하나로 유지합니다.

종료 조건: 두 번째 팀이 인증, 텔레메트리, 평가, 배포를 다시 만들지 않고 유용한 역량을 배포하고 관리할 수 있습니다.

3단계: 경계가 있는 전문 에이전트

분리 조건을 통과한 역량만 승격합니다. 같은 입구 뒤에 배치합니다. 라우팅 평가, handoff 계약, 에이전트별 예산, 필요한 경우 내구성 있는 상태, 명시적인 에스컬레이션을 추가합니다.

종료 조건: 전문 에이전트가 통제되지 않은 라우팅 오류, 비용, 책임 공백을 만들지 않으면서 결과 품질이나 소유권을 개선합니다.

4단계: 통제된 협업

에이전트 디렉터리, 의존성 그래프, 서명되거나 인증된 discovery, 에이전트 간 실행 envelope, artifact 계약, 취소, 포트폴리오 위험 보고를 도입합니다. 업무 가치와 독립성이 비용을 정당화하는 경우에만 병렬 멀티 에이전트를 사용합니다.

종료 조건: 부분 실패가 발생해도 위임된 실행의 모든 edge에서 신원, 목적, 권한, 근거, 예산, 책임이 보존됩니다.

에이전트 수가 아니라 결과를 측정한다

에이전트 수는 인벤토리 지표이지 성공 지표가 아닙니다. fleet이 커지는 동안 직원의 결과는 악화될 수 있습니다. 다음을 측정해야 합니다.

지표	판단할 수 있는 것
수용된 결과 비율	역량이 실제 업무를 해결하는지
수용된 결과당 비용	추가 추론과 위임이 경제적인지
라우팅 정밀도	하나의 입구가 올바른 역량을 선택하는지
불필요한 위임 비율	가치 없이 멀티 에이전트 복잡도가 추가되는지
handoff 완료율	신원, 컨텍스트, artifact가 전달 과정에서 유지되는지
수정 노력	사람이 결과를 얼마나 고쳐야 하는지
정책 위반 및 차단 행동 비율	권한 설계가 작동하는지
역량 재사용	도메인 자산이 팀을 넘어 누적되는지
오래됐거나 소유자 없는 역량 비율	카탈로그를 관리할 수 있는지
p95 지연 시간과 취소 성공률	장기 실행 작업을 운영할 수 있는지

제안된 전문 에이전트는 그것이 대체하는 더 단순한 기준선과 비교해야 합니다. 도구를 가진 단일 에이전트, 플레이북, 전문 에이전트로 같은 평가를 실행하세요. 개선 효과가 총비용, 지연 시간, 실패 복구, 운영 노력을 고려한 뒤에도 남을 때만 분리를 유지해야 합니다.

권고안

직원에게는 시작할 곳 하나를 명확하게 제공하세요. 그렇다고 그 인터페이스를 하나의 거대한 구현으로 만들지는 마세요. 공통 통제 계층과 역량 registry를 구축한 뒤, 도메인 전문가가 통제된 템플릿을 통해 도구, 스킬, 플레이북, 예시, 평가를 배포하게 하세요. 권한, 컨텍스트, 상태, 평가, 소유권, 경제적 가치가 있는 병렬성으로 격리 경계를 정당화한 역량만 별도 에이전트로 승격하세요.

가능성이 높은 미래는 디지털 직원 한 명도, 제한 없이 늘어나는 봇 집단도 아닙니다. 하나의 접근 경험, 관리되는 여러 도메인 자산, 소수의 책임 있는 전문 에이전트, 명시적인 협업 계약으로 이루어진 연합형 역량 조직입니다.

공통 런타임, 신원, registry, 수명주기 계층은 Enterprise Agent Platforms에서 이어서 볼 수 있습니다. 이 역량에 공급할 지식은 Enterprise Knowledge for AI Agents를 참고하세요. 권한과 근거 통제는 Agent Governance에서 설명합니다.