AWS Summit Seoul 2026 후기

TaekJun Jung·2026년 5월 25일

aws summit

AWS

목록 보기

2/2

이번에 5월 20~21일에 열린 AWS Summit Seoul 2026에 다녀왔습니다!!
다녀온 후기를 작성하려고 합니다.

AWS Summit Seoul

AWS Summit은 Amazon Web Services가 전 세계 주요 도시에서 개최하는 무료 클라우드 컨퍼런스입니다.

개발자, 아키텍트, IT 관리자, 스타트업 등 다양한 직군이 참여하고, AWS의 최신 서비스 발표와 실제 기업들의 사례를 세션 형태로 공유하는 큰 행사입니다.

주요 구성으로는
1. 키노트(신규 서비스/방향성 발표)
2. 기술 세션(실전 사례 공유)
3. 핸즈온 랩(직접 실습)
4. 부스 전시(AWS 파트너사들)
등이 있습니다.

한국 서밋은 매년 서울에서 열리고, 수만 명이 참가하는 국내 최대 규모 클라우드 행사 중 하나이기 때문에 정말 큰 기대를 안고 다녀왔습니다.

참가비가 무료라 관심 있으면 누구나 신청할 수 있습니다!!

부스 전시

먼저 코엑스 전체를 빌려서 하는 행사이기 때문에 사람이 너무나도 많았습니다..

들어가서 개인 카드를 주셨습니다.
목에 걸고 다녔는데 세션에 참여하거나 부스에 참여할 때마다 카드를 태그하시기 때문에 무조건 들고 다녀야 했습니다.

부스 운영존에 먼저 들어갔는데 일단 크기가 너무 컸고, 사람들이 너무 많아서 놀랬습니다.
그리고 바로 앞에 노션이 보였습니다!!!
평소에 사용하는 툴이나 익숙한 여러 기업들이 참여한 것을 보고 너무나도 신기했습니다.

각 부스마다 설문조사를 참여하면 여러 굿즈들을 주셨습니다.

AMD에서는 에코백?이랑 스티커를 받았어요.

메가존 클라우드에서 주신 양산도 정말 잘 사용하고 있습니당

그리고 제가 진짜 좋아하는 키로 부스도 있어서 구경했어요.
너무 귀엽습니다.
키로 재킷도 추첨으로 줬다고 들었는데, 행사에 좀 늦게 참여해서 재킷은 이미 다 나가고 없었습니다...

그리고 키로 키링이나 인형도 제발 많이 만들어줬으면 좋겠어요.,

그래도 스티커는 받아서 기분이 좋습니다.

그리고 부스를 돌면서 흥미로운 기술도 설명 들었습니다.
위 사진은 Upstage 회사의 부스입니다.
최근 LLM을 사용할 때에 금융권 같은 경우에 개인정보와 같이 민감한 정보를 LLM에 넣어 분석시키면 보안적으로 큰 이슈가 있죠.

그래서 제안하는 서비스인데,

① 토큰화 (Tokenization / PII 마스킹)
실제 개인정보(이름, 대출금액, 주민번호 등)를 LLM에 넣기 전에 [PERSON_1], [AMOUNT_1] 같은 토큰(key)으로 치환하고, 실제 값(value)은 사내 DB(여기선 DynamoDB)에 암호화해서 보관을 합니다.

② LLM 처리
개인정보가 빠진 상태의 문서를 LLM이 분석합니다.
외부 API를 쓰더라도 실제 PII가 나가지 않으니 개인정보보호법 문제가 없습니다.

③ 역치환
LLM이 생성한 결과물의 토큰을 다시 DynamoDB에서 꺼낸 실제 값으로 교체해서 최종 사용자에게 보여줍니다.

이러한 흐름으로 진행이 되는데 흥미로웠던 점은
지금 생각해보면 그리 어려운 방식이 아닌데 왜 이런 생각을 못했을까? 라는 생각이 들었습니다.
금융권에서 AI를 도입할 때 현실적인 해법 중 하나인 것 같습니다.
기발한 것 같아요. 설명을 들으면서 재밌었습니다.

위 사진은 WhaTap이라는 클라우드 기반 모니터링 SaaS 서비스입니다.

낭만 인프라 팀 활동을 하면서 Zabbix, Grafana, Prometheus 같이 오픈소스 모니터링 도구만 사용했었는데, 이런 관리해주는 모니터링 서비스를 보니까 신기했습니다.

찾아보니 간단하게 에이전트만 설치하면 되고, 사용량 기반 구독료라고 합니다.
또한, 사진을 보니까 LLM 모니터링까지 지원을 해주는 것 같습니다.

