이미 커밋한 파일에서 비밀번호·API Key 완벽 삭제하는 법 (Push 전/후 총정리)

Posted on by steve

 

Git 커밋에 실수로 비밀번호나 API Key를 올리셨나요? 단순 파일 삭제 후 재커밋으로는 이전 히스토리에 민감 정보가 그대로 남습니다. 로컬 미푸시 상태부터 이미 원격 저장소에 Push된 상황까지, Git 히스토리에서 비밀정보를 완벽하게 영구 삭제하는 실전 솔루션을 단계별로 친절하게 정리해 드립니다!

 

코딩에 한창 몰입하다가 무심코 git add . 후 커밋과 푸시를 누른 순간, 등골이 오싹해졌던 경험 다들 한 번쯤 있으실 거예요. “아차, 방금 올린 파일에 AWS 시크릿 키랑 데이터베이스 접속 암호가 그대로 적혀 있었는데…!” 하는 순간 말이죠. 😱

저도 예전에 개인 프로젝트를 진행하다가 결제 연동 테스트용 시크릿 키가 담긴 .env 파일을 깃허브(GitHub) 퍼블릭 저장소에 올린 적이 있었어요. 불과 5분도 안 돼서 해외 IP로부터 비정상적인 접근 시도가 감지되었다는 클라우드 알림 메일을 받고 심장이 철렁 내려앉았답니다. 다행히 빠른 대처로 추가 과금이나 유출 피해는 막았지만, 그때 식은땀을 흘리며 배운 Git 히스토리 정제법은 지금도 가장 든든한 무기가 되었어요.

많은 분들이 당황해서 “해당 파일에서 비밀번호를 지우고 새로 커밋하면 되겠지?”라고 생각하시는데요, 안타깝게도 Git의 세계에서는 그렇게 해결되지 않습니다. 오늘 글에서는 왜 단순 삭제가 위험한지부터, 내 상황(Push 전/후)에 맞는 가장 안전하고 확실한 삭제 방법까지 속 시원하게 알려드릴게요! 😊

 

1. 단순 파일 삭제가 통하지 않는 치명적인 이유 🤔

Git은 파일의 현재 상태만 보관하는 단순한 웹 하드가 아니라, 프로젝트의 모든 변경 이력을 영구 보관하는 타임머신과 같아요. 파일에서 비밀번호를 지우고 새 커밋을 남기더라도, 과거 커밋 로그(Commit History)를 열어보면 누구나 당시 저장되었던 파일 내용을 온전히 열람할 수 있습니다.

특히 GitHub 같은 공개 저장소는 전 세계의 스캐너 봇들이 24시간 실시간 커밋 피드를 감시하고 있어요. API 키나 DB 암호가 커밋에 포함된 채 퍼블릭으로 공개되면 단 몇 초 만에 자동으로 수집되어 악용될 수 있습니다. 따라서 단순히 새 커밋을 쌓는 것이 아니라, 과거의 커밋 스냅샷 자체에서 해당 파일의 기록을 완전히 도려내는 작업이 반드시 필요합니다.

⚠️ 골든타임 최우선 행동 수칙!
만약 이미 GitHub 퍼블릭 저장소에 키가 노출되었다면, Git 기록을 삭제하기 전에 해당 서비스(AWS, OpenAI, 구글 클라우드 등)의 콘솔에 즉시 접속하여 노출된 키를 ‘비활성화(Disable)’하거나 ‘삭제(Revoke)’하고 재발급받으세요. 아무리 히스토리를 1분 만에 지워도 이미 봇이 긁어갔을 가능성이 매우 높기 때문입니다!

 

2. [상황 1] 아직 원격 저장소에 Push하지 않은 경우 💡

로컬 환경에서 커밋만 하고 아직 git push를 날리지 않으셨나요? 그렇다면 정말 천만다행이에요! 외부 세상에 아직 노출되지 않았으므로 로컬 저장소의 커밋 기록만 깔끔하게 정돈해 주면 끝납니다.

방법 A: 방금 한 최신 커밋 하나만 수정할 때 (가장 간단)

직전에 작성한 커밋에 실수로 민감 파일이 들어갔다면, 해당 파일만 추적에서 제외하고 커밋을 덮어쓰는(Amend) 방식이 가장 깔끔합니다.

📝 최신 커밋 덮어쓰기 명령어

1단계: 커밋 추적에서만 민감 파일 제외 (로컬 실물 파일은 유지)

git rm –cached .env

2단계: 커밋 메시지 변경 없이 직전 커밋 내용만 덮어쓰기

git commit –amend –no-edit

3단계: 앞으로 영구 제외되도록 .gitignore 파일에 .env 등록 후 커밋

