국가공공기관 정보화사업 담당자가 알아야 할 보안적합성 검증 완벽 가이드

국가사이버보안기본지침 제5절 쉽게 이해하기

국가·공공기관에서 정보시스템이나 정보통신제품을 새롭게 도입할 때 가장 많이 접하게 되는 보안 관련 절차 중 하나가 ‘보안적합성 검증’​입니다.

방화벽, 침입방지시스템, 네트워크 보안제품, 접근통제 제품 등 보안기능을 수행하는 제품을 기관에 도입한다고 해서 단순히 제품을 구매하고 설치하는 것으로 끝나는 것은 아닙니다.

특히 국가기관과 공공기관의 정보시스템은 일반 기업의 정보시스템과 달리 국가 중요정보와 행정정보를 처리할 수 있기 때문에, 제품에 구현된 보안기능이 실제 환경에서도 제대로 동작하는지 확인하고 취약점에 대한 대응체계를 갖추는 것이 중요합니다.

「국가사이버보안기본지침」에서는 이러한 절차를 제5절 ‘보안적합성 검증’​에서 규정하고 있습니다.

2026년 5월 1일 개정본에서는 보안적합성 검증 관련 조문과 제출절차에도 일부 변경이 반영되어 있으므로, 과거 자료만 참고하기보다는 최신 지침과 국가정보원 공개자료를 함께 확인하는 것이 필요합니다.

보안적합성 검증이란?

쉽게 말하면 보안적합성 검증은 다음과 같이 이해할 수 있습니다.

“공공기관이 도입하려는 보안기능이 있는 정보통신제품이 기관의 보안환경에서 안전하게 사용할 수 있는지를 확인하는 절차”

국가사이버보안기본지침 제31조는 보안기능이 있는 정보통신제품을 도입하는 경우 실제 적용·운용 이전에 안전성을 확인하기 위해 보안적합성 검증을 받아야 한다고 규정하고 있습니다.

따라서 정보화사업 담당자는 제품 구매 단계에서부터 다음 질문을 검토하는 것이 좋습니다.

• 이 제품에 보안기능이 있는가?

• 해당 제품이 보안적합성 검증 대상인가?

• CC인증 또는 보안기능 확인서 등 별도의 사전 인증·확인 제도가 적용되는가?

• 우리 기관의 실제 운영환경에서 필요한 보안기능을 모두 제공하는가?

• 제품의 버전과 모델이 검증 또는 인증 범위와 일치하는가?

• 제품 도입 후 형상이나 용도가 변경되는 경우 추가 조치가 필요한가?

즉, “제품을 구매할 수 있는가?”와 “기관에서 보안제품으로 운용할 수 있는가?”는 별개의 문제​라는 점을 이해해야 합니다.

누가 보안적합성 검증을 신청하는가?

국가사이버보안기본지침 제32조에 따르면 보안적합성 검증을 받고자 하는 경우 국가정보원장에게 검증을 신청할 수 있으며, 국방부는 자체 검증할 수 있도록 규정​되어 있습니다. 이 내용은 2026년 5월 1일 개정사항이 반영된 부분입니다.

실무적으로는 정보화사업 담당자가 제품의 보안요건을 검토하고 관련 자료를 준비하여 기관의 정보보안 담당부서와 협의하는 방식으로 접근하는 것이 중요합니다.

특히 사업담당자 혼자서 보안적합성 검증을 진행하는 것으로 생각하기보다는 다음과 같이 역할을 나누는 것이 효율적입니다.

정보화사업 담당자

• 도입 제품 및 사업 범위 확인

• 제안요청서의 보안요구사항 반영

• 제품 모델 및 버전 확인

• 사업자 제출자료 관리

• 검증 관련 자료 취합

정보보안 담당자

• 보안적합성 검증 대상 여부 검토

• 보안요구사항 검토

• 검증 신청 절차 지원

• 시험 및 검증 결과에 따른 보안조치 확인

• 운영 이후 취약점 대응 관리

공급업체

• 제품의 보안기능 설명

• 보안기능 구현명세 제공

• 설계 및 운용자료 제공

• 시험에 필요한 기술자료 제공

• 취약점 발생 시 보완조치 지원

어떤 제품이 대상인가?

가장 중요한 부분입니다.

