AWS Summit Seoul 2026 후기

🥑 들어가며

5월 20일부터 21일까지 진행된 AWS Summit Seoul 2026에 다녀왔다.

이번에 AWS Summit에 가게 된 가장 큰 이유는 요즘 클라우드와 AI 트렌드가 어떻게 흘러가고 있는지 직접 보고 싶었기 때문이다. 최근에는 DevOps, Kubernetes, MSA 같은 인프라 주제에 관심이 많아졌고, AWS가 이런 흐름을 어떤 방향으로 풀어내고 있는지도 궁금했다.

이번 글에서는 AWS Summit Seoul 2026에서 인상 깊었던 내용과 개인적으로 느낀 점을 정리해보려 한다.

입장 및 기조연설

지방에서 오전에 버스를 타고 출발했다. 문제는 하차가 10분 정도 늦어져 행사장에 조금 늦게 도착했다는 것이다. 결국 기조연설은 중간부터 듣게 되었다.

기조연설에서는 AWS가 바라보는 클라우드와 AI의 방향성을 볼 수 있었다. 특히 단순히 인프라를 제공하는 것을 넘어, 개발자가 더 빠르게 만들고 운영할 수 있도록 돕는 도구와 플랫폼을 강조한다는 인상을 받았다.

기억에 남았던 키워드

르네상스 개발자

기조연설 중 르네상스 시대의 개발자라는 표현이 흥미로웠다. 행사 이후 관련 글도 찾아보았다.

이 표현은 개발자가 단순히 코드를 작성하는 역할에 머무르지 않고, AI와 클라우드 도구를 활용해 더 넓은 범위의 문제를 해결하는 방향으로 변하고 있다는 의미로 느껴졌다.

예전에는 백엔드, 프론트엔드, 인프라, 데이터처럼 역할이 비교적 분리되어 있었다면, 이제는 AI 도구와 관리형 클라우드 서비스 덕분에 한 사람이 다룰 수 있는 영역이 점점 넓어지고 있다.

생성형 AI와 개발 방식의 변화

이번 AWS Summit의 큰 흐름 중 하나는 생성형 AI였다.

단순히 AI 모델을 제공하는 것을 넘어서, 개발 생산성, 고객 지원, 데이터 분석, 운영 자동화 등 여러 영역에 AI를 붙이는 방향이 강조되고 있었다.

특히 개발자 관점에서는 AI가 코드를 대신 작성해주는 도구라기보다, 개발 과정에서 반복적인 작업을 줄이고 더 빠르게 의사결정할 수 있게 돕는 도구에 가깝다고 느꼈다.

클라우드 운영과 자동화

최근 Kubernetes와 DevOps를 공부하면서 느낀 것은, 서비스를 잘 만드는 것만큼 안정적으로 운영하는 것도 중요하다는 점이다.

AWS Summit에서도 운영 자동화, 모니터링, 보안, 비용 최적화 같은 주제가 계속 등장했다. 클라우드가 단순히 서버를 빌려 쓰는 개념이 아니라, 애플리케이션의 배포와 운영 방식을 바꾸는 플랫폼이라는 점을 다시 느낄 수 있었다.

둘러본 세션과 부스

아직 세션 내용을 모두 정리하지는 못했지만, 기억에 남는 내용들을 중심으로 정리해보려 한다.

5월 20일 세션

KBaaS, 금융이 플랫폼속으로: KB 국민은행의 임베디드 금융 전략과 API 인프라 현대화

이 세션은 KB 국민은행이 금융 기능을 하나의 플랫폼처럼 제공하기 위해 어떤 방향으로 API 인프라를 현대화하고 있는지 다룬 세션이었다.

KBaaS는 이름 그대로 Banking as a Service에 가까운 개념으로 이해했다. 금융 서비스를 은행 앱 안에서만 제공하는 것이 아니라, 외부 플랫폼이나 서비스 안에 자연스럽게 녹여 넣는 방식이다. 이를 위해서는 계좌, 결제, 인증, 조회 같은 금융 기능이 안정적인 API 형태로 제공되어야 한다.

기억에 남았던 키워드는 임베디드 금융이었다. 사용자가 금융 서비스를 이용하기 위해 은행 채널로 직접 이동하는 것이 아니라, 사용자가 머무르는 서비스 흐름 안에서 금융 기능을 사용할 수 있게 만드는 방향이다.

외부 서비스 / 플랫폼
        ↓
금융 API
        ↓
은행 내부 시스템

이 구조에서 중요한 것은 단순히 API를 여는 것이 아니다. 금융 도메인 특성상 보안, 인증, 권한, 트래픽 제어, 장애 대응, 감사 추적 같은 요구사항이 함께 따라온다. 그래서 API 인프라 현대화는 단순한 기술 교체가 아니라, 금융 서비스를 플랫폼화하기 위한 기반 작업에 가깝다고 느꼈다.

