「AI 에이전트」의 도입이 진행됨에 따라, 많은 기업이 「에이전트의 난립」이라는 새로운 과제에 직면하고 있습니다. 이 기사에서는 개별 유스케이스 (Use Case)에 최적화된 **에이전트 애플리케이션 (Agent Application)**과 이를 뒷받침하는 공통 기반인 **에이전트 플랫폼 (Agent Platform)**의 차이를 명확히 합니다.

그 위에, 실제로 시스템 설계에 적용하기 위한 3층 레퍼런스 아키텍처 (Runtime / Context & Knowledge / Governance & Operations)를 해설합니다. 특히 API 연동, 권한 제어, 감사, 평가, 가드레일 (Guardrail)과 같은 운용·거버넌스 관점에 초점을 맞추어, 확장 가능하고 안전한 에이전트 운용 기반의 구축 순서를 제시합니다.

어느 기업에서 다음과 같은 상황이 일어나고 있다고 상상해 보십시오.

• 경리 팀이 월간 결산을 40% 단축하는 에이전트를 구축
• 구매 부서가 그것을 보고 발주 처리용 에이전트를 별도로 개발
• 고객 서비스 팀이 문의 해결 에이전트를 프로토타입으로 제작
• IT 운용 부서가 인시던트 트리아지 (Incident Triage)용 에이전트를 설계

각 팀은 최선의 의도로 각자 독자적인 스택 (Stack)을 선택했습니다. 경리는 스프레드시트로 로그를 관리하고, 구매는 다른 모델 게이트웨이 (Model Gateway)를 사용하며, 고객 서비스는 로컬 파일에 컨텍스트 (Context)를 저장하고, IT 운용은 독자적인 승인 메커니즘을 구현했습니다.

개별적인 판단은 합리적이지만, 결과적으로 「도구를 공유할 수 없다」, 「액세스 제어가 제각각이다」, 「감사 로그 형식을 통일할 수 없다」, 「에이전트 간의 품질 비교가 불가능하다」는 상태에 빠지게 됩니다. 이는 에이전트 애플리케이션을 양산한 결과이며, 에이전트 플랫폼의 부재가 원인입니다.

다음 도표는 엔터프라이즈 에이전트 플랫폼의 참조 아키텍처입니다. 3개의 층이 독립적으로 스케일 (Scale)할 수 있도록 설계되어 있습니다.

이 층은 에이전트가 실제로 태스크 (Task)를 실행하기 위한 기반입니다. 「모델을 호출하여 결과를 반환한다」는 것만으로는 불충분하며, 엔터프라이즈에서 요구되는 5가지 컴포넌트 (Component)를 이해해야 합니다.

가장 과소평가되기 쉬운 컴포넌트입니다. 단순한 모델 연결 래퍼 (Wrapper)가 아니라 다음과 같은 책임을 가집니다.

태스크에 따른 모델 선택: 단순 분류는 경량 모델, 복잡한 추론은 고성능 모델을 자동 선택 -
폴백 (Fallback) 처리: 특정 모델 장애 시, 자동으로 대체 모델로 라우팅 -
비용 제어 및 가시화: 모든 모델 호출의 로그 취득 및 비용 집계

# 모델 게이트웨이의 라우팅 설정 예시 (개념)
routing_rules:
- task_type: "classification"
...

**툴 레지스트리 (Tool Registry)**는 카탈로그입니다. 각 툴의 메타데이터 (소유자, 권한, 리스크 레벨)를 관리합니다. **툴 실행 서비스 (Tool Execution Service)**는 실제 호출 전에 다음과 같은 검증 (Validation)을 실시합니다.

• 파라미터 (Parameter)의 타입 및 범위 체크
• 호출자의 권한 확인
• 정책 위반 여부
• 임계값을 초과하는 경우 승인 플로우 (Flow)로 유도

# 툴 실행 전의 정책 체크 (의사 코드)
def execute_tool(tool_name: str, params: dict, user_context: dict):
tool = tool_registry.get(tool_name)
...

두 가지는 혼동되기 쉽지만, 명확히 분리해야 합니다.

State: 워크플로우 (Workflow)의 진행 상황 (어느 단계까지 완료되었는가). 엄격한 거버넌스와 감사가 필요. -
Memory: 세션을 넘나드는 컨텍스트 정보. 유연성은 높지만 권한과 보유 정책을 따라야 함.

정책은 문서나 코드에 산재시키지 말고, **툴 호출, 데이터 액세스, 액션 실행 직전에 명시적인 체크포인트 (Checkpoint)**로서 배치합니다.

많은 에이전트 장애의 원인은 모델이 아니라 컨텍스트의 오류입니다. 정보가 오래되었거나, 불완전하거나, 권한 부족으로 액세스할 수 없는 경우가 대부분을 차지합니다.

가장 중요한 기능입니다. 에이전트는 「의미적으로 유사하다」는 이유만으로 도큐먼트를 가져와서는 안 됩니다. 다음과 같은 정보를 고려해야 합니다.