모든 IT제품이 보안적합성 검증 대상이 되는 것은 아닙니다.

지침에서는 보안기능이 있는 정보통신제품을 대상으로 실제 적용·운용 이전에 안전성을 확인하도록 하고 있습니다.

예를 들어 다음과 같은 제품은 사업 초기부터 보안적합성 검증 여부를 검토할 필요가 있습니다.

• 방화벽

• 침입방지시스템(IPS)

• 네트워크 접근통제 제품

• 망간자료전송 제품

• 무선침입방지시스템

• 데이터베이스 접근통제 제품

• 보안관리 제품

• 암호 관련 제품

• 기타 보안기능을 제공하는 정보통신제품

다만 제품 유형별로 CC인증, 보안기능 확인서, 국가용 보안요구사항, 안전성 검증필 제품 목록 등 별도의 도입요건​이 적용될 수 있으므로 단순히 제품 이름만 보고 판단해서는 안 됩니다.

국가정보원은 국가용 보안요구사항과 보호프로파일(PP) 등을 공개하고 있으며, 2024년에도 데이터베이스 접근통제, 무선침입방지시스템, 인터넷전화 방화벽, 침입방지시스템 등에 대한 국가용 보안요구사항 관련 자료를 제공하고 있습니다.

보안적합성 검증과 CC인증은 같은 것일까?

실무에서 자주 혼동하는 부분입니다.

CC(Common Criteria) 인증과 보안적합성 검증은 동일한 절차가 아닙니다.

CC인증은 제품의 보안기능을 정해진 평가기준에 따라 평가·인증하는 제도이고, 보안적합성 검증은 공공기관이 특정 보안기능을 가진 정보통신제품을 실제로 도입·운용하기 전에 안전성을 확인하는 절차라는 점에서 목적과 적용 방식에 차이가 있습니다.

또한 현재 국가정보원은 보안적합성 검증 외에도 보안기능 시험 제도와 국가용 보안요구사항 등을 운영하고 있습니다. 국가정보원 홈페이지에서는 보안기능 시험 관련 제도와 보안요구사항을 별도로 제공하고 있습니다.

따라서 사업담당자는 업체가 단순히

“CC인증을 받았습니다.”

라고 설명하는 것만으로 도입절차가 모두 끝났다고 판단해서는 안 됩니다.

인증의 종류, 인증범위, 제품 모델, 펌웨어·소프트웨어 버전, 실제 사용하려는 보안기능이 인증 범위에 포함되는지 등을 확인해야 합니다.

보안적합성 검증은 어떤 순서로 진행되는가?

전체 흐름을 간단하게 정리하면 다음과 같습니다.

① 제품 및 보안기능 식별
↓
② 보안적합성 검증 대상 여부 확인
↓
③ 보안요구사항 및 도입조건 검토
↓
④ 검증 신청자료 준비
↓
⑤ 검증 신청
↓
⑥ 제출자료 검토
↓
⑦ 보안기능 안전성 시험
↓
⑧ 검증결과 통보
↓
⑨ 필요한 보완조치 수행
↓
⑩ 실제 운영
↓
⑪ 취약점·형상변경·용도변경 관리

중요한 것은 검증이 제품 구매 직전에 갑자기 시작되는 절차가 아니라는 점입니다.

정보화사업의 기획 및 발주 단계에서부터 보안요건을 고려해야 사업 일정 지연을 줄일 수 있습니다.

가장 중요한 것은 ‘신청자료’ 준비

제33조에서는 보안적합성 검증 신청 시 별표 3에서 정한 자료를 제출하도록 하고 있습니다. 또한 국가정보원이 필요하다고 판단하여 추가자료를 요청하는 경우에도 이를 제출해야 합니다.

국가사이버보안기본지침의 별표 3에 제시된 최초검증 신청자료에는 다음과 같은 항목들이 포함됩니다.

주요 제출자료

제품의 작성 주체나 상용제품·자체(용역) 개발 여부에 따라 요구되는 자료가 달라질 수 있습니다.

따라서 사업 초기부터 “검증자료 목록”을 별도의 산출물 관리표로 만들어 관리하는 방법​을 추천할 수 있습니다.

정보화사업 담당자가 제안요청서(RFP)에 꼭 반영해야 할 것

