이번 게시글에서는 EKS 워크샵 스터디 제 9주차 내용을 작성합니다.

이 글은 3부로 나누어집니다.

1. 9주차 - EKS 위 AI/ML 워크로드 Part 1 - EKSworkshop AI/ML로 Neuron 기반 다지기
2. 9주차 - EKS 위 AI/ML 워크로드 Part 2 - GenAI on EKS로 추론 서빙 운영하기
3. 9주차 - EKS 위 AI/ML 워크로드 Part 3 - Agentic AI Platform으로 멀티 에이전트 플랫폼 구축하기 (현재 보고 계신 글)

들어가며

이번 편에서 다루는 워크샵은 다음과 같습니다.

• 고급 에이전트 AI 플랫폼

워크샵 페이지(catalog.workshops.aws/k8sagenticplatform/ko-KR)는 Part 2와 마찬가지로 AWS Workshop Studio라 콘텐츠를 직접 인용하기 어렵습니다. 워크샵의 실제 코드·랩 자료는 aws-samples/sample-agentic-platform 공개 리포에 있는 것으로 강하게 추정되어, 이 글은 그 리포와 awslabs/ai-on-eks의 guidance/agentic-ai 도큐먼트를 함께 기준으로 정리했습니다.

Part 1에서 Amazon Q CLI(이하 Kiro)와 EKS MCP server를 통해 "자연어 요청을 EKS 운영 도구 호출로 바꾸는 방식"을 먼저 살펴봤습니다. 이번 편은 그 관점을 한 단계 확장합니다. Kiro가 단일 운영 인터페이스였다면, 이 워크샵은 EKS 위에 직접 에이전트 애플리케이션을 배포하고, LiteLLM Gateway · Memory Gateway · Retrieval Gateway · MCP server · OpenTelemetry collector를 묶어 에이전트를 운영 가능한 플랫폼 구성요소로 다루는 방법을 보여줍니다.

따라서 이 글에서는 명령 실행 결과를 순서대로 옮기기보다, 각 단계에서 다음 네 가지를 기준으로 정리합니다.

워크샵을 따라가는 관점

이 워크샵은 "LLM API를 호출하는 애플리케이션"을 만드는 데서 끝나지 않습니다. 핵심은 에이전트가 도구를 호출하고, 다른 에이전트와 협업하고, 요청별 상태를 유지하고, Kubernetes 위에서 일반 서비스처럼 배포·확장·관측되는 구조를 확인하는 것입니다.

Part 1의 Kiro LAB과 비교하면 차이가 분명합니다.

Agentic AI Platform 워크샵 개요

워크샵의 실제 구성을 aws-samples/sample-agentic-platform/labs 기준으로 정리하면 다음 다섯 Module로 나뉘어 있습니다.

각 Module은 README.md + notebooks/ 형태로 Jupyter 노트북 기반 실습이며, EKS 위의 컴포넌트 배포는 Module 5에 집중되어 있습니다. 그 이전 Module은 주로 노트북에서 Bedrock과 에이전트 프레임워크를 다룹니다.

컴퓨트 옵션

sample-agentic-platform 리포는 다음 두 가지 컴퓨트 백엔드를 명시합니다.

• Amazon EKS: Helm chart 기반으로 클러스터에 컴포넌트를 띄움
• Amazon Bedrock AgentCore Runtime: 관리형 에이전트 실행 환경

이 글의 관심은 EKS 쪽입니다. AgentCore Runtime은 운영 책임을 AWS에 더 위임하는 선택지로, 같은 에이전트 코드를 그대로 옮길 수 있다는 점만 챙기고 넘어갑니다.

사용되는 에이전트 프레임워크

src/agentic_platform/agent/ 아래에 실제로 들어 있는 에이전트는 다음과 같습니다.

두 프레임워크가 같은 플랫폼 위에서 공존하므로, 워크샵을 따라가다 보면 "프레임워크는 갈아끼울 수 있는 모듈이고, 진짜 플랫폼 자산은 게이트웨이·MCP·관측"이라는 결론에 자연스럽게 도달합니다.

플랫폼 컴포넌트 구성

sample-agentic-platform이 EKS에 올리는 핵심 컴포넌트는 다음과 같습니다.

배포는 Helm chart (k8s/helm/charts, k8s/helm/values) 기반이고, 각 에이전트는 FastAPI 서버로 port 8080의 /invocations 엔드포인트를 구현합니다. 이 컨벤션 덕분에 에이전트는 다음과 같이 균일한 패키지가 됩니다.

