• AWS Summit Seoul 2026
  • 현장 이야기
    • 스탬프 미션과 가챠
    • 설문 참여 굿즈
  • 부스 탐방
  • AWS 피지컬 AI로 실현하는 기업의 차세대 혁신 전략
  • 당근의 CloudHSM/KMS 기반 대규모 서명키 관리 시스템 구축기
    • 한 줄 요약
    • 당근 서비스와 서명키 과제 (최용환, SRE)
      • 기존 아키텍처의 한계
      • 새 시스템에서 고려한 부분
      • KMS vs CloudHSM 비교
    • CloudHSM 선택과 도입기
      • 접근 제어 흐름
      • HSM 사용자 역할
      • Access Controller
    • Lessons Learned: Forward Proxy
    • 서명 시스템 구현과 Failover 설계 (조승환, Identity Service Engineer)
      • 서명 Failover
      • 서명 알고리즘 전환
    • 트러블슈팅
      • Scale-out 시 세션 고정 문제
      • Scale-in 중 요청 실패
      • MaxSessions 튜닝
      • 로깅 체계
    • 서명키 안전하게 전환하기 (Key Rotation)
    • Wrap-Up: 하이브리드 전략
    • Key Takeaways
  • 새벽 3시, 18만 개의 모델이 대신 판단한다 : 넥슨의 에이전틱 Ops
    • Statistical Backbone
    • 시계열 자체의 급격한 변화 탐지
    • 전방위적 상황 분석을 위한 대규모 이상 탐지 백본
    • ContextLake Flow
    • Agents' Context Flow
    • THE ANOMALY TIMES
    • 성과 지표
    • Our History
  • 요기요의 AIOps: SRE 운영의 콘솔 탈출기
    • 회사 소개
    • 기존 운영의 현실
    • 우리가 원했던 것
    • AIOps 아키텍처
    • 시나리오 1: AI Assistant (대화형 인프라 진단)
    • 시나리오 2: Resource Optimizing
    • 시나리오 3: Intelligence Report
    • AIOps 도입 후 효과
    • 도입하며 배운 것
    • 앞으로의 계획
  • 참고

AWS Summit Seoul 2026

• 기간: 2026-05-20 (수) ~ 2026-05-21 (목)
• 장소: COEX Convention Center, Seoul
• 구성: Industry Day (5/20) + AI Day (5/21)
• 공식: aws.amazon.com/ko/events/summits/seoul

올해 AWS Summit Seoul은 COEX에서 이틀에 걸쳐 열렸다. 첫째 날은 산업별로 묶인 Industry Day, 둘째 날은 AI에 초점을 맞춘 AI Day로 구성됐다. 100개 이상의 세션, 70여 개의 고객 사례, 워크숍, 라이트닝 토크가 한꺼번에 돌아가서 동선을 짜는 것부터 작은 미션이었다.

현장 이야기

스탬프 미션과 가챠

행사장 곳곳의 부스에서 스탬프를 받을 수 있었다. 총 16개를 모두 모으면 가챠 머신을 한 번 돌릴 수 있는 이벤트였고, 자연스럽게 부스를 골고루 돌아보게 만드는 장치였다.

설문 참여 굿즈

세션이나 부스에서 설문에 응하면 티셔츠를 받을 수 있었다.

부스 탐방

파트너 기업 부스에서는 자체 솔루션 데모와 굿즈 이벤트가 함께 진행됐다. 둘러본 부스는 다음과 같다.

여기서부터는 직접 들은 세션을 정리한다.

AWS 피지컬 AI로 실현하는 기업의 차세대 혁신 전략

• Publisher: TBD

(정리 예정)

당근의 CloudHSM/KMS 기반 대규모 서명키 관리 시스템 구축기

• Publisher: 최용환 (Yany, SRE), 조승환 (Josh.cho, Identity Service Engineer)

한 줄 요약

• KMS vs CloudHSM
• 대부분의 워크로드는 KMS, 규제가 있고 직접 구축할 수 있다면 CloudHSM

당근 서비스와 서명키 과제 (최용환, SRE)

기존 아키텍처의 한계

• 촘촘한 접근 제어 기법이 필요했다
• 의도치 않은 토큰 서명이 발생할 수 있는 구조였다

새 시스템에서 고려한 부분

• Private 키 유출이 없어야 한다
• 서명 트래픽을 감당해야 한다
• SPOF 없이 대안이 존재해야 한다
• 서명 트래픽에 촘촘한 접근 제어가 가능해야 한다
• 담당자 없이도 임의로 안전하게 서명할 수 있어야 한다

KMS vs CloudHSM 비교

CloudHSM 선택과 도입기

접근 제어 흐름

• HSM 담당자: HSM 관리 인스턴스에서 CLI로 HSM 접근
• 개발자: 접근 불가
• Token Issuer: Secrets Manager의 정보로 HSM 접근

HSM 사용자 역할

Access Controller

• Kyverno로 정책 적용
• CloudTrail로 감사

Lessons Learned: Forward Proxy

