당근이 AWS CloudHSM으로 대규모 서명키 관리 시스템을 구축한 방법 – 1부: 서명키 보안의 중요성과 서비스 선택

해당 포스트는 당근의 최용환님, 조승환님, 오현준님과 함께 작성했으며, AWS Summit Seoul 2026에서 발표한 세션 내용을 기반으로 합니다.

 당근은 대한민국을 대표하는 지역생활 커뮤니티로서, 2,100만 이상의 월간 활성 사용자(MAU)와 4,300만 이상의 누적 가입자를 보유하고 있습니다. 당근의 인증 서비스는 이 거대한 사용자 기반을 대상으로 하루 평균 6,500만 건 이상의 JWT 토큰 서명을 처리하고 있습니다. JWT(JSON Web Token)는 서명으로 위·변조를 막는 인증 토큰입니다.

그런데 이 막대한 양의 서명을 처리하던 기존 구조에는 한 가지 고민이 있었습니다. 서명에 사용하는 Private Key를 추출할 수 있는 형태로 보관하고 있었던 것입니다. 토큰 서명키는 곧 인증 체계 전체의 신뢰 기반이기 때문에, 당근은 이 키를 더 안전하게 보관하면서도 대규모 트래픽을 안정적으로 감당할 수 있는 새로운 시스템이 필요하다고 판단했습니다. 그 해법으로 선택한 것이 AWS CloudHSM과 AWS KMS를 조합한 하이브리드 서명키 관리 시스템입니다.

이 블로그는 3부작으로 구성됩니다.

• 1부에서는 서명키 보안이 왜 중요한지 짚어본 뒤, 당근이 어떤 기준으로 두 서비스를 비교하고 선택했는지 설명합니다.
• 2부에서는 CloudHSM 아키텍처 설계와 다계층 접근 제어 전략
• 3부에서는 서명 시스템 구현, 트러블슈팅, 그리고 무중단 키 전환 과정을 공유합니다.

키 관리 실패가 불러온 현실

서명키 보안은 왜 중요할까요? 최근 보안 업계 보고서들은 키와 자격증명 관리의 실패가 대형 사고로 이어지는 흐름을 일관되게 보여줍니다. IBM의 2025 데이터 유출 비용 연구 보고서에 따르면 전 세계 데이터 유출 사고의 평균 피해액은 444만 달러에 달하며, Verizon의 2025 Data Breach Investigations Report는 초기 침투 경로 중 탈취된 자격증명이 가장 큰 비중(약 22%)을 차지한다고 분석했습니다. GitGuardian의 State of Secrets Sprawl 보고서는 공개 저장소에서 매일 수만 건의 시크릿이 유출되고 있으며, 그중 상당수가 수년이 지난 뒤에도 여전히 유효하다고 지적했습니다.

최근 대형 보안 사고들을 살펴보면, 원인은 다양하지만 ’키 관리 실패’라는 공통 패턴이 반복적으로 나타납니다.

• 하드코딩된 키로 인한 광범위한 시스템 탈취 — 스크립트나 소스 코드에 직접 넣어둔 키 하나가 전체 인프라의 접근 권한으로 이어진 사례
• 서명키 탈취를 통한 공급망 공격 — 합법적 인증서로 서명된 악성 업데이트가 다수 조직에 배포되어, 서명키 하나의 유출이 공급망 전체로 확산된 사례
• 핵심 인프라 이중화 부재로 인한 장기 서비스 마비 — 데이터센터 장애 시 보안키 저장소를 포함한 핵심 시스템 복구가 지연되며 장시간 서비스가 중단된 사례
• 토큰 서명키 유출로 인한 인증 위조 — 유출된 서명키로 인증 토큰이 위조되어 민감한 시스템이 침해된 사례

이 사고들의 공통점은 명확합니다. 키가 안전하지 않은 곳에 저장되어 있었다는 것입니다. 그렇다면 오늘의 주제인 ’서명키’는 정확히 무엇이고, 왜 특별히 중요할까요?

서명키란 무엇인가

암호키는 크게 두 종류로 나뉩니다. 대칭키(Symmetric Key)는 하나의 키로 암호화와 복호화를 함께 수행해 빠르지만 키 전달이 까다롭고, 비대칭키(Asymmetric Key)는 공개키와 개인키 쌍으로 동작해 공개키는 공유해도 안전하므로 키 전달이 자유로운 대신 연산 비용이 더 큽니다. 개인키로 서명하고 공개키로 검증하는 구조입니다.

서명(Signing)은 이 비대칭키를 활용하는 행위로, 한 줄로 정리하면 “내 개인키로 데이터에 도장을 찍는 것”입니다. 받는 쪽은 공개키로 그 도장이 진짜인지 확인합니다. 이 도장 한 번이 무결성(데이터 변조 여부), 인증(보낸 사람 확인), 부인방지(나중에 부인하지 못함)를 동시에 보장합니다. 그래서 JWT 토큰, 코드 서명, TLS/SSL 인증서, API 요청 서명 등 신뢰가 필요한 거의 모든 곳에 서명키가 사용됩니다.

