MunChanChoi 기술 블로그
← 아티클 목록

침해사고 분석

티빙 침해사고 조사결과로 본 접속키 관리와 탐지·대응의 빈틈

티빙의 개발환경 접속키 악용이 운영환경 접근과 대규모 정보유출로 이어진 과정을 공식 조사결과로 살펴본다.

Mun Chan Choi업데이트 2026년 9월 7일10분 분량이슈 정리
목차 6

2026년 5월 30일 티빙은 데이터베이스(DB) 과부하 알림을 받고 관련 작업을 차단했다. 그러나 다음 날 재시도에서 대규모 정보유출이 발생했다. 9월 3일 과학기술정보통신부가 공개한 민관합동조사단 조사결과는 이 과정을 접속키 관리, 접근권한, 비정상 행위 탐지와 조직 대응의 문제로 설명한다.

첫 이상 작업을 차단하고도 대규모 유출을 막지 못한 이유는 무엇일까? 성능 이상을 발견한 뒤 어떤 접근을 차단했고, 어떤 권한과 대응 문제가 남았는지를 공식 발표에서 살펴봤다.

과기정통부의 조사보고서와 브리핑을 중심으로 사고 흐름을 살펴보고, 개인정보보호위원회 발표와 티빙 공지를 함께 읽었다. 참고한 자료는 글 하단에 모았다.

이상징후 발견과 침해사고 인지는 시점이 달랐다

DB 과부하를 발견한 때, 정보보안팀에 상황이 전달된 때, 관계 기관에 신고한 때는 서로 달랐다. 정부 발표와 티빙 공지에 나온 날짜와 시각을 나란히 놓으면 그 차이가 드러난다.

시점 경과 발표·설명 주체
5월 29일 개발환경 침투와 프로젝트 유출, 운영환경 접근 조사단
5월 30일 18:00 DB 과부하 알림 발생. 이후 관련 작업 차단 조사단. 정확한 차단 시각은 공개되지 않음
5월 31일 10:10 운영환경 접속키 탈취와 정보유출 의심 상황이 정보보안팀에 전파됨 조사단이 판단한 침해사고 인지 시점
5월 31일 19:00~22:20 2차 정보유출 시도와 대규모 유출 조사단
6월 1일 15:08 KISA에 침해사고 신고 조사단
6월 2일 개인정보 유출 정황 인지 개인정보위 초기 발표와 티빙 설명
6월 2~3일 현장조사 착수, 민관합동조사단 구성 과기정통부
6월 3일 약 02:00 개인정보위가 유출신고 접수 개인정보위
6월 3일 이용자에게 개인정보 유출 사실 통지 등록 티빙
9월 3일 기술 조사결과 발표 과기정통부

인지 시점은 후속 조사에서도 쟁점이었다. 과기정통부 조사보고서에 따르면 티빙은 처음 신고할 때 5월 31일 15:09에 사고를 인지했다고 밝혔다. 조사단은 그보다 앞선 10:10에 정보보안팀으로 의심 상황이 전달된 점을 기준으로 삼았다. 개인정보위의 6월 4일 발표와 티빙의 유출 통지에 나오는 6월 2일은 개인정보 유출 정황을 인지한 날짜다. 침해사고 인지와 개인정보 유출 정황 인지를 같은 시점으로 읽으면 대응 경과를 잘못 이해할 수 있다.

약 3,954만은 중복을 포함한 계정 수다

조사단은 DB와 관련 로그를 분석해 다음 계정 수를 발표했다. 합계에는 동일인이 여러 방식으로 가입한 계정이 중복되어 있다.

계정 구분 유출된 계정 수
활성화 22,063,021개
휴면 8,502,679개
탈퇴 8,868,174개
테스트 106,823개
합계 39,540,697개

사람 수를 산정하려면 계정 간 중복 제거가 필요하다. 티빙 자체 가입, CJ ONE 통합회원, SNS 간편가입 등 여러 가입 경로가 있으며, 조사단은 한 사람이 최대 13개 계정을 보유한 사례도 확인했다. 연계정보(CI)가 없는 계정에는 부정확하거나 누락된 정보도 있다고 설명했고, 구체적인 개인정보 유출 규모는 개인정보위의 상세 분석 대상으로 남겼다.