개인적으로는 이 세션이 Kubernetes나 MSA를 공부하면서 봤던 내용과도 연결되어 흥미로웠다. 서비스를 잘게 나누고 API로 연결하는 것만으로는 충분하지 않고, 외부에 제공 가능한 수준의 안정성과 운영 체계를 갖춰야 진짜 플랫폼이 될 수 있다는 생각이 들었다.

특히 금융권처럼 안정성과 신뢰가 중요한 환경에서는 API Gateway, 인증/인가, 모니터링, 장애 격리, 배포 자동화 같은 요소가 더 중요해질 수밖에 없다. 결국 임베디드 금융도 기술적으로 보면 잘 설계된 API 플랫폼과 운영 인프라 위에서 가능하다는 점이 인상 깊었다.

쿠팡의 RedShift 멀티 클러스터 아키텍처 최적화 전략

이 세션은 쿠팡이 Amazon Redshift를 멀티 클러스터 구조로 운영하면서 어떤 방식으로 아키텍처를 최적화했는지 다룬 세션이었다.

Redshift는 대규모 데이터를 분석하기 위한 데이터 웨어하우스 서비스다. 데이터가 많아지고 분석 요구사항이 다양해지면 하나의 클러스터에서 모든 워크로드를 처리하기 어려워질 수 있다.

예를 들어 아래와 같은 워크로드가 동시에 존재할 수 있다.

• 실시간에 가까운 대시보드 조회
• 정기 배치성 리포트 생성
• 데이터 분석가의 ad-hoc query
• ETL/ELT 작업
• 서비스 운영 지표 분석

이런 작업을 하나의 클러스터에서 모두 처리하면 특정 무거운 쿼리가 전체 성능에 영향을 줄 수 있다. 그래서 멀티 클러스터 아키텍처는 워크로드를 분리하고, 각 목적에 맞게 리소스를 조정하는 전략으로 이해했다.

Data Lake / Source
        ↓
Redshift Cluster A - Dashboard
Redshift Cluster B - Batch Report
Redshift Cluster C - Ad-hoc Analysis

이 세션에서 인상 깊었던 부분은 데이터 인프라도 결국 애플리케이션 인프라와 비슷한 고민을 한다는 점이었다. 트래픽을 나누고, 병목을 줄이고, 비용과 성능 사이에서 균형을 잡아야 한다.

특히 Redshift 같은 분석 시스템에서는 단순히 클러스터를 크게 만드는 것보다, 워크로드 특성에 따라 분리하고 최적화하는 것이 중요해 보였다. 읽기 패턴, 쿼리 복잡도, 사용 시간대, 데이터 신선도 요구사항이 다르면 같은 데이터 분석이라도 운영 방식이 달라질 수밖에 없다.

개인적으로는 이 세션을 들으면서 MSA에서 서비스별로 책임을 나누는 것과 비슷하다는 생각이 들었다. 애플리케이션에서는 서비스 단위로 트래픽과 장애를 분리하고, 데이터 분석 환경에서는 클러스터 단위로 워크로드와 비용을 분리하는 식이다.

결국 중요한 것은 “하나로 크게 처리하기”보다 “특성에 맞게 나누고 운영하기”라는 점이었다.

Convert To AI-Ready Data: 미래에셋증권의 GraphRAG 기반 상품 지식 DB 구축기

이 세션은 미래에셋증권이 금융 상품 지식을 AI가 활용할 수 있는 형태로 바꾸기 위해 GraphRAG 기반 지식 DB를 구축한 사례를 다룬 세션이었다.

최근 생성형 AI를 서비스에 적용하려는 시도가 많지만, 결국 중요한 것은 모델 자체보다 모델이 참고할 수 있는 데이터의 품질이라는 생각이 들었다. 특히 금융 상품처럼 용어가 복잡하고 관계가 많은 도메인에서는 단순히 문서를 벡터화해서 검색하는 것만으로는 한계가 있을 수 있다.

GraphRAG는 Graph와 RAG를 결합한 접근으로 이해했다. 일반적인 RAG가 문서를 검색해서 LLM에 참고 자료로 넘기는 방식이라면, GraphRAG는 데이터 사이의 관계를 그래프 형태로 표현해 더 구조적인 검색과 추론을 돕는다.

금융 상품 문서
      ↓
Entity / Relationship 추출
      ↓
상품 지식 Graph DB
      ↓
GraphRAG
      ↓
LLM 답변

금융 상품 데이터는 단순 텍스트가 아니라 상품, 조건, 위험 등급, 수수료, 투자 대상, 규정 같은 요소들이 서로 연결되어 있다. 그래서 “이 상품이 어떤 고객에게 적합한가”, “비슷한 상품과 어떤 차이가 있는가” 같은 질문에 답하려면 관계 정보가 중요해진다.