컨테이너 이미지 (FastAPI + 에이전트 런타임)
  └─ POST /invocations
       └─ 에이전트 코드(Strands/LangGraph)
            └─ LiteLLM Gateway → Bedrock
            └─ MCP server → tool 호출
            └─ Memory/Retrieval Gateway → 상태·문맥

인증·권한

이 워크샵은 에이전트·게이트웨이 Pod에 IRSA를 연결해 IAM 권한을 위임합니다. 4주차에서 정리했듯이 IRSA(OIDC Provider + ServiceAccount annotation 기반의 기존 경로)와 Pod Identity(EKS Pod Identity Association + Pod Identity Agent 기반의 신규 권장 경로)는 둘 다 ServiceAccount → IAM Role 매핑을 제공하지만, AWS는 신규 환경에 Pod Identity를 우선 검토하라고 안내합니다. 이 워크샵이 IRSA를 선택한 것은 OIDC 흐름이 명확히 필요한 경우에 해당하는 기존 패턴으로 보면 됩니다.

참고로 Part 1 LAB 3의 사전 준비 Terraform이 깔아둔 Pod Identity Association은 Kiro CLI 자체가 아니라 Advanced 트러블슈팅 시나리오의 carts 워크로드용이었습니다. Kiro CLI는 워크샵 IDE 터미널에서 사용자 AWS credentials로 동작하므로 Pod Identity 경로와는 별개입니다.

관측

Part 2의 GenAI on EKS가 Prometheus/Grafana 축으로 메트릭에 집중했다면, Agentic 워크샵은 OpenTelemetry collector를 가운데 두고 백엔드를 선택해 보내는 추상화가 중심입니다. 노트북 데모에서는 trace를 LangFuse, log/metric을 OpenSearch로 보내는 조합을 기본으로 보여주고, X-Ray·Phoenix·LogFire 같은 다른 백엔드로 라우팅을 갈아끼우는 패턴도 함께 다룹니다. 핵심은 agent run → tool call → model call의 호출 사슬을 trace context로 잇는다는 점이지, 특정 백엔드에 묶이지 않습니다.

아키텍처 개요

전체 요청 흐름을 머릿속에 잡아두면 각 Module을 따라가기 한결 수월합니다.

사용자 요청
  -> Ingress/ALB (Cognito 인증)
  -> 에이전트 Deployment (FastAPI :8080 /invocations)
  -> LiteLLM Gateway -> Amazon Bedrock (또는 AgentCore)
  -> MCP server -> tool 호출 (AWS API / 외부 SaaS)
  -> Memory/Retrieval Gateway -> 세션/벡터 조회
  -> OpenTelemetry -> X-Ray / CloudWatch / OpenSearch

여기서 EKS가 맡는 역할은 모델 자체를 제공하는 것이 아니라, 에이전트 런타임과 주변 구성요소를 안정적으로 배포하고 격리하고 확장하는 것입니다. 그래서 실습 중에는 "어떤 모델을 썼는가"보다 각 컴포넌트가 어떤 Pod와 Service로 뜨고, 어떤 권한으로 어떤 도구를 호출하는가를 더 중요하게 봐야 합니다.

Module 1. Prompt Engineering & Evaluation

첫 번째 Module은 EKS가 등장하기 전에 LLM 애플리케이션의 기본 단위인 프롬프트와 평가를 다룹니다. Bedrock Converse API를 사용해 chain-of-thought, few-shot, function calling, 간단한 RAG를 노트북에서 구현하고, 출력 품질을 체계적으로 평가하는 방법을 익힙니다.

워크샵이 보여주는 function calling의 한 호출 흐름은 다음과 같습니다 (모듈 1의 마지막 노트북).

sequenceDiagram
    participant App
    participant Bedrock
    participant Tool
    App->>Bedrock: User question + tool definitions
    Bedrock-->>App: "I want to call calculator(7, 3, multiply)"
    App->>Tool: Execute calculator(7, 3, multiply)
    Tool-->>App: Result: 21
    App->>Bedrock: "Tool returned 21"
    Bedrock-->>App: "7 times 3 equals 21"

플랫폼 관점에서 짚을 부분은 이 Module이 다음 단계 Module에서 만들어질 에이전트의 품질 기준선을 잡는다는 점입니다. 평가 지표 없이 에이전트를 운영하면 "모델을 바꿨는데 결과가 좋아졌는가"를 객관적으로 답할 수 없습니다.

관찰 포인트

• 동일 프롬프트에서 모델·파라미터를 바꿨을 때 출력 분산이 얼마나 큰가
• 평가가 자동화될 수 있는 형태인가 (정답 vs 비교형 vs LLM-as-judge)
• 함수 호출(function calling)의 입력 검증·실패 처리 책임은 누구에게 있는가

