29CM 개인정보 16만 건 유출부터 GS리테일 과징금까지, 유통업계는 왜 계속 뚫리나

[핵심요약] 무신사가 운영하는 29CM에서 15만9852건의 개인정보가 유출됐고, 같은 주 GS리테일은 166만 회원 정보 유출로 128억원 과징금을 받았어요. 유통업계 개인정보 유출이 왜 반복되는지 짚어봐요.

2026년 8월 27일, 무신사가 운영하는 패션 플랫폼 29CM의 주문조회 API에서 외부의 비정상 접근이 발생해 고객 15만9852명의 개인정보가 새어나갔어요. 이름과 이메일, 휴대전화번호, 배송지 정보까지 유출된 회원도 2만1011명에 달해요. 같은 주인 8월 31일에는 개인정보보호위원회가 GS리테일에 128억3600만원의 과징금을 부과했다고 발표했어요 — GS샵과 GS25 회원 166만여 명의 정보가 크리덴셜 스터핑 공격으로 새어나간 데 대한 제재예요. 여기에 2025년 11월 퇴사자의 인증 토큰으로 3755만 명분이 유출돼 역대 최대인 6246억원 과징금을 받은 쿠팡 사례까지 겹치면서, 국내 유통업계 전반의 개인정보 관리 체계에 물음표가 붙고 있어요.

29CM부터 쿠팡까지, 유통업계를 덮친 유출 사고들

29CM 사고는 지난 8월 27일, 주문정보를 조회하는 연동 기능(API)에서 시작됐어요. 외부에서 이 API에 비정상적으로 접근해 회원 15만9852명의 정보를 빼갔는데, 다행히 결제정보나 아이디·비밀번호 같은 로그인 계정 정보는 유출 항목에서 빠졌어요. 29CM은 접근을 확인하자마자 경로를 차단하고 한국인터넷진흥원(KISA)에 자진 신고했고, 홈페이지에 30일간 개인별 유출 내역을 조회할 수 있는 기능도 열었어요.

비슷한 시기 GS리테일 소식도 들려왔어요. 신원 미상의 해커가 다른 사이트에서 유출된 아이디·비밀번호를 GS샵과 GS25 홈페이지에 무작위로 대입하는 '크리덴셜 스터핑' 공격을 벌였고, GS샵 회원 158만1025명과 GS25 회원 7만9128명의 이름·생년월일·연락처·주소가 새어나갔어요. 더 심각한 건 대응 속도예요. GS리테일은 동일 IP에서 대량 로그인 시도가 벌어지는데도 이를 탐지·차단할 장치가 없었고, GS25 유출을 파악한 뒤에도 GS샵에서 똑같은 공격이 한 달 넘게 이어진 걸 몰랐어요. 개인정보보호위원회는 8월 31일 이 사고에 128억3600만원의 과징금을 부과했다고 발표했어요.

가장 뼈아픈 선례는 쿠팡이에요. 2025년 11월 퇴사한 직원의 액세스 토큰이 무단으로 사용돼 3755만 명분의 정보가 빠져나갔는데, 쿠팡은 최초 침입 후 12일이 지나서야 고객 민원으로 이 사실을 알아챘어요. 개인정보보호법이 정한 72시간 내 통지 의무도 지키지 못했고, 결국 역대 최대인 6246억원의 과징금을 부과받았어요.

왜 유통업계에서 유독 반복될까요

세 사고는 침투 방식이 다 달라요. 29CM은 API 취약점, GS리테일은 크리덴셜 스터핑, 쿠팡은 퇴사자 계정 방치였어요. 그런데 공통점이 하나 있어요 — 온라인 쇼핑몰은 이름, 연락처, 배송지처럼 실제 배송에 꼭 필요한 개인정보를 수백만~수천만 건 단위로 쌓아두고 있다는 점이에요. 공격자 입장에서는 하나만 뚫어도 대규모 정보를 한 번에 확보할 수 있으니, 매력적인 표적이 될 수밖에 없어요.

더 큰 문제는 탐지와 대응 체계예요. GS리테일은 같은 공격이 한 달 넘게 반복되는 동안 이를 알아채지 못했고, 쿠팡은 침해를 인지하고도 법정 통지 기한을 넘겼어요. 아무리 침투 자체를 100% 막기 어렵다 해도, 얼마나 빨리 알아채고 얼마나 빨리 대응하느냐가 피해 규모와 제재 수위를 가르는 핵심이라는 걸 세 사고 모두 보여줘요. 특히 쿠팡 사례처럼 퇴사자 계정이 제때 회수되지 않으면, 정교한 외부 공격 없이도 내부 관리 실패만으로 최대 규모 유출이 벌어질 수 있다는 점도 눈여겨볼 대목이에요.

