티빙 3954만 계정 해킹 사고, 개발자 액세스 키 하나가 부른 대규모 유출

[핵심요약] 티빙(TVING)에서 해커가 탈취한 개발자 액세스 키 하나로 3954만 개 계정과 소스코드 361건이 통째로 유출됐고, 신고 지연 정황까지 드러나 개인정보보호위원회 조사를 받고 있어요.

2026년 5월 29일부터 사흘간, OTT 서비스 티빙(TVING)의 개발 환경에 신원 불명의 해커가 침투했어요. CJ ENM 계열사인 티빙은 이용자 3954만 개 계정과 소스코드 등 기술자산 361건을 통째로 빼앗겼고, 유출 항목에는 아이디·비밀번호(암호화)·성명·생년월일·성별·연계정보(CI)·휴대전화번호까지 20개 카테고리 70종이 포함됐어요. 더 심각한 건 티빙이 사고를 인지하고도 개인정보보호법이 정한 24시간 신고 기한을 넘겨 6월 1일에야 당국에 신고했고, 이용자 공지는 그보다 늦은 6월 3일에야 나왔다는 점이에요. 2026년 9월 3일, 개인정보보호위원회의 조사 결과 발표와 함께 CJ ENM 대표이사 명의의 공식 사과문이 나오면서 석 달 전 사고의 전모가 뒤늦게 드러났어요.

무슨 일이 있었나?

조사 결과 해커는 개발자 한 명의 액세스 키를 탈취해 5월 29일부터 31일까지 사흘간 티빙의 개발 환경에 머물렀어요. 5월 30일 저녁, 공격자가 처음 정보 유출을 시도했을 때는 티빙이 이상행동을 감지해 1차 시도를 막아냈어요. 문제는 그다음이었어요. 하루 뒤인 5월 31일, 공격자는 별도의 가상 서버를 새로 만들어 그 안에 24GB 분량의 이용자 정보를 모아 담은 뒤, 이를 외부 서버로 빼돌리는 데 성공했어요. 티빙은 이 2차 공격을 막지 못했고, 결국 개인정보보호위원회 조사에서 최초 발표보다 유출 규모가 2배 가까이 늘어난 3954만 개 계정(활성 2206만 개, 휴면 1737만 개)으로 확정됐어요. 티빙은 이보다 앞선 2025년 12월에도 크리덴셜 스터핑 공격을 당한 이력이 있어, 같은 해에 두 번째로 뚫린 셈이에요.

무엇이 위험한가?

이 사고에서 가장 뼈아픈 대목은 "탐지에 실패해서"가 아니라 "탐지하고도 막지 못해서" 피해가 커졌다는 점이에요. 티빙은 5월 30일 1차 공격 시도를 실제로 감지했어요. 하지만 그 이상행동이 왜 발생했는지 원인을 추적해 개발자 액세스 키 자체를 무효화하는 조치로 이어지지 못했고, 결국 같은 경로로 하루 뒤 2차 공격이 성공했어요. 탐지와 차단 사이의 그 하루가 3954만 명의 개인정보가 빠져나가는 시간이 된 거예요. 게다가 유출 항목에 CI(연계정보)가 포함돼 있다는 점도 위험도를 키워요. CI는 본인 확인 수단으로 다른 서비스 가입·인증에도 쓰이기 때문에, 이 정보 하나로 티빙 바깥의 다른 계정까지 도미노처럼 위협받을 수 있어요. 여기에 법정 신고 기한(24시간)을 넘긴 것까지 겹치면서, 이용자들은 비밀번호를 바꿀 기회조차 며칠 늦게 얻은 셈이 됐어요.

우리 회사도 대비하려면?

가장 먼저 점검할 부분은 개발 환경과 운영(프로덕션) 데이터베이스 사이의 경계예요. 개발자 계정 하나가 뚫렸다고 해서 곧바로 실제 이용자 데이터베이스까지 접근할 수 있는 구조라면, 그 자체가 가장 큰 위험 요소예요. 액세스 키에는 반드시 만료 기한과 최소 권한 원칙을 적용해서, 퇴사자나 프로젝트 종료 후에도 키가 살아있는 일이 없도록 관리해야 해요.

