「우리 회사는 이미 AI 에이전트를 도입했다」라는 말을 들었을 때, 그것이 단순한 챗봇인지, 메일 초안 작성 지원인지, 아니면 실제로 API를 호출하여 업무 시스템에 데이터를 쓰는 자율 실행인지 조직 내에서 정의가 일치하지 않았던 경험이 있지 않은가.

본 기사에서는 Agentic AI Maturity Model (에이전틱 AI 성숙도 모델) 을 엔지니어링 관점에서 해설한다. 특히 다음 사항에 초점을 맞춘다.

• 각 레벨에서의 아키텍처 (Architecture) 차이와 API 연동 요구사항
• 에이전트가 '작동'하기 위해 필요한 권한 설계 · 감사 · 운영 기반
• 현실적인 12개월 타겟 설정과 해서는 안 될 구현 패턴

경영론에 그치지 않고, 시스템 설계로 연결할 수 있는 내용을 목표로 한다.

상태: 각 엔지니어나 비즈니스 사용자가 ChatGPT나 사내 LLM을 개인의 어시스턴트로 이용. 코드 리뷰 초안 작성, 문서 요약, 메일 작성 지원 등.

아키텍처의 실태:

• 시스템 연동은 없음. 브라우저상의 Web UI가 주 전장. - API 호출은 발생하지만, 그것은 개인의 클라이언트에서 LLM 프로바이더로의 직접 호출.
• 기업 차원의 추적성 (Traceability) 및 거버넌스 (Governance) 는 존재하지 않음.

엔지니어링 상의 문제점:

• 데이터 유출 리스크: 고객 정보나 소스 코드가 허가되지 않은 외부 LLM으로 전송될 가능성. - 재사용성 제로: 프롬프트나 설정이 개인의 로컬 환경에 갇혀 조직의 자산이 되지 않음. - 측정 불가능: 「생산성이 향상되었다」라는 주관적인 보고밖에 얻을 수 없음. 사이클 타임 단축이나 에러율 개선과 같은 비즈니스 지표와 연결되지 않음.

판단 기준:

• 「AI를 쓰고 있다」라고 말하면서, 그 성과가 개인의 만족도 설문조사로만 측정되고 있음. - 프로세스 오너가 부재하여, 아무도 AI의 아웃풋 품질에 책임을 지지 않음.

상태: AI가 공식적인 워크플로우 (Workflow) 에 통합됨. 인간이 최종 실행은 하지만, AI가 초안 작성 · 분석 · 검색을 지원함.

아키텍처의 특징:

• RAG (검색 증강 생성) 도입이 일반적임. 사내 지식 베이스나 과거 티켓을 벡터 DB에 저장하여 LLM이 참조. - API 연동은 참조계가 중심. CRM이나 티켓 시스템에서 데이터를 취득하여 AI가 요약 · 제안을 생성. 쓰기는 인간이 수행. - 가드레일(Guardrail)은 프롬프트 레벨. 시스템 프롬프트로 「기밀 정보를 출력하지 않는다」, 「특정 포맷을 따른다」 등을 지정.

구현 예시 (고객 지원용):

# 의사 설정: 워크플로우 지원을 위한 AI 에이전트 설정
workflow_assistant:
name: "case_summarizer"
...

엔지니어링 상의 포인트:

• 측정 가능해짐: 「AI 지원 후 평균 처리 시간」, 「초기 해결률의 변화」를 추적할 수 있음. - 리스크가 낮음: 인간이 모든 액션을 실행하므로 잘못된 쓰기가 발생하지 않음. - 한계: 고빈도 프로세스의 근본적인 경제성은 변하지 않음. 인간이 병목 현상으로 계속 남음.

상태: AI가 도구를 호출하고, 제한적인 액션을 실행함. 여기서 비로소 「에이전트」라고 부를 수 있는 동작이 시작됨.

아키텍처의 필수 요소:

• Function Calling / Tool Use: LLM이 정의된 API를 선택 · 호출. 예: 환불 API, 티켓 생성 API, 재고 확인 API. - ID 및 액세스 제어: 에이전트에 서비스 계정 (Service Account) 을 부여. 인간과 동일한 IAM 정책으로 관리. - 정책 엔진 (Policy Engine): 「이 조건하에서만 액션을 허가한다」라는 규칙을 실행 시점에 평가. 예: 「환불 금액이 5,000엔 미만이고 정책 위반이 없는 경우에만 실행 가능」. - 감사 로그 (Audit Log): 모든 도구 호출, LLM의 응답, 인간의 승인/거절을 기록. - Human-in-the-loop: 특정 조건(고액 거래, 첫 방문 고객 등)에서는 에이전트는 제안까지만 수행하고 인간의 승인을 기다림.

구현 예시 (환불 에이전트):

의사 코드: 정책 엔진을 통한 액션 제어

def can_execute_refund(agent_id: str, refund_amount: float, customer_tier: str) -> bool:

에이전트 권한 확인

...

엔지니어링 측면의 함정 (Pitfalls):

• API의 비동기성 (Asynchronicity): 에이전트가 동기적인 API 호출을 전제로 하면, 장시간 처리나 타임아웃으로 인해 에러가 빈번하게 발생한다. 이벤트 기반 아키텍처 (Event-driven Architecture) (큐, Webhook)가 필요하다.
• 에러 핸들링 (Error Handling)의 복잡성: API가 503 에러를 반환한다면? 부분적으로 성공했다면? 롤백 (Rollback)이 가능한가? 이를 에이전트의 프롬프트 (Prompt)만으로 해결하는 것은 불가능하다. **오케스트레이션 레이어 (Orchestration Layer)**에서 트랜잭션 관리가 필요하다.
• 프롬프트 인젝션 (Prompt Injection): 악의적인 사용자 입력이 에이전트로 하여금 의도하지 않은 API 호출을 수행하게 할 가능성이 있다. **입력 데이터 정화 (Input Sanitization)**와 **도구 호출 화이트리스트 (Tool Calling Whitelist)**가 필수적이다.

판단 기준:

• 에이전트에게 **전용 IAM 역할 (IAM Role)**이 할당되어 있는가?
• "읽기 전용 API"와 "쓰기 API"가 명확하게 분리되어 있는가?
• 에이전트의 액션을 실시간으로 시각화하는 대시보드가 있는가?

상태: 여러 에이전트가 오케스트레이터 (Orchestrator) 아래에서 협력하며, 엔드 투 엔드 (End-to-end) 가치 스트림 (예: 견적부터 청구까지, 인시던트 발생부터 해결까지)을 처리한다.

아키텍처 특징:

• 오케스트레이터 에이전트 (Orchestrator Agent): 태스크를 분해하여 적절한 에이전트에게 할당한다. 상태 관리를 수행하며 전체 진행 상황을 추적한다.
• 에이전트 카탈로그 (Agent Catalog): 각 에이전트의 책임, 사용 가능한 도구, 담당 소유자를 관리하는 레지스트리 (Registry).
• 교차 기능적 데이터 동기화 (Cross-functional Data Synchronization): 부서 간에 데이터 불일치가 발생하면 에이전트들끼리 모순된 판단을 내리게 된다. **마스터 데이터 관리 (MDM)**의 중요성이 커진다.

구현 예시 (구매 주문의 예외 처리):

• 구매 에이전트: 주문 요청을 수신하고 정책 체크를 수행한다. 재고 부족을 감지한다.
• 재고 에이전트: 대체 창고의 재고 상황을 확인하고 납기를 계산한다.
• 정책 에이전트: "고객 우선순위가 높은 경우 긴급 조달을 허용한다"라는 규칙을 평가한다.
• 오케스트레이터: 위 결과들을 통합하여 구매 담당자에게 "대안 A: 별도 창고에서 배송 (+2일), 대안 B: 긴급 조달 (+5만 엔)"을 제시한다. 인간이 선택한다.

엔지니어링 측면의 과제:

• 에이전트 스프롤 (Agent Sprawl): 관리되지 않는 에이전트가 증식하여 누가 무엇을 하고 있는지 알 수 없게 된다. 에이전트 라이프사이클 관리 (Agent Lifecycle Management) (등록, 버전 관리, 폐기)가 필요하다.
• 충돌 해결 (Conflict Resolution): 에이전트 A는 "승인"을, 에이전트 B는 "거절"을 권장할 경우 어떻게 할 것인가? 우선순위 규칙과 에스컬레이션 경로 (Escalation Path)를 설계해야 한다.
• 책임 소재: 멀티 에이전트의 판단이 틀렸을 경우, 어떤 에이전트의 어떤 판단이 원인인지 추적할 수 있는가? 분산 트레이싱 (Distributed Tracing) (OpenTelemetry 등)의 도입이 거의 필수적이다.

