「AI 에이전트」가 단순한 챗봇을 넘어 ERP나 CRM과 같은 기존 시스템과 연계하여 실제 업무 프로세스를 실행하게 될 때, 설계자는 무엇을 고려해야 하는가.

본 기사에서는 엔터프라이즈 시스템에서의 AI 에이전트 아키텍처(Architecture)를 Agent층·Context층·Control층의 3개 층으로 분해하여, 각 층의 책임과 구현상의 판단 기준을 해설한다. 특히 API 연계·권한 관리·감사·운영 설계에 초점을 맞추어, 현장 엔지니어가 즉시 설계에 반영할 수 있는 관점을 제공한다.

많은 조직은 AI 에이전트를 '더 똑똑한 챗봇'의 연장선상에서 파악하고 있다. 더 좋은 모델, 더 좋은 프롬프트(Prompt), 더 좋은 UI──하지만 이것만으로는 엔터프라이즈의 요구사항을 충족할 수 없다.

엔터프라이즈 시스템에서 AI 에이전트에게 요구되는 것은 **「답하는 것」이 아니라 「실행하는 것」**이다. 월말 결산 처리에서 에이전트는 여러 시스템으로부터 데이터를 수집하고, 분개(仕訳)의 이상을 감지하며, 승인자에게 권장 사항을 생성한다. 이 일련의 흐름을 감사 가능하고 제어 가능한 형태로 실현해야 한다.

그러기 위해서는 프롬프트 엔지니어링(Prompt Engineering)만으로는 도달할 수 없다. 시스템 아키텍처로서의 설계가 필요하다.

다음 그림이 보여주는 바와 같이, 에이전트 시스템은 기존의 디지털 코어(ERP/CRM/HRIS/데이터 기반) 위에 3개의 층으로 구축된다.

가장 큰 설계 실수는 하나의 범용 에이전트에게 모든 것을 맡기는 것이다. 제어 불능, 테스트 곤란, 그리고 비즈니스로부터의 신뢰를 얻을 수 없게 된다.

실천적인 설계에서는 다음과 같이 에이전트 타입을 분리한다.

이러한 분리를 통해 각 에이전트의 스코프(Scope)가 명확해지며, 테스트·거버넌스·소유권 관리가 극적으로 용이해진다.

• Orchestrator는 「무엇을」 「어떤 순서로」 실행할지만 알고 있으면 된다. 도메인 지식은 갖지 않는다.
• Specialist Agent는 해당 도메인에 한정된 API·데이터 소스에만 액세스하도록 한다.
• Task Agent는 멱등성(Idempotency)을 보장하여 재실행 가능한 설계로 만든다.

에이전트가 올바르게 판단하기 위해서는 단순한 문서 검색(RAG) 이상의 문맥(Context)이 필요하다.

「이 고객은 어떤 계약에 연결되어 있는가」 「이 송장은 어떤 발주서에 대응하는가」──이러한 관계성을 이해하기 위해 **지식 그래프(Knowledge Graph)**나 **엔터프라이즈 관계 모델(Enterprise Relational Model)**의 도입이 유효하다.