• PKCS#11 Client 초기화 시 커넥션 에러 발생
• Istio에서 CloudHSM IP 식별을 위해 도메인을 병행 사용해야 함
• 처음에는 Service Discovery로 관리하려 했지만 세션이 불안정해 도메인 접근 포기
• 지금은 configure-pkcs11 방식으로 운영

서명 시스템 구현과 Failover 설계 (조승환, Identity Service Engineer)

PKCS#11은 C 기반으로 Shared Object 바이너리를 호출하는 구조라 FFI가 필요하다.

서명 Failover

• Active / Standby 구조로 설계
• 서명 실패 시 Fallback signer 사용
• 실제 사례: HSM 통신에 Latency Spike 발생 시 Failover로 Secondary(KMS) 서명 전환

flowchart LR
    REQ["서명 요청"]
    REQ --> ACT["Primary: CloudHSM"]
    ACT -- "실패 / 지연" --> FB["Fallback: KMS"]
    ACT -- "성공" --> OUT["서명 결과"]
    FB --> OUT

서명 알고리즘 전환

• 기존: RS256 (소인수분해 기반)
• 신규: ES256 (타원곡선 이산대수)

트러블슈팅

Scale-out 시 세션 고정 문제

• HSM을 추가하면 애플리케이션에서 세션 재연결이 필요
• 현재는 애플리케이션 재시작으로 대응

Scale-in 중 요청 실패

• HSM 인스턴스 종료 시점에 처리 중이던 요청 실패
• Fallback으로 사용자 관점의 에러는 없도록 처리

MaxSessions 튜닝

• 실패보다 대기가 낫다
• MaxSessions를 너무 높게 잡으면 Flow control이 없어 Latency 급등
• MaxSessions를 낮게 잡고 poolWaitTimeout을 함께 설정해서 Latency 소폭 증가만으로 안정화

로깅 체계

• PKCS#11은 자체 로그 트래킹이 불가
• .so 파일이 남기는 바이너리 로그 파일을 실시간 tail하는 LogTail 구현
• Error Level은 Sentry, Metric은 Datadog로 송출

서명키 안전하게 전환하기 (Key Rotation)

flowchart LR
    A["1. 새 키 생성"] --> B["2. Weight 이동"]
    B --> C["3. 기존 서명 중단"]
    C --> D["4. 토큰 만료 대기"]
    D --> E["5. 공개키 제거"]

1. 새 키 생성
2. 트래픽 Weight 이동
3. 기존 키로의 서명 중단
4. 기존 키로 서명된 토큰 만료 대기
5. 공개키 제거

Wrap-Up: 하이브리드 전략

저트래픽 환경은 KMS를 Primary로, 고트래픽 환경은 CloudHSM을 Primary로 두는 Active-StandBy 조합으로 보안, 성능, 안정성을 모두 달성한다.

Key Takeaways

• Private Key의 안전한 격리: HSM/KMS 안에서만 서명, 키는 절대 밖으로 나오지 않는 구조
• 장애에 대비한 안정성 확보: Failover 구조 설계를 통한 단일 벤더 SPOF 제거
• 더욱 안전하게 당근 서비스를 제공: 하루 수천만 건의 인증 토큰을 더 안전한 기반 위에서 발급

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

24시간 가동되는 게임 운영에서 새벽 3시에 누가 깨어 이상을 감지할 것인가에 대한 넥슨의 답. 사람 대신 18만 개의 모델이 시계열 신호를 동시에 살피고, 의미를 모아 결국 사람에게 "기사" 형태로 전달하는 에이전틱 Ops 시스템이다.

Statistical Backbone

통계적 모델링이 의미 있는 결과로 이어지려면, 먼저 기존 장애 이력으로부터 시스템 지표가 어떻게 반응했는지를 살펴야 한다. 이 작업이 빠지면 정교한 모델을 얹어도 표면만 긁는다.

시계열 자체의 급격한 변화 탐지

동시 접속자 같은 핵심 지표에서는 절대 임계치보다 시계열 자체의 급격한 변화가 더 결정적이다. 그리고 서버/서비스 사이의 이질성을 함께 본다.

전방위적 상황 분석을 위한 대규모 이상 탐지 백본

지금까지의 모든 얘기를 한 마디로 응축하면, "전방위적 상황 분석을 위한 대규모 이상 탐지 백본"이다. 18만 개 모델은 이 백본 위에서 동시에 돌아간다.

ContextLake Flow

숫자가 그저 한글로 번역되는 수준이 아니라, 의미론적으로 묶이고 분류되는 흐름이 필요했다. ContextLake는 Backend Layer → ContextLake → Harvesting 의 3단으로 실시간 의미를 흘려보낸다.

Agents' Context Flow

화성 탐사대의 식물학자 마크 와트니가 화성에서 조난당하는 상황에 비유하며, 에이전트들이 부분 정보로부터 어떻게 종합적 결론에 도달하는지를 설명했다. 각 에이전트의 추론 결과가 다층 의미(인수 / 서비스 / 비즈니스 등)로 합쳐진다.

THE ANOMALY TIMES

