암호 인벤토리 구축을 통한 체계적 PQC 전환 전략

자물쇠를 교체하려면, 먼저 건물 안에 자물쇠가 몇 개인지, 어디에 달려 있는지부터 파악해야 합니다. 이 단순한 원칙이 바로 오늘 이야기의 핵심입니다.

양자 컴퓨팅 기술이 발전하면, 지금 인터넷 통신과 인증에 쓰이는 공개키 암호 체계(RSA, ECC 등)의 안전성은 장기적으로 무너집니다. 더 심각한 건 위협이 이미 시작됐다는 점입니다. 'Harvest Now, Decrypt Later(HNDL, 지금 수집해 나중에 해독)'라는 공격 방식이 대표적입니다. 지금 당장은 해독하지 못하더라도 암호화된 데이터를 미리 긁어 모아 두었다가 향후 양자 컴퓨터가 완성되는 날 한꺼번에 풀어버리는 공격 방식입니다. 마치 금고를 열 수 있는 열쇠는 없지만 금고 째로 훔쳐 두는 것과 같습니다. 그래서 양자내성암호(Post-Quantum Cryptography, PQC)로의 전환은 언젠가 해야 할 미래의 과제가 아니라 지금 당장 준비해야 하는 현실적인 과제가 되었습니다.

문제는 암호가 한 곳에 모여 있지 않다는 데 있습니다. 코드 안에도 있고, 라이브러리 깊숙이도 있고, 네트워크 통신 과정에도 흩어져 있습니다. 웹 서비스, 내부 API, 배치 잡, 레거시 모듈, 외부 연동 구간을 따로따로 일일이 들여다봐야 하는데, 이를 수작업으로 다 확인하는 건 사실상 불가능합니다. 그래서 PQC 전환의 첫 번째 과제는 알고리즘 선택이 아니라, 지금 조직 안에서 암호가 어디에 어떻게 쓰이고 있는지를 체계적으로 파악하는 '식별(Discovery)'입니다. 이 식별 결과가 쌓여야 신규 도입 검토, 기존 시스템 전환, DevSecOps(개발, 빌드, 배포, 운영 전 과정에서 보안을 자동화해 내재화하는 방식) 기반 지속 운영으로 이어지는 암호 인벤토리가 만들어집니다.

특히 까다로운 건 조직이 직접 개발, 운영하는 인하우스(in-house) 애플리케이션입니다. 외부 SaaS나 상용 솔루션은 벤더에게 확인이라도 할 수 있지만, 직접 만든 서비스는 코드 구조, 실행 경로, 배포 환경, 외부 라이브러리 의존성이 제각각이라 암호가 어디서 어떻게 쓰이는지 예측하기 어렵습니다. 이 글에서는 DevSecOps 파이프라인 전반에서 정적 분석, 동적 분석, 프로토콜 분석, 패킷 분석으로 암호 사용 현황을 파악하는 방법을 살펴봅니다. 나아가 그 결과를 CBOM(Cryptography Bill of Materials, 암호 자산 명세서) 형식으로 구조화해 인벤토리로 관리하고 이를 정책·조달·전환·운영에 실제로 연결하는 방법까지 다룹니다.

삼성SDS R&D센터는 NIST(미국 국립표준기술연구소) PQC 전환 프로젝트에 초기부터 참여하며 암호 인벤토리 식별 기술인 S-CAPE(Samsung SDS Crypto Agility Platform for Enterprise)를 개발해 왔습니다. 그 기술적 배경과 실무 접근 방식을 지금부터 구체적으로 풀어봅니다.

핵심 인사이트: PQC 전환의 출발점은 알고리즘 교체가 아닙니다. 양자내성암호 전환을 실행 가능한 과제로 만들려면, 먼저 조직 내 암호 사용 현황을 식별하고 암호 인벤토리 구축을 통해 전환 범위·우선 순위·비용을 데이터로 확인할 수 있어야 합니다.

🔗 참고 포스트 : 삼성SDS 기술블로그 | 양자컴퓨터 시대, SDS는 이렇게 보안을 준비하고 있습니다

1. PQC 전환 첫 단계: 암호 사용 현황 식별(Discovery)이란

건물 리모델링을 맡은 팀이 가장 먼저 하는 일은 무엇일까요? 새 자재를 주문하는 것이 아니라, 현재 구조도를 꺼내 보는 것입니다. PQC 전환도 다르지 않습니다. 새 알고리즘을 먼저 고르는 게 아니라, 지금 우리 시스템이 어디서 어떤 암호를 쓰고 있는지 파악하는 것이 첫 번째 단계입니다.

공개키 암호는 오늘날 IT 환경에서 인증, 기밀성, 무결성 보장에 폭넓게 활용됩니다. HTTPS 기반 웹 서비스, VPN을 통한 원격 접속, 전자서명 기반 인증 등 핵심 보안 기능 대부분이 암호 기술에 의존합니다. 그러나 양자 컴퓨팅 기술이 성숙해지면 RSA(Rivest-Shamir-Adleman, 소인수분해 기반 공개키 암호), ECC(Elliptic Curve Cryptography, 타원 곡선 암호) 같은 기존 공개키 암호 체계는 장기적으로 안전성을 보장받기 어려워집니다. 특히 앞서 언급한 HNDL 시나리오는 지금 수집된 데이터가 미래에 복호화될 수 있으므로, 장기 보호가 필요한 정보는 선제적으로 대비해야 합니다.

