CDR PoC 가이드 —
샘플 설계부터 판정 기준까지 검증 6단계

PoC는 제품 소개를 한 번 더 듣는 자리가 아니다. 우리 조직의 파일 흐름에서 탐지와 무해화가 실제로 어떻게 동작하는지 측정하고, 그 결과를 증거로 남기는 절차다. 성공 기준 없이 시작한 PoC는 "써 보니 괜찮았다"는 인상만 남기고, 그 인상은 예산 심의나 감사에서 근거가 되지 못한다. 이 CDR PoC 가이드는 범위 설정, 샘플셋 설계, 탐지·무해화·성능·운영 측정, 판정까지 여섯 단계로 나눠 단계마다 무엇을 어떻게 재고 어떤 기준으로 합격을 정할지 정리한다. 근거는 공개된 보안 테스트 방법론(NIST, AMTSO), 공격 기법 분류(MITRE ATT&CK), 파일·메일 포맷 표준, 시큐레터 공식 자료다.

보안 제품을 검증하는 방법은 크게 셋이다. 인증 시험, BMT, PoC다. 셋은 묻는 질문이 다르고, 그래서 하나가 다른 하나를 대신하지 못한다.

인증 시험은 공인기관이 정한 샘플과 조건에서 제품 성능을 확인한다. 시큐레터가 KISA 인증에서 받은 악성코드 탐지율 100%, TTA GS 인증 시험에서 실측한 분석 시간 12초^[1]가 여기에 해당한다. 인증은 제품이 정해진 시험을 통과했다는 객관적 근거다. 다만 시험 샘플은 우리 조직으로 들어오는 파일과 같지 않고, 시험 환경은 우리 메일 서버나 망연계 구간과 다르다. 어떤 탐지 기술도 모든 위협을 잡아낸다고 보장할 수 없다는 점도 함께 기억해야 한다.

BMT는 복수의 후보 제품을 같은 조건에 놓고 비교한다. 후보군을 좁히는 데 유용하다. 반면 PoC는 특정 후보가 우리 환경에서 우리가 정한 목표를 달성하는지 확인한다. 이 글은 PoC에 집중하며, 다음 세 질문을 축으로 삼는다.

1. 위협 질문 — 우리 유입 경로로 실제 들어오는 유형의 악성 파일을 찾아내거나 무력화하는가.
2. 업무 질문 — 처리를 거친 정상 문서가 그대로 열리고, 읽히고, 편집되는가.
3. 운영 질문 — 지연, 예외 처리, 로그, 장애 대응을 현재 인력으로 감당할 수 있는가.

PoC는 '제품이 좋다'를 확인하는 행사가 아니라 반증 가능한 가설을 검증하는 실험으로 설계해야 한다. "외부 메일 첨부 HWP·OOXML 문서에서, 정상 문서의 열림 실패율을 합의 기준 이하로 유지하면서, 회피형 샘플을 포함한 악성 샘플을 탐지 또는 무해화한다" 같은 문장이 가설이다. 이 문장의 각 요소가 이후 단계의 측정 항목이 된다.

PoC 범위는 "어떤 제품을 시험할까"가 아니라 "어떤 경로로 들어오는 파일을 보호할까"에서 출발한다. 경로가 정해져야 샘플, 측정 지점, 성공 기준이 정해진다. 대표 경로는 외부 이메일 첨부, 망연계를 통한 내·외부망 자료 전송, 웹게시판·민원 창구 업로드, 협력사와의 파일 교환이다. 이메일이 악성코드의 주요 1차 전파 경로로 꼽히는 만큼^[1], 메일 경로를 첫 범위로 잡는 조직이 적지 않다. 다만 망연계나 민원 업로드가 핵심 업무 경로라면 그쪽이 우선이다. 공격 기법 분류로 보면 첨부파일 기반 스피어피싱은 MITRE ATT&CK에서 독립 기법(T1566.001)으로 정리되어 있다^[7].

