• 여러 부서에서 AI 에이전트가 동시에 움직이기 시작할 때 발생하는 「통치의 결핍」을 아키텍처가 아닌 **운용 모델 (Operating Model)**의 관점에서 정리한다.
• 권한 경계, 소유권, 에스컬레이션 경로 (Escalation Path), 동작 모드, 평가 지표, 인간의 역할 재설계라는 6가지 설계 요소를 시스템 설계, API, 감사, 운용에 적용한다.
• 경영론에 그치지 않고, 실제로 엔터프라이즈 환경에서 에이전트를 확장(Scale)시키기 위한 거버넌스 구조와 경고 신호를 제시한다.

당신의 조직에서 다음과 같은 에이전트가 작동하고 있지는 않습니까?

• 경리 팀: 송장 자동 대조 에이전트
• 고객 지원 (Customer Support): 주소 변경 처리 에이전트
• IT 운용: 인시던트 트리아지 (Incident Triage) 에이전트

각각 단체로는 생산성이 높아지는 것처럼 보인다. 하지만 어느 날 "에이전트가 중요한 송장을 오분류했다. 누구의 책임인가?"라는 질문이 터져 나온다.

이 질문에 대해 기술 아키텍처 (Technical Architecture)는 답을 가지고 있지 않다. 아키텍처는 "에이전트가 어떻게 도구를 호출하는가", "어떻게 추론하는가"를 정의하지만, "누가 그 에이전트를 소유하는가", "어느 정도의 자율성을 허용할 것인가", "실패했을 때의 에스컬레이션 대상은 누구인가"는 정의하지 않는다.

여기서 필요한 것이 바로 **Agentic Operating Model (에이전트 운용 모델)**이다. 소프트웨어가 「지원」에서 「실행」으로 전환되었을 때, 기업 전체로서 어떻게 통치할지를 설계하는 프레임워크이다.

각 부서가 독립적으로 에이전트 도구를 도입한다. 경리는 경리용, 고객 지원은 고객 지원용. 각각 단체로는 기능하지만, 횡단적인 소유권 모델이 없다. 결과적으로 「야생의 자동화」가 사내에 난립하게 된다.

에이전트가 잘못된 처리를 했을 때, 누가 책임을 지는가?

• 데이터 사이언스 팀?
• 업무 프로세스 오너 (Process Owner)?
• 플랫폼 벤더 (Platform Vendor)?

이것들이 정의되어 있지 않으면, 인시던트 발생 시마다 부서 간의 책임 논쟁이 일어난다.

소규모 PoC (Proof of Concept)에서는 프로젝트 팀이 밀착 감시하고 있기 때문에 문제가 잘 보이지 않는다. 하지만 여러 부서와 여러 국가로 전개되는 순간, 승인 임계값의 불일치, 리스크 허용도의 차이, 평가 지표의 비호환성이 표면화된다.

AI 에이전트는 기술 프로젝트가 아니다. 새로운 실행 레이어이며, 새로운 운용 규율을 요구한다.

에이전트가 「읽기」, 「권장」, 「초안 작성」, 「실행」 중 어디까지 허용할지를 명시한다.

# 권한 경계 정의 예시 (YAML)
agent:
  name: invoice_reconciliation
...

설계 관점:

• API 게이트웨이 레벨에서 권한을 강제한다 (에이전트가 직접 DB를 업데이트할 수 없도록 한다)
• 각 권한은 최소 권한의 원칙 (Principle of Least Privilege)을 따른다
• 권한 변경은 변경 관리 프로세스를 거친다

실무 포인트:

• 하나의 에이전트에 3명을 지명하고, 에스컬레이션 매트릭스 (Escalation Matrix)에 기재한다
• 주간 운용 리뷰에 3명 전원이 참여한다

「인간이 루프에 참여한다 (Human-in-the-loop)」는 것만으로는 불충분하다. 어떤 인간이, 어떤 채널로, 어느 시간대에 대응할지를 정의해야 한다.

escalation:
  level1:
    role: "operations_lead"
...

API 설계와의 연결:

• 에이전트의 도구 호출에 에스컬레이션 훅 (Escalation Hook)을 포함시킨다
• 에스컬레이션 발생 시 감사 로그 (Audit Log)에 자동 기록한다

워크플로마다 3가지 모드를 선택한다:

구현 시 주의사항:

• 모드는 동적으로 변경 가능하도록 한다 (API를 통해 설정 변경)
• 모드 변경은 감사 로그에 기록한다

「에이전트가 얼마나 움직였는가」가 아니라 「비즈니스 성과에 어떻게 기여했는가」를 측정한다.

API 연계 포인트:

• 에이전트의 모든 액션을 이벤트로서 감사 로그에 흘려보낸다
• 감사 로그를 데이터 레이크 (Data Lake)에 집약하여 정기적으로 분석한다

에이전트 도입 후, 인간은 「태스크 실행」에서 「감시·예외 처리·정책 개선」으로 전환된다.

• 주간 운영 리뷰를 통해 에이전트의 퍼포먼스(Performance)를 평가
• 월간 단위로 정책(Policy, 승인 임계값, 에스컬레이션(Escalation) 조건)을 업데이트
• 분기별로 에이전트 포트폴리오 전체에 대한 리스크 평가 실시

에이전트가 운영 환경(Production)에서 움직이기 시작하면, 다음과 같은 거버넌스(Governance) 체제를 구축해야 한다:

• 구성원: 사업, 기술, 리스크, 보안, 법무, 인사

• 의제: 유스케이스(Use case) 우선순위, 자율성 수준, 최소한의 통제 기준, 퍼포먼스 지표, 인시던트(Incident), 인력 영향

• 에이전트 유스케이스를 「파일럿의 집합」이 아닌 「운영 프로덕트 포트폴리오(Product Portfolio)」로 관리

• 로드맵, 장기 소유권, 목표 아웃컴(Outcome), 철수 판단 기준을 책정

COO: 프로세스 설계 및 운영 경제성 변경 주도 -
CHRO: 직무 설계, 스킬, 퍼포먼스 관리 영향 관리 -
CFO/리스크 책임자: 통제, 감사 가능성, 책임성(Accountability)

Agentic Operating Model은 기술 아젠다가 아니다. 경영 아젠다이다.

다음 증상 중 여러 개가 해당될 경우, 새로운 유스케이스를 추가하기보다 운영 규율의 강화를 우선해야 한다:

• 각 부서가 제각각 에이전트를 구축하며, 소유권 기준이 없음
• 운영 중인 에이전트의 공식 레지스트리(Registry)가 존재하지 않음
• 비즈니스 오너(Business Owner)가 불명확함
• 승인 임계값이 리스크 기반이 아니라 제각각임
• 운영 팀이 에이전트의 동작을 파악하지 못하고 있음
• 성공 지표가 「툴 도입률」뿐임
• 인사 부서가 역할 변화를 파악하지 못하고 있음
• 에이전트로 인한 인시던트가 공식적인 거버넌스 기구에 보고되지 않음

Agentic Operating Model의 본질은 AI를 더 활발하게 움직이게 하는 것이 아니다. 소프트웨어가 인간과 함께 일하기 시작했을 때, 누가 결단하고, 누가 책임을 지며, 리스크를 어떻게 통제하고, 인간과 에이전트가 어떻게 협업하여 아웃컴(Outcome)을 만들어낼 것인가를 명확히 하는 것이다.

인상적인 데모와 실제로 스케일(Scale)하는 변혁을 가르는 것은 바로 이 운영 모델의 유무이다.