이상 탐지 결과는 단순한 경보가 아니라 신문(THE ANOMALY TIMES) 형식의 기사로 전달된다. 99% 이상의 동시 접속자가 감소한 큰 사건부터, 다양한 상황에서 놀라움을 주는 작은 케이스까지 같은 톤으로 정리된다.

성과 지표

발표 슬라이드에 표시된 수치는 다음과 같다 (자세한 정의는 공식 자료 공개 시 갱신).

• 탐지율 100%
• 운영자가 모르던 이상 추가 발견 +34%
• 오탐률 2.8%
• 1분 이내 탐지
• 평균 대응 시간 30분 단축
• 인시던트 채널 노이즈 1/3 감소

Our History

발표 후반의 로드맵 슬라이드를 그대로 옮긴 흐름이다.

• 2024 Q3: 주요 지표 기반 이상 감지 시작
• 2024 Q4: 복합 지표 고려
• 2025 Q1: 실시간 분석 서비스
• 2025 Q2: AIOPS v1 Launch
• 2026 Q2: AIOPS v2 Launch

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

• Publisher: 김예준 (외식한상상)

흩어진 콘솔과 대시보드 사이를 오가던 운영을 어떻게 에이전트 기반으로 정리했는지에 대한 사례.

회사 소개

• 서비스 라인업: 요기요 / 요기배달 / 요기패스 / 요미트 / 요편의점 / 무한적팁
• 배달앱 최초 멤버십 할인 구독 서비스
• 최대 40배 피크 트래픽을 감당하는 운영 환경
• 30+ 개 계정, 60+ 개 마이크로서비스

기존 운영의 현실

• 통합 모니터링 솔루션에서 관리되는 지표: APM, Infra, K8s, Log, Redis/RDS
• 그 바깥에서 추가로 봐야 하는 지표: ArgoCD, Grafana, Elasticsearch, CDN
• 30+ 개 계정마다 따로 콘솔에 들어가야 하는 정보
• 결과적으로 담당자의 경험에 크게 의존하게 되는 운영

우리가 원했던 것

또 하나의 대시보드가 아니라, 질문에 답이 바로 나오는 통합 모니터링 경험이 필요했다.

• 서비스 영향도 분석: 한 번의 요청으로 연관 서비스의 영향 순위 분석
• 리소스 최적화: Idle-Peak 격차를 분석해 절감 가능한 옵션 추천과 추적
• 이벤트 리포트 자동화: Datadog, Kubernetes, Amazon CloudWatch 등 여러 출처를 모아 정리

AIOps 아키텍처

• 사용자 요청은 ALB를 거쳐 Frontend/Backend (ECS)로 들어간다
• 핵심은 Amazon Bedrock 위에 올린 AgentCore. Network / Compute / Storage / Auditing / Security / Memory 자원을 다루는 MCP Tool Functions를 호출한다
• External Data Sources로 Datadog, Grafana, CloudWatch, K8s 등이 연결되고, AWS Services는 Compute / Networking / Storage / Security / Monitoring 카테고리로 묶여 있다

운영자가 자연어로 질문을 던지면 AgentCore가 외부 데이터를 직접 조회해 응답한다.

시나리오 1: AI Assistant (대화형 인프라 진단)

콘솔을 직접 열지 않고, 자연어 질의로 시스템 상태를 진단한다. SRE의 콘솔 탈출 시작점.

시나리오 2: Resource Optimizing

피크 대비 오버프로비저닝을 식별한다.

• 멀티 리소스 분석: EC2, RDS, ElastiCache 등 다양한 리소스 분석
• 액션 중심 추천: 유휴 자원 식별, Down-sizing, 패밀리 변경, 세대 교체, Graviton 전환 등
• 병목 시뮬레이션: 추천 적용 후의 변경을 사전 검증

시나리오 3: Intelligence Report

프로모션과 같은 이벤트 전 구간을 AI가 기록한다.

• Cluster Overview: 이벤트 전 준비가 충분했는지 (Prewarming, Pod, Node, RPS)
• 마이크로서비스 Overview: 피크 구간의 서비스별 영향 (RPS, Latency, Error Rate, 리소스 사용률)
• 영향도 큰 서비스 순으로 정렬: 지금 가장 먼저 봐야 할 서비스부터 우선순위로 노출

AIOps 도입 후 효과

• Right-Sizing 47%, 리소스 제거 23%, Valkey 전환 19%, 세대교체 11%
• Amazon ElastiCache 비용 55% 절감
• 작업 효율 10배 증대

도입하며 배운 것

• 통합은 에이전트를 나누는 것만으로는 해결되지 않는다
• AIOps의 가치는 자동 판단이 아니라 탐색 시간 단축에 있다
• 무작정 전체를 보게 만드는 것이 아니라, AI가 변화 큰 대상을 좁혀 주는 것이 핵심

앞으로의 계획

운영 → AI 분석 → 조치 제안 → 승인 → 운영의 사이클을 다음 단계로 본다. 즉, 승인 기반의 자동화(AWS가 조치를 제안하고 운영자가 승인하면 적용)가 그 시작점이다.

참고

• AWS Summit Seoul 2026 공식