개인정보 유출 사건 사고 총정리 최근 5년간 | 140건 사례표·과징금 TOP 10과 바이브코딩 개발자가 지킬 법적 의무

필자가 2021년 1월부터 2026년 10월 8일까지 국내에서 공개된 개인정보 유출 사건 143건을 모아, 개인정보보호위원회 처분 발표와 언론 기사로 한 건씩 맞춰 본 정리다. 기사나 공식 발표로 확인되는 140건은 연도별 표에 모두 싣고, 다크웹 판매글처럼 SNS 게시물로만 알려진 3건은 언론 미확인으로 따로 분리했다. 표의 모든 행에는 그 사건을 보도한 기사 링크를 달았고, 개인정보위 보도자료나 회사 공지가 있는 사례는 공식 링크를 함께 걸었다. 기사를 찾지 못한 2건은 회사 공지로 대신했다.

숫자부터 보면 규모가 달라졌다. 티빙은 민관합동조사단 집계로 3,954만 계정, 쿠팡은 개인정보위 기준 약 3,755만 명, SK텔레콤은 2,324만여 명의 정보가 빠져나갔다. 과징금도 쿠팡 6,246억 8,100만 원, SK텔레콤 1,347억 9,100만 원으로 커졌다. 이 목록 기준으로 2026년 9월 한 달에만 36건이 새로 알려졌고, 하나의 교육 플랫폼 위탁사가 뚫리면서 공공기관 교육 사이트와 노동조합까지 줄줄이 피해를 신고한 일도 있었다.

필자가 이 목록에서 특히 눈여겨본 부분은 원인이다. 소스코드 안에 그대로 적어 둔 접속키, 권한 확인 없이 열려 있던 조회 API, 6일치밖에 남지 않은 접속기록, 운영 서버에 방치된 테스트 데이터는 대기업만의 문제가 아니다. AI에게 말로 기능을 주문해 앱을 만드는 바이브코딩이 퍼지면서 회원가입 폼 하나로 개인정보를 받는 1인 서비스가 빠르게 늘고 있고, 같은 실수는 작은 서비스에서 더 쉽게 생긴다.

글 뒷부분에는 개인정보 보호법과 시행령, 개인정보의 안전성 확보조치 기준 원문을 국가법령정보센터에서 확인해 개발자가 지켜야 할 의무와 실제 과징금 수준을 정리했다. 조사 중인 사건은 처분이 확정되지 않았으므로 표에 미확인으로 적었고, 출처마다 숫자가 다른 경우 범위로 함께 적었다.

핵심 포인트: 2021~2026년 공개 사례 143건 가운데 140건을 근거 기사와 함께 표로 정리했다. 규모 1위는 티빙 3,954만 계정, 과징금 1위는 쿠팡 6,246억 8,100만 원이다. 반복되는 원인은 하드코딩된 키, 권한 검사 없는 API, 짧은 로그 보관, 크리덴셜 스터핑이며 1인 개발자도 개인정보를 받는 순간 같은 법적 의무를 진다.

1. 최근 5년 개인정보 유출 한눈에 보기

아래 표는 이 글에 담은 140건을 공개 시점으로 나눈 것이다. 2023~2025년 사례는 개인정보위 처분까지 나온 사건이 중심이고, 2026년 사례는 신고·보도 단계의 사건까지 넓게 담아 건수가 많다. 국내 전체 유출 신고 건수와는 다른 집계이므로 연도 간 증감을 그대로 비교하기보다 사건의 성격을 보는 용도로 읽는 편이 맞다.

• 공공기관 사례는 대학, 교육청, 법원, 행정안전부, 공단 등 33건이다. 서울대학교병원은 공공기관 첫 과징금 사례로 기록됐다.
• 2025년부터 통신 3사 가운데 2곳(SK텔레콤, KT)과 대형 유통·카드사가 연달아 대규모 처분을 받았다.
• 2026년 9월 이후는 위탁사 한 곳이 뚫리며 여러 기관이 동시에 피해를 입는 연쇄 유출과 금융권 침해 신고가 몰렸다.

2. 유출 규모 TOP 10