• 누가 (사용자 ID)
• 어떤 에이전트가 (에이전트 ID)
• 어느 도메인의 처리 중인가 (도메인 컨텍스트)
• 어떤 데이터에 액세스 권한이 있는가 (권한 매트릭스)

-- 권한 인식형 검색 (Permission-aware Search)의 개념 (의사 SQL)
SELECT content FROM documents
WHERE semantic_similarity(query, content) > 0.8
...

모든 케이스에서 지식 그래프 (Knowledge Graph)가 필요한 것은 아닙니다. 단순한 지식 어시스턴트라면 벡터 (Vector) + 메타데이터 (Metadata)만으로도 충분합니다. 하지만 공급망 혼란 분석이나, 여러 엔티티 (Entity)에 걸친 회계 예외 처리에서는 그래프 기반 추론 (Graph-based Reasoning)이 효과를 발휘합니다.

이 계층은 "번거로우니까 나중에"라며 미뤄지기 쉽지만, 신뢰할 수 있는 에이전트와 배포할 수 없는 에이전트를 가르는 분수령입니다.

**에이전트 레지스트리 (Agent Registry)**는 공식 카탈로그입니다. 다음 정보를 일원 관리합니다.

• 에이전트 이름, 목적
• 비즈니스 오너 (Business Owner), 테크니컬 오너 (Technical Owner)
• 리스크 레벨, 사용 도구, 데이터 소스
• 자율성 레벨 (assist / semi-auto / auto)
• 라이프사이클 상태 (개발/테스트/운영/폐기)

**정책 레지스트리 (Policy Registry)**는 횡단적인 규칙을 관리합니다.

• 거래 임계값 (예: 100만 엔 이상의 지급은 승인 필수)
• 도구 제한 (예: 외부 API 호출은 특정 에이전트만 허용)
• 리스크 분류 기준

"모든 에이전트에 동일한 제어"를 적용하는 것은 비효율적입니다. 리스크 레벨에 따라 제어를 달리합니다.

에이전트의 품질을 담보하기 위한 테스트 환경입니다. 다음 요소들을 포함합니다.

• 골든 데이터셋 (Golden Dataset): 정답이 알려진 테스트 케이스
• 시나리오 테스트 (Scenario Test): 다단계 워크플로우 테스트
• 정책 컴플라이언스 체크 (Policy Compliance Check): 규칙 위반 여부의 자동 검증
• 회귀 테스트 (Regression Test): 모델이나 프롬프트 (Prompt) 변경 시 품질 저하 탐지
• 운영 샘플링 (Production Sampling): 실제 운영 후의 품질 모니터링

플랫폼 구축에서 가장 흔한 실패는 "한 번에 전부 만들려고" 하는 것입니다. 결과적으로 시간이 오래 걸리고, 비용이 불어나며, 비즈니스 니즈와 괴리됩니다.

권장하는 구축 순서:

• 모델 게이트웨이 (Model Gateway) (최우선) - 모든 에이전트에 표준적인 모델 액세스, 로그 취득, 폴백 (Fallback), 비용 제어를 제공

• 도구 레지스트리 및 실행 (Tool Registry & Execution) (에이전트가 업무 시스템에 접촉하는 시점) - 통합이 무분별해지고 감사 불가능해지는 것을 방지

• 로그, 트레이스, 관측성 (Logs, Traces, Observability) (스케일 전) - 에이전트의 행동, 비용, 응답 시간을 가시화

• 권한 적용 및 정책 체크 (Permission Enforcement & Policy Check) (기밀 데이터나 액션 실행 시) - 데이터 유출 및 부정 조작을 방지

• 평가 하네스 (Evaluation Harness) (모델/프롬프트 변경이 빈번해지는 시점) - 품질 저하를 조기에 발견

• 메모리 서비스 및 에이전트 레지스트리 (Memory Service & Agent Registry) (필요에 따라) - 태스크 기반의 스테이트리스 (Stateless) 에이전트에는 당분간 불필요

중요한 원칙: 케이파빌리티 (Capability)는 반드시 실제 유스케이스에서 비롯되게 하십시오. 지식 그래프를 "언젠가 쓸지도 모르니까"라는 이유로 구축하면, 아무도 사용하지 않는 고가의 자산이 됩니다. 우선 AP 예외 처리와 IT 인시던트 트리아지 (Incident Triage)라는 두 가지 유스케이스부터 시작하면, 모델 게이트웨이, 도구 레지스트리, 관측성, 권한 인식형 검색, 승인 워크플로우가 최우선으로 필요하다는 것을 자연스럽게 알게 될 것입니다.

좋은 레퍼런스 아키텍처 (Reference Architecture)란 종이 위에서 가장 완벽한 것이 아닙니다. 다음 질문에 자신 있게 답할 수 있는지 여부입니다.

"내일 회계, 구매, 고객 운영, IT 부서에 10개의 새로운 에이전트를 추가한다면, 에이전트 스프로울 (Agent Sprawl, 난립)을 일으키지 않고 안전하고 확장 가능하게 운영할 수 있는 공유 기반이 있는가?"

만약 대답이 "No"라면, 다음 우선순위는 에이전트의 양산이 아니라 플랫폼의 강화입니다.