우리 회사도 대비하려면?

고객 개인정보를 다루는 온라인 서비스라면 이번 세 사고에서 공통으로 짚을 대비책이 있어요. 먼저 API 접근통제예요. 주문조회처럼 외부 연동이 필요한 API라도 인증 토큰의 유효기간을 짧게 두고, 비정상적으로 많은 요청이 들어오면 자동으로 탐지·차단하는 장치를 갖춰야 해요. GS리테일 사고처럼 동일 IP의 대량 로그인 시도조차 걸러내지 못하면, 크리덴셜 스터핑 같은 단순한 공격에도 백만 단위 정보가 새어나갈 수 있어요.

두 번째는 계정 생명주기 관리예요. 퇴사자·협력업체 계정은 퇴사·계약 종료 즉시 접근 권한을 회수해야 하는데, 쿠팡 사고는 이 기본 원칙이 무너지면 얼마나 큰 피해로 이어지는지 보여준 사례예요. 정기적으로 활성 계정 목록을 점검해서 더 이상 필요 없는 권한이 남아있지 않은지 확인하는 절차가 필요해요.

마지막으로 탐지 이후의 대응 속도예요. 개인정보보호법은 유출 인지 후 72시간 이내 통지·신고를 의무화하고 있는데, 이 골든타임을 지키려면 침해 여부를 판단하는 내부 프로세스와 보고 체계가 미리 정해져 있어야 해요. 사고가 난 뒤에 매뉴얼을 만들기 시작하면 이미 늦어요.

이런 신호, 놓치지 마세요

• 같은 IP나 계정에서 짧은 시간에 로그인 시도가 비정상적으로 몰린 적이 있는지 확인해 보세요.
• 주문조회·배송조회처럼 외부에 열어둔 API에 접근 로그와 이상 트래픽 알림이 설정돼 있는지 점검해 보세요.
• 퇴사한 직원이나 계약이 끝난 협력업체 계정이 아직 살아있지는 않은지 확인해 보세요.
• 개인정보 유출을 인지했을 때 72시간 내 신고·통지할 담당자와 절차가 문서로 정해져 있는지 확인해 보세요.
• 고객 개인정보 중 실제로 필요한 항목만 최소한으로 수집·보관하고 있는지 점검해 보세요.

Q. 우리 회사는 쇼핑몰이 아닌데도 해당되나요?

A. 네, 이번 사고들의 핵심은 외부와 연동되는 API와 계정 관리 소홀이에요. 회원 정보를 다루면서 외부 시스템과 데이터를 주고받는 서비스라면 업종과 무관하게 같은 위험에 노출돼 있어요.

Q. 전산 인력이 1~2명뿐인 중견기업도 크리덴셜 스터핑을 막을 수 있나요?

A. 대규모 보안팀이 없어도 동일 IP에서의 반복 로그인 시도를 차단하는 기능은 대부분의 로그인 보안 솔루션이나 웹방화벽(WAF)에 기본으로 들어있어요. 이미 쓰고 있는 인프라에 이 기능이 켜져 있는지부터 확인하는 것만으로도 첫걸음이 돼요.

Q. 퇴사자 계정 관리는 구체적으로 어떻게 시작하면 되나요?

A. 인사팀의 퇴사 처리와 IT팀의 계정 회수를 같은 날 동시에 진행하도록 절차를 연결하는 게 핵심이에요. 분기별로 활성 계정과 재직자 명단을 대조하는 점검만 정례화해도 방치된 계정을 크게 줄일 수 있어요.

29CM, GS리테일, 쿠팡까지 — 침투 경로는 제각각이었지만 결과는 같았어요. 국내 유통업계가 그동안 쌓아온 고객 개인정보가 얼마나 취약하게 관리돼 왔는지 드러난 셈이에요. 과징금 액수가 커지고 있다는 건 규제 당국의 시선도 그만큼 엄격해지고 있다는 신호예요. 다음 유출 사고의 주인공이 되지 않으려면, 지금 우리 회사의 API와 계정 관리부터 다시 들여다볼 때예요.

이런 사고를 막으려면 API나 계정이 뚫려도 핵심 데이터 백업까지는 손대지 못하는 구조가 필요해요. 물리적으로 분리된 이중 데이터 다이오드 방식의 디포트리스가 그 역할을 해줘요. 계정이 뚫려도 핵심 백업은 왜 안전한지 궁금하다면 여기서 확인해보세요.