PQC 전환을 위한 팀 협업 구조: 보안·플랫폼·개발이 같이 움직이는 방식

PQC(포스트 양자 암호) 전환은 ‘알고리즘 교체’가 아니라 서비스 운영 방식까지 바꾸는 프로젝트다. 보안·플랫폼·개발이 각자 최적화만 하면 정책은 문서로 남고, 적용은 예외로 새는 일이 반복된다. 그래서 처음부터 세 팀이 같은 목표·같은 리듬으로 움직이는 협업 구조를 설계해야 한다. 1) 왜 협업 구조가 먼저인가: 표준, 호환성, 운영이 동시에 흔들린다 PQC는 키 교환(TLS/VPN)과 서명(PKI/코드서명) 영역이 같이 바뀐다. 이때 가장 흔한 실패는 “보안은 금지 목록을 만들고, 플랫폼은 기본값을 못 바꾸고, 개발은 장애가 무서워 미루는” 삼각 지연이다.  협업 구조를 먼저 잡으면 표준 변경(예: 하이브리드 키 교환), 성능 변화(핸드셰이크 크기·CPU), 장애 모드(재시도·호환성 폴백)를 한 회의에서 같이 판단할 수 있다. 전환은 기능이 아니라 리스크 관리이기 때문이다. 2) 역할은 RACI로 고정한다: 책임 경계가 흐리면 예외가 폭증한다 협업의 핵심은 ‘최종 책임자 1명’이다. 보안 PM 또는 플랫폼 리드 중 한 명을 PQC 프로그램 오너로 지정하고, 의사결정 기록(ADR)과 예외 승인 권한을 묶어준다. 보안팀은 정책(허용 스위트·최소 버전)과 위협모델(다운그레이드, 중간자, 레거시 우회)을 책임지고, 플랫폼팀은 공통 구현(라이브러리·빌드 이미지·게이트웨이)과 자동화(키/인증서 교체, 기능 플래그, 롤백 스위치)를 맡는다.  개발팀은 서비스별 적용과 배포를 책임지며, 장애 대응을 위해 런북과 지표를 업데이트한다. 중요한 원칙은 예외를 단일 창구에서만 받는 것이다. 예외에는 만료일과 대체 계획이 항상 붙어야 한다. 3) 같이 움직이게 만드는 운영 루틴: 산출물 5개로 대화 비용을 줄인다 세 팀이 같은 문서를 보면 싸움의 주제가 ‘의견’이 아니라 ‘데이터’로 바뀐다. 최소 산출물은 다섯 가지다.  첫째 크립토 인벤토리(서비스, 라이브러리, 장비, 벤더).  둘째 호환성 매트릭스(클라이언트·브라우저·프록시...

PQC 전환을 위한 데이터 분류 정책: 장기 기밀 데이터부터 지키는 방법

포스트 양자 암호(PQC) 전환은 “모든 암호를 한 번에 교체”가 아니라, 데이터 분류 정책으로 ‘오래 숨겨야 하는 것’부터 보호 순서를 정하는 일이다. 특히 장기 기밀 데이터는 지금 수집해 두었다가(저장) 나중에 해독하는 공격(Harvest Now, Decrypt Later) 위험이 있어, 전환 우선순위의 출발점이 된다.

1) 장기 기밀 데이터 정의: “민감도”보다 “기밀 유지 기간”

데이터 분류 정책에 PQC 관점을 넣을 때 핵심 축은 ‘기밀 유지 기간(Confidentiality Horizon)’이다. 예를 들어 인사기록·의료정보·고객식별정보·소스코드·특허/영업비밀·M&A 문서·장기 계약서처럼 5~10년 이상 가치가 남는 자료는 “장기 기밀”로 별도 등급을 둔다. 

반대로 30일 후 의미가 거의 없는 세션 로그나 일회성 알림은 같은 민감도라도 우선순위가 내려간다. 실무에서는 ISO/IEC 27001의 분류 개념을 바탕으로, (1) 유출 시 피해(규제/평판/매출), (2) 외부 노출 가능 경로(API·메일·협력사·모바일), (3) 보관 기간/법정 보존, (4) 접근 주체 수/권한 폭을 1~5점으로 점수화해 등급을 확정하면 논쟁이 줄어든다. 

그리고 “장기 기밀”에는 자동 만료가 아니라 재분류 리뷰 주기(예: 연 1회)를 강제해, 데이터가 방치되며 위험이 커지는 것을 막는다.

2) 등급별 암호 요구사항 매핑: 전송·저장·서명·키관리까지 한 세트

분류가 끝나면 각 등급에 “암호 적용 범위”를 붙인다. 장기 기밀은 저장 데이터(디스크/오브젝트/백업), 전송 데이터(TLS/VPN), 그리고 서명/인증(코드서명·인증서·업데이트 체인)까지 전부 포함한다. 

정책 문장 예시는 “장기 기밀 등급은 하이브리드 방식(기존 알고리즘+PQC)을 우선 적용하고, 예외는 만료일·대체 통제·책임자를 함께 기록한다”처럼 적는다. 키관리는 더 구체적이어야 한다. NIST SP 800-57의 ‘키 수명’ 개념을 참고해 데이터 보관 기간과 키 교체 주기를 맞추고, 등급이 높은 데이터는 키 분리(서비스/테넌트/환경별), 접근 통제(MFA·승인 워크플로), 내보내기 금지, 백업 키의 보호(HSM/KMS 정책)를 의무화한다. 

또한 “서명은 장기 검증이 필요”하므로, 문서/코드 서명은 타임스탬프·재서명 절차를 정책에 포함해 ‘나중에 검증 불가’ 문제를 예방한다.

3) 전환 실행 루틴: “인벤토리 → 파일럿 → 강제”로 정책을 굴린다

정책은 문서로 끝나면 무용지물이라 운영 루틴이 필요하다. 먼저 시스템 인벤토리에서 “장기 기밀이 어디를 지나가는지” 데이터 흐름도를 만든다(업로드, API, ETL, 백업, 협력사 전송). 다음으로 2~3개 핵심 경로(예: 로그인·결제/정산 API·백업 암호화)를 파일럿으로 잡고, KPI(핸드셰이크 지연, 오류율, CPU), 종료 조건(롤백 기준, 호환성 컷라인)을 붙인다. 

이후 정책 준수는 기술적으로 강제한다: 등급 라벨이 붙은 스토리지는 기본 암호화 미적용을 금지하고, TLS 최소 버전/암호 스위트, 인증서 발급 프로파일, 라이브러리 버전을 표준으로 고정한다. 

마지막으로 크립토 애질리티 항목을 넣어 알고리즘 교체가 가능한 설계(구성 분리, 피처 플래그, 이중검증)를 요구하고, 협력사 계약에도 “암호 요구사항·감사 로그 제공·예외 승인 절차”를 넣으면 경계(Edge)에서 새는 구멍을 줄일 수 있다.

4) 결론

PQC 전환의 시작은 기술 선택이 아니라 데이터 분류 정책이다. 장기 기밀 데이터를 별도 등급으로 정의하고, 전송·저장·서명·키관리 요구사항을 묶어 매핑한 뒤, 인벤토리와 파일럿 운영으로 강제하면 ‘지금 보호해야 할 것’부터 현실적으로 지킬 수 있다.