배달대행 '플라이' 4790만 건 유출 주장, 공동현관 비밀번호까지 새나갔다

[핵심요약] 배달대행 플랫폼 '플라이'에서 다크웹 해커가 4,790만 건, 46.6GB 규모 데이터를 탈취했다고 주장하며 판매를 시도했어요. 주민등록번호부터 공동현관 비밀번호까지 포함됐다는 주장이라 파장이 커요.

2026년 9월 6일 데일리시큐 보도에 따르면, 다크웹 해킹 포럼 '다크포럼(DarkForums)'에서 활동하는 해커 exfilar가 배달대행 서비스 '플라이'를 운영하는 주식회사 플라이의 데이터를 탈취했다고 주장하며 6만 달러에 판매를 시도하고 있어요. 공개된 샘플에는 배달기사 1만1,629명의 주민등록번호·평문 비밀번호·은행계좌 정보와 고객 약 616만 건의 배송지 주소·GPS 좌표, 심지어 공동현관 비밀번호까지 포함돼 있어요. 데이터는 지난 8월 13~14일 이틀간 빠져나간 것으로 추정되고, 플라이 측은 의심 건수를 약 33만 건으로 공식 확인했지만 해커가 주장하는 4,790만 건 전체가 실제 유출됐는지는 아직 확인되지 않았어요. 공격자는 인증 절차 없이 열려 있던 Firebase Firestore와 Cloud Storage에서 데이터를 그대로 긁어갔다고 주장하고 있어요.

무슨 일이 있었나?

공격자가 다크포럼에 올린 게시글에는 배달기사 정보 1만1,629명, 고객 주문정보 약 616만 건, 매장 정보 8,611곳, 결제 API 키 7,700개 이상, 접속 로그 344만 건, 배달 완료 인증사진 약 1만7,000장까지 나열돼 있어요. 별도의 침투 기법 없이 Firestore와 Cloud Storage에 인증 절차 없이 읽기·쓰기가 가능했다는 게 공격자 주장인데, 사실이라면 정교한 해킹이 아니라 클라우드 보안 설정 실수가 원인이라는 뜻이에요. 공교롭게도 며칠 앞서 다른 다크포럼 이용자가 '배달의민족 이용자 4,200만 명 정보'를 판매한다고 주장했다가 운영사 우아한형제들이 자사 데이터가 아니라고 즉시 확인한 일이 있었어요. 이번 플라이 건은 별개 사고이고, 4,790만 건이라는 숫자도 아직은 판매자 주장으로 받아들이고 공식 조사를 지켜볼 필요가 있어요.

왜 중요한가, 무엇이 위험한가?

이번 사고가 특히 위험한 이유는 유출 주장 항목이 단순 개인정보를 넘어선다는 점이에요. 공동현관 비밀번호와 배송지 주소, GPS 좌표가 한 세트로 묶이면 온라인 사기를 넘어 실제 주거지 침입 같은 물리적 범죄로 이어질 수 있어요. 배달기사의 주민등록번호와 평문 비밀번호가 그대로 노출된 점도 심각해요 — 다른 서비스에 같은 비밀번호를 쓰고 있었다면 계정 탈취 피해가 연쇄적으로 번질 수 있어요. 결제 API 키 7,700개 이상이 함께 유출됐다면 부정 결제로 이어질 위험도 남아있고요. 실제 유출 규모와 안전조치 의무 위반이 확인되면 상당한 과징금으로도 이어질 수 있어요. 무엇보다 원인으로 지목된 게 고난도 해킹 기법이 아니라 '인증 없이 열려 있던 클라우드 설정'이라는 점이 중요해요 — 보안 인력이 부족한 스타트업이라면 누구나 겪을 수 있는 문제라는 뜻이에요.

우리 회사도 대비하려면?

