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

PQC(포스트 양자 암호) 전환은 ‘알고리즘 교체’가 아니라 서비스 운영 방식까지 바꾸는 프로젝트다. 보안·플랫폼·개발이 각자 최적화만 하면 정책은 문서로 남고, 적용은 예외로 새는 일이 반복된다. 그래서 처음부터 세 팀이 같은 목표·같은 리듬으로 움직이는 협업 구조를 설계해야 한다.

1) 왜 협업 구조가 먼저인가: 표준, 호환성, 운영이 동시에 흔들린다

PQC는 키 교환(TLS/VPN)과 서명(PKI/코드서명) 영역이 같이 바뀐다. 이때 가장 흔한 실패는 “보안은 금지 목록을 만들고, 플랫폼은 기본값을 못 바꾸고, 개발은 장애가 무서워 미루는” 삼각 지연이다. 

협업 구조를 먼저 잡으면 표준 변경(예: 하이브리드 키 교환), 성능 변화(핸드셰이크 크기·CPU), 장애 모드(재시도·호환성 폴백)를 한 회의에서 같이 판단할 수 있다. 전환은 기능이 아니라 리스크 관리이기 때문이다.

2) 역할은 RACI로 고정한다: 책임 경계가 흐리면 예외가 폭증한다

협업의 핵심은 ‘최종 책임자 1명’이다. 보안 PM 또는 플랫폼 리드 중 한 명을 PQC 프로그램 오너로 지정하고, 의사결정 기록(ADR)과 예외 승인 권한을 묶어준다. 보안팀은 정책(허용 스위트·최소 버전)과 위협모델(다운그레이드, 중간자, 레거시 우회)을 책임지고, 플랫폼팀은 공통 구현(라이브러리·빌드 이미지·게이트웨이)과 자동화(키/인증서 교체, 기능 플래그, 롤백 스위치)를 맡는다. 

개발팀은 서비스별 적용과 배포를 책임지며, 장애 대응을 위해 런북과 지표를 업데이트한다. 중요한 원칙은 예외를 단일 창구에서만 받는 것이다. 예외에는 만료일과 대체 계획이 항상 붙어야 한다.

3) 같이 움직이게 만드는 운영 루틴: 산출물 5개로 대화 비용을 줄인다

세 팀이 같은 문서를 보면 싸움의 주제가 ‘의견’이 아니라 ‘데이터’로 바뀐다. 최소 산출물은 다섯 가지다. 

첫째 크립토 인벤토리(서비스, 라이브러리, 장비, 벤더). 

둘째 호환성 매트릭스(클라이언트·브라우저·프록시 조합). 

셋째 전환 ADR(하이브리드 적용, 폴백 정책, 롤백 조건). 

넷째 테스트 케이스(정상·실패·다운그레이드·성능 회귀). 다섯째 관측 대시보드(핸드셰이크 실패율, 지연, CPU, 재시도율, 인증서 오류). 회의는 주간 워킹그룹으로 블로커를 제거하고, 월간 Go/No-Go에서 KPI로 단계 승인을 한다.

4) 결론

PQC 전환을 성공시키는 협업 구조는 단순하다. 보안은 위험 기준과 예외를 통제하고, 플랫폼은 기본값과 자동화를 제공하며, 개발은 서비스 적용과 점진 배포를 실행한다. 세 팀이 같은 산출물과 같은 지표를 보며 움직이면, 전환은 ‘언젠가 해야 할 일’이 아니라 ‘관리 가능한 변화’가 된다.