결국 서명키는 신뢰 체계의 뿌리(Root of Trust)입니다. 이 키가 유출되면 누구든 정상적인 토큰을 위조하거나 악성코드에 합법적인 서명을 할 수 있어, 전체 인증 체계가 무력화됩니다. 서명키를 안전하게 보관하는 것이 무엇보다 중요한 이유입니다. AWS는 이를 위한 두 가지 핵심 서비스로 AWS KMS와 AWS CloudHSM을 제공합니다.

AWS KMS와 CloudHSM

AWS Key Management Service(KMS)는 데이터 암복호화, 디지털 서명 및 검증, 데이터 키 생성, 메시지 인증 코드(MAC) 등 핵심 암호화 작업을 제공하는 완전관리형 서비스입니다. 가장 큰 장점은 Amazon S3, Amazon DynamoDB 등 AWS 서비스와 네이티브로 통합되어 별도 코드 변경 없이 암호화를 적용할 수 있다는 점이며, AWS CloudTrail과 Amazon CloudWatch로 키 사용 이력을 모니터링할 수 있습니다. KMS에서 생성한 키는 FIPS 140-3 Security Level 3 인증을 받은 하드웨어 보안 모듈(HSM)에 의해 보호되며, 암호화되지 않은 상태로 KMS 외부로 나가지 않습니다. (FIPS 140-3 Level 3은 미국 정부의 암호화 모듈 보안 표준 중 하나로, 물리적 변조가 감지되면 키를 폐기하는 높은 등급입니다.)

AWS CloudHSM은 FIPS 140-2 또는 140-3 Level 3 인증 하드웨어(HSM 인스턴스 유형에 따라 다름)에서 고객 전용 단일 테넌트 HSM을 제공합니다. HSM(Hardware Security Module)은 암호화 키를 전용 하드웨어 내부에서만 생성·저장·사용하는 변조 방지(tamper-resistant) 장치입니다. KMS와의 핵심 차이는 세 가지입니다:

1. 단일 테넌트 — 다른 고객과 하드웨어를 공유하지 않는 전용 HSM입니다. 격리규제 요건이 엄격한 환경에서 특히 유리합니다.
2. 표준 인터페이스 — PKCS#11(애플리케이션이 HSM에 키 작업을 요청하는 표준 API), JCE, OpenSSL, KSP/CNG 등 업계 표준 HSM 인터페이스를 지원하여, 온프레미스 HSM에 익숙한 방식 그대로 활용할 수 있습니다.
3. 고객 전용 제어 — 키 운영 권한이 고객에게 있으며, AWS는 고객의 키 자체에 접근하지 않습니다. 그만큼 키 관리 책임도 고객이 직접 부담하는 구조입니다.

아키텍처는 고객의 VPC 안에서 다중 가용영역(AZ) 클러스터로 구성할 수 있고, KMS Custom Key Store를 통한 AWS 서비스 간접 연동이나 EC2·클라이언트 애플리케이션에서의 직접 연동이 모두 가능합니다.

당근의 기존 아키텍처와 한계

앞서 언급했듯 당근의 인증 시스템은 하루 6,500만 건 이상의 JWT 토큰 서명을 처리합니다. 기존에는 서명에 필요한 Private Key를 AWS Secrets Manager에 보관하여 사용했습니다. 원하는 애플리케이션에서만 서명하는 것은 가능했지만, 다음과 같은 한계가 있었습니다:

• Secrets Manager의 접근 제어 한계 — 접근 권한이 있으면 Private Key 자체를 추출할 수 있어, 의도하지 않은 토큰이 발행될 가능성이 존재했습니다.
• 네트워크 레벨 접근 제어 부족 — 모바일 앱에서 서명 서비스에 직접 연결할 수 있는 구조였기 때문에, 더 촘촘한 접근 제어가 필요했습니다.

이 한계를 인식한 당근은 새로운 토큰 서명 시스템을 설계하면서 다섯 가지 핵심 기준을 설정했습니다:

1. Private Key가 외부로 유출되지 않도록 보관한다.
2. 서명 트래픽을 안정적으로 감당할 수 있어야 한다.
3. SPOF(Single Point of Failure) 없이 여러 대안이 존재해야 한다.
4. 서명 트래픽에 대한 접근 제어를 촘촘하게 수행한다.
5. 담당자도 임의로 서명할 수 없도록 키를 안전하게 보관한다.

AWS KMS vs CloudHSM: 서비스 비교

이 다섯 가지 기준을 충족할 수 있는 두 서비스를 비교했습니다.

처리량(RPS) 비교

당근은 6,000 RPS 이상을 안정적으로 처리하는 것을 목표로 설정했고, 두 서비스 모두 당근의 요구사항을 충족했습니다.

