배달대행 플랫폼 플라이 해킹, 4,790만건 유출 주장…요기요·SSG닷컴까지 불똥

[핵심요약] 배달대행 플랫폼 플라이가 해킹당해 라이더·상점·주문고객 정보 약 33만 건이 유출된 것으로 확인됐어요. 요기요·SSG닷컴이 위탁한 배송업무의 재하도급 구조 탓에 대형 서비스 고객정보까지 함께 새어나갔어요.

2026년 8월 14일경 국내 배달대행 플랫폼 플라이의 시스템에 외부인이 무단으로 접근했고, 8월 18일 오후 플라이는 개인정보 유출 사실을 공식 확인했어요. 해커는 해외 다크포럼에 라이더 1만1,629명 정보와 고객 주문정보 약 616만 건 등 총 4,790만 건, 46.6GB 규모 데이터를 훔쳤다고 주장하며 6만 달러에 판매를 시도했어요. 플라이 측은 실제 유출 의심 건수는 약 33만 건이라고 밝혔지만, 문제는 여기서 끝나지 않았어요. 플라이는 배달앱 요기요와 이커머스 SSG닷컴이 각각 바로고 등을 거쳐 배송 업무를 재위탁한 협력사여서, 두 대형 서비스의 고객 정보까지 함께 유출 범위에 들어갔어요.

재위탁의 재위탁, 4,790만 건까지 불어난 유출 주장

다크포럼 이용자 exfilar는 8월 13~14일 사이 플라이의 운영 데이터에 접근했다고 밝히며, 관리자·라이더 정보(성명, 연락처, 주소, 계좌, 주민등록번호), 약 8,611개 매장의 사업자·금융정보, 7,700개 이상의 결제 API 키, 그리고 주문 고객의 배송지·GPS 좌표·공동현관 비밀번호까지 확보했다고 주장했어요. 공개된 샘플 화면에는 평문 상태의 비밀번호로 보이는 값도 포함돼 있었어요. 공격자는 이런 접근이 가능했던 경로로 인증 절차 없이 읽고 쓸 수 있었던 클라우드 데이터베이스와 저장소를 지목했다고 알려졌는데, 사실이라면 계정을 하나하나 뚫은 게 아니라 애초에 문이 열려 있었던 셈이에요. 플라이는 8월 15일 저녁 KISA를 통해 이상 징후를 인지했고, 8월 18일 유출 사실을 공식화하며 침해 경로를 차단했어요. 이후 SSG닷컴은 자사가 위탁한 바로고가 일부 배송 업무를 플라이에 재위탁했다는 사실을 확인했고, 8월 24일 기준 피해 고객 약 40명(배송지 주소·공동현관 비밀번호)을 파악했다고 밝혔어요. 비슷한 시기 요기요 플랫폼 이용자의 개인정보도 함께 노출된 정황이 보도됐어요.

왜 중요한가: "우리는 직접 계약 안 했는데"가 안 통하는 이유

이 사고가 특히 뼈아픈 이유는 플라이가 요기요나 SSG닷컴과 직접 계약한 업체가 아니라는 데 있어요. SSG닷컴은 바로고에 배송을 맡겼고, 바로고가 다시 그 업무 일부를 플라이에 넘긴 구조였어요. 즉 원청 입장에서는 이름도 들어본 적 없는 3차, 4차 협력사의 보안 수준이 자사 고객정보의 안전을 좌우한 셈이에요. 게다가 유출 경로로 지목된 것이 정교한 해킹 기법이 아니라 클라우드 서비스 접근 권한 설정 실수였다면, 이런 사고는 예산이 크지 않은 중소 협력사 어디서든 똑같이 재현될 수 있어요. 최근 국내외에서 랜섬웨어·해킹 공격이 매달 최다 기록을 경신하고 있는 만큼, 원청 대기업의 보안 투자만으로는 이런 하도급망의 구멍을 막을 수 없다는 게 이번 사고가 보여주는 현실이에요.

우리 회사도 대비하려면?