Module 2. Common Agentic Patterns

두 번째 Module은 단일 LLM 호출에서 벗어나 워크플로로 확장하는 패턴을 다룹니다. 병렬화, 라우팅, 평가-재시도, 오케스트레이션 같은 재사용 가능한 패턴을 노트북으로 구현하면서 "에이전트가 호출되는 흐름은 결국 그래프"라는 시각을 잡습니다.

마지막에 다루는 evaluator-optimizer 패턴이 이 모듈의 결론입니다.

flowchart LR
    START([START]) --> GA[Generate Answer]
    GA --> EQ{Evaluate Quality}
    EQ -- IMPROVE --> IA[Improve Answer]
    IA --> EQ
    EQ -- "DONE / max iterations" --> FIN[Finalize]
    FIN --> END([END])

이 Module은 Module 3·4에서 다룰 단일 에이전트와 멀티 에이전트의 차이가 어디서 발생하는지를 미리 보여줍니다. 단일 LLM 호출에 워크플로 패턴을 두르면 에이전트가 되고, 그래프의 노드를 별도 프로세스로 분리하면 멀티 에이전트가 됩니다.

관찰 포인트

• 같은 작업을 병렬 호출 vs 순차 호출로 처리했을 때 비용·지연·정확도가 어떻게 달라지는가
• 실패한 호출에 대한 재시도 정책이 워크플로 안에 들어가 있는가, 바깥에 있는가
• "어떤 작업이 워크플로의 어느 노드에 속하는가"를 결정하는 기준은 무엇인가

Module 3. Building Agentic Applications

세 번째 Module부터 본격적으로 에이전트를 만듭니다. 처음에는 외부 의존 없이 단일 에이전트를 from scratch로 짜고, 이어서 메모리·도구·검색·프레임워크(Strands·LangGraph)를 점진적으로 도입합니다.

워크샵의 모듈 3 노트북은 from-scratch / LangChain / PydanticAI 세 구현을 같은 Shared Platform Layer 위에 올려 비교합니다. 동일한 AgenticRequest·MemoryClient·AgenticResponse를 공유하면서 프레임워크별 구현체만 갈아끼우는 구조입니다.

