티빙으로 배우는 히스토리의 역설

TL;DR

2026년 9월 3일, 과기정통부와 KISA 민관합동조사단에서 티빙 침해사고 조사 결과를 발표했다. 단순한 해킹 사고로 생각했지만, 개발자의 깃허브 PAT가 유출되었다는 점이 핵심이었다. 누구나 히스토리를 쉽게 알 수 있도록 모든 것을 공유했던 업무 문화 와 함께 2024년 모의해킹 지적사항을 방치한 결과 로 발생한 침해 사고다.

• 티빙 사태, DB 유출보다 깃허브에 주목할 이유
• 정부 "티빙, 개인정보 3954만 계정 유출"... 기술자산도 함께 털렸다
• 취약점 방치한 티빙, ISMS 인증은 무엇을 확인했나

히스토리를 알기 쉬운 업무 환경

나는 평소 이력서를 작성할 때 "히스토리를 알기 위한 코드 작성을 지향한다"라고 써왔다. 현재 몸을 담은 회사는 코드에 대한 히스토리를 알기 어려운 문제를 가지고 있기 때문이다. 그래서 업무상 히스토리를 추적할 수 있는 개발 문화가 필요하다라고 생각해왔다. 하지만 이번 티빙 사고를 보면, 누구나 히스토리를 쉽게 알 수 있는 업무 환경이 역설적이게도 위험할 수 있다는 점을 생각해보게 되었다.

공유 문화가 부른 침해의 과정

깃허브 PAT 노출과 과거 히스토리 노출 문제

근본적인 원인은 개발자의 깃허브 PAT 유출이라고 한다. 얼마 전에 경찰청에서 깃허브 PAT 유출 주의 및 조치를 권고했던 게 아마 이 사건을 계기로 한 것으로 추정된다. 깃허브 PAT 유출에 대한 인지는 조사 과정에서 발견했을 수도 있는 부분이다.

현재 회사도 얼마전까지 깃허브 PAT 를 발급해서 사용하고 있었다. 지금은 GitHub CLI 를 사용하고 있지만 내 컴퓨터가 해킹되면 이 문제는 동일하게 발생할 수 있다. 더 나아가서 티빙이라는 회사의 업무 방식은 누구나 히스토리를 알 수 있게 하는 개발 문화로 모든 개발자에게 전체 열람 권한을 부여한 것으로 보인다.

뉴스에서는 개발자라고 했지만 비개발자 인력들도 포함되어 있을 수 있다. 현재 회사의 사업팀도 관련된 프로젝트별 저장소에 이슈를 보고 작성할 권한을 가지고 있으니까 말이다. 아무튼, 개발자가 발급해서 사용하던 깃허브 PAT 가 유출된 게 시작점이라고 하니 그 부분에 대해 생각을 좀 해봐야겠다.

모든 저장소 권한을 가지는 깃허브 PAT 를 사용하여 소스 코드 뿐만 깃 히스토리까지 살펴볼 수 있게 된다. 이 말은 누군가 한번이라도 보안 키 또는 크레덴셜 정보를 커밋해서 올렸다면 현재 눈에 보이지 않더라도 히스토리에 남게 된다는 것이다. 보통 깃 히스토리를 정리하는 건 어려우니 실수로 포함된 키 또는 크레덴셜은 폐기하고 새로 발급해서 사용하는 걸 권장하게 된다.

보안 실수가 아닌 편한 운영 방식

정부 발표는 "개발자 149명 대비 보안 인력이 4명으로 부족했다"라는 점을 지적했으나 "보안의 불편함보다는 편한 업무 환경을 우선시한 문화" 때문으로 생각하게 된다. 티빙 채용 공고를 보면 엄격한 코드 리뷰와 테스트 문화를 강조하고 품질을 중시하는 것으로 보이는데 개발자들이 잘 관리할 수 있다고 신뢰했던 것 같다. 2024년 모의해킹에 발견된 지적사항인데도 불구하고 현재까지도 조치되지 않고 방치된 걸 보면 말이다.

암호화 키 유출

application-prod.yml

  # 운영 설정 파일을 깃에 그대로 커밋하면 안 된다.
spring:
    config:
        activate:
            on-profile: prod
    datasource:
        url: jdbc:postgresql://prod-db.internal:5432/service
        username: admin
        password: my-prod-password-1234
cloud:
    aws:
        credentials:
            access-key: PRD_AWS_ACCESS_KEY
            secret-key: PRD_AWS_SECRET_KEY

실제 서비스 운영 환경에서 사용되는 암호화 키가 소스코드에 포함되어 있었다고 한다. 이 말은 운영 환경에서 필요한 정보들을 빌드 환경에서 주입하는게 아니라 저장소에서 프로파일로 구분해서 운영 프로파일(application-prod.yml)을 통째로 깃에 올려두고 사용했음을 의미한다.

티빙이 ISMS-P 인증을 받았어도 깃허브 저장소를 어떻게 사용하고 있는지는 직접 검사하지 않고 서류 상으로만 판단하는 것으로 보인다.

보안은 귀찮아야 한다.

해킹 사고로 늘 배우게 되는 건 보안은 귀찮아야 한다 는 것이다. 개발자 스스로 우리 회사가 개발하기 편하다는 느낌이 든다면 위험한 신호를 내재하고 있을 수 있다는 말이다. 과연 우리 조직의 저장소에는 보안 키가 포함되지 않았다고 보장할 수 있을까?