보안적합성 검증이 사업 마지막 단계에서 문제가 되는 가장 흔한 이유 중 하나는 사업 초기에 보안관련 산출물을 명확하게 요구하지 않았기 때문입니다.

따라서 제안요청서를 작성할 때 다음과 같은 내용을 검토할 필요가 있습니다.

제품 관련

• 제품명

• 제조사

• 모델명

• 소프트웨어 버전

• 펌웨어 버전

• 주요 보안기능

보안기능 관련

• 접근통제

• 인증

• 암호화

• 감사로그

• 관리자 권한관리

• 보안정책 설정

• 보안로그 관리

• 침입탐지·차단 기능 등

검증 관련

• 보안적합성 검증에 필요한 자료 제출

• 보안기능 구현명세서 제출

• 운용 설명서 제출

• 설계자료 제출

• 보안기능 점검 지원

• 안전성 시험 대응

• 취약점 보완

• 검증 이후 기술지원

이러한 요구사항을 계약문서에 명확하게 반영해 두면 검증 단계에서 업체가 필요한 자료를 준비하지 못하는 문제를 줄일 수 있습니다.

안전성 시험에서는 무엇을 확인하는가?

제34조에 따르면 국가정보원은 제출된 문서의 적절성을 검토한 후 검증대상 제품의 보안기능 정상 동작 여부 등 안전성을 시험할 수 있습니다. 필요한 경우 검증신청 기관에 추가자료를 요청할 수 있으며, 지침에서는 요청받은 사항을 10일(근무일 기준) 이내에 제출​하도록 규정하고 있습니다.

또한 국가정보원은 관련 시험 업무를 국가보안기술연구소에 의뢰할 수 있습니다. 시험에 필요한 자료가 준비되지 않거나 제품 제출이 지연되는 등의 사유로 시험을 진행할 수 없는 경우 검증절차를 중단하거나 시험 신청을 취소할 수도 있습니다.

따라서 사업담당자는 시험단계에서 필요한 장비와 환경을 미리 준비해야 합니다.

예를 들어 다음을 사전에 확인할 수 있습니다.

• 시험대상 제품이 준비되어 있는가?

• 정확한 모델명과 버전이 확인되는가?

• 시험환경을 구축할 수 있는가?

• 관리자 계정 및 테스트 계정이 준비되어 있는가?

• 테스트용 네트워크가 준비되어 있는가?

• 제품 설정정보를 제공할 수 있는가?

• 보안기능 구현명세와 실제 제품 기능이 일치하는가?

• 업체 기술지원 담당자가 시험에 대응할 수 있는가?

검증결과가 나오면 끝나는 것일까?

아닙니다.

제35조에서는 검증결과를 통보받은 기관이 해당 조치를 실시하고 그 결과를 국가정보원장에게 통보하도록 규정하고 있습니다.

즉,

검증 → 결과 통보 → 필요한 조치 → 조치결과 통보

라는 후속절차가 존재합니다.

따라서 정보화사업 담당자는 검증결과를 단순히 문서로 보관하는 것으로 끝내지 말고 조치사항 관리대장을 만들어 관리하는 것이 좋습니다.

예를 들어 다음과 같이 관리할 수 있습니다.

보안적합성 검증이 끝났다고 영원히 안전한 것은 아니다

이 부분이 매우 중요합니다.

정보보안에서는 검증 완료 = 영구적인 안전성 보장으로 이해해서는 안 됩니다.

제36조는 검증이 완료된 제품에서 새로운 취약점이 발견되는 경우 취약점을 제거하거나 보완하고 그 결과를 통보하도록 규정하고 있습니다.

따라서 운영기관은 제품을 도입한 후에도 다음을 지속적으로 관리해야 합니다.

• 제조사 보안공지 확인

• 취약점 정보 확인

• 보안패치 관리

• 펌웨어 업데이트 관리

• 관리자 계정 관리

• 보안로그 점검

• 보안설정 변경 관리

• 새로운 취약점 발생 여부 확인

즉, 보안적합성 검증은 운영단계의 보안관리와 연결되어야 합니다.

제품의 형상을 변경하면 어떻게 해야 할까?

운영 과정에서 다음과 같은 상황이 발생할 수 있습니다.

• 제품 버전 변경

• 펌웨어 업데이트