규모는 계정 수와 사람 수가 섞여 있어 단순 비교에 한계가 있다. 출처마다 숫자가 다른 사건은 범위로 적었고, 실제 반출이 확정되지 않은 교원그룹(영향 범위 554만~960만 명)과 한국파파존스(3,700만 건 유출 가능성 보도)는 순위에서 뺐다.

그림 1. 최근 5년 개인정보 유출 규모 TOP 10. 단위가 계정과 명으로 섞여 있어 비고를 함께 봐야 한다.

상위 10건 가운데 8건이 2025년 이후 공개됐다. 티빙과 쿠팡은 휴면·탈퇴 계정까지 유출 범위에 들어가 숫자가 커졌는데, 쓰지 않는 계정 정보를 오래 보관할수록 유출 규모가 함께 커진다는 점을 보여 준다.

3. 과징금 TOP 10

개인정보위가 부과한 과징금만 비교했다. 과태료와 다른 기관(금융위원회, 과학기술정보통신부)의 처분은 금액에 넣지 않았다. 쿠팡 금액에는 유출 관련분 4,235억 7,500만 원과 별도 위반분이 함께 들어 있다.

그림 2. 개인정보위 과징금 TOP 10. 과태료와 다른 기관 처분은 제외한 금액이다.

과징금 상위권은 2024년 이후 처분이 대부분이다. 2026년 3월 개정돼 9월 11일부터 시행 중인 법에서는 고의나 중대한 과실로 1천만 명 이상이 피해를 입은 경우 등에 전체 매출액의 최대 10%까지 과징금을 매길 수 있어, 앞으로 상한이 더 높아질 수 있다.

4. 2021~2022년 유출 사례

서울대학교병원 해킹은 북한 해킹조직이 지목된 사건으로, 공공기관에 처음 과징금이 부과됐다. 같은 시기 쿠팡이츠는 배달원 정보를 외부 주문관리 시스템으로 보내고 신고까지 늦어 처분을 받았고, 섹타나인은 크리덴셜 스터핑 피해가 한 번 더 반복됐다.

5. 2023년 유출 사례

LG유플러스 사건에서는 노후 시스템과 방치된 웹셸에 더해 테스트 데이터 1천만 건 이상이 운영 환경에 남아 있던 점이 드러났다. 카카오 오픈채팅은 임시 ID로 회원번호를 추출할 수 있는 취약점이 문제가 됐고, SK스토아는 4,400만 회에 이르는 로그인 시도를 막지 못했다.

6. 2024년 유출 사례

2024년에는 SQL 인젝션과 관리자 계정 탈취처럼 오래된 공격 방식이 여전히 통했다. 전북대학교는 2010년부터 있던 취약점으로 32만여 명의 정보가 유출됐고, 클래스유는 DB 관리자 계정이 탈취돼 약 160만 명이 영향을 받았다. 행정안전부와 한화호텔앤드리조트는 외부 공격이 아니라 개발 과정의 오류로 처분을 받았다.

7. 2025년 유출 사례

2025년은 규모와 과징금이 모두 최대치를 경신한 해다. SK텔레콤은 2021년 8월 시작된 내부망 침투가 2025년 4월 유심 정보 유출로 이어졌고, 쿠팡은 퇴사자가 서명키로 인증 토큰을 위조해 장기간 데이터를 긁어 갔다. 명품 브랜드 3곳은 직원 보이스피싱이나 악성코드로 고객관리 SaaS 계정을 빼앗겼다.

8. 2026년 1~8월 유출 사례

티빙 사건은 개발자 접속키 탈취에서 시작해 소스코드에 적힌 운영환경 키로 번졌다. 데이원컴퍼니는 GitHub 마스터 계정 키를 탈취당했고, 29CM는 주문 조회 API로 비정상 접근이 이뤄졌다. 국가아동권리보장원은 암호화하지 않은 보조저장매체 관리 부실로 입양기록이 유출됐다.

9. 2026년 9월 유출 사례

9월에는 하루에도 여러 건의 유출 공지가 이어졌다. 강남언니와 위버스, 하이타이는 API 권한 검사가 핵심 원인으로 지목됐고, 토스페이먼츠와 SSG닷컴은 결제 연동키 노출 문제가 보도됐다. 교육 플랫폼 위탁사 맑은소프트가 해킹되면서 피해처가 22~36곳으로 늘었다는 보도도 나왔다.

