회사 코드 저장소에 비밀번호 파일 28개가 5년째 들어 있었습니다 — 「지우면 된다」가 틀린 이유

개발자에게 「비밀번호 파일이 저장소에 올라가 있던데요」라고 하면 답은 거의 같습니다.
「지우면 되죠.」

그 말은 반만 맞습니다. 지우는 것은 10분이면 끝나고, 실제로 그날 지웠습니다. 그런데 지운 뒤에도 옛 값은 살아 있었고, 지우는 순간 다른 컴퓨터의 배포가 멈췄습니다.

9월 12일에 저희가 직접 겪은 순서 그대로 적습니다. 대표가 가져갈 것은 세 칸입니다.

고객사는 뉴스 앱을 운영하는 회사입니다. 그 백엔드 저장소를 정리하려고 추적 중인 파일 수부터 셌습니다.
157,347개였습니다.

그중 155,048개가 설치 부산물이었습니다. 개발 도구가 내려받는 외부 패키지 폴더인데, 저장소에 올릴 이유가 없는 것입니다. 정리를 마치니 2,275개가 남았습니다.

문제는 그 15만 개 사이에 섞여 있던 28개였습니다. DB 비밀번호, 외부 API 키, 결제·알림 서비스 토큰이 든 설정 파일들입니다. 첫 커밋부터 몇 년째 저장소 안에 있었습니다.

부산물 15만 개가 나쁜 이유가 여기 있습니다. 파일이 너무 많으면 그 사이에 든 28개가 보이지 않습니다. 몇 년째 아무도 못 본 이유가 게으름이 아니라 개수였습니다.

코드 저장소는 파일 보관함이 아닙니다. 누가 언제 무엇을 바꿨는지를 전부 남기는 이력 장부입니다.
그래서 오늘 파일을 지워도 어제의 파일은 장부에 그대로 있습니다.

저장소를 복제한 사람은 누구나 그 장부를 되감아 볼 수 있습니다. 퇴사한 개발자의 노트북, 외주사의 서버, 한 번 공개로 잘못 열렸던 순간의 복제본까지 전부입니다.

이건 저희 해석이 아니라 GitHub 공식 문서의 첫 경고입니다.

"if the sensitive data you need to remove is a secret (e.g. password/token/credential), as is often the case, then as a first step you need to revoke and/or rotate that secret."

풀어 쓰면 이렇습니다. 지워야 할 것이 비밀값이면 첫 단계는 지우기가 아니라 폐기하거나 새것으로 바꾸는 것이다. 문서는 그다음 줄에서 이력을 다시 쓰는 수고가 「필요 없을 수도 있다」고까지 적습니다.

같은 일이 채팅에서도 벌어집니다. 상담 채널에서 한 대표님이 외부 서비스 인증을 마치고 완료 화면을 통째로 붙여 넣으셨습니다.

그 아래에 접근 토큰 원문이 이어졌습니다. 화면은 「새로고침하면 사라진다」고 적혀 있었지만, 채팅에 붙는 순간 채팅 이력에는 남습니다. 메시지를 지워도 상대 쪽 알림과 백업에는 남습니다.

이력이 남는 도구에서는 삭제가 곧 안전이 아닙니다. 지운 뒤의 상태는 「없어 보이는」 상태일 뿐입니다.

추적 해제 변경을 합친 그날, 두 번째 일이 벌어졌습니다.
그 변경을 받은 컴퓨터에서 비밀 파일 28개가 디스크에서도 사라졌습니다.

저장소에서 「이 파일은 더 이상 추적하지 않는다」고 기록하면, 그 기록을 내려받는 쪽은 파일을 지우는 것으로 따라갑니다. 배포 서버든 다른 개발자의 노트북이든 같습니다.

저희 작업용 맥에서도 지워졌습니다. 미리 떠 둔 백업본 35개로 되돌려 놓고서야 배포가 다시 됐습니다. 백업이 없었다면 그날 저녁 배포는 멈춘 채였을 겁니다.

그래서 지우는 날은 질문이 하나 더 붙습니다. 「이걸 지우면 다른 컴퓨터에서 무엇이 사라지나.」 배포 컴퓨터마다 복원 절차와 백업본을 먼저 만들고 나서 지웁니다.

그러면 순서는 이렇게 됩니다.
새 키를 발급하고, 서비스를 새 키로 옮기고, 옛 키를 서비스 쪽에서 폐기합니다. 그다음에야 저장소의 옛 파일은 지워도 안 지워도 무해합니다.

이 순서를 「키 회전」이라 부릅니다. 자물쇠를 새로 달면 옛 열쇠가 어디에 굴러다니든 문은 안 열립니다. 옛 열쇠를 찾아 없애는 일은 그 뒤에 해도 됩니다.

바꾸기가 얼마나 확실한지는 저희 실수에서 봤습니다. 위 대표님 채널에서 저희가 검증한다고 토큰을 한 번 호출했더니, 그 서비스는 그 호출만으로 저장된 토큰을 무효로 만들었습니다.

채팅에 붙었던 토큰 원문은 그 순간 종이 조각이 됐습니다. 지워서가 아니라 바뀌어서입니다. 대표님이 다시 동의 버튼 한 번을 눌러 새 토큰이 나왔고, 옛것은 어디에 남아 있어도 쓸 수 없습니다.

