국내 e-Commerce 플랫폼 시장을 선도하는 쿠팡에서 2025년 하반기, 사상 최악의 규모로 기록될 개인정보 유출 사고가 발생하였습니다. 이 사고는 고도화된 외부 APT(Advanced Persistent Threat) 공격이 아닌, 퇴직자 권한 관리 실패와 인증 아키텍처의 설계 결함이 복합적으로 맞물려 발생한 전형적인 내부자 위협(Insider Threat) 시나리오라는 점에서 업계 전반에 강한 경고음을 울리고 있습니다.

정부 조사 결과, 이번 사고는 지능화된 공격이라기보다는 기업의 관리 부실에 따른 결과라는 점이 확인되었습니다. 이는 역설적으로 더욱 심각한 시사점을 내포합니다. 최첨단 공격 기법이 아닌 기본적인 보안 위생(Security Hygiene)의 실패가 3,700만 명이 넘는 정보주체에게 직접적 피해 위험을 초래하였기 때문입니다.

본 포스팅은 민관합동조사단의 조사 결과와 개인정보보호위원회의 최종 의결 내용을 바탕으로, ISMS-P 심사원 및 실무 보안 담당자가 자사 아키텍처를 벤치마킹하고 컴플라이언스 체계를 점검하는 데 활용할 수 있도록 사고를 심층 분석합니다.

1. Incident Summary (사고 개요 및 규제 현황)

사고경위

구분 내용
사고 발생 추정 시점 2025년 4월 ~ 2025년 11월 (약 7개월간 지속)
최초 인지 시점 2025년 11월 18일 (비인가 조회 확인)
최초 공개 규모 고객 약 4,500명 개인정보 노출
최종 확인 규모 3,367만 3,817건 (민관합동조사단 기준)
공격 주체 전직 쿠팡 직원 (중국 국적, 수사 당시 출국 상태)
공격 경로 퇴사 전 탈취한 JWT 서명키 악용, 해외 서버 경유 무단 접근
개인정보위 의결 2026년 6월 11일 전체회의 의결, 과징금 6,246억 원 부과

침해 유형 및 자산

침해 영역은 쿠팡의 내부 API Gateway 서버 및 고객 계정 관리 시스템(Customer Data Platform)으로, 정상적인 로그인 절차를 거치지 않고 위조 JWT 토큰을 통해 고객 데이터베이스에 직접 접근한 형태입니다. 유출된 데이터 항목은 다음과 같습니다.

  • 이름, 이메일 주소
  • 배송지 주소, 전화번호
  • 최근 주문 내역
  • 공동현관 출입 비밀번호 2,609건 (준고유식별정보에 준하는 민감 정보)

결제 관련 카드 정보 및 로그인 자격증명(패스워드), 개인통관번호는 유출 범위에 포함되지 않은 것으로 조사되었습니다.

피해 Scale

전직 쿠팡 직원인 해커는 총 3,322만 명의 회원 개인정보와 최소 433만 명의 비회원 개인정보를 유출한 것으로 확인되었습니다. 개인정보보호위원회는 중복 조회 건수를 제외하고, 비회원의 배송지 정보 유출까지 가산하여 최종 정보주체 규모를 산정하였습니다. 이는 국내 단일 기업 개인정보 유출 사고로서는 사상 최대 규모에 해당합니다.

법적 행정처분

개인정보 유출에만 4,235억여 원, 이용자의 온라인 활동 무단 수집과 '납치광고' 관리 부실에 대해 2,011억여 원 등 총 과징금은 역대 최대인 6,247억 원이 부과되었습니다.

처분 내역을 세분화하면 다음과 같습니다.

처분 기관 위반 내용 처분 결과
개인정보보호위원회 개인정보 유출(안전조치 의무 위반) 과징금 4,235억여 원
개인정보보호위원회 이용자 온라인 활동 무단 수집, 납치광고 관리 감독 소홀 과징금 2,011억여 원
개인정보보호위원회 (합계) 과징금 6,246억 원 + 과태료 1,680만 원
개인정보보호위원회 쿠팡 풀필먼트 (경찰청 기자 71명 개인정보 무단 수집) 과징금 2억 2천만 원
과학기술정보통신부 정보통신망법 위반 (기술·관리적 보호조치 미흡, 침해사고 신고 지연) 시정명령 + 과태료
경찰청 웹 로그 삭제 등 조사 방해 행위 수사 의뢰