[그림 1] PQC 전환의 필요성: Harvest Now, Decrypt Later(HNDL, 지금 수집해 나중에 해독)

양자컴퓨터로 인한 보안 위협, 지금이 바로 PQC 전환을 시작할 때!

양자컴퓨터로 인한 보안 위협에 대한 내용의 표
Today - Harvest Now.	XXX Bank	←Non-PQC(Encrypted Traffic)→ ↓	Customer	←PQC(Enctyped Traffic)→ ↓	AAA Bank
Today - Harvest Now.	공격자가 암호화된 트래픽 저장 Secure for NOW ↓
Future - Decrypt Later!	개인정보 대량 유출 / 개인정보 해킹 가능		←QUANTUM COMPUTER→	개인정보 보호 / 개인정보 해킹 불가

"PQC 적용 시, Harvest Now, Decrypt Later 공격 불가

이러한 배경에서 NIST*를 중심으로 PQC 표준화가 진행되고 있으며, 여러 기관과 기업이 단계적 전환을 추진하고 있습니다. 다만 실제 운영 환경에서는 다양한 시스템과 애플리케이션이 서로 다른 방식으로 암호 기술을 사용하고 있어, 그 현황이 항상 명확히 관리되지는 않습니다. 특히 레거시 시스템, 오픈소스 의존성이 높은 구성요소, 상용 솔루션과 SaaS 연계 구간에서는 암호 사용 방식이 분산되어 있어 한눈에 파악하기 어렵습니다. *NIST: 미국 상무부 산하 표준 기관. 2024년 FIPS 203(ML-KEM), FIPS 204(ML-DSA) 등 첫 PQC 공식 표준을 발표함

따라서 PQC 전환은 알고리즘을 한 번에 교체하는 작업이 아니라, 현재 상태를 기반으로 영향 범위를 파악하고 우선순위를 정해 점진적으로 개선해 나가는 운영 과제 입니다. 그 출발점이 바로 '암호 사용 식별(Discovery)'이며, 결과를 암호 인벤토리로 체계화하는 것이 핵심입니다.

[그림 2] PQC 전환 5단계 프로세스

그림 2는 이 전체 흐름을 5단계로 정리합니다: ① 암호 사용 식별 → ② CBOM 생성 → ③ 인벤토리 구축 → ④ 정책/전환 활용 → ⑤ 지속 관리. 2장에서는 이 중 첫 번째 단계, 즉 DevSecOps 파이프라인 전반에서 암호 사용을 어떻게 식별하는지를 중점적으로 다룹니다. 조직 내부에서 개발, 운영하는 인하우스 애플리케이션은 외부 문서나 명세만으로는 현황 파악이 어렵기 때문에, 코드, 실행, 서비스 프로토콜, 네트워크 네 가지 관점에서 직접 들여다보는 식별 체계가 필요합니다.

2. DevSecOps 환경에서 암호 식별하는 4가지 방법

코드를 수정하다 버그가 생겼을 때, 원인을 찾으려면 코드, 빌드, 배포, 운영 이력을 레이어별로 추적해야 합니다. 암호 취약점 식별도 마찬가지입니다. "어딘가에 취약한 알고리즘이 쓰인다"는 사실을 아는 것과, 그게 소스코드인지, 실행 중인 프로세스인지, 네트워크 통신 구간인지를 정확히 짚는 것은 전혀 다른 문제입니다. 단일 레이어만 봐서는 전체 그림이 그려지지 않습니다.

오늘날 기업 IT 시스템은 DevSecOps 프로세스를 기반으로 개발, 배포, 운영됩니다. 암호 기술 역시 개발부터 운영까지 전 과정에 걸쳐 사용됩니다. 기업 IT 환경을 구성하는 시스템은 크게 인하우스 애플리케이션, 상용 솔루션, SaaS로 나눌 수 있습니다. 상용 솔루션이나 SaaS는 주로 벤더가 암호 설정을 관리하는 반면, 인하우스 애플리케이션은 코드 수준부터 실행 환경까지 조직이 직접 관리해야 합니다.

인하우스 애플리케이션의 암호 사용 현황을 파악하기 위해서는 단계별로 서로 다른 관점의 식별 방법이 필요합니다. 소스코드에 존재하더라도 실제로 실행되지 않는 코드가 있는 반면, 외부 라이브러리나 동적 로딩 구성요소는 런타임에야 확인됩니다. 따라서 정적 분석, 동적 분석, 프로토콜 분석, 패킷 분석이라는 네 가지 기법을 상호 보완적으로 활용하는 접근이 필요합니다.