LLM API 요청 수, 토큰 사용량, 응답 TTFT(첫 토큰까지 걸리는 시간), 모델별 성능 비교 같은 것들이 다 대시보드 하나에 나오고 있어요.

항목	Zabbix / Grafana	WhaTap
형태	오픈소스, 직접 설치/운영	SaaS, 에이전트만 설치
초기 셋업	복잡함 (직접 구성)	빠름 (몇 분 내 연동)
대시보드	직접 만들어야 함	기본 제공
비용	서버 비용만	사용량 기반 구독료
유지보수	직접 해야 함	와탭이 해줌

위 사진은 카카오페이 손해보험 부스인데 AI 기반 해외 의료비 청구 심사 아키텍처를 보여주고 있습니다.

해외여행 중 병원을 갔을 때 보험금 청구하는 과정, 원래는 담당자가 서류 하나하나 검토하는 복잡한 수작업이었는데 이걸 AI로 자동화한 것입니다.

해외 의료비 청구서류가 들어오면

1. 문서 구조화 Agent — Amazon Textract로 OCR 처리 후 문서 유형 분류, 텍스트 추출 및 한국어 번역, 데이터 구조화

2. 청구서류 통합 Agent — 서류 유형별 우선순위 적용, 청구 통합 정보 생성

3. 그 다음 4개 Agent가 병렬로 동시에 심사

청구 정합성 검증 (진단코드 매핑, 필수 서류 확인)
의료기관 진위 검증 (유의기관 DB 검색, 국가 인증 의료기관 탐색)
손해액 산정 (손해액 중복 서류 탐지, 부당금여·결제금액 검증)
처방약 분석 (처방약 목록 추출, 용도 분석, 진단 추론)

4. 최종 청구심사 결과 리포트 생성

부스를 돌면서 체감한게, 올해 Summit의 키워드는 단연 AI였다는 것입니다.

Upstage의 금융 문서 AI, 페이 손해보험의 의료비 청구 자동화까지, AI가 이제는 실제 비즈니스 문제를 푸는 도구로 자리잡았다는 걸 체감했습니다.

기술 세션

이어서 세션 발표도 들었습니다.

홀에 들어오자마자 정말 놀랐습니다.. 사진을 보면 세 가지의 다른 세션을 한 장소에서 나눠서 진행합니다.
각 자리에 있는 헤드셋의 채널을 변경해서 실시간으로 발표하는 세션을 들을 수 있었습니다.

헤드셋으로 듣기때문에 수 많은 사람이 있음에도 조용했고 진짜 뭔가 사이버펑크스러운? 미래세계 같이 느껴졌어요.

아이디어가 정말 참신했고 와 이게 진짜 대기업이 진행하는 행사구나.. 라고 실감을 다시 한번 하게 됐습니다.

Amazon's AI Strategy

첫 번째로 들은 세션은 Amazon's AI Strategy입니다.

단순한 서비스 소개가 아니라 Amazon이라는 회사가 AI라는 변곡점을 어떻게 읽고 있는가에 대한 이야기였습니다.

Amazon은 AI라는 변곡점에 Big Bet을 단행했습니다.
슬라이드에는 거대한 변곡점을 발견하면 과감하게 베팅하라고 쓰여있습니다.

슬라이드에 제시된 Amazon의 AI 베팅 근거들은 다음과 같았습니다.

AI는 역사상 가장 빠르게 채택된 기술 — 2개월 만에 1억 명 돌파
AWS AI 매출 급성장 — 2026년 Q1 기준 런레이트 150억 달러 이상
AWS 성장 여력 충분 — 2025년 3.9GW, 2027년 말까지 총 전력 용량 2배 확대
자체 칩 사업 폭발적 성장 — Trainium3가 2026년 초 출하 시작
고객 약정 기반 투자 — 2026년 약 2,000억 달러 규모 설비투자(capex) 계획

숫자만 봐도 Amazon이 AI를 얼마나 진지하게 받아들이고 있는지 느껴졌습니다.

세션의 핵심 메시지 중 하나는 AI 패러다임의 전환이었습니다.

지금까지의 생성형 AI가 "질문하면 답변해주는" 수동적 도구였다면, 에이전틱 AI는 "목표를 주면 스스로 계획하고 실행하는" 능동적 에이전트입니다.

실제로 이날 부스에서도 Multi-Agent 기반의 의료비 청구 자동화(CLAIMY), 금융 문서 AI 처리(Upstage) 등 에이전틱 AI의 실제 적용 사례들이 즐비했습니다.

후기