쿠팡은 약 5개월 치 접속 기록을 삭제하는 등 개보위 조사를 방해하였으며, 언론의 허위 보도에 대응하겠다며 경찰청 출입기자 71명의 인적사항을 무단 확보했던 사실도 드러났습니다.

2. Root Cause Analysis (공격 벡터 및 기술적 결함 분석)

TTPs (공격 기법): JWT 서명키 탈취 및 토큰 위조를 통한 API 인증 우회

이번 사고의 핵심 공격 벡터는 JWT(JSON Web Token) 서명키 탈취 후 유효 토큰 임의 생성(Token Forgery)입니다. 공격자는 재직 기간 중 JWT 서명키(Signing Key)를 사전에 확보하였으며, 퇴직 이후에도 해당 키가 폐기되지 않은 점을 악용하였습니다.

공격 메커니즘은 다음의 단계로 진행되었습니다.

  1. 키 사전 탈취(Pre-exfiltration): 공격자는 재직 시절 소스코드 저장소 또는 빌드 파이프라인 접근 권한을 이용하여, 소스코드 내 하드코딩된 JWT 서명키를 확보
  2. 유효 토큰 위조: 퇴직 후 외부에서 확보한 서명키로 서버가 신뢰하는 JWT 토큰을 직접 생성
  3. API Gateway 통과: 쿠팡의 관문(Gateway) 서버는 서명키 값이 일치하면 무조건 정상 접근으로 허용하는 구조였으며, 공격자가 사용한 키가 '진짜'였기에 시스템은 이를 의심 없이 통과시켰습니다.
  4. 장기간 대량 조회: 2025년 4월부터 11월까지 약 7개월에 걸쳐 수천만 건의 고객 개인정보를 순차적으로 조회 및 수집
  5. 해외 서버 경유: 접근 출처를 은닉하기 위해 해외 서버를 경유하여 역추적을 지연

Technical Vulnerabilities (기술적 취약점)

(1) JWT 서명키 하드코딩(Hardcoded Secret) — 시크릿 관리 부재

쿠팡은 서명키를 별도의 보안 저장소가 아닌 소스코드 내부에 포함시키는 '하드코딩' 방식으로 운영하였으며, 이 구조상 키를 변경하려면 소스코드를 수정하는 등 절차상 어려움이 있었습니다. 이러한 번거로움으로 인해 퇴사자가 발생했음에도 키를 갱신하지 않고 방치한 것으로 파악됩니다. 이는 비밀값(Secret) 관리의 근본적 실패로, HashiCorp Vault, AWS Secrets Manager 등 HSM(Hardware Security Module) 기반 시크릿 관리 체계가 전혀 구축되지 않았음을 의미합니다.

(2) API Gateway의 단일 인증 요소 의존 — 심층 방어(Defense-in-Depth) 미흡

JWT 서명 검증만을 유일한 인증 통제로 운영하였으며, 서명 유효성 이외의 추가 검증 로직(예: IP 범위 기반 허용 목록, 사용자 행위 프로파일링, 접근 컨텍스트 검증)이 존재하지 않았습니다. 이는 단일 실패 지점(Single Point of Failure) 아키텍처로, 서명키 하나의 유출이 전체 인증 체계를 무력화하는 구조적 결함입니다.

(3) 퇴직자 접근권한 회수(Off-boarding) 프로세스의 공백

정상적인 계정 탈퇴(Access Revocation) 절차가 작동했더라면 서명키는 즉시 무효화되었어야 합니다. 그러나 키 갱신 절차의 복잡성을 이유로 퇴직자 발생 후에도 키가 장기간 유효 상태로 방치되었다는 점은 IAM(Identity and Access Management) 정책의 심각한 공백을 드러냅니다.

(4) 이상행위 탐지(Anomaly Detection) 체계 부재

단일 출처(해외 서버)에서 7개월이라는 장기간에 걸쳐 수천만 건의 고객 계정 데이터를 순차 조회하는 행위는, 정상적인 서비스 트래픽과 명확히 구별되는 이상 패턴입니다. SIEM(Security Information and Event Management) 또는 UEBA(User and Entity Behavior Analytics) 기반의 API 이상행위 탐지 룰이 운영되었다면 조기 탐지가 가능했을 것으로 분석됩니다.

(5) 로그 관리 및 무결성 체계 부재

