창진원 '모두의 창업' 개인정보 유출 사고, API 보안 취약점 예고된 참사

핵심 요약

- 창업진흥원 '모두의 창업' 플랫폼에서 API 보안 취약점을 통한 개인정보 유출 사고 발생 (2026년) - 비공개 설정된 이메일 주소가 특정 API 호출, AI 기반 자동 수집, 웹 크롤링으로 노출 - 사고 한 달 전 보안 경고가 있었음에도 적절한 조치 미흡으로 예견된 사고로 평가

주요 내용

중소벤처기업진흥공단 창업진흥원이 운영하는 '모두의 창업' 플랫폼에서 심각한 개인정보 유출 사고가 발생했다. 개인정보보호위원회에 제출된 사고 신고서에 따르면, 비공개로 설정된 이용자 이메일 주소가 특정 API 호출 및 AI 기반 자동 수집 도구, 웹 크롤링을 통해 외부로 유출된 것으로 확인됐다.

특히 이번 사고는 외부 화면상으로는 표출되지 않았던 개인정보가 API 레벨에서 접근 통제가 제대로 이루어지지 않아 발생한 전형적인 기술적 보안 취약점 사례다. 프론트엔드(화면)에서는 정보를 숨겼지만, 백엔드 API에서는 해당 데이터를 여과 없이 응답하는 구조적 결함이 문제의 핵심이었다.

더욱 심각한 것은 사고 발생 한 달 전 이미 보안 취약점에 대한 경고가 있었음에도 창업진흥원이 적절한 보안 조치를 취하지 않았다는 점이다. 이는 단순한 기술적 실수를 넘어 개인정보 관리 체계의 부실과 보안 거버넌스의 공백을 드러낸 사례로 평가된다.

AI 기반 자동 수집 도구와 웹 크롤링 기술이 고도화되면서 이러한 API 보안 취약점을 악용한 개인정보 수집 시도가 증가하고 있다. 2026년 현재 생성형 AI와 자동화 도구의 발전으로 보안 취약점 탐지 및 악용이 더욱 용이해진 환경에서, 공공기관의 개인정보 보호 역량 강화가 시급한 상황이다.

전문가 시각

ISMS-P 선임심사원 관점에서 볼 때, 이번 사고는 '보호대책 요구사항 2.8.2 (전송 데이터 보호)' 및 '2.9.2 (접근통제 정책 및 절차 수립)'의 이행 부재가 명확한 사례다. API 응답 데이터에 대한 필터링과 최소 권한 원칙이 적용되지 않았고, 사전 보안 경고에 대한 후속 조치 프로세스가 작동하지 않았다는 점에서 관리적·기술적 보호조치 모두 실패했다.

특히 공공기관의 경우 개인정보보호법 제29조(안전조치의무)와 개인정보의 안전성 확보조치 기준을 준수해야 하며, API 설계 단계에서부터 Privacy by Design 원칙을 적용했어야 한다. 화면 비공개와 API 비공개는 별개 영역으로, 두 레이어 모두에서 접근통제가 구현되어야 하며, 정기적인 모의해킹과 보안 취약점 점검이 필수적이다. 2026년 현재 AI 기반 공격 도구가 일반화된 상황에서 전통적 보안 점검만으로는 불충분하며, AI 기반 보안 위협에 대응하는 고도화된 보안 체계 구축이 요구된다.

CPPG·ISMS-P 연계 포인트

API 보안 및 접근통제: ISMS-P 인증기준 2.9.2(접근통제 정책 및 절차)에서 요구하는 최소 권한 원칙과 Need-to-Know 원칙이 API 레벨에서 구현되어야 한다. 프론트엔드 제한만으로는 불충분하며, API 응답 데이터에서 민감정보를 필터링하고, API 호출 시 인증·인가 검증을 다층적으로 수행해야 한다.

사전 경고 대응 체계: ISMS-P 인증기준 2.11.1(취약점 점검 및 조치)에 따라 발견된 보안 취약점에 대한 조치 기한과 책임자를 명확히 하고, 경고 발생 시 즉각적인 위험 평가 및 대응 절차가 문서화되어 운영되어야 한다. 특히 개인정보 관련 취약점은 최우선 처리 대상으로 분류해야 한다.