10. 2026년 10월 1~8일 유출 사례

10월 첫 주에는 은행·저축은행·캐피탈 등 금융권 신고가 몰렸다. BNK부산은행은 AI를 활용한 웹서버 공격, 현대캐피탈은 해외 IP에서 AI를 활용한 반복 조회가 원인으로 보도됐다. 공격하는 쪽도 AI를 쓰고 있다는 점에서 바이브코딩으로 만든 서비스가 받는 압력도 커지고 있다.

11. 언론 미확인 3건

다음 3건은 다크웹 판매글이나 해커 측 게시물 등 SNS로만 알려졌고, 2026년 10월 8일 기준 언론 기사나 공식 발표로 사실이 확인되지 않았다. 확인되지 않은 주장을 사실처럼 옮기지 않기 위해 규모와 링크를 싣지 않는다.

• 해커 측이 주장한 용량이나 건수는 표 어디에도 사실로 적지 않았다.
• 이후 회사 공지나 기사가 나오면 정식 사례로 옮겨야 할 항목이다.

12. 반복되는 유출 원인

140건의 원인 칸을 모아 보면 몇 가지 유형이 계속 반복된다. 아래 표는 유형별 대표 사례만 고른 것이며, 한 사건에 여러 원인이 겹친 경우도 많다.

13. 바이브코딩 붐이 위험한 이유

바이브코딩은 화면과 기능을 빠르게 만들어 주지만, AI가 만든 코드는 동작 여부를 기준으로 완성되는 경우가 많다. 누가 어떤 데이터를 볼 수 있는지, 비밀값이 어디에 저장되는지, 사고가 났을 때 무엇이 기록에 남는지는 따로 요구하지 않으면 빠지기 쉽다. 아래 항목은 위 사례에서 확인된 원인을 일반적인 보안 상식과 연결한 것이다.

13.1. 소스코드에 적어 둔 접속키

1. 티빙 민관합동조사단 발표에 따르면 공격자는 개발자의 개발환경 접속키를 탈취한 뒤, 361개 개발 프로젝트 소스코드에 평문으로 남아 있던 운영환경 접속키 43개를 추가로 손에 넣었다(동아일보 · 정책브리핑).
2. 티빙은 2024년 모의해킹에서 접속키를 소스코드에 그대로 노출하는 취약점을 지적받고도 조치하지 않은 것으로 조사됐다(동아일보 · 정책브리핑).
3. AI에게 기능을 만들어 달라고 하면 예제 편의를 위해 API 키나 DB 비밀번호를 코드에 바로 적는 경우가 있다. 비밀값은 환경변수나 비밀값 관리 서비스로 옮기고, 한 번이라도 커밋된 키는 지우는 것으로 끝내지 말고 폐기 후 재발급해야 한다.

13.2. 깃허브 계정과 저장소

1. 데이원컴퍼니는 GitHub 마스터 계정 키 탈취가 원인으로 보도됐다(지디넷코리아).
2. 한국은행 직원 186명의 정보는 온라인 연수 수탁업체의 GitHub 침입으로 새어 나갔다(연합뉴스).
3. 멜로밍은 내부 API 키 탈취로 전체 이용자 정보가 유출됐고 서비스 종료를 결정했다고 보도됐다(이코노미사이언스).
4. 공개 저장소는 물론 비공개 저장소도 계정이 뚫리면 코드 속 키가 함께 넘어간다. 저장소 계정에 2단계 인증을 켜고, 배포용 토큰은 권한과 기간을 최소로 잡는 편이 안전하다.

13.3. Supabase RLS와 Firebase 보안 규칙

1. Supabase 공식 문서는 노출된 스키마의 테이블에 RLS가 없으면 권한이 부여된 역할 누구나 읽고 쓸 수 있다고 경고하며, 노출된 스키마의 모든 테이블에 RLS를 켜라고 안내한다(Supabase RLS 문서).
2. 같은 문서는 RLS를 우회하는 서버용 비밀 키를 브라우저에 두거나 고객에게 노출하지 말라고 적고 있다.
3. Firebase 공식 문서도 개발 중 열어 둔 오픈 액세스 규칙을 배포 전에 반드시 고치라고 하며, 인증과 규칙 없이 배포하면 프로젝트 ID를 추측한 사람이 데이터를 훔치거나 지울 수 있다고 설명한다(Firebase 보안 규칙 문서).
4. 이 글에 정리한 140건의 기사와 처분 발표에서는 Supabase나 Firebase 설정 오류가 원인으로 밝혀진 사례가 없었다. 다만 브라우저에서 DB를 직접 부르는 구조는 규칙 한 줄이 곧 전체 회원 정보의 공개 여부를 정하므로, 배포 전에 로그아웃 상태와 다른 계정 상태에서 직접 조회해 보는 점검이 필요하다.

