비밀번호를 바꾸는 게 늘 정답은 아니다

보안 사고를 발견하면 으레 “지금 당장 비밀번호를 바꿔야 한다”는 충동이 온다. 그 충동이 꼭 틀린 건 아니지만, 항상 옳지도 않다. 이 글은 키를 바꾸기 전에 먼저 따져봤어야 할 것에 대한 짧은 반성이다.

며칠 전 코드 저장소 히스토리를 뒤지다가, 챗봇에 쓰이는 토큰 하나가 예전 커밋에 그대로 박혀 있는 걸 발견했다. 나는 여러 대의 컴퓨터에 AI 챗봇을 올려두고 일을 시키는데, 그 챗봇이 외부 서비스와 대화할 때 쓰는 일종의 비밀 열쇠다. 그게 삭제되지 않은 채로 코드 이력 안에 남아 있었다.

순간적으로 떠오른 건 딱 하나였다. “바꿔야 해.”

재발급이라는 선택지

토큰 재발급(rotate)은 보안에서 교과서 같은 처방이다. 노출된 열쇠는 버리고 새 열쇠를 받는다. 이 열쇠를 발급한 서비스(텔레그램 봇 서버)에서 기존 토큰을 취소하고 새 토큰을 발급받는 절차 자체는 어렵지 않다. 클릭 몇 번이면 끝난다.

그래서 곧장 했다. 취소하고, 새 토큰을 받고, 다섯 대 기계에 흩어진 설정 파일을 하나씩 열어 새 값으로 교체했다. 여기까지는 계획대로였다.

예상하지 못했던 후폭풍

문제는 그다음에 왔다. 다섯 대를 다 바꿨다고 생각했는데 한 대가 빠져 있었다. 그 기계의 챗봇이 옛날 토큰으로 계속 통신을 시도하다가 “인증 실패(401)“를 뱉기 시작했다. 그 자체는 심각한 사고는 아니다. 그런데 이 오류를 감시하는 자동 알림이 30분 동안 연속으로 울려댔다. 한 대만 빠트렸을 뿐인데, 그 기계가 죽은 것처럼 보이는 오진 알림이 계속 쌓였다.

결국 나 포함 이 시스템을 신경 쓰는 사람이 “이게 진짜 고장인가, 아니면 토큰 교체 중 헝클어진 건가”를 판단하느라 시간을 소비했다. 단순히 설정 파일 하나를 고치면 끝나는 일이었지만, 그 과정이 시끄러웠다.

끝나고 보니 이런 계산이 서 있었다.

직접 손댄 시간: 봇 서버 접속 → 취소 → 재발급 → 다섯 대 설정 파일 교체
놓친 한 대를 수습하는 시간
30분간 울린 가짜 알림을 정리하는 시간
알림이 진짜인지 가짜인지 판별하느라 멈춘 흐름

반면 재발급으로 막으려 했던 위험은 얼마나 컸는가. 그 저장소는 외부에 공개되지 않은 비공개 저장소였다. 노출됐다 해도 나와 나의 기계들 외에 그 히스토리를 뒤질 수 있는 사람이 사실상 없었다.

위험이 작았다. 그런데 대응 비용이 컸다.

노출 가리기가 먼저였다

나중에 룰을 정리하면서 생각이 정리됐다. 토큰 노출을 발견했을 때 맞는 순서는 이랬다.

노출된 파일에서 토큰 값을 지운다(redaction)
그 파일이 다시는 비밀 값을 담지 않도록 .gitignore 같은 안전망을 확인한다
노출 사실을 기록해 둔다

재발급은 그다음, 그것도 “이 노출이 정말 위험한 상황이라면”이라는 조건 아래서 판단하는 일이다. 위험도가 낮은 비공개 환경이라면, 재발급보다 redaction이 훨씬 저렴하고 조용하다.

이렇게 쓰면 “그럼 보안 대응 안 하겠다는 거냐”로 들릴 수 있다. 그게 아니다. 대응하되, 비용에 맞는 대응을 한다는 이야기다.

반사적 처방의 함정

“보안 문제 발견 → 즉시 재발급”은 직관적이고, 교과서적이고, 전문가들이 권하는 방법이다. 그래서 아무 의심 없이 따라가기 쉽다.

그런데 이 처방이 전제하는 상황이 있다. 위험이 실제로 크다는 것. 토큰이 공개 저장소에 노출됐거나, 악의적인 제3자가 접근할 수 있는 환경이거나, 그 토큰으로 막을 수 없는 피해가 발생할 수 있는 서비스라거나.

모든 전제가 맞지 않는 상황에서도 같은 처방을 반사적으로 적용하면, 위험보다 수습이 더 시끄럽다. 나는 그걸 이번에 실제로 겪었다.

앞으로 토큰 노출을 발견했을 때는 재발급부터 떠올리지 않기로 했다. 먼저 “이 노출이 실제로 위험한가”를 따지고, 위험도가 낮다면 redaction으로 조용히 끝내기로.

결국 비용-편익이다

보안 대응이 특별하게 느껴지는 건, 위험에 맞서는 일처럼 보여서다. 하지만 실제로는 다른 의사결정과 같은 구조다. 위험이 있고, 대응 방법이 있고, 각각의 비용이 있다. 위험 비용보다 대응 비용이 크면 그 대응은 잘못된 처방이다.

“비밀번호를 바꾸는 게 정답”인 경우는 분명히 있다. 하지만 “항상 정답”은 아니다. 그 판단을 가르는 건 위험의 크기이지, 노출이 발생했다는 사실 자체가 아니다.

조용히 가릴 수 있는 걸, 굳이 시끄럽게 바꾸지 않아도 된다.

이 글은 비공개 저장소 환경에서의 경험을 바탕으로 씁니다. 공개 저장소나 외부 접근 위험이 있는 환경이라면 재발급이 맞는 첫 단계일 수 있습니다.

— 강대종