국내 유명 온라인 쇼핑몰과 미용 의료 플랫폼을 시작으로 시중은행과 저축은행에 이르기까지 대규모 고객 정보 유출 사고가 연쇄적으로 발생했습니다.
단순한 개별 기업의 전산 오류나 돌발적인 침입이 아니라, 8월 말부터 동일한 공격 수법이 표적을 바꾸어가며 이어진 체계적인 사이버 공격으로 드러났습니다.
이번 연쇄 해킹 사건의 구체적인 피해 규모와 공격 수법, 핵심 원인으로 지목된 API 인가 누락 문제, 그리고 2차 금융 피해 방지 요령을 상세히 정리해 드립니다.
무신사 29CM에서 금융권까지 이어진 연쇄 해킹 전말
이번 침해 사고는 패션 e커머스 플랫폼에서 첫 징후가 포착된 이후 플랫폼과 제1·2금융권으로 급속히 번져나갔습니다.
공격자는 데이터베이스(DB) 자체를 부수고 들어오는 방식 대신, 외부와 연결된 데이터 조회 창구를 집중적으로 공략했습니다.
무신사 29CM 주문정보 유출과 정부 제보
사태의 시작은 8월 27일 무신사가 운영하는 셀렉트숍 '29CM'의 주문정보 조회 API 비정상 접근 사고였습니다.
이 사고로 총 15만 9,852건의 고객 정보가 유출되었으며, 그중 2만 1,011건은 이름, 이메일, 전화번호와 함께 상세 배송지 정보까지 고스란히 포함되었습니다.
배송지 정보는 이용자가 실제 구매한 상품명과 주소가 묶여 있어, 택배 배송 오류를 빙자한 정밀 스미싱 문자에 악용될 위험이 매우 큽니다.
해커로 추정되는 인물은 이후 과기부와 KISA에 취약점 관련 제보 메일을 보냈고, 이를 분석한 정부 당국이 기업들에 통보하면서 추가 피해 사실이 드러나기 시작했습니다.
강남언니 22만 건 유출과 민감 의료 데이터 노출
9월 4일에는 국내외 누적 가입자 800만 명을 보유한 대표 미용의료 플랫폼 '강남언니'의 상담조회 API가 뚫렸습니다.
이로 인해 한국인과 일본인 4만 8,000명을 포함한 총 22만 명의 이용자 데이터가 외부로 유출되었습니다.
단순 연락처를 넘어 시술 항목, 상담 병원 및 의사 정보, 수술 전후 사진, 상담 메모 등 유출 시 심각한 사생활 침해를 부르는 민감 정보가 대거 빠져나가 파장이 커졌습니다.
시중은행과 예가람저축은행 등 금융권 전산망 침투
9월 28일을 전후해 공격 대상은 시중은행과 저축은행으로 확대되었습니다.
신한은행은 대출모집인 간편조회 시스템을 통해 고객 약 2만 5,000명의 이름, 연락처, 연소득, 대출한도 데이터가 빠져나갔습니다.
KB국민은행은 직원용 모바일 업무지원 시스템에서 119명, 하나은행은 89명의 개인정보가 유출되었으며, 예가람저축은행 역시 약 4만 명의 고객 데이터가 유출된 것으로 추산되었습니다.
우리은행과 NH농협은 비정상 공격 징후를 조기에 감지하고 자체 차단 시스템을 가동하여 정보 유출 피해를 막아냈습니다.
해킹의 핵심 원인: 인증은 통과하고 인가는 빠진 API 허점
이번 연쇄 유출 사고는 대형 서버의 중앙 데이터베이스를 직접 탈취한 것이 아니라, 정상적인 조회 창구의 규칙을 악용한 결과입니다.
전문가들은 보안 설계의 가장 기본적인 두 축인 '인증'과 '인가' 중 한 축이 무너진 점을 핵심 원인으로 지목합니다.
API 조회 창구의 작동 방식과 파라미터 변조
API(Application Programming Interface)는 모바일 앱과 서버가 데이터를 주고받는 공식적인 통신 창구입니다.
이용자가 스마트폰 앱 화면에서 조회 버튼을 누르면, 앱은 서버 창구로 특정 식별 번호가 적힌 요청 전문을 전송합니다.
해커는 앱의 화면 인터페이스를 거치지 않고 서버 API 창구에 직접 통신 전문을 보내는 방식을 취했습니다.
자신의 고유 번호 대신 타인의 고객번호나 주문번호를 순차적으로 변경해 전송하면서 방대한 데이터를 한 건씩 긁어모았습니다.
로그인(인증)과 조회 권한(인가)의 치명적 분리
보안 통제는 사용자가 누구인지 확인하는 '인증(Authentication)'과, 요청한 정보에 접근할 자격이 있는지 확인하는 '인가(Authorization)'로 나뉩니다.
이번에 피해를 입은 시스템들은 로그인 단계의 신원 확인은 거쳤으나, 요청받은 데이터가 로그인한 당사자의 소유인지 확인하는 절차를 생략했습니다.
즉, 외부인이 업무용 계정이나 정상 절차를 통해 시스템에 접속한 뒤 다른 사람의 번호로 조회를 요청해도 서버가 아무런 검증 없이 타인의 정보를 회신해 준 것입니다.
강력한 보안 장치가 갖춰진 대고객 뱅킹 앱 대신, 외부 활동이 잦은 모집인이나 외주 인력이 사용하는 상대적으로 취약한 업무용 시스템이 손쉬운 표적이 되었습니다.
AI 침투 도구의 악용과 다크웹 계정 유통 실태
이번 침해 사고가 기존 해킹과 차별화되는 가장 큰 특징은 고도화된 인공지능(AI) 자동화 도구가 실전 공격에 직접 투입되었다는 점입니다.
탈취된 정보는 이미 해외 온라인 플랫폼을 통해 암거래 시장으로 흘러 들어가고 있습니다.
오픈소스 AI 침투 도구 ARTEX의 실전 동원
금융보안원의 추적 결과 공격자 IP 환경에서 중국어 기반의 오픈소스 AI 자율 침투 도구인 'ARTEX'가 가동된 정황이 공식 확인되었습니다.
공격 서버 페이지에는 해당 도구의 콘솔 간판이 그대로 노출되어 있었습니다.
ARTEX는 본래 시스템 방어 역량을 점검하기 위한 화이트해커용 경진대회 우승 프로젝트였으나, 실제 현장에서는 보안 구멍을 탐색하고 요청값을 자동으로 조작하는 공격 무기로 변질되었습니다.
AI 에이전트가 투입되면서 과거 수작업으로 진행되던 파라미터 변조와 취약점 탐색이 자동화되어 대량의 데이터가 단시간에 유출되었습니다.
해외 온라인 암거래 시장의 한국 완제품 계정 유통
빼돌려진 개인 식별 데이터는 2차 수익화 단계로 빠르게 이어지고 있습니다.
중국 주요 전자상거래 사이트와 중고거래 플랫폼에서는 국내 주요 플랫폼의 '한국 완제품 계정'이 공공연히 매물로 등록되었습니다.
완제품 계정이란 본인 인증과 휴대전화 실명 인증 절차를 모두 통과하여 구매 즉시 로그인해 사용할 수 있는 상태의 계정을 뜻합니다.
단순 미인증 계정은 수백 원 선에 거래되지만, 실명과 연락처 인증이 완료된 계정은 수만 원대에 거래되며 불법 마케팅, 보이스피싱, 명의 도용 범죄의 숙주로 악용되고 있습니다.
이용자 2차 피해 방지 및 금융 소비자가 취해야 할 조치
유출된 데이터에는 이름, 휴대전화 번호, 연소득, 대출한도, 상세 배송지 등 개인을 정밀하게 특정할 수 있는 정보들이 망라되어 있습니다.
금융 소비자와 해당 서비스 이용자는 추가적인 금전적·사회적 피해를 방지하기 위해 신속한 자구책을 마련해야 합니다.
피싱 및 스미싱 문자메시지 식별 요령
배송지 정보가 노출된 이용자라면 택배 오배송, 통관 보류, 배송 주소지 정정을 사칭한 문자메시지 내 인터넷 링크(URL)를 절대 클릭하지 말아야 합니다.
대출한도 및 소득 정보가 유출된 금융권 이용자는 저금리 대환대출이나 정부 지원 대출을 미끼로 앱 설치를 요구하는 전화에 각별히 유의해야 합니다.
출처가 불분명한 문자나 알림톡에 포함된 인터넷 주소는 악성 앱 설치 파일(APK)로 연결되므로 즉시 삭제하는 것이 안전합니다.
연계 계정 비밀번호 변경과 보안 설정 강화
피해 대상 기업에 가입되어 있다면 포털이나 타 금융 사이트와 동일하게 설정된 비밀번호를 즉시 변경해야 합니다.
각 금융사에서 무료로 제공하는 '개인정보 노출자 사고예방 시스템'에 등록하면 본인 명의의 신규 계좌 개설이나 카드 발급을 사전에 차단할 수 있습니다.
또한 모바일 뱅킹 및 주요 플랫폼 계정의 2단계 인증(2FA)을 필수로 활성화하여 도용 위험을 원천 차단하는 습관이 중요합니다.
자주 묻는 질문
Q1. 일반 고객이 사용하는 은행 뱅킹 앱에서도 돈이 빠져나갈 위험이 있나요?
A1. 대고객 인터넷뱅킹과 스마트폰 뱅킹 앱의 전자금융망 자체가 직접 해킹된 것은 아니므로 계좌에서 예금이 즉시 무단 인출될 위험은 낮습니다. 다만 유출된 소득 및 대출 정보를 토대로 한 정교한 맞춤형 보이스피싱과 스미싱 공격이 발생할 수 있으므로 전화나 문자를 통한 금융 요구에 각별히 주의해야 합니다.
Q2. 예가람저축은행이나 29CM 등 피해 플랫폼 이용자가 지금 당장 해야 할 일은 무엇인가요?
A2. 해당 사이트의 로그인 비밀번호를 즉시 변경하고, 동일한 아이디와 비밀번호를 사용하는 다른 웹사이트의 계정 정보도 함께 수정해야 합니다. 아울러 택배 배송 조회나 고객센터를 사칭해 전송되는 문자메시지 내 링크는 절대로 접속하지 않아야 합니다.
Q3. API 인가 누락 취약점을 근본적으로 방어하려면 어떻게 해야 하나요?
A3. 서버 개발 시 이용자가 정상적으로 로그인했는지만 확인하는 단순 '인증'을 넘어, 조회 요청한 데이터의 식별자가 로그인한 사용자의 실제 소유인지 대조하는 '인가 검증' 로직을 모든 API에 필수 적용해야 합니다. 또한 동일 IP나 계정에서 단시간에 반복적인 조회가 발생하는 비정상 패턴을 감지하고 차단하는 속도 제한(Rate Limiting) 조치가 병행되어야 합니다.