[그림 3] DevOps 기반 취약 암호 탐지 프레임워크
— 개발·빌드·배포·운영 전 단계 암호 사용 현황 식별 및 자동 탐지

개발(Dev) : 개발, 빌드, 적용(이관)
운영(Ops) : 적용(이관), Runtime

DevOps 기반 취약 암호 탐지 프레임워크를 설명하는 표
개발	빌드	적용(이관)	Runtime	→ 사용자 브라우저, 서버(OpenAPI 등), Cloud
개발자(coding) 소스코드 Coding & 오픈소스 저장소(Git - 내·외부 Lib 등)(Lib.다운로드) → 빌드 →	빌드 결과물 →	배포 →	서비스 인프라 : 스토리지 ↔ DB ↔ WAS ↔ 웹서버 App : 웹서버/WAS(Apache Tomcat, Oracle WebLogic...), DB/스토리지(Oracle, Oracle MySQL...), 기타(Elastic search, Impervo WAF...) 서버 or VM(OS)	→ 사용자 브라우저, 서버(OpenAPI 등), Cloud
소스 코드, 빌드 결과물 → 암호화 API 및 메타데이터(File path, Line no., Function 등) → App, 서버 or VM(OS) → 암호화 API 및 메타데이터( Module path, Function 등) → 서비스 인프라 → 암호화 API 및 메타데이터(Cipher suite. 인증서 등) →				취약암호 자동탐지 기술 : Samsung SDS Crypto Agility Platform for Enterprise (S-CAPE)

2.1. 정적분석으로 암호 API 식별하기

정적 분석은 애플리케이션을 실행하지 않은 채로 소스코드나 빌드 산출물(JAR, 바이너리 등)을 스캔해 암호 알고리즘의 사용 흔적을 찾아냅니다. lint나 SonarQube로 코드 품질을 검사하는 것과 같은 방식입니다. 코드에 포함된 암호 관련 API 호출, 라이브러리 의존성, 알고리즘 식별자, 파라미터 설정 등이 주요 탐지 대상입니다.