상태: 에이전트는 더 이상 실험 프로젝트가 아니다. 기업 실행 레이어의 공식적인 일부로서, 통합 플랫폼, 거버넌스 (Governance), 운영 모델이 확립되어 있다.

아키텍처 특징:

• 통합 에이전트 플랫폼 (Unified Agent Platform): 에이전트의 개발, 배포, 모니터링, 관리를 일원화하는 내부 플랫폼.
• 정책의 코드화 (Policy as Code): 모든 거버넌스 규칙이 코드로 작성되어 CI/CD 파이프라인에서 관리된다.
• 인간-AI 팀의 퍼포먼스 지표: 에이전트 단독의 정확도뿐만 아니라, "인간 + 에이전트" 팀으로서의 생산성, 품질, 비용을 측정한다.

중요한 오해: Level 5는 완전 자동화가 아니다. 오히려 "언제 에이전트에게 맡기고, 언제 인간이 개입해야 하는지"의 경계가 명확하게 정의된 상태를 의미한다. 일부 도메인에서는 높은 자율성을 가지며, 다른 도메인에서는 인간 참여 (Human-in-the-loop)가 지배적이다. 중요한 것은 자율성의 높낮이가 아니라 일관성 있는 운영 규율이다.

대부분의 조직에서는 다음 세 가지 패턴 중 하나가 현실적이다.

• Level 1 → Level 2: 우선순위가 높은 2~3개의 워크플로우 (Workflow)를 선정하여 AI를 공식 프로세스에 통합한다. 사이클 타임 (Cycle time)과 품질을 측정하고, 기본적인 가드레일 (Guardrails)을 구축한다. -
  Level 2 → Level 3: 리스크가 낮은 액션 (예: 정형화된 티켓 생성, 정책 체크)부터 시작한다. ID 관리, 정책 엔진 (Policy engine), 승인 워크플로우, 감사 로그 (Audit log)를 정비한다. API와 데이터 기반의 성숙도를 확인한다. -
  Level 3 → Level 4: 에이전트의 스프로울 (Sprawl, 무분별한 확산)을 방지한다. 오케스트레이터 (Orchestrator)와 에이전트 카탈로그를 구축한다. 교차 기능적 (Cross-functional) 소유권을 확립한다. 고립된 유스케이스 (Use case)가 아닌, 밸류 스트림 (Value stream) 단위로 관리를 시작한다.

Level 5로의 풀 점프 (Full jump)를 12개월 안에 목표로 할 수 있는 조직은, 이미 디지털 코어 (Digital core), 거버넌스 (Governance), 운영 규율이 성숙해 있는 경우에 한정된다.

'에이전트'의 정의를 조직 내에서 통일한다: 코파일럿 (Copilot), 워크플로우 지원, 액션 실행 에이전트를 명확히 구분한다. -
API와 데이터 기반의 성숙도를 점검한다: Level 3를 목표로 한다면, 쓰기 API의 안정성, 에러 핸들링 (Error handling), 비동기 처리 (Asynchronous processing) 대응은 필수적이다. -
거버넌스를 뒤로 미루지 않는다: 에이전트가 움직이기 시작한 후에는 늦다. IAM, 정책 엔진, 감사 로그는 선행 투자로 간주해야 한다. -
측정할 수 없는 것은 개선할 수 없다: 개인의 만족도가 아니라, 프로세스의 사이클 타임, 에러율, 비용 절감액으로 AI의 가치를 측정한다.

성숙도 모델은 조직 전체가 일률적으로 동일한 수준을 목표로 할 필요는 없다. HR은 Level 1, 재무는 Level 2, 고객 운영 (Customer operations)은 Level 3인 상태도 있을 수 있다. 중요한 것은, 우리가 지금 어디에 있으며, 다음에 어떤 기반을 마련해야 하는지를 정확하게 파악하는 것이다.