Firebase 같은 서비스형 백엔드는 개발 속도가 빠른 대신, 보안 규칙(Security Rules)을 직접 세심하게 설정해야 하는 책임이 그대로 남아요. 테스트 단계에서 임시로 열어둔 '인증 없이 읽기/쓰기 허용' 설정을 운영 환경까지 그대로 가져가는 실수가 전형적인 원인이에요. 누구든 요청만 하면 접근 가능한 상태를 방치하지 않는 제로트러스트 원칙을 클라우드 설정에도 동일하게 적용해야 해요. 공동현관 비밀번호처럼 물리적 위험으로 직결되는 정보는 암호화하거나 보관 기간을 최소화하고, 결제 API 키 같은 민감 값은 별도 관리 시스템에서 주기적으로 교체(rotation)해야 해요.

• Firebase 등 클라우드 백엔드 보안 규칙에 '인증 없이 읽기/쓰기'가 허용된 항목이 남아있는지 점검해 보세요.
• 공동현관 비밀번호처럼 물리적 위험으로 이어지는 정보를 원문 그대로 저장하고 있지 않은지 확인해 보세요.
• 결제 연동에 쓰는 API 키가 코드나 로그에 평문으로 노출되고 있지 않은지 점검해 보세요.
• 짧은 시간에 대량의 데이터를 조회하거나 내보낸 이상 접속 로그가 있는지 확인해 보세요.
• 직원과 배달기사 계정 비밀번호가 해시·솔트 없이 평문으로 저장되는 구조는 아닌지 확인해 보세요.

해커가 주장하는 4,790만 건과 회사가 확인한 33만 건, 왜 이렇게 차이가 나나요?

공식적으로 확인된 이유는 아직 없어요. 판매가를 높이려 접속 로그 같은 비민감 항목까지 합쳐 부풀렸을 가능성도, 회사가 조사 초기라 범위를 보수적으로 발표했을 가능성도 있어요. 공식 조사 결과가 나와야 명확해질 거예요.

공동현관 비밀번호가 유출되면 실제로 어떤 피해로 이어질 수 있나요?

배송지 주소, GPS 좌표와 공동현관 비밀번호가 한 세트로 유출되면 스토킹이나 주거 침입 같은 오프라인 범죄로 곧바로 연결될 수 있는 조합이에요. 온라인 유출과 달리 즉각적인 물리적 안전 문제로 이어질 수 있다는 점에서 더 무겁게 다뤄야 해요.

Firebase 같은 서비스형 백엔드를 쓰는 스타트업은 뭘 가장 먼저 점검해야 하나요?

가장 먼저 볼 건 보안 규칙(Security Rules)의 기본값이에요. 개발 단계에서 편의상 열어둔 '인증 없이 읽기/쓰기 허용' 설정이 운영 배포 시에도 남는 경우가 실무에서 의외로 흔해요. 배포 전 체크리스트에 보안 규칙 검토 항목을 반드시 넣어야 해요.

이번 플라이 사고는 아직 진위와 피해 규모가 공식 조사로 확인되지 않았지만, 공개된 샘플만으로도 배달 플랫폼이 얼마나 많은 민감 정보(위치, 출입 비밀번호, 신분증)를 쌓아두고 있는지 새삼 보여줬어요. 정교한 해킹 기법이 아니라 클라우드 설정 하나를 놓친 것만으로 이 정도 피해가 날 수 있다는 점이 가장 무서운 대목이에요. 클라우드 백엔드를 쓰는 모든 서비스가 남 일이 아니라고 받아들여야 할 사례예요.

이런 사고처럼 인증 없이 접근 가능한 설정이 방치되면, 데이터는 물론 백업 시스템도 똑같이 무방비로 뚫릴 수 있어요. 관리자 권한이 뚫려도 백업까지는 손대지 못하게 물리적으로 분리해두는 이중 데이터 다이오드 방식의 디포트리스가 그런 최후 방어선 역할을 해줘요. 관리자 설정이 뚫려도 백업까지는 왜 안전한지 궁금하다면 여기서 확인해보세요.