경로가 정해지면 제품 배치를 맞춘다. 시큐레터 제품은 제품마다 탐지 구성이 다르다. 이 차이를 모른 채 평가표를 만들면, 제품에 없는 기능을 평가 항목에 넣거나 있는 기능을 빠뜨리게 된다.

탐지 엔진 MARS는 자동화된 리버스 엔지니어링으로 문서를 어셈블리 수준까지 분해해, 악성 행위가 일어나기 전에 취약점의 근원을 찾아낸다. 탐지 범위는 문서형에 국한되지 않는다. 문서·이미지·압축 파일은 리버스 엔지니어링으로, 실행 파일은 백신·YARA·평판 분석으로 탐지한다. 따라서 SLF·SLE PoC에서는 리버스 엔지니어링 탐지를 평가 항목에 넣는 것이 맞다. 반면 SLCDR은 CDR 전용 제품이라 리버스 엔지니어링 기반 APT 탐지가 없다. SLCDR PoC의 탐지 항목은 백신·YARA·평판 결과로 한정하고, 평가 비중을 무해화 품질과 처리량에 둔다. SLCDR을 어느 유입 구간에 둘지는 조직의 경로 구성에 따라 달라지므로, 착수 전에 제품 측에 확인해 PoC 계획서에 배치 구간을 명시한다.

한 번의 PoC에 모든 경로를 넣는 것은 권하지 않는다. 경로가 늘수록 샘플 구성, 측정 지점, 이해관계자가 함께 늘어 기간 안에 의미 있는 표본을 모으기 어렵다. 가장 위험도가 높거나 파일량이 많은 경로 한두 개에 집중하고, 나머지는 결과를 바탕으로 확장 계획에 넣는 편이 판정 품질을 지킨다.

PoC 결과의 신뢰도는 샘플셋이 결정한다. 제품 측이 가져온 샘플만으로 시험하면 제품이 잘 처리하는 파일만 보게 된다. 정상 문서 없이 악성 샘플만 넣으면 오탐과 업무 영향을 볼 수 없다. 샘플은 목적별로 네 묶음으로 나눠 구성하고, 결과도 묶음별로 따로 집계한다.

A 묶음이 가장 중요하다. 업무 영향은 정상 문서에서만 드러나기 때문이다. 부서별로 자주 쓰는 양식을 고루 모으고, 표·수식·차트·각주·도형·하이퍼링크·임베디드 이미지가 들어간 복잡한 문서를 의도적으로 포함한다. OOXML은 ECMA-376 표준이 정의한 패키지 구조를 따르므로^[14], 구조 요소가 다양한 문서를 넣을수록 재생성 품질을 넓게 볼 수 있다. PDF도 단순 텍스트 문서와 양식 필드·주석·전자서명이 있는 문서를 나눠 넣는다. ISO 32000-2가 정의하는 PDF 기능 범위는 넓어서^[17], 조직이 실제로 쓰는 기능 위주로 고르는 것이 현실적이다. 개인정보가 담긴 문서는 비식별화하거나 같은 구조의 대체 문서를 만들어 쓴다.

C 묶음은 PoC의 변별력을 만든다. 원격 템플릿 주입(MITRE ATT&CK T1221)^[9]은 문서 본문에 악성 코드가 없고 열릴 때 외부 템플릿을 불러온다. 가상화·샌드박스 회피(T1497)^[8]는 분석 환경의 흔적을 확인하고 악성 동작을 멈춘다. 이런 샘플은 레드팀이나 보안팀이 승인된 절차에 따라 직접 만들거나, 공개된 연구 샘플을 쓴다. 회피 로직을 넣은 샘플과 넣지 않은 원형 샘플을 짝지어 두면, 회피 기법이 결과를 바꾸는지 직접 비교할 수 있다.

D 묶음은 정책 설계를 검증한다. 확장자와 실제 형식이 다른 파일이 대표적이다. 예를 들어 매크로가 들어간 문서는 application/vnd.ms-word.document.macroEnabled.12 형식인데, 확장자만 바꿔 일반 문서 application/vnd.openxmlformats-officedocument.wordprocessingml.document 처럼 보이게 만들 수 있다. 메일 첨부라면 MIME 헤더의 선언값까지 함께 조작될 수 있다^[16]. 이런 파일을 확장자 기준이 아니라 실제 구조 기준으로 처리하는지가 확인 항목이다.