발표된 유출정보는 20개 항목·70종이다. 이름, 연락처, 생년월일, 연계정보(CI)와 중복가입 확인정보(DI), 서비스 이용·거래 관련 정보 등이 포함되며 계정별 유출 항목은 다르다. 일부 휴대전화 번호와 이메일은 암호화된 상태였지만 암호화키도 함께 유출되어, 조사단은 평문 유출과 같은 수준으로 평가했다. 비밀번호는 일방향 암호화 상태로 보고됐다.

용량도 측정 대상을 구분해야 한다. 개발 프로젝트 유출은 361건·30.35GB, 이용자 정보유출 과정에서 일괄 저장된 데이터는 24GB다. 약 3.5TB는 조사자료에 적힌 DB 규모다. 24GB를 전체 유출 자산의 합계로 쓰거나, 3.5TB 전부가 외부로 전송되었다고 해석할 근거는 없다.

개발환경 접근이 대규모 유출로 이어진 과정

조사보고서에서 개발환경은 소스코드를 보관하고 여러 개발자가 함께 수정·관리하는 공간, 운영환경은 서버와 IT 인프라를 사용하는 클라우드 기반 시스템으로 설명된다. 두 환경에 접근할 때는 각각 개발환경 접속키와 운영환경 접속키가 필요하다.

개발환경 접속키 탈취, 개발 프로젝트 유출과 운영환경 접속키 확보, 운영환경 침투, 1차와 2차 정보유출 시도를 표시한 과기정통부의 사고 흐름도

과학기술정보통신부 「티빙(TVING) 침해사고 조사결과 발표」(2026. 9. 3.)의 사고원인 분석 도식. 첨부문서에 실린 그림을 그대로 사용했다. 그림 크게 보기.

조사단이 제시한 순서에서 눈여겨볼 부분은 각 단계에서 접근 가능한 범위가 달라졌다는 점이다. 개발 프로젝트에 대한 접근이 운영환경과 이용자 DB로 확대됐고, 첫 작업을 차단한 뒤에도 다른 운영환경 접속키를 통한 유출이 이어졌다.

개발환경 접속키의 영향이 전체 프로젝트로 번졌다

조사단에 따르면 공격자는 개발환경 접속키를 악용해 개발 프로젝트 361건 전체에 접근하고 이를 유출했다. 티빙은 모든 개발자에게 전체 프로젝트 접근권한을 부여하고 있었다. 조사단은 이 때문에 개발환경 접속키 하나가 탈취된 경우에도 전체 프로젝트에 접근할 수 있었다고 설명했다.

최초 개발환경 접속키를 탈취한 방법은 규명되지 않았다. 조사단은 피싱·악성코드·공급망 공격 등 여러 가설을 조사했지만 이를 뒷받침할 근거를 확보하지 못했다고 밝혔다. 질의응답에서는 로그 보관기간의 한계와 단말기 포렌식 분석 범위도 설명했다. 하드코딩과 평문 저장은 공식적으로 지적된 관리 문제이며, 최초 탈취 방법은 미확인으로 남는다.

내가 주목한 부분은 최초 키의 탈취 경로가 밝혀지지 않았어도 피해가 커진 이유는 접근권한에서 찾을 수 있다는 점이다. 업무별로 접근 범위를 제한하지 않아 개발환경의 한 접속 수단이 전체 프로젝트에 영향을 줄 수 있었다. 이 사례를 통해 최소권한이 접속키 하나가 탈취됐을 때의 피해 범위와 어떻게 연결되는지 이해하게 됐다.

프로젝트에 있던 자격증명이 운영환경과 DB 접근으로 이어졌다

과기정통부 조사보고서에는 유출된 프로젝트에 운영환경 접속키 43개가 포함되어 있었다고 나와 있다. 소스코드에 직접 적어 둔 키가 41개, 환경변수에 평문으로 저장한 키가 3개이며, 이 중 1개가 겹친다. 공격자는 운영환경에 접근한 뒤 평문으로 저장된 DB 접속정보도 확보했다. 조사단이 실제 공격에 악용된 것으로 확인한 운영환경 접속키는 2개다.