• KMS: 기본 1,000 RPS에서 시작하여 Quota 증설 요청을 통해 확장할 수 있습니다. 다만, 처음부터 높은 Quota를 요청할 경우 그에 맞는 Use Case와 충분한 사유 설명 과정을 거쳐 증설이 이루어집니다.
• CloudHSM: hsm2m.medium 4대 기준 약 7,000 RPS를 처리할 수 있었습니다. HSM 인스턴스를 추가하면 처리 가능한 요청량이 함께 증가하는데, 노드 수에 정확히 정비례하지는 않지만 인스턴스 증설만으로 용량을 확장할 수 있다는 점이 강점이었습니다.

비용 비교

하루 6,500만 건의 서명을 기준으로 비용을 비교했습니다.

• KMS: 비대칭 서명 기준 요청 1만 건당 $0.15가 발생합니다(RSA·ECC 동일 단가). 하루 6,500만 건이면 일일 약 $975 입니다. (월 $29,250, 연 $355,875 수준)
• CloudHSM: 인스턴스 시간당 $1.54가 고정 과금되며, 4대 기준 일일 약 $148입니다. (월 $4,440, 연 $54,020)

순수 서명 처리 비용(API 호출 vs HSM 인스턴스)만 놓고 보면 CloudHSM이 KMS 대비 약 85% 저렴합니다. 다만 CloudHSM은 전용 NodeGroup, HSM 관리 인스턴스, 운영 복잡도 등 부대 비용이 수반되므로 전체 TCO 차이는 이보다 적을 수 있습니다. 그럼에도 당근처럼 대량의 서명이 발생하는 환경에서는 CloudHSM이 비용 효율적이라는 판단에는 변함이 없었습니다.

어느 서비스가 유리한지는 손익분기를 따져보면 가늠할 수 있습니다. 대략 ‘서명 건수 × KMS 요청 단가’와 ‘HSM 대수 × 시간 단가 + 운영·부대 비용’을 비교해, 서명량이 일정 수준을 넘어서면 CloudHSM 쪽이 저렴해지는 구조입니다. 자신의 호출량을 이 식에 대입해 보면 CloudHSM 전환의 타당성을 손쉽게 추정할 수 있습니다.

벤치마크 성능 비교

직접 벤치마크 테스트도 진행했습니다.

• Latency: CloudHSM이 KMS 대비 p50은 2.5배(약 2ms vs 5ms) , p99는 6배(약 5ms vs 30ms) 더 빨랐습니다. CloudHSM은 고객 VPC 내에 직접 위치해 네트워크 홉이 적기 때문입니다.
• Throughput: 인스턴스를 추가할수록 처리량이 함께 증가했습니다. 인스턴스 추가만으로 용량을 늘릴 수 있다는 점이 운영상 큰 장점이었습니다.

접근 제어 비교

• KMS: AWS Managed VPC에 위치하며 AWS API와 IAM 정책으로 접근을 제어합니다. AWS 환경에 익숙한 개발자에게 친숙한 방식입니다.
• CloudHSM: 고객 VPC 안에 직접 위치하여 물리적으로 격리되며, PKCS#11 표준 인터페이스 기반으로 유저와 키를 세밀하게 관리할 수 있습니다.

CloudHSM을 중심으로, KMS로 보완하는 하이브리드 전략

모든 비교를 종합했을 때, 비용·성능·접근 제어 측면에서 CloudHSM이 당근의 대규모 서명 워크로드에 더 적합하다고 판단했습니다. 그래서 CloudHSM을 메인 서명 서비스로, KMS를 플랜 B로 보완하는 하이브리드 구조로 결정했습니다.

하이브리드를 택한 데는 비용·성능 외에 안정성 측면의 이유도 있었습니다. CloudHSM과 KMS는 서로 장애 도메인(failure domain)이 다르기 때문에, 한쪽에 문제(HSM 유지보수, 운영 실수, 일시적 통신 장애 등)가 생겨도 다른 한쪽으로 서명을 이어갈 수 있습니다. 단일 서비스만 사용한다면 그 서비스 자체가 SPOF가 되므로, KMS를 플랜 B로 두는 것은 비용 낭비가 아니라 안정성 설계에 가깝습니다.

또한 CloudHSM 용량을 산정할 때는 평상시 평균 RPS가 아니라 “HSM 한 대가 빠지거나 AWS 유지보수가 겹쳐도 남은 노드로 버틸 수 있는가(N+1)”를 기준으로 잡는 것이 안전합니다. 정리하면, 어떤 서비스가 맞는지는 트래픽 규모뿐 아니라 운영 역량(PKCS#11 경험), 규제·컴플라이언스 요건, 비용 예측성, 장애 대응 전략을 함께 놓고 판단하는 것이 좋습니다.

마무리

1부에서는 서명키 보안이 왜 중요한지 살펴보고, 당근이 기존 아키텍처의 한계를 인식한 뒤 어떤 기준으로 CloudHSM과 KMS를 비교하여 하이브리드 전략을 선택했는지 설명했습니다.

2부에서는 CloudHSM 아키텍처를 어떻게 설계하고, Istio·Kyverno·PKCS#11 User 등을 활용한 다계층 접근 제어 전략을 어떻게 구현했는지 자세히 다루겠습니다.