흔히 쓰는 EICAR 테스트 파일^[10]은 백신 엔진이 연결되어 경보를 내는지 확인하는 용도로 만들어졌다. 탐지 경로가 살아 있는지 점검하는 데는 유용하지만, 문서 내부 구조를 다루는 CDR이나 리버스 엔지니어링 분석 능력을 보여 주지는 않는다. EICAR 결과를 탐지 성능 항목에 넣지 않는다.

샘플 규모는 기간과 경로에 맞춰 정하되, 묶음별 결과가 소수 파일에 좌우되지 않을 만큼 확보한다. 특히 오탐률과 열림 실패율은 분모가 작으면 한두 건으로 수치가 크게 흔들린다. 메일 경로라면 표본 파일과 별도로 실제 트래픽 미러를 함께 쓰는 방법이 있다. 메일 샘플은 첨부만 떼어 넣지 말고 RFC 5322 형식의 메시지 전체(.eml)로 보관하면^[15] 헤더·본문·첨부를 함께 재현할 수 있다.

탐지 검증은 SLF·SLE처럼 MARS 탐지가 탑재된 구성에서 핵심 항목이다. 측정 지표는 단순하지만, 정의를 미리 맞추지 않으면 같은 결과를 두고 해석이 갈린다.

판정 근거는 숫자만큼 중요하다. 같은 '악성' 판정이라도, 어떤 취약점을 노린 것인지, 문서의 어느 부분에 근원이 있는지 보여 주는 리포트는 이후 침해 대응과 위협 공유에 바로 쓰인다. MARS는 문서를 분해해 근본 원인을 보는 방식이므로, PoC에서 리포트가 실제로 그 근거를 담고 있는지 확인하는 것이 맞다.

회피형 샘플(C 묶음)은 방식의 차이가 드러나는 곳이다. 행위 기반(샌드박스) 방식은 파일을 실행해 결과를 관찰한다. 실행 중 생기는 네트워크 연결, 프로세스 생성, 파일 변경을 기록하므로, 알려지지 않은 실행 파일의 행위를 파악하고 침해 지표(IOC)를 뽑아내는 데 강점이 있다. 반면 가상환경을 확인하고 동작을 멈추는 샘플, 일정 시간이 지나야 동작하는 샘플, 사용자의 클릭이나 스크롤이 있어야 동작하는 샘플은 관찰 시간 안에 악성 행위를 보이지 않을 수 있다. 시큐레터는 이런 우회 공격을, 행위의 결과가 아니라 문서 안 취약점의 근원을 분석해 잡는 구조를 택했다. PoC에서는 C 묶음의 회피 로직 포함 샘플과 원형 샘플을 짝지어 넣고, 회피 로직이 판정 결과를 바꾸는지 직접 확인한다.

탐지 결과를 해석할 때 하나 더 기억할 점이 있다. 어떤 탐지 기술도 모든 위협을 잡는다고 보장할 수 없다. 그래서 SLF·SLE는 탐지와 무해화를 함께 쓴다. 탐지가 놓친 파일이라도 무해화를 거치면 능동 요소가 제거된 상태로 전달된다. 따라서 PoC 보고서에는 미탐 샘플 목록과 함께, 그 샘플이 무해화 후 어떤 상태가 되었는지를 같이 적는다. 탐지율 하나만 보고 결론을 내리면 구성 전체의 방어 효과를 과소 또는 과대평가하게 된다.

공개 테스트 방법론도 참고할 만하다. AMTSO의 테스트 프로토콜 표준은 시험 설계·샘플 출처·결과 공개 방식에서 투명성을 강조한다^[11]. 조직 내부 PoC라도 같은 원칙을 적용하면 결과를 제3자에게 설명하기 쉬워진다. 샘플을 어디서 얻었는지, 언제 넣었는지, 판정이 언제 나왔는지를 모두 남기는 것이 출발점이다.