• 보안모듈 변경

• 주요 보안기능 변경

• 네트워크 구성 변경

• 제품 구성요소 추가

• 다른 시스템과 연계

• 당초 목적과 다른 용도로 사용

이 경우 단순히 “같은 제품이니까 괜찮겠지”라고 판단하면 안 됩니다.

제37조에서는 보안적합성 검증이 완료된 제품이라도 보안기능 등 형상을 변경하거나 도입 목적 이외의 용도로 운용하려는 경우 국가정보원과 협의하여 재검증 등 필요한 조치를 취하도록 규정하고 있습니다.

따라서 제품 도입 시점부터 형상관리(Configuration Management)​를 함께 운영하는 것이 중요합니다.

재검증이 필요한 경우

국가사이버보안기본지침 별표 3에는 최초검증과 재검증 신청자료를 구분하고 있습니다.

재검증의 경우에도 신청서, 정보통신제품 도입확인서, 보안기능 점검표, 운용점검사항, 변경내용 분석서 등의 자료가 요구될 수 있습니다.

따라서 제품을 변경할 때는 다음과 같은 변경관리 절차를 마련하는 것이 좋습니다.

변경 발생

→ 변경내용 기록

→ 보안기능 영향 분석

→ 기존 검증 범위와 비교

→ 보안담당자 검토

→ 필요 시 국가정보원과 협의

→ 재검증 등 필요한 조치

→ 변경 후 시험

→ 운영 반영

이러한 절차를 마련하면 운영 중 제품 변경으로 인해 보안통제가 약화되는 문제를 예방할 수 있습니다.

실제 정보화사업에서 자주 발생할 수 있는 실수

실수 ① “CC인증 제품이면 무조건 된다”

CC인증 여부만 확인하지 말고 인증범위와 실제 도입제품의 모델·버전·보안기능을 함께 확인해야 합니다.

실수 ② 사업 완료 직전에 검증을 시작한다

검증에 필요한 자료가 부족하면 일정이 지연될 수 있습니다.

따라서 사업계획 → RFP → 계약 → 제품선정 → 시험환경 구축 → 검증자료 준비 단계에서부터 준비하는 것이 좋습니다.

실수 ③ 업체가 알아서 준비할 것이라고 생각한다

보안적합성 검증은 제품업체만의 업무가 아닙니다.

기관은 검증 신청 주체로서 필요한 자료와 절차를 관리해야 하므로 사업담당자와 정보보안담당자, 업체 사이의 역할을 명확히 해야 합니다.

실수 ④ 제품 모델과 인증 모델이 다르다

동일 제조사의 제품이라고 하더라도 모델명이나 하드웨어 구성, 펌웨어 버전 등이 달라질 수 있습니다.

따라서 다음 정보를 정확하게 관리해야 합니다.

제조사 + 제품명 + 모델명 + 버전 + 펌웨어 + 인증정보

실수 ⑤ 검증 이후 변경사항을 관리하지 않는다

검증 완료 후에도 새로운 취약점이 발생할 수 있고 제품의 형상이나 용도가 변경될 수 있습니다.

따라서 검증 결과를 운영관리의 출발점으로 보는 관점이 필요합니다.

정보화사업 담당자를 위한 실무 체크리스트

다음 체크리스트를 사업관리 과정에서 활용할 수 있습니다.

기획단계

• 도입 제품의 보안기능을 식별했는가?

• 보안적합성 검증 대상 여부를 확인했는가?

• 국가용 보안요구사항 적용 여부를 확인했는가?

• 관련 인증 또는 확인제도를 확인했는가?

발주단계

• RFP에 보안요구사항을 반영했는가?

• 검증 관련 제출자료를 요구했는가?

• 업체의 검증 지원 책임을 명확히 했는가?

• 취약점 보완 책임을 계약에 반영했는가?

구축단계

• 실제 도입 모델을 확인했는가?

• 제품 버전을 확인했는가?

• 인증 또는 검증 범위를 확인했는가?

• 보안기능 구현명세를 확보했는가?

• 운용설명서를 확보했는가?

• 시험환경을 준비했는가?

검증단계

• 신청자료를 모두 준비했는가?

• 추가자료 요청에 대응할 수 있는가?

• 시험 대상 제품이 준비되어 있는가?

