올해도 코엑스에서 열린 AWS Summit Seoul 2026에 다녀왔습니다. 5월 20일과 21일 양일간 진행된 이번 행사에서 저는 고민 끝에 1일차 세션에 참석하기로 결정했습니다. 후기 작성이 조금 늦어졌지만, 현장에서 느꼈던 기술의 열기와 인사이트를 휘발되기 전에 기록해두려 합니다.
이번 서밋 방문의 핵심 목표는 명확했다. 클라우드 인프라와 보안의 최신 동향 파악,
그리고 현재 IT 업계를 관통하는 절대적인 화두인, AI 입니다.
올해 초 SCS-C03 자격증을 취득하면서 클라우드 보안 아키텍처에 대한 고민이 한층 깊어졌는데, 이번 행사에서 이 이론적인 지식들이 실제 엔터프라이즈 환경에서 어떻게 구현되고 있는지 직접 확인하고 싶었습니다. 인프라와 보안, 그리고 AI의 결합은 더 이상 트렌드가 아닌 생존 조건이라는 생각이 들었기 때문입니다.
따라서 이번 세션 계획은 이 세 가지 요소가 실무에서 어떻게 유기적으로 엮여 시너지를 내는지에 중점을 두고 짰습니다.
https://aws.amazon.com/ko/events/summits/
AWS Summit 개요
AWS Summit에서 끊임없이 혁신하고, 새로운 기술을 배우며 업계 동료들과 교류하세요.
aws.amazon.com
올해 AWS Summit Seoul 2026에서 중점적으로 다룬 4대 핵심 주제는 다음과 같습니다.
- AI (인공지능): 생성형 AI를 넘어, 스스로 계획하고 임무를 수행하는 에이전틱 AI(Agentic AI)의 실무 적용과 워크플로우 진화
- 마이그레이션 및 현대화: 단순한 서버 이전을 넘어, 컨테이너와 서버리스 중심의 클라우드 네이티브 아키텍처로 전환하는 방법론
- 개발자 셀프서비스: 개발자가 인프라 팀을 거치지 않고 가드레일 안에서 필요한 리소스를 직접 띄우는 플랫폼 엔지니어링과 운영 자동화
- 데이터 및 분석: 비즈니스 인사이트 창출과 제로 트러스트(Zero Trust) 보안 가시성 확보를 위한 대규모 데이터 파이프라인 및 실시간 분석 기술
사전 신청을 완료하면 이메일을 통해 입장용 QR 코드가 전송됩니다.
저는 올해도 학생 신분으로 방문하게 되었습니다. 해당 QR 코드로 현장에 도착해서 명찰을 발급 받으면 됩니다.
방문
행사장에 일찍 방문하면 선착순으로 런치 쿠폰을 제공한다고 합니다. (저는 늦어서 못받았지만 부럽,,)
코엑스에 도착하니 오전 10시가 채 되지 않은 이른 시간이었음에도, 이미 수많은 IT 업계 관계자분들로 현장의 열기가 뜨거웠습니다. 비록 시간 관계상 메인 기조연설은 직접 관람하지 못해 아쉬움이 남았습니다.
참고로 시간이 조금 늦더라도 입장은 언제든 자유롭게 가능합니다. 저는 점심시간에 맞춰 코엑스 근처에서 식사를 해결하려고 했지만, 워낙 참석자가 많다 보니 식당 어디를 가든 대기 줄이 길기 때문에 금쪽같은 행사 시간에 밥을 먹기 위해 체력을 소모하는 것보다는, 아예 점심을 든든히 드시고 여유롭게 오시거나 행사장과 조금 떨어진 곳에서 식사를 하고 방문하시는 것을 추천합니다.
코엑스는 두 번째 방문인데도 특유의 복잡한 구조 탓에 여전히 길이 헷갈리는 건 어쩔 수 없는 것 같습니다. 도착했을 때는 이미 오전 트랙 세션들이 한창 진행 중이었기 때문에,
무리해서 세션에 중간 입장하기보다는 먼저 Expo 부스부터 둘러보기로 동선을 조정했습니다. 작년과 마찬가지로 다양한 파트너사들의 최신 기술을 직접 눈으로 확인하고 체험해 보며, 부스 곳곳에서 제공하는 쏠쏠한 굿즈들을 모으는 재미도 기대가 되었습니다.
이번 엑스포 전시장에서는 70개 이상의 방대한 AWS 제품군 소개와 함께 수많은 기업들의 다채로운 기술 시연이 열리고 있었습니다. 그중에서도 제 시선을 가장 강렬하게 사로잡은 것은 단연 피지컬 AI 파트였습니다. 소프트웨어적인 AI 모델이 실제 기계나 전자 장비와 결합하여 유기적으로 움직이는 모습은 무척 흥미롭고 인상 깊었습니다.
이번 AWS Summit은 AI가 단순히 화면 속에서 텍스트를 생성하는 단계를 뛰어넘어, 로봇, 물류, 제조 등 우리의 현실 공간과 직접 상호작용하는 기술로 본격적인 진화를 이루었음을 선언하는 자리였다고 합니다.
나아가 한국을 이러한 피지컬 AI 기술 혁신의 글로벌 거점으로 육성하겠다는 거대한 비전까지 발표했다고 하니, 앞으로 클라우드와 하드웨어 생태계에 불어닥칠 변화가 더욱 기대됩니다.
Datadog
엑스포 전시장에 들어서서 가장 먼저 발걸음을 향한 곳은 Datadog 부스였습니다.
마침 부스 한켠의 대형 스크린 앞에서 Cloud Security를 주제로 한 미니 강연이 진행되고 있었습니다. 올해 초 클라우드 보안 환경을 깊이 있게 공부하며 가장 큰 과제로 느꼈던 것이 바로 방대한 리소스 내에서의 가시성 확보였기에, 저 역시 자연스럽게 발걸음을 멈추고 세션에 몰입하게 되었습니다.
시연 내용은 무척 흥미로웠습니다. 단순히 인프라의 상태를 모니터링하는 것을 넘어, 클라우드 환경 전반의 보안 설정 오류를 실시간으로 스캔하고 위협 로그를 직관적인 대시보드로 시각화해 주는 과정이 인상 깊었습니다. 개발과 운영, 그리고 DevSecOps 영역이 하나의 플랫폼 안에서 어떻게 유기적으로 맞물려 돌아가는지 실무적인 관점에서 명확한 힌트를 얻을 수 있는 유익한 시간이었습니다.
강연을 흥미롭게 다 듣고 난 후에는 부스 이벤트에 참여해 굿즈도 챙겼습니다. Datadog의 귀여운 강아지 로고가 촘촘하게 수놓아진 브랜드 시그니처 컬러의 양말을 받았습니다.
삼성전자
다음으로 참석한 강연은 삼성전자의 에이전틱 AI 전략 - 개발혁신과 AIOps 여정 세션이었습니다.
단순히 트렌드를 논하는 자리가 아니라, 국내 최대 기업인 삼성전자가 실제 삼성계정 운영에서 AI를 어떻게 활용하고 있고, 어떤 시행착오를 거쳤는지 생생하게 들을 수 있었던 최고의 세션이었습니다.
현장에서 공유된 핵심 내용을 요약해 공유해 드립니다.
AX의 본질적인 질문: "AI 도구도입 ≠ 개발 생산성"
많은 기업이 AI 도구를 도입하지만, 그것이 곧바로 개발 생산성의 향상으로 이어지지는 않는다는 점을 지적했습니다. 가장 뛰어난 LLM이라 할지라도 기업 내부의 깊숙한 암묵지의 장벽을 넘지 못하기 때문입니다.
- 히스토리 부제: 문서화되지 않은 고유의 비즈니스 로직
- 레거시의 얽힘: 수십 번 리팩토링되며 누적된 기술 부채
- 컨텍스트 한계: 단일 프롬프트로는 담아낼 수 없는 복잡한 시스템 간의 의존성
결국 최종 결과물의 품질, 보안, 아키텍처적 책임은 인간이 져야만 하며, 의도와 실행의 분리가 필요하다고 강조했습니다. 인간은 의사 결정 및 감독을 하고, AI는 지속적인 컨텍스트를 유지하며 실행하는 구조입니다.
삼성계정의 에이전틱 AI 현장 체감: AIOps와 Security Agent
삼성전자는 단순한 AI 어시스턴트를 넘어, 여러 AI 에이전트들이 유기적으로 협업하는 Multi-Agent 아키텍처를 삼성계정 시스템에 구축했습니다. Datadog MCP 서버, Amazon CloudWatch, WAF 등의 데이터 소스를 기반으로 오케스트레이터 에이전트가 각 전문 에이전트(AIOps, Security, WAF 등)를 조율하는 방식입니다.
① 복잡한 지표 속 AI의 진단: AIOps Agent
과거에는 복잡한 인프라 지표를 사람이 수동으로 모니터링하며 원인을 파악해야 했습니다. 하지만 삼성전자가 구축한 AIOps Agent는 AWS Region 단위의 장애가 발생했을 때, Datadog 지표를 스스로 분석하여 1분 내에 정확한 근본 원인을 탐지해 냅니다.
"5XX 에러 급증, DynamoDB 레이턴시 이상, DDB DNS 해소 실패 진단. 단순 서비스 이슈가 아닌 리전 단위 인프라 장애이므로 즉각 조치가 필요합니다."
이처럼 명확한 판단을 내려주는 부분이 무척 경이로웠습니다.
② WAF 로그를 실시간 분석하는 Security Agent
보안 관점에서도 엄청난 혁신이 있었습니다. Security Agent는 Text-to-SQL 기술을 활용하여 웹 응용 프로그램 방화벽 로그를 실시간으로 탐지, 분석, 보고합니다. 웹 게이트웨이 로그를 분석해 크리티컬한 스캐닝 공격 유형을 파악하거나, L7 DDoS 및 무차별 대입 공격을 실시간 차단하고 분석 보고서를 생성하는 전 과정을 AI가 주도적으로 수행하고 있었습니다.
이러한 에이전틱 AI 원칙이 실제 삼성계정 현장에서 가동된 결과는 놀라웠습니다.
과거 시스템 엔지니어로서 수많은 모니터링 대시보드와 로그에 파묻혀 장애 원인을 찾으려 애썼던 기억이 떠올라 소름이 돋았던 세션이었습니다. 인프라 운영과 보안 영역에서 AI가 어떻게 인간 엔지니어의 강력한 파트너가 될 수 있는지 가 장 이상적인 유스케이스를 직접 확인한 느낌이었습니다.
앞으로 제가 설계할 아키텍처나 플랫폼에서도 이러한 Multi-Agent 기반의 지능형 자동화를 어떻게 녹여낼 수 있을지 깊은 인사이트를 얻을 수 있었던 뜻깊은 시간이었습니다.
당근
이어서 보안 인프라 영역인 당근의 CloudHSM/KMS 기반 대규모 서명키 관리 시스템 구축기 세션입니다.
대규모 트래픽을 처리하는 서비스에서 가장 민감한 자산인 서명키를 어떻게 안전하고 효율적으로 관리하고 있는지,
실제 인프라의 한계와 극복 과정을 생생하게 들을 수 있었습니다.
서명키 관리의 중요성과 실패가 불러오는 현실
세션은 서명키 관리가 왜 기업 보안의 뿌리 인지를 설명하며 시작되었습니다. 대칭키와 비대칭키의 개념을 짚으며, 서명은 결국 개인키로 데이터에 도장을 찍는 것과 같아 무결성, 인증, 부인방지를 보장하는 핵심 요소라고 강조했습니다.
만약 이 키 관리에 실패한다면 다음과 같은 치명적인 현실을 마주하게 됩니다.
- 서명키 탈취: 공급망 공격으로 이어져 악성 코드가 합법적인 서명을 달고 수만 개의 조직에 배포될 수 있음
- 토큰 서명키 유출: 인증 위조로 인해 핵심 시스템 및 메일 시스템 침해 발생
- 키 하드코딩: 스크립트 내 관리자 키 하나로 전사 시스템 권한 탈취 가능
기존 아키텍처의 한계와 문제점 식별
당근의 기존 구조는 AWS Secrets Manager를 활용해 Private Key를 보관하고 EKS 클러스터 내의 인증 서버가 이를 가져와 모니터링하는 방식이었습니다. 하지만 이 방식에는 명확한 한계가 존재했습니다.
- AWS Secrets Manager에 대한 촘촘한 접근 제어 미흡
- 인증 서버나 담당자에게 접근 권한이 있으면 Private Key 자체를 추출할 수 있는 위험 존재
- 의도치 않은 토큰의 발행 가능성 및 모바일 앱에서의 인증 요청 우회 가능성
결국 Key 자체를 외부로 노출하지 않으면서도, 인프라 단에서 더 촘촘한 접근 제어를 수행할 수 있는 새로운 아키텍처가 필요했습니다.
AWS KMS vs AWS CloudHSM
당근은 이를 해결하기 위해 AWS가 제공하는 대표적인 두 가지 키 관리 서비스인 KMS와 CloudHSM을 비교 분석했습니다.
| 비교 항목 | AWS KMS | AWS CloudHSM |
| HSM 유형 | Multi-tenant | Single-tenant (고객 전용 단일 테넌트) |
| 인터페이스 | AWS API / SDK (kms:Sign 등) | PKCS#11, JCE, OpenSSL 등 표준 인터페이스 |
| 키 관리 | AWS 관리 (자동 Rotation 지원) | 고객 직접 관리 |
| 접근 제어 | IAM Policy + Key Policy | HSM User/Key 레벨 제어 |
| 인증 수준 | FIPS 140-3 Level 3 (KMS 내부 보호) | FIPS 140-2/3 Level 3 인증 하드웨어 |
| 비용 모델 | 요청당 과금 (비대칭키: $0.15 / 10,000 req) | 시간당 과금 (hsm2m.medium: $1.54/hr) |
| 운영 복잡도 | 낮음 | 높음 |
당근은 각 서비스의 특징을 면밀히 분석한 후, 진단 -> 설계 -> 검증 -> 안정화 -> 배포에 이르는 AWS와의 과정을 거쳐 최종 아키텍처를 도출했습니다. POC 과정에서 Scale 성능 한계 테스트와 Service Quota 증설 등을 철저히 검증했다고 합니다.
CloudHSM 아키텍처 개선
당근이 구축한 최종 CloudHSM 아키텍처는 Private Subnet 안에 멀티 AZ(AZ-a, b, c)로 CloudHSM 클러스터를 구성하여 고가용성을 확보한 것이 핵심입니다.
- 가드레일 기반 접근 제어: EKS 클러스터 내부에서 오직 허용된 서버들만 istio와 Allow CloudHSM Access Security Group을 통해 서명 애플리케이션(HSM 접근 NodeGroup)으로 접근할 수 있도록 촘촘하게 통제합니다. 권한이 없는 다른 서버의 접근은 인프라 단에서 차단됩니다.
- Key 추출 불가능 구조: FIPS 140 인증을 받은 CloudHSM 내부에서 키가 생성·보관되며, 암호화되지 않은 상태로는 절대로 HSM 외부로 유출되지 않는 구조를 완성했습니다. 이를 통해 기존 Secrets Manager의 Private Key 추출 리스크를 완벽하게 해소했습니다.
CloudHSM Cluster 추가 설정 및 접근 제어 흐름
당근은 인프라와 애플리케이션 단뿐만 아니라, 네트워크와 모듈 설정 수준까지 제로 트러스트 관점을 적용했습니다.
① mTLS 설정 및 다중 인프라 격리
- 상호 TLS(mTLS) 적용: CloudHSM Cluster 내부의 HSM 인스턴스들 간의 동기화 통신은 물론, 외부 인프라와 담당자가 HSM에 접근할 때도 mTLS 설정을 필수적으로 거치도록 설계했습니다.
- 개발자 접근 불가: 인프라 아키텍처상 개발자는 CloudHSM에 직접 접근할 수 없도록 원천 차단 했습니다.
- 엄격한 자격증명 제출: 오직 통제된 HSM 관리 인스턴스를 통해 HSM 담당자가 직접 ID/PW를 stdin으로 입력해야만 키 생성 및 속성 변경이 가능합니다. 실제 서명을 수행하는 Token Issuer 역시 AWS Secrets Manager에 보관된 클러스터 접근용 ID/PW를 PKCS#11 제출 과정을 거쳐 획득하는 구조를 짰습니다.
② Kubernetes 기반의 촘촘한 CloudHSM Access Control
- Kyverno를 통한 비정상 접근 차단: 만약 허용되지 않은 Pod(Imposter)가 서비스 어카운트 토큰을 요청하거나 노드 스케줄링을 시도하는 공격 시나리오에 대비했습니다. Kubernetes 네이티브 정책 엔진인 Kyverno를 도입하여, 허용된 Pod 이외의 요청은 K8s API Server의 Validation 과정에서 즉각 차단하도록 방어선을 구축했습니다.
- 자격증명 조회 제한: Token Issuer의 Role이 아닌 일반 SRE 팀이나 다른 Pod가 Secrets Manager 내의 HSM 접근 정보 Key에 접근하려 할 경우, 접근 권한을 제한하는 가드레일을 세웠습니다.
③ 키 권한 설정 방식
가장 인상 깊었던 부분은 CloudHSM 내의 비대칭키 쌍을 생성할 때 부여하는 Crypto User 속성 통제였습니다.
- --private-attributes extractable=false: Disable Extraction 설정을 통해 Private Key가 임의로 추출되어 외부로 유출되는 것을 원천 방지합니다.
- --private-attributes destroyable=false: Prevent Destruction 설정을 비활성화하여 악의적인 침입자가 키를 임의로 삭제하는 행위를 방지합니다.
- share-crypto-users token_issuer: 키를 생성한 Owner와 별개로, 실제 서명을 수행할 token_issuer 계정에 키를 공유하여 오직 서명 권한만 허용하고 의도치 않은 설정 변경을 사전 차단했습니다.
- 비정상 접근 추적: HSM 및 HSM 관리 인스턴스에 대한 모든 접근 기록은 AWS CloudTrail을 통해 지속적으로 추적하고 모니터링합니다.
CloudHSM vs AWS KMS 연동 비교
당근은 실제 구현 방식과 성능, 비용 면에서 두 서비스를 면밀히 벤치마크했습니다.
① 개발 생산성과 연동 방식의 차이
- CloudHSM: HSM 통신 표준 인터페이스인 PKCS#11을 사용해야 하므로 C 기반 작성이 필요합니다. Go(Cgo 사용)나 Java(JNI 사용) 같은 언어에서는 Shared Object(.so) 바이너리 파일을 FFI(Foreign Function Interface) 형태로 호출하여 mTLS 통신을 처리해야 하므로 운영 및 개발 복잡도가 매우 높습니다.
- AWS KMS: 단순한 AWS API 호출(kms:Sign) 및 IRSA(IAM Roles for Service Accounts) 기반의 접근 제어가 가능하여 도입이 매우 쉽습니다.
② 성능 및 비용 비교 (매일 65M 서명 가정)
같은 VPC 내에서 구동될 때의 벤치마크 결과는 놀라웠습니다.
- 지연 시간: AWS KMS는 p50 기준 5ms, p99 기준 30ms의 레이턴시를 보인 반면, AWS CloudHSM은 p50 기준 2ms, p99 기준 5ms로 훨씬 낮고 안정적인 지연 시간을 확보했습니다.
- 처리량: CloudHSM은 인스턴스 1대당 약 1,600 RPS의 성능을 내며, 4대 기준 약 6,400 RPS, 5대 기준 7,900 RPS로 장비 증설에 따라 성능이 선형적으로 투명하게 증가했습니다.
- 비용 및 성능 요약:
- KMS: 일간 서명 횟수 65M 기준 일일 약 $975의 비용이 발생하며, Quota 증설이 가능하지만 AWS Managed 영역의 API 통제를 받습니다.
- CloudHSM: hsm2m.medium 4대 기준 일일 약 $147.84로 비용 효율성이 극대화되며, 4대 기준으로 ES256 signing 7K RPS의 고성능을 보장합니다. 무엇보다 고객 VPC 내 물리적 격리가 가능하다는 장점이 큽니다.
결론: 당근은 성능과 물리적 격리가 핵심인 AWS CloudHSM을 중심으로 대규모 서명 인프라를 사용하되, AWS KMS로 상호 보완하는 하이브리드 전략을 취했습니다.
토큰 서명 시스템 설계 시 고려해야 할 5대 원칙
대규모 인증 아키텍처를 설계하는 엔지니어가 가슴에 새겨야 할 5가지 원칙으로 정리되었습니다.
- Private Key가 절대 외부에 유출되지 않는다. (CloudHSM 하드웨어 격리 및 Extractable=false)
- 서명 트래픽을 안정적으로 감당할 수 있다. (인스턴스 선형 증설을 통한 고성능 배정)
- SPOF(Single Point of Failure) 없이 여러 대안이 존재한다. (Multi-AZ 및 KMS 보완 설계)
- 촘촘하게 서명 트래픽에 대한 접근제어를 수행한다. (Kyverno, Istio, SG 및 Secrets Manager 가드레일)
- 담당자도 임의로 서명할 수 없도록 안전하게 키를 보관한다. (Crypto User 권한 분리 및 사용처 제한)
CloudHSM 운영 중 마주한 4대 한계와 트러블슈팅
당근 SRE 팀은 CloudHSM을 대규모 프로덕션 환경에 적용하면서 오토스케일링(Scale-out/in), 성능 튜닝, 로깅 등 다방면에서 예상치 못한 기술적 난제들을 마주했고, 이를 다음과 같이 영리하게 해결했습니다.
① Scale-out 시 세션 고정 문제
- 문제점: 트래픽 급증으로 인해 CloudHSM 인스턴스를 추가(Scale-out)하더라도, 기존 애플리케이션 Pod(Pod A, B)들이 기존 HSM 장비에만 세션이 고정되어 있었습니다. 이 때문에 새로 추가된 HSM-3 장비로는 트래픽이 전혀 분산되지 않는 문제가 발생했습니다. 추가된 장비로 세션을 재연결하려면 애플리케이션 단에서 재연결 로직이 필요했습니다.
- 해결책: 당근은 인프라 단에서 애플리케이션(Pod)을 순차적으로 재시작하는 방식을 도입하여, 신규 인스턴스(HSM-3)를 포함한 모든 장비와 세션을 새롭게 수립하도록 유도해 로드 밸런싱을 해결했습니다.
- 시행착오: 처음에는 도메인(Route 53) 기반으로 HSM 목록을 관리하며 크론잡(CronJob)으로 ENI IP 목록을 갱신하려 했으나, 도메인 연결 시 세션 불안정 문제가 발생하여 이를 폐기했습니다. 대신 configure-pkcs11로 cloudhsm:DescribeCluster API를 직접 호출하여 IP 목록을 투명하게 실시간으로 확보하는 권장 방식으로 정착했습니다. 또한 Istio 환경에서 PKCS#11 Client 초기화 시 커넥션 에러가 발생하는 문제를 해결하기 위해, Istio에서 CloudHSM IP 식별을 위한 도메인 병행 방식을 적용했습니다.
② Scale-in 중 요청 실패 및 인플라이트 요청 처리
- 문제점: 트래픽이 줄어 HSM 인스턴스를 줄일 때(Scale-in), 제거되는 인스턴스(HSM-3)로 진행 중이던 일부 인플라이트 요청들이 즉각 끊어지며 Device Removed, Resource Pool Timeout 에러와 함께 약 0.5%의 ErrorRate가 발생했습니다.
- 해결책: 제거된 인스턴스를 감지하고 커넥션을 끊는 로직을 보완함과 동시에, 이 과정에서 발생하는 일시적인 실패 트래픽은 후술할 KMS Fallback 처리를 통해 사용자 단의 에러를 0건으로 방어했습니다.
③ MaxSessions 튜닝: 실패보다 대기가 낫다
- 문제점: 초기 설정 시 MaxSessions 값을 너무 높게 잡았더니, 흐름 제어가 작동하지 않아 대규모 요청 시 CloudHSM 내부 큐에 과부하가 걸렸습니다. 이는 곧바로 레이턴시 급증과 HSM could not Queue 에러로 이어졌습니다.
- 해결책: MaxSessions 값을 낮게 조정하는 대신 Session Pool과 poolWaitTimeout 설정을 추가했습니다. 애플리케이션 단에서 흐름 제어를 적용하여 Pool에서 세션 획득을 잠시 대기하게 만듦으로써 HSM 내부 큐를 안전하게 보호한 것입니다. 그 결과 레이턴시는 소폭 증가했으나 에러 발생을 0건으로 만드는 데 성공했습니다.
④ 바이너리 .so 파일의 로깅 체계 구축
- 문제점: AWS가 제공하는 libcloudhsm_pkcs11.so 바이너리는 자체 로그 출력 스트림 제어가 불가능하여, 실시간으로 보안 위협이나 모니터링 지표를 파악하기 어려웠습니다.
- 해결책: 서버 내 특정 경로(/opt/cloudhsm/run/cloudhsm-pkcs11.log)에 쌓이는 바이너리 로그 파일을 실시간으로 추적하는 LogTail을 직접 구현했습니다. 이후 별도의 정규식 파싱 과정을 거쳐 Datadog 지표 및 Sentry와 연동함으로써, 실시간 모니터링 및 얼럿 시스템을 구축했습니다.
키 로테이션과 서명 Failover 아키텍처
① 무중단 Key Rotation 프로세스
보안 규정상 주기적인 키 교체는 필수입니다. 당근은 대규모 트래픽 환경에서 서비스 중단 없이 키를 교체하기 위해 총 5단계의 Dynamic Config 기반 파이프라인을 설계했습니다.
- 새 키 생성: AWS CloudHSM 및 AWS KMS에 새 키(hsm-key-02, kms-key-03)를 사전에 생성합니다.
- Weight 이동: 가중치를 이용해 신규 키로 트래픽을 서서히 이동시킵니다.
- 기존 서명 중단: 기존 키(local-key-01)의 서명 권한을 중단합니다.
- 토큰 만료 대기: 기존 키로 발급된 토큰들이 완전히 만료될 때까지 읽기 권한만 유지하며 대기합니다.
- 공개키 제거: 안전하게 기존 공개키를 구성에서 완전히 제거합니다.
② 3중 서명 Failover (고가용성) 설계
당근은 CloudHSM이나 KMS의 장애 상황까지 대비하여 TokenSigner 인터페이스 하위에 가중치 기반의 Active-Standby 3중 방어선을 구축했습니다.
- 1차 (Active, 가중치 100%): 고성능의 하드웨어 암호화 장비인 HSMSigner를 통해 메인 서명을 처리합니다.
- 2차 (Standby - 실패 시 전환): CloudHSM 장애 시 AWS Managed 서비스인 KMSSigner로 즉각 트래픽을 Fallback 시킵니다.
- 3차 (Standby - 실패 시 전환): 최악의 경우 엔드포인트가 모두 마비되더라도 비즈니스 연속성을 유지할 수 있도록 로컬 내 가드레일 통제 하에 작동하는 LocalSigner로 최종 전환되는 촘촘한 Failover 구조를 완성했습니다.
서명 알고리즘 변경: RS256과 ES256
성능과 비용을 최적화하기 위해 기반 암호학 알고리즘에도 변화를 주었습니다. 소인수 분해 기반의 기존 RS256 대신, 타원곡선 이산대수 기반의 ES256(ECDSA)으로 전면 전환했습니다.
- 키 크기: 2048-bit에서 256-bit (8배 감소)
- 서명 크기: 256 bytes에서 64 bytes (4:1 압축)
- 토큰 크기: ~800 bytes에서 ~500 bytes (37% 절감, 네트워크 비용 최적화)
- 보안 수준: 112-bit에서 128-bit (더 높은 보안성 확보)
- 연산 효율성: 서명 속도가 대폭 향상되었으며, 하드웨어 보안 모듈(HSM)에서 처리하기에 훨씬 효율적인 구조로 개선되었습니다.
스마일샤크
올해도 스마일샤크 부스에서 재밌는 굿즈를 제공해 주셨다, 작년에는 키링인걸로 기억하는데
'나의 클라우드 엔지니어 유형'을 알아보는 간단한 심리테스트 같은 조사를 진행했는데, 내 결과는 올라운더 수비형 상어가 나왔다.
"전체를 보는 눈! 팀 전체의 흐름을 관리하고 연결하는 것이 특기예요. 클라우드로 치면 서비스 전체가 어떻게 연결되어 있는지 한눈에 파악하는 운영 전문가예요. 어디서 병목이 생기는지, 어느 구간이 느린지를 꿰뚫어 봅니다."
설명을 읽어보니, 그런것 같기도하고.. 아닌것 같기도하고..
스태프분께서 결과에 맞는 캐릭터 스티커와 함께 슈즈백을 증정해 주시고, 취향대로 가방을 커스텀할 수 있게 해 준다. 야구 글러브를 야무지게 끼고 있는 상어 캐릭터나 HIT THE CLOUD! 같은 야구 콘셉트의 굿즈 디자인이었다.
야구공 불꽃 마크와 넘버원 손가락 폼핑거 스티커까지 슈즈백 캔버스 위에 요리조리 배치해 붙이며 나만의 가방을 완성해 보았다. 묵직하고 진지한 클라우드 아키텍처와 보안 세션들 사이에서, 쏠쏠한 전리품을 챙길 수 있었던 기분 좋은 이벤트였다.
피지컬 AI
오전 세션을 듣고 난 후 Expo 전시장에서 흥미로웠던 부분은 피지컬 AI 관련 시연 부스들이었습니다.
가장 먼저 인파가 몰렸던 아이스크림을 나눠주는 로봇 팔.
단순히 입력된 좌표로만 움직이는 과거의 기계 장치를 넘어, 센서를 통해 상황을 인지하고 정교한 관절 제어로 종이컵을 집어 들어 정확한 양의 아이스크림을 담아내는 일련의 과정이 느린부분은 있었지만 무척이나 부드럽고 자연스러웠습니다.
전시장 통로 한켠에서는 사족보행 로봇과 자율주행 배달 로봇이 현장을 누비는 모습도 포착할 수 있었습니다. 자세한 스펙이나 모델명까지 가까이서 확인하지는 못했지만, 수많은 참관객이 오가는 복잡하고 동적인 전시장 환경 속에서도 충돌 없이 부드럽게 장애물을 회피하며 자신의 경로를 찾아가는 모습이 무척 신기했습니다.
이번 서밋에서 AWS가 강조한 AI가 단순한 언어 생성을 넘어 로봇, 물류, 제조 등 현실 공간의 물리적 혁신으로 진화했다는 선언이 단지 먼 미래의 비전이 아니라, 이미 우리 눈앞에 성큼 다가온 기술적 현실임을 피부로 체감할 수 있었던 흥미로운 시간이었습니다.
부스를 돌며 받았던 굿즈들..