CDR 방식은 일반적으로 파일을 스캔해 매크로, 스크립트, 외부 연결, 임베디드 객체 같은 능동 요소를 찾아내고, 그 요소를 정책에 따라 제거한 뒤, 포맷 표준에 맞는 구조로 문서를 다시 쓰는 흐름으로 동작한다. 악성 여부를 먼저 판정하지 않아도 능동 요소 자체를 걷어 낸다는 점이 탐지와 다르고, 그래서 앞 장에서 본 미탐 샘플도 무해화 경로에서 다시 다뤄진다. 다만 문서를 다시 쓰는 과정이 있는 만큼 결과물이 원본과 얼마나 같은지가 함께 문제가 된다. 따라서 무해화 검증은 두 방향을 동시에 본다. 위협이 남지 않았는가, 그리고 업무에 필요한 것은 남았는가.

첫째 방향은 B·C 묶음으로 확인한다. 무해화 결과물을 다시 탐지 구간에 넣거나 격리 단말에서 열어, 원래 샘플이 가졌던 악성 요소가 남아 있는지 본다. 원격 템플릿 주입 샘플이라면 외부 참조가 남았는지, 매크로 샘플이라면 매크로 저장 영역이 남았는지가 확인 대상이다.

둘째 방향은 A 묶음으로 확인한다. 이 부분이 실제 도입 성패를 가른다. 시큐레터가 제시하는 기준은 원본 레이아웃 100% 보존이며, PoC는 이 기준을 조직의 실제 양식으로 확인하는 자리다. 확인은 담당자 한 명이 눈으로 훑는 것보다, 현업 부서 대표가 자기 부서 양식을 직접 열어 보는 방식이 정확하다.

Office의 인터넷 매크로 기본 차단과 CDR의 관계도 정리해 둘 만하다. Windows용 Office의 일부 앱은 인터넷에서 받은 것으로 표시된 파일의 VBA 매크로를 기본 차단한다^[6]. 다만 이 표시가 붙는지는 파일이 전달된 경로, 압축 해제 도구, 저장된 파일 시스템에 따라 달라지고, 조직은 중앙 정책 배포 도구로 동작을 바꿀 수 있다. 원격 템플릿처럼 매크로가 아닌 기법에는 적용 대상이 다르다. 즉 내장 기능은 특정 조건에서 특정 요소를 막는 장치이고, CDR은 유입 지점에서 파일 자체의 능동 요소를 정책에 따라 제거하는 장치다. PoC에서는 단말 설정과 무관하게 같은 결과가 나오는지를 확인하면 된다.

결과는 등급으로 기록하면 부서 간 비교가 쉽다. 아래 등급 정의는 예시이며, 조직 상황에 맞춰 조정한다.

성능 항목은 숫자가 분명해 보여서 오히려 오해가 잦다. 공식 수치부터 정확히 읽자. 12초는 TTA GS 인증 시험에서 실측한 분석 시간이고^[1], 34ms는 파일 한 건을 무해화하는 데 걸리는 시간이다^[2]. 앞의 값은 분석, 뒤의 값은 무해화 단계를 가리키므로 두 수치를 더하거나 서로 비교해 하나의 처리 시간으로 읽으면 안 되고, 둘 다 각 자료가 밝힌 조건에서 나온 값이다. 사용자가 체감하는 지연은 이 값들에 대기열, 네트워크, 메일 서버나 연동 시스템의 처리 시간이 더해진 결과다. 그래서 PoC에서는 측정 지점을 먼저 정의하고, 조직의 실제 파일로 각 구간을 따로 잰다.

지연은 평균만 보지 않는다. 중앙값과 함께 상위 구간(예: 95번째 백분위)을 같이 기록하면, 평소에는 빠르지만 특정 파일 유형이나 시간대에 느려지는 현상을 잡을 수 있다. 측정은 최소 세 조건에서 한다. 평상시 트래픽, 업무 시작 직후 같은 최대 부하 시간대, 그리고 D 묶음의 대용량·다중 압축 파일이다. 최대 부하를 실제로 기다리기 어렵다면 운영 로그에서 피크 시간대 유입량을 확인해, 그 규모로 샘플을 재생하는 방식으로 재현한다.

