티빙 3954만 계정, 열쇠 하나가 아니라 잠기지 않은 문 다섯 개였다

이 사고를 "개발자가 키를 코드에 넣어놨다"로 읽으면 절반만 읽은 겁니다. 조사 결과를 보면서 제가 계속 붙들고 있던 질문은 하나였어요. 키가 코드에 없었다면 이 사고는 안 났을까. 제 답은 "그때는 안 났겠지만 언젠가는 났다"입니다. 개발자 한 명의 접속키가 새는 일은 어느 조직에서든 일어나거든요. 피싱이든, 노트북 분실이든, 메신저에 붙여 넣은 키든. 조사단도 PC 9대를 포렌식하고 최초 탈취 경로를 끝내 못 찾았잖아요. 그래서 이 글은 "키가 왜 샜나"가 아니라 "키 하나가 샜을 때 왜 3954만 계정까지 갔나"를 따라갑니다.

공격자는 문을 다섯 번 통과했다

과기정통부 조사단 발표를 시간순이 아니라 관문 순으로 다시 세워 보면 이렇습니다.

첫 번째 문. 개발자 한 명의 개발환경 접속키로 5월 29일에 들어왔는데, 그 키로 개발 프로젝트 361건 전부에 손이 닿았어요. 티빙이 모든 개발자에게 전체 프로젝트 접근 권한을 줬기 때문이죠. 개발 인력 149명 중 누구 키가 털리든 결과가 같았다는 뜻이고요.

두 번째 문. 그 개발 프로젝트 안에 운영환경 접속키 43개가 들어 있었습니다. 41개는 소스코드에 하드코딩, 3개는 평문 환경변수, 1개는 중복. 개발 코드가 새면 운영 열쇠가 같이 새는 길을 스스로 깔아 둔 셈이죠.

세 번째 문. 운영 키 43개 중 2개로 AWS 운영환경에 들어갔더니 개인정보 DB 접속 아이디와 비밀번호가 평문으로 놓여 있었어요. 여기까지 오면 DB 는 이미 열린 거고요.

네 번째 문. 첫 시도가 5월 30일에 있었고, DB 서버 CPU 가 100% 까지 올라가서 알람이 울렸습니다. 티빙은 조회 작업을 차단했어요. 여기가 이 사고의 진짜 분기점이라고 저는 봐요. 차단은 했는데 해킹이 아니라 시스템 이상으로 판단했고, 추가 침해에 대비한 조치를 하지 않았거든요. 공격자는 다음 날 다른 운영 키로 다시 들어왔습니다.

다섯 번째 문. 두 번째로 쓴 키에는 AWS 안에 가상 서버를 만들 권한이 있었어요. 공격자는 서버를 하나 띄워 DB 데이터를 거기로 옮기고 해외 서버로 약 24GB 를 내보낸 뒤 서버를 지웠습니다. CPU 는 10% 이내로 유지하면서요. 첫날 탐지된 방식을 학습해서 피한 거죠.

다섯 문 중 하나만 잠겨 있었어도 결과가 달랐다는 게 제 판단입니다. 권한이 프로젝트 단위로 쪼개져 있었으면 361건이 아니라 몇 건이었을 거고, 운영 키가 개발 리포에 없었으면 개발환경에서 멈췄을 거고, DB 자격증명이 시크릿 매니저에 있었으면 AWS 에 들어가도 DB 는 못 열었을 거고, 첫날 알람에서 키를 전부 회전했으면 둘째 날 침투가 없었을 거고, 그 키에 서버 생성 권한이 없었으면 24GB 를 빼돌릴 통로가 없었을 거예요. 하드코딩은 두 번째 문 하나입니다. 헤드라인이 거기에만 붙는 게 저는 좀 불편해요.

3954만은 사람 수가 아니라 계정 수다

숫자도 한 번 뜯어 볼 필요가 있어요. 처음 알려진 1953만명은 티빙이 자체적으로 중복을 제거해 신고한 수치고, 조사단이 확인한 계정은 3954만697개입니다. 활성 2206만3021개, 휴면 850만2679개, 탈퇴 886만8174개, 테스트 10만6823개. 한 사람이 최대 13개 계정을 갖고 있던 사례도 나왔어요. 가입 경로별로는 네이버·카카오·애플 같은 SNS 간편가입이 약 2247만개로 가장 많고, CJ ONE 통합회원 약 863만개, 티빙 자체 가입 약 726만개 순이고요. 연계정보(CI)가 있는 약 1904만개에서 약 580만개 중복을 걷어내면 약 1324만개인데, CI 가 없는 약 2040만개는 동일인 여부를 확인할 길이 없습니다. 그래서 실제 피해자 수는 개인정보보호위원회가 따로 확정하기로 했어요.

여기서 제가 보는 건 계정 모델 설계예요. 탈퇴 계정 886만개가 유출 대상에 들어 있다는 건 탈퇴 후에도 데이터를 지우지 않았다는 뜻이고, 테스트 계정 10만개가 운영 DB 에 섞여 있다는 건 환경 분리가 데이터 층에서도 안 됐다는 뜻이거든요. 유출 항목은 20개 항목 70종이고 CI 보유 계정은 평균 11.1개, 미보유 계정은 4.6개 항목이 나갔습니다. 휴대전화번호와 이메일 일부는 암호화돼 있었지만 암호화키가 함께 유출돼 평문과 같은 수준으로 판정됐어요. 암호화를 했느냐가 아니라 키를 데이터와 같은 곳에 뒀느냐가 갈랐죠. 비밀번호만 일방향 암호화라 복구가 안 됐고요.

2024년에 알고도 안 고친 이유는 뭐였을까