Amazon은 AI를 유행처럼 따라가는 게 아니라, 회사의 다음 10년을 AI 위에 올려놓겠다는 결정을 이미 내린 것 같다는 생각을 했습니다.

에이전틱 AI로의 전환이 이제 막 시작된 지금, 개발자로서도 단순히 API를 붙이는 수준을 넘어 AI를 어떻게 설계하고 운영할 것인가를 더 깊이 고민해야 할 시점인 것 같아요.

또, 세션을 들을 때는 미리 가있어야 한다는 생각을 했어요...
사람이 너무 많아서 맨 뒤에 서서 들었습니다 ㅠ

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

당근의 엔지니어분들이 직접 나와 AWS CloudHSM과 KMS 기반의 하이브리드 아키텍처를 설계하고 운영하면서 겪은 경험을 공유하는 자리였습니다.
단순한 개념 소개가 아닌, 실제 서비스에서 맞닥뜨린 문제와 그것을 해결하는 과정이 담겨 있어 밀도가 높은 세션이었어요.

기본 개념 정리

세션 내용을 이해하려면 먼저 핵심 기술 개념을 짚어봐야 할 것 같아요.

AWS CloudHSM

FIPS 140-2/140-3 Level 3 인증을 받은 하드웨어에서 고객 전용 단일 테넌트 HSM을 제공하는 서비스입니다.
가장 큰 특징은 "키는 고객만 제어한다" 는 점이에요. AWS조차 키에 접근할 수 없습니다.

주요 기능은

데이터 암호화/복호화
디지털 서명 및 검증
키 생성·저장·가져오기/내보내기
SSL/TLS 오프로드 처리
인증 기관(CA) 프라이빗 키 보호

등이 있습니다.

클러스터 아키텍처는 VPC 안에 AZ-a, AZ-b, AZ-c 이렇게 멀티 AZ로 HSM 인스턴스를 분산 배치합니다. (고가용성을 위한 구조)
연동 방식은 두 가지인데, KMS Custom Key Store를 통해 AWS 서비스와 간접 연동하거나 EC2 등 서버에서 직접 연동할 수 있어요.

모니터링은 AWS CloudTrail, Amazon CloudWatch, Client SDK 로그 세 가지로 감사 추적과 상태 모니터링을 해요.

한 줄 요약하면 AWS가 하드웨어만 제공하고, 키 관리는 완전히 내가 하는 전용 암호화 하드웨어입니다.

AWS KMS

AWS에서 제공하는 완전 관리형 키 관리 서비스입니다.
암호화 키를 직접 서버에 저장하거나 관리할 필요 없이, AWS API 호출만으로 키를 다룰 수 있어요.

"KMS에서 생성한 키는 FIPS 140-3 Security Level 3 인증을 받은 HSM에 의해 보호되며, 암호화되지 않은 상태로 KMS 외부로 유출되지 않는다" 는 게 가장 중요한 보안 원칙이에요.

주요 기능은

데이터 암호화/복호화
디지털 서명 및 검증
데이터 키 생성 및 내보내기
메시지 인증 코드(MAC) 생성 및 검증

등이 있습니다.

연동 서비스가 풍부한 게 KMS의 큰 장점인데, Amazon S3, DynamoDB, RDS, OpenSearch Service 등 주요 AWS 서비스와 네이티브로 통합돼요.

즉, S3 버킷에 파일을 올릴 때 KMS 키로 자동 암호화하는 식으로 별도 코드 없이 바로 쓸 수 있습니다.
모니터링은 CloudTrail로 키 사용 이력 감사, CloudWatch로 이상 탐지를 해요.

한 줄 요약하면 AWS가 키 인프라를 모두 관리해주는, 가져다 쓰기 쉬운 암호화 키 관리 서비스 입니다.

AWS KMS vs CloudHSM 한눈에 비교

항목	AWS KMS	AWS CloudHSM
HSM 유형	Multi-tenant	Single-tenant
인터페이스	AWS API / SDK	PKCS#11, JCE, OpenSSL
접근제어	IAM Policy + Key Policy	HSM User/Key 레벨
키 관리	AWS 관리 (자동 Rotation)	고객 직접 관리
성능	기본 1,000 RPS (증설 가능)	HSM 인스턴스 수에 비례
비용 모델	요청당 과금	시간당 과금
네트워크 위치	AWS Managed VPC	고객 VPC 내
운영 복잡도	낮음	높음

핵심 차이: KMS는 요청이 적을 때 유리하고, CloudHSM은 대규모 트래픽에서 시간 고정 비용이 더 유리해집니다.