처리 속도는 행위 기반 방식과의 구조적 차이가 드러나는 지점이기도 하다. 행위 기반 방식은 관찰 시간을 길게 잡을수록 지연 시간 공격을 더 볼 수 있지만, 그만큼 전달이 늦어지는 교환 관계가 있다. 시큐레터는 샌드박스 방식 대비 10~20배 빠른 처리를 제시한다. PoC에서는 이 비교를 그대로 받아들이기보다, 조직 환경에서 T0→T4를 직접 재고 업무 부서가 받아들일 수 있는 지연 상한과 비교하는 것이 맞다. 그 상한은 1단계에서 합의한 성공 기준에 들어 있어야 한다.

포맷 커버리지도 이 단계에서 함께 확인한다. 시큐레터 제품은 309종 이상의 파일 포맷을 지원한다^[1]. PoC에서 볼 것은 총 개수가 아니라, 조직의 유입 로그에 나타나는 포맷이 모두 처리 대상에 들어가는지, 들어가지 않는 포맷은 어떤 정책(차단·통과·격리)으로 흐르는지다. 유입 로그에서 확장자와 실제 형식 분포를 뽑아 두면 이 확인이 빨라진다.

탐지와 무해화가 기준을 넘어도, 운영팀이 감당하지 못하면 도입 뒤 예외 설정이 쌓이며 보호 수준이 떨어진다. 운영 검증은 PoC 기간 중 실제 관리자가 직접 콘솔을 다루며 일상 업무를 재현하는 방식으로 한다. 제품 측 엔지니어가 대신 조작한 결과는 운영 부담을 보여 주지 않는다.

장애 시 동작은 반드시 실제로 시험한다. 보안 구간이 멈췄을 때 파일을 모두 보류하면 업무가 서고, 모두 통과시키면 보호가 비게 된다. 어느 쪽이 맞는지는 경로의 위험도와 업무 중요도에 따라 다르다. 중요한 것은 정책으로 정한 동작이 실제로 일어나는지, 그리고 장애 기간에 통과한 파일을 나중에 다시 확인할 수 있는지다.

로그 연동은 기존 관제 체계 담당자를 PoC 초기에 참여시켜야 한다. 로그 필드의 의미, 시간 표기 방식, 파일 식별자(해시) 포함 여부를 미리 맞추지 않으면, 연동은 됐는데 관제 규칙에서 쓸 수 없는 상태가 된다. 판정 로그에 해시가 있으면 다른 보안 장비 로그와 같은 파일을 추적할 수 있다.

측정이 끝나면 결과를 하나의 판정으로 묶어야 한다. 흔한 방식은 영역별 점수를 가중 합산하는 것이다. 그런데 합산만 하면 한 영역의 치명적 결함이 다른 영역의 높은 점수에 가려진다. 예를 들어 탐지가 뛰어나도 업무 필수 양식이 열리지 않으면 도입할 수 없다. 그래서 평가 기준표는 가중 점수와 탈락 조건을 따로 둔다.

가중치는 예시다. 메일 경로라면 성능·업무 영향의 비중을 높이고, 망연계 구간이라면 무해화 품질과 증적 비중을 높이는 식으로 조정한다. SLCDR처럼 CDR 전용 제품을 평가할 때는 탐지 영역을 백신·YARA·평판 결과로 좁히고 그만큼 무해화와 성능 비중을 키운다. 어떤 경우든 가중치와 탈락 조건은 측정 전에 확정한다.

지금까지의 내용을 일정으로 묶으면 여섯 단계가 된다. 기간은 경로 수와 샘플 규모에 따라 달라진다. 시큐레터의 구축형 메일 보안 제품 SLE는 PoC 기간을 3주로 설계한다. 아래 단계는 이 정도 기간을 가정한 순서이며, 단계별 산출물을 남기는 것이 핵심이다.