나는 이 대목을 개발 프로젝트 유출이 이용자 정보유출로 이어진 연결 지점으로 봤다. 프로젝트 안의 자격증명이 운영환경 접근을 허용하고, 그 안에서 다시 DB 접속정보가 노출된 것이다. 개발환경과 운영환경을 구분해 운영하더라도 자격증명의 보관 위치와 사용 권한이 연결되어 있으면 피해도 이어질 수 있다. 접속키가 어디에 저장되어 있는지와 그 키로 무엇을 읽을 수 있는지를 함께 보니, 환경 사이로 피해가 확대된 과정이 더 구체적으로 이해됐다.

첫 작업의 차단 뒤에도 다른 접속키가 사용됐다

조사단은 두 차례의 이용자 정보유출 시도에 서로 다른 운영환경 접속키가 사용됐다고 밝혔다. 첫 시도에서는 DB 과부하 알림에 따라 해당 작업을 차단했다. 다음 날 재시도에는 권한이 다른 별개의 키가 사용됐고, 과부하 알림 없이 대규모 유출이 발생했다.

조사단은 재시도 당시 CPU 사용량을 근거로, 공격자가 과부하 알림을 피하려 부하를 제한했을 것으로 판단했다. CPU 사용량은 관측한 값이고, 알림을 피하려 했다는 의도는 그 값에 근거한 조사단의 추정이다.

이 흐름을 보며 첫 차단 이후에도 어떤 자격증명을 사용할 수 있었는지가 대응의 핵심이라고 생각했다. 다른 키로 재시도가 이어졌으므로 최초 작업을 멈춘 것만으로 접근 차단이 충분했는지 판단하기는 어렵다. CPU 경보가 다시 울리지 않은 상황에서도 데이터 접근을 감시할 수 있어야 한다. 다만 키별 폐기 시각과 당시의 상세 접근정책은 공개되지 않아, 어떤 조치가 빠졌는지 모두 특정할 수는 없다.

내부 상황 전파와 유출 차단 사이에 공백이 남았다

조사단이 인지 시점으로 판단한 5월 31일 10:10에는 접속키 탈취와 정보유출 의심 상황이 정보보안팀에 전달되어 있었다. 2차 유출은 그날 19:00부터 발생했고 KISA 신고는 다음 날 15:08에 이루어졌다. 조사결과 브리핑의 질의응답에서 조사단은 티빙이 최초 알림을 일반적인 과부하로 보아 당시 접속 차단 외 추가 조치를 하지 않았다고 설명했다. KISA는 알림 이후 상세 분석과 내부 공유가 이루어진 과정도 덧붙였다.

내가 이 시간표에서 눈여겨본 것은 정보보안팀에 의심 상황이 전달된 뒤에도 대규모 유출이 이어졌다는 점이다. 이를 보며 상황 전달 이후 어떤 접근이 차단됐는지, 차단 효과를 어떻게 확인하는지가 궁금해졌다. 공개자료만으로 그 사이의 조치를 모두 복원하거나 특정 조치 하나가 유출을 막았을 것이라고 단정할 수는 없다. 다만 사고 대응을 이해하려면 알림과 내부 공유에 이어 실제 접근 차단까지 연결해 봐야 한다는 점을 배웠다.

티빙이 설명한 조치와 이용자 지원

티빙은 6월 3일 개인정보 유출 통지에서 공격자 접근 차단, 클라우드 접근정책 변경, DB 접속 모니터링 강화를 시행했다고 밝혔다. 같은 계정 정보를 사용하는 티빙과 다른 서비스의 비밀번호 변경도 권고했다. 이는 티빙이 공지한 조치이며, 각 조치의 효과를 독립적으로 검증한 결과는 아니다.

암호화에 관한 설명은 후속 조사와 함께 읽을 필요가 있다. 티빙의 초기 통지에는 전화번호·이메일 일부가 암호화되어 있다고 적혀 있다. 과기정통부는 이후 암호화키도 유출되어 복호화가 가능했다고 밝혔다. 나는 이 차이 때문에 저장 당시의 암호화 여부와 유출 이후의 보호 수준을 각각 평가해야 한다고 본다. 비밀번호 역시 일방향 암호화라는 발표만으로 안전성을 단정하기는 어렵다. 알고리즘과 솔트 사용 여부 등은 공개자료에서 확인하지 못했다.