이 세션에서 인상 깊었던 점은 AI-Ready Data라는 표현이었다. AI를 잘 쓰기 위해서는 데이터를 그냥 많이 모으는 것이 아니라, AI가 이해하고 활용할 수 있는 형태로 정리해야 한다는 의미로 느껴졌다.

개인적으로는 이 내용이 데이터 엔지니어링과 AI 서비스 개발 사이의 연결 지점처럼 보였다. 좋은 LLM을 붙이는 것만으로는 충분하지 않고, 도메인 지식을 어떻게 구조화하고 검색 가능하게 만들 것인지가 실제 서비스 품질을 크게 좌우할 것 같다.

결국 생성형 AI 서비스의 핵심은 모델 호출이 아니라, 모델이 신뢰할 수 있는 컨텍스트를 제공하는 데이터 기반을 만드는 일이라는 생각이 들었다.

다운타임 0의 도전: Agentic AI와 Bedrock으로 완성하는 자율 예지정비

이 세션은 Agentic AI와 Amazon Bedrock을 활용해 장애를 사전에 예측하고 대응하는 자율 예지정비를 다룬 세션이었다.

예지정비는 문제가 발생한 뒤 대응하는 것이 아니라, 장애가 발생하기 전에 이상 징후를 감지하고 미리 조치하는 접근이다. 특히 제조, 설비, 인프라, 서비스 운영처럼 다운타임이 비용과 직결되는 환경에서는 매우 중요한 주제다.

운영 데이터 / 로그 / 메트릭
        ↓
이상 징후 감지
        ↓
Agentic AI 판단
        ↓
조치 계획 수립
        ↓
자동 대응 또는 운영자 승인

기존의 모니터링은 임계치를 넘으면 알림을 보내는 방식에 가까웠다. 하지만 Agentic AI는 단순 알림을 넘어서, 상황을 해석하고 가능한 원인을 추론한 뒤 다음 행동을 제안하거나 수행하는 방향으로 확장될 수 있다.

Amazon Bedrock은 이런 Agentic AI를 만들기 위한 기반으로 소개되었다. 여러 Foundation Model을 활용하고, 필요한 도구나 데이터 소스와 연결해 특정 업무를 수행하는 Agent를 구성할 수 있다는 점이 핵심으로 느껴졌다.

이 세션에서 흥미로웠던 점은 AI가 운영 영역으로 들어오는 방식이었다. AI를 챗봇이나 문서 검색에만 쓰는 것이 아니라, 장애 예방과 운영 자동화에 활용한다는 점이 인상 깊었다.

특히 Kubernetes나 DevOps를 공부하면서 보던 observability, alert, incident response와도 연결되는 주제였다. 운영 데이터가 충분히 쌓이고, 로그와 메트릭이 잘 정리되어 있다면 AI가 장애 대응 과정의 일부를 도울 수 있겠다는 생각이 들었다.

물론 모든 조치를 AI가 바로 수행하는 것은 위험할 수 있다. 특히 운영 환경에서는 잘못된 자동 조치가 더 큰 장애를 만들 수도 있기 때문에, 처음에는 운영자 승인 기반의 human-in-the-loop 구조가 현실적일 것 같다.

결국 다운타임 0이라는 목표는 단순히 좋은 인프라를 쓰는 것만으로 달성되는 것이 아니라, 관측 가능한 데이터, 이상 탐지, 원인 분석, 자동화된 대응 체계가 함께 갖춰져야 가능하다는 생각이 들었다.

AWS 서버리스로 완성하는 확장 가능한 멀티 에이전트 시스템

이 세션은 AWS 서버리스 서비스를 활용해 확장 가능한 멀티 에이전트 시스템을 구성하는 방법을 다룬 세션이었다.

멀티 에이전트 시스템은 하나의 거대한 Agent가 모든 일을 처리하는 것이 아니라, 역할이 다른 여러 Agent가 협력해서 문제를 해결하는 구조다. 예를 들어 하나의 Agent는 사용자의 요청을 분석하고, 다른 Agent는 데이터를 조회하고, 또 다른 Agent는 결과를 검증하거나 후속 작업을 수행할 수 있다.

User Request
     ↓
Orchestrator Agent
     ↓
Planner Agent
     ↓
Tool / Data Agent
     ↓
Reviewer Agent
     ↓
Response

이 구조에서 중요한 것은 Agent 간 역할 분리와 오케스트레이션이다. 각 Agent가 어떤 책임을 가지는지, 어떤 순서로 실행되는지, 실패했을 때 어떻게 재시도하거나 중단할지를 설계해야 한다.

