배달 플랫폼 플라이 해킹 사건 정리. 회사 공식 33만 건과 해커 주장 4790만 건의 간극, SSG닷컴까지 번진 재위탁 피해 전말.
배달 플랫폼 하나가 뚫리면 몇 단계를 거쳐 몇 명까지 영향을 받을까. 국내 배달 대행 플랫폼 플라이(FLY)가 2026년 8월 침해를 인정하면서, 이 질문에 대한 답이 SSG닷컴 고객 통지 문자로 구체화됐다.
회사가 공식 확인한 유출 의심 건수는 약 33만 건이다. 그런데 같은 사건을 두고 해커는 다크웹 포럼에서 4,790만 건, 46.6GB 규모라고 주장하며 6만 달러에 판매를 시도했다. 두 숫자 사이의 간극이 145배에 달한다.
플라이는 라이더(배달기사)·가맹점·주문 고객 세 축의 개인정보를 다루는 배달 대행 플랫폼이다. 이런 플랫폼은 자사 서비스만 운영하는 게 아니라, SSG닷컴 '바로퀵' 같은 대형 커머스의 즉시배송을 바로고 등 중간 사업자를 거쳐 재위탁받아 처리하는 경우가 많다. 이 구조에서는 최종 이용자(SSG닷컴 고객)가 자신의 배송지 정보를 몇 단계 떨어진 하청 업체 서버가 들고 있다는 사실을 알기 어렵다.
공격자의 동기는 전형적인 데이터 판매형이다. 시스템을 마비시키는 랜섬웨어가 아니라, 탈취한 데이터를 다크웹에서 현금화하는 방식을 택했다.
플라이 측은 외부의 비인가 접근이 있었다는 사실만 공식 확인했고, 구체적인 침투 경로는 "조사 중"이라며 공개하지 않았다. 반면 해커 측은 플라이가 사용하던 Firebase의 Firestore·Cloud Storage에 별도 인증 절차 없이 읽기·쓰기가 가능한 상태였다고 주장했다. 이 주장은 공격자의 일방적 진술일 뿐 회사나 수사기관의 공식 확인을 거치지 않았다는 점을 감안해야 한다.
이 타임라인에서 눈에 띄는 건 최초 침해 추정 시점(8월 14일)부터 해커가 다크웹에 데이터를 올린 시점(8월 18일)까지 나흘밖에 걸리지 않았다는 점이다. 회사가 KISA를 통해 사고를 인지한 게 8월 15일이니, 인지 이후에도 데이터 유출을 막기엔 이미 늦은 시점이었다.
회사가 공식 확인한 유출 의심 항목은 관리자·라이더의 성명·연락처·주소·계좌정보·주민등록번호, 가맹점의 성명·생년월일·상호명·사업자등록번호·주소, 그리고 주문 고객의 주소·일부 연락처·공동현관 비밀번호다.
해커 측이 주장하는 목록은 이보다 훨씬 방대하다. 라이더 11,629명의 주민등록번호·평문 비밀번호·계좌정보, 주문 데이터 약 616만 건(주소·GPS 좌표·공동현관 비밀번호 포함), 가맹점 정보 8,611개, 결제 API 키 7,700개 이상, 알림 기록 3,830만 건, 접속 로그 344만 건이다. 이 항목들은 회사의 공식 확인 목록에는 들어있지 않다. 즉 두 목록 중 어느 쪽이 실제에 가까운지는 아직 검증되지 않은 상태다.
실제 확산 사례는 확인됐다. SSG닷컴은 '바로퀵' 즉시배송을 이용한 고객 약 40명에게 배송지 주소와 공동현관 비밀번호가 유출됐다고 통지했다. 경로는 SSG닷컴이 바로고에, 바로고가 다시 플라이에 배송을 재위탁하는 구조였고, 플라이의 침해가 그 체인 끝단의 SSG닷컴 고객에게까지 전달된 것이다.
해커 측 주장대로 클라우드 데이터베이스에 인증 없는 접근이 가능했다면, 이런 사고의 흔적은 대개 서버 침해처럼 요란하지 않다. 정상적인 애플리케이션 트래픽과 구분되지 않는 API 호출로 위장되기 때문에, 방화벽 로그만으로는 이상 징후를 잡기 어렵다.
실무에서 흔히 쓰이는 탐지 단서는 두 가지다. 첫째, 짧은 시간에 대량의 레코드를 순차 조회하는 패턴이다. 정상 사용자라면 하루에 자기 주문 몇 건만 조회하지, 수백만 건을 훑지 않는다. 둘째, 애플리케이션 서버가 아닌 출처(개발자 로컬 환경, 알려지지 않은 클라우드 리전)에서의 직접 접근 시도다. 플라이는 사고 이후 "비정상 접근 경로 차단"과 이상행위 모니터링 강화를 조치했다고 밝혔는데, 이는 이런 접근 패턴 감시 체계가 사고 전에는 충분하지 않았음을 방증한다.
이 사건의 핵심은 유출 규모 그 자체가 아니라, 피해가 계약 관계로 연결된 제3자에게까지 전달되는 방식이다. SSG닷컴 이용자는 플라이라는 회사 이름조차 모른 채 자신의 정보가 그 회사 서버를 거쳤다는 사실을 통지 문자로 처음 알게 됐다. 배달 생태계처럼 여러 단계의 위탁·재위탁이 겹치는 산업에서는, 계약서에 명시된 개인정보 처리방침보다 실제 데이터가 어느 서버에 어떤 형태로 쌓여 있는지가 더 중요한 리스크 지표가 된다.
AI 활용 안내 이 글은 AI(Claude)의 도움을 받아 작성되었습니다. 인용된 통계와 사례는 참고 자료에 명시된 출처에 근거하며, 설명을 위한 일부 표현은 각색되었습니다.
면책 조항 본 글은 보안 인식 제고를 위한 교육 목적으로 작성되었습니다. 언급된 공격 기법을 실제로 시도하는 행위는 「정보통신망법」, 「형법」 등에 따라 처벌받을 수 있으며, 본 블로그는 이에 대한 법적 책임을 지지 않습니다.