Agentic AI Platform 아키텍처
개요
Agentic AI 플랫폼은 에이전트가 모델과 도구를 호출해 작업을 수행하는 데 필요한 실행 환경입니다. 이 문서는 구성 요소를 요청 처리에 참여하는 기능과 여러 기능에 공통으로 적용하는 운영 책임으로 나눕니다.
요청 처리 기능은 가속 컴퓨팅 인프라, 모델 서빙, 데이터·지식·메모리, 에이전트 오케스트레이션, 지능형 추론 라우팅, 멀티 채널 노출의 6개 런타임 레이어로 정리합니다. 관측성·평가, 거버넌스·안전·주권, 모델 라이프사이클(FMOps)은 여러 레이어에 걸쳐 적용하므로 3개 횡단 플레인으로 구분합니다. 각 도전과제에 대한 상세 분석은 기술적 도전과제 문서를 참조하세요.
이 문서는 솔루션 아키텍트, 플랫폼 엔지니어, DevOps 엔지니어를 대상으로 합니다. Kubernetes와 AI/ML 워크로드에 대한 기본적인 이해가 필요합니다.
레이어와 플레인의 분리
기존 레이어 모델은 평가, 드리프트 감지, 피드백 같은 관심사를 여러 레이어에 중복 배치하여 책임 경계가 모호했습니다. 본 아키텍처는 이를 두 종류의 구성 요소로 명확히 구분합니다.
- 런타임 레이어(Runtime Layer): 요청 처리에 참여하는 기능을 책임별로 묶은 6개 계층입니다. 레이어 번호는 책임의 추상화 수준(Layer 1 인프라 → Layer 6 경험)을 나타낼 뿐, 요청이 번호 순서대로 한 방향으로만 흐른다는 뜻은 아닙니다. 실제 요청은 Layer 6에서 진입해 Layer 5 게이트웨이와 Layer 4 Agent로 내려간 뒤, 추론이 필요하면 다시 Layer 5 게이트웨이를 거쳐 Layer 2 모델 서빙을 호출하는 되돌이(loop) 구조를 가집니다(자세한 경로는 아래 데이터 플로우 참조). 플랫폼은 아래(Layer 1)에서 위로 구축됩니다.
- 횡단 플레인(Cross-cutting Plane): 특정 레이어에 속하지 않고 모든 레이어를 수직으로 관통하는 3개 관심사입니다. 관측성·평가, 거버넌스·안전·주권, 모델 라이프사이클이 여기에 해당합니다.
품질 평가(RAGAS), 드리프트 감지, 피드백 수집, Guardrails는 단일 레이어의 기능이 아니라 전 레이어에 걸쳐 작동하는 관심사입니다. 이를 별도 레이어로 두면 같은 기능이 여러 레이어에 중복 기술되어 책임이 분산됩니다. 플레인으로 분리하면 "어디서 추론하는가(레이어)"와 "어떻게 관측·통제·개선하는가(플레인)"가 직교(orthogonal)하게 정리됩니다. 6개 런타임 레이어와 3개 횡단 플레인이라는 구체적 분해는 본 문서가 채택한 설계이며, 공개된 참조 모델을 그대로 옮긴 것이 아닙니다. 이 분해는 Chip Huyen의 AI Engineering(2025)이 제시하는 Infrastructure / Model / Application 3계층, FTI(Feature–Training–Inference) 파이프라인 패턴, AWS Well-Architected Generative AI Lens의 전 계층을 관통하는 운영 관점과 문제의식(관심사 분리와 횡단 운영)이 유사합니다. 다만 레이어·플레인 개수와 경계가 이들 자료와 일대일로 대응하지는 않으므로, 정확한 대응 관계는 원문을 함께 확인하시기 바랍니다.
전체 시스템 아키텍처
Agentic AI Platform은 6개 런타임 레이어와 이를 관통하는 3개 횡단 플레인으로 구성됩니다. 각 레이어는 명확한 책임을 가지며, 느슨한 결합을 통해 독립적인 확장과 운영이 가능합니다.
설계 원칙:
- 레이어와 플레인의 직교 분리: "어디서 추론하는가(6 레이어)"와 "어떻게 관측·통제·개선하는가(3 플레인)"를 분리하여 관심사 중복을 제거
- AI Infrastructure를 1급 레이어로: 가속 컴퓨팅(GPU·Trainium·Inferentia)과 그 오케스트레이션·모니터링·성능 최적화를 최하단 독립 레이어(Layer 1)로 명시
- Self-hosted + External AI 하이브리드: 자체 호스팅 모델과 외부 AI Provider API를 동일한 게이트웨이(Layer 5)에서 통합 관리
- 2-Tier Cost Tracking: 인프라 레벨(가속기 시간 · 모델 단가 x 토큰)과 애플리케이션 레벨(Agent 스텝별 비용) 이중 추적
- MCP/A2A 표준 프로토콜: Agent와 도구 간(MCP), Agent 간(A2A) 통신을 표준화하여 상호운용성 확보
- Closed-loop FMOps: 프로덕션 피드백이 재학습을 트리거하고, 새 모델이 평가 게이트를 통과해야 배포되는 폐쇄 루프 (모델 라이프사이클 플레인)
- Sovereignty-aware: 데이터 주권 요구를 SCP 리전 강제, in-country 리전, 하이브리드/온프레미스 자체 호스팅으로 충족 (거버넌스 플레인)
레이어 & 플레인 역할
| 레이어 | 역할 | 주요 컴포넌트 |
|---|---|---|
| Layer 6: Experience & Channels | 사용자·시스템 진입점, 멀티 채널 노출 | API · gRPC, Agent SDK, Web UI, 채널 연동 |
| Layer 5: Gateway & Routing | 인증, 지능형 추론 라우팅, 비용 가드레일 | 2-Tier Gateway, Cascade Router, KV Cache-aware 라우팅, Rate Limit |
| Layer 4: Agent Runtime & Orchestration | Agent 실행 루프, 메모리, 도구·멀티에이전트 협업 | Agent Runtime, Tool Registry (MCP), A2A, State Store |
| Layer 3: Data, Knowledge & Memory | RAG 검색, 지식 그래프, 세션·장기 메모리 | Vector DB, Knowledge/Feature Store, Cache, Object Storage |
| Layer 2: Model Serving & Inference | LLM·비-LLM 추론 엔진, 분산 추론, 모델 레지스트리 | vLLM, llm-d, Triton, Model Registry |
| Layer 1: AI Infrastructure | 가속 컴퓨팅, GPU 오케스트레이션·모니터링·성능 최적화 | GPU · Trainium · Inferentia, Karpenter · Kueue · DRA, MIG, DCGM · Neuron Monitor, EFA |
| 플레인 | 역할 | 주요 컴포넌트 |
|---|---|---|
| 관측성 & 평가 | 트레이싱, 메트릭, 비용 추적, 품질 평가, 드리프트 감지 | Langfuse, OpenTelemetry, RAGAS, Cost Tracking, Drift Detection |
| 거버넌스 · 안전 · 주권 | Guardrails, 정책·RBAC, 컴플라이언스, 데이터 주권·리전 강제 | NeMo Guardrails, OIDC/RBAC, SCP 리전 강제, ISMS-P · SOC2 |
| 모델 라이프사이클 (FMOps) | 학습·파인튜닝, 평가 게이트, 지속 학습(CT), 피드백 루프 | Training Pipeline, CT Scheduler, Eval Harness, Feedback Loop |
기존 8-레이어 모델과의 매핑
이전 버전은 8개 레이어를 사용했으나, 평가·드리프트·피드백·Guardrails가 여러 레이어에 중복되는 문제가 있었습니다. 다음과 같이 6 레이어 + 3 플레인으로 재정렬했습니다.
| 기존 (8-레이어) | 현재 (6 레이어 + 3 플레인) |
|---|---|
| Layer 1: Client & Feedback | Layer 6: Experience & Channels (Feedback → 라이프사이클 플레인) |
| Layer 2: Gateway & Governance | Layer 5: Gateway & Routing (Governance → 거버넌스 플레인) |
| Layer 3: Agent & Orchestration | Layer 4: Agent Runtime & Orchestration |
| Layer 4: Model Serving & Lifecycle | Layer 2: Model Serving (Lifecycle → 라이프사이클 플레인) |
| Layer 5: Data & Feature | Layer 3: Data, Knowledge & Memory |
| Layer 6: Observability & Insights | 관측성 & 평가 플레인 |
| Layer 7: Training & Feedback | 모델 라이프사이클 플레인 |
| Layer 8: Evaluation & Quality | 관측성 & 평가 플레인 + 거버넌스 플레인(Guardrails) |
| (없음) | Layer 1: AI Infrastructure (신규) |
주요 컴포넌트: 런타임 레이어
요청 경로의 역순(최하단 인프라 → 최상단 경험)으로 6개 레이어를 설명합니다. 플랫폼은 Layer 1에서 위로 구축됩니다. 요청 흐름은 Layer 6(진입) → Layer 5(게이트웨이) → Layer 4(Agent)로 내려가고, Agent가 추론이 필요하면 다시 Layer 5 게이트웨이를 거쳐 Layer 2(모델 서빙)를 호출하며, 모델 서빙은 Layer 1의 가속 컴퓨팅 위에서 실행됩니다.
Layer 1: AI Infrastructure
플랫폼의 최하단에서 가속 컴퓨팅 자원과 그 운영을 담당하는 레이어입니다. GPU·Trainium·Inferentia 같은 가속기는 Agentic AI에서 가장 비싼 자원이므로, 단순 프로비저닝을 넘어 오케스트레이션·모니터링·성능 최적화가 하나의 계층으로 통합되어야 합니다. 이 레이어는 다수의 컴포넌트가 조합되어 동작하며, 상위 레이어(Layer 2 모델 서빙)에 안정적인 가속 컴퓨팅 추상화를 제공합니다.
Karpenter(노드 공급), Kueue(작업 승인·쿼터), 디바이스 할당(DRA/MIG/Time-Slicing)은 서로 다른 제어 책임이며, 하나의 직렬 파이프라인이 아닙니다. Karpenter는 노드를 공급하고, Kueue는 쿼터 안에서 작업을 승인하며, 디바이스 할당 계층은 승인된 Pod에 가속기를 배정합니다. 세 책임은 독립적으로 설정·운영됩니다.
| 기능 영역 | 책임 | 주요 컴포넌트 |
|---|---|---|
| 가속 컴퓨팅 | LLM·비-LLM 추론/학습용 가속기 제공 | NVIDIA GPU, AWS Trainium2/Inferentia2 |
| 노드 오케스트레이션 | 워크로드 기반 동적 노드 프로비저닝, Spot 활용 | Karpenter, Cluster Autoscaler |
| 작업 스케줄링 | GPU 작업 큐잉, 팀별 쿼터, 공정 분배 | Kueue, KAI Scheduler |
| GPU 분할 | 단일 GPU를 다중 워크로드에서 사용하도록 분할 (방식별 격리 수준 상이, 아래 참조) | MIG, Time-Slicing, DRA |
| 가속기 모니터링 | 사용률·온도·메모리·전력 실시간 추적 | DCGM Exporter, Neuron Monitor |
| 성능 최적화 | 토폴로지 인식 배치, 고속 네트워크 | NVLink/NVSwitch 인지 스케줄링, EFA |
MIG, Time-Slicing, DRA는 모두 "단일 GPU를 다중 워크로드가 쓰도록" 하지만, 제공하는 격리 수준이 다르므로 등가로 취급해서는 안 됩니다.
- MIG(Multi-Instance GPU): 지원되는 NVIDIA GPU(예: A100·H100)에서만 사용 가능한 하드웨어 파티셔닝입니다. GPU를 물리적으로 분할해 각 인스턴스에 전용 메모리·연산·캐시 경로를 할당하므로 인스턴스 간 메모리·성능 격리를 제공합니다.
- Time-Slicing: 하나의 GPU를 여러 워크로드가 **시분할(time-share)**로 번갈아 사용합니다. 메모리를 격리하지 않으므로 한 워크로드가 메모리를 과점하거나 다른 워크로드의 성능에 영향을 줄 수 있습니다. 하드웨어 격리가 필요 없는 저위험 공유에 적합합니다.
- DRA(Dynamic Resource Allocation): Kubernetes의 디바이스 요청·할당 메커니즘이며 그 자체가 분할 방식은 아닙니다. 드라이버에 따라 MIG 파티션이나 Time-Slicing 공유를 유연하게 요청·배정하는 데 사용됩니다.
따라서 규제 준수나 테넌트 간 강한 격리가 필요하면 MIG처럼 하드웨어 격리를 제공하는 방식을 선택해야 하며, Time-Slicing은 메모리 격리가 없다는 점을 전제로 사용해야 합니다.
왜 별도 레이어인가:
가속 컴퓨팅의 운영은 모델 서빙(Layer 2)과 책임이 분리됩니다. 모델 서빙은 "어떤 모델을 어떻게 추론하는가"를, AI Infrastructure는 "그 추론을 어떤 가속기 위에서 얼마나 효율적으로 돌리는가"를 책임집니다. GPU 모니터링·스케줄링·파티셔닝은 vLLM·llm-d 같은 서빙 엔진과 독립적으로 진화하며, 학습 워크로드(라이프사이클 플레인)도 동일한 인프라 레이어를 공유합니다.
GPU 노드 전략, Karpenter·KEDA·DRA 리소스 관리, NVIDIA GPU 스택(GPU Operator·DCGM·MIG), AWS Neuron 스택은 모델 서빙 & 추론 인프라의 가속 컴퓨팅 인프라 섹션을 참조하세요.
Layer 2: Model Serving & Inference
자체 호스팅 모델과 비-LLM 모델의 추론을 담당하는 레이어입니다. Layer 1이 제공하는 가속 컴퓨팅 위에서 동작하며, Layer 5 게이트웨이로부터 라우팅된 추론 요청을 처리합니다.
Self-hosted LLM Serving
PagedAttention, KV cache 최적화, 분산 추론을 지원하는 고성능 LLM 서빙 엔진을 운영합니다. vLLM, llm-d 등 오픈소스 추론 엔진을 Kubernetes 위에서 자동 확장합니다.
Non-LLM Serving
임베딩, 리랭킹, STT(Whisper) 등 비-LLM 모델은 Triton Inference Server 등으로 별도 서빙합니다. RAG 파이프라인(Layer 3)과 Agent(Layer 4)가 이를 호출합니다.
Model Registry
모든 배포된 모델의 버전, 메타데이터, 성능 지표를 중앙 집중 관리합니다. 모델 라이프사이클 플레인의 학습 파이프라인이 신규 모델을 등록하고, 평가 게이트를 통과한 모델만 이 레지스트리를 통해 서빙됩니다.
저장 구조:
s3://model-registry/
├── llama-3-70b/
│ ├── v1.0.0/
│ │ ├── model.safetensors
│ │ ├── metadata.json
│ │ └── evaluation_metrics.json
│ ├── v1.1.0/
│ └── v1.2.0/ (current production)
└── mistral-7b/
vLLM 모델 서빙, llm-d 분산 추론(KV Cache-aware 라우팅), MoE 서빙, NeMo 학습 프레임워크는 모델 서빙 & 추론 인프라를 참조하세요. 파인튜닝·증류 등 모델 변형은 모델 라이프사이클에서 다룹니다.
Layer 3: Data, Knowledge & Memory
Agent와 RAG 파이프라인이 사용하는 데이터·지식·메모리를 제공하는 레이어입니다.
Vector DB (RAG 저장소)
문서를 임베딩 벡터로 변환하여 저장하고, Agent 요청 시 유사도 검색으로 관련 컨텍스트를 제공합니다.
설계 고려사항:
- 멀티 테넌트 격리: Partition Key로 테넌트별 데이터를 물리적으로 분리합니다. 다만 Partition Key 자체는 데이터 배치 수단일 뿐 접근 통제가 아니므로, 테넌트가 자신의 파티션만 조회하도록 **쿼리 계층에서 테넌트 ID를 강제하는 인가(authorization)**를 함께 적용해야 교차 테넌트 조회를 막을 수 있습니다.
- 인덱스 전략: HNSW 인덱스로 고성능 Approximate Nearest Neighbor 검색
- 하이브리드 검색: Dense Vector + Sparse Vector (BM25) 결합으로 검색 품질 향상
Knowledge / Feature Store
ML 모델 학습과 추론에 사용되는 입력 특성(feature)과 도메인 지식을 관리합니다. 학습 시와 추론 시 **동일한 특성 정의(feature definition)**를 공유하는 것은 training-serving skew를 줄이기 위한 필요 조건이지만, 그것만으로 skew가 사라지지는 않습니다. 시점 정합성(point-in-time correctness)을 지키는 조인으로 라벨 누수(label leakage)를 방지하고, 특성 버전·구체화(materialization) 시점·온라인/오프라인 저장소 간 값 일치를 함께 보장해야 합니다. 온톨로지·지식 그래프를 결합하면 RAG 답변의 근거 추적을 돕고 환각을 줄이는 데 기여할 수 있으나, 그 효과는 그래프 품질·커버리지와 검색 설계에 따라 달라지므로 평가로 확인해야 합니다.
아키텍처:
Online Store (Redis/DynamoDB)
└─ 저지연 특성 조회 · 실시간 추론용 (목표 지연은 백엔드·데이터 규모·네트워크에 좌우되며, 예: 한 자릿수 ms는 측정으로 검증해야 함)
Offline Store (S3 Parquet)
└─ 대용량 특성 저장 · 배치 학습용
Cache · State · Object Storage
세션 상태, 단기 메모리, LangGraph checkpointer 상태를 저장합니다. Agent의 장기 실행 작업에 대한 체크포인팅과 복구를 지원합니다.
온톨로지 기반 Knowledge Feature Store의 3-plane 설계는 Knowledge Feature Store, Milvus 벡터 DB 운영은 Milvus 벡터 DB를 참조하세요.
Layer 4: Agent Runtime & Orchestration
AI 에이전트가 실행되는 레이어입니다. 각 에이전트는 독립적인 컨테이너로 실행되며, 워크플로우 엔진이 라이프사이클을 관리합니다.
| 기능 | 설명 |
|---|---|
| 상태 관리 | 대화 컨텍스트 및 작업 상태 유지, 체크포인팅 |
| 도구 실행 | MCP 프로토콜로 등록된 도구를 비동기 실행 |
| 메모리 관리 | 단기 메모리(세션)와 장기 메모리(벡터 DB) 결합 |
| Agent 간 통신 | A2A 프로토콜로 멀티 에이전트 협업 |
| 오류 복구 | 실패한 작업의 재시도 및 폴백 (동작·멱등성에 따라 정책을 구분, 아래 참조) |
Tool Registry
에이전트가 사용할 수 있는 도구를 중앙에서 선언적으로 관리합니다. 도구는 MCP 서버를 통해 노출되며, 하나의 MCP 서버는 보통 **여러 도구(tool)**를 제공합니다(도구와 서버는 1:1이 아닙니다). Agent는 MCP 표준 프로토콜로 이 도구들을 호출합니다. 외부 REST/gRPC API처럼 MCP를 직접 지원하지 않는 대상은 어댑터가 MCP 도구로 감싸 노출합니다. 한편 A2A(Agent-to-Agent)는 MCP와 별개의 프로토콜로, Agent 간 작업 위임에 사용됩니다. 아래 표의 "A2A 도구"는 A2A 호출을 MCP 도구 인터페이스로 감싼 어댑터를 가리키며, A2A가 MCP의 하위 기능이라는 뜻은 아닙니다.
| 도구 유형 | 용도 | 예시 |
|---|---|---|
| API 도구 | 외부 REST/gRPC 서비스 호출 (어댑터가 MCP 도구로 노출) | CRM 조회, 주문 처리 |
| 검색 도구 | 벡터 DB 검색, 문서 검색 | RAG 컨텍스트 보강 |
| 코드 실행 | 샌드박스 환경에서 코드 실행 | 데이터 분석, 계산 |
| A2A 도구 | 다른 Agent에 작업 위임 (A2A 프로토콜을 어댑터로 노출) | 전문 Agent 협업 |
"실패 시 자동 재시도"는 조회처럼 멱등(idempotent)한 동작에는 안전하지만, 결제·주문·메시지 발송처럼 부수효과가 있는 비멱등 동작에는 그대로 적용하면 중복 실행을 일으킬 수 있습니다. 특히 요청은 전송됐으나 응답이 유실된 커밋 불확실(uncertain commit) 상황에서는 단순 재시도가 위험합니다. 따라서 도구별로 (1) 멱등 키 또는 재시도 안전성 표시, (2) 비멱등 동작에 대한 조정(reconciliation)·확인 조회, (3) 지속적(durable) 체크포인트에 기반한 재개 계약을 정의하고, 재시도 가능 여부를 동작 단위로 선언해야 합니다.
Kagent 기반 Kubernetes Agent 관리는 Kagent, AWS Native AgentCore 기반 Agent 운영은 AWS Native 플랫폼을 참조하세요.
Layer 5: Gateway & Routing
모델 추론 요청을 지능적으로 라우팅하는 레이어입니다. Self-hosted 모델(Layer 2)과 외부 AI Provider를 단일 엔드포인트로 통합합니다.
라우팅 전략: 아래 전략들의 효과(지연·비용 절감 등)는 트래픽·캐시 적중률·모델 구성에 따라 달라지므로, 도입 전후 측정으로 검증해야 하는 정책으로 다룹니다.
| 전략 | 설명 |
|---|---|
| 모델 기반 라우팅 | 요청 헤더/파라미터에 따라 적절한 모델 백엔드로 분배 |
| KV Cache-aware 라우팅 | Prefix Cache 적중 시 TTFT를 줄일 수 있음(캐시 미스 시 효과 없음). 적중률에 비례하는 효과 |
| Cascade 라우팅 | 저비용 모델 우선 시도 → 품질 기준 미달 또는 실패 시 고성능 모델로 전환. "실패"의 판정 기준(품질 임계·오류)을 명시해야 함 |
| 가중치 기반 라우팅 | Canary/Blue-Green 배포를 위한 트래픽 비율 분할 |
| Fallback | Provider 장애 시 대체 Provider로 자동 전환 (Circuit Breaker) |
Cost Guardrails
요청별, Agent별, 테넌트별 비용 한도를 설정합니다. 비용 통제는 강제 수준에 따라 두 가지로 구분해야 합니다.
- 하드 스톱(hard stop): 한도를 반드시 지켜야 하는 경우, 요청 처리 이전에 예상 비용을 예약(preflight reservation)하고 잔여 예산이 없으면 요청을 거부합니다. 이미 예산을 초과한 뒤 저비용 모델로 폴백하거나 알림만 보내는 방식은 추가 과금을 막지 못합니다.
- 소프트 알림(soft alert)·폴백: 초과를 허용하되 저비용 모델로 전환하거나 알림을 보내는 방식입니다. 이때 허용되는 초과분(overshoot) 범위를 함께 정의해야 하며, 비용 상한을 보장하지는 않습니다.
(정책 강제 자체는 거버넌스 플레인과 연동)
Layer 5의 운영 상세는 다음 문서에서 다룹니다.
- 테넌트별 키·예산 계층과 격리 3단 모델: AI Gateway 멀티테넌시
- 토큰 메터링·showback/chargeback·예산 정책 매트릭스: LLM FinOps Chargeback
- Agent가 게이트웨이 경유로 MCP 툴을 사용할 때의 토큰 오버헤드 최적화: MCP 툴 토큰 최적화 패턴
2-Tier Gateway 아키텍처(kgateway + Bifrost), Cascade Routing 튜닝, Semantic Router는 Inference Gateway를 참조하세요.
Layer 6: Experience & Channels
사용자와 외부 시스템이 플랫폼에 진입하는 최상단 레이어입니다. 다양한 채널(API, SDK, Web UI, 메신저·상담 채널)로 Agent 기능을 노출합니다.
| 진입점 | 설명 | 활용 |
|---|---|---|
| API · gRPC | REST/gRPC 엔드포인트 | 시스템 간 통합, 백엔드 호출 |
| Agent SDK | Python/JS 클라이언트 SDK | 애플리케이션 내장 Agent |
| Web UI | 대시보드·챗 인터페이스 | 운영자·사용자 직접 상호작용 |
| 채널 연동 | 메신저, 상담(AICC), 음성 채널 | 옴니채널 고객 접점 |
피드백 수집(사용자 평가, 수정 사항)은 이 레이어에서 시작되지만, 수집된 데이터의 처리·학습 반영은 모델 라이프사이클 플레인이 담당합니다.
주요 컴포넌트: 횡단 플레인
다음 3개 플레인은 특정 레이어에 속하지 않고 6개 런타임 레이어를 수직으로 관통합니다.
관측성 & 평가 플레인
모든 레이어에서 발생하는 트레이스·메트릭·비용·품질을 통합 수집하고 평가합니다.
LLM Tracing
모든 LLM 호출의 입력, 출력, 지연시간, 토큰 사용량을 기록합니다. 개발 환경에서는 디버깅용 상세 트레이스를, 프로덕션에서는 샘플링된 트레이스를 저장합니다. Langfuse, OpenTelemetry 기반으로 Layer 4(Agent)~Layer 2(Serving)의 전체 흐름을 추적합니다.
2-Tier Cost Tracking
- 인프라 레벨: Layer 1 가속기 시간, 모델 단가 x 토큰
- 애플리케이션 레벨: Agent 스텝별 비용, 테넌트별·모델별 예산 추적
Quality Evaluation (RAGAS)
RAG·Agent 품질을 정량 측정합니다. 단일 레이어가 아니라 데이터(Layer 3)·서빙(Layer 2)·Agent(Layer 4)에 걸친 품질을 종합 평가합니다.
RAGAS Metrics:
- Context Precision / Context Recall: 검색 정확도·재현율
- Faithfulness: 생성 답변이 컨텍스트에 근거하는 정도
- Answer Relevancy: 질문과 답변의 관련성
Agent Success Rate:
- Task Completion Rate, Tool Execution Accuracy, Multi-step Coherence
Drift Detection
드리프트는 종류를 구분해야 하며, 지표에 따라 감지할 수 있는 대상이 다릅니다.
- 공변량 드리프트(covariate/data drift): 입력 분포 P(X)의 변화입니다. PSI, KL Divergence 같은 지표는 입력 분포 변화를 감지하며, 예시 임계값으로 PSI > 0.25, KL Divergence > 0.1을 둘 수 있습니다(값은 제안 기준이며 데이터·윈도·특성에 맞게 보정해야 함).
- 개념 드리프트(concept drift): 입력과 출력의 관계 P(Y|X) 자체가 변하는 것입니다. 입력 분포만 보는 PSI/KL로는 개념 드리프트를 직접 식별할 수 없고, 정답(ground truth)이 도착한 뒤의 예측 품질 변화로 판단해야 합니다.
- 품질 저하(quality degradation): RAGAS·Agent 성공률 등 출력 품질 지표의 하락입니다. 이는 개념 드리프트뿐 아니라 프롬프트·검색(RAG)·도구·모델 등 여러 원인에서 비롯될 수 있습니다.
따라서 임계값 초과는 재학습을 바로 트리거하는 신호가 아니라 진단의 출발점입니다. 원인(프롬프트/검색/도구/모델)을 먼저 진단하고, 가중치 재학습이 필요하다고 판단될 때에만 승인된 절차로 모델 라이프사이클 플레인의 재학습을 트리거합니다. PSI/KL 임계값 초과만으로 가중치 재학습이 필요함이 증명되지는 않습니다.
Langfuse 기반 Agent 모니터링은 Agent 모니터링, LLMOps 도구 비교는 LLMOps Observability, RAG 평가는 Ragas 평가를 참조하세요.
거버넌스 · 안전 · 주권 플레인
플랫폼 전반의 안전·정책·규제 준수·데이터 주권을 강제합니다.
Guardrails Enforcement
NeMo Guardrails 또는 Guardrails AI로 LLM 입출력을 검증합니다:
- PII Leakage Detection (개인정보 유출 차단)
- Prompt Injection Detection (프롬프트 인젝션 방어)
- Toxic Content Filtering (유해 콘텐츠 필터링)
- Factuality Check (사실 검증)
Guardrails는 Layer 5(Gateway 입구)와 Layer 4(Agent 출력)에 동시에 적용되므로 단일 레이어가 아닌 플레인으로 정의합니다.
정책 · 접근 제어 (RBAC)
OIDC/JWT 인증, 역할 기반 접근 제어, 도구별 호출 권한 제한, 테넌트 격리를 강제합니다. 최소 권한 원칙으로 Agent별 호출 가능 도구를 선언적으로 정의합니다.
데이터 주권 · 리전 강제 (Sovereignty)
데이터 주권 요구가 있는 조직(금융·공공·규제 산업)은 추론·학습·데이터 저장을 특정 지리 경계 내로 강제해야 합니다. 아래 수단들은 각각 서로 다른 경계만 통제하므로, 조직은 처리·저장·텔레메트리·컨트롤 플레인별로 요구되는 경계와 프로파일링되는 모든 목적지를 먼저 식별한 뒤 조합해야 합니다. 이 표는 "플랫폼이 주권을 자동으로 충족한다"가 아니라 **각 수단이 통제하는 범위와 남는 흐름(residual flow)**을 보여줍니다.
| 수단 | 통제하는 범위 | 통제하지 못하는 범위(잔여 흐름) | 적용 위치 |
|---|---|---|---|
| SCP 리전 강제 | aws:RequestedRegion으로 승인되지 않은 리전의 API 호출 엔드포인트를 거부 | 엔드포인트 리전만 제한할 뿐, 서비스 내부에서 데이터가 처리되는 리전은 서비스 동작에 따름 | 계정·OU 경계 |
| Bedrock Geographic CRIS | 추론을 지리(geography, 예: US·EU·APAC) 경계 내로 유지 | 지리는 여러 리전·국가를 포함하므로 in-country(단일 국가)를 보장하지 않음. 국가 단위 요구에는 부족 | Layer 5 → External AI |
| In-country 자체 호스팅 | 모델 추론·가중치를 특정 국가 리전 또는 온프레미스에 유지 | 로그·메트릭·관리 플레인 등 부수 흐름은 별도 통제 필요 | Layer 1·2 |
| 하이브리드(EKS Hybrid Nodes) | 데이터 플레인(워크로드)을 온프레미스·in-country에 배치 | 컨트롤 플레인(EKS 관리 영역)은 AWS 리전에서 호스팅되므로 완전한 온프레미스 격리가 아님 | Layer 1 |
SCP 리전 강제 정책, Bedrock Geographic cross-Region inference, EKS Hybrid Nodes 기반 하이브리드·주권 배포 패턴은 소버린 & 하이브리드 배포와 AI 플랫폼 선택 가이드를 참조하세요. Guardrails 기술 스택은 AI Gateway Guardrails, 컴플라이언스 매핑(SOC2·ISMS-P)은 컴플라이언스 프레임워크를 참조하세요.
모델 라이프사이클 (FMOps) 플레인
프로덕션 피드백을 기반으로 모델을 지속적으로 개선하는 폐쇄 루프를 담당합니다. 학습·파인튜닝·평가·재학습·피드백이 모두 이 플레인에 속하며, 결과물(신규 모델)은 Layer 2 Model Registry로 전달됩니다.
Training Pipeline Orchestration
Kubeflow Pipelines 또는 Argo Workflows로 학습 워크플로우를 자동화합니다. 데이터 검증 → 전처리 → 학습 → 평가 → 등록 단계를 DAG로 정의합니다. 학습 워크로드는 Layer 1 AI Infrastructure의 가속 컴퓨팅을 공유합니다.
Continuous Training (CT) Scheduler
데이터 드리프트 감지(관측성 플레인) 시 재학습을 실행할 수 있습니다. 예약 기반(Cron) 또는 이벤트 기반(드리프트 임계값 초과) 트리거를 지원합니다. 아래 트리거 조건의 구체적 수치는 검증되지 않은 **제안값(예시)**이며, 실제 적용 전에 조직 데이터로 보정하고, 재학습은 승인된 학습 데이터와 사전 등록된(prespecified) 실험 절차를 거쳐야 합니다.
트리거 조건(제안값, 보정 필요):
- 예약 기반:
0 0 * * 0(매주 일요일) - 드리프트 기반: PSI > 0.25 또는 KL Divergence > 0.1 (입력 분포 변화 신호 — 재학습 전 원인 진단 필요)
- 품질 저하: Agent Success Rate < 85% 지속 7일
Evaluation Gate
배포 전 모델 품질을 검증하는 게이트입니다. Accuracy, RAGAS 메트릭, Guardrails 통과율을 자동 측정하며, 품질 임계값 미달 시 배포를 차단합니다. 신규 모델은 canary 배포(예: 10%) 후 사전 등록된 지표·방향·효과 크기 기준으로 회귀 여부를 판단합니다. 통계 검정은 지표 분포 비교에 적합한 방법(예: Mann-Whitney U test)을 사용할 수 있으나, 임의의 p < 0.05만으로 "회귀 있음/없음"이 증명되지는 않습니다. 검정 방향·효과 크기·검정력(power)·다중 비교 보정을 함께 정의해야 하며, 회귀가 확인되면 롤백합니다(canary 비율·임계값은 제안값).
Feedback Loop
프로덕션 피드백(사용자 평가, 수정 사항, A/B 테스트 결과)을 학습 데이터로 환류합니다. 선호 학습(예: DPO)에서는 원래의 나쁜 답변을 거부(rejected) 샘플로, 사용자가 제공한 검증된 수정 답변을 채택(chosen) 샘플로 다루어야 합니다. 아래 의사코드의 "hard negative"는 이 거부/채택 쌍 구성을 가리키며, 수정된 올바른 답변 자체를 부정 예시로 학습한다는 뜻이 아닙니다. 또한 환류된 데이터는 평가용 홀드아웃(holdout)과 분리해 데이터 누수를 막아야 합니다.
Positive Feedback (thumbs up)
→ chosen(채택) 예시로 학습 데이터셋에 추가
Negative Feedback (thumbs down)
→ 사용자가 수정 제공: (원답변=rejected, 수정답변=chosen) 선호 쌍 구성
→ 수정 없음: 학습 데이터셋에서 제외(필터)
MLOps 파이프라인(EKS), 지속 학습(GRPO/DPO), trace-to-dataset, 평가·롤아웃은 모델 라이프사이클을 참조하세요.
레이어 & 플레인 통합 플로우
런타임 레이어와 횡단 플레인이 어떻게 상호작용하여 완전한 FMOps 파이프라인을 구성하는지 보여줍니다. 세 플로우 모두 플레인이 레이어를 관통하는 구조를 드러냅니다.
Feedback → Training → Serving Loop
프로덕션 피드백이 재학습을 트리거하고, 새 모델이 배포되는 전체 루프입니다. 라이프사이클 플레인과 관측성 플레인이 런타임 레이어를 관통합니다.
플로우 설명:
- Layer 4 (Agent Runtime)가 사용자 피드백을 수집하여 라이프사이클 플레인의 Feedback Loop로 전달
- 관측성 플레인의 Drift Detection이 입력 데이터 드리프트를 감지
- 라이프사이클 플레인의 CT Scheduler가 재학습 트리거를 받아 Training Pipeline 실행 (Layer 1 가속 컴퓨팅 사용)
- 평가 게이트 통과 시 Layer 2 Model Registry에 신규 모델 등록
- Layer 5 Gateway가 10% canary 배포로 신규 모델 검증
- 회귀 탐지 시 Model Registry의 이전 버전으로 자동 롤백
Evaluation → Rollback Path
품질 회귀를 감지하고 자동으로 롤백하는 경로입니다. 관측성 플레인이 감지하고 라이프사이클 플레인이 대응합니다.
플로우 설명:
- 관측성 플레인이 RAGAS 점수 하락을 감지
- 라이프사이클 플레인의 Eval Gate가 통계 검정으로 유의성을 확인(검정 방향·효과 크기·검정력을 사전 정의)
- 유의한 회귀로 판단되면 Alert System이 롤백 정책 실행
- 컨트롤 플레인: Layer 2 Model Registry에서 마지막 안정 버전을 선택(레지스트리의 스테이지 전환은 메타데이터 변경이며, 그 자체가 트래픽 전환은 아님)
- 배포·준비: Deployment Controller가 이전 버전으로 롤링 재배포하고 pod readiness·드레이닝·진행 중 요청·캐시/상태 호환성을 확인
- 트래픽 컷오버: 새 pod가 준비된 뒤 Layer 5 Gateway가 사용자 트래픽을 전환
- 복구 완료
"5분 내 원자적 교체"는 아직 검증되지 않은 복구 목표이며, 실제 소요 시간은 모델 로딩·pod 준비·캐시 워밍·용량 확보에 좌우됩니다. 컨트롤 플레인의 버전 선택, 롤링 pod 준비, 사용자 트래픽 컷오버는 별개의 단계이고 어느 것도 즉시·원자적이지 않습니다. 복구 시간을 수치로 주장하려면 관측된 롤백 픽스처(fixture)로 측정해야 합니다.
A/B Testing → Production
두 Agent/Model variant를 실험하여 승자를 프로덕션에 배포하는 경로입니다.
플로우 설명: 아래 수치(50:50, n, p, 개선율)는 제안 예시 기준이며, 실험 전 랜덤화 단위·지표 방향·효과 크기·검정력·다중 비교 정책을 사전 등록해야 합니다.
- Layer 4 (Agent Runtime)가 A/B 두 variant를 실행
- Layer 5 (Gateway)가 요청을 분배(예: 50:50). 랜덤화 단위(요청/세션/사용자)를 명시해야 하며, 단위에 따라 독립·대응(paired) 표본 여부가 달라짐
- 관측성 플레인의 Experiment Tracking이 variant별 메트릭 수집(표본 크기는 검정력 분석으로 산정; 예: n ≥ 1000은 제안값)
- 관측성 플레인의 Statistical Analysis가 지표 분포 비교에 적합한 검정(예: Mann-Whitney U test)을 실행. 이 검정은 두 분포가 다른지를 보며, "평균 개선"을 직접 검정하지 않음
- 사전 정의한 지표 방향으로 유의한 차이(예: p < 0.05)와 실질적 효과 크기(예: 개선 > 5%)를 함께 만족할 때 승자 선정(수치는 제안 게이트)
- 라이프사이클 플레인이 Layer 2 Model Registry에 승자 variant를 프로덕션으로 표시
- Layer 5 (Gateway)가 트래픽을 승자로 전환
배포 아키텍처
네임스페이스 구성
관심사 분리와 보안을 위해 기능별로 네임스페이스를 분리하고, 각 네임스페이스에는 **최소 권한(Pod Security Standards)**을 기본값으로 적용합니다. Pod Security의 privileged는 "제약이 없는(unrestricted)" 정책으로 알려진 권한 상승을 허용하고 컨테이너 격리를 우회할 수 있으므로, GPU를 쓴다는 이유만으로 서빙·학습 전체를 privileged로 두어서는 안 됩니다. 일반 GPU 모델 Pod는 호스트 특권 없이 baseline(또는 디바이스 플러그인 요구에 맞춘 예외) 수준으로 동작할 수 있으며, 드라이버·시스템 오퍼레이터 등 호스트 접근이 실제로 필요한 특권 컴포넌트만 좁은 예외로 분리합니다.
| 네임스페이스 | 레이어 / 플레인 | 컴포넌트 | Pod Security | GPU |
|---|---|---|---|---|
| ai-infra | Layer 1 | GPU Operator, Karpenter, Kueue, DCGM Exporter | baseline (단, GPU 드라이버/디바이스 플러그인 등 호스트 접근 컴포넌트만 privileged 예외) | 필요 |
| ai-inference | Layer 2 | LLM Serving Engine, Triton, Model Registry | baseline (서빙 Pod는 호스트 특권 불필요; 백엔드별 디바이스 접근 예외만 문서화) | 필요 |
| ai-data | Layer 3 | Vector DB, Cache, Knowledge/Feature Store | baseline | - |
| ai-agents | Layer 4 | Agent Runtime, Tool Registry, A2A | baseline | - |
| ai-gateway | Layer 5 | Inference Gateway, Auth, A/B Router | restricted | - |
| observability | 관측성 플레인 | Tracing, Metrics, RAGAS, Drift Detection | baseline | - |
| ai-governance | 거버넌스 플레인 | Guardrails, Policy, Regression Detection | baseline | - |
| ai-training | 라이프사이클 플레인 | Training Pipeline, CT Scheduler, Eval Gate | baseline (분산 학습 통신 등 필요한 Pod만 좁은 특권 예외) | 필요 |
여기서 "privileged"는 Pod Security Standards의 **정책 수준(네임스페이스 승인 정책의 완화)**을 뜻하며, 컨테이너의 securityContext.privileged: true 플래그와는 구분됩니다. 가능하면 정책 완화 대신 컴포넌트별로 필요한 최소 권한(특정 디바이스·capability)만 부여하세요.
Layer 6(Experience & Channels)은 별도 네임스페이스 없이 ai-gateway 앞단의 Ingress/ALB와 외부 채널 연동으로 노출됩니다.
확장성 설계
수평적 확장 전략
각 컴포넌트는 독립적으로 수평 확장이 가능합니다.
| 컴포넌트 | 레이어 | 스케일링 트리거 | 방식 |
|---|---|---|---|
| GPU 노드 | Layer 1 | Pending Pod, GPU 요청량 | Karpenter Node Auto-provisioning |
| LLM Serving | Layer 2 | GPU 사용률, 대기 큐 길이 | HPA + KEDA |
| Vector DB | Layer 3 | 쿼리 지연 시간, 인덱스 크기 | Query/Index Node 독립 확장 |
| Agent Pod | Layer 4 | 메시지 큐 길이, 활성 세션 수 | Event-driven Autoscaling (KEDA) |
| Gateway | Layer 5 | 요청 수, 동시 연결 | HPA |
| Training Pipeline | 라이프사이클 플레인 | 학습 작업 큐 길이 | Spot Instance Auto-provisioning |
멀티 테넌트 지원
여러 팀이나 프로젝트가 동일한 플랫폼을 공유할 수 있도록 네임스페이스 격리, 리소스 쿼터, 네트워크 정책을 조합한 멀티 테넌트를 지원합니다. 여기서 다루는 것은 인프라(Kubernetes) 레벨 격리이며, LLM 요청 경로의 테넌트 격리 — 게이트웨이 키·예산, 벡터 DB 네임스페이스, 팀별 트레이스 분리 — 는 AI Gateway 멀티테넌시의 격리 3단 모델이 canonical입니다.
| 격리 수준 | 권장 환경 | 방법 | 장점 | 단점 |
|---|---|---|---|---|
| 네임스페이스 | 일반적인 멀티테넌시 | 테넌트별 네임스페이스 | 간단한 구현, 리소스 격리 | 네트워크 정책 필요 |
| 노드 | RBAC·네트워크·스토리지 분리와 병행 시 규제 요건 일부 충족 | 테넌트별 노드 풀 | 데이터 플레인(워커 컴퓨팅) 격리 강화 | 비용 증가, 컨트롤 플레인·API는 여전히 공유 |
| 클러스터 | 엔터프라이즈 고객 | 테넌트별 클러스터 | 최고 수준 격리 | 관리 복잡성 |
보안 아키텍처
Agentic AI Platform은 외부 접근, 내부 통신, 데이터 보안의 3중 보안 레이어를 적용합니다.
Agent 특화 보안 고려사항: 아래 항목은 **측정된 완화책(mitigation)**이며, 단독으로 공격을 "차단"한다고 보장하지 않습니다. 각 항목은 실패 시 동작(fail-closed/open)을 정의하고, 효과를 평가로 검증해야 합니다.
- 프롬프트 인젝션 완화: 입력 검증 레이어(Guardrails)로 악의적 프롬프트의 상당 부분을 걸러낼 수 있으나, LLM 기반 필터는 우회 가능하므로 완전 차단을 전제하지 않습니다. 인가(authorization)·도구 브로커 통제·이그레스(egress) 제한을 필터 바깥의 별도 통제로 유지해야 합니다.
- 도구 실행 권한 제한: Agent별 호출 가능 도구를 선언적으로 정의하고 최소 권한을 적용합니다. 이는 LLM 출력 필터가 아니라 도구 브로커·인가 계층에서 강제합니다.
- PII 유출 완화: 출력 필터링으로 민감 정보 노출을 줄이지만 완전 차단은 보장하지 않으므로, 데이터 접근 통제·이그레스 제한과 병행합니다.
- 실행 시간 제한: Agent 무한 루프 방지를 위한 타임아웃 및 최대 스텝 수 설정
- 내부·외부 통신 구간을 식별하여 실제 엔드포인트에 맞게 mTLS를 적용하세요(모든 호출에 일괄 적용되는 것은 아니며, 외부 Provider API는 TLS 종단 방식이 다를 수 있음). NeMo Guardrails 등 Guardrails 서버 자체에는 인증·TLS·레이트 제한이 내장되어 있지 않으므로, 게이트웨이·서비스 메시 등 외부 계층에서 보강해야 합니다.
- API 키와 토큰은 Secrets Manager에 저장하세요
- 정기적으로 보안 감사를 수행하고 취약점을 패치하세요
데이터 플로우
사용자 요청이 플랫폼을 통해 처리되는 전체 흐름입니다.
| 단계 | 컴포넌트 | 설명 |
|---|---|---|
| 1-2 | Gateway (L5) | 인증 · Rate Limit · Guardrail 검증 |
| 3 | Gateway → Agent (L4) | 에이전트 라우팅 및 작업 할당 |
| 4-5 | Agent → Vector DB (L3) | RAG를 위한 컨텍스트 검색 |
| 6-8 | Agent → Gateway → Model (L2) | 게이트웨이 경유 모델 추론 (Cascade · Fallback) |
| 9 | 관측성 플레인 | Trace · 비용 기록 |
| 10-11 | Agent → Gateway → Client | 응답 반환 |
모니터링 및 관측성
주요 모니터링 영역
| 영역 | 대상 메트릭 | 목적 |
|---|---|---|
| Agent Performance | 요청 수, P50/P99 지연 시간, 오류율, 스텝 수 | 에이전트 성능 추적 |
| LLM Performance | 토큰 처리량, TTFT, TPS, 큐 대기 시간 | 모델 서빙 성능 |
| Resource Usage | CPU, 메모리, GPU 사용률/온도 | 리소스 효율성 |
| Cost Tracking | 테넌트별/모델별 토큰 비용, 인프라 비용 | 비용 거버넌스 |
| Quality | RAGAS 점수, Agent 성공률, Guardrails 통과율 | 품질 SLO 준수 |
| Training | 학습 빈도, 모델 승격률, 드리프트 탐지 횟수 | MLOps 파이프라인 건강도 |
알림 규칙 예시:
- Agent P99 지연 시간 > 10초 → Warning
- Agent 오류율 > 5% → Critical
- GPU 사용률 < 20% (30분 지속) → Cost Warning
- 토큰 비용 일일 예산 80% 도달 → Budget Warning
- RAGAS Faithfulness < 0.85 (1시간 지속) → Quality Warning
- Agent Success Rate < 90% (7일 지속) → Retraining Trigger
플랫폼 요구사항
| 영역 | 레이어 / 플레인 | 필요 역량 | 설명 |
|---|---|---|---|
| AI 인프라 | Layer 1 | 가속 컴퓨팅 + GPU 오케스트레이션 | GPU/Trainium/Inferentia, Karpenter·Kueue·DRA, DCGM 모니터링 |
| 모델 서빙 | Layer 2 | LLM 추론 엔진 | PagedAttention, KV cache 최적화, 분산 추론, Model Registry |
| 데이터 레이어 | Layer 3 | 벡터 DB + 캐시 + Knowledge Store | RAG 검색, 세션 상태 저장, 장기 메모리, 특성 관리 |
| Agent 프레임워크 | Layer 4 | 워크플로우 엔진 | 멀티스텝 실행, 상태 관리, MCP/A2A 프로토콜 |
| 게이트웨이 | Layer 5 | Gateway API + 라우팅 | 지능형 모델 라우팅, mTLS, Rate Limiting, External AI 연동 |
| 경험·채널 | Layer 6 | API/SDK/UI/채널 | 멀티 채널 노출, 피드백 수집 |
| 관측성 | 관측성 플레인 | LLM 트레이싱 + 평가 | 토큰 비용 추적, Agent Trace 분석, RAGAS, 드리프트 감지 |
| 거버넌스·주권 | 거버넌스 플레인 | 다층 보안 + 주권 강제 | OIDC/JWT, RBAC, Guardrails, SCP 리전 강제, 컴플라이언스 |
| 모델 라이프사이클 | 라이프사이클 플레인 | 분산 학습 + CT + 평가 게이트 | LoRA/QLoRA 파인튜닝, 자동 재학습, 회귀 탐지, 롤백 |
구체적인 기술 스택과 구현 방법은 AWS Native 플랫폼 또는 EKS 기반 오픈 아키텍처를 참조하세요.
결론
Agentic AI Platform 아키텍처의 설계 원칙:
- 레이어와 플레인의 직교 분리: "어디서 추론하는가(6 런타임 레이어)"와 "어떻게 관측·통제·개선하는가(3 횡단 플레인)"를 분리하여 관심사 중복을 제거
- AI Infrastructure 1급 레이어: 가속 컴퓨팅과 그 오케스트레이션·모니터링·성능 최적화를 최하단 독립 레이어로 명시
- 하이브리드 AI: Self-hosted 모델과 External AI Provider를 단일 게이트웨이에서 통합 관리
- 표준 프로토콜: MCP/A2A로 도구 연결과 Agent 간 통신을 표준화
- 관측성·평가 통합: 전체 요청 흐름의 Trace, 비용, 품질을 단일 플레인에서 모니터링·평가
- 거버넌스·주권: 다층 보안 + Agent 특화 안전(Guardrails) + 데이터 주권(SCP 리전 강제, in-country, 하이브리드)
- Closed-loop FMOps: 피드백 → 드리프트 탐지 → 재학습 → 평가 게이트 → 배포 자동화
- Quality-first: 모든 모델 변경은 평가 게이트의 통계적 검증을 통과해야 프로덕션 승격
이 플랫폼 아키텍처를 구현하는 구체적인 방법은 다음 문서에서 다룹니다:
- 기술적 도전과제 — 플랫폼 구축 시 직면하는 주요 과제
- AWS Native 플랫폼 — 매니지드 서비스 기반 구현
- EKS 기반 오픈 아키텍처 — EKS + 오픈소스 기반 구현
참고 자료
업계 참조 아키텍처
- AWS Well-Architected Generative AI Lens — AWS 공식 생성형 AI 설계 원칙, 전 계층을 관통하는 운영 관점
- CNCF Cloud Native AI Whitepaper — CNCF 클라우드 네이티브 AI 레이어링과 인프라 패턴
- a16z: Emerging Architectures for LLM Applications — LLM 앱 레퍼런스 아키텍처(오케스트레이션·데이터·모델 분리)
- Chip Huyen, AI Engineering (O'Reilly, 2025) — Infrastructure/Model/Application 3-tier, FTI 파이프라인
주요 저자
- Chip Huyen: "Designing Machine Learning Systems" (2022), "AI Engineering" (2025) — MLOps 프로덕션 베스트 프랙티스
- Eugene Yan: "What We Learned from a Year of Building with LLMs" (O'Reilly 2024) — 실전 LLM 구축 경험
- Shreya Shankar: DocETL research, MLOps papers (UC Berkeley) — 데이터 품질 및 평가 프레임워크
공식 문서
- Kubernetes Gateway API — K8s 공식 게이트웨이 API
- MCP (Model Context Protocol) — MCP 프로토콜 명세
- CNCF Cloud Native Architecture — 클라우드 네이티브 아키텍처 패턴
- OpenTelemetry — 관측성 표준
논문 / 기술 블로그
- A2A (Agent-to-Agent Protocol) — Google이 개발, 현재 Linux Foundation 관리하는 멀티 에이전트 통신 프로토콜
- LangChain Architecture Patterns — Agent 아키텍처 패턴
- Building Production-Ready LLM Applications — 프로덕션 LLM 엔지니어링
- AWS Well-Architected Framework for AI/ML — AI/ML 워크로드 설계 원칙
관련 문서 (내부)
- 기술적 도전과제 — 플랫폼이 해결하는 5가지 주요 문제
- Knowledge Feature Store — 온톨로지 기반 특성 관리
- MCP 툴 토큰 최적화 패턴 — Layer 4 Agent의 MCP 툴 토큰 오버헤드 최적화
- AI Gateway 멀티테넌시 — Layer 5 테넌트 격리·예산 강제
- LLM FinOps Chargeback — 토큰 메터링·비용 배부 방법론
- Model Serving & 추론 인프라 — vLLM, llm-d, MoE 배포 가이드
- Operations & 거버넌스 — Langfuse, RAGAS, Guardrails 운영
- Reference Architecture — 단계별 구현 가이드