50억 짜리 암호 교체 프로젝트를 3.8억으로 줄인 비결: A사 PQC 컨설팅 실전 사례

안녕하세요! 강사 저스틴(Justin)입니다.

지난 시간에는 PQC가 무엇인지 이론적으로 알아봤죠? 오늘은 실제 현장에서 벌어지는 생생한 사례를 가져왔습니다.

미국 규제 기관과 한국 정부로부터 “6개월 안에 양자내성암호(PQC) 전환 계획을 내놓으라”는 통보를 받은 핀테크 결제기업 ‘A사’의 이야기입니다.

STAGE 1 — Why It Matters: 데이터는 넘치는데, 왜 결정을 못 내릴까요?

A사 보안팀은 문제를 해결하려고 최신 자동 스캐닝 도구 3종(SCA, SAST, DAST)을 전면 가동했습니다. 그리고 엄청난 양의 보고서를 얻었죠.

그런데 여기서부터 진짜 비극이 시작됩니다. 개발팀과 경영진이 충돌한 것입니다.

제시된 시나리오를 보면 개발팀은 이렇게 주장합니다.

“3년과 50억 원의 예산이 필요하다”

반면 경영진의 반응은 이랬습니다.

“할당 가능한 예산은 4억 원뿐이다”

개발팀은 스캐너가 찾아낸 1,450곳의 암호 코드를 전부 바꾸려면 회사가 휘청거린다고 하고, 경영진은 6개월 뒤 규제 위반으로 사업이 정지될까 봐 발만 굴렀습니다.

왜 이런 일이 벌어졌을까요?

도구는 “여기에 암호가 있다”고 알려줄 뿐, “이 중 무엇이 진짜 위험하고, 무엇부터 바꿔야 하는지”는 알려주지 않기 때문입니다. 데이터는 넘쳐나지만 ‘판정’이 빠져 있었던 것이죠.

STAGE 2 — Unpacking the Core Concept: 응급실 ‘트리아지’와 2축 매트릭스

이 모호한 상황을 해결하기 위해 컨설턴트가 투입되었습니다. 컨설턴트가 사용한 핵심 방법론은 바로 ‘트리아지(Triage, 중증도 분류)’입니다.

종합병원 응급실에 환자 1,000명이 몰려왔다고 해봅시다. 의사가 모든 환자를 온종일 진찰할 수 있을까요? 불가능합니다. 당장 수술하지 않으면 사망하는 중증 환자부터 구분해 내야 합니다.

컨설턴트는 A사의 1,450개 암호 지점을 [위험도]와 [실행 가능성]이라는 2개의 축으로 재배치했습니다.

• 위험도 (Risk): 이 암호가 뚫리면 회사 결제망이 마비되는가? (HNDL 공격 노출 여부)
• 실행 가능성 (Feasibility): 지금 당장 코드를 바꿀 수 있는 구조인가? (벤더 지원 여부)

비유하자면, 스캐너가 찾아낸 1,450개 중 1,100개(75.8%)는 수술이 필요 없는 ‘가짜 환자(호출되지 않는 미사용 코드)’였습니다. 컨설턴트는 이를 즉시 솎아내어 오탐을 제거했습니다.

그리고 실제로 당장 수술해야 하는 ‘구획 I(고위험·고실행성)’ 자산 30개를 정밀 타격 대상으로 선별했습니다.

STAGE 3 — Evidence and Application: A사를 구한 5단계 컨설팅 로드맵

컨설턴트는 이 판정을 바탕으로 5단계 실행 로드맵을 설계했습니다.

1. 1단계: 범위 격리 (Scope Isolation) 전체 50개 시스템 중 규제 대상인 ‘미국 연방 연동 결제 API’ 8개 시스템으로 범위를 물리적으로 격리했습니다. (전체 업무의 80%를 1차 범위에서 제외)
2. 2단계: CBOM 정규화 (Evidence Normalization) 진짜 위험한 암호 자산 350개를 확정하고, 국제 기계판독 표준인 CycloneDX 1.7 CBOM(JSON) 파일로 변환했습니다.
3. 3단계: 2축 우선순위 정렬 (Prioritization) 350개 자산 중 당장 조치할 30개(1순위), 중기 과제 120개(2순위), 보류 100개 등으로 등급을 명확히 나눴습니다.
4. 4단계: 암호 민첩성 설계 (Crypto-Agility) 개발팀이 코드에 새 암호를 하드코딩하지 않도록, 외부 설정 파일만 바꾸면 암호가 교체되는 구조(OpenSSL 3.x Provider)를 도입했습니다.
5. 5단계: 경영진 의사결정서 작성 (Executive Approval) 미전환 자산에 대한 법적 위험 수용(Risk Acceptance) 근거를 문서화하여 규제 기관에 제출했습니다.

📊 정량적 성과 (Data Outcome)

컨설턴트의 판정을 거친 후 A사의 지표는 이렇게 바뀌었습니다.

• 전환 소요 기간: 개발팀 추산 36개월 ➔ 5개월로 단축 (6개월 기한 충족)
• 소요 예산: 초기 추산 50억 원 ➔ 3.8억 원으로 절감 (경영진 예산 4억 원 내 충족)

단순히 소스코드를 고친 것이 아니라, ‘의사결정의 근거’를 만들어 줌으로써 회사를 구한 것입니다.

STAGE 4 — Summary and Extension: 요약 및 스스로 확인하기

오늘 배운 핵심 내용을 요약해 볼까요?

1. 스캐너의 한계: 보안 도구(SAST/DAST)는 현상만 보여줄 뿐 결론을 내려주지 못합니다.
2. 트리아지(Triage): 위험도와 실행 가능성 2축 매트릭스를 통해 진짜 위험한 자산을 솎아내야 합니다.
3. 컨설팅의 가치: 기술적 과제를 경영진이 승인할 수 있는 정량적 로드맵과 예산 범위 내의 계획으로 바꿔주는 것입니다.