13.4. 권한 검사 없는 조회 API

1. 29CM는 주문 조회 API로 159,852건이 비정상 접근됐고(아주경제), 강남언니는 상담내역 조회 API 비인가 접근으로 219,665명이 영향을 받았다(전자신문).
2. 위버스는 결제 API 취약점으로 계정 422,584건이 노출됐다고 보도됐다(연합뉴스).
3. 한화호텔앤드리조트는 예약 절차를 바꾸는 과정의 개발 과실로 타인의 예약정보 조회가 가능해져 과징금 1억 8,531만 원을 받았다(보안뉴스 · 개인정보위).
4. 주문번호나 회원번호만 바꿔 남의 정보를 볼 수 있는지, 로그인한 이용자와 조회 대상이 같은 사람인지 서버에서 확인하는지 점검해야 한다. 화면에서 버튼을 숨기는 것만으로는 막을 수 없다.

13.5. 로그가 없으면 원인도 찾지 못한다

1. 티빙은 시스템 접속기록을 6일치만 보관해 최초 접속키 탈취 경로와 공격자 신원을 밝히지 못했다고 보도됐다(중앙일보).
2. 안전성 확보조치 기준 제8조는 개인정보처리시스템 접속기록을 1년 이상, 5만 명 이상의 정보주체를 처리하거나 고유식별정보·민감정보를 처리하는 시스템은 2년 이상 보관하도록 정한다(안전성 확보조치 기준).
3. 무료 호스팅이나 서버리스 플랫폼의 기본 로그는 보관 기간이 짧은 경우가 많다. 관리자 화면에서 누가 언제 어떤 회원 정보를 조회·다운로드했는지 별도로 남기는 설계가 필요하다.

13.6. 테스트 데이터에 들어간 실제 개인정보

1. 개인정보위는 LG유플러스 사건에서 테스트 데이터 1천만 건 이상이 방치된 점을 지적했다(연합뉴스 · 개인정보위).
2. 개발용 DB를 만들 때 운영 DB를 통째로 복사하면 테스트 서버의 약한 보안이 실제 고객 정보에 그대로 적용된다. 개발·시연용 데이터는 가짜 데이터로 만들고, 운영 데이터가 필요하면 가명처리한 뒤 쓰는 편이 안전하다.

13.7. 크리덴셜 스터핑과 로그인 방어

1. GS리테일은 크리덴셜 스터핑을 장기간 탐지하지 못해 과징금 128억 3,600만 원을 받았다(이데일리 · 개인정보위).
2. SK스토아는 4,400만 회에 이르는 로그인 시도 끝에 12만 5천여 명의 정보가 유출됐다(연합뉴스 · 개인정보위).
3. 안전성 확보조치 기준 제5조 제6항은 일정 횟수 이상 인증에 실패하면 접근을 제한하는 등 필요한 조치를 하도록 정한다. 로그인 실패 횟수 제한, 이상 접속 알림, 2단계 인증 선택지는 바이브코딩 앱에도 처음부터 넣어 둘 기능이다.

14. 개인정보보호법상 개발자가 지켜야 할 의무

개인정보 보호법은 업무를 목적으로 개인정보파일을 운용하기 위해 개인정보를 처리하는 공공기관, 법인, 단체 및 개인을 개인정보처리자로 정의한다(법 제2조). 회원가입이나 예약 폼으로 이름과 연락처를 모아 서비스를 운영한다면 1인 개발자도 아래 의무를 진다. 조문은 2026년 9월 11일 시행 법률과 시행령, 2026년 7월 1일 시행 고시 원문 기준이다.

