보안은 제품이 아니라 과업이다 - 왜 보안 발주는 실패하는가 (01/08)

AI 시대의 보안 발주 가이드 · Ep.01

침투는 세 시간이면 끝난다.
방어는 삼 년 전에 결정됐다.

보안은 제품이 아니라 과업이다 · HFC Consulting

---

침해 통보는 아침에 온다. 보안관제가 이상 징후를 올리고, 회의가 소집되고, 누군가 묻는다. 우리 계약서에 이런 상황의 조항이 있습니까.

대개 없다. 있는 것은 과업내용서의 한 줄이다. "보안을 철저히 한다." 이 연재는 그 한 줄이 어떻게 사고 후의 책임 공방으로 자라는지, 그리고 발주 단계에서 무엇을 적어야 했는지를 여덟 편에 걸쳐 다룬다.

사고의 날짜는 발주의 날짜다

2025년 전 국민을 흔든 통신사 USIM 정보 유출의 정부 합동조사 결과를 보면, 최초 침투 시점은 발표로부터 거의 4년 전인 2021년 8월이었다. 악성코드는 28대의 서버에 심어져 있었고, 조사가 지목한 원인은 세 가지였다. 계정 관리 부실, 과거 침해 대응 미흡, 암호화 미흡. 셋 다 특정일의 실수가 아니라 수년에 걸친 체계의 문제, 즉 어떤 보안 과업을 발주하고 무엇을 검수해 왔는가의 문제다.

공격의 속도는 반대 방향으로 움직인다. 올해 다룬 침투에서 탈취까지 세 시간이었다(Brief 27)의 사례처럼, AI를 쥔 공격자는 침투와 탐색과 탈취를 시간 단위로 압축한다. 침해는 세 시간에 끝나는데 방어 체계는 계약으로 고정되어 있다. 이 비대칭이 보안 발주의 출발점이다. 사고 당일 할 수 있는 일은 많지 않다. 할 수 있는 일의 목록은 계약 시점에 이미 닫혔기 때문이다.

"보안을 철저히 한다"는 문장의 가격

보안이 발주 문서에서 다뤄지는 방식은 대체로 둘 중 하나다. 부대 조건이거나, 별첨이거나. 과업범위에는 기능 요구사항이 수백 항목으로 적히지만 보안은 "관련 법령 및 지침을 준수한다" 수준의 선언으로 남는다. 선언은 검수할 수 없다. 검수할 수 없는 요구는 대가산정에도 반영되지 않고, 대가 없는 과업은 수행 현장에서 가장 먼저 밀려난다.

결과는 익숙한 구조다. 사고가 나면 발주자는 "철저히 하기로 했다"를 근거로 책임을 묻고, 수급인은 "요구된 항목은 모두 이행했다"로 맞선다. 둘 다 틀리지 않았다는 것이 이 구조의 비극이다. 요구가 명세되지 않았으므로 이행의 경계도 없었던 것이다. 분쟁의 언어로 옮기면, 보안은 하자담보책임의 범위가 가장 자주 다퉈지는 과업이다.

사후분석 보고서가 가리키는 곳

공식 사후분석들은 놀랄 만큼 같은 곳을 가리킨다. 영국 감사원(NAO)의 WannaCry 조사 보고서를 보면, NHS 산하 236개 트러스트 중 최소 81곳이 감염됐고 1만 9천 건 이상의 진료가 취소됐다. 원인은 신종 공격이 아니었다. 패치되지 않았거나 지원이 끝난 운영체제였다. 경고는 공격 1년 전부터 있었고, 두 달 전에는 긴급 지침까지 내려갔다. 무너진 것은 기술이 아니라 자산 수명과 패치를 관리하는 과업, 그것을 점검하는 체계였다.

미국 사이버안전심의위원회(CSRB)의 2023년 Microsoft Exchange Online 침해 보고서는 더 노골적으로 조달의 문제다. 정부 기관들이 침해를 스스로 탐지하지 못한 배경에 보안 로그가 상위 요금제에 묶여 있던 판매 구조가 있었고, 보고서는 보안에 필수적인 로그를 기본 제공하라고 권고했다. 방어에 필요한 가시성이 옵션 상품이었던 셈이다. 클라우드 약관을 읽는 일이 왜 보안 과업인지를 이보다 잘 보여주는 문서는 없다.