사고 인지 이후 쿠팡이 약 5개월 분량의 웹 접속 로그를 삭제한 사실은, 로그 보존 정책 및 로그 무결성 보장 체계(예: Immutable Log Storage, WORM 스토리지 적용)가 전무했음을 시사합니다. 이는 사후 포렌식 및 피해 범위 산정을 근본적으로 불가능하게 만드는 2차 보안 실패입니다.

3. Compliance Gap Analysis (법적·인증 기준 매칭)

개인정보 보호법 위반 매칭

위반 조항 조항 내용 쿠팡의 위반 행위
제29조 (안전성 확보조치 의무) 개인정보처리자는 개인정보가 분실·도난·유출·위조·변조 또는 훼손되지 아니하도록 안전성 확보에 필요한 기술적·관리적 및 물리적 조치를 하여야 한다 JWT 서명키 하드코딩 운영, 퇴직자 서명키 미폐기, API 단일 인증 구조 운영
제34조 (개인정보 유출 통지·신고 의무) 개인정보 유출 인지 후 72시간 이내 신고 의무 (정보통신망법 기준 24시간) 4,500명 수준으로 축소 신고 후, 수천만 건 유출 사실을 장기간 축소 보고
제26조 (수탁자 관리·감독) 개인정보처리자는 수탁자가 개인정보 처리 업무를 수행할 때 개인정보 보호 관련 법령을 준수하도록 지도·감독하여야 한다 납치광고 운영 광고파트너에 대한 관리·감독 소홀
제15조, 제17조 (개인정보 수집·이용 동의) 정보주체의 동의 없이 개인정보를 수집·이용하여서는 아니 된다 1,117만 명의 온라인 활동 정보를 동의 없이 무단 수집

정보통신망법 위반

  • 제45조(기술적·관리적 보호조치) 위반: 인증 체계 및 키 관리 시스템의 기본적 보호조치 미이행
  • 제48조의3(침해사고 신고) 위반: 24시간 이내 신고 의무 위반 (피해 규모 축소 신고)

ISMS-P 인증 통제 항목 Gap 분석 (심사원 결함 지적 관점)

[결함 1] 2.5.2 사용자 계정 관리 — 퇴직자 접근권한 회수 절차 부재

ISMS-P 인증기준 2.5.2는 인사이동, 퇴직 등 인원 변경 시 해당 계정의 접근권한을 지체 없이 회수할 것을 요구합니다. 본 사고에서는 퇴직자 발생 시점과 서명키 폐기 시점 간에 유의미한 시간적 공백이 존재하였으며, 기술적 번거로움을 이유로 장기간 방치한 사실이 확인됩니다. 이는 '퇴직자 계정 및 접근권한 즉시 회수' 프로세스의 명백한 통제 실패로, 심사 시 즉각 결함 지적 대상에 해당합니다.

[결함 2] 2.6.2 정보시스템 접근 — API 인증 아키텍처의 단일 실패 지점

ISMS-P 2.6.2는 정보시스템에 대한 접근통제 정책 수립 및 다단계 인증 체계 구현을 요구합니다. 서명키 일치 여부만으로 무조건 접근을 허용하는 Gateway 구조는 다단계 접근통제 원칙(Defense-in-Depth)에 정면으로 위배됩니다. 특히 대량의 고객 데이터에 접근 가능한 내부 API에 대해 추가적인 컨텍스트 기반 인증(접근 IP, 시간대, 조회 패턴 등)이 전혀 적용되지 않았다는 점은 중요 결함(Major Finding)으로 분류됩니다.

[결함 3] 2.9.4 로그 및 접속기록 관리 — 로그 무결성 및 보존 기간 미준수

ISMS-P 2.9.4는 개인정보처리시스템 접속 기록의 안전한 보관과 무결성 보장을 명시합니다. 쿠팡이 약 5개월 분량의 접속 로그를 규제기관의 자료 보전 명령에도 불구하고 삭제한 사실은 이 통제 항목의 심각한 결함일 뿐만 아니라, 형사상 증거인멸에도 해당할 수 있는 중대한 사안입니다.

[결함 4] 2.10.1 보안시스템 운영 / 2.10.2 취약점 점검 및 조치 — 이상행위 탐지 부재

ISMS-P 2.10.1은 침해사고 예방을 위한 보안 모니터링 체계 구축을 요구합니다. 7개월에 걸쳐 반복적으로 대규모 고객 데이터를 조회하는 이상 API 호출 패턴이 단 한 차례도 탐지·알람되지 않았다는 사실은, 실효성 있는 SIEM/UEBA 운영 체계가 존재하지 않았음을 의미합니다. 행위 기반 이상 탐지 룰의 부재 또는 임계값 미설정은 명백한 결함으로 지적되어야 합니다.

