새 API 키를 쓰게 되면서, "실수로 GitHub에 올라가지 않게 해달라"고 부탁했다. 코드에 직접 안 쓰고 따로 관리하는 방식과, 이미 올라간 적 있는지 커밋 기록 전체를 검사하는 법을 정리했다.
A brass padlock securing a rusty wire on a concrete post, symbolizing security and protection.
이 글은 이런 분께
처음으로 API 키를 발급받아서 쓰게 됐는데, 어떻게 보관해야 안전한지 모르는 분
“이거 혹시 깃허브에 그대로 올라간 거 아니야?” 뒤늦게 걱정되는 분
“코드에 직접 쓰지 말라”는 말은 들었는데 그게 정확히 뭔 뜻인지 감이 안 잡히는 분
Before — 키를 만들긴 했는데 어떻게 보관해야 할지 몰랐다
Pexels API 키를 직접 발급받고 나니, 이 키를 어디에 어떻게 저장해야 안전한지가 걱정됐다. 코드 파일 안에 그냥 적어두면 될 것 같았는데, 그게 위험하다는 말은 어디선가 들어본 것 같았다. 그래서 이렇게 부탁했다.
API 키 를 쓰게 됐어. 실수로 GitHub에 올라가지 않게 안전하게 넣어줘.
- 키를 코드에 직접 쓰지 말고 따로 관리하는 방식으로 해줘.
- 그 파일이 .gitignore에 들어 있는지 확인해줘.
- 혹시 이미 올라간 적이 있으면 알려줘.어떻게 — 세 가지를 한 번에 확인
1. 키를 코드가 아니라 별도 파일에 저장
.env라는 파일 하나를 새로 만들어서 그 안에 키이름=값 형태로만 저장했다. 실제 코드에는 값이 아예 안 적히고, “환경변수(.env)에서 이 이름의 값을 읽어와라”는 지시만 남는다. 이렇게 하면 코드를 통째로 남에게 보여줘도 키 값 자체는 안 보인다.
2. .gitignore에 등록됐는지 확인
grep -n "\.env" .gitignore.env, .env.production이 이미 등록돼 있는 걸 확인했다. .gitignore는 “이 목록에 있는 파일은 깃허브에 절대 안 올린다”는 규칙을 적어두는 파일이다.
3. 예전 커밋 기록까지 전부 뒤져서 확인
지금 상태만 안전한 게 다가 아니다. 과거에 실수로 한 번이라도 올라간 적 있으면, 지금 지워도 예전 기록엔 남아있다. 그래서 처음 만든 이후의 전체 히스토리를 다 뒤졌다.
git log --all --full-history -- .env # .env 파일 자체가 커밋된 적 있는지
git log --all -p | grep "실제_키_문자열" # 키 값이 다른 파일 안에 그대로 적힌 적 둘 다 결과가 아무것도 안 나와야 안전하다는 뜻이다.
After — 결과
점검 항목
결과
.gitignore에 .env 등록 여부
✅ 이미 등록돼 있었음
.env가 지금까지 커밋된 적 있는지
✅ 한 번도 없음
키 값 문자열이 다른 파일에 남아있는지
✅ 없음 (전체 히스토리 검사)
세 가지 다 안전하다는 걸 확인하고 나서야 마음이 놓였다. “커밋 안 했으니까 괜찮겠지”가 아니라 직접 검사해서 눈으로 확인한 게 핵심이었다.
배운 것 / 재사용 자산
API 키는 “코드”가 아니라 “환경변수”에. 코드는 여러 사람이 보고, GitHub에 영구히 기록되고, 검색도 된다. 반면 .env 파일은 내 컴퓨터에만 있고 .gitignore가 깃허브 업로드 자체를 막아준다. 이 둘을 분리하는 게 API 키 보안의 기본이라는 걸 알게 됐다.
새 API 키를 받을 때마다 쓸 체크리스트
키 값을 코드에 직접 쓰지 않고
.env(또는 그에 준하는 별도 파일)에 저장했는가그 파일이
.gitignore에 등록돼 있는가전체 커밋 기록(
git log --all)까지 검사해서, 과거에 실수로 올라간 적이 없는지 확인했는가배포 사이트(Vercel 등)를 쓴다면, 그쪽 환경변수 설정에도 별도로 등록했는가
재사용 프롬프트
API 키를 쓰게 됐어. 실수로 GitHub에 올라가지 않게 안전하게 넣어줘.
- 키를 코드에 직접 쓰지 말고 따로 관리하는 방식으로 해줘.
- 그 파일이 .gitignore에 들어 있는지 확인해줘.
- 혹시 이미 올라간 적이 있으면 알려줘.이 네 줄만 기억해두면, 앞으로 어떤 API 키를 받든 똑같이 안전하게 시작할 수 있다.
