개념
보안 SW 는 두 종류의 문을 통과해야 한다
레슨 1~6 은 GS 인증 하나를 끝까지 따라갔다. 그 경로로 충분한 제품이 많다. 그런데 보안 소프트웨어 는 사정이 다르다. 공공 시장에 들어가려면 품질을 보는 문 과 보안 기능을 보는 문 을 함께 지나야 하는 경우가 생긴다.
그리고 이 영역은 제도가 자주 바뀐다. 중복 요건을 줄이려는 방향으로 여러 차례 조정이 있었고, 새 제도가 생겼다. 그래서 이 레슨의 목표는 현재 요건을 외우는 것이 아니다. 제도들이 각각 무엇을 보는지 구조를 이해하고, 우리 제품에 무엇이 필요한지 확인하는 경로 를 손에 쥐는 것이다.
중요한 전제 — 이 레슨에 적힌 제도 내용은 공개 보도와 기관 안내에서 확인된 범위이고, 현행 요건은 반드시 해당 기관의 공개 안내와 조달 등록 기준에서 확인한다(원문 확인). 외운 요건으로 일정을 세우면 거의 틀린다.
네 제도가 보는 것이 다르다
구조를 먼저 가른다.
| 제도 | 보는 것 | 성격 |
|---|---|---|
| GS 인증 | 제품의 품질 — 기능 적합성, 성능 효율성 등 | 품질 인증 |
| CC 인증 | 제품이 주장한 보안 기능 을 선언한 깊이로 검증 | 보안 평가 |
| 보안기능확인서 | 공공 납품용으로 보안 기능을 확인 | 보안 기능 확인 |
| 신속확인제 | 평가 기준이 아직 없는 신기술·융복합 제품의 보안성·기능 적합성 점검 | 보완 제도 |
이 표에서 읽어야 할 것은 "품질" 과 "보안 기능" 은 다른 축 이라는 점이다. GS 인증은 제품이 설명서대로 동작하고 성능이 나오는지를 본다. 보안 기능이 잘 설계되었는지는 보지 않는다. 반대로 CC 는 보안 기능을 깊게 보지만 제품 전체의 품질을 보증하지 않는다. CC 인증이 "안전하다" 는 증명이 아니라 "주장한 기능이 선언한 깊이로 검증되었다" 는 증명 이라는 점은 모듈 63 레슨 6 에서 다룬 그대로다.
신속확인제는 성격이 다르다. 앞의 셋이 "기준에 맞는지 본다" 라면, 신속확인제는 기준이 없는 제품을 위한 길 이다. 신기술·융복합 제품은 평가 기준이 따로 마련되어 있지 않아 공공 도입에 필요한 인증을 받기 어려웠고, 그 공백을 메우려 생겼다. 그래서 이미 CC 인증이나 성능평가, 또는 다른 전용 인증(클라우드 보안 인증, IoT 보안 인증 등) 으로 갈 수 있는 제품은 신속확인 대상이 아니다. 이것이 판정 흐름의 핵심 분기가 된다.
중복이 줄어 온 방향
제도 변화의 방향을 알아 두면 현재 요건을 확인할 때 무엇을 물어야 하는지 알게 된다. 공개 보도로 확인되는 흐름은 이렇다.
조달 등록에서의 중복 완화. 과거에는 정보보호제품을 나라장터에 등록하려면 CC 인증 외에 GS 인증을 추가로 받아야 했다. 2018년 관계 부처 합의로 CC 인증 또는 정보보호제품 성능평가로 GS 인증을 대체 하는 방향이 정해졌고, 법 개정을 통해 시행하기로 했다는 보도가 있다. 현행 조달 등록 기준의 정확한 문장은 조달 기관의 공개 기준에서 확인한다(원문 확인).
공공 납품 경로의 완화. 2022년 1월 1일부터 국가·공공기관에 정보보호제품을 납품할 때 CC 인증 없이 보안기능확인서로도 납품이 가능 해졌다는 보도가 있다. 당시 보도는 대상 제품을 24종으로, 확인서 발급 기간을 평균 39일(이전 평균 170일 대비) 로 전하고, 발급 시험기관을 5곳으로 적고 있다. 대상 제품 종류·발급 기간· 기관 목록은 변동되는 항목이므로 반드시 현행 안내에서 확인한다(원문 확인).
신속확인제의 도입. 2022년 11월 시행이라는 보도가 있고, 2023년 4월에 첫 통과 제품이 발표되었다. 신속확인서의 효력은 발급일로부터 2년 으로 보도되었다. 효력 기간과 갱신 조건은 제도 안내에서 확인한다(원문 확인).
이 흐름에서 QA 가 얻을 실질적 정보는 하나다. "두 제도를 다 받아야 한다" 는 말을 들었을 때 그것이 현행인지 의심해 봐야 한다. 중복을 줄여 온 영역이라, 몇 년 전 경험으로 말하는 사람의 정보가 오래되었을 가능성이 높다.
판정 흐름 — 우리 제품에 무엇이 필요한가
제품 담당자나 QA 가 가장 먼저 만들어야 할 것은 판정 흐름 이다. 아래는 구조이고, 각 분기의 현행 기준은 원문에서 확인한다.
1) 목표 시장을 정한다. 공공인가 민간인가. 공공이면 어느 기관 유형인가. 민간 시장만이면 제도 요구가 크게 줄어든다.
2) 제품 유형이 평가 체계 안에 있는지 확인한다. 우리 제품 유형에 대한 평가 기준(보호 프로파일·국가용 보안요구사항 등) 이 존재하는가.
- 있다 → CC 인증 또는 성능평가 경로를 본다
- 없다 → 신속확인제 경로를 검토한다. 단, 다른 전용 인증으로 갈 수 있는지 먼저 확인한다(클라우드·IoT 등)
3) 납품·조달 요건을 확인한다. 발주 문서와 조달 등록 기준에서 어떤 인증·확인서를 요구하는지 읽는다. 발주 문서가 최종 구속력을 갖는다 — 제도상 대체가 가능해도 발주처가 특정 인증을 명시했다면 그것을 받아야 한다.
4) 품질 인증이 별도로 필요한지 확인한다. 조달 등록 요건에서 GS 인증이 대체되는지, 아니면 별도로 요구되는지. 그리고 발주처가 GS 인증을 평가 가점이나 요건으로 두고 있는지 를 본다. 제도상 불필요해도 가점이 걸려 있으면 사업 판단이 달라진다.
5) 유효기간과 버전 정책을 확인한다. 각 인증·확인서의 효력 기간, 그리고 제품 버전이 올라가면 어떻게 되는지. 이것이 가장 자주 놓치는 항목이고, 아래에서 따로 다룬다.
이 흐름의 산출물은 한 장의 판정표 다. "우리 제품은 공공 목표, 평가 유형 있음, 발주 문서가 CC 요구, 조달 등록은 CC 로 대체 가능, GS 는 가점 항목" 같은 형태로 정리해 두면 경영 판단과 일정 산정의 근거가 된다.
중복을 줄이는 실제 방법 — 산출물 재사용
여러 제도를 거치게 되면 중복 작업이 생긴다. 그런데 중복의 대부분은 시험 자체가 아니라 산출물 이다. 재사용 설계가 가능한 지점은 넷이다.
1) 제품 설명 문서. GS 인증에서 제품설명서가 합격 기준이 된다는 것은 레슨 3 에서 다뤘다. 보안 평가 쪽에서도 제품의 기능·구조·사용 방법을 적은 문서가 요구된다. 같은 원천 문서에서 각 제도의 양식으로 내보내는 구조 를 만들면 두 번 쓰지 않는다. 원천 문서를 하나로 관리하고, 제도별 양식은 추출 규칙으로 둔다.
2) 사용자 지침서. 설치·운영·관리자 매뉴얼은 거의 모든 제도가 요구한다. 다만 요구하는 상세 수준이 다르므로, 가장 엄한 쪽 기준으로 한 번 쓰고 다른 제도에는 그대로 제출하거나 요약해 낸다.
3) 시험 환경과 구성 기록. 환경을 재현 가능하게 기재하는 일(모듈 31 레슨 2)은 어느 제도에서나 같은 요구다. 환경 구성서를 버전 붙은 문서 로 관리하면 여러 제도에서 참조할 수 있다.
4) 결함 조치 이력. GS 인증의 결함 조치 라운드(레슨 5)에서 고친 내용이 보안 평가 쪽 제품 버전에 반영되어야 한다. 반대도 마찬가지다. 두 제도가 서로 다른 버전을 보고 있으면 양쪽에서 문제가 된다 — 아래 버전 문제로 이어진다.
재사용할 수 없는 것도 분명히 해 둔다. 판정 기준과 시험 항목은 제도마다 다르다. GS 인증의 측정량(모듈 33 레슨 4) 과 보안 평가의 보안 기능 요구는 서로 환산되지 않는다. "GS 에서 통과했으니 보안 평가도 통과한다" 는 추론은 없다.
버전이 제도를 흔든다 — 가장 자주 놓치는 지점
여러 제도를 동시에 거치는 제품에서 실무 사고가 가장 많이 나는 곳이 버전 이다.
문제의 구조는 이렇다. 각 인증·확인서는 특정 버전 에 대한 것이다. 그런데 제품은 계속 개발되고, 보안 패치는 미룰 수 없다. 그러면 이런 상황이 생긴다.
- 제도 A 는
v2.3에 대해 받았고, 제도 B 심사는v2.5로 진행 중이다 - 그 사이 발주처에는
v2.4를 납품했다 - 어느 버전이 "인증받은 제품" 인가
이 혼란을 막는 장치는 둘이다.
1) 인증 버전 대장. 어느 제도의 어느 확인서가 어느 버전에 대한 것이고, 유효기간이 언제까지이며, 현재 출하 버전과 어떻게 다른지를 한 표로 관리한다. 열 구성은 — 제도, 문서 번호, 대상 버전, 발급일, 유효기간, 현재 출하 버전, 차이 내용, 재평가 필요 여부.
2) 변경 영향 판정 규칙. 버전이 올라갈 때 각 제도에 대해 재평가·변경 인증이 필요한지를 미리 정한 기준으로 판정한다. 변경 인증의 조건과 범위는 제도마다 다르므로 각 제도 안내에서 확인한다(원문 확인). GS 인증 쪽의 변경 인증과 버전 관리는 레슨 6 에서 다뤘고, 보안 평가 쪽의 변경 처리는 모듈 63 레슨 6 의 변경 영향 분석 양식과 같은 구조다.
여기서 가장 위험한 선택은 "인증 때문에 보안 패치를 미루는 것" 이다. 보안 제품이 알려진 취약점을 안은 채 공공 기관에 깔려 있는 상태가 되고, 그것이 인증의 목적과 정면으로 어긋난다. 판정 규칙을 미리 만들어 두는 이유가 바로 이 선택을 하지 않기 위해서다.
일정 설계 — 순차인가 병행인가
제도 둘 이상을 거쳐야 할 때의 일정 설계다.
순차의 장점 — 앞 제도에서 결함을 고친 버전으로 뒤 제도에 들어가므로 뒤쪽 라운드가 줄어든다. 산출물도 앞에서 만든 것을 다듬어 쓴다.
순차의 단점 — 총 기간이 길다. 각 제도의 리드타임이 더해진다.
병행의 장점 — 총 기간이 짧다.
병행의 단점 — 버전이 갈린다. 한쪽에서 결함을 고치면 다른 쪽이 보고 있는 버전과 달라진다. 그리고 두 제도의 지적이 서로 충돌하는 요구를 할 수 있다.
실무에서 쓰이는 판단 기준은 셋이다.
- 결함이 많이 나올 것으로 예상되면 순차 — 병행하면 버전 관리가 무너진다
- 일정이 촉박하고 제품이 안정적이면 병행 — 단, 버전 동결 기간을 합의한다
- 발주 일정에서 역산해 가장 긴 리드타임을 먼저 시작 — 어느 쪽이든 공통
병행을 택하면 버전 동결(code freeze) 구간을 명시 하는 것이 필수다. 두 제도의 심사 기간이 겹치는 구간에 제품을 고치지 않기로 합의하고, 그 기간에 발견된 결함은 목록으로 쌓아 두고 심사 후 일괄 반영한다. 보안 취약점은 예외로 처리하는 규칙을 함께 정한다.
QA 가 이 영역에서 실제로 하는 일
정리하면 QA 의 기여는 네 가지다.
- 판정표를 만든다. 어느 제도가 왜 필요한지, 근거 문서와 함께
- 산출물 재사용 구조를 설계한다. 원천 문서 하나에서 제도별 양식으로
- 인증 버전 대장을 관리한다. 어느 확인서가 어느 버전에 대한 것인지
- 변경 영향 판정 규칙을 만든다. 보안 패치를 미루지 않기 위해
이 중 3번과 4번이 가장 저평가되어 있다. 인증을 받는 일은 사업 담당이 주도하지만, 받은 뒤에 버전과 유효기간을 추적하는 일은 대개 아무도 하지 않는다. QA 가 그 자리를 채우면 조직에서 대체하기 어려운 역할이 된다.
실무에서 왜 필요한가
보안 소프트웨어 기업에서 인증 관련 사고는 세 가지 모양으로 나타난다.
첫째, 필요 없는 인증을 받는다. 제도가 바뀌어 대체가 가능해졌는데 과거 경험대로 두 제도를 다 받는다. 시간과 비용이 두 배로 들고, 그 기간에 사업 기회를 놓친다. 반대로 필요한 인증을 안 받는 경우 도 있다 — 제도상 대체 가능한데 발주 문서가 특정 인증을 명시했고 그것을 놓친 경우다. 둘 다 판정표 한 장 으로 막힌다.
둘째, 버전이 갈려 납품이 막힌다. 인증은 v2.3 으로 받았는데 출하는
v2.5 다. 발주처가 "인증받은 버전과 다르다" 고 지적하면 그때부터 변경 인증
절차를 알아보게 되고, 납품 일정이 밀린다. 인증 버전 대장이 있으면 사전에 보인다.
셋째, 인증 때문에 보안 패치를 미룬다. 가장 심각하다. 보안 제품이 알려진 취약점을 안은 채 공공 기관에 설치되어 있는 상태를 만든다. 변경 영향 판정 규칙을 미리 만들어 두면 "패치하면 어떻게 되는가" 를 즉시 답할 수 있어 이 선택을 피한다.
세 사고 모두 기술이 아니라 관리 의 문제다. 그리고 세 가지 모두 QA 가 만들 수 있는 문서 한두 장으로 상당 부분 막힌다. 그것이 이 레슨의 실질적 가치다.
채용시장에서의 위치
이 레슨이 겨냥하는 자리는 보안 소프트웨어 기업의 품질·인증 담당 이다. 국내 보안 업계에서 이 역할은 공고 제목이 다양하게 붙는다 — QA, 품질보증, 인증 담당, 사업지원. 공통적으로 요구하는 것은 제도를 읽고 일정을 만드는 능력 이다.
이 자리의 특징은 제도 변화를 따라가는 것 자체가 역량 이라는 점이다. 외운 지식은 몇 년이면 낡고, 확인 경로를 아는 사람은 계속 쓰인다. 면접에서 "CC 인증 절차를 설명해 보세요" 보다 "제도가 바뀌었는지 어떻게 확인하십니까" 가 더 가르는 질문이고, 후자에 답할 수 있는 사람이 적다.
경쟁력이 되는 것은 셋이다. 첫째, 판정할 수 있는 능력 이다. 우리 제품에 무엇이 필요한지를 근거 문서와 함께 한 장으로 정리해 오는 사람은 경영 판단에 직접 기여한다. 둘째, 버전과 유효기간을 추적하는 습관 이다. 아무도 하지 않는 일이라 하는 사람의 가치가 바로 드러난다. 셋째, 보안 패치와 인증 사이에서 판단할 수 있는 능력 이다. "패치하면 인증이 어떻게 되는가" 에 즉시 답하는 사람이 있으면 조직이 위험한 선택을 하지 않는다.
경력 축으로 보면 이 역량은 모듈 25(표준 지도)·32(KOLAS)·63 레슨 6(CC 구조) 와 붙어 하나의 묶음이 된다. 인증·성적서·평가 대응을 함께 다룰 수 있는 사람은 보안·시험인증 업계에서 폭이 넓다.