• 업체 기술지원 담당자가 지정되어 있는가?

운영단계

• 검증결과의 조치사항을 완료했는가?

• 취약점 관리체계를 운영하는가?

• 보안패치와 버전을 관리하는가?

• 형상변경을 관리하는가?

• 용도변경 시 보안영향을 검토하는가?

• 필요 시 재검증 절차를 검토하는가?

보안적합성 검증을 ‘사업 마지막 관문’으로 생각하지 말아야 하는 이유

보안적합성 검증을 사업 종료 직전에 처리해야 하는 행정절차로 생각하면 여러 문제가 발생할 수 있습니다.

가장 대표적인 문제는 일정 지연입니다.

제품 자체는 이미 구매했는데 검증에 필요한 자료가 부족하거나, 실제 제품과 제출자료가 일치하지 않거나, 시험환경이 준비되어 있지 않다면 추가적인 시간이 필요할 수 있습니다.

반대로 사업 초기부터 보안적합성 검증을 고려하면 다음과 같은 장점이 있습니다.

기획단계에서 대상 식별

→ RFP에 보안요건 반영

→ 계약단계에서 자료 제출 의무 명확화

→ 제품선정 단계에서 인증·검증 범위 확인

→ 구축단계에서 시험환경 준비

→ 검증자료 사전 준비

→ 검증 및 조치

→ 안전한 운영

이와 같은 접근이 공공 정보화사업의 보안관리 효율성을 높이는 데 도움이 됩니다.

2026년 기준으로 특히 확인해야 할 사항

국가사이버보안기본지침은 2026년 5월 1일 개정사항을 반영하고 있습니다.

특히 보안적합성 검증 관련 조문에서는 제32조의 제목 및 검증 신청 관련 내용, 제33조의 제출자료, 제34조의 안전성 시험 및 추가자료 제출 등에 개정사항이 반영되어 있습니다.

따라서 과거 블로그 글이나 오래된 업무 매뉴얼만 가지고 업무를 처리하기보다는 현재 시행 중인 국가사이버보안기본지침과 국가정보원에서 최신으로 제공하는 신청서·요구사항·공지사항을 기준으로 확인하는 것이 중요합니다.

국가정보원은 보안적합성 검증 관련 홈페이지에서 검증 공지사항과 보안요구사항을 제공하고 있으며, 보안기능 구현명세서 작성 가이드와 국가용 보안요구사항 관련 자료도 공개하고 있습니다.

보안적합성 검증은 ‘문서’가 아니라 ‘안전한 도입과 운영’을 위한 절차

보안적합성 검증을 한 문장으로 정리하면 다음과 같습니다.

“보안기능이 있는 정보통신제품을 공공기관의 실제 정보시스템에 적용하기 전에 안전성을 확인하고, 이후에도 취약점과 변경사항을 지속적으로 관리하기 위한 보안관리 절차”

정보화사업 담당자가 기억해야 할 핵심은 크게 6가지입니다.

첫째, 대상 여부를 사업 초기에 확인해야 합니다.

둘째, RFP와 계약 단계에서 보안요건과 자료제출 의무를 명확히 해야 합니다.

셋째, 제품의 인증·검증 여부뿐만 아니라 실제 모델과 버전, 보안기능 범위를 확인해야 합니다.

넷째, 검증 신청자료를 사업 완료 직전이 아니라 구축 초기부터 준비해야 합니다.

다섯째, 검증결과에 따른 보완조치를 반드시 완료해야 합니다.

여섯째, 검증 이후에도 취약점·형상변경·용도변경을 지속적으로 관리해야 합니다.

특히 최근 공공기관의 정보시스템은 클라우드, AI, 네트워크 가상화, 다양한 외부 서비스와 연계되는 등 구조가 복잡해지고 있습니다. 따라서 보안제품을 단순히 구매하는 것보다 “어떤 보안기능을 어떤 환경에서 어떤 목적으로 사용하는가”를 중심으로 검증하고 관리하는 접근​이 더욱 중요해지고 있습니다.

공공기관 정보화사업 담당자는 보안적합성 검증을 사업의 마지막 행정절차가 아니라 기획부터 운영까지 이어지는 정보보안 관리 프로세스의 일부로 이해하는 것이 바람직합니다.