---
title: "티빙 해킹, 개인정보 유출보다 더 큰 문제는 AWS 액세스 키 노출이었다"
published: 2026-06-07T06:05:05.846Z
canonical: https://jeff.news/article/3820
---
# 티빙 해킹, 개인정보 유출보다 더 큰 문제는 AWS 액세스 키 노출이었다

티빙 해킹 사고가 단순 DB 유출이 아니라 AWS 클라우드 자격증명 관리 실패로 번지는 분위기다. GitHub에 노출된 자격증명, 하드코딩된 액세스 키, 21시간 늦은 이상 징후 인지, 24시간 신고 시한 1분 전 신고까지 보안 운영 전반이 도마 위에 올랐다.

## 이건 단순 개인정보 유출보다 클라우드 권한 사고에 가까움

- 티빙 해킹 사고가 고객 정보 유출을 넘어 내부 시스템 제어권 노출 가능성으로 번지고 있음
  - 국회 과학기술정보방송통신위원회 소속 이해민 의원실이 입수한 한국인터넷진흥원(KISA) 침해사고 신고서 내용이 근거로 제시됨
  - 비인가자가 내부 시스템에 직접 접근해 데이터 조회와 수정 명령, 즉 쿼리를 실행한 정황이 확인됐다고 함

- 주요 원인으로는 GitHub에 노출된 자격증명과 AWS 핵심 액세스 키 관리 부실이 지목됨
  - 개발 플랫폼인 GitHub 계정이 유출되면서 소스코드 안의 민감 정보가 드러난 것으로 추정됨
  - 특히 자격증명을 암호화하지 않고 문자열 그대로 코드에 적어두는 하드코딩이 문제로 언급됨

> [!WARNING]
> AWS 액세스 키는 단순 로그인 비밀번호가 아님. 권한 설정에 따라 서버, 저장소, 데이터베이스까지 건드릴 수 있어서 키 하나가 인프라 전체 리스크로 번질 수 있음.

- 티빙은 사고 직후 해당 키를 교체했지만, 그걸로 끝났다고 보기 어렵다는 지적이 나옴
  - 시스템 구조가 이미 노출됐을 수 있기 때문임
  - 보안 전문가들은 우회 침투 경로, 즉 백도어 가능성까지 고려해 정밀 포렌식 조사가 필요하다고 봄

## 신고와 공지도 ‘법적 마감 맞추기’처럼 보였다는 비판

- 티빙은 사고를 인지한 지 23시간 59분 만에 KISA에 신고함
  - 현행법상 침해사고 의무 신고 시한은 24시간 이내임
  - 말 그대로 마감 1분 전에 들어간 셈이라, 빠른 대응이라기보다는 규정 턱걸이로 보일 수밖에 없음

- 이용자 공지는 더 늦어서 사고 인지 이틀 뒤에야 이뤄짐
  - 개인정보보호위원회의 72시간 이내 통보 기준은 충족해 법적 처벌은 피한 것으로 보임
  - 하지만 대형 플랫폼이라면 피해 확산을 막기 위한 선제 조치가 먼저 아니냐는 비판이 나옴

- 이 대목이 중요한 이유는 침해사고 대응에서 시간 자체가 보안 조치이기 때문임
  - 사용자는 비밀번호 변경, 결제수단 점검, 피싱 주의 같은 행동을 빨리 해야 함
  - 공지가 늦어질수록 피해자가 스스로 방어할 시간도 줄어듦

## 더 아픈 지점은 자체 탐지가 아니라 서버 과부하로 알아챘다는 점

- 신고서에 따르면 해커가 대량의 회원 정보를 조회하면서 DB 서버 CPU 사용률이 100%까지 치솟았음
  - 이상 징후가 발생한 시점은 지난달 30일 오후 6시 1분으로 언급됨
  - 티빙이 이를 인지한 건 21시간 뒤인 다음 날 오후 3시 9분임

- 보안 전문가들은 이걸 ‘탐지 시스템이 막아낸 사고’로 보기 어렵다고 설명함
  - 대량 데이터 추출로 서버 과부하가 난 뒤에야 사후 확인이 이뤄진 흐름에 가깝다는 것임
  - 월간 활성 이용자수(MAU) 770만 명이 넘는 서비스라면 꽤 뼈아픈 지점임

> [!IMPORTANT]
> CPU 100% 같은 극단적인 증상이 난 뒤 21시간이 지나서야 인지했다면, 로그 기반 이상 탐지와 클라우드 권한 모니터링이 제대로 작동했는지부터 다시 봐야 함.