반론 — 보안은 전문 영역이니 보안 솔루션과 전문 업체를 도입하면 되지 않는가.
대응 — 도입은 시작일 뿐이다. 위 사례들의 공통점은 제품의 부재가 아니라 과업의 부재다. 자산 수명 관리, 로그 확보, 계정 통제는 솔루션이 아니라 요구사항과 SLA와 검수기준으로만 계약에 들어간다. 성을 샀다고 성이 지켜지지 않는다. 성문을 누가 언제 잠그는지가 계약서에 있어야 한다.

AI가 위협 지형을 바꿨다

AI 시대의 보안 발주가 과거와 다른 이유는 둘이다. 첫째, 공격자가 AI로 무장했다. 침투 자동화와 악성코드 생성의 문턱이 낮아져 공격의 양과 속도가 함께 늘었다. 둘째, 도입하는 AI 자체가 새로운 공격면이다. 프롬프트 주입, 학습 데이터 유출, 권한을 가진 에이전트의 오동작은 기존 보안 점검표에 없던 항목이다. 정부가 AI를 사는 규격이 공개되기 시작한 지금(Brief 32), 보안 요구는 그 규격의 한가운데로 들어오고 있다. 벤더의 보안 지위 자체가 흔들리는 장면(Brief 31)까지 더하면, 보안은 더 이상 별첨이 될 수 없다.

공공 도메인의 보안 관문(망분리·CSAP·보안성 검토)은 15기 4화에서 다뤘다. 이 연재는 도메인을 가리지 않는 공통 질문으로 간다. 보안이라는 과업을 어떻게 적고, 어떻게 값을 치르고, 어떻게 검수하는가.

이 연재가 가는 길

회차	제목
01	보안은 제품이 아니라 과업이다 - 왜 보안 발주는 실패하는가 (본 편)
02	"보안 철저" 한 줄의 대가 - 보안 요구사항을 과업범위로
03	인증서는 성벽이 아니다 - CSAP, ISMS, 보안성 검토의 조달
04	AI가 바꾼 위협 - 프롬프트 주입은 과업지시서에 없다
05	숫자로 적는 방어 - 보안 SLA와 검수기준
06	사고는 온다 - 침해 대응 조항과 책임의 분기
07	공급망이라는 뒷문 - SBOM과 제3자 위험
08	지키는 성은 계약으로 쌓인다 (완결)

발주 단계 보안 점검 체크포인트 — 보안 요구가 과업범위에 항목으로 존재하는가 / 보안 과업의 대가가 산정에 반영됐는가 / 로그·가시성 확보가 계약 조건인가 / 자산 수명·패치 관리의 책임자가 적혀 있는가 / 사고 시 통지·협조 조항이 있는가

보안 사고의 날짜는 침투의 날이 아니다. "보안을 철저히 한다"고만 적고 계약서를 덮은 날이다. 다음 편에서는 그 한 줄을 검수 가능한 과업범위로 바꾸는 법부터 다룬다.

본 글은 공개된 조사·감사 보고서와 보도를 근거로 작성된 일반적인 정보 제공 목적의 글이며, 특정 사안에 대한 법률 자문이 아닙니다. 구체적인 계약·분쟁 사안은 전문가의 자문을 받으시기 바랍니다.

📎 더 읽을거리

NAO, Investigation: WannaCry cyber attack and the NHS — 지원 종료 OS와 미적용 패치가 국가 의료망을 세운 과정의 공식 기록

CISA, CSRB Review of the Summer 2023 Microsoft Exchange Online Intrusion — 보안 로그가 유료 옵션이었던 구조를 지적한 사후분석

뉴시스, 정부 SKT 해킹 최종 조사결과 발표 — 2021년 침투가 2025년에 발표되기까지, 체계 부실 세 가지의 공식 확인

귀사의 RFP에서 보안은 몇 번째 줄에 있습니까?

HFC컨설팅은 발주 단계의 보안 요구사항 명세, 보안 SLA·검수기준 설계, 침해 대응 조항 정비를 지원합니다. 사고 후의 공방이 아니라 발주 전의 문장을 함께 만듭니다.

changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

---

📚 AI 시대의 보안 발주 가이드 (전 8화)

다음 편 ▶ "보안 철저" 한 줄의 대가 - 보안 요구사항을 과업범위로 (02/08)

연재 전체 보기 →