• 위반 시 칸의 과태료는 제75조 원문의 상한이며, 실제 금액은 위반 정도에 따라 정해진다. 수탁자 관리·감독 소홀로 수탁자가 법을 어긴 경우도 과징금 대상이다(제64조의2 제1항 제5호).
• 같은 행위에 과징금이 부과되면 과태료는 부과하지 않는다(법 제76조).
• 2025년 개정 고시의 일부 조항은 발령 1년 뒤 시행되도록 유예됐다(정책브리핑 고시 개정 안내).

15. 안전성 확보조치 기준 숫자로 보기

개인정보의 안전성 확보조치 기준(개인정보보호위원회 고시 제2026-9호)은 법 제29조와 시행령 제30조의 세부 기준이다. 바이브코딩 앱에서 바로 설계에 반영할 숫자와 항목을 원문에서 골랐다.

• 2025년 10월 31일 발령된 개정 고시(제2025-9호) 부칙 제1조는 제4조 제1항 제12호·제13호, 제5조 제1항·제6항, 제6조 제2항, 제8조 제1항·제2항을 발령한 날의 1년 후부터 시행하도록 정했다(제2025-9호 원문). 위 표에서 제5조 제6항, 제6조 제2항, 제8조 제1항은 개정 전후 요지가 같고, 내용이 달라지는 제8조 제2항은 종전 규정과 개정 규정을 함께 적었다.
• 개정 규정이 시행되기 전까지 효력이 있는 종전 고시(제2023-6호) 제8조 제2항은 개인정보처리시스템의 접속기록 등을 월 1회 이상 점검하고, 개인정보 다운로드가 확인되면 내부 관리계획 등에 따라 그 사유를 반드시 확인하도록 정하고 있다(제2023-6호 원문).
• 개인정보위 안전성 확보조치 기준 안내서(조항별 해설과 예시): 개인정보위 안내서

16. 유출을 알았을 때 72시간 대응

시행령 제39조와 제40조는 유출을 알게 된 때부터 72시간을 기준으로 삼는다. 2026년 3월 법 개정으로 유출 가능성만 확인된 단계의 통지 의무도 새로 생겼다.

실제 처분에서도 통지·신고 지연은 따로 지적됐다. 디올은 72시간이 지나 통지했고(연합뉴스 · 개인정보위), 모두투어네트워크는 통지가 2개월 늦었으며(SBS · 개인정보위), 쿠팡이츠 사건도 신고 지연이 처분 사유에 들어갔다(연합뉴스 · 개인정보위). 티빙은 침해사고를 인지한 뒤 24시간 안에 한국인터넷진흥원에 신고할 정보통신망법상 의무를 지키지 못해 과기정통부 과태료가 예정됐다(중앙일보).

• 유출을 알게 된 시점, 차단 조치, 확인된 항목을 시간 순으로 기록해 두면 통지문과 신고서를 빠르게 쓸 수 있다.
• 통지문에는 비밀번호 변경, 스미싱 주의처럼 이용자가 바로 할 수 있는 피해 최소화 방법을 구체적으로 적는다.
• 개인정보 포털 신고 화면과 신고 양식을 미리 확인해 두면 72시간 안에 처리하기 쉽다.

17. 과징금은 얼마나 나올까

과징금은 전체 매출액의 3%를 넘지 않는 범위가 기본이며, 위반과 관련 없는 매출은 빼고 산정한다. 매출이 없거나 산정이 어려우면 20억 원 이하다. 2026년 개정으로 고의·중과실 반복 위반이나 1천만 명 이상 피해 등에는 매출액의 10%, 매출 산정이 어려운 경우 50억 원까지 높아졌다(법 제64조의2).

대기업 사례만 보면 먼 이야기 같지만, 규모가 작은 서비스나 개발 실수에도 수천만~수억 원이 부과된 사례가 있다. 아래 표는 개발 과정의 실수나 기본 보안 미비가 원인이었던 처분을 골랐다.

• 클래스유는 약 160만 명 규모에도 과징금이 5,360만 원이었다. 과징금은 피해 규모만이 아니라 매출액, 위반 기간, 보호 노력 등을 함께 고려해 산정된다.
• 한화호텔앤드리조트와 행정안전부 사례는 해킹이 아니라 개발 과정의 오류만으로도 처분 대상이 된다는 점을 보여 준다.
• 과징금과 별개로 손해배상 청구와 서비스 신뢰 하락이 뒤따른다. 멜로밍은 유출 뒤 서비스 종료를 결정했다고 보도됐다.

