안녕하세요! 복잡한 기술과 제도의 개념을 가장 명쾌하게 풀어드리는 강사, 저스틴(Justin)입니다.

오늘 함께 다룰 주제는 대한민국 디지털 안보의 핵심 이슈인 “소프트웨어 공급망 보안과 양자내성암호의 연결 규칙”입니다.

먼저 보내주신 기사(하이테크정보, 제이슨 박 외신국장 기고문)의 핵심을 한 문장으로 인용하며 출발해 볼까요? 원문에서는 현재 상황을 이렇게 짚었습니다.

“두 요구를 이어 줄 공통의 서류 양식은 아직 만들어지지 않았다.”
— 하이테크정보 (2026.08.29)

기사의 요지는 명확합니다. 정부는 2028년까지 소프트웨어 부품 목록을 제출받기로 했고, 2035년까지 암호 체계를 양자컴퓨터가 뚫지 못하는 최신 암호로 바꾸라고 법을 만들었습니다. 그런데 정작 ‘어떤 양식으로, 누가, 무엇을 적어 내야 하는지’ 이어주는 다리가 없다는 뜻입니다.

이 말이 도대체 왜 문제가 되는지, 저 저스틴의 방식으로 아주 쉽게 풀어보겠습니다. 감이 잡히시도록 차근차근 들어가 볼까요?

[STAGE 1] Why It Matters: 왜 이 문제가 중요할까요?

여러분이 새 아파트를 샀다고 상상해 보세요.

건설사가 여러분에게 두꺼운 서류 한 장을 건넵니다. 거기엔 콘크리트 어느 회사 것 썼는지, 창틀은 어느 브랜드인지, 배관 파이프는 무엇인지 빽빽하게 적혀 있습니다. 이건 안심이 되죠. 부품 목록이 투명하니까요.

그런데 열쇠를 받으러 가니 관리사무소에서 그럽니다.
“요즘 도둑들은 최첨단 마스터키(양자컴퓨터)를 써서 기존 도어록을 1초 만에 땁니다. 2035년까지 아파트의 모든 자물쇠를 새것으로 바꾸는 계획을 내세요.”

그래서 여러분이 건설사가 준 자재표를 펼쳐 봅니다. 거기엔 딱 한 줄 적혀 있습니다.
현관문: 디지털 도어록 설치 완료.

끝입니다. 이 도어록이 비밀번호 4자리짜리인지, 지문 인식인지, 암호 알고리즘은 10년 전 구형인지 최신형인지 자재표만 봐서는 도무지 알 수가 없습니다.

자물쇠를 바꾸려면 어디에 무슨 자물쇠가 달렸는지 알아야 하는데, 손에 든 종이엔 부품 이름만 덜렁 적혀 있는 셈이죠. 지금 대한민국 정부와 공공기관 소프트웨어가 딱 이 처지에 놓였습니다.

이해되시나요?

[STAGE 2] Unpacking the Core Concept: SBOM과 CBOM의 결정적 차이

이 혼란을 이해하려면 딱 두 가지 핵심 단어만 알면 됩니다. SBOM과 CBOM입니다.

┌────────────────────────────────────────────────────────┐
│ SBOM (Software Bill of Materials: 소프트웨어 자재명세서)     │
│ → "이 프로그램 안에 어떤 부품(오픈소스/라이브러리)이 들어갔는가?"  │
└────────────────────────────────────────────────────────┘
                           ▼
┌────────────────────────────────────────────────────────┐
│ CBOM (Cryptography Bill of Materials: 암호자재명세서)   │
│ → "그 부품 속에 들어있는 '자물쇠(암호 알고리즘/키)'는 무엇인가?" │
└────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────┐

│ SBOM (Software Bill of Materials: 소프트웨어 자재명세서) │

│ → "이 프로그램 안에 어떤 부품(오픈소스/라이브러리)이 들어갔는가?" │

└────────────────────────────────────────────────────────┘

▼

┌────────────────────────────────────────────────────────┐

│ CBOM (Cryptography Bill of Materials: 암호자재명세서) │

│ → "그 부품 속에 들어있는 '자물쇠(암호 알고리즘/키)'는 무엇인가?" │

└────────────────────────────────────────────────────────┘

1. SBOM (소프트웨어 자재명세서)

음식으로 치면 ‘식품 성분표’입니다.
과자 봉지 뒤에 “밀가루(미국산), 팜유(말레이시아산), 코코아분말” 적혀 있는 것과 같습니다.
소프트웨어에서도 “이 프로그램에는 OpenSSL 3.x 버전 부품이 들어갔습니다”라고 적어내는 것이죠.