티빙은 6월 10일 공지에서 사고를 악용한 스미싱·피싱 시도를 설명하고 의심 링크, 앱 설치, 개인정보 제공 요구에 응하지 말라고 안내했다. 한편 조사단은 결과 발표 당시 유출정보를 이용한 추가 피해 사례와 불법유통 정황을 확인하지 못했다고 설명했다. 두 발표를 함께 읽으면, 티빙을 사칭한 시도가 있었다는 사실만으로 실제 유출정보가 그 사기에 사용됐다고 연결해서는 안 된다고 생각한다.

9월 3일 티빙은 사고 대상자로 안내받은 회원을 위한 보상안도 공지했다. 신청 일정은 9월 7일 10:00부터 9월 30일 23:59까지, 순차 보상 예정일은 10월 6일 10:00부터다. 대상 여부와 본인 확인 절차, 혜택별 조건은 티빙의 ‘사이버 침해 사고에 대한 사과 및 보상 안내’ 공지에서 확인할 수 있다. 이 일정은 티빙이 발표한 계획이며, 실제 지급 결과는 아직 확인하지 않았다.

재발방지 대책을 보며 이해한 점

조사단은 2024년 모의해킹에서 발견한 접속키 하드코딩 문제를 개선하지 않은 사실도 지적했다. 신규 장비에는 로그관리 정책이 제대로 적용되지 않았다.

조사단이 제시한 대책에는 접속키의 발급부터 폐기까지 관리하고 접근권한을 최소화하는 것, 비정상 행위와 대량 조회를 감시하는 것, 로그 보관정책과 취약점 조치체계를 정비하는 것이 포함됐다. 정보보호 인력·예산을 확보하고 부서 간 대응체계를 개선하는 내용도 있었다.

이 대책들을 사고 흐름에 대입하니 각각이 어떤 문제와 연결되는지 이해할 수 있었다. 전체 프로젝트로 접근이 번진 부분은 최소권한과, 다른 키로 재시도가 이어진 부분은 접속키 관리와 연결됐다. 과부하 알림 없이 유출이 발생한 과정에서는 성능 상태와 데이터 접근을 함께 살펴야 하는 이유를 배웠다.

더 공부해 보고 싶은 부분은 이상징후를 발견한 뒤의 대응이다. 성능 경보와 데이터 접근 기록을 어떻게 함께 읽는지, 접속키 유출이 의심될 때 그 키로 접근할 수 있는 범위를 어떻게 파악하는지 궁금해졌다.

과기정통부 조사보고서에 따르면 조사단은 유출된 개발 프로젝트의 취약점 진단결과와 개선조치 이행 여부를 점검했다. 전체 재발방지 대책에는 별도의 후속 일정이 있다. 과기정통부가 발표한 계획은 2026년 9월 이행계획 제출, 10~12월 이행, 2027년 1월부터 점검하는 순서다.

과기정통부는 침해사고 신고 지연에 대해 3,000만 원 이하 과태료를 부과할 예정이라고 밝혔다. 개인정보위의 6월 4일 발표는 안전조치와 유출 통지·신고 의무 등에 관한 조사 착수를 알린 자료다. 과기정통부가 발표한 기술 조사결과와 개인정보위의 최종 의결·처분은 구분해 읽었다.

2026년 9월 7일까지 살펴본 정부 발표와 티빙 공지에서는 최초 키 탈취 경로와 공격자 신원, 중복을 제거한 전체 피해자 수, 개인정보위 최종 처분과 전체 재발방지 대책의 이행 결과를 확인하지 못했다. 티빙의 내부 로그나 유출 데이터는 직접 확인하지 않았으므로, 그 자료가 있어야 판단할 수 있는 당시의 세부 대응은 분석에 한계가 남는다.

출처

아래 정부 발표와 티빙 공지를 2026년 9월 7일 기준으로 확인했다.

공식자료 대조와 초안 구성, 문장 편집에 AI를 활용했다.