# 의사 코드: 엔티티 관계 쿼리
context = agent_context.query(
entity="Invoice-12345",
...

가장 간과하기 쉽지만 치명적인 것이 권한을 고려하지 않은 검색이다. HR 에이전트가 전 직원의 급여 데이터를 가져올 수 있거나, 구매 에이전트가 전략적 계약을 누구나 참조할 수 있게 되는 것──이는 중대한 데이터 유출 경로가 된다.

설계 원칙:

• 검색 레이어는 호출 측의 사용자 컨텍스트(역할, 부서, 권한)를 항상 수신한다.
• 에이전트 자신에게도 「스코프」를 설정하여, 그 스코프 외의 데이터에는 액세스할 수 없도록 한다.
• 벡터 DB의 메타데이터 필터링이나 그래프 DB의 에지(Edge) 권한 제어를 활용한다.

에이전트가 「답하는 것」에서 「실행하는 것」으로 이행할수록 이 층의 중요성은 커진다. 컴플라이언스의 부속물이 아니라, 아키텍처의 핵심으로 위치시켜야 한다.

모든 에이전트에는 명확한 ID가 필요하다. 시스템은 「어떤 에이전트가」 「누구를 대신하여」 「어떤 권한으로」 「어떤 시스템에」 「어떤 프로세스 컨텍스트에서」 액션을 실행했는지를 항상 파악할 수 있어야 한다.

원칙: 에이전트에게는 해당 태스크 스코프(Task Scope)에 필요한 최소한의 권한만을 부여한다. 인간을 대신하여 동작하는 경우라도, 그 인간의 권한을 상속받는 것이 아니라 에이전트 전용 서비스 계정(Service Account)을 사용한다.

모든 액션을 자동으로 실행해도 되는 것은 아니다. 다음 조건에서는 인간의 승인을 필수적으로 요구하도록 설계한다.

• 거래 금액이 임계값을 초과하는 경우
• 기밀 데이터(개인정보, 전략 정보)를 다루는 경우
• 모델의 신뢰도(Confidence)가 낮은 경우
• 리스크 카테고리가 높은 경우
• 업무 영향도가 큰 경우 (예: 발주 확정, 거래 취소)

에이전트는 권장 사항과 근거를 준비하고, 인간이 최종 판단을 내린다. 이러한 "인간 참여형(Human-in-the-loop)" 설계는 비상시의 폴백(Fallback)이 아니라, 통상 운영의 일부로서 통합한다.

최소한 다음 정보는 추적 가능해야 한다.

• 어떤 에이전트가 액션을 실행했는가
• 어떤 데이터를 입력값으로 사용했는가
• 어떤 도구(Tool) 및 API를 호출했는가
• 어떤 정책(Policy)이 적용되었는가
• 어떤 출력이 생성되었는가
• 인간의 승인이 필요했던 경우, 누가 승인했는가

# 감사 로그(Audit Log)의 최소 스키마 예시
audit_entry:
agent_id: "procurement-specialist-v2"
...

스코프(Scope)에서 시작하라, 모델의 능력에서 시작하지 마라

가장 강력한 모델을 먼저 선택한 뒤 과제를 찾는 것이 아니라, 비즈니스 아웃컴(Business Outcome)을 정의하고, 에이전트의 스코프를 결정한 뒤, 필요한 능력을 선정한다. -
모든 액션은 설명 가능하고 추적 가능해야 한다

성공했는지 여부뿐만 아니라, 어떻게 성공했는지를 설명할 수 있어야 한다. -
인간에 의한 오버라이드(Override)는 핵심 기능이다

비상시의 폴백이 아니라, 통상 운영의 일부로서 설계한다. -
그레이스풀 디그레이데이션(Graceful Degradation)을 설계하라

모델이 실패했을 때, 도구를 사용할 수 없을 때, 검색이 불충분할 때── 시스템은 자율 실행에서 권장 제시로, 멀티 스텝(Multi-step) 실행에서 초안(Draft) 출력으로, 셀프 서비스에서 인간으로의 핸드오프(Handoff)로 단계적으로 축소(Degrade)된다. -
모듈성(Modularity)을 우선하라

하나의 거대한 에이전트보다 여러 개의 작은 에이전트가 테스트, 교체, 거버넌스 측면에서 용이하다. 오케스트레이션(Orchestration)의 오버헤드는 대규모 엔터프라이즈에서는 허용 가능한 수준이다.

CIO에게: 당신의 엔터프라이즈 아키텍처는 에이전트를 "진정한 운영 아이덴티티(Operational Identity)"로 취급하고 있는가? 아니면 단순한 애플리케이션 기능의 일부로 취급하고 있는가? -
COO에게: 어떤 프로세스가 인간과 에이전트의 협업 운영을 진정으로 견뎌낼 수 있는가? 어떤 프로세스는 아직 자율성을 허용할 수 없는가? -
CHRO에게: 실행이 디지털 노동(Digital Labor)으로 전환될 때, 인간의 역할은 어떻게 강화되어야 하는가? -
변혁 리더에게: 확장 가능한 기반을 구축하고 있는가? 아니면 운영 모델이 될 수 없는 데모들을 수집하고 있을 뿐인가?

원문 기사(일본어):