AWS 서버리스는 이런 구조와 잘 맞는 부분이 있다. 요청량에 따라 자동으로 확장되고, 필요한 순간에만 실행되며, 이벤트 기반으로 여러 컴포넌트를 연결하기 쉽기 때문이다.

예를 들어 멀티 에이전트 시스템은 아래와 같은 AWS 서비스와 연결해 생각해볼 수 있다.

역할	활용 가능한 AWS 서비스
Agent 실행	AWS Lambda
Agent workflow orchestration	AWS Step Functions
Foundation Model 호출	Amazon Bedrock
이벤트 전달	Amazon EventBridge
메시지 큐	Amazon SQS
상태 저장	Amazon DynamoDB

특히 Step Functions는 여러 Agent의 실행 순서를 정의하고, 분기, 재시도, 실패 처리를 명시적으로 표현할 수 있다는 점에서 멀티 에이전트 오케스트레이션과 잘 어울린다고 느꼈다.

Step Functions
 ├── 요청 분석 Agent
 ├── 데이터 조회 Agent
 ├── 도구 실행 Agent
 └── 결과 검증 Agent

개인적으로 흥미로웠던 점은 AI Agent 시스템도 결국 분산 시스템이라는 점이었다. Agent가 많아질수록 각 Agent의 책임, 상태 관리, 실패 처리, 비용 관리, 관측성이 중요해진다. 단순히 LLM을 호출하는 수준을 넘어서, 안정적으로 운영 가능한 아키텍처를 설계해야 실제 서비스로 이어질 수 있다.

서버리스는 이런 멀티 에이전트 시스템을 빠르게 실험하고 확장하기에 좋은 선택지로 보였다. 다만 요청 흐름이 복잡해질수록 observability와 비용 추적을 함께 설계해야 한다는 생각도 들었다.

2천만 디바이스 요청을 처리하는 API Gateway 마이그레이션 생존기

이 세션은 2천만 디바이스에서 발생하는 요청을 처리하는 API Gateway를 마이그레이션하면서 겪은 고민과 전략을 다룬 세션이었다.

API Gateway는 단순히 요청을 백엔드로 전달하는 프록시가 아니다. 대규모 서비스에서는 인증, 인가, 라우팅, rate limiting, 모니터링, 로깅, 장애 대응, 트래픽 제어 같은 역할을 함께 수행한다.

특히 2천만 디바이스 규모라면 API Gateway는 시스템의 가장 앞단에서 엄청난 양의 요청을 받아내는 핵심 인프라가 된다.

Devices
   ↓
API Gateway
   ↓
Backend Services

이런 구조에서 마이그레이션은 단순히 새로운 Gateway로 바꾸는 작업이 아니다. 서비스 중단 없이 트래픽을 옮겨야 하고, 기존 API 호환성을 유지해야 하며, 장애가 발생했을 때 빠르게 롤백할 수 있어야 한다.

대규모 API Gateway 마이그레이션에서 중요해 보였던 포인트는 다음과 같다.

• 기존 API contract 유지
• 점진적인 트래픽 전환
• 모니터링과 로그 기반 검증
• 장애 발생 시 즉시 rollback 가능한 구조
• 인증/인가 정책의 일관성 유지
• latency와 error rate 관찰

개인적으로는 이 세션이 API 인프라의 중요성을 다시 생각하게 했다. 백엔드 서비스 내부 구조도 중요하지만, 실제 사용자의 요청이 처음 도착하는 관문을 안정적으로 운영하는 것도 그만큼 중요하다.

특히 디바이스 수가 많을수록 작은 latency 증가나 error rate 변화도 전체 사용자 경험에 큰 영향을 줄 수 있다. 그래서 API Gateway 마이그레이션은 기능 이전보다 운영 안정성과 관측성이 더 중요한 작업처럼 느껴졌다.

이 내용은 Kubernetes의 Ingress나 Service Mesh와도 연결해서 생각해볼 수 있었다. 어떤 기술을 쓰든 결국 외부 요청을 안전하게 받아 내부 서비스로 전달하고, 장애를 격리하고, 트래픽을 제어하는 계층이 필요하다는 점은 같다.

요기요의 AIOps: SRE 운영의 콘솔 탈출기

이 세션은 요기요가 SRE 운영 과정에서 콘솔 중심의 수동 작업을 줄이고, AIOps를 통해 운영 효율을 높여가는 과정을 다룬 세션이었다.

SRE 업무에서는 장애 대응, 알림 확인, 로그 분석, 메트릭 조회, 배포 상태 확인처럼 반복적으로 수행하는 작업이 많다. 이런 작업을 매번 콘솔에 들어가 사람이 직접 확인하고 판단하면 시간이 오래 걸리고, 운영자의 피로도도 커질 수밖에 없다.