- ISMS 인증을 갖고 있었는데도 기본 수칙 누락 의혹이 제기됨
  - 클라우드 관리자 접속 시 스마트폰 2차 인증(OTP) 같은 기본 보호 장치가 현장에서 빠졌다는 지적이 나옴
  - 인증 보유와 실제 운영 보안 수준이 항상 같지 않다는, 매우 현실적인 사례임

## 보안 투자 축소 얘기까지 나오면서 구조적 문제로 커짐

- 티빙의 정보보호 투자액은 2022년 약 22억 원에서 2024년 약 17억 원으로 줄었다고 공시됨
  - 2년 연속 감소한 수치임
  - 사고가 난 뒤 보면 비용 절감이 보안 운영 역량 저하로 이어진 것 아니냐는 의심을 피하기 어려움

- 보안 인력 규모도 논란 포인트임
  - 전담 보안 인력은 내부와 외주를 합쳐 총 7.5명으로 언급됨
  - 최고정보보호책임자(CISO)도 전임 임원이 아니라 겸직 팀장급이라고 보도됨

- 티빙 측은 정부 합동조사단 조사가 진행 중이라 구체적 확인은 어렵다는 입장을 냄
  - 경위 조사가 끝나면 투명하게 밝히겠다고 설명함
  - 다만 이번 사안은 이미 ‘누가 몇 명 털렸나’보다 ‘클라우드 권한을 어떻게 관리했나’로 초점이 이동한 상태임

---

## 기술 맥락

- AWS 액세스 키가 위험한 이유는 권한 범위가 계정 설정에 따라 매우 커질 수 있기 때문이에요. 단순히 DB 하나 읽는 수준이 아니라, 서버와 저장소, 네트워크 설정까지 접근 가능한 권한이면 사고 반경이 인프라 전체로 커져요.

- 하드코딩이 특히 나쁜 습관인 이유는 코드 저장소와 자격증명의 생명주기가 엮여버리기 때문이에요. GitHub 계정이나 저장소 권한이 한 번 뚫리면, 코드뿐 아니라 운영 환경으로 들어가는 열쇠까지 같이 노출될 수 있거든요.

- 이런 사고를 줄이려면 장기 액세스 키를 최소화하고, 필요한 권한만 주는 최소 권한 원칙이 중요해요. 기사에서는 구체적인 권한 정책이 나오진 않지만, 키 노출이 인프라 제어권 논란으로 이어졌다는 점만으로도 권한 범위 관리가 핵심이라는 걸 알 수 있어요.

- 탐지도 별도 문제예요. CPU가 100%까지 올라간 뒤에야 알아챘다면, API 호출 패턴, 대량 조회, 비정상 리전 접근, 권한 사용 이벤트 같은 신호를 더 빨리 잡았어야 해요. 클라우드 보안은 방화벽 하나보다 로그와 이벤트를 얼마나 빨리 해석하느냐가 중요해요.

- 사고 대응 시간도 기술 운영의 일부예요. 신고 시한을 맞추는 것과 피해 확산을 줄이는 건 다른 문제라서, 대형 서비스라면 키 폐기, 세션 무효화, 사용자 공지, 포렌식 범위 확정을 거의 동시에 굴릴 수 있는 체계가 필요해요.

## 핵심 포인트

- 비인가자가 내부 시스템에 접근해 데이터 조회와 수정 쿼리를 실행한 정황이 확인됐다
- GitHub 계정 유출과 소스코드 내 하드코딩된 AWS 액세스 키가 주요 원인으로 추정된다
- DB 서버 CPU 사용률이 100%까지 치솟았지만 티빙은 21시간 뒤에야 사고를 인지했다
- KISA 신고는 침해 인지 후 23시간 59분 만에 이뤄졌고, 이용자 공지는 이틀 뒤에 나왔다
- 티빙의 정보보호 투자액은 2022년 약 22억 원에서 2024년 약 17억 원으로 줄었다

## 인사이트

이번 건은 ‘비밀번호 유출 조심하자’ 수준이 아니라 클라우드 시대의 권한 관리 실패가 얼마나 크게 터질 수 있는지 보여주는 사례다. 특히 GitHub, AWS 키, 이상 탐지, 사고 대응 시간이 한꺼번에 엮여 있어서 국내 서비스 보안팀이 체크리스트로 삼을 만하다.