Agentic AI 워크로드의 기술적 도전과제
문서 도구
소개
Agentic AI 플랫폼을 구축하고 운영할 때, 플랫폼 엔지니어와 아키텍트는 기존 웹 애플리 케이션과는 근본적으로 다른 기술적 도전에 직면합니다. 이 문서에서는 5가지 핵심 도전과제를 분석합니다.
이 문서를 읽기 전에 플랫폼 아키텍처에서 Agentic AI Platform의 전체 구조를 먼저 확인하세요.
왜 단일 LLM만으로는 부족한가
Agentic AI 시대를 맞아 기업이 가장 먼저 직면하는 질문은 *"가장 크고 비싼 LLM 하나만 쓰면 되지 않나?"*입니다. 실제 기업 환경에서 단일 거대 LLM에 전적으로 의존하면 다음과 같은 실질적인 한계에 부딪힙니다.
기업 실무에서 경험하는 단일 LLM의 4가지 한계
| 한계 영역 | 기업이 겪는 문제 | 플랫폼 대응 |
|---|---|---|
| 비용 | 70B+ 모델의 토큰 과금은 대량 트래픽 시 월 수천만 원에 달하며, 에이전트 내부의 도구 호출·포맷팅 등 단순 작업에도 동일 비용이 발생합니다. 실제 연구에 따르면 에이전트 LLM 호출의 40~70%는 SLM으로 대체 가능합니다. | Bifrost 2-Tier 라우팅으로 단순 호출은 자체 호스팅 SLM, 복잡한 추론만 LLM으로 분리 |
| 성능 · 지연 | 거대 모델은 응답 지연(TTFT)이 길어 실시간 상담(AICC)이나 대화형 에이전트에서 사용자 경험을 저하시킵니다. 도메인 특화 SLM은 동일 작업에서 10배 이상 빠른 응답이 가능합니다. | 3-Tier Orchestration — Tier 1(SLM 직접)은 ~50ms, Tier 2(LLM)는 복잡한 추론에만 사용 |
| 정보 정확성 | LLM의 환각(hallucination)은 구조적 특성이며, 요금 계산·약관 검증 등 정확성이 요구되는 업무에서는 치명적입니다. 트랜스포머 아키텍처는 복잡한 산술과 논리 연산에 본질적 한계를 가집니다. | Tool Delegation — 산술은 규칙 엔진, 팩트 검증은 Knowledge Graph에 위임. LLM은 자연어 이해에만 집중 |
| 거버넌스 · 보안 | 민감 데이터(PII/PHI)가 외부 LLM API로 유출될 위험, 에이전트의 자율적 행동에 대한 감사 추적, 팀별 접근 제어와 예산 관리가 필요합니다. | NeMo Guardrails (입출력 필터링) + LangGraph HITL (인간 승인 게이트) + Langfuse (감사 추적) |
인프라 최적화: 초지능 연구 기업과 K8s 생태계의 방향
이러한 다중 모델 생태계를 효율적으로 운영하려면 인프라 플랫폼화가 필수입니다. 이는 단순히 비용 절감의 문제가 아니라, AI를 선도하는 기업들이 공통적으로 핵심 분야로 투자하는 영역입니다.
Meta는 초지능(ASI) 연구와 병행하여 자체 AI 인프라 최적화에 막대한 투자를 하고 있습니다. Grand Teton(GPU 서버 아키텍처), MTIA(자체 추론 칩), PyTorch 생태계의 추론 효율화(torch.compile, ExecuTorch)는 모두 모델 성능만큼 인프라 효율이 중요하다는 인식에서 비롯됩니다.
CNCF Kubernetes 생태계 역시 AI 워크로드를 위한 기능을 빠르게 확장하고 있습니다:
| K8s AI 기능 | 버전 | 역할 | 다중 모델 생태계에서의 의미 |
|---|---|---|---|
| DRA (Dynamic Resource Allocation) | 1.34 GA (1.35+ stable) | GPU를 MIG 단위로 세밀 분할·할당 | SLM은 MIG 파티션, LLM은 전체 GPU — 하나의 클러스터에서 공존 |
| Gateway API + Inference Extension | 2025 | LLM 추론 요청의 표준화된 라우팅 | KV Cache 상태 기반 지능형 라우팅, 모델별 트래픽 분배 |
| Kueue | v0.18.x (베타 API) | AI 워크로드 큐잉·스케줄링 | 학습/추론 작업의 공정한 GPU 자원 분배, 팀별 쿼터 |
| LeaderWorkerSet | v0.9 (kubernetes-sigs 별도 프로젝트) | 분산 추론·학습 워크로드 패턴 | 70B+ 모델의 Tensor Parallel 분산 추론을 K8s 네이티브로 관리 |
| KAI Scheduler | 2025 | GPU-aware Pod 스케줄링 | GPU 토폴로지(NVLink, NVSwitch)를 고려한 최적 배치 |
이처럼 Kubernetes는 단순한 컨테이너 오케스트레이터를 넘어 AI 워크로드의 기반 인프라로 진화하고 있으며, 다중 모델 생태계를 운영하기 위한 가장 성숙한 플랫폼입니다.
결론: 다중 모델 생태계와 인프라 플랫폼화
기업은 단일 LLM 의존에서 벗어나 이질적 다중 모델(Heterogeneous Multi-model) 생태계를 구축하되, 이를 뒷받침하는 인프라 플랫폼이 반드시 수반되어야 합니다.
전략 기획 · 복잡한 추론 반복 실무 · 도메인 특화
┌──────────────────┐ ┌──────────────────┐
│ LLM Orchestrator │ 작업 │ SLM Expert Pool │
│ (Claude, GPT 등) │──분배──→ │ (7B/14B + LoRA) │
│ Tier 2 워크플로우 │ │ Tier 1 직접 호출 │
└──────────────────┘ └──────────────────┘
│ │
└── 외부 도구 위임 ─────────────┘
(산술, 검색, 지식 그래프)
│
┌────────────┴────────────┐
│ Kubernetes 인프라 플랫폼 │
│ DRA · Gateway API · Kueue │
│ Karpenter · vLLM · Bifrost│
└─────────────────────────┘
이 생태계를 Kubernetes 네이티브 환경에서 효율적으로 운영하기 위해 플랫폼이 해결해야 할 5가지 핵심 도전과제를 아래에서 분석합니다.
Agentic AI 플랫폼의 5가지 핵심 도전과제
Frontier Model(최신 대규모 언어 모델)을 활용한 Agentic AI 시스템은 기존 웹 애플리케이션과는 근본적으로 다른 인프라 요구사항을 가집니다.
도전과제 요약
전통적인 VM 기반 인프라나 수동 관리 방식으로는 Agentic AI의 동적이고 예측 불가능한 워크로드 패턴에 효과적으로 대응할 수 없습니다. GPU 리소스의 높은 비용과 복잡한 분산 시스템 요구사항은 자동화된 인프라 관리를 필수로 만듭니다.
도전과제 1: GPU 리소스 관리 및 비용 최적화
GPU는 Agentic AI 플랫폼에서 가장 비용이 높은 리소스입니다. 모델 크기와 워크로드 특성에 따라 적절한 GPU 할당 전략이 필요합니다. 이 도전과제는 플랫폼 아키텍처의 Layer 1: AI Infrastructure가 책임지는 영역으로, 가속 컴퓨팅·오케스트레이션·모니터링·성능 최적화를 단일 레이어로 통합하여 해결합니다.
왜 어려운가:
- 높은 비용: GPU 인스턴스는 CPU 대비 10~100배 비싼 비용 (H100 8장 p5.48xlarge 기준 us-east-1 시간당
$55, 리전별 $55$92) - 다양한 모델 크기: 3B 파라미터 모델부터 70B+ 모델까지 요구하는 GPU 메모리가 극단적으로 다름
- 동적 워크로드: 추론 트래픽이 시간대에 따라 10배 이상 변동
- 유휴 낭비: GPU 프로비저닝 후 활용률이 낮으면 막대한 비용 낭비
- 멀티 테넌트: 여러 모델과 팀이 제한된 GPU를 공유해야 함
| 모델 크기 | GPU 요구사항 | 비용 압박 |
|---|---|---|
| 70B+ 파라미터 | Full GPU (H100/A100) 8장 | 시간당 $30~$92 |
| 7B~30B 파라미터 | GPU 1~2장 또는 MIG 파티션 | 시간당 $1~$10 |
| 3B 이하 파라미터 | Time-Slicing 또는 공유 GPU | 시간당 $0.5~$2 |
도전과제 2: 지능형 추론 라우팅 및 게이트웨이
Agentic AI 워크로드는 다양한 모델과 프로바이더를 동시에 활용합니다. 단순한 로드밸런싱이 아닌, 모델 특성을 이해하는 지능형 라우팅이 필요합니다.
왜 어려운가:
- 멀티 모델 운영: 하나의 플랫폼에서 Llama, Qwen, Claude, GPT 등 다양한 모델을 동시 운영
- KV Cache 효율성: LLM의 KV Cache 상태를 고려하지 않은 라우팅은 성능을 크게 저하시킴
- 비용-성능 트레이드오프: 작업 복잡도에 따라 저비용 모델과 고성능 모델을 동적으로 선택해야 함
- 프로바이더 다변화: Self-hosted 모델과 외부 API (Bedrock, OpenAI) 를 통합 관리해야 함
- Canary/A-B 배포: 새 모델 버전을 안전하게 트래픽 전환해야 함
도전과제 3: LLMOps 관찰성 및 비용 거버넌스
LLM 기반 시스템은 기존 애플리케이션과 근본적으로 다른 관찰성(Observability) 요구사항을 가집니다. 전통적 관찰성은 "무슨 일이 일어났는가"(상태 코드·지연·처리량)를 알려주지만, 에이전트는 200 OK를 반환하면서도 틀린 답을 내놓을 수 있습니다. 즉 "동작했는가"가 아니라 **"제대로 수행했는가"**를 측정해야 하며, 여기에는 토큰 단위 비용 추적, 멀티스텝 Agent Trace, 출력 품질 평가가 필요합니다.
왜 어려운가:
- 비결정적 출력: 동일 입력에도 다른 출력이 나오므로 전통적 테스트/모니터링이 불충분하고, 프롬프트의 단어 하나만 바꿔도 연쇄 장애가 발생할 수 있음
- "성공한 실패" 가시성 부재: 전통적 o11y는 요청이 성공했는지만 알려줄 뿐, 응답이 정확했는지·사용자당 손실이 발생하는지조차 알 수 없음
- 토큰 비용 추적: 인프라 비용(GPU)과 애플리케이션 비용(토큰)을 이중으로 추적해야 하며, 모델·기능·도구(tool)별 비용 귀속이 어려움
- 멀티스텝 디버깅: Agent가 여러 도구를 호출하는 복잡한 체인에서 병목·실패 지점 파악이 어려움
- 프롬프트 품질 드리프트: 로컬에서는 멀쩡하던 품질이 프로덕션에서 서서히 저하되며, 보통 사용자가 먼저 알아챔
- 팀별 예산: 여러 팀이 공유하는 AI 인프라에서 팀별 비용 할당과 한도 관리가 필요
토큰 이코노믹스 — 토큰 숏티지 시대의 비용 거버넌 스
GPU 공급 제약과 추론 수요 급증으로 토큰은 점점 희소하고 비싼 자원이 되고 있습니다. 에이전트는 도구 호출·포맷팅·재시도 같은 단순 작업에도 LLM 호출을 반복하므로, 가시성 없이 실트래픽에 투입하면 요청별 비용이 폭증합니다. 토큰 이코노믹스 관점에서 관찰성은 단순 모니터링이 아니라 비용을 자산으로 전환하는 핵심 통제 수단입니다.
- 요청별 비용 귀속: 호출별 입출력 토큰·모델 단가를 추적해, 어떤 프롬프트·도구·사용자 코호트가 비용을 지배하는지 식별
- 모델 라이트사이징: 추적 데이터로 "이 작업은 SLM으로 충분한가"를 판단 — 단순 호출은 자체 호스팅 SLM, 복잡한 추론만 LLM으로 분리(2-Tier 라우팅)하는 근거 확보
- 품질 대비 비용 최적화: 더 비싼 모델·더 긴 프롬프트가 실제로 더 나은 결과를 내는지 데이터로 검증(감(gut feel)이 아니라 평가 기반)
- 예산 가드레일: 모델별·팀별 토큰 예산과 한도를 게이트웨이에서 강제
관찰성은 블랙박스 모델을 감사 가능하고 최적화 가능한 자산으로 전환합니다. 모든 프롬프트·응답·비용·지연을 추적할 수 있어야 토큰 숏티지 시대에 지속 가능한 단가로 에이전트를 운영할 수 있습니다.
관찰(Observe) → 평가(Evaluate) → 개선(Improve) 운영 루프
핵심은 대시보드가 아니라 루프 구조입니다. 배포 → 관측 → 평가 → 개선 사이클을 에이전트 개발에 적용합니다.
- Observe(관측): 호출별 완전한 I/O와 lineage, 스텝별 지연·토큰 비용, 사용자·세션 단위 여정 추적
- Evaluate(평가): 프로덕션 트레이스에서 데이터셋을 만들어 LLM-as-judge·인간 어노테이션으로 채점. 오프라인 평가(회귀 방지)와 온라인 평가(드리프트·품질 저하 감지)를 병행
- Improve(개선): 프롬프트 버전 관리·A/B 실험, Eval harness를 CI/CD에 연결해 퇴행 배포를 차단
이 루프는 점차 자동화됩니다 — 온라인 평가가 트레이스를 채점·플래그하고 실패 큐를 형성하면, 사람은 규칙·가드레일을 정의하고 배포(publish) 시점에만 승인/반려로 개입합니다.
| 관찰성 영역 | 기존 애플리케이션 | LLM 애플리케이션 |
|---|---|---|
| 측정 대상 | "동작했는가"(상태·지연) | "제대로 수행했는가"(출력 정확성) |
| 비용 추적 | 인프라 비용만 | 인프라 + 토큰 비용 이중 추적, 도구·모델별 귀속 |
| 디버깅 | 요청-응답 로그 | 멀티스텝 Agent Trace + lineage |
| 품질 모니터링 | 에러율, 지연 시간 | Faithfulness, Relevance, Hallucination, drift |
| 예산 관리 | 리소스 기반 | 모델별/팀별 토큰 예산 |
| 개선 방식 | 수동 핫픽스 | Observe→Evaluate→Improve 루프(평가 기반) |
도구 생태계: 이 요구사항을 충족하는 LLM 특화 관찰성 도구로 Langfuse(OSS, OpenTelemetry 기반, LLM-as-judge·프롬프트 관리·데이터셋 평가 내장), LangSmith, Helicone 등이 있습니다. 전통 APM(Datadog 등)은 토큰·품질 평가가 약하고 LLM 호출당 비용이 높습니다. 도구별 상세 비교와 하이브리드 아키텍처는 LLMOps 관찰성 도구 비교를 참조하세요.
도전과제 4: Agent 오케스트레이션 및 안전성
Agentic AI 시스템에서 Agent는 자율적으로 도구를 호출하고 외부 시스템과 상호작용합니다. 이러한 자율성은 안전성과 통제 가능성 측면에서 새로운 도전과제를 만듭니다.
왜 어려운가:
- 자율적 행동: Agent가 스스로 판단하여 도구를 호출하므로 예상치 못한 행동 가능
- 프롬프트 인젝션: 악의적 입력으로 Agent가 의도하지 않은 작업을 수행할 위험
- 도구 연결 표준화: 다양한 외부 시스템(DB, API, 파일)을 Agent에 안전하게 연결하는 표준 필요
- 멀티 Agent 통신: 여러 Agent가 협업할 때 안전하고 효율적인 통신 프로토콜 필요
- 상태 관리: 장기 실행 Agent의 상태 저장, 복구, 체크포인팅이 필요
- 스케일링: Agent 워크로드는 CPU 기반이지만 트래픽 패턴이 불규칙하여 효율적 스케일링이 어려움
도전과제 5: 모델 공급망 관리 (Model Supply Chain)
단순히 모델을 배포하는 것이 아니라, 전체 모델 라이프사이클(학습 → 평가 → 레지스트리 → 배포 → 피드백)을 체계적으로 관리해야 합니다.
왜 어려운가:
- 모델 버전 관리: 파운데이션 모델, 파인튜닝 모델, 어댑터(LoRA) 등 다양한 아티팩트 관리
- 분산 학습 인프라: 대규모 모델 파인튜닝에는 멀티 노드 GPU 클러스터와 고속 네트워크(EFA) 필요
- 평가 파이프라인: 모델 품질을 자동으로 평가하고 배포 게이트를 설정해야 함
- 안전한 배 포: Canary/Blue-Green 배포로 모델 업데이트 시 서비스 영향 최소화
- 하이브리드 환경: 온프레미스 GPU와 클라우드 GPU 간 모델 전송 및 동기화
- RAG 데이터 파이프라인: 문서 처리, 임베딩 생성, 벡터 저장의 지속적 업데이트 파이프라인 필요
- 피드백 루프: 프로덕션 추적 데이터를 재학습에 반영하는 지속적 개선 체계
다음 단계: 도전과제 해결 접근
이 5가지 도전과제를 해결하기 위한 두 가지 접근 방식을 제시합니다:
- AWS Native 플랫폼: AWS 매니지드 서비스(Bedrock, AgentCore)를 활용하여 인프라 운영 부담을 최소화하고 Agent 개발에 집중하는 접근
- EKS 기반 오픈 아키텍처: Amazon EKS와 오픈소스 생태계를 활용하여 세밀한 제어와 비용 최적화를 달성하는 접근
두 접근은 상호 보완적이며, 워크로드 특성에 따라 조합하여 사용할 수 있 습니다.
| 기준 | AWS Native | EKS 기반 오픈 아키텍처 |
|---|---|---|
| GPU 관리 | 불필요 (서버리스) | Karpenter 자동 프로비저닝 |
| 모델 선택 | Bedrock 지원 모델 | 모든 Open Weight 모델 |
| 운영 부담 | 최소 | 중간 (Auto Mode로 절감) |
| 비용 최적화 | 사용량 기반 과금 | Spot, Consolidation 등 세밀 제어 |
| 커스터마이징 | 제한적 | 완전한 유연성 |
- 빠르게 시작하고 Agent 로직에 집중: AWS Native 플랫폼
- Open Weight 모델 + 하이브리드 + 비용 최적화: EKS 기반 오픈 아키텍처
- 현실적 최적해: 두 접근의 조합 (AWS Native로 시작, 필요 시 EKS로 확장)
참고 자료
공식 문서
- Kubernetes Gateway API — K8s 공식 게이트웨이 API 명세
- CNCF AI/ML Landscape — Cloud Native AI/ML 생태계 전체 조감
- NVIDIA GPU Operator Documentation — GPU 오퍼레이터 공식 가이드
- AWS EKS Best Practices for AI/ML — EKS AI/ML 워크로드 최적화
논문 / 기술 블로그
- vLLM: Easy, Fast, and Cheap LLM Serving — PagedAttention 메커니즘 설명
- Efficient Memory Management for LLM Serving (OSDI 2023) — KV Cache 최적화 연구
- Cost-Effective LLM Inference at Scale — 프로덕션 비용 최적화 사례
- NVIDIA Blog: Optimizing AI Workloads — GPU 최적화 기술 블로그
관련 문서 (내부)
- 플랫폼 아키텍처 — 전체 시스템 설계 청사진
- AWS Native 플랫폼 — 매니지드 서비스 접근
- EKS 기반 오픈 아키텍처 — 자체 호스팅 접근
- GPU 리소스 관리 — GPU 비용 최적화 상세