콘솔 탈출기라는 표현이 인상적이었다. 단순히 AWS Console을 쓰지 않는다는 의미라기보다, 사람이 화면을 하나씩 확인하며 운영하는 방식에서 벗어나 운영 흐름을 자동화하고 지능화하려는 시도로 느껴졌다.

Alert
  ↓
Log / Metric / Trace 수집
  ↓
AIOps 분석
  ↓
원인 후보 정리
  ↓
대응 가이드 또는 자동 조치

AIOps는 운영 데이터를 기반으로 이상 징후를 탐지하고, 원인 분석을 돕고, 반복적인 대응을 자동화하는 방향으로 이해했다. SRE 관점에서는 장애를 더 빨리 파악하고, 대응 시간을 줄이며, 운영자의 인지 부담을 낮추는 것이 핵심이다.

이 세션은 앞서 들었던 Agentic AI 기반 예지정비와도 연결되는 부분이 있었다. 예지정비가 장애를 미리 감지하고 예방하는 방향이라면, AIOps는 실제 운영 과정에서 발생하는 알림과 장애 대응 흐름을 더 효율적으로 만드는 방향에 가깝다.

개인적으로는 운영 자동화에서 중요한 것은 무조건 자동 조치를 늘리는 것이 아니라, 사람이 판단해야 하는 지점을 줄이고 필요한 정보를 빠르게 모아주는 것이라고 느꼈다. 장애 상황에서는 로그, 메트릭, 배포 이력, 인프라 상태를 여기저기서 확인하는 시간이 길어질수록 대응이 늦어진다.

결국 SRE 운영의 핵심은 관측성, 자동화, 표준화된 대응 흐름이라는 생각이 들었다. AI는 이 흐름에서 운영자가 더 빨리 판단할 수 있도록 도와주는 도구로 활용될 수 있다.

새벽 3시, 18만 개의 모델이 대신 판단한다: 넥슨의 에이전틱 Ops

이 세션은 넥슨이 대규모 운영 환경에서 Agentic AI를 활용해 Ops 판단을 자동화하는 사례를 다룬 세션이었다.

제목의 새벽 3시라는 표현이 인상적이었다. 운영 관점에서 새벽 시간대의 장애나 이상 징후는 대응이 어렵다. 사람이 항상 모든 상황을 실시간으로 확인하고 판단하기 어렵기 때문에, 반복적인 판단과 초기 대응을 AI가 도울 수 있다면 운영 부담을 크게 줄일 수 있다.

18만 개의 모델이라는 표현에서는 넥슨이 다루는 서비스와 운영 지표의 규모가 느껴졌다. 게임 서비스는 사용자 행동, 서버 상태, 매칭, 결제, 이벤트, 트래픽 패턴 등 다양한 지표가 동시에 움직인다. 이런 환경에서는 하나의 범용 모델이 모든 상황을 판단하기보다, 각 도메인과 지표에 맞는 많은 모델이 함께 동작하는 구조가 필요할 수 있다.

서비스 로그 / 메트릭 / 이벤트
        ↓
다수의 판단 모델
        ↓
Agentic Ops
        ↓
이상 탐지 / 원인 후보 / 대응 판단
        ↓
운영자 알림 또는 자동 조치

이 세션에서 흥미로웠던 점은 Ops 영역에서 AI가 단순 분석 도구를 넘어 판단 주체에 가까워지고 있다는 점이었다. 기존 운영 자동화가 “정해진 조건이 발생하면 정해진 조치를 수행한다”에 가까웠다면, Agentic Ops는 상황을 해석하고 다음 행동을 결정하는 방향에 가깝다.

물론 운영 판단을 AI에 맡긴다는 것은 신뢰성과 안전장치가 매우 중요하다는 뜻이기도 하다. 잘못된 판단이 서비스 장애로 이어질 수 있기 때문에, 모델의 판단 근거를 추적하고, 자동 조치 범위를 제한하고, 필요할 때 사람이 개입할 수 있는 구조가 필요하다.

개인적으로는 이 세션이 AIOps의 다음 단계처럼 느껴졌다. AIOps가 운영 데이터를 분석해 사람의 판단을 돕는다면, Agentic Ops는 일부 판단과 행동까지 Agent가 수행하는 방향으로 확장된다.

결국 운영 자동화의 방향은 단순 알림을 줄이는 것에서 시작해, 원인 분석을 돕고, 나아가 제한된 범위의 판단과 조치까지 자동화하는 쪽으로 가고 있다는 생각이 들었다.

5월 21일 세션

21억 사용자규모 삼성 어카운트의 에이전틱 AIOps on AWS

이 세션은 21억 사용자 규모의 Samsung Account 운영 환경에서 Agentic AIOps를 AWS 위에서 어떻게 활용할 수 있는지 다룬 세션이었다.