두 번째는 "탐지 이후"예요. 이상행동을 감지하는 시스템이 있는 것과, 감지 즉시 해당 계정·키를 자동으로 차단하고 격리하는 대응 체계가 있는 것은 전혀 다른 이야기예요. 티빙처럼 1차 시도는 막았지만 원인 제거로 이어지지 못하면, 공격자는 방법을 바꿔 재시도할 시간을 벌게 돼요. 탐지부터 차단까지 걸리는 시간을 실제로 측정하고 훈련해 본 조직만이 이 골든타임을 지킬 수 있어요.

마지막으로 신고·공지 프로세스도 미리 문서화해 둬야 해요. 사고가 터진 뒤에 누가 KISA에 신고하고 누가 이용자에게 공지할지를 그제서야 정하면 반드시 지연돼요. 법정 기한(24시간)을 지킬 수 있는 담당자와 절차를 평상시에 정해 두는 것 자체가 피해 확산을 막는 대응이에요.

• 개발 환경과 운영 데이터베이스가 물리적·논리적으로 분리돼 있는지 확인해 보세요.
• 외주 개발자나 협력사에게 발급한 액세스 키 중 만료 기한이 없는 것이 남아있는지 점검해 보세요.
• 대량 데이터 조회·다운로드가 발생하면 실시간으로 담당자에게 알림이 가는 체계인지 확인해 보세요.
• 이상행동을 1차로 탐지한 뒤, 원인 계정·키를 실제로 차단·격리하기까지 걸리는 시간을 측정해 본 적이 있는지 점검해 보세요.
• 침해사고 발생 시 24시간 내 KISA 신고 매뉴얼과 담당자 연락체계가 문서화돼 있는지 확인해 보세요.
• 과거 유사 공격(크리덴셜 스터핑 등)을 겪었다면, 그 취약점이 실제로 근본적으로 고쳐졌는지 재점검해 보세요.

비밀번호는 암호화됐다는데 그럼 큰 문제는 없는 거 아닌가요?

비밀번호와 환불 계좌번호는 암호화된 상태로 유출됐지만, 성명·생년월일·휴대전화번호·CI 같은 정보는 암호화 없이 그대로 빠져나갔어요. 이 정보만으로도 피싱 문자나 명의도용, 다른 서비스에서의 본인인증 우회 시도가 가능해서, 비밀번호가 안전하다고 안심할 수 있는 상황이 아니에요.

유출 규모가 왜 처음 발표보다 2배로 늘어난 건가요?

티빙이 6월 초 처음 공지했을 때는 유출 계정 수가 지금의 절반 수준이었어요. 이후 개인정보보호위원회가 서버 로그와 전송 기록을 정밀 분석하는 과정에서, 활성 계정뿐 아니라 오랫동안 로그인하지 않은 휴면 계정 1737만 개까지 유출 대상에 포함된 사실이 추가로 확인되면서 총 3954만 개로 규모가 확정됐어요.

티빙 사고는 액세스 키 하나, 그리고 탐지와 차단 사이의 단 하루가 어떤 결과를 만들 수 있는지를 그대로 보여줘요. 이상행동을 감지하는 것만으로는 부족하고, 그 즉시 원인을 끊어내는 체계가 있어야 진짜 방어가 완성된다는 교훈이에요. 게다가 같은 해 두 번째로 뚫렸다는 사실은, 한 번의 공격을 겪고도 근본 원인을 고치지 않으면 다음 공격은 반드시 온다는 걸 보여줘요. 3954만 명의 개인정보가 걸린 이번 사고가, 비슷한 구조를 가진 다른 서비스에도 조용한 경고로 남았으면 해요.

이번 티빙 사고처럼 계정 하나, 키 하나가 뚫리는 일은 어느 조직에서도 일어날 수 있어요. 진짜 중요한 건 그다음이에요 — 뚫린 계정으로 핵심 데이터까지 손댈 수 있느냐 없느냐가 피해 규모를 갈라요. 물리적으로 분리된 이중 데이터 다이오드 방식의 디포트리스는 관리자 권한이나 액세스 키가 탈취돼도 백업 데이터만큼은 건드리지 못하게 막아줘요. 개발자 키 하나가 전체 시스템을 뚫는 구조, 어떻게 막을 수 있는지 궁금하다면 여기서 확인해보세요.