Java 환경에서는 JCA(Java Cryptography Architecture, Java 암호화 표준 API 프레임워크) API 사용 여부를 확인하거나, Bouncy Castle(Java 및 C# 환경에서 폭넓게 사용되는 오픈 소스 암호화 라이브러리) 같은 외부 암호 라이브러리의 참조 패턴을 분석할 수 있습니다. 단순 문자열 검색을 넘어 Cipher.getInstance("AES/CBC/PKCS5Padding") 같은 호출을 AST(Abstract Syntax Tree, 소스코드를 트리 구조로 표현해 문법적 의미까지 분석하는 방식) 기반으로 해석하면 알고리즘, 운용 모드, 패딩 방식까지 함께 파악할 수 있습니다. 이 방법은 코드 전반을 폭넓게 탐색해 암호 사용 가능성이 있는 지점을 빠르게 식별하는 데 강점이 있습니다.

2.2. 동적 분석으로 런타임 암호 사용 현황 파악하기

소스코드 정적 분석만으로는 파악하기 어려운 영역이 있습니다. 소스코드에는 분기 조건에 따라 실행되지 않는 코드가 존재하고, 외부 설정 파일이나 DB 값에 따라 런타임에 비로소 결정되는 암호 설정도 있기 때문입니다. 정적 분석이 코드 리뷰라면, 동적 분석은 프로파일러를 붙여놓고 실제 실행 흐름을 직접 들여다보는 것에 가깝습니다.

동적 분석은 애플리케이션이 실제로 실행되는 환경(Test, Staging, Production 등)에서 암호 알고리즘 관련 동작을 관찰하는 방법입니다. Java 환경에서는 에이전트(Agent)나 후킹(Hooking, 실행 중인 프로그램의 특정 함수 호출을 가로채 분석하는 기법) 기법을 활용해 JCE(Java Cryptography Extension, JCA를 확장해 더 강력한 암호화 기능을 제공하는 Java 라이브러리) 프로바이더가 로드되는 시점이나 Cipher.init(), Signature.sign() 같은 주요 메서드 호출 시점을 추적할 수 있습니다. 실제 실행 경로를 기준으로 정보를 수집하므로, 외부 구성 정보에 의해 런타임에 결정되는 암호 설정까지 파악할 수 있습니다. 테스트 자동화나 시나리오 기반 실행과 연계하면 분석 범위를 안정적으로 확장할 수 있습니다.

2.3. 프로토콜 분석으로 TLS 암호 설정 점검하기

코드나 런타임 외에, 서비스가 외부에 어떤 암호 설정을 보여주는지도 확인해야 합니다. 터미널에서 curl -v 명령으로 HTTPS 요청을 수행하면 TLS 핸드셰이크(TLS 통신을 시작할 때 클라이언트와 서버가 암호 방식을 협상하는 과정) 과정이 그대로 출력됩니다. 어떤 프로토콜 버전이 협상됐는지, 어떤 암호 스위트(Cipher Suite, TLS 통신에서 키 교환, 인증, 암호화, 해시 알고리즘을 조합한 묶음)가 선택됐는지 한눈에 볼 수 있습니다. 프로토콜 분석은 이 관점을 조직 전체 서비스에 체계적으로 적용하는 방법입니다.

프로토콜 분석은 애플리케이션이 제공하는 서비스 포트(예: 443, 8443)에 외부에서 연결을 시도해, 해당 서비스가 어떤 암호 프로토콜과 설정을 사용하는지 확인합니다. 스캐너가 클라이언트 역할을 수행하면서 다양한 TLS 버전과 암호 스위트 조합을 포함한 ClientHello 메시지를 전송하고, 서버 응답을 분석합니다. 로드밸런서, 웹서버, 보안 장비처럼 서비스 전면에 위치한 구성요소의 통신 설정을 확인하거나, 외부 노출 서비스의 PQC 지원 수준을 점검하는 데 활용됩니다.

2.4. 패킷 분석으로 실제 운영 구간 암호화 통신 확인하기

패킷 분석은 실제 운영 네트워크에서 오가는 트래픽을 직접 들여다봅니다. 네트워크 장애를 디버깅할 때 tcpdump(터미널에서 실시간으로 패킷을 캡처하는 CLI 도구)나 Wireshark(패킷 캡처 및 분석 도구)로 트래픽을 분석하듯, 운영 중인 서비스에서 실제로 어떤 암호화 통신이 이루어지는지 관찰합니다. 프로토콜 분석이 "이 서버가 어떤 암호를 지원하는가"를 묻는다면, 패킷 분석은 "지금 실제로 어떤 암호가 사용되고 있는가"를 답합니다.

구체적으로는 실제 운영 네트워크에서 발생하는 트래픽을 미러링하거나 PCAP(Packet Capture, 네트워크 패킷을 파일 형태로 저장 및 분석하는 방식) 형태로 캡처하여 암호화 통신 현황을 확인합니다. Tshark(터미널 기반 네트워크 패킷 분석 도구)나 Wireshark, 또는 네트워크 보안 장비 로그를 활용해 TLS 핸드셰이크 구간을 분석하며, 협상된 TLS 버전, 암호 스위트, 인증서 정보, 클라이언트 확장 필드(Extensions) 등을 확인할 수 있습니다. 프로토콜 분석과 같이 서비스에 직접 요청을 보내는 방식만으로는 확인하기 어려운 특정 클라이언트의 접속 패턴이나 비표준 포트의 암호화 통신을 식별하는 데 유용합니다.

2.5. 분석 방법별 특징과 활용 관점

위에서 다룬 네 가지 분석 방법은 각각 코드, 실행 환경, 외부 인터페이스, 네트워크 트래픽이라는 서로 다른 영역에서 암호 사용을 드러냅니다. 어느 한 방법만으로는 전체 그림을 그릴 수 없으며, 네 가지 관점을 함께 활용할 때 암호 사용 현황을 입체적으로 파악하고 CBOM 기반 암호 인벤토리를 구축하기 위한 안정적인 근거를 마련할 수 있습니다.

그림 4는 네 방법의 주요 특징을 비교합니다.

[그림 4] 인하우스 애플리케이션의 암호 식별 4가지 방법 비교

분석 방법별 주요 특징 비교 표
분석 기법	분석 대상	주요 강점	주요 산출물
정적 분석	소스코드 및 바이너리 파일	빠르고 광범위한 스캔 높은 재현성 보장	사용 라이브러리 목록 호출 알고리즘 맵
동적 분석	실행 중인 프로세스 및 메모리	실제 실행 경로 확인 정확한 키 길이 파악	런타임 호출 트레이스 실제 사용 암호화 정보
프로토콜 분석	TLS/SSH 등 네트워크 세션	핸드셰이크 과정 분석 지원하는 암호 스위트 파악	지원하는 TLS버전 및 암호 스위트 목록 등
패킷 분석	전체 니트워크 패킷 흐름 및 페이로드	운영시점에서 실제 사용되는 암호 스위트 파악	협상된 암호 스위트, 인증서 정보, 클라이언트 연결 패턴

3. CBOM과 암호 인벤토리: 개념과 구성 방법

패키지 의존성을 관리할 때 사용되는 라이브러리들의 이름만 관리하는 것으로는 부족합니다. 버전, 라이선스, 취약점 여부까지 함께 관리해야 실질적인 보안 대응이 가능합니다. 암호 인벤토리도 마찬가지입니다. "RSA와 AES를 쓴다"는 수준의 목록으로는 PQC 전환에 필요한 의사결정을 지원하기 어렵습니다. 어떤 암호 기술이, 어떤 IT 자산에서, 어떤 목적으로 쓰이는지를 함께 관리해야 합니다.

그러려면 먼저 암호 사용 현황을 구성하는 핵심 개념을 작은 단위부터 짚어볼 필요가 있습니다.

먼저 암호 알고리즘 자산(Cryptographic Algorithm Asset)은 특정 IT 자산에서 사용되는 개별 암호 알고리즘과 그 속성 정보를 의미합니다. 사용된 알고리즘 종류, 키 길이, 운용 모드, 패딩 방식, 해시 함수, 기타 파라미터 등이 여기에 포함됩니다. CBOM(Cryptography Bill of Materials)은 이러한 암호 알고리즘 정보를 일관되게 정의하고 교환하기 위한 구조화된 표현 방식입니다. 실제 구현에서는 BOM(Bill of Materials) 표준을 활용할 수 있으며, CycloneDX는 SBOM 표준을 확장해 CBOM을 명시적으로 지원합니다. 이렇게 정리된 정보는 JSON, XML과 같은 파일 형식으로 표현, 저장, 교환할 수 있어 자동화된 조회와 관리에 적합합니다.

이러한 암호 알고리즘 정보가 IT 자산 정보와 함께 관리되는 단위가 암호 자산(Cryptographic Asset)입니다. 즉, 하나의 애플리케이션이나 컴포넌트 단위에서 SBOM으로 관리되는 자산 정보와 CBOM으로 관리되는 암호 사용 정보를 포함하는 개별 항목이며, 데이터 관리 관점에서는 암호 자산(CA)이 하나의 레코드(row)에 해당합니다.

이런 암호 자산들이 모여 구성된 집합이 암호 인벤토리(Cryptographic Inventory)입니다. 이는 조직 내 시스템과 애플리케이션의 암호 사용 현황을 구조화해 모아둔 것으로, 여러 레코드로 구성된 데이터베이스와 유사하게 이해할 수 있습니다. 마지막으로 이를 저장, 조회, 갱신하며 지속적으로 관리하는 체계가 암호 인벤토리 관리시스템(CIMS: Cryptographic Inventory Management System)입니다. *SBOM(Software Bill of Materials): 소프트웨어 구성요소 및 의존성 정보를 기계 판독 가능한 형식으로 기록한 명세서

3.1. CBOM에 담아야 할 정보

도서관에서 책을 관리할 때를 생각해보면 제목만으로는 부족합니다. ISBN, 저자, 출판사, 판형, 소장 위치와 같은 정보가 함께 정리되어 있어야 검색, 분류, 대출이 가능합니다. CBOM도 이와 비슷합니다. 단순히 “AES를 사용한다”는 정보만으로는 암호 자산을 제대로 식별하고 관리하기 어렵습니다. 어떤 애플리케이션의 어느 모듈이, 어떤 라이브러리를 통해, 몇 비트 키와 어떤 운용 모드로 암호 알고리즘을 사용하는지를 함께 기록해야 비로소 조회, 분석, 관리 가능한 자산 단위가 됩니다.

CBOM에는 다음 범주의 정보를 포함해야 합니다. 자산 식별 정보(애플리케이션명, 컴포넌트명, 소유 조직, 담당자 등), 암호 알고리즘 정보(알고리즘 종류, 키 길이, 운용 모드, 패딩 방식, 해시 함수 등 세부 파라미터), 구현체 정보(사용 라이브러리, 프로바이더, 버전 등 구현 환경 정보), 탐지 근거 정보(분석 방법, 식별 위치인 파일 경로, 라인 번호, 포트 등)가 해당됩니다. 이러한 정보는 단순한 구성 목록을 넘어, 암호 사용 현황을 정확히 이해하고 영향 범위를 분석하기 위한 기반 데이터로 활용됩니다.

3.2. 분석 결과의 정규화와 암호 인벤토리 구성

여러 모니터링 도구가 각기 다른 형식으로 로그를 출력하더라도, 하나의 대시보드에서 활용하려면 공통 스키마로 정규화하는 ETL(Extract-Transform-Load, 데이터를 추출, 변환, 적재하는 처리 과정) 과정이 필요합니다. 암호 인벤토리 구축도 이와 유사합니다. 정적 분석은 파일 경로와 라인 번호 중심의 정보를 제공하고, 패킷 분석은 IP, 프로토콜 버전, 핸드셰이크 정보와 같은 네트워크 관점의 데이터를 제공합니다. 이처럼 형식이 다른 분석 결과를 공통된 CBOM 스키마에 맞춰 정규화해야 비로소 하나의 인벤토리로 묶어 조회하고 관리할 수 있습니다.

예를 들어 정적 분석 결과 특정 JAR 파일에서 Cipher.getInstance("RSA") 호출이 확인되었다면, 이를 CBOM의 알고리즘 항목으로 기록할 수 있습니다. 암호키 길이와 같이 추가 정보가 필요한 항목은 별도로 표시해 관리할 수 있습니다.

3.3. 우선순위 판단을 위한 비즈니스 메타데이터

만약 버그 트래커에 이슈가 200개 쌓여 있는데 severity(심각도) 레이블 없이 생성일 순서대로만 나열되어 있다면, 어디서부터 손대야 할지 알 수 없습니다. 암호 인벤토리도 마찬가지입니다. 기술적 현황만으로는 어떤 시스템을 먼저 전환해야 하는지 우선순위를 정하기 어렵습니다. 데이터 민감도, 외부 노출 여부, 시스템 중요도와 같은 비즈니스 맥락이 함께 있어야 실제 대응 순서를 판단할 수 있습니다.

예를 들어 동일한 RSA-2048 키를 사용하더라도, 내부 테스트 시스템과 외부 금융 API는 전환의 시급성과 영향 범위가 완전히 다릅니다. 이처럼 기술 정보만으로 드러나지 않는 서비스 중요도나 데이터 민감도는 사용자가 제공하는 정보를 통해 보완할 수 있습니다. 더 나아가 CMDB(Configuration Management Database, 조직 내 IT 자산 정보—소유 조직, 역할, 중요도 등—를 관리하는 데이터베이스)와 연계하면 기술 정보와 비즈니스 정보가 결합된 암호 인벤토리를 구성할 수 있으며, 전환 우선순위를 판단할 수 있는 실질적인 운영 데이터로 확장할 수 있습니다.

4. 암호 인벤토리를 정책·조달·전환·운영에 연결하는 방법

테스트 코드 커버리지 리포트가 어떤 코드 경로가 검증되었고 어떤 부분이 아직 검토되지 않았는지를 보여주듯, 암호 인벤토리도 조직의 암호 사용 현황을 운영 관점에서 가시화하는 기준점이 됩니다. 암호 인벤토리를 통해 현재 우리 시스템이 정책 기준에 미달하는지, 신규 도입 제품이 PQC 전환 요구사항을 얼마나 충족하는지, 어떤 시스템을 우선적으로 전환해야 하는지를 데이터로 확인할 수 있습니다. 이처럼 암호 인벤토리는 단순한 현황 목록이 아니라, 정책 수립, 조달 검토, 기존 시스템 전환, DevSecOps 체계와 연계하여, PQC 전환 작업을 실제 실행 가능한 업무로 연결하는 기반 데이터로 활용됩니다.

4.1. 암호 사용 정책 수립과 평가 기준

암호 인벤토리로 현재 사용 현황(As-Is)을 파악했다면, 다음 단계에서는 조직 차원의 목표 상태(To-Be)를 구체적인 규칙으로 정의해야 합니다. 허용 알고리즘, 사용 제한 또는 중단 대상 알고리즘, 요구 보안 수준, PQC 전환을 고려한 프로토콜 및 지원 요건 등이 여기에 포함됩니다. 마치 정적 분석 도구에 규칙을 정의해두면 코드베이스 전체를 한 번에 검사해 기준을 위반하는 항목을 바로 확인할 수 있듯, 정책이 구체적인 규칙으로 정의되어 있으면 암호 인벤토리를 대상으로 쿼리해 정책 미달 항목을 즉시 찾아낼 수 있습니다. 예를 들어 "AES 키 길이는 256비트 이상", "TLS 1.2 미만은 허용하지 않음"이 그 예입니다. 정책은 목표 상태를 정의하는 평가 기준이 되고, 암호 인벤토리는 현재 상태가 그 기준을 얼마나 충족하는지 확인하는 기반 자료가 됩니다.

4.2. 신규 시스템 및 소프트웨어 도입 시점의 활용

새 오픈소스 라이브러리를 도입하기 전에 GitHub Stars, 마지막 커밋 날짜, 라이선스 그리고 CVE 이력을 확인하듯, 새로운 솔루션이나 장비를 도입할 때도 PQC 준비 상태를 사전에 점검해야 합니다. 그렇지 않으면 양자 취약 가능성이 있는 솔루션이 계속 유입되어 나중에 교체해야 할 레거시만 늘어나기 때문입니다.

따라서 솔루션 조달 단계에서 제품의 PQC 대응 수준과 향후 지원 계획을 함께 확인해야 합니다. 신규 솔루션 도입 시 벤더에게 CBOM 제공 가능 여부를 확인하거나, PQC 지원 로드맵을 요청하는 방식으로 사전 검토를 수행할 수 있습니다. 이미 암호 인벤토리 체계가 구축되어 있다면, 신규 도입 제품 정보를 CBOM 형식으로 정리해 기존 인벤토리 및 암호 사용 정책 기준과 비교함으로써 충족 여부와 추가 검토 사항을 사전에 식별할 수 있습니다. 이를 통해 신규 도입 단계에서부터 암호 사용 정책을 일관되게 적용하고, 향후 PQC 전환 부담도 줄일 수 있습니다.

4.3. 기존 시스템 전환 시 우선순위와 협업 방식

레거시 코드 리팩토링을 계획할 때 모든 모듈을 동시에 건드리는 팀은 없습니다. 일반적으로는 트래픽이 몰리는 핵심 경로, 장애나 버그가 반복되는 모듈, 의존성이 복잡하게 얽힌 부분부터 우선순위를 매겨 단계적으로 진행합니다. PQC 전환도 동일한 원칙입니다. CBOM 데이터와 비즈니스 메타데이터를 결합해 "외부 노출 여부 × 데이터 민감도" 매트릭스를 그리면 어디서부터 시작할지 윤곽이 잡힙니다.

기존 시스템 전환은 검토 범위가 넓고 변경 영향도도 크기 때문에 많은 시간과 비용이 소요됩니다. 따라서 모든 시스템을 동시에 전환하기 보다는, 외부에 노출되어 있고 민감한 데이터를 장기간 처리하거나 보관하며, 현재 양자 취약 가능성이 있는 암호 구성을 사용하는 시스템을 우선 검토 대상으로 식별하는 방식이 현실적입니다.

[그림 5] PQC 전환 우선순위 매트릭스 — 위험 기반 평가를 통한 효율적인 PQC 전환 단계 설정

상용 솔루션은 벤더와 협업하여 지원 여부, 패치 일정, 업그레이드 계획을 조율해야 하며, 인하우스 애플리케이션은 내부 개발팀과의 협업이 중요합니다. 이때 단순히 전환 필요성을 전달하는 것보다, 암호 인벤토리를 근거로 변경 대상을 구체적으로 제시하는 것이 효과적입니다. 예를 들어 특정 모듈, 사용 라이브러리와 버전, 적용된 알고리즘 및 키 교환 방식 등을 함께 제시하면 실제 수정 범위와 영향도를 보다 명확하게 공유할 수 있습니다.

4.4. DevSecOps 기반 지속 모니터링

DevSecOps는 개발, 빌드, 배포, 운영으로 이어지는 파이프라인에 보안 검사를 내재화한 접근입니다. 여기에 암호 자산 식별과 암호 인벤토리 갱신까지 통합하면, 암호 인벤토리는 한 번 만들고 방치하는 문서가 아니라 시스템 변화에 맞춰 함께 살아 움직이는 운영 데이터가 됩니다.

예를 들어 코드 변경이나 빌드 시점에는 정적 분석을 수행해 새로운 암호 관련 구성요소의 유입 여부를 확인하고, 운영 단계에서는 프로토콜 분석과 패킷 분석을 통해 실제 서비스 환경의 암호화 통신 상태를 점검해 인벤토리에 반영합니다. 이러한 갱신 과정을 DevSecOps 흐름에 통합해 자동화하면 지속적인 암호 민첩성(Crypto Agility)을 확보할 수 있으며, 새로운 PQC 알고리즘 도입이나 기존 구성 재검토가 필요할 때 영향을 받는 자산을 보다 빠르게 식별할 수 있습니다. *DevSecOps: 개발(Development), 보안(Security), 운영(Operations)을 통합한 소프트웨어 개발 방법론

5. 맺음말

PQC 전환의 본질은 알고리즘 교체가 아니라 가시성 확보에 있습니다. 어떤 암호가 어디에 얼마나 쓰이는지를 파악하지 못한 채로는 전환 범위도, 우선순위도, 비용도 추정할 수 없습니다. 앞에서 살펴본 정적 분석, 동적 분석, 프로토콜 분석, 패킷 분석은 그 가시성을 확보하기 위한 수단이며, CBOM 기반 암호 인벤토리는 그 결과를 조직이 지속적으로 관리할 수 있는 형태로 만드는 구조입니다.

더 중요한 것은 암호 인벤토리가 단순한 목록으로 머물러서는 안된다는 점입니다. 암호 인벤토리가 암호 사용 정책의 평가 기준이 되고, 신규 조달의 검토 근거가 되며, 전환 우선순위를 정하는 데이터가 되고, DevSecOps 파이프라인과 연결되어 지속적으로 갱신될 때 비로소 실질적인 운영 체계로 작동합니다. 식별에서 시작해 정책, 조달, 전환, 운영으로 이어지는 이 흐름이 갖춰져야 PQC 전환은 선언이 아니라 실행 가능한 과제가 됩니다.

삼성SDS R&D센터는 이 흐름을 기술로 구현하는 방향으로 지속적으로 나아가고 있습니다. 앞선 포스트에서 소개한 특허 확보와 국내외 발표 활동에 더해, NIST PQC 전환 프로젝트 참여를 통해 암호 식별 기술을 국제 실무 가이드(NIST SP 1800-38)에 반영했으며, S-CAPE 기술을 통해 식별부터 모니터링까지의 자동화된 전 주기 대응 체계를 DevSecOps 환경에 연계하여 적용하고 있습니다. 알고리즘 원천 연구에서 전환 실행 기술까지, 삼성SDS의 PQC 전략은 개별 기술의 나열이 아니라 단계별로 연결된 하나의 흐름이라 할 수 있습니다.

핵심 요약

PQC 전환은 알고리즘 교체가 아니라 암호 가시성 확보에서 시작됩니다. 조직 내 암호 사용 현황을 파악하지 못하면 전환 범위, 우선순위, 비용을 추정할 수 없습니다.
암호 식별에는 네 가지 관점이 필요합니다. 정적 분석(코드), 동적 분석(런타임), 프로토콜 분석(TLS 설정), 패킷 분석(실제 트래픽)을 상호 보완적으로 활용할 때 인하우스 애플리케이션의 전체 암호 사용 현황을 파악할 수 있습니다.
CBOM 기반 암호 인벤토리 구축은 목록이 아니라 운영 체계입니다. 정책 평가, 신규 조달 검토, 전환 우선순위 결정, DevSecOps 기반 지속 모니터링으로 연결될 때 실질적인 양자내성암호 전환 기반이 됩니다.
삼성SDS S-CAPE는 이 흐름을 자동화합니다. NIST PQC 전환 프로젝트(SP 1800-38B,C) 참여를 통해 검증된 암호 식별 기술로, 식별부터 DevSecOps 기반 지속 모니터링까지 전 주기를 지원합니다

FAQ

A. 양자 컴퓨터가 아직 완성되지 않았더라도 위협은 이미 시작됐습니다. HNDL(Harvest Now, Decrypt Later) 시나리오처럼 지금 암호화된 데이터를 미리 수집해두었다가 양자 컴퓨터가 완성되는 날 한꺼번에 해독하는 공격 방식이 현실적인 위협으로 거론되고 있습니다. 장기 보호가 필요한 데이터를 다루는 조직일수록 지금부터 준비를 시작해야 합니다. HNDL에 대해 더 궁금하시다면 Q9.를 확인하세요.
A. 소스코드에 존재하더라도 실제 실행되지 않는 코드가 있는 반면, 외부 라이브러리나 동적 로딩 구성요소는 런타임 시 확인됩니다. 정적 분석은 광범위한 초기 탐색에 강하고, 동적 분석은 실제 실행 경로를 기준으로 정보를 수집하므로 두 방법을 상호 보완적으로 사용하는 것이 적합합니다.
A. 반드시 동시에 적용할 필요는 없습니다. 정적 분석은 초기 탐색에 적합하고, 동적 분석은 실제 실행 경로 확인에 강점이 있습니다. 프로토콜 분석과 패킷 분석은 네트워크 통신 구간의 암호 현황을 파악하는 데 유용합니다. 조직의 여건에 따라 정적분석부터 시작해 점진적으로 확대하는 방식이 현실적입니다.
A. 단순 암호 알고리즘 목록은 "RSA, AES를 사용한다"는 수준에 그치지만, 암호 인벤토리는 어떤 자산이, 어떤 목적으로, 어느 위치에서 해당 알고리즘을 사용하는지까지 포함합니다. 암호 인벤토리를 CBOM 형식으로 구조화하면 자동화된 정책 평가와 전환 우선순위 결정에 활용할 수 있습니다.
A. CycloneDX 같은 SBOM 표준을 확장하여 암호화 알고리즘 명칭과 함께 키 길이, 운용모드 등 암호화 속성을 포함하는 형태입니다. JSON 또는 XML 포맷으로 표현되며, 자동화된 분석과 시스템 간 교환이 가능한 구조입니다.
A. 벤더에게 CBOM 제공 가능 여부와 PQC 지원 로드맵을 요청하는 방식으로 사전 검토할 수 있습니다. 이미 암호 인벤토리 체계가 갖춰져 있다면 신규 제품의 CBOM을 기존 인벤토리 및 암호 사용 정책과 비교해 충족 여부를 확인할 수 있습니다.
A. 외부 노출 여부, 데이터 민감도, 장기 보존 필요성, 현재 사용 중인 알고리즘의 양자 취약 가능성을 종합해 판단합니다. CBOM 기반 암호 인벤토리에 CMDB의 비즈니스 메타데이터를 결합하면 위험 기반 우선순위 매트릭스를 구성할 수 있습니다.
A. 특정 암호 알고리즘이나 프로토콜에 고착되지 않고, 보안 위협이나 표준 변화에 따라 빠르게 전환할 수 있는 능력을 의미합니다. DevSecOps 파이프라인에 식별-갱신 과정을 통합하면 코드 변경이나 라이브러리 추가 시점에 자동으로 인벤토리가 갱신되어 지속적인 암호 민첩성을 유지할 수 있습니다.
A. HNDL(Harvest Now, Decrypt Later)은 지금 당장 해독하지 못하더라도 암호화된 데이터를 미리 수집해두었다가, 향후 양자컴퓨터가 완성되는 시점에 한꺼번에 복호화하는 공격 방식입니다. 양자컴퓨터가 아직 실용화되지 않았더라도 위협은 이미 시작됐다는 의미입니다. 장기 보호가 필요한 데이터를 다루는 조직일수록 PQC 전환을 지금 준비해야 하는 핵심 근거가 됩니다.
A. S-CAPE(Samsung SDS Crypto Agility Platform for Enterprise)는 삼성SDS R&D센터가 개발한 암호 인벤토리 식별 자동화 기술입니다. 정적 분석, 동적 분석, 프로토콜 분석, 패킷 분석을 DevSecOps 파이프라인에 통합해 인하우스 애플리케이션의 암호 사용 현황을 자동으로 식별하고 CBOM 형식으로 구조화합니다. NIST PQC 전환 실무 가이드(SP 1800-38)에도 해당 기술이 반영되어 있습니다.