비밀값 사고에서 대표가 확인할 질문은 하나입니다. 「지웠나」가 아니라 「바꿨나」입니다. 그 고객사에서도 남은 결정은 지우기가 아니라 28개 키의 회전입니다.

「몇 개가 올라가 있나요」를 개발자에게 물으면 기억으로 답합니다. 기억은 몇 년 전 것입니다.
대신 명령 한 줄을 받아 두면 언제든 같은 숫자를 다시 셀 수 있습니다.

추적 중인 파일 수를 세는 명령, 비밀 파일 이름 패턴을 세는 명령, 이 두 줄이면 됩니다. 이번 사례에서 첫 줄의 답이 157,347에서 2,275로 바뀌었습니다. 분기마다 같은 명령을 돌리면 다시 늘어나는지 보입니다.

AI가 대신 센 결과도 같은 명령으로 다시 확인합니다. 이번 정리에서 저희 보조 에이전트가 「배포 설정 파일의 AWS 키도 커밋돼 있다」고 보고했습니다. 명령으로 다시 세니 그 파일은 제외 목록에 걸려 애초에 올라간 적이 없었습니다.

보고가 틀렸다고 AI가 쓸모없는 것은 아닙니다. 28개를 찾아낸 것도 같은 에이전트였습니다. 다만 찾은 것과 센 것은 사람의 명령으로 한 번 더 확인하고 나서야 결정의 근거가 됩니다.

정리

경고 신호

• 비밀 파일 사고에 개발자의 답이 「지웠습니다」에서 끝난다

• 저장소에 몇 개가 올라가 있는지 세는 명령이 회사에 없다

• 지우는 날 배포 컴퓨터에서 무엇이 사라지는지 아무도 묻지 않았다

• AI나 개발자의 「커밋돼 있다」 보고를 명령으로 다시 세지 않는다

좋은 신호

• 새 키 발급·서비스 이전·옛 키 폐기까지 끝난 날짜가 키마다 적혀 있다

• 추적 파일 수와 비밀 파일 패턴을 세는 명령 두 줄이 있고 분기마다 같은 숫자를 남긴다

• 저장소에서 빼기 전에 배포 컴퓨터마다 백업본과 복원 절차가 먼저 있다

• 보고는 사람이든 AI든 명령 출력으로 한 번 더 확인하고 결정한다

개발자에게 오늘 물어볼 네 가지

1. 저장소에 비밀값이 든 파일이 몇 개 있습니까? 세는 명령을 보여 주세요.
   기억이 아니라 명령의 출력으로 답을 받습니다. 이번 사례는 28개였습니다.

2. 그 키들은 새것으로 바뀌었습니까, 지워지기만 했습니까?
   지우기만 한 상태는 옛 커밋과 복제본에 값이 그대로 남은 상태입니다.

3. 저장소에서 빼면 배포 컴퓨터에서 무엇이 사라집니까?
   받는 쪽 디스크에서도 파일이 지워집니다. 백업본과 복원 절차를 먼저 만듭니다.

4. 이 숫자를 분기마다 다시 셀 수 있습니까?
   같은 명령을 같은 자리에서 돌려 늘어나는지 봅니다.

자주 묻는 질문

Q. 파일을 지웠는데 왜 아직 위험합니까?

코드 저장소는 변경 이력을 전부 보관합니다. 오늘 지워도 파일을 올렸던 과거 커밋에 값이 그대로 남고, 저장소를 복제한 컴퓨터마다 그 이력이 통째로 있습니다. GitHub 문서도 비밀값이면 첫 단계는 삭제가 아니라 폐기·회전이라고 적습니다.

Q. 키 회전이 정확히 무엇입니까?

새 키를 발급해 서비스가 새 키로 동작하게 옮긴 뒤, 옛 키를 발급처에서 폐기하는 일입니다. 옛 키가 어디에 남아 있든 더는 쓸 수 없게 됩니다. 이 순서가 끝나야 저장소의 옛 파일이 무해해집니다.

Q. 이력까지 다시 써서 지워야 합니까?

회전이 끝났다면 필수는 아닙니다. GitHub 문서는 회전 뒤에는 이력을 다시 쓰는 추가 작업이 「필요 없을 수도 있다」고 적습니다. 이력 재작성은 협업자 전원의 저장소를 다시 맞춰야 하는 큰 작업이라 별도로 결정합니다.

Q. 지우는 날 배포가 멈춘 이유는 무엇입니까?

「더 이상 추적하지 않는다」는 변경을 받은 컴퓨터는 그 파일을 디스크에서 지우는 것으로 따라갑니다. 배포에 필요한 설정 파일이 사라지니 배포가 안 됩니다. 저희도 백업본 35개로 복원하고서야 다시 됐습니다.

Q. 몇 개가 올라가 있는지 대표가 직접 볼 수 있습니까?

개발자에게 「추적 중인 파일 수」와 「비밀 파일 이름 패턴 수」를 세는 명령 두 줄을 받아 두면 됩니다. 이번 사례는 첫 줄이 157,347에서 2,275로 바뀌었습니다. 분기마다 같은 명령을 돌려 숫자를 남깁니다.