21억 사용자 규모라는 숫자에서 가장 먼저 느껴진 것은 운영 복잡도였다. 사용자 수가 이 정도로 커지면 장애 하나가 미치는 영향도 크고, 지역별 트래픽, 인증 요청, 계정 연동, 보안 이벤트 등 관찰해야 할 지표도 많아질 수밖에 없다.

Samsung Account 같은 계정 시스템은 여러 서비스의 진입점 역할을 한다. 사용자가 로그인하고, 인증하고, 여러 서비스와 연결되는 기반이기 때문에 안정성이 특히 중요하다.

Global Users
      ↓
Samsung Account
      ↓
Authentication / Authorization
      ↓
Connected Services

이런 환경에서 AIOps는 단순 알림 시스템을 넘어 운영자의 판단을 돕는 역할을 할 수 있다. 로그, 메트릭, 트레이스, 보안 이벤트를 모아 이상 징후를 감지하고, 원인 후보를 좁히고, 대응 방향을 제안하는 식이다.

여기에 Agentic이라는 키워드가 붙으면 한 단계 더 나아간다. 단순히 “이상하다”고 알려주는 것이 아니라, 상황을 분석하고 필요한 정보를 조회하며, 다음 조치를 계획하는 Agent의 역할이 중요해진다.

Alert / Incident
      ↓
Agentic AIOps
      ↓
관련 로그, 메트릭, 변경 이력 수집
      ↓
원인 후보 분석
      ↓
대응 방안 제안
      ↓
운영자 승인 또는 자동 조치

개인적으로는 앞서 들었던 요기요 AIOps, 넥슨 Agentic Ops 세션과 같은 흐름으로 연결해서 볼 수 있었다. 세션마다 도메인은 다르지만 공통점은 운영 데이터가 너무 많아 사람이 모든 것을 직접 확인하기 어렵고, AI가 이를 요약하고 판단을 보조하는 방향으로 발전하고 있다는 점이다.

특히 계정 시스템처럼 신뢰성과 보안이 중요한 영역에서는 자동화의 범위를 신중하게 정해야 한다고 느꼈다. AI가 바로 조치하는 것보다, 우선은 원인 분석과 대응 가이드 제공을 통해 운영자의 의사결정을 빠르게 만드는 방식이 현실적일 수 있다.

결국 대규모 서비스 운영에서 중요한 것은 장애를 빨리 감지하는 것뿐만 아니라, 그 장애가 왜 발생했는지 빠르게 좁히고, 안전하게 대응하는 체계를 만드는 것이다. Agentic AIOps는 이 과정에서 운영자의 시간을 줄이고, 반복적인 분석을 자동화하는 방향으로 활용될 수 있다고 느꼈다.

인퍼런스와 모델 퍼포먼스 최적화를 위한 EKS 아키텍처

이 세션은 Amazon EKS 위에서 AI 모델 인퍼런스 환경을 구성하고, 모델 성능과 운영 효율을 최적화하는 아키텍처를 다룬 세션이었다.

모델을 학습시키는 것과 실제 서비스에서 안정적으로 추론 요청을 처리하는 것은 다른 문제다. 서비스 환경에서는 latency, throughput, GPU 사용률, auto scaling, 배포 전략, 비용까지 함께 고려해야 한다.

Client
  ↓
Inference API
  ↓
EKS Service / Ingress
  ↓
Model Serving Pod
  ↓
GPU Node

EKS를 사용하면 Kubernetes의 배포, 스케일링, 롤링 업데이트 같은 장점을 모델 서빙 환경에도 적용할 수 있다. 모델 서버를 Pod로 배포하고, Service나 Ingress를 통해 요청을 라우팅하며, 필요에 따라 replica 수를 조정할 수 있다.

인퍼런스 최적화에서 중요해 보였던 포인트는 다음과 같다.

• 모델별 resource request/limit 설정
• GPU Node Group 분리
• 요청량에 따른 auto scaling
• cold start와 scale-out 시간 고려
• 모델 버전별 배포 전략
• latency와 throughput 모니터링
• 비용 대비 GPU 사용률 최적화

특히 GPU 리소스는 비용이 크기 때문에 단순히 넉넉하게 띄워두는 방식으로 운영하기 어렵다. 요청 패턴에 맞춰 적절히 scale out/in하고, 모델별로 필요한 리소스를 분리하는 것이 중요해 보였다.

개인적으로는 이 세션이 Kubernetes를 공부하는 입장에서 흥미로웠다. 기존에는 Web/API 서버를 Deployment로 띄우는 정도를 생각했다면, AI 모델 서빙도 결국 Kubernetes 위에서 하나의 워크로드로 운영될 수 있다는 점이 인상 깊었다.