flowchart LR
    REQ[AgenticRequest]
    subgraph A["Implementation A: From Scratch"]
        TCA["ToolCallingAgent
(notebooks 2-4)"]
    end
    subgraph B["Implementation B: LangChain"]
        LCA["LangChainAgent
(create_react_agent)"]
        LCMC[LangChainMessageConverter]
    end
    subgraph C["Implementation C: PydanticAI"]
        PA["PydanticAIAgent
(Agent.run_sync)"]
        PAMC[PydanticAIMessageConverter]
    end
    MEM["MemoryClient
(same instance)"]
    RES[AgenticResponse]
    REQ --> TCA
    REQ --> LCA --> LCMC
    REQ --> PA --> PAMC
    TCA --> MEM
    LCMC --> MEM
    PAMC --> MEM
    MEM --> RES

반면 sample-agentic-platform의 운영 코드(src/agentic_platform/agent/)에는 Strands(agentic_chat·agentic_rag·jira_agent·strands_glue_athena)와 LangGraph(langgraph_chat)가 함께 들어 있습니다. 모듈 3 노트북의 프레임워크 세트(from-scratch/LangChain/PydanticAI)와 운영 코드의 프레임워크 세트(Strands/LangGraph)가 다르다는 점은 이 워크샵의 학습 흐름이 "교실용 비교"와 "실제 플랫폼 코드"를 분리해 두었다는 신호입니다.

이때 운영 코드의 두 프레임워크가 같은 Shared Layer 위에 공존한다는 점이 의미 있습니다. 프레임워크는 갈아끼울 수 있는 모듈이고, 진짜 플랫폼 자산은 Shared Layer라는 시각이 여기서 명확해집니다.

관찰 포인트

• 에이전트 코드가 어떻게 컨테이너 이미지에 패키징되고, /invocations 엔드포인트로 노출되는가
• 메모리는 인메모리에 머무는가, 별도 Memory Gateway를 거치는가
• 도구는 함수 호출 수준에 머무는가, MCP server 호출까지 가는가
• 로컬 노트북 실행과 EKS 배포 사이에서 환경 변수·자격 증명이 어떻게 달라지는가
• 모델 API 키나 AWS 자격 증명은 Secret, ServiceAccount, IRSA 중 어디에 걸리는가

Module 4. Multi-Agent Systems & MCP

네 번째 Module은 두 축을 함께 다룹니다.

• MCP server/client 직접 빌드: 도구 호출을 표준 인터페이스로 추상화
• 멀티 에이전트 협업: 역할이 다른 에이전트를 분리해 협업하는 구조

워크샵의 멀티 에이전트 예시는 Researcher와 Writer를 분리하고 각 단계에 별도의 LLM 평가자를 끼워 피드백 루프를 만드는 구조입니다.

flowchart LR
    RQ["ResearchQuery
(Researcher Agent + MCP)"] --> ER["EvaluateResearch
(Structured LLM call)"]
    ER -- "REVISE (+ feedback)" --> RQ
    ER -- APPROVE --> WR["WriteReport
(Writer Agent)"]
    WR --> ERP["EvaluateReport
(Structured LLM call)"]
    ERP -- "REVISE (+ feedback)" --> WR
    ERP -- APPROVE --> END(["End
Final Report"])

Part 1의 Kiro LAB이 이미 만들어진 EKS MCP server를 소비했다면, 여기서는 MCP server를 직접 만들어 보고 거기에 에이전트가 client로 붙는 구조를 짜봅니다. 같은 MCP 패턴을 양쪽 관점에서 한 번씩 보게 되는 셈입니다.

멀티 에이전트 부분은 워크샵 페이지가 어떤 협업 프로토콜을 명시적으로 채택했는지 공개 소스에서 단정할 수는 없습니다. sample-agentic-platform 코드에서는 MCP를 매개로 한 도구 호출과 에이전트 간 직접 호출이 등장합니다.

관찰 포인트

• MCP server가 어떤 프로세스 또는 Pod로 실행되는가 (stdio · HTTP · WebSocket)
• 에이전트가 호출할 수 있는 도구 목록은 어디에서 정의되는가
• 도구 호출이 AWS API, Kubernetes API, 외부 SaaS 중 어디까지 닿는가
• 에이전트 간 호출은 동기 요청인가, 큐/이벤트 기반인가
• 한 에이전트의 실패가 전체 요청에 어떻게 전파되는가
• 모든 에이전트가 같은 모델을 쓰는가, 역할별로 다른 모델/파라미터를 쓰는가

운영 관점에서는 멀티 에이전트 구조가 항상 이득은 아닙니다. 역할 분리가 명확하지 않으면 호출 경로만 길어지고 디버깅이 어려워질 수 있습니다. 실습에서는 "왜 이 에이전트를 분리했는가"를 계속 확인하는 것이 좋습니다.

Module 5. Deployment and Infrastructure

마지막 Module이 이 워크샵을 다른 LLM 튜토리얼과 구분 짓는 지점입니다. 앞 Module에서 만든 에이전트와 도구를 실제 EKS 위에 운영 가능한 플랫폼으로 배포합니다.

이 단계에서 LiteLLM Gateway, Memory Gateway, Retrieval Gateway, MCP server, OpenTelemetry collector가 Helm chart로 차례로 들어옵니다. 에이전트 자체도 별도 Deployment로 분리되어 게이트웨이들을 통해 모델·메모리·도구를 호출합니다.

워크샵이 보여주는 LLM Gateway의 내부 구성은 다음과 같습니다. 인증·rate limit·사용량 추적·타입 변환이 한 게이트웨이 안에 묶이고, 그 뒤로 Bedrock·OpenAI·Gemini가 모두 같은 인터페이스로 호출됩니다.

flowchart TB
    CA["Client Applications
(PydanticAI / LangChain / boto3)"]
    CA -- "OAuth / Bearer Token" --> LG[LLM Gateway]
    subgraph INT["LLM Gateway Internals"]
        RL[Rate Limiter]
        TC[Type Converter]
        UT[Usage Tracker]
        AM[Authentication Module]
    end
    LG --> INT
    RL -- "Sliding Window" --> REDIS[("Redis Cache
(ElastiCache)")]
    UT -- "Store Metrics" --> DDB[(DynamoDB)]
    LG --> BR[Bedrock Models]
    LG --> OAI[OpenAI GPT]
    LG --> GG[Google Gemini]

관찰 포인트

• 세션 상태와 대화 메모리는 어디에 저장되는가 (Memory Gateway 백엔드)
• 벡터 스토어가 있다면 색인 생성과 조회 경로는 어떻게 나뉘는가 (Retrieval Gateway)
• LiteLLM Gateway가 인증·라우팅·rate limit·관측 중 무엇을 담당하는가
• HPA나 KEDA 같은 스케일링 구성이 에이전트와 게이트웨이 양쪽에 들어가는가
• OpenTelemetry trace에서 agent run, tool call, model call을 구분할 수 있는가
• 워크샵 종료 후 비용 통제 지점은 어디인가 (Bedrock 호출, OpenSearch, EKS 노드)

이 단계에서 중요한 기준은 "한 번 응답이 잘 나왔다"가 아니라, 장애가 났을 때 어느 레이어를 봐야 하는지 설명할 수 있는가입니다.

따라가며 남길 체크리스트

실습 중에는 각 Module이 끝날 때마다 다음 명령과 질문을 함께 남겨두면 나중에 글로 정리하기 쉽습니다.

kubectl get ns
kubectl get deploy,svc,ingress -A
kubectl get sa -A
kubectl get pods -A -o wide
kubectl describe pod -n <namespace> <pod>
kubectl logs -n <namespace> <pod>
helm list -A

• 새로 생긴 Namespace와 핵심 Pod(LiteLLM·Memory·Retrieval Gateway, MCP server, 에이전트)는 무엇인가
• 외부로 노출된 endpoint는 무엇인가 (ALB/Ingress 한 개인가, 다중인가)
• 에이전트가 호출할 수 있는 tool 목록은 어디에서 정의되는가 (MCP server 메니페스트)
• tool 호출 권한은 IAM(IRSA), RBAC, 애플리케이션 설정 중 어디에서 제한되는가
• 요청 하나를 보냈을 때 X-Ray trace에 어떤 segment가 남는가
• 워크샵 종료 후 반드시 지워야 할 리소스는 무엇인가 (Bedrock Knowledge Base, OpenSearch 도메인, ALB)

운영 관점에서 미리 의심할 부분

• 권한 경계: 에이전트가 사용할 수 있는 tool은 곧 사용자가 자연어로 간접 실행할 수 있는 작업 목록입니다. MCP server, ServiceAccount, IRSA가 부여한 IAM Role을 한꺼번에 봐야 합니다.
• 상태 저장: Memory Gateway가 들어가면 개인정보, 보존 기간, 삭제 정책이 바로 운영 이슈가 됩니다. 백엔드(예: 캐시·DB)별 보존 정책이 일치하는지 확인이 필요합니다.
• 관측성: 일반 HTTP 요청 로그만으로는 agent run, tool call, model call을 구분하기 어렵습니다. OpenTelemetry trace를 처음부터 켜둔 이 워크샵 구성은 운영 환경에 그대로 이식할 가치가 있습니다.
• 비용 통제: Bedrock 호출, 벡터 검색(OpenSearch), 에이전트 재시도, HPA 확장이 함께 움직이면 비용 원인을 분해하기 어려워집니다. LiteLLM Gateway에서 모델별 호출량·토큰량을 모으는 게 첫 가드레일입니다.
• 결정성 부족: 같은 요청이 매번 같은 tool call 순서로 실행된다는 보장이 약합니다. runbook을 대체하기보다 runbook을 생성·검증하는 보조 수단으로 보는 편이 안전합니다.

마치며

이번 편의 핵심은 에이전트를 "똑똑한 챗봇"으로 보는 것이 아니라, Kubernetes 위에서 배포·권한·네트워크·상태·관측을 함께 관리해야 하는 분산 애플리케이션으로 보는 것입니다. Part 1에서 MCP를 운영 도구 연결 방식으로 봤다면, 여기서는 MCP가 에이전트 플랫폼 내부에서 도구 호출의 표준 경계로 자리잡는 모습을 확인합니다.

9주차 세 편을 묶어 보면 결국 한 가지 흐름이 드러납니다.

• Part 1은 EKS 위에서 AWS Neuron 가속기와 Kiro + MCP를 통해 "가속기·운영 도구의 기반"을 닦았고,
• Part 2는 EKS Auto Mode 위에 vLLM·Ray Serve·AMP/Grafana로 "추론 서빙의 운영 흐름"을 잡았고,
• Part 3은 그 추론 엔드포인트가 단순 API 소비 대상이 아니라 에이전트 플랫폼의 한 컴포넌트로 들어가는 한 단계 위 구조를 확인했습니다.

EKS 위에서 AI 워크로드를 다룬다는 말이 이제는 GPU 노드 한 대를 띄우는 일이 아니라, 가속기 선택부터 추론 서빙, 에이전트 운영, 관측·권한 위임까지를 한 줄로 잇는 일이라는 점이 9주차 세 워크샵을 묶었을 때 가장 분명해집니다.