당근이 마주한 문제: 기존 아키텍처의 한계

당근의 기존 구성은 EKS 클러스터 내 인증 서버가 AWS Secrets Manager에 저장된 Private Key를 가져와 JWT 서명을 수행하는 구조였습니다.
MAU 2,100만 규모로 성장하면서 이 구조의 취약점이 드러났어요.

Secrets Manager 접근제어 미흡 — 권한이 있으면 누구든 Private Key 원본을 추출할 수 있음.
의도치 않은 토큰 발행 가능성 — 모바일 앱 등 허가되지 않은 주체가 인증 요청을 직접 수행할 수 있는 구조였음.
키가 메모리 위에 노출 — 서버 프로세스 내에서 키를 직접 로드해 사용하므로, 런타임 수준의 공격에 취약했음.

결론: "더 촘촘한 접근제어 기법이 필요하다"

당근 × AWS 협업 과정

단순히 서비스를 붙이는 게 아니라 5단계 구조화된 프로세스를 밟았습니다.

01 진단 → 02 설계 → 03 검증(POC) → 04 안정화 → 05 배포

진단: 기존 구성 진단, 개선 포인트 식별, 서비스 요구사항 정리
설계: CloudHSM + KMS 솔루션 제안, 아키텍처 구성도 및 실행 가능한 대안 논의
검증: 필요한 Metric 점검, Scale 성능 한계 테스트, Service Quota 확인 및 증설 요청
안정화: POC 과정 중 발생한 이슈 해결, Failover 동작 검증
배포: Production 환경 배포 및 최종 동작 확인, 사후 모니터링

최종 아키텍처: CloudHSM Architecture Overview

세션의 핵심인 최종 아키텍처는 다음과 같습니다.

[EKS Cluster - Private Subnet]
  ├── Allowed Servers → Istio (Allow) → 서명 애플리케이션
  ├── Other Servers  → Istio (Deny)  ✗
  └── 서명 애플리케이션
        ├── HSM 접근 NodeGroup → HSM 관리 인스턴스 → AWS CloudHSM
        └── Certbot CronJob → AWS Secrets Manager (인증서 갱신용)

설계 포인트:

CloudHSM은 고객 VPC의 Private Subnet에 위치 — AWS Managed VPC가 아닌 완전 격리
EKS의 Istio 서비스 메시로 서명 애플리케이션에 대한 접근을 Allowed Servers만 허용, 나머지는 Deny
HSM 접근 전용 NodeGroup을 별도로 분리해 보안 경계를 물리적으로 강화
Certbot CronJob은 인증서 갱신을 자동화하여 Secrets Manager와 연계

CloudHSM 키 권한 설계: Access Control

단순히 CloudHSM을 도입하는 것보다 키 레벨의 접근제어 설계가 더 중요한 부분이었습니다.

세 가지 핵심 접근제어 원칙:

Disable Extraction — extractable=false로 Private Key 임의 추출 원천 차단
Prevent Destruction — destroyable=false로 키 임의 삭제 방지
Separate Read User with Key Owner — Token Issuer 계정에 키를 공유하여 Signing만 허용, 설정 변경은 원천 차단

비용 최적화: KMS vs CloudHSM

슬라이드에서 인상적으로 제시된 비용 비교 그래프가 있었습니다.

당근의 트래픽 규모에서 KMS를 사용하면 비용이 압도적으로 높은 반면, CloudHSM은 시간당 고정 비용이기 때문에 대규모 트래픽에서 CloudHSM이 훨씬 경제적이라는 것을 명확하게 보여줬어요.

KMS: $0.15 / 10,000 req → 수백만 서명 요청 시 비용 폭증
CloudHSM: $1.54/hr 고정 → 트래픽이 많을수록 단가 하락

MAU 2,100만 수준에서는 CloudHSM이 비용 면에서 압도적으로 유리합니다.

Lessons Learned: 예상치 못한 함정들

실전 운영에서 마주친 두 가지 인상적인 트러블슈팅이 소개됐습니다.

1. Istio와 CloudHSM IP 식별 문제

Istio 서비스 메시 환경에서 PKCS#11 Client 초기화 시 커넥션 에러가 발생했습니다.
원인은 Istio가 CloudHSM의 IP를 식별하지 못해 Egress Gateway 라우팅이 제대로 동작하지 않은 것.

해결책은 CloudHSM IP를 도메인으로 병행 등록하여 Istio가 식별할 수 있도록 처리하는 것이었습니다.

2. 도메인으로 HSM 목록 관리 시도와 그 실패