다만 모델 서빙은 일반적인 API 서버보다 고려할 것이 많다. GPU 스케줄링, 모델 로딩 시간, batch inference, 실시간 inference, 모델 버전 관리처럼 AI 워크로드 특유의 운영 문제가 있기 때문이다.

결국 EKS 기반 인퍼런스 아키텍처의 핵심은 Kubernetes의 운영 모델 위에 AI 워크로드의 특성을 잘 반영하는 것이라고 느꼈다.

IaC 기반 EKS 멀티태넌시와 Sidecar-less 네트워킹

이 세션은 EKS 환경에서 IaC를 기반으로 멀티태넌시를 구성하고, Sidecar-less 네트워킹을 통해 네트워크 운영 복잡도를 줄이는 방향을 다룬 세션이었다.

멀티태넌시는 하나의 클러스터 또는 플랫폼을 여러 팀이나 서비스가 함께 사용하되, 각 tenant의 리소스와 권한을 분리하는 구조다. EKS 같은 Kubernetes 환경에서는 Namespace, RBAC, Network Policy, ResourceQuota 등을 조합해 tenant 간 경계를 만들 수 있다.

EKS Cluster
 ├── Team A Namespace
 ├── Team B Namespace
 └── Team C Namespace

이런 구성을 수동으로 만들면 시간이 갈수록 일관성을 유지하기 어렵다. 그래서 IaC가 중요해진다. Terraform, CDK, Helm 같은 도구로 클러스터 구성, Namespace, 권한, 네트워크 정책, add-on 설정을 코드로 관리하면 재현성과 변경 추적이 좋아진다.

IaC Code
   ↓
EKS Cluster / Namespace / RBAC / Network Policy
   ↓
Tenant별 표준 환경 제공

Sidecar-less 네트워킹은 기존 Service Mesh처럼 Pod마다 proxy sidecar를 붙이는 방식의 부담을 줄이려는 접근으로 이해했다. Sidecar 방식은 트래픽 제어, mTLS, 관측성 같은 기능을 제공하지만, Pod마다 proxy가 추가되기 때문에 리소스 사용량과 운영 복잡도가 늘어난다.

기존 Sidecar 방식

Pod
 ├── app
 └── proxy sidecar

Sidecar-less 방식은 이런 기능을 sidecar 컨테이너가 아니라 네트워크 계층이나 node 단에서 처리하려는 방향이다.

Sidecar-less

App Pod
  ↓
Node / Network Layer
  ↓
Other Service

개인적으로는 이 세션이 Kubernetes 운영이 성숙해질수록 생기는 고민을 잘 보여준다고 느꼈다. 처음에는 Pod, Deployment, Service를 이해하는 것이 중요하지만, 실제 조직에서 여러 팀이 함께 EKS를 쓰기 시작하면 권한 분리, 비용 관리, 네트워크 격리, 표준화된 배포 환경이 더 중요해진다.

또한 Sidecar-less 네트워킹은 이전에 공부했던 Service Mesh 흐름과도 연결되었다. Sidecar는 강력하지만 비용이 있고, 그 비용을 줄이기 위해 eBPF나 node-level proxy 같은 접근이 등장하는 흐름이 이해됐다.

결국 EKS 운영의 핵심은 단순히 클러스터를 띄우는 것이 아니라, 여러 팀이 안전하고 일관되게 사용할 수 있는 플랫폼으로 만드는 것이라는 생각이 들었다.

우아한형제들의 Nova 2 프로덕션 적용 여정

이 세션은 우아한형제들이 Amazon Nova 2를 실제 프로덕션 환경에 적용하면서 어떤 과정을 거쳤는지 다룬 세션이었다.

AI 모델을 데모로 사용해보는 것과 실제 서비스에 적용하는 것은 전혀 다른 문제다. 프로덕션에서는 모델 성능뿐 아니라 응답 속도, 비용, 안정성, 품질 검증, 장애 대응, 사용자 경험까지 함께 고려해야 한다.

Amazon Nova는 AWS에서 제공하는 Foundation Model 계열로 이해했다. 이 세션에서는 Nova 2를 실제 서비스 요구사항에 맞게 검토하고 적용하는 과정이 핵심이었다.

서비스 요구사항
      ↓
모델 후보 검토
      ↓
Nova 2 적용
      ↓
품질 / 비용 / latency 검증
      ↓
프로덕션 반영

프로덕션 적용에서 중요해 보였던 포인트는 다음과 같았다.

• 모델 응답 품질 검증
• latency와 timeout 관리
• 호출 비용 관리
• fallback 전략
• 프롬프트와 입력 데이터 관리
• 사용자에게 노출되는 결과의 안정성
• 운영 모니터링과 로그 분석

