암호키까지 뚫린 창업 플랫폼, 8월 재개의 조건

암호화는 있었지만, 열쇠도 같이 있었다

개인정보 유출 사고가 터질 때마다 기관이 가장 먼저 내놓는 해명은 "암호화되어 있었다"는 말이다. 이번 창업지원 플랫폼 사고가 다른 점은 여기에 있다. 암호화 키까지 함께 유출됐다는 사실이 확인되면서, 암호화라는 방어선 자체가 무의미해졌다.

보안 업계에서 이 구조는 오래된 지적 사항이다. 데이터베이스는 암호화하면서 그 데이터를 푸는 키를 같은 서버, 심하면 같은 애플리케이션 설정 파일에 두는 관행 말이다. 키 관리 시스템(KMS)이나 하드웨어 보안 모듈(HSM)로 키를 분리 보관하는 것은 이미 표준에 가까운 요구사항인데, 예산과 일정에 쫓기는 공공 플랫폼 구축 사업에서는 자주 후순위로 밀린다. 결과적으로 암호화는 감사 항목을 채우는 형식적 절차로 전락한다.

'웹 크롤링'이라는 이름의 회색지대

이번 유출에 사용된 수법으로 지목된 것은 웹 크롤링이다. AI 기반 자동 수집 기능이라는 설명이 붙었지만, 본질은 로그인 이후 접근 가능한 화면을 프로그램이 반복 호출해 데이터를 긁어모으는 방식이다. 해킹처럼 시스템 취약점을 뚫는 게 아니라, 정상 권한으로 대량 조회를 반복하는 것이 특징이다.

문제는 이 방식이 기술적으로 '침입'의 외형을 띠지 않는다는 데 있다. 서버 입장에서는 유효한 세션이 정상 API를 호출한 기록만 남는다. 그래서 방화벽이나 침입탐지 시스템은 대체로 이를 걸러내지 못한다. 이를 막으려면 계정당 조회 횟수 제한(레이트 리미팅), 비정상 조회 패턴 탐지, 대량 조회 시 추가 인증 같은 애플리케이션 계층의 통제가 필요하다. 상당수 공공 서비스가 이 계층에서 사실상 무방비 상태라는 점이 이번 사고로 드러났다.

AI가 붙으면서 달라진 난이도

크롤링 자체는 새로운 기술이 아니다. 다만 최근 몇 년 사이 자동화 도구의 문턱이 급격히 낮아졌다. 캡차 우회, 화면 구조 변화에 대한 적응, 사람과 유사한 클릭 간격 생성까지 상용 도구로 처리 가능해졌다. 공격자가 갖춰야 할 기술 수준은 내려가고, 방어자가 구분해야 할 트래픽의 정교함은 올라간 것이다. 공격 비용의 비대칭이 심화됐다는 표현이 정확하다.

진짜 문제는 애초에 모아둔 데이터의 양

유출 사고 조사 과정에서 함께 지적된 것이 개인정보 관리체계 자체다. 보관 기한이 통상 기준보다 길고, 수집 항목의 종류도 과도했다는 평가가 나왔다. 이건 보안 기술의 문제가 아니라 설계 철학의 문제다.

창업 지원 플랫폼은 사업계획서, 재무 정보, 신원 확인 자료, 연락처 등을 한곳에 모은다. 지원 심사에 필요하다는 이유로 수집 범위가 계속 넓어지고, 사후 감사와 통계 활용을 이유로 보관 기간이 늘어난다. 각 단계에는 나름의 명분이 있지만, 합쳐놓으면 고밀도 개인정보 저장소가 된다. 유출 시 피해 규모를 결정하는 것은 결국 이 축적된 총량이다.

개인정보보호법의 최소 수집 원칙과 목적 달성 후 파기 원칙은 이미 존재한다. 문제는 이 원칙이 서비스 기획 단계에서 검토되는 게 아니라, 사고가 난 뒤 감사에서 확인된다는 점이다. 데이터 최소화는 보안팀이 아니라 기획팀의 업무여야 한다.

8월 재개, 무엇을 봐야 하나

플랫폼은 보안을 보강해 8월 2차 서비스를 시작한다. 재개 자체를 비판할 일은 아니다. 창업 지원 창구가 장기간 멈춰 있는 것도 정책적으로 비용이기 때문이다. 다만 재개 발표에서 확인해야 할 항목은 분명하다.

첫째, 암호화 키가 데이터와 물리적·논리적으로 분리 보관되는지다. 둘째, 계정 단위 조회 한도와 이상 패턴 탐지가 실제로 작동하는지다. 셋째, 수집 항목이 실제로 줄었는지, 보관 기한이 단축됐는지다. 앞의 두 가지는 기술 투자로 해결되지만, 세 번째는 조직이 데이터에 대한 욕심을 내려놓아야 가능하다. 그래서 가장 어려운 건 세 번째다.

공공 플랫폼 전반에 던지는 질문

이 사고를 개별 플랫폼의 실수로 보면 배울 게 없다. 공공 디지털 서비스는 대체로 짧은 구축 기간, 고정된 예산, 낮은 유지보수 비용 구조 위에서 만들어진다. 구축 사업자는 기능 요구사항을 맞추는 데 자원을 쓰고, 로그 분석이나 이상 탐지처럼 눈에 보이지 않는 운영 역량은 계약 범위 밖으로 밀린다.

결국 필요한 것은 사고 후 대응 매뉴얼이 아니라, 발주 단계의 기준 변경이다. 데이터 최소 수집 설계, 키 분리 보관, 애플리케이션 계층 조회 통제를 필수 요구사항으로 명시하고 그만큼의 예산을 배정하는 것. 이번 사고가 남긴 실질적 교훈은 여기에 있다.

참고 자료

암호키마저 뚫린 '모두의 창업'···보안 강화해 8월 2차 시작 — 한경비즈니스