방법 B: 커밋 자체를 취소하고 다시 준비할 때

커밋 상태를 아예 커밋 직전(Staging 이전)으로 되돌리고 싶다면 소프트/믹스드 리셋을 사용합니다. 작성했던 작업 코드는 안전하게 그대로 남겨집니다.

# 직전 1개 커밋을 취소하고 파일 변경 사항은 언스테이징 상태로 보존
git reset HEAD~1

이후 민감한 정보를 다른 곳으로 옮기거나 삭제한 뒤, 다시 git add 및 git commit을 진행하시면 됩니다.

💡 알아두세요!
몇 단계 이전 커밋에 민감 정보가 묻혀 있다면 대화형 리베이스인 git rebase -i HEAD~N(N은 확인할 커밋 수)을 실행해 해당 커밋의 pick을 edit으로 바꾼 뒤 수정하고 git rebase --continue로 이어갈 수 있습니다.

 

3. [상황 2] 이미 원격 저장소에 Push해 버린 경우 📊

이미 원격 브랜치에 커밋이 반영되었다면, 전체 히스토리를 거슬러 올라가 모든 커밋에서 해당 파일 흔적을 완전히 지우는 영구 재작성 도구를 써야 합니다. 과거에는 git filter-branch를 많이 썼지만, 처리 속도가 매우 느리고 저장소 손상 위험이 커서 현재 Git 공식 문서에서도 사용을 중단하길 권고하고 있어요.

현재 표준으로 쓰이는 가장 강력한 두 가지 해결책을 비교해 드릴게요!

Git 민감정보 제거 전문 도구 비교

비교 항목 git-filter-repo (공식 권장) BFG Repo-Cleaner
실행 환경 Python 3 기반 패키지 Java 실행 환경 (.jar 파일)
공식 지원 여부 Git 공식 커뮤니티 강력 권장 오픈소스 서드파티 도구
처리 속도 매우 빠름 (C수준 최적화) 극도로 빠름 (대용량 특화)
특수 기능 특정 텍스트 치환, 브랜치 재구성 파일 내 텍스트 치환 간편함

실전 가이드: git-filter-repo로 완벽하게 박멸하기

Git 공식 권장 도구인 git-filter-repo를 활용하는 정석 순서입니다. 작업을 시작하기 전 현재 프로젝트 폴더 전체를 다른 디렉터리에 복사해 백업해두는 것을 잊지 마세요!

1단계: 도구 설치 (Python이 설치되어 있어야 합니다)

pip install git-filter-repo

2단계: 전체 히스토리에서 해당 파일 흔적 완전 삭제 (예: config/secret.json)

git filter-repo –invert-paths –path config/secret.json

3단계: 원격 저장소 주소 재연결 (filter-repo 실행 후 안전을 위해 origin이 자동 해제됨)

git remote add origin <원격저장소-깃-URL>

4단계: 원격 저장소에 강제 푸시하여 서버 히스토리 교체

git push origin –force –all

 

4. 내 상황별 맞춤 솔루션 진단기 🧮

지금 내 커밋 상태가 어떤 단계인지 헷갈리시나요? 아래 선택 박스에서 현재 직면한 상황을 선택하고 버튼을 누르시면 가장 안전한 명령어 세트를 바로 확인하실 수 있습니다.

🔢 Git 긴급 상황별 솔루션 파인더

현재 발생 상황:

 

5. 실전 사례: 개발자 김주니어 씨의 긴급 탈출기 📚

실제 협업 프로젝트에서 발생할 수 있는 구체적인 가상 시나리오를 통해, 사고 발생부터 사후 수습까지의 매끄러운 전체 흐름을 짚어보겠습니다.

사례 주인공의 조난 상황

  • 상황: Node.js 프로젝트의 결제 모듈 연동 중 .env 파일에 실서버 PG사 API Key를 입력함
  • 실수: .gitignore 작성을 깜빡하고 git add . 후 메인 브랜치에 그대로 푸시 완료
  • 경과 시간: 푸시 후 약 7분 경과, 슬랙으로 동료 개발자가 유출 사실을 제보해 옴

김주니어 씨의 침착한 4단계 수습 절차

1단계 (1분 컷): PG사 개발자 센터에 즉시 로그인하여 유출된 API Key를 [즉시 폐기] 처리하고 신규 키를 발급받았습니다.

2단계: 터미널에서 git filter-repo --invert-paths --path .env를 실행하여 모든 로컬 커밋 기록에서 .env 흔적을 완벽히 소거했습니다.

3단계: 원격 저장소에 git push origin --force --all을 실행하여 GitHub 상의 히스토리를 덮어썼습니다.