CloudHSM 클러스터의 ENI IP를 Route 53 도메인으로 등록하고, Token Issuer가 도메인으로 CloudHSM에 접근하는 구조를 시도했습니다.

그러나 도메인 연결 시 세션이 불안정해지는 문제가 발생했고, 결국 권장 방식은 configure-pkcs11로 cloudhsm:DescribeCluster를 호출하여 IP 목록을 직접 확보하는 것임을 확인했습니다.

이 두 사례는 "공식 문서만으로는 알 수 없는 실전 노하우"라는 점에서 세션의 가장 값진 부분이었어요.

이 세션에서 배울 수 있는 것들

1. 보안 아키텍처는 "키를 안 보이게" 하는 것이 핵심이다

Secrets Manager에 키를 저장하는 것과 CloudHSM에서 키가 하드웨어 밖으로 절대 나오지 않도록 설계하는 것은 근본적으로 다른 수준의 보안입니다.
extractable=false 한 줄이 얼마나 큰 의미를 갖는지 이 세션이 명확하게 보여줬습니다.

2. 비용 최적화는 트래픽 규모를 함께 고려해야 한다

KMS가 더 편리하고 운영 비용도 낮지만, 대규모 서명 요청이 발생하는 서비스에서는 CloudHSM이 훨씬 경제적이었어요.
"어떤 서비스가 더 좋다"가 아니라 트래픽 패턴과 비용 구조를 함께 분석해 선택해야 할 것 같습니다.

3. 접근제어는 레이어드(Layered) 전략으로

당근의 아키텍처는 세 개의 방어선을 가집니다.
①Istio로 네트워크 레벨 접근 차단 →
②HSM User 권한으로 Signing만 허용 →
③extractable=false로 키 추출 원천 차단.

보안은 단일 방어선이 아닌 중첩된 레이어로 설계해야 합니다.

4. POC를 체계적으로 돌려야 Production 사고가 없다

당근 × AWS 협업 과정에서 인상적이었던 것은 "진단 → 설계 → POC → 안정화 → 배포"라는 명확한 5단계를 밟은 점입니다.
Failover 동작 검증과 Service Quota 확인을 POC 단계에서 미리 수행한 덕에 Production 배포가 안정적으로 이루어질 수 있었습니다.

후기

이 세션은 단순한 AWS 서비스 소개가 아니라 실제 서비스 규모에서 보안과 비용이라는 두 마리 토끼를 잡는 과정을 보여줬다는 점에서 인상깊었습니다.

특히 Lessons Learned 섹션에서 공유된 Istio-CloudHSM 연동 이슈와 도메인 방식의 한계는 공식 문서 어디에도 없는 실전 지식이었죠.

MAU 수백만 이상의 서비스를 운영하거나, 서명키 관리의 보안 수준을 높이려는 엔지니어라면 이 아키텍처 패턴을 참고할 때 도움이 많이 될 것 같습니다.

마치며

이런 큰 행사에 참여하는 것은 처음이라 많은 기대를 안고 갔는데, 기대 이상으로 재밌고 알찬 하루였습니다.

당근 세션에서 가장 많이 느낀 건, 직접 연동하면서 겪은 트러블슈팅이나, 도메인 방식이 안 된다는 걸 직접 시도해보고 알게 된 것들. 그 경험이 쌓여서 지금의 아키텍처가 나온 거라는 게 느껴졌어요.

부스를 돌아보면서는 AI가 이제 실험 단계가 아니라 실제 비즈니스 문제를 푸는 도구로 자리잡았다는 걸 체감했습니다.
많은 기업에서 전부 실제 서비스에서 돌아가고 있는 것들이었어요.

또한, 그라파나, 자빅스만 쓰다가 와탭 같은 서비스를 보니 내가 당연하게 여기던 것들도 더 나은 방법이 있을 수 있겠다는 생각도 들었습니다.

기술은 계속 변하고, 계속 보고 배워야겠다는 자극을 받은 하루였어요.

당근 세션말고도 여러 세션을 더 들었지만, 너무 길어질 것 같아 끊었어요.

내년에도 꼭 오고 싶다~~
저도 언젠가 저런 큰 행사에서 발표를 할 수 있는 날이 오면 좋겠어요.

아 그리고 AWSKRUG 부스에서 응모 3등 마우스 당첨됐어요!!!
AWSKRUG 최고!!

지금까지 긴 글 읽어주셔서 감사합니다.
문제 되는 부분이 있다면 삭제 조치 하겠습니다.

정택준
Email: taekjunnnn@gmail.com
Team: https://nangman.cloud/

TaekJun Jung

\\^o^//

이전 포스트