티빙 3954만 계정 유출, 2년 전 발견한 접속키 취약점을 방치한 대가

[핵심요약] 티빙에서 2026년 5월 말 이용자 계정 3,954만 개가 유출됐어요. 2024년 모의해킹에서 이미 발견된 접속키 하드코딩 취약점을 2년 넘게 방치하다 터진 사고로, 암호화 키까지 함께 유출돼 사실상 평문 노출이나 다름없었어요.

2026년 5월 30일 오후 6시 1분, CJ ENM 계열 OTT 플랫폼 티빙의 개인정보 데이터베이스에 공격자가 직접 접근하는 사고가 발생했어요. 티빙은 이용자 계정 약 3,954만 개(실제 피해 회원 약 1,953만 명)의 아이디, 비밀번호, 이름, 생년월일, CI·DI(온라인 주민등록번호 역할), 결제 이력과 환불 계좌번호를 도난당했고, 더 심각하게는 이 데이터를 지키던 암호화 키까지 함께 유출됐어요. 공격자는 개발환경에서 탈취한 접속키로 소스코드에 그대로 노출된 운영환경 접속키를 확보해 침투했는데, 이 취약점은 이미 2024년 모의해킹에서 발견됐지만 고쳐지지 않은 채 방치돼 있었어요. 사건 발생 석 달여가 지난 지금, 티빙은 9월 3일 대표이사 명의로 공식 사과했고 9월 7일부터 30일까지 보상 신청을 받고 있어요.

어떻게 3,954만 개 계정이 뚫렸을까요?

침투 경로는 다섯 단계로 정리돼요. ① 개발환경 침투로 개발자 접속키를 훔치고, ② 소스코드에 하드코딩된 운영환경 접속키를 확보한 뒤, ③ 운영환경 내부까지 들어갔어요. ④ 가상서버 생성 권한을 가진 접속키로 새 가상서버를 만들어 유출 통로로 삼았고, ⑤ DB의 이용자 정보 약 24GB를 그 서버에 모아 외부로 빼돌렸어요. 이상 징후는 5월 31일 DB 서버 CPU 사용률이 100%까지 치솟으면서 뒤늦게 감지됐어요. 티빙은 발각 후 23시간 59분 만에야 개인정보보호위원회에 신고했고, 6월 3일 공지에서도 유출 항목 상당수를 “이외 서비스 이용과 관련한 정보”로 뭉뚱그려 투명성 부족 지적을 받았어요.

왜 이번 사고가 유독 뼈아픈가요?

이번 사고는 고난도 해킹 기술 때문이 아니라 기본적인 보안 관리가 여러 단계에서 동시에 무너지면서 벌어졌어요. 2024년 모의해킹에서 접속키 하드코딩 문제를 이미 발견하고도 2년 가까이 조치하지 않았다는 점이 가장 뼈아파요. 게다가 비밀번호와 결제정보는 암호화돼 있었지만, 그걸 푸는 키까지 같은 경로로 유출되면서 사실상 평문 노출과 다를 바 없게 됐어요. CI·DI는 온라인상 주민등록번호를 대체하는 식별정보라 명의도용 등 2차 피해로 이어지기 쉬워요. 6월 11일 1,051명 규모로 시작된 손해배상 소송은 6월 18일 참여자가 10만 명을 넘어설 정도로 파장이 커졌어요.

우리 회사도 대비하려면 뭘 해야 할까요?

가장 먼저 소스코드에 접속키·API 키를 직접 적어두는 하드코딩 관행부터 없애야 해요. 접속키는 시크릿 매니저나 환경변수로 분리해서 관리하고 주기적으로 교체하는 게 기본이에요. 개발환경과 운영환경은 계정·접근권한을 철저히 분리해서, 개발자 계정 하나가 뚫려도 운영 시스템까지 넘어가지 못하게 막아야 해요. 또 모의해킹에서 나온 지적사항을 실제로 조치했는지 추적하는 프로세스도 중요해요 — 발견만 하고 방치하면 몇 년 뒤 그대로 침투 경로가 될 수 있어요. DB 트래픽·CPU 사용률의 이상행동을 실시간으로 탐지하는 체계까지 갖춰두면, 침해가 나도 대량 유출 전에 막을 기회가 생겨요.

지금 바로 확인해보세요

• 소스코드 저장소(깃 등)에 접속키·API 키가 평문으로 남아있지 않은지 점검해 보세요.
• 개발환경 계정으로 운영환경 리소스에 접근할 수 있는 경로가 있는지 확인해 보세요.
• DB 서버의 CPU·트래픽이 평소보다 급증하는 이상 징후를 실시간으로 알림받고 있는지 확인해 보세요.
• 암호화 키를 암호화된 데이터와 같은 저장소·경로에 두고 있지 않은지 확인해 보세요.
• 최근 모의해킹에서 지적된 취약점 중 아직 조치하지 않은 항목이 남아있는지 다시 확인해 보세요.
• 가상서버(인스턴스) 생성 권한을 가진 계정 목록과 최근 생성 이력을 점검해 보세요.

비밀번호가 암호화됐다는데 왜 이렇게 심각하게 다뤄지나요?

암호화는 그 키가 안전하게 보관될 때만 의미가 있어요. 이번 사고에서는 암호화된 데이터와 그걸 풀 수 있는 키가 같은 경로로 함께 빠져나가면서, 공격자가 마음만 먹으면 원문 그대로 복원할 수 있는 상태가 됐어요. “암호화했으니 안전하다”는 설명만으로는 이용자를 안심시킬 수 없었던 거예요.

신고를 23시간 59분 만에 했다는데, 왜 이게 논란이 되나요?

개인정보보호법은 침해 인지 후 정해진 시간 안에 신고하도록 규정하는데, 그 마지노선에 아슬아슬하게 맞춘 셈이에요. 신고가 늦어질수록 이용자가 비밀번호를 바꾸거나 카드사에 알리는 등 스스로 대응할 시간이 줄어들기 때문에, 법정 시한을 지켰다는 사실만으로 “신속한 대응”이었다고 보기는 어렵다는 지적이 나와요.

티빙 사고는 최신 해킹 기법이 아니라 2년 전 이미 알고 있던 문제를 방치한 대가였어요. 대형 플랫폼도 접속키 관리, 개발·운영 환경 분리 같은 기본 원칙에서 예외일 수 없다는 걸 보여준 사례예요. 보상 신청이 9월 30일 마감되는 지금도 소송 참여자는 계속 늘고 있어요.

이런 사고를 막으려면 접속키 하나가 뚫려도 그 다음 단계인 백업 데이터까지는 손댈 수 없는 구조가 필요해요. 물리적으로 분리된 이중 데이터 다이오드 방식의 디포트리스가 그 역할을 해줘요. 접속키가 뚫려도 왜 백업만은 안전하게 지켜지는지 궁금하다면 여기서 확인해보세요.