1. 왜 아직도 .env를 그냥 올리나요?

생각보다 많은 개발자들이 이런 실수를 합니다.

• .env 파일을 깃에 그대로 커밋

• 테스트용 API 키를 “일단” 올림

• 나중에 지우면 되겠지라고 생각

• Private 레포니까 괜찮겠지라고 착각

하지만 Git은 “히스토리 기반 시스템”입니다.
한 번 올라간 시크릿은 커밋 기록 전체에 남습니다.

삭제해도 안 사라집니다.

심지어 GitHub에서 레포를 비공개 → 공개로 바꾼 순간
과거 커밋의 키가 크롤링되어 자동으로 수집되는 사례도 많습니다.

OpenAI API 키, AWS Access Key, GCP Service Account JSON, Stripe Secret Key
이런 것들은 노출되면 곧바로 악용됩니다.

실제로 GitHub에는 자동으로 시크릿을 스캔하는 봇이 상시 대기 중입니다.

—

2. “삭제했는데요?”가 통하지 않는 이유

git rm .env
커밋 삭제
revert

이걸로는 부족합니다.

Git은 분산 버전 관리 시스템입니다.
이미 push된 커밋은 clone된 모든 로컬과 fork에 남아있습니다.

히스토리를 완전히 정리하려면:

• git filter-repo

• BFG Repo Cleaner

• force push

• 팀원 전원 re-clone

실무에서는 거의 불가능에 가깝습니다.

그래서 애초에 “올리지 않는 구조”를 만들어야 합니다.

—

3. Git Secret이 필요한 이유

Git Secret은 말 그대로:

“Git 저장소 안에 시크릿을 안전하게 보관하는 방법”

핵심 아이디어는 간단합니다.

• 파일은 암호화된 상태로 커밋

• 복호화 키는 특정 GPG 사용자만 보유

• 저장소에는 평문이 절대 존재하지 않음

즉,

git에는 암호화된 blob만 존재
개발자 로컬에서만 복호화

입니다.

—

4. Git Secret의 기본 구조

대표적인 도구는 다음과 같습니다.

• git-secret

• sops (Mozilla)

• git-crypt

이 중 가장 직관적인 건 git-secret입니다.

설치 후:

git secret init
git secret tell your@email.com
git secret add .env
git secret hide

이렇게 하면 .env는 암호화되어 커밋됩니다.

다른 팀원이 clone 후:

git secret reveal

을 해야 복호화됩니다.

—

5. “근데 그냥 GitHub Secret 쓰면 되잖아요?”

맞습니다.
CI/CD에서는 GitHub Actions Secret, GCP Secret Manager 등을 쓰는 게 맞습니다.

하지만 문제는 로컬 개발 환경입니다.

• 팀원 5명이 .env 파일을 슬랙으로 주고받는다?

• 드라이브에 공유한다?

• 노션에 복붙한다?

이미 거버넌스가 무너진 상태입니다.

Git Secret은 “시크릿 배포 경로를 통제”하는 도구입니다.

—

6. 실무에서 더 중요한 것: 키 순환(Rotation)

많은 개발자가 “숨기는 것”만 생각합니다.

하지만 더 중요한 건:

• 키를 얼마나 자주 교체하는가

• 누가 접근 가능한가

• 퇴사자 접근을 어떻게 차단하는가

Git Secret은 암호화 통제일 뿐
거버넌스 정책을 대신해주지 않습니다.

그래서 다음 구조가 이상적입니다:

1. Git에는 암호화된 파일만 존재

2. 실제 운영 키는 Secret Manager에서 주입

3. 개발 키는 주기적으로 재발급

4. 키 권한은 최소 권한 원칙 적용

—

7. 초보자가 가장 많이 하는 3가지 실수

1. .gitignore에 넣으면 안전하다고 믿음
   → 이미 커밋된 파일은 ignore와 무관

2. Base64 인코딩을 암호화로 착각
   → 인코딩은 누구나 복원 가능

3. “Private 레포라 괜찮다”
   → 내부 유출, 협력사 접근, 계정 탈취는 항상 발생

—

8. 추천 실전 전략

개인 프로젝트라면:

• 최소한 .env는 절대 커밋하지 말 것

• 실수했다면 즉시 키 폐기

팀 프로젝트라면:

• git-secret 또는 sops 사용

• 운영 키는 반드시 Secret Manager 사용

• 키 접근 권한을 문서화

• CI 로그에 키 노출 여부 점검

스타트업이라면:

• 초기부터 시크릿 관리 체계를 설계해야 함

• “나중에 정리하자”는 100% 폭탄이 됨

—

9. 결론

Git Secret은 단순한 보안 도구가 아닙니다.

이건 “개발자 성숙도 테스트”입니다.

시크릿 관리가 허술한 팀은
배포, 인프라, 접근 통제도 거의 항상 허술합니다.

그리고 보안 사고는
대기업보다 스타트업에서 더 많이 터집니다.

지금 레포를 한 번 열어보세요.

.env
firebase-admin.json
service-account.json
config.js 안에 API_KEY

혹시 하나라도 있습니까?

있다면
이 글을 저장해두세요.

그리고 오늘 당장 키를 폐기하세요.

—

필요하다면 다음 글에서는:

• git-secret vs sops vs git-crypt 비교

• 실제 운영 환경에서의 시크릿 거버넌스 구조

• OpenAI API 키 노출 시 대응 절차

까지 다뤄보겠습니다.

이건 단순 팁이 아닙니다.
개발자의 기본기입니다.