2. CBOM (암호자재명세서)

하지만 암호는 성분표만으로 부족합니다.
“소금이 들어갔다”는 사실만 알 뿐, 그 소금이 천일염인지 맛소금인지, 얼마나 짠지 모르는 것과 같아요.
CBOM은 바로 그 디테일을 적는 ‘자물쇠 전문 장부’입니다.

어떤 암호 수학 방식을 썼는가? (RSA? AES?)
열쇠 길이는 몇 비트인가? (안전한 길이인가?)
인증서는 언제 만료되는가?
이 자물쇠를 바꾸면 어떤 연동 시스템이 멈추는가?

기사에서 지적하듯, SBOM에 OpenSSL이 적혀 있다고 해서 암호의 안전성을 알 수는 없습니다. 자재표(SBOM)와 별개로, 자물쇠 장부(CBOM)가 반드시 필요한 이유입니다.

어떤 느낌인지 감이 오시나요?

[STAGE 3] Evidence and Application: 두 개의 시계와 사라진 규칙

현재 한국 정책에는 두 개의 시계가 따로 째깍거리고 있습니다. 표로 한눈에 비교해 볼까요?

구분	첫 번째 시계: 조달 공급망 (과기정통부·국정원)	두 번째 시계: 양자내성 전환 (양자기술산업법 제18조의2)
목표 시점	2028년부터 공공 납품 시 단계적 적용	2035년까지 국가 암호체계 전면 전환
요구하는 것	부품 성분표(SBOM) 및 공급망 체크리스트	양자보안체계 구축계획 (암호 전환 준비)
질문의 방향	“너 납품할 때 어떤 부품 썼어?” (공급자 대상)	“너희 시스템 안에 위험한 암호 뭐 있어?” (운영기관 대상)
현재의 공백	암호 세부 스펙(CBOM) 요구 규격이 없음	계획을 세우라면서 구체적 목록 제출 양식이 없음

기사의 분석에 따르면, 정부는 법을 고쳐 기관들에게 “양자보안 대책을 세우라”고 의무를 얹었습니다(양자기술산업법 제18조의2).

하지만 정작 현장에서는 깊은 한숨이 나옵니다.

양식이 없습니다: 엑셀로 내야 합니까? PDF로 내야 합니까? 기계가 자동으로 읽을 수 있는 코드(JSON/XML) 규격이 정해지지 않았습니다.
주체가 모호합니다: 프로그램을 만든 원개발사가 써야 합니까, 납품한 SI(시스템 구축) 업체가 써야 합니까, 클라우드 회사가 써야 합니까?
연결 고리가 없습니다: 2028년에 소프트웨어 부품표(SBOM)를 받아봤자, 거기에 암호 정보가 없으니 2035년 양자암호 전환 계획을 세울 때 아무런 도움이 되지 않습니다.

결국 필요한 것은 거창하고 새로운 법률이 아닙니다.
“SBOM을 적을 때 암호 정보(CBOM)를 이런 형식의 공통 식별자로 함께 적어라”라는 실무적인 연결 규칙(Interface Rule)입니다.

[STAGE 4] Summary and Extension: 핵심 요약과 생각거리

오늘 배운 내용을 세 줄로 요약해 드립니다.

시선의 이동: 정부 보안 정책은 ‘완제품 검사’에서 ‘부품 성분표(SBOM) 확인’으로 이동하고 있습니다.
치명적 빈틈: 부품 목록(SBOM)만으로는 그 안에 든 자물쇠 스펙(CBOM)을 알 수 없어, 2035년 양자내성암호 전환에 써먹을 수 없습니다.
해결책: 법을 새로 만드는 것보다, 부품 목록과 암호 목록을 하나로 이어주는 ‘표준 제출 규격’을 먼저 합의해야 합니다.

[저스틴의 셀프 체크 질문]

강의를 제대로 이해했는지 스스로 확인해 볼까요?

Q1. 왜 오픈소스 부품 이름(예: OpenSSL)이 적힌 SBOM만으로는 양자컴퓨터 공격에 대비한 암호 교체 계획을 세우기 어려울까요?
Q2. 만약 여러분이 공공기관의 보안 책임자라면, 기업들이 각자 자유로운 양식(한글 파일, 엑셀, PDF)으로 암호 목록을 제출했을 때 2035년까지 어떤 실무적 난관에 부딪히게 될까요?