[결함 5] 2.13.1 보호대책 점검 — 수탁자 관리감독 체계 부재

납치광고 사태에서 드러났듯, 광고 파트너사에 대한 개인정보 처리 관련 관리·감독 체계가 존재하지 않았습니다. 이는 ISMS-P 2.13.1 위탁업무 보안 통제 항목의 결함으로, 수탁자에 대한 정기적 점검, 계약상 보안 조건 명시, 위반 시 통제 메커니즘의 부재로 분석됩니다.

4. Mitigation Strategies (실무자를 위한 아키텍처 보완 대책)

[1] 시크릿 관리 아키텍처 전면 재설계: 하드코딩 제거 및 HSM/Secret Manager 도입

JWT 서명키, API 키, DB 자격증명 등 모든 시크릿 값은 소스코드 및 설정 파일에서 완전히 분리되어야 합니다. HashiCorp Vault, AWS Secrets Manager, Azure Key Vault와 같은 중앙화된 시크릿 관리 솔루션을 도입하고, 런타임 시점에 환경변수(Environment Variable) 또는 Sidecar 방식으로 키를 주입하는 구조로 전환해야 합니다. 소스코드 저장소(Git 등) 전체에 대해 트러플호그(TruffleHog), GitLeaks 등 시크릿 스캐너를 CI/CD 파이프라인에 강제 통합하여 하드코딩 시크릿의 커밋 자체를 차단해야 합니다.

[2] 퇴직자 Off-boarding 프로세스 자동화: Zero Standing Privilege 원칙 적용

퇴직 발령 즉시 연동되는 자동화된 계정·권한 폐기 워크플로를 구축해야 합니다. HR 시스템과 IAM 솔루션을 SCIM(System for Cross-domain Identity Management) 프로토콜로 통합하여, 퇴직 처리와 동시에 관련 서명키, 접근 토큰, SSH 키, API 자격증명 일체가 자동 폐기(Revoke)되도록 설계합니다. JWT의 경우, 단기 유효 토큰(Short-lived Token, 예: 15분 이내 만료) 정책과 서명키 자동 로테이션(Key Rotation) 주기를 의무화해야 합니다.

[3] API Gateway에 다중 인증 레이어(Multi-Layer Authentication) 적용

서명 유효성 검증을 1차 관문으로 하되, 다음의 추가 검증 레이어를 순차적으로 적용하는 심층 방어 구조를 구성해야 합니다. ① 요청 출처 IP에 대한 허용 목록(Allowlisting) 또는 지리적 이상 탐지(Geo-anomaly Detection), ② 동일 토큰·사용자 ID로 과도한 API 호출 시 자동 차단하는 Rate Limiting 및 Request Throttling, ③ 특정 시간대·디바이스 핑거프린트 등 컨텍스트 기반 위험 점수(Risk Scoring)를 산정하는 Adaptive Authentication 엔진 적용. 특히 대규모 고객 데이터 접근 API는 별도의 Zero Trust 정책을 적용하여 매 요청마다 재검증을 수행하도록 설계합니다.

[4] API 행위 기반 이상 탐지(UEBA) 룰 구축 및 SOC 연동

SIEM에 다음의 탐지 룰(Detection Rule)을 구현하고 임계값을 튜닝해야 합니다. ① 단일 토큰/IP에서 분당 N건 이상의 고객 계정 조회 발생 시 즉시 Alert, ② 업무 시간 외(야간, 주말) 또는 해외 IP 기반의 내부 API 대량 호출 시 자동 차단 + Tier-1 에스컬레이션, ③ 퇴직 처리된 사용자 ID 또는 만료 예정 토큰의 접근 시도 시 Zero-tolerance Alert. API 응답 본문 샘플링 기반의 DLP(Data Loss Prevention) 정책을 API Gateway 레벨에서 적용하여, 개인정보가 포함된 대량 응답 스트림을 실시간 인터셉트하는 체계도 병행 구축해야 합니다.

[5] 불변 로그 저장소(Immutable Log Storage) 구축

