안녕하세요, 1601 구현민입니다. 제가 조사한 주제는 ‘모두의 창업’ 개인정보 유출 사건입니다.
이 사건은 정부의 창업 지원 플랫폼에서 합격자들의 정보가 새어 나간 일인데, 저는 여기서 통신 기술의 편리함과 그 뒤에 따라오는 위험을 함께 보려고 합니다.
사건 소개부터 원인, 후속 보도, 그리고 앞으로의 대책까지 순서대로 말씀드리겠습니다.
화면에는 핵심만 담았고, 자세한 설명은 말로 보충하겠습니다. 약 10분 정도 걸립니다.
CONTENTS
발표 흐름
사건을 이해하고, 원인을 따져 보고, 대책을 찾는 순서
1 · 무슨 일이 있었나
모두의 창업은 어떤 곳인지, 무엇이 얼마나 유출됐는지
2 · 왜 일어났나
API는 무엇인지, 어디에서 허점이 생겼는지
3 · 그 뒤에 밝혀진 것
경찰 수사, 암호키 유출, 전체 타임라인
4 · 누구의 책임인가
기관과 이용자, 그리고 공공 플랫폼의 신뢰
5 · 무엇을 바꿔야 하나
재발 방지 대책과 우리가 할 수 있는 일
6 · 내 생각과 결론
이 사건이 우리에게 남긴 것
1601 구현민
발표는 크게 여섯 단계로 진행하겠습니다.
먼저 무슨 일이 있었는지 사건을 소개하고, 다음으로 왜 일어났는지 기술적인 원인을 쉽게 설명하겠습니다.
그 다음에는 사건 이후 밝혀진 사실들, 즉 경찰 수사와 암호키 유출 내용을 정리하고, 누구의 책임인지를 따져 보겠습니다.
마지막으로 재발 방지 대책과 우리가 지금 할 수 있는 일을 말씀드리고, 제 생각으로 마무리하겠습니다.
WHY
왜 이 사건을 조사했나
뉴스 속 이름이 내가 써 본 플랫폼이었기 때문입니다.
익숙한 플랫폼
직접 아이디어를 정리해 제출해 본 경험이 있는 곳이었습니다.
내가 입력한 정보
직접 정보를 넣어 봤기에 남의 일로 느껴지지 않았습니다.
공공기관도 예외 아니다
믿고 냈던 정보였지만, 보안이 부족하면 피해는 똑같습니다.
개인정보 보호는 먼 이야기가 아니라 내가 매일 쓰는 서비스의 문제였습니다.
1601 구현민
제가 이 사건을 조사한 이유는 단순합니다. 제 이야기처럼 느껴졌기 때문입니다.
저는 창업 아이디어를 정리해서 온라인으로 제출해 본 경험이 있고, 그때 제 정보를 직접 입력했습니다.
그래서 익숙한 플랫폼에서 개인정보가 유출됐다는 소식이 훨씬 크게 다가왔습니다.
특히 정부가 관련된 서비스라서 더 믿고 정보를 냈는데, 공공기관이 관련돼 있어도 보안이 부족하면 이용자가 그대로 피해를 본다는 점이 충격이었습니다.
STRUCTURE
정보는 어떤 길을 지나갈까
통신은 정보의 이동이다. 이동하는 지점마다 지켜야 할 곳이 생긴다.
인터넷·통신사람과 시스템을 연결
›
온라인 플랫폼신청·제출·결과 확인
›
API정보가 오가는 통로
›
서버 저장개인정보가 모이는 곳
›
보안 관리권한·암호화·점검
통신이 준 편리함
시간과 장소에 상관없이 참여 가능
지역·나이와 무관하게 기회가 열림
결과 확인과 안내가 빠름
함께 온 위험
정보가 한곳에 모여 피해가 커짐
이동 통로에 허점이 생길 수 있음
이용자는 내부를 볼 수 없음
1601 구현민
사건을 이해하려면 정보가 지나가는 길을 먼저 알아야 합니다.
통신을 한마디로 하면 정보가 한 곳에서 다른 곳으로 이동하는 것입니다. 인터넷 위에 온라인 플랫폼이 있고, 그 플랫폼은 API라는 통로로 서버와 정보를 주고받고, 정보는 서버에 저장됩니다.
이 구조 덕분에 우리는 언제 어디서나 신청하고 결과를 확인할 수 있게 되었습니다.
하지만 정보가 이동한다는 건 중간에 틈이 생길 수 있다는 뜻이기도 합니다. 이번 사건은 바로 그 통로에서 벌어졌습니다.
BACKGROUND
‘모두의 창업’은 어떤 곳인가
누구나 창업에 도전할 수 있게 만든 정부의 온라인 지원 플랫폼
아이디어 제출
온라인으로 창업 아이디어 접수
심사·결과 확인
합격 여부와 심사평을 확인
창업 지원
교육·멘토링 등 프로그램 연결
정부 지원 사업
공적 신뢰를 바탕으로 운영
공공성이 높다
국민 누구나 참여할 수 있는 열린 서비스
주는 것이 상품이 아니라 기회와 지원
그래서 더 위험하다
사람들이 의심 없이 정보를 제공한다
참여자가 많은 만큼 사고 피해도 커진다
1601 구현민
‘모두의 창업’은 정부의 창업 지원 프로젝트로, 온라인으로 창업 아이디어를 제출하고 합격 여부와 심사평을 확인하며 여러 지원 서비스를 이용할 수 있게 만든 플랫폼입니다.
특정 회사의 고객만 쓰는 곳이 아니라 국민 누구나 참여할 수 있는 공공성 높은 서비스였습니다.
그런데 여기에 중요한 점이 있습니다. 사람들은 정부가 관련된 서비스일수록 의심하지 않고 정보를 냅니다.
그래서 신뢰가 높고 참여자가 많은 플랫폼일수록, 사고가 났을 때 피해와 충격이 훨씬 커집니다.
WHAT HAPPENED
사건 핵심 요약
자물쇠를 부순 것이 아니라, 문이 열려 있었던 사건
2026년 6월
사건이 알려진 시점
약 5,000명
정보가 유출된 1차 합격자
API 통신
유출이 일어난 지점
무엇이 나갔나
이메일 주소
창업 아이디어 요약
심사평
조사 과정에서 암호키까지 확인
왜 단순 해킹이 아닌가
비밀번호를 알아내 몰래 로그인한 것이 아니라,
API 통신 과정의 보안이 미흡해 보여주면 안 되는 정보까지 함께 나간 사건에 가깝습니다.
1601 구현민
사건의 핵심입니다. 2026년 6월, 모두의 창업 플랫폼에서 1차 합격자 약 5천 명의 정보가 유출된 것으로 알려졌습니다.
유출된 정보에는 이메일 주소, 창업 아이디어 요약, 심사평이 포함돼 있었고, 이후 조사에서 암호키까지 노출된 사실이 확인됐습니다.
여기서 꼭 강조하고 싶은 것은, 이 사건이 단순한 비밀번호 해킹이 아니었다는 점입니다.
누가 자물쇠를 부순 게 아니라 문이 열려 있었던 상황에 가깝습니다. 그래서 기술력의 문제라기보다 관리와 점검의 문제였습니다.
LEAKED DATA
무엇이 유출됐나
‘이름과 주민번호가 아니니 괜찮다’고 말할 수 없는 이유
유출 항목
발생할 수 있는 피해
위험도
이메일 주소
스팸, 피싱 메일, 악성 링크 유도
높음
창업 아이디어
내가 만든 결과물의 노출·도용 위험
매우 높음
심사평
나에 대한 평가가 그대로 공개됨
매우 높음
암호키
암호화된 정보를 다시 읽을 수 있게 만듦
치명적
핵심은 ‘조합’
이메일 하나만 보면 사소해 보입니다. 하지만 이메일 + 아이디어 + 심사평이 묶이면
“당신의 ○○ 아이디어 심사 결과 안내입니다” 같은 진짜처럼 보이는 맞춤형 피싱 메일을 만들 수 있습니다.
1601 구현민
유출된 정보는 이메일 주소, 창업 아이디어 요약, 심사평, 그리고 암호키입니다.
이메일은 단순한 연락처가 아니라 여러 서비스의 아이디로 쓰이기 때문에 피싱으로 이어질 수 있습니다.
창업 아이디어는 직접 만든 결과물이고, 심사평은 나에 대한 평가가 담긴 민감한 정보입니다. 암호키는 잠근 정보를 다시 열게 해 주는 열쇠라 가장 위험합니다.
그리고 가장 중요한 건 ‘조합’입니다. 이 정보들이 묶이면 진짜처럼 보이는 맞춤형 피싱 메일을 만들 수 있습니다. 개인정보는 하나씩보다 묶였을 때 훨씬 위험합니다.
RISK
‘이메일뿐’이어도 심각한 이유
이메일 주소는 공격이 시작되는 출입문이다.
① 이메일 유출주소가 외부로 나감
›
② 스팸·홍보 메일원치 않는 메일 도착
›
③ 피싱 메일공식 안내인 척 속임
›
④ 악성 링크가짜 사이트로 유도
›
⑤ 계정 피해다른 서비스까지 위험
표적이 정해진다
‘1차 합격자’ 명단은 무작위가 아니라 목표가 분명한 표적 목록입니다.
계정과 연결돼 있다
이메일은 대부분 아이디이자 비밀번호 재설정 통로입니다.
불안은 남는다
어디까지 퍼졌는지 알 수 없다는 사실 자체가 피해입니다.
1601 구현민
“이메일 주소만 나갔으면 괜찮지 않나?”라고 생각할 수 있습니다. 저는 그렇지 않다고 봅니다.
화면의 흐름처럼 이메일 유출은 스팸 → 피싱 → 악성 링크 → 계정 피해로 이어질 수 있는 출발점이기 때문입니다.
특히 이번 명단은 ‘1차 합격자’라는 표적이 분명한 목록이라, “합격 관련 안내입니다”라는 메일이 오면 훨씬 쉽게 속게 됩니다.
또 이메일은 대부분의 서비스에서 비밀번호를 재설정하는 통로라서, 뚫리면 다른 서비스까지 위험해집니다.
무엇보다 내 정보가 어디까지 갔는지 알 수 없다는 불안이 남습니다. 이건 숫자로 표현되지 않는 피해입니다.
BEYOND DATA
아이디어와 심사평의 무게
이건 ‘정보’가 아니라 한 사람의 노력과 평가다.
창업 아이디어 = 나의 결과물
시간과 노력을 들여 만든 창작물
아직 공개하지 않은 구상일 수 있음
먼저 알려지면 모방·도용 위험
심사평 = 나에 대한 평가
부정적 평가가 담길 수 있음
본인만 보도록 쓰인 글이 공개됨
성적표가 유출된 것과 비슷한 느낌
허락 없이 공개된 순간, 개인정보를 넘어 개인의 노력과 권리까지 함께 침해됩니다.
1601 구현민
저는 창업 아이디어와 심사평이 유출됐다는 점을 특히 심각하게 봤습니다.
창업 아이디어는 오래 고민해서 만든 결과물입니다. 아직 공개하지 않은 구상이 먼저 알려지면 모방이나 도용 위험이 생깁니다.
심사평은 더 민감합니다. “현실성이 부족하다” 같은 평가가 담길 수 있는데, 이건 본인만 보도록 쓰인 글입니다. 성적표가 유출된 것과 비슷하다고 생각합니다.
그래서 이 사건은 단순한 개인정보 유출이 아니라, 개인의 노력과 권리가 함께 침해된 사건이라고 봅니다.
CAUSE ①
API란 무엇인가
API는 앱과 서버가 정보를 주고받는 식당의 주문 창구와 같다.
손님
우리가 보는 앱·웹 화면
주문 창구
API — 요청을 받고 결과를 돌려줌
주방
서버·데이터베이스 — 정보 보관
사용자 화면“내 결과 보여줘”
›
API 요청권한 확인이 불충분했다면?
›
서버 조회정보를 꺼냄
›
API 응답필요 없는 정보까지 전달
›
외부 수집프로그램으로 대량 수집
문제의 지점 — 창구에서 “이 사람이 이 정보를 받을 자격이 있는가”를 충분히 확인하지 않으면,
화면에 필요 없는 정보까지 함께 나갑니다. 통로가 열려 있으면 수천 건도 순식간에 가져갈 수 있습니다.
1601 구현민
이제 기술적인 원인입니다. 어렵게 들릴 수 있어 식당에 비유하겠습니다.
우리가 보는 화면이 손님이라면, API는 주문 창구이고, 정보가 저장된 서버는 주방입니다. 손님은 주방에 직접 들어가지 않고 창구를 통해 결과를 받습니다.
그래서 가장 중요한 일은 창구에서 “이 사람이 이 정보를 받을 자격이 있는가”를 확인하는 것입니다.
이번 사건에서는 그 권한 확인이 충분하지 않았고, 화면에 필요 없는 정보까지 응답에 담겨 나갔던 것으로 보입니다.
통로가 열려 있으면 사람이 하나씩 볼 필요도 없습니다. 프로그램으로 수천 건을 순식간에 가져갈 수 있습니다. 5천 명 규모 유출이 가능했던 이유입니다.
CAUSE ②
‘화면에 안 보이면 안전’이라는 착각
숨긴 것과 지킨 것은 다르다.
이용자가 보는 화면
이름은 일부만 표시 (구*민)
다른 사람 심사평은 안 보임
→ “비공개구나”라고 믿게 됨
실제 API 응답 안에는
전체 이메일이 들어 있을 수 있음
심사평 전문이 담겨 있을 수 있음
→ 브라우저 도구로 확인 가능
왜 생기나
정보를 한 번에 다 받아 두고 화면에서 골라 보여주는 방식이 편하기 때문입니다.
확인은 쉽다
특별한 해킹 기술 없이도 볼 수 있어, ‘화면에서 가리기’는 대책이 못 됩니다.
그래서 원칙
보호는 화면이 아니라 시스템 내부에서. 애초에 필요한 것만 내보내기.
1601 구현민
많은 사람이 “화면에 안 보이면 안전하다”고 생각합니다. 저도 조사 전까지 그랬습니다.
그런데 화면에 보이지 않는 정보도 서버 안에는 그대로 존재합니다. 화면에는 이름이 별표로 가려져 있어도, API 응답 안에는 전체 정보가 들어 있을 수 있습니다.
이런 일이 생기는 이유는, 개발할 때 정보를 한 번에 다 받아 두고 화면에서 필요한 것만 골라 보여주는 방식이 편하기 때문입니다.
문제는 API 응답이 특별한 기술 없이 브라우저 도구로 확인 가능하다는 점입니다. 그래서 ‘가리기’는 보안이 아닙니다.
개인정보 보호는 화면이 아니라 시스템 내부 구조에서 이루어져야 합니다.
WARNING
한 달 전, 경고가 있었다는 주장
몰라서 못 막은 것과 알고도 못 막은 것은 무게가 다르다.
보도 내용 · 5월 7일
사고 약 한 달 전, “API 응답으로 개인정보가 노출될 수 있다”는
보안 취약점 제보가 있었다는 주장이 제기되었습니다.
제대로 처리했다면
응답에서 불필요한 항목 제거
접속 기록 확인으로 이상 접근 차단
5천 명 유출을 예방할 가능성
조치하지 못했다면
“몰랐다”는 해명이 어려움
실수가 아니라 관리 소홀의 문제
신뢰 회복이 훨씬 어려움
※ 제보 관련 내용은 제보자 측 주장으로 보도된 사항이므로, 확정된 사실이 아니라 ‘주장이 제기되었다’는 점으로 정리했습니다.
1601 구현민
이 사건에서 가장 안타까운 부분입니다. 보도에 따르면 사고 약 한 달 전인 5월 7일에 “API 응답으로 개인정보가 노출될 수 있다”는 보안 취약점 제보가 있었다는 주장이 나왔습니다.
이건 제보자 측 주장으로 보도된 내용이라, 저는 ‘그런 주장이 제기되었다’는 선에서 말씀드리겠습니다.
다만 만약 사실이라면 사건의 성격이 달라집니다. 몰라서 못 막은 것과 알고도 못 막은 것은 책임의 무게가 다르기 때문입니다.
보안 제보는 공격이 아니라 막을 수 있는 기회입니다. 한 달이면 응답에서 불필요한 정보를 빼고 권한을 점검하기에 충분한 시간일 수 있습니다.
FOLLOW-UP ①
경찰 수사와 압수수색
개인정보 유출은 법적 책임이 따르는 문제다.
2026년 7월 14일 보도
경찰이 AI 솔루션 업체 대표 등을 정보통신망법 위반 혐의로 입건하고,
업체와 서버 관리 주체 등 4곳을 압수수색했습니다. 서버 접속 기록을 분석해 유출 경위를 조사 중입니다.
입건
업체 대표 등이 수사 대상
정보통신망법
정보를 함부로 수집·이용하면 처벌 가능
4곳 압수수색
업체와 서버 관리 주체까지 확대
로그 분석
누가·언제·얼마나 접근했는지 추적
여기서 알 수 있는 것 — 하나의 플랫폼에는 발주 기관·운영사·외부 업체·서버 관리자가 얽혀 있습니다.
한 곳만 느슨해도 전체가 위험해지기 때문에 외부 업체 관리·감독이 중요한 과제가 됩니다.
1601 구현민
사건은 여기서 끝나지 않았습니다. 2026년 7월 14일 보도에 따르면 경찰은 AI 솔루션 업체 대표 등을 정보통신망법 위반 혐의로 입건하고, 업체와 서버 관리 주체 등 4곳을 압수수색했습니다.
그리고 서버 접속 기록, 즉 로그를 분석하며 유출 경위를 조사하고 있습니다.
이 뉴스에서 두 가지를 확인했습니다. 첫째, 개인정보 유출은 “실수했습니다”로 끝나지 않고 법적 책임이 따른다는 것입니다.
둘째, 하나의 플랫폼에는 발주 기관, 운영사, 외부 업체, 서버 관리자가 얽혀 있어서, 한 곳만 느슨해도 전체가 위험해진다는 것입니다.
FOLLOW-UP ②
암호키까지 함께 유출
암호화는 되어 있었다. 그런데 열쇠도 같이 나갔다.
7/31
중소벤처기업부 조사 결과 발표
39개 IP
비정상 접근을 시도한 국내 IP
복호화 가능
암호키가 함께 노출됨
39개 IP가 뜻하는 것
IP는 인터넷에서의 주소입니다. 39곳이 접근을 시도했다는 건
우연한 사고가 아니라 반복적인 수집 시도가 있었다는 뜻입니다.
암호키 노출이 뜻하는 것
정보를 잠가 두긴 했지만 열쇠까지 함께 나가 원래 내용을 다시 읽을 수 있었습니다.
“암호화했다”는 사실만으로는 안전하지 않습니다.
1601 구현민
2026년 7월 31일 조사 결과에서는 더 구체적인 사실이 드러났습니다.
비공개 정보가 포함된 API에 국내 IP 39개가 비정상적으로 접근을 시도한 것으로 확인됐습니다. 39곳이 시도했다는 건 우연이 아니라 반복적인 수집이 있었다는 뜻입니다.
더 충격적인 것은, 정보가 암호화되어 있었지만 암호키도 함께 노출되어 복호화가 가능했다는 점입니다.
쉽게 말해 정보를 금고에 넣어 두고 열쇠를 금고 옆에 둔 것과 같습니다. 암호화보다 암호키 관리가 함께 중요하다는 교훈입니다.
EASY EXPLAINER
암호화 = 자물쇠, 암호키 = 열쇠
잠그는 것만큼 열쇠를 어디에 두느냐가 중요하다.
암호화 — 자물쇠 채우기
“구현민” → “x7#Qa2” 처럼 알아볼 수 없게 바꿔 저장합니다.
암호키 — 그 열쇠
“x7#Qa2” → “구현민” 으로 되돌리는 비밀 값입니다.
원본 정보이메일·심사평
›
암호화알아볼 수 없게 변환
›
암호문 저장그 자체로는 안전
›
암호키 함께 유출열쇠가 같은 곳에
›
복호화 성공원본이 그대로 노출
아무리 튼튼한 자물쇠도 열쇠를 문 앞에 두면 소용없습니다 →
암호키는 데이터와 분리 보관, 접근자는 최소한으로
1601 구현민
암호화와 암호키를 자물쇠와 열쇠로 설명해 보겠습니다.
암호화는 정보를 알아볼 수 없게 바꿔 자물쇠를 채우는 것입니다. “구현민”을 “x7#Qa2” 같은 형태로 저장하는 것이죠.
암호키는 그걸 다시 원래대로 되돌리는 열쇠입니다. 그래서 아무리 잘 잠가도 열쇠를 같은 장소에 두면 보안 효과가 사라집니다.
이번 사건이 정확히 그런 경우였습니다. 그래서 실제 보안에서는 암호키를 데이터와 분리해 보관하고, 접근할 수 있는 사람을 최소한으로 제한합니다.
TIMELINE
사건 타임라인
약 3개월, 하나의 허점이 사회적 사건이 되기까지
5월 7일
보안 취약점 제보 주장
6월 15일
비정상 API 호출 문제 인지
6월 18일
유출 사실 공지
6월 21일
언론 보도 확산
6월 23일
경찰 내사 착수
7월 14일
업체 등 4곳 압수수색
7월 31일
39개 IP·암호키 유출 확인
경고 → 인지 약 39일
막을 수 있었던 시간이 있었습니다.
인지 → 공지 3일
신속한 통지는 피해를 줄이는 핵심입니다.
이후 약 46일 조사
공지 뒤에도 추가 사실이 계속 드러났습니다.
1601 구현민
지금까지 내용을 시간 순서로 정리했습니다.
5월 7일 보안 취약점 제보 주장이 있었고, 6월 15일 비정상 API 호출과 홍보 메일 발송으로 문제를 인지했습니다.
6월 18일 유출 사실이 공지되었고, 6월 21일부터 언론 보도가 확산, 6월 23일 경찰이 내사에 착수했습니다.
그리고 7월 14일 압수수색이 보도되었고, 7월 31일 조사 결과에서 39개 IP의 비정상 접근과 암호키 유출이 확인되었습니다.
제가 주목한 것은 경고와 인지 사이의 약 한 달입니다. 그 시간이 곧 막을 수 있었던 기회였다고 생각합니다.
CAUSE & EFFECT
원인과 결과 정리
하나의 실수가 아니라 겹겹이 쌓인 관리의 빈틈
원인
API 접근 권한 관리 부족
비공개 정보가 응답에 포함
암호키 관리 부실
사전 점검·제보 대응 부족
외부 업체 감독 부족
›››
이어짐
결과
합격자 약 5,000명 유출
피싱·스팸 위험 증가
아이디어·심사평 권리 침해
공공 플랫폼 신뢰 하락
경찰 수사·제도 개선 요구
원인 다섯 가지 중 순수한 기술 문제는 하나도 없습니다. 모두 관리와 점검의 문제였습니다.
1601 구현민
지금까지 살펴본 내용을 원인과 결과로 정리했습니다.
원인은 API 접근 권한 관리 부족, 비공개 정보가 응답에 포함된 점, 암호키 관리 부실, 사전 점검과 제보 대응 부족, 외부 업체 감독 부족 다섯 가지입니다.
그 결과 약 5천 명의 정보가 유출되고, 피싱과 스팸 위험이 커졌으며, 아이디어와 심사평 노출로 개인의 권리가 침해됐습니다. 나아가 공공 플랫폼 신뢰가 떨어지고 제도 개선 요구까지 커졌습니다.
여기서 강조하고 싶은 건, 다섯 가지 원인 중 순수한 기술 문제는 하나도 없다는 점입니다. 전부 관리의 문제였습니다.
RESPONSIBILITY
누구의 책임인가
이용자는 시스템 내부를 볼 수 없다. 그래서 책임은 아는 쪽이 더 크다.
기관·기업이 할 일
접근 권한 제한과 응답 최소화
암호키 분리 보관
취약점 제보 즉시 확인·조치
위탁해도 감독 책임은 남음
이용자가 할 일
필수 항목만 골라 최소 입력
의심스러운 메일·링크 주의
서비스마다 다른 비밀번호
침해 시 신고 방법 알아두기
책임의 무게는 같지 않다
이용자는 API도 암호키도 볼 수 없습니다. 이번 사건은 이용자가 조심해서 막을 수 있는 일이 아니었습니다.
이용자의 주의는 피해를 줄이는 역할이고, 예방의 책임은 정보를 수집·관리하는 쪽에 있습니다.
1601 구현민
그렇다면 책임은 누구에게 있을까요? 저는 먼저 기관과 기업의 책임이 크다고 봅니다. 이유는 정보 비대칭 때문입니다.
이용자는 자기 정보가 어떤 통로로 이동하는지 확인할 방법이 없지만, 기관은 모든 것을 알고 통제할 수 있습니다. 더 많이 알고 통제하는 쪽이 더 큰 책임을 져야 합니다.
물론 이용자도 최소한만 입력하고, 의심스러운 메일을 조심하고, 비밀번호를 다르게 쓰는 역할이 있습니다.
하지만 이용자는 API도 암호키도 볼 수 없습니다. 그래서 “개인이 조심하세요”로 끝내면 책임이 잘못된 방향으로 넘어갑니다. 예방의 책임은 기관에 있습니다.
PUBLIC TRUST
공공 플랫폼에서 사고는 ‘신뢰 사고’다
편리한 서비스보다 믿을 수 있는 서비스가 먼저다.
“정부니까 믿는다”공적 신뢰
›
더 많은 정보 제공의심 없이 상세히 입력
›
유출 사고믿고 맡긴 정보가 샘
›
신뢰 붕괴“공공기관도 못 믿겠다”
›
참여 위축다른 서비스도 꺼림
선택지가 없다
민간 서비스는 다른 곳을 쓰면 되지만, 정부 지원 사업은 대체할 곳이 없습니다.
피해가 번진다
한 곳의 사고가 공공 서비스 전체에 대한 불신으로 이어집니다.
신뢰가 기본 기능
신뢰는 서비스의 부가 기능이 아니라 기본 조건입니다.
1601 구현민
저는 이 사건의 가장 큰 피해가 ‘신뢰’라고 생각합니다.
사람들은 “정부가 하는 거니까 믿는다”는 마음으로 더 많은 정보를 제공합니다. 저도 아이디어를 아주 자세히 적었습니다.
그런데 믿고 맡긴 정보가 새어 나가면 “공공기관도 못 믿겠다”는 생각으로 이어지고, 다른 서비스 참여까지 꺼리게 됩니다.
특히 민간 서비스는 다른 곳을 쓰면 되지만 정부 지원 사업은 대체할 곳이 없습니다. 그래서 공공 플랫폼에서는 편리함보다 신뢰가 먼저여야 합니다.
CRITICAL READING
같은 사건, 다른 제목
제목만 보면 누구의 잘못인지가 달라 보인다.
강조된 표현
받는 인상
빠지기 쉬운 오해
“해킹으로 5천 명 유출”
전문 해커의 침입
“막기 어려웠겠네” → 관리 책임이 흐려짐
“외부 해킹은 아니다”
큰 사고는 아닌 듯
“별일 아니네” → 피해가 축소돼 보임
“비정상 API 호출”
어려운 기술 문제
“나와 상관없네” → 관심에서 멀어짐
“AI 업체 홍보 메일”
업체 한 곳의 잘못
“그 회사만 처벌” → 구조적 원인이 가려짐
이렇게 비교했습니다
기사마다 ① 원인 ② 피해 ③ 책임 ④ 대책 네 가지를 표로 정리해 비교하고,
차이 나는 부분은 정부 발표 자료를 기준으로 확인했습니다.
‘노출’과 ‘유출’
볼 수 있는 상태였는지, 실제로 나갔는지에 따라 표현이 달라집니다. 하지만 이용자에겐
통제 밖으로 나갈 수 있었다는 사실 자체가 불안입니다. 기관은 축소보다 투명한 설명을 해야 합니다.
1601 구현민
조사하면서 흥미로웠던 건 기사마다 강조점이 달랐다는 것입니다. ‘해킹’, ‘외부 해킹은 아니다’, ‘비정상 API 호출’, ‘AI 업체 홍보 메일’처럼요.
표를 보시면 어떤 단어를 고르느냐에 따라 누구의 잘못처럼 보이는지가 달라집니다.
그래서 저는 기사마다 원인, 피해, 책임, 대책 네 가지를 표로 정리해 비교하고, 차이 나는 부분은 정부 발표 자료를 기준으로 확인했습니다.
또 ‘노출’과 ‘유출’이라는 표현도 섞여 쓰였는데, 이용자 입장에서는 내 정보가 통제 밖으로 나갈 수 있었다는 것만으로도 불안합니다. 기관은 표현을 축소하기보다 투명하게 설명해야 합니다.
RULES
유출되면 무엇을 해야 하나
우리나라는 유출을 알게 되면 72시간 이내 통지·신고를 원칙으로 한다.
72시간 규칙, 쉽게 말하면
유출 사실을 알게 된 때부터 72시간 이내에 피해자에게 알리고, 기준에 해당하면 전문기관에 신고해야 합니다.
한마디로 “조용히 덮을 수 없다”는 뜻이며, 이용자가 스스로 대비할 시간을 벌어 줍니다.
통지에 담겨야 할 것
무엇이 유출됐는지
언제·얼마나 유출됐는지
기관의 피해 최소화 대책
피해자의 조치 방법과 문의처
① 유출 인지사실관계 파악
›
② 72시간 이내통지 + 신고
›
③ 피해 최소화취약점 차단·안내
›
④ 원인 조사로그 분석·수사 협조
›
⑤ 재발 방지제도·시스템 개선
1601 구현민
개인정보가 유출되면 기관이 마음대로 처리할 수 있는 게 아닙니다. 지켜야 할 절차가 정해져 있습니다.
개인정보 보호법에 따르면 유출 사실을 알게 된 때부터 72시간 이내에 피해자에게 알리고, 기준에 해당하면 전문기관에 신고해야 합니다.
쉽게 말해 “조용히 덮고 넘어갈 수 없다”는 뜻이고, 이용자가 비밀번호를 바꾸거나 피싱을 조심할 시간을 벌어 주기 위한 규칙입니다.
통지할 때는 무엇이, 언제, 얼마나 유출됐는지와 함께 기관의 대책, 그리고 피해자가 할 수 있는 조치와 문의처까지 알려야 합니다.
SOLUTION
재발 방지 체크리스트
문제가 생긴 뒤 고치는 것이 아니라, 처음부터 안전하게 설계하기
✓
API 접근 권한 최소화
요청마다 자격을 확인
✓
응답에서 불필요 정보 제외
안 쓰는 항목은 내보내지 않기
✓
암호키 분리 보관
데이터와 열쇠를 다른 곳에
✓
접속 기록 저장·점검
이상 징후를 조기에 발견
✓
자동 수집·크롤링 차단
과도한 요청은 자동 제한
✓
사전 취약점 점검
공개 전 점검, 제보는 즉시 조치
✓
외부 업체 감독 강화
위탁해도 책임은 남는다
✓
빠르고 정확한 통지
피해자에게 신속히 알리기
원칙 1 · 최소 수집, 최소 제공
꼭 필요한 정보만 모으고, 꼭 필요한 만큼만 보여줍니다.
원칙 2 · 설계 단계부터 보안
다 만든 뒤 덧붙이는 것이 아니라, 기획 때부터 기본 조건으로 넣습니다.
1601 구현민
그렇다면 어떻게 해야 다시 생기지 않을까요? 여덟 가지로 정리했습니다.
API 접근 권한을 최소화하고, 응답에서 불필요한 정보를 빼고, 암호키를 분리 보관하고, 접속 기록을 저장해 점검해야 합니다.
또 자동 수집을 차단하고, 사전에 취약점을 점검하며, 외부 업체 감독을 강화하고, 사고가 나면 빠르고 정확하게 통지해야 합니다.
이걸 두 가지 원칙으로 줄이면 ‘최소 수집·최소 제공’과 ‘설계 단계부터 보안’입니다.
다 만든 뒤에 보안을 덧붙이는 방식으로는 이런 사고를 막기 어렵다는 것이 이번 사건의 교훈입니다.
FOR US
우리가 지금 할 수 있는 일
사고를 막을 수는 없어도, 피해는 줄일 수 있다.
1
불필요한 정보는 입력하지 않기
필수 표시가 없는 항목은 비워 둬도 됩니다
2
개인정보 처리방침 확인
무엇을 얼마나 보관하는지 한 번은 보기
3
이메일 공개 범위 점검
프로필에 공개돼 있지 않은지 확인
4
의심스러운 메일·링크 주의
보낸 사람 주소를 먼저 확인
5
비밀번호 돌려쓰지 않기
한 곳이 뚫려도 번지지 않게
6
신고 방법 알아두기
개인정보 침해 신고 국번 없이 118
추가로 — 메일 계정에 2단계 인증을 켜 두면 비밀번호가 새어 나가도 계정을 지킬 수 있습니다.
1601 구현민
그렇다면 우리는 무엇을 할 수 있을까요? 여섯 가지입니다.
첫째 불필요한 정보는 입력하지 않기, 둘째 개인정보 처리방침 확인하기, 셋째 이메일 공개 범위 점검하기입니다.
넷째 의심스러운 메일과 링크 조심하기. “합격 안내” 같은 메일도 보낸 사람 주소를 먼저 봐야 합니다. 다섯째 같은 비밀번호를 돌려쓰지 않기입니다.
여섯째 신고 방법을 알아두기입니다. 개인정보 침해는 국번 없이 118로 상담할 수 있습니다.
여기에 메일 계정 2단계 인증까지 켜 두면 훨씬 안전합니다.
MY OPINION
이 사건을 보며 든 생각
통신 기술 발전의 핵심은 속도가 아니라 신뢰다.
편리함은 목적이 아니다
아무리 빠르고 편리해도 안전하지 않으면 믿고 쓸 수 없습니다. 편리함은 신뢰 위에서만 의미가 있습니다.
공공기관은 기준이 더 높아야
더 큰 신뢰를 받는 쪽이 더 큰 책임을 져야 합니다. 참여를 거부하기 어려운 서비스라면 더욱 그렇습니다.
책임의 무게는 같지 않다
아무것도 볼 수 없는 이용자에게 “조심하지 그랬냐”고 말하는 것은 공정하지 않습니다.
대응보다 예방
사과문을 잘 쓰는 것보다 제보 하나를 진지하게 처리하는 것이 훨씬 값집니다.
1601 구현민
이제 제 생각을 말씀드리겠습니다. 네 가지를 느꼈습니다.
첫째, 편리함은 목적이 아니라 수단이라는 것입니다. 아무리 빨라도 안전하지 않으면 사람들은 그 서비스를 믿고 쓸 수 없습니다.
둘째, 공공기관 관련 플랫폼은 더 높은 보안 책임을 져야 합니다. 더 큰 신뢰를 받는 쪽이 더 큰 책임을 지는 게 맞습니다.
셋째, 이용자와 기관의 책임 무게는 같지 않습니다. 아무것도 볼 수 없는 사람에게 “조심하지 그랬냐”고 하는 건 공정하지 않습니다.
넷째, 대응보다 예방입니다. 보안은 사고가 나야 드는 비용이 아니라 평소에 지불해야 하는 기본 비용이라고 생각합니다.
CONCLUSION
결론
개인정보 보호는 기술 문제가 아니라 권리 · 책임 · 신뢰의 문제다.
개인의 권리
내 정보가 어디로 가는지 알고 통제할 권리
기관의 책임
정보를 모은 쪽이 지킬 의무를 진다
사회적 신뢰
신뢰가 무너지면 좋은 서비스도 작동하지 않는다
지금까지 — 사후 대응
서비스를 빨리 만드는 것이 우선
보안은 나중에 추가하는 항목
사고가 나면 사과문과 수사로 마무리
앞으로 — 사전 예방
기획 단계부터 보안이 기본 조건
최소 수집·최소 제공을 원칙으로
제보를 막을 기회로 받아들이기
1601 구현민
결론입니다. 이번 사건은 통신 기술이 우리 삶을 편리하게 만들지만, 그 편리함 뒤에는 개인정보 보호라는 과제가 함께 있다는 것을 보여줍니다.
개인정보 보호는 단순한 기술 문제가 아니라 개인의 권리, 기관의 책임, 사회적 신뢰와 연결된 문제입니다.
지금까지는 서비스를 빨리 만들고 보안은 나중에 붙이는 방식이 많았고, 사고가 나면 사과문과 수사로 마무리되곤 했습니다.
앞으로는 기획 단계부터 보안을 기본 조건으로 삼고, 최소 수집·최소 제공을 원칙으로 해야 합니다.
한마디로 ‘문제가 생긴 뒤 대응’이 아니라 ‘생기기 전에 예방’하는 태도가 필요합니다.
통신 기술의 진짜 발전은 더 빠른 연결이 아니라,
더 안전하게 믿고 연결될 수 있는 사회를 만드는 것이다.
통신개인정보공공기관 책임신뢰
들어주셔서 감사합니다 — 1601 구현민
1601 구현민
제 발표를 한 문장으로 정리하겠습니다.
“통신 기술의 진짜 발전은 더 빠른 연결이 아니라, 더 안전하게 믿고 연결될 수 있는 사회를 만드는 것이다.”
이번 조사를 통해 저는 편리함과 안전함이 서로 반대되는 것이 아니라 함께 가야 하는 것이라는 걸 배웠습니다.
앞으로 무언가를 만들게 된다면 “이 정보가 안전한가”를 먼저 묻는 사람이 되고 싶습니다.
이상으로 발표를 마치겠습니다. 감사합니다. 질문 있으시면 답변드리겠습니다.
REFERENCES
참고자료
여러 자료를 비교·교차 확인해 정리했습니다.
구분
자료
활용한 부분
언론 보도
‘모두의 창업’ 유출 관련 기사 2026년 6월 21일 이후 / 7월 14일 압수수색 보도
사건 개요, 유출 규모·항목, 경찰 수사 경과
정부 발표
중소벤처기업부 조사 결과 2026년 7월 31일
39개 IP 비정상 접근, 암호키 노출 사실
법령
개인정보 보호법 유출 통지·신고 조항 개인정보보호위원회 안내 자료
72시간 통지 원칙, 통지 포함 항목
기관 안내
한국인터넷진흥원(KISA) 개인정보 침해 신고센터 국번 없이 118
신고·상담 방법, 피싱 대응 요령
유의 — ‘5월 7일 제보’는 제보자 측 주장으로 보도된 내용이라 단정하지 않았고,
유출 규모와 항목은 발표 시점까지 알려진 내용으로 추후 조사에 따라 달라질 수 있습니다.
※ 기사 제목·언론사명·URL은 직접 확인해 채워 넣으세요.
1601 구현민
마지막으로 참고자료입니다.
저는 언론 기사, 중소벤처기업부 조사 결과 발표, 개인정보 보호법 관련 안내 자료, 한국인터넷진흥원 개인정보 침해 신고센터 안내를 참고했습니다.
기사를 여러 개 모아 원인·피해·책임·대책 네 항목으로 비교했고, 차이 나는 부분은 정부 발표를 기준으로 확인했습니다.
‘5월 7일 제보’ 부분은 제보자 측 주장이라 단정하지 않았고, 유출 규모와 항목도 발표 시점까지 알려진 내용임을 함께 말씀드립니다. 이상으로 마치겠습니다. 감사합니다.