협력사·위탁업체를 쓰고 있다면 계약서에 보안 조항을 넣는 것만으로는 부족해요. 실제로 그 협력사가 어떤 클라우드 서비스를 쓰고, 접근 권한이 어떻게 설정돼 있는지 최소한 연 1회는 점검하거나 점검 결과를 제출받는 절차가 필요해요. 특히 Firebase, AWS S3 같은 클라우드 스토리지는 기본 설정 그대로 두면 인증 없이도 외부에서 읽고 쓸 수 있는 상태로 열려 있는 경우가 실무에서 생각보다 흔해요. 담당자가 편의를 위해 임시로 열어둔 접근 권한을 되돌리는 걸 잊는 사소한 실수가 수십만 건 유출로 이어질 수 있다는 걸 이번 사고가 잘 보여줘요.

또한 결제 API 키처럼 민감한 자격 증명은 애초에 일반 데이터베이스와 같은 공간에 저장하지 않는 게 원칙이에요. 유출되면 부정결제나 계정 탈취 같은 2차 피해로 곧바로 이어지기 때문에, 별도의 비밀관리 시스템(시크릿 매니저)으로 분리 보관하고 값을 주기적으로 교체하는 습관이 필요해요.

• 클라우드 스토리지(Firebase, S3 등) 버킷·DB에 인증 없이 접근 가능한 주소가 있는지 정기적으로 스캔해 보세요
• 협력사·재위탁업체가 우리 고객 데이터를 다루고 있다면, 그 업체의 보안 점검 결과를 최근 1년 내 받아본 적이 있는지 확인해 보세요
• 결제 API 키, 계좌 정보 등 민감 값이 평문 상태로 일반 DB에 저장돼 있지 않은지 점검해 보세요
• 다크웹·해킹포럼에서 우리 회사명이나 서비스명이 언급되는지 모니터링 체계가 있는지 확인해 보세요
• 대량 다운로드나 낯선 IP의 관리자 계정 접속 같은 이상 접근 로그를 실시간으로 알림받는 체계가 있는지 점검해 보세요

Q. 우리 회사는 배달앱이 아닌데도 이런 사고와 관련이 있을까요?

네, 관련 있어요. 이번 사고의 핵심은 배달 서비스 자체가 아니라 재위탁 구조예요. 물류, 콜센터, 마케팅 대행처럼 외부 업체에 데이터 처리를 맡기는 업종이라면 업종과 무관하게 같은 구조적 위험을 안고 있어요.

Q. 전산 인력이 1~2명뿐인 중견기업도 이런 사고를 막을 수 있나요?

클라우드 서비스 자체 점검 도구(Firebase 보안 규칙 검사, AWS Trusted Advisor 등)는 대부분 무료로 제공돼요. 전담 인력이 적더라도 분기 1회 정도 이 도구로 접근 권한만 점검해도 이런 유형의 사고 상당수는 막을 수 있어요.

플라이 사태는 정교한 해킹 기법이 아니라 클라우드 접근 권한 설정 하나가 얼마나 큰 피해로 번질 수 있는지 보여준 사고예요. 그리고 그 피해는 계약서에 이름조차 없는 3차, 4차 협력사를 타고 요기요·SSG닷컴 같은 대형 서비스까지 조용히 번졌어요. 우리 회사가 직접 뚫리지 않아도, 우리 데이터를 만지는 누군가가 뚫리는 순간 똑같이 피해자가 될 수 있다는 걸 잊지 말아야 해요.

이런 사고를 막으려면 협력사 시스템 하나가 뚫려도 우리 회사의 핵심 데이터베이스와 백업까지는 손댈 수 없는 구조가 필요해요. 물리적으로 분리된 이중 데이터 다이오드 방식의 디포트리스가 그 역할을 해줘요. 클라우드 설정 실수 하나로도 이런 대형 유출이 벌어지는 시대에, 어떻게 원천적으로 접근을 차단하는지 궁금하다면 여기서 확인해보세요.