이 사고에서 가장 뼈아픈 사실은 티빙이 2024년 모의해킹에서 하드코딩 취약점을 이미 확인했다는 겁니다. 발표는 "개선하지 않았다"에서 멈추는데, 왜 안 했는지를 상상해 보면 우리 팀 얘기가 됩니다.

운영 키 43개를 코드에서 걷어내는 작업을 생각해 보세요. 키를 시크릿 매니저로 옮기고, 코드가 런타임에 읽게 바꾸고, 기존 키를 폐기하고, 배포하고, 깨지는 곳을 잡아야 하잖아요. 한 프로젝트면 하루지만 361개 프로젝트에 흩어져 있으면 분기 단위 과제죠. 정보보호 전담 인력이 외주 빼고 4명 안팎이었습니다. 265명 회사에서 4명이 이걸 밀어붙이려면 개발 조직의 우선순위를 빼앗아야 하는데, 그게 안 됐던 거라고 저는 읽어요. 정부도 이런 키 관리가 ISMS 인증 기준에 맞지 않는다고 했지만, 모의해킹 리포트에 하드코딩 41건이 찍혀 있어도 고칠 사람과 시간이 배정되지 않으면 리포트는 그냥 문서거든요.

같은 맥락의 사실이 몇 개 더 있습니다. 접속키의 발급·사용·변경·폐기 절차가 없었고, 일부 개발자는 사내 메신저로 키를 공유했어요. VPN 접속 기록은 6일만 보관돼서 조사단이 탈취 경로를 추적하지 못했고요. 모니터링은 CPU 부하를 보는 수준이었고, 대량 조회나 비정상 네트워크 흐름을 잡는 체계는 없었습니다. 도구가 없어서라기보다 보안이 개발 속도를 늦추면 안 된다는 암묵적 합의가 오래 유지된 조직의 모습이에요. 저는 이걸 티빙만의 문제로 보지 않아요. 키 회전을 한 번도 안 해본 팀, 로그 보관 기간을 비용 때문에 줄여 둔 팀은 생각보다 많거든요.

월요일에 우리 팀이 확인할 것

이 사고를 읽고 리포에서 액세스 키를 grep 하는 건 좋은 시작이지만, 거기서 끝내면 두 번째 문만 잠그는 겁니다. 순서를 이렇게 잡는 걸 권해요.

먼저 폭발 반경부터 그려 보세요. "개발자 한 명의 노트북이 오늘 털리면 어디까지 가나"를 종이에 그리는 거예요. 그 사람이 접근할 수 있는 리포 수, 그 리포에 들어 있는 자격증명, 그 자격증명이 열 수 있는 운영 리소스. 티빙은 이 그림이 "전부 → 운영 키 43개 → DB 평문 자격증명 → 가상 서버 생성 가능"이었습니다. 우리 팀 그림이 이것과 얼마나 다른지가 첫 질문이에요.

그다음이 권한 범위입니다. 리포 접근을 팀 단위로 쪼개면 불편하고 요청이 늘어나요. 그래도 해야 하는 이유가 이번에 숫자로 나왔습니다. 키 하나로 361건이 열리는 조직과 열 건이 열리는 조직은 같은 사고를 겪어도 규모가 서른 배 넘게 다르잖아요. IAM 키에 붙은 권한도 마찬가지고요. 데이터 읽기용 키에 컴퓨트 생성 권한이 왜 있는지 설명 못 하면 떼야 합니다.

세 번째가 탐지 이후의 행동이에요. 티빙은 첫날 알람을 받았고 차단도 했습니다. 부족했던 건 "왜 CPU 가 100% 였나"를 끝까지 묻는 것과, 원인을 모를 때는 침해로 가정하고 키를 전부 돌리는 결정이었어요. 알람 대응 절차에 "원인 불명이면 자격증명 회전"이 한 줄 들어 있었으면 24GB 는 안 나갔을 겁니다. 돈 드는 일이 아니라 결정의 문제죠.

로그 보관 기간은 마지막이지만 빼먹기 쉬워요. 6일은 조사가 시작되기도 전에 증거가 사라지는 길이입니다. 인증·VPN 로그는 최소 한 분기는 두는 게 맞다고 봐요.

과징금이 아니라 소스코드가 남은 문제

발표에서 사람들이 덜 보는 대목이 있어요. 개인정보와 함께 추천·검색 알고리즘, 인증 체계, 결제 관리 소스코드 30.35GB 가 나갔습니다. 침해 인지 시점은 5월 31일 오전 10시 10분이고 KISA 신고는 다음 날 오후 3시 8분이라 정보통신망법의 24시간 규정을 넘겼는데, 그 과태료가 3000만원 이하예요. 9월 11일 시행되는 개정 개인정보보호법의 매출액 최대 10% 과징금은 시행일 전 사고라 적용이 안 되고요. 그러니 금전적 제재는 이 회사 규모에서 거의 의미가 없고, 진짜 부담은 유출된 코드가 다음 공격의 지도가 된다는 점입니다. 인증 로직과 결제 흐름을 공격자가 소스 레벨로 들고 있는 상태에서 서비스를 계속 운영해야 하거든요. 조사단도 추가 공격에 악용될 가능성을 짚었고요.

저는 이 사고의 교훈을 "키를 코드에 넣지 말자"로 요약하는 팀보다 "키 하나가 새도 여기서 멈춘다는 선을 어디에 그을 것인가"를 회의 안건으로 올리는 팀이 다음 사고를 피한다고 봅니다. 전자는 이미 다들 알고 있고, 티빙도 2년 전에 알았어요. 후자는 권한을 쪼개고 알람 대응 절차를 고치는 불편한 일이라 아무도 먼저 꺼내지 않죠. 보안 인력이 네 명이든 마흔 명이든, 그 불편을 감수하기로 결정하는 건 개발 조직이에요.