일정이 밀리는 지점은 대개 2단계다. 정상 업무 문서 수집에는 현업 부서의 협조가 필요하고, 개인정보 비식별화에 시간이 든다. 1단계 회의에서 부서별 문서 제출 담당자와 기한을 정해 두면 이 지연을 줄일 수 있다. 반대로 4단계와 5단계는 기간 안에서 일부 겹쳐 진행해도 된다. 운영 관찰은 측정이 진행되는 동안 쌓이는 로그로 함께 할 수 있기 때문이다.

NIST SP 800-115는 보안 시험을 계획·실행·사후 단계로 나누고, 각 단계에서 범위와 규칙을 문서화하도록 권고한다^[12]. 이 CDR PoC 가이드의 1단계 계획서와 6단계 보고서는 그 계획·사후 단계에 해당한다. 공개 방법론의 구조를 따르면, 내부 결재와 외부 감사에서 PoC의 절차적 타당성을 설명하기 쉽다.

PoC가 끝났는데 판정을 내리지 못하거나, 판정을 내렸는데 도입 뒤에 문제가 터지는 경우가 있다. 원인을 거슬러 올라가면 설계 단계의 실수인 경우가 많다. 아래는 앞 단계에서 다룬 원칙을 어긴 전형적인 모습이다.

여기에 하나를 더하자면, 판정 회의에 현업 부서를 부르지 않는 것이다. 무해화 결과물의 품질은 그 문서를 매일 쓰는 사람이 가장 정확하게 판단한다. 보안팀이 '양호'로 본 결과물을 회계 부서가 '수식이 깨졌다'고 보는 일은 흔하다. 현업 대표의 확인 결과를 판정 근거로 기록에 넣는다.

공공기관과 금융기관에서 PoC 보고서는 구매 결정 자료이면서 동시에 규제 대응 증적이 된다. 공공 분야의 국가 망 보안체계(N2SF) 보안 가이드라인은 업무 정보의 중요도에 따라 보안 통제를 적용하는 체계를 제시하며^[3], KISA는 실증 사례를 묶은 사례집을 공개했다^[4]. 금융·민간 영역의 ISMS-P 인증기준에는 악성코드 통제 항목이 있다^[5]. 국제적으로는 NIST SP 800-53의 악성코드 방어 통제(SI-3)가 유입 지점에서의 악성코드 방어를 다룬다^[13].

이들 기준은 공통적으로 "통제가 있다"는 선언보다 "통제가 설계대로 동작한다"는 근거를 요구한다. PoC 보고서는 바로 그 근거가 될 수 있다. 어떤 경로를 보호하기로 했고, 어떤 샘플로 시험했고, 결과가 어땠고, 남은 위험을 어떻게 다루기로 했는지가 모두 들어 있기 때문이다. 보고서를 감사 증적으로 쓰려면 다음 구성을 갖추는 것이 좋다.

미탐·오탐 분석을 숨기지 않는 것이 중요하다. 모든 항목이 완벽하게 나온 보고서는 오히려 설득력이 떨어진다. 한계를 정확히 적고, 그 한계를 어떤 보완 통제나 운영 절차로 다룰지 적은 보고서가 감사에서 더 강한 증적이 된다. 이 CDR PoC 가이드가 탐지와 무해화 결과를 함께 기록하라고 하는 이유도 여기에 있다. 탐지가 놓친 것을 무해화가 어떻게 처리했는지가 구성 전체의 방어 근거이기 때문이다.

도입이 결정되면 PoC 계획서의 성공 기준을 그대로 운영 지표로 옮기는 것을 권한다. PoC에서 쓴 지연 상한, 오탐 처리 시간, 원본 요청 처리 시간을 도입 뒤에도 같은 정의로 측정하면, 운영 첫해의 성과를 PoC 결과와 직접 비교할 수 있다. PoC가 일회성 검증이 아니라 운영 기준선을 만드는 작업이 되는 셈이다.