AI 에이전트에게 필요한 것은 '프롬프트'가 아니라 '아키텍처'──3층 구조로 설계하는 엔터프라이즈 AI 구현론

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

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

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

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

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

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

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

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

타입	책임	구체적인 예시
Orchestrator Agent	워크플로우 진행 관리, 타 에이전트로의 디스패치(Dispatch)	결산 처리의 각 단계를 제어하고 전문 에이전트를 호출함
Specialist Agent	특정 도메인의 깊은 판단	구매 정책 해석, 계약 분석, 인시던트 원인 특정
Task Agent	단일·반복 작업의 실행	송장에서의 데이터 추출, 폼(Form)의 유효성 검사
Human Interface Agent	인간과의 대화 창구	채팅, 포털, 메일을 통한 문의 접수

이러한 분리를 통해 각 에이전트의 스코프(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)으로 전환될 때, 인간의 역할은 어떻게 강화되어야 하는가? -
변혁 리더에게: 확장 가능한 기반을 구축하고 있는가? 아니면 운영 모델이 될 수 없는 데모들을 수집하고 있을 뿐인가?

원문 기사(일본어):