18. 바이브코딩 개인정보 체크리스트

개인정보를 받는 기능을 배포하기 전에 아래 항목을 한 번씩 확인하면 위 사례에서 반복된 원인 상당수를 피할 수 있다.

그림 3. 바이브코딩 앱이 개인정보를 받기 전 확인할 8가지. 법령 원문을 요약한 것으로 법률 자문은 아니다.

함께 보면 좋은 글로는 바이브 코딩과 개인정보보호법, 바이브코딩 보안 위협 총정리, 회원가입 직접 만들면 망하는 이유, 관리자 페이지 보안 설정, 티빙 개인정보 유출 CI DI 뜻, 개인정보 유출 사고 2차 인증·계정 보호이 있다.

19. 출처

사례별 근거 기사와 공식 발표는 각 표의 사례 칸에 링크했다. 법령과 공통 근거는 아래와 같다.

• 개인정보 보호법(국가법령정보센터, 2026년 9월 11일 시행): 법령 원문
• 개인정보 보호법 시행령(2026년 9월 11일 시행): 시행령 원문
• 개인정보의 안전성 확보조치 기준(개인정보보호위원회 고시 제2026-9호): 안전성 확보조치 기준
• 개인정보위 안전성 확보조치 기준 안내서: 개인정보위 안내서
• 안전성 확보조치 기준 개정 고시 원문: 제2025-9호 · 종전 고시: 제2023-6호
• 안전성 확보조치 기준 개정 보도(2025년 10월 31일): 정책브리핑
• 티빙 민관합동조사단 조사 결과 브리핑: 정책브리핑
• 티빙 조사 결과 보도: 중앙일보 · 동아일보
• 쿠팡 처분 발표(정책브리핑): 정책브리핑
• SK텔레콤 처분 발표: 개인정보위 보도자료
• KT 처분 발표: 개인정보위 보도자료
• Supabase Row Level Security 문서: Supabase Docs
• Firebase 안전하지 않은 규칙 차단 문서: Firebase Docs
• 그 밖의 개인정보위 처분 보도자료와 회사 공지는 각 사례표의 사례 칸에 기사 링크와 함께 걸었다.

이 글의 사례 수와 순위는 2026년 10월 8일까지 공개된 자료를 기준으로 했다. 조사 중인 사건은 이후 발표에 따라 규모와 처분이 달라질 수 있다.

20. 마무리

앞에서 다룬 최근 5년 개인정보 유출 사례와 개발자 의무의 핵심만 짧게 정리한다.

• 2021년 1월~2026년 10월 8일 공개 사례 143건 중 140건을 근거 기사와 함께 정리했고, SNS로만 알려진 3건은 언론 미확인으로 분리했다.
• 규모는 티빙 3,954만 계정, 쿠팡 약 3,370만~3,755만, SK텔레콤 2,324만여 명 순이다.
• 과징금은 쿠팡 6,246억 8,100만 원, SK텔레콤 1,347억 9,100만 원, KT 539억 7,900만 원 순이다.
• 반복되는 원인은 코드 속 접속키, 권한 검사 없는 API, 크리덴셜 스터핑, 관리자 계정 탈취, 짧은 로그 보관이다.
• 개인정보를 받는 1인 개발자도 개인정보처리자이며, 동의·최소 수집·처리방침·안전조치·72시간 통지와 신고 의무를 진다.
• 과징금 상한은 2026년 9월 11일부터 중대·반복 위반 시 전체 매출액의 10%까지 올라갔다.

「코드는 AI가 써 줘도 개인정보 책임은 서비스를 연 사람에게 남는다」 개인정보를 받는 기능을 배포하기 전에 체크리스트 10개 항목부터 확인하는 편이 사고 뒤 수습보다 훨씬 싸다. 이 글은 법령 원문과 공개 보도를 정리한 정보이며 개별 사안의 법률 자문을 대신하지 않는다.

자주 묻는 질문