모든 개인정보처리시스템의 접속 기록은 Write-Once-Read-Many(WORM) 정책이 적용된 별도의 로그 저장소(예: AWS S3 Object Lock, Azure Blob Immutable Storage)에 실시간 스트리밍 복제하여 보관해야 합니다. 운영 인원이라 할지라도 로그 삭제가 원천 불가능한 구조를 설계함으로써, 사고 발생 시 포렌식 무결성을 보장하고 규제기관의 증거 보전 요구에 즉시 대응할 수 있어야 합니다. 로그 보존 기간은 개인정보 보호법 시행령 및 ISMS-P 기준에 따라 최소 6개월~1년 이상을 유지해야 합니다.

[6] 수탁자(파트너사) 보안 감리 프로그램 정례화

광고 파트너, 물류 협력사, IT 수탁사 등 개인정보를 처리하거나 내부 시스템에 접근하는 모든 수탁자를 대상으로, 연 1회 이상 기술적 보안 점검(취약점 스캔, 접근권한 감사)과 계약 조항 이행 여부 감리를 수행해야 합니다. 수탁 계약서에는 개인정보 보호법 제26조에 의거한 보안 이행 기준과 위반 시 즉시 계약 해지 및 손해배상 조항을 명문화해야 합니다.

[7] 침해사고 신고·통지 프로세스의 에스컬레이션 매트릭스 정비

개인정보 보호법 및 정보통신망법의 신고 의무 타임라인(24~72시간 이내)을 준수하기 위한 에스컬레이션 매트릭스(Escalation Matrix)를 사전에 문서화하고, 반기 1회 이상 모의 훈련(Tabletop Exercise)을 수행해야 합니다. 최초 인지 시점부터 피해 규모 추정 → CISO/CPO 보고 → 개인정보위/과기정통부 신고 → 정보주체 통지까지의 전 과정을 플레이북(Runbook)으로 정형화하고, 초기 피해 과소 신고로 인한 추가 행정처분 리스크를 차단해야 합니다.

5. Conclusion & Takeaway

이번 쿠팡 사고는 '고도화된 공격을 막지 못한 것'이 아니라, 기초 보안 원칙의 붕괴가 사상 최대 규모의 개인정보 유출로 이어진 사례입니다. 개인정보보호위원회 위원장은 이번 사고가 고도의 해킹 방법이 아닌 쿠팡의 기본적인 안전관리체계 미비 및 관리 소홀로 인해 발생한 것이라고 명시하였습니다. 이 한 마디는 국내 모든 플랫폼 보안 조직이 겸허히 수용해야 할 경고입니다.

특히 세 가지 정보보호 거버넌스적 시사점이 도출됩니다.

첫째, 기술 부채(Tech Debt)는 곧 보안 부채(Security Debt)입니다. 서명키 하드코딩이라는 오랜 기술 부채는 단순한 개발 관행의 문제가 아니라, 퇴직자 관리라는 인적 보안 프로세스와 결합되는 순간 치명적인 공격 벡터로 전환되었습니다.

둘째, 보안 가시성(Visibility)의 부재는 침묵 속의 재앙입니다. 7개월간 탐지되지 않은 대규모 API 스크래핑은, 조직이 자사의 데이터 흐름과 접근 패턴에 대한 실시간 가시성을 확보하지 못했을 때 어떤 결과가 초래되는지를 적나라하게 보여줍니다.

셋째, 사고 대응 과정에서의 투명성 실패는 처분을 배가시킵니다. 피해 규모 축소 신고, 접속 로그 삭제, 조사 비협조는 원래의 위반 행위에 더해 신뢰 손상과 규제 제재 가중이라는 이중의 손실을 초래하였습니다.

개인정보보호위원회는 이번 처분이 국민 생활과 밀접한 온라인 플랫폼 전반의 보안 투자 확대와 내부 통제 강화를 유도하는 계기가 되길 바란다고 밝혔습니다. 6,246억 원이라는 과징금은 단순한 벌금이 아니라, 보안 투자를 '비용'이 아닌 '필수 인프라'로 재정의해야 한다는 규제 당국의 강력한 시그널로 해석해야 합니다.

자사의 API 인증 아키텍처에서 서명키 하드코딩 여부를 점검하고, 퇴직자 접근권한 회수 프로세스의 자동화 수준을 진단하는 것이 이 사고로부터 얻어야 할 최우선 실무 과제입니다. 본 분석 내용 중 자사 환경에의 적용 방안이나 특정 통제 항목에 대한 심화 논의가 필요하신 분들의 의견을 환영합니다.

자료 출처

저작자표시 비영리 동일조건 (새창열림)

+ Recent posts

티스토리툴바