티빙과 모두의 창업 개인정보 유출 사고 간단 분석## TL;DR 2026년 6월, 티빙과 정부 사업 모두의 창업에서 개인정보 유출이 연달아 발생했습니다. 두 사고는 원인이 다릅니다. 티빙은 자격증명 관리 부실과 클라우드 접근 통제 미흡이 핵심 쟁점으로 지목되는 외부 침해 사고이고, 모두의 창업은 현재까지 DB 자체 접근은 확인되지 않았고, 인가가 미흡한 서버 API를 통해 비공개 데이터가 확보된 사고입니다(창업진흥원 신고서에는 참여 AI 솔루션 업체의 비정상 API 호출·크롤링이 정보 확보 경위로 기재). 공통점은 신뢰할 수 없는 대상을 신뢰했고, 서버·인프라 단에서 접근을 검증하는 지점이 없었다는 것입니다. > 이 글은 보도와 침해사고 신고서, 정부·기업 발표를 기반으로 정리한 내용입니다. 두 사고 모두 조사가 진행 중이라, 최종 침해 경로는 조사 결과로 확정됩니다. --- ## 1. 티빙: 자격증명 노출과 탐지 실패 침해사고 신고서 기준으로, 5월 30일 오후 6시 1분 DB 서버 CPU 사용률이 100%에 도달하는 이상 징후가 기록됐고, 티빙은 5월 31일 오후 3시 9분 침해 사실을 인지한 뒤 6월 2일 비인가 접근에 따른 개인정보 유출을 확인했습니다. 유출 규모는 정부 초기 추산 약 1,300만 명에서 이후 약 1,953만 명으로 늘었고, 유출 항목에는 변경이 어려운 연계정보(CI)와 중복가입확인정보(DI)가 포함됐습니다. KISA에 제출된 침해사고 신고서에 따르면 단순 DB 유출이 아니라, 공격자가 내부 시스템 또는 데이터에 접근해 직접 쿼리를 실행한 정황이 확인됐습니다. 사고 직후 티빙의 조치는 원인을 시사합니다. 공격에 사용된 AWS 액세스 키를 폐기했고, GitHub에 하드코딩된 자격증명을 제거·교체했으며, 클라우드 접근 통제 정책을 변경했습니다. 이는 적어도 코드 저장소와 클라우드 자격증명 관리 과정에 문제가 있었을 가능성을 보여줍니다. 해당 키에 부여된 권한 범위에 따라 서버·저장소·DB 등 주요 시스템 접근으로 이어질 수 있습니다. 다만 이 자격증명이 실제 침입 경로였는지, 공격자가 GitHub를 통해 시스템을 선제 장악했는지는 아직 확정되지 않은 정황이며, 최종 경로는 조사 결과로 확인될 부분입니다. 여기에 두 가지 대응 실패가 겹쳤습니다. 비정상적인 데이터 조회·명령이 발생한 시점부터 이를 인지하기까지 약 21시간이 걸렸고, KISA 신고는 의무 시한인 24시간을 1분 남긴 23시간 59분 만에 이뤄졌습니다. 또한 CI·DI처럼 변경이 어렵고 서비스 간 식별에 악용될 수 있는 값을 운영 DB에 보관하다 함께 유출된 점도 비판받았습니다. --- ## 2. 모두의 창업: 서버 API의 인가 미흡 이 사고는 현재까지 DB 자체 접근은 확인되지 않았고, 백엔드 API의 인가 미흡을 이용한 비정상 접근으로 설명됩니다. 창업진흥원이 개인정보위에 제출한 신고서에는 프로젝트에 참여한 AI 솔루션 업체의 비정상 API 호출·크롤링이 정보 확보 경위로 기재된 것으로 보도됐습니다. 6월 15일 1차 합격자 5,000명의 프로필이 공개됐는데(이들이 유출 통지 대상), 이메일은 비공개로 설정하면 화면에는 표시되지 않았지만, 일부 서버 API(도전자 프로필·심사평)의 인가가 미흡해 특정 호출을 하면 값이 그대로 반환됐습니다. ``` [화면] [서버 API 응답] 이메일: (비공개) ←→ "email": "gildong@example.com" ← 그대로 반환 ``` 신고서와 보도에 따르면 해당 업체는 AI 도구와 웹 크롤링을 활용해 정상 권한이 있는 사용자처럼 시스템을 호출한 것으로 기재됐고, 확보한 이메일 주소로 홍보 메일을 발송했다가 확인됐습니다. 조사 과정에서는 9개 IP를 통한 비정상 API 호출 정황도 확인됐습니다. 유출된 개인정보는 이메일 주소이며, 여기에 아이디어 요약 정보와 심사평 등 비공개 정보도 함께 외부로 노출된 것으로 확인됐습니다(중기부는 DB 자체 접근은 확인되지 않았고 주민등록번호·연락처·상세 신청서는 유출되지 않은 것으로 파악). 중기부와 국정원도 권한이 없는 사용자가 정상 권한이 있는 것처럼 시스템을 호출해 정보를 가져간 것으로 보고 있습니다. 다만 중기부는 수사가 진행 중인 만큼 특정 업체를 유출 주체로 단정하기는 어렵다는 입장이고, 해당 업체는 공개된 정보만 활용했다고 주장하고 있습니다. 한편 서버 API에 문제가 있었다는 점에 대해서는 중기부도 결과적으로 문제가 있었다는 점을 인정했습니다. 이는 OWASP API 보안 기준으로 보면, 화면에서 숨긴 이메일 필드가 API 응답에는 그대로 포함된 점에서 객체 속성 수준 인가 실패(BOPLA)에 가까운 사례입니다(객체 ID를 조작해 접근하는 경우라면 BOLA에도 해당). 보안 전문가들은 이를 고난도 공격이 아닌 예방 가능한 기초 취약점으로 평가했습니다. 또한 사고 한 달 전인 5월 7일, 보안팀 '젠토'가 API 응답으로 개인정보가 노출되는 유사한 유형의 취약점을 재현 경로·개선안과 함께 제보했으나, 근본적으로 해소되지 않은 채 유사한 형태의 사고로 이어졌습니다. > 참고로 "생성형 AI 코딩 도구(바이브코딩)로 플랫폼을 구축해 보안이 취약했다"는 의혹도 제기됐으나, 중기부는 "개발사 확인 결과 해당 방식은 사용되지 않았다(단, 조사 결과를 봐야 한다)"고 밝혔습니다. 즉 바이브코딩은 현재까지 이 사고의 원인으로 확인된 사항이 아니며, 플랫폼이 AI로 개발돼 취약해졌다는 주장은 확인되지 않았습니다. --- ## 3. 실제로 무엇이 잘못됐을까? 원인은 다르지만 근본 문제는 세 가지로 정리됩니다. 1. 신뢰 경계 설정 실패 — 티빙은 자격증명을 가진 주체를, 모두의 창업은 협력업체와 화면 단의 비공개 처리를 신뢰했습니다. 둘 다 신뢰의 기준이 될 수 없습니다. 2. 강제 검증 지점의 부재 — 티빙은 자격증명·클라우드 권한 관리 문제가 내부 시스템 접근으로 이어졌을 가능성이 제기됐고 이상 징후 탐지도 늦었으며, 모두의 창업은 응답 전에 요청자의 권한을 검증하지 않았습니다. 3. 경고 무시와 과다 보유 — 티빙은 변경이 어려운 CI·DI를 운영 DB에 보관하다 함께 유출됐고, 모두의 창업은 한 달 전 제보된 취약점이 근본적으로 해소되지 않은 채 유사한 사고로 이어졌습니다. --- ## 4. 어디서 막았어야 할까? 티빙은 시크릿을 소스코드에 하드코딩하지 않고 별도 시크릿 관리 도구를 사용해야 하며, 자격증명 정기 교체와 유출 시 즉시 무효화, IAM 최소 권한 적용, 비정상 쿼리에 대한 실시간 탐지가 필요합니다. 모두의 창업은 화면이 아니라 서버 응답 단에서 요청자 권한에 따라 필드를 필터링해야 하며, 협력업체를 포함한 모든 API 호출자를 신뢰할 수 없는 주체로 취급하고, 비정상 API 호출·크롤링 탐지와 rate limiting을 적용해야 합니다. 제보된 취약점은 임시 차단이 아니라 근본 수정으로 마무리해야 합니다. 두 사고에 공통으로 적용되는 원칙은 하나입니다. 화면에서 숨기는 것은 보안이 아니며, 인가는 서버에서 강제되어야 합니다. --- ## 5. 마치며 원인은 다르지만 두 사고 모두, 특정 주체나 화면 처리를 신뢰하고 서버 단에서 접근 권한을 검증하지 않은 것이 유출로 이어졌습니다. 참고로 개인정보위·KISA가 2026년 5월 발표한 보고서에 따르면, 2025년 개인정보 유출 신고는 447건으로 전년(307건) 대비 45.6% 증가했고, 과징금은 40건에 1,677억 원, 과징금·과태료 부과 규모는 전년 대비 172% 늘었습니다. 또한 2026년 3월 10일 공포된 개인정보 보호법 개정안에 따라, 9월 11일부터는 고의·중과실로 반복 위반하거나, 고의·중과실로 1천만 명 이상 대규모 피해를 초래한 경우 등에는 전체 매출액의 최대 10%까지 과징금이 부과될 수 있습니다. (다만 개정법은 시행 이후 발생 사건부터 적용됩니다.) 이 두 사건에서 눈에 띄는 점은, 둘 다 특별히 정교하거나 새로운 공격이 아니었다는 것입니다. 그런데 이건 특정 기업만의 문제라기보다, 서비스를 운영하다 보면 누구나 놓치기 쉬운 지점들이기도 합니다. 시크릿 관리나 서버에서의 권한 검증 같은 부분은 익숙하고 당연해 보이는 만큼 오히려 우선순위에서 밀리기 쉽습니다. 그래서 보안은 어렵고 복잡한 공격을 대비하는 일이라기보다, 이런 기본적인 것들을 꾸준히 점검하는 일에 가깝다고 생각합니다. 남의 일로 여기기보다, 내가 만들고 운영하는 서비스에는 이런 구멍이 없는지 함께 조심해 보면 좋겠습니다.