4단계: .gitignore 최상단에 .env를 명시적으로 등록하고, 팀 슬랙 채널에 브랜치 재작성 사실을 공지하여 팀원들이 새로 git clone을 받도록 조치했습니다.

최종 결과 및 얻은 교훈

– 결과: 유출 직후 키가 무효화되어 금전적 피해 0원, 저장소 히스토리에서도 영구 삭제 성공

– 교훈: 팀 내에 pre-commit 훅과 git-secrets 도구를 도입하여 민감 키가 포함되면 아예 커밋되지 않도록 사전 차단 장치를 구축함

이처럼 당황하지 않고 키 폐기 ➔ 히스토리 재작성 ➔ 강제 푸시 ➔ 팀원 공지의 4박자 프로세스를 지키면 어떤 유출 사고라도 피해를 최소화하며 깔끔하게 수습할 수 있습니다.

💡

Git 민감 정보 삭제 3줄 핵심 요약

🚨 1원칙: 노출된 키는 무조건 즉시 폐기 및 재발급! 깃 지우는 동안에도 봇이 털 수 있습니다.
💻 Push 전: git rm –cached 후 git commit –amend로 직전 커밋 덮어쓰기!
🌐 Push 후:

git-filter-repo –invert-paths –path <파일명>

🛡️ 영구 예방: .gitignore 등록 및 pre-commit / git-secrets 훅 설치로 원천 봉쇄!

강제 푸시(force push) 후에는 반드시 팀원들과 브랜치 상태를 동기화해야 충돌이 나지 않습니다.

 

자주 묻는 질문 ❓

Q: GitHub 리포지토리를 Private(비공개)으로 바꾸면 안전한가요?
A: 임시방편일 뿐 결코 안전하지 않습니다. 이미 Public 상태였던 기간 동안 GitHub 아카이브나 검색 엔진, 전문 크롤링 봇에 데이터가 복제되었을 가능성이 매우 큽니다. 리포지토리 공개 범위 변경과 무관하게 노출된 키는 즉시 무효화하고 재발급받아야 합니다.

Q: git-filter-repo를 썼더니 remote origin 주소가 사라졌어요! 오류인가요?
A: 정상적인 안전장치 동작입니다! git-filter-repo는 사용자가 의도치 않게 원격 저장소로 즉시 실수 푸시하는 것을 방지하기 위해 기존 원격 저장소 URL(remote) 연결을 자동으로 끊어버립니다. git remote add origin <URL> 명령어로 다시 원격 주소를 연결해 주시면 정상 작동합니다.

Q: 이전 커밋에서 파일을 삭제했는데 GitHub 커밋 기록 링크가 웹에서 계속 열립니다. 왜 그런가요?
A: GitHub 서버의 캐시(Dangling Commit) 때문입니다. 강제 푸시를 하더라도 커밋 해시 ID(URL)를 직접 입력해 접근하면 캐시가 며칠 동안 남아있을 수 있습니다. 완전히 즉각 삭제를 원하신다면 GitHub 서포트 센터에 ‘캐시된 고아 커밋(Cached views) 영구 제거’ 티켓을 요청하셔야 합니다.

Q: BFG Repo-Cleaner와 git-filter-repo 중 어떤 것을 추천하시나요?
A: 일반적인 환경에서는 Git 공식 지원 도구인 git-filter-repo를 추천합니다. 단, 수십 기가바이트(GB) 이상의 방대한 히스토리를 가진 엔터프라이즈급 대형 저장소에서 특정 텍스트만 초고속으로 치환하고 싶을 때는 Java 기반의 BFG Repo-Cleaner가 더 직관적이고 빠를 수 있습니다.

Q: 협업 중인 팀원들은 강제 푸시 이후에 어떤 작업을 해야 하나요?
A: 팀원들이 기존 브랜치에서 그대로 git pull을 받으면 이전 커밋과 새 커밋이 엉켜 히스토리가 다시 복원될 위험이 있습니다. 팀원들은 작업 중이던 변경점만 임시 저장(Stash)해 둔 뒤, 로컬 브랜치를 원격 브랜치로 하드 리셋(git reset --hard origin/main)하거나 프로젝트를 새로 clone 받는 것이 가장 안전합니다.


개발자라면 누구나 한 번쯤은 겪는 아찔한 순간이지만, 원리를 알고 침착하게 대응하면 소중한 서비스와 보안을 지켜낼 수 있습니다. 가장 좋은 대처법은 애초에 커밋되지 않도록 .env 파일 생성 즉시 .gitignore에 넣는 습관이라는 점, 꼭 기억해 주세요! 추가로 궁금한 점이나 진행 중 막히는 명령어가 있다면 언제든 댓글로 편하게 물어봐주세요~ 😊