• 최근 5년간 가장 큰 개인정보 유출 사건은 무엇인가?

  이 글의 140건 기준으로 티빙이 민관합동조사단 집계 3,954만 계정으로 가장 크다. 쿠팡은 초기 3,370만 계정, 개인정보위 기준 약 3,755만 명이며 SK텔레콤은 23,244,649명이다. 계정과 사람 단위가 섞여 있어 단순 비교에는 주의가 필요하다.

• 개인정보 유출 과징금이 가장 많이 나온 곳은 어디인가?

  개인정보위 과징금 기준으로 쿠팡이 6,246억 8,100만 원으로 가장 많고, SK텔레콤 1,347억 9,100만 원, KT 539억 7,900만 원이 뒤를 잇는다. 과태료와 금융위원회 등 다른 기관의 처분 금액은 이 비교에 넣지 않았다.

• 언론 미확인으로 분류한 3건은 왜 표에서 뺐나?

  데이터스트림즈, SK텔레콤 다크웹 판매 주장, 시큐브 3건은 다크웹 판매글이나 SNS 게시물로만 알려졌고 2026년 10월 8일 기준 기사나 공식 발표로 확인되지 않았다. 해커 측 주장을 사실처럼 옮기지 않기 위해 규모와 링크 없이 별도 표로만 남겼다.

• 혼자 만든 앱이나 사이트도 개인정보보호법을 지켜야 하나?

  개인정보 보호법 제2조 제5호는 업무를 목적으로 개인정보파일을 운용하기 위해 개인정보를 처리하는 개인도 개인정보처리자로 본다. 회원가입이나 예약 폼으로 이름과 연락처를 모아 서비스를 운영하면 동의, 최소 수집, 처리방침 공개, 안전조치, 유출 통지·신고 의무가 생긴다.

• 개인정보 유출을 알게 되면 언제까지 신고해야 하나?

  시행령 제39조와 제40조에 따라 유출을 알게 된 때부터 72시간 이내에 정보주체에게 통지하고, 1천 명 이상 유출, 민감정보·고유식별정보 유출, 외부 불법 접근에 의한 유출이면 72시간 이내에 개인정보위 또는 한국인터넷진흥원에 신고해야 한다.

• 접속기록은 얼마나 보관해야 하나?

  개인정보의 안전성 확보조치 기준 제8조는 개인정보처리시스템 접속기록을 1년 이상 보관하도록 하고, 5만 명 이상의 정보주체를 처리하거나 고유식별정보·민감정보를 처리하는 시스템은 2년 이상 보관하도록 정한다. 티빙은 6일치만 보관해 최초 침입 경로를 밝히지 못했다고 보도됐다.

• 티빙 유출은 바이브코딩과 어떤 관련이 있나?

  티빙은 바이브코딩으로 만든 서비스라는 근거는 없다. 다만 소스코드에 평문으로 적힌 운영환경 접속키 43개가 침입 확대의 원인이 됐고, 이런 하드코딩은 AI가 만든 예제 코드에서도 자주 나오는 패턴이라 바이브코딩 개발자가 특히 조심해야 할 사례다.

• Supabase나 Firebase를 쓰면 무엇을 확인해야 하나?

  Supabase는 노출된 스키마의 모든 테이블에 RLS를 켜고 서버용 비밀 키를 브라우저에 두지 말라고 안내한다. Firebase는 개발 중 열어 둔 오픈 액세스 규칙을 배포 전에 고치라고 한다. 로그아웃 상태와 다른 계정으로 직접 조회해 막히는지 확인하는 점검이 필요하다.

• 작은 서비스도 과징금을 받은 사례가 있나?

  있다. 엔에이치엔커머스는 122건 유출에 870만 원(보도), 클래스유는 5,360만 원, 국립항공박물관은 9,800만 원, 비즈니스온커뮤니케이션은 1억 3,700만 원의 과징금을 받았다. 한화호텔앤드리조트와 행정안전부처럼 개발 과정의 오류만으로 처분된 사례도 있다.

• 2026년 법 개정으로 과징금 상한이 어떻게 바뀌었나?

  2026년 9월 11일 시행 개인정보 보호법 제64조의2는 기본 상한을 전체 매출액의 3%로 두고, 고의·중과실로 1천만 명 이상 피해가 생기거나 3년 안에 같은 위반을 반복하는 경우 등에는 10%까지 부과할 수 있게 했다. 매출 산정이 어려우면 50억 원 이하다.