특히 AI 기능은 일반적인 API 기능보다 결과가 비결정적일 수 있다. 같은 입력에도 모델 설정이나 컨텍스트에 따라 응답이 달라질 수 있기 때문에, 운영 환경에서는 품질 기준과 검증 체계가 중요해 보였다.

개인적으로는 이 세션이 “AI를 적용한다”는 말을 현실적으로 보게 해줬다. 모델을 호출하는 코드를 작성하는 것보다, 그 모델이 실제 사용자 경험을 해치지 않도록 검증하고 운영하는 과정이 훨씬 중요할 수 있다.

또한 우아한형제들처럼 사용자가 많은 서비스에서는 작은 품질 저하나 비용 증가도 크게 체감될 수 있다. 그래서 프로덕션 적용은 기술 검토뿐 아니라 비즈니스 영향, 운영 비용, 장애 대응까지 함께 보는 작업이라는 생각이 들었다.

결국 생성형 AI를 서비스에 붙이는 핵심은 좋은 모델을 고르는 것에서 끝나지 않는다. 서비스 맥락에 맞는 품질 기준을 세우고, 안정적으로 운영 가능한 구조를 만드는 것이 더 중요하다고 느꼈다.

부스 / 체험

• 인상 깊었던 부스:
• 체험해본 내용:
• 기억에 남은 점:

개인적으로 느낀 점

이번 AWS Summit을 다녀오면서 가장 크게 느낀 것은, 클라우드와 AI가 점점 더 개발자의 기본 도구가 되고 있다는 점이다.

예전에는 인프라를 직접 구성하고 운영하는 일이 별도의 영역처럼 느껴졌다면, 이제는 애플리케이션을 만드는 과정 안에 자연스럽게 포함되는 것 같다. Kubernetes, DevOps, MSA를 공부하면서 느꼈던 운영의 복잡성이 AWS의 여러 서비스와 AI 도구를 통해 어떻게 추상화되고 있는지도 생각해보게 되었다.

물론 모든 것을 AWS 서비스로 해결할 수 있는 것은 아니다. 하지만 현재 산업이 어떤 방향으로 움직이고 있는지 보기에는 충분히 의미 있는 행사였다.

Summit 이후 관심이 생긴 것

이번 Summit을 통해 개인적으로 더 관심이 생긴 것은 Kiro와 Amazon Bedrock이다.

Kiro는 AI를 활용한 개발 경험이 앞으로 어떻게 바뀔 수 있는지 생각하게 만든 도구였다. 단순히 코드를 자동완성하는 수준을 넘어, 요구사항을 정리하고 설계와 구현 흐름을 함께 다루는 방향으로 개발 도구가 발전하고 있다는 느낌을 받았다.

Amazon Bedrock은 여러 세션에서 반복적으로 등장했다. GraphRAG, Agentic AI, 예지정비, 멀티 에이전트 시스템처럼 생성형 AI를 실제 업무에 붙이는 사례에서 Bedrock이 기반 역할을 하고 있었다. 모델을 직접 운영하지 않고도 다양한 Foundation Model을 활용하고, Agent나 Knowledge Base 같은 기능과 연결할 수 있다는 점이 흥미로웠다.

이번 글에서는 내가 들은 세션을 중심으로 인상 깊었던 점을 정리했기 때문에, 각 세션의 자세한 내용은 AWS에서 제공하는 온디맨드 자료를 참고하면 좋을 것 같다.

정리

AWS Summit Seoul 2026은 클라우드, AI, 개발자 경험, 운영 자동화가 어떻게 연결되고 있는지 볼 수 있는 행사였다.

개인적으로는 르네상스 개발자, 생성형 AI, AI-Ready Data, Agentic AI, AIOps, 클라우드 운영 자동화라는 키워드가 가장 기억에 남았다. KB 국민은행의 임베디드 금융, 쿠팡의 Redshift 멀티 클러스터, 미래에셋증권의 GraphRAG, Agentic AI 기반 예지정비, 서버리스 멀티 에이전트 시스템, 대규모 API Gateway 마이그레이션, 요기요의 AIOps, 넥슨의 Agentic Ops, 삼성 어카운트의 Agentic AIOps, EKS 기반 인퍼런스 최적화, EKS 멀티태넌시와 Sidecar-less 네트워킹, 우아한형제들의 Nova 2 프로덕션 적용 사례를 보면서 결국 중요한 것은 데이터를 잘 다루고, 안정적으로 운영하며, 필요한 곳에 AI를 연결하는 역량이라는 생각이 들었다.

앞으로 Kubernetes와 DevOps를 공부하면서 AWS의 관리형 서비스와 AI 도구가 실제 운영 환경에서 어떤 식으로 연결되는지도 함께 살펴보고, Kiro와 Bedrock도 따로 사용해보며 정리해보고 싶다.