깃허브에 API 키를 올렸다?! 당황하지 않고 해결하는 방법
개발을 하다 보면 예기치 못한 실수를 저지르는 경우가 종종 있다. 그중 하나가 바로 API 키를 깃허브에 올리는 치명적인 실수다. API 키는 애플리케이션의 중요한 정보를 담고 있어 외부에 노출될 경우 심각한 보안 문제를 야기할 수 있다. 만약 API 키를 깃허브에 올렸다면 당황하지 않고 다음 단계를 따라 해결해보자.
1. 현재 상황 파악하기
firebase를 쓰려고 필요한 패키지를 다운받고 commit을 했더니 온 한 메일...
 |
| !? |
API 키가 노출된 것을 확인했다면 가장 먼저 해야 할 일은 침착하게 현재 상황을 파악하는 것이다. 어떤 파일에서 API 키가 노출되었는지, 어떤 커밋에서 문제가 발생했는지 확인해야 한다. 깃허브의 히스토리 기능을 이용하면 커밋 기록을 쉽게 추적할 수 있다.
(vscode의 extension 중 'Git graph'를 사용하면 visualize하기 쉽다)
 |
| git graph |
2. API 키가 노출되지 않은 안전한 커밋으로 이동하기
깃허브 히스토리에서 API 키가 노출되지 않은 가장 최근 커밋을 찾았다면, git checkout <commit hash> 명령어를 사용하여 해당 커밋으로 이동한다. <commit hash>는 히스토리에서 확인한 커밋의 고유한 해시 값을 의미한다. 이 명령어를 실행하면 로컬 저장소의 main 브랜치가 해당 커밋으로 이동하게 된다.
(Git graph에서는 단순히 우클릭 만으로 checkout이 가능하다)
 |
| checkout |
3. API 키를 안전하게 제거하고 다시 커밋하기(커밋만!!)
이제 API 키가 노출된 파일을 수정해야 한다. API 키를 제거하거나, 더미 데이터로 변경하여 다시 커밋한다. 이때, 커밋 메시지에 API 키 제거와 관련된 내용을 명확하게 작성하는 것이 좋다.
커밋을 하면 다음과 같이 파란색 로컬 브랜치와 분홍색 원격 브랜치로 나뉘는 것을 볼 수 있다.
 |
| local vs remote |
4. 로컬과 클라우드 브랜치의 충돌 해결하기
API 키를 제거하고 다시 커밋했다면, 로컬 저장소의 main 브랜치와 깃허브 클라우드의 main 브랜치는 서로 다른 상태가 된다. 이 상태에서 단순히 git push 명령어를 사용하면 충돌이 발생하게 된다. 따라서 git push -f origin main 명령어를 사용하여 로컬 브랜치의 커밋 기록을 클라우드에 강제로 반영해야 한다.
-f 옵션은 --force 옵션의 줄임말로, 로컬 브랜치의 변경 사항을 클라우드 브랜치에 강제로 덮어쓰도록 지시한다. 이 명령어를 실행하면 API 키가 노출된 커밋 기록이 삭제되고, API 키가 제거된 상태의 커밋 기록으로 대체된다.
 |
| 분홍색 branch는 사라지고 하나로 합쳐진 모습! |
주의: 이번 경우는 API key가 노출된 이후 거의 바로 인지한 덕분에 별 걱정 없이 사용할 수 있었다. 하지만 git push -f 명령어는 클라우드 저장소의 기록을 덮어쓰므로 주의해서 사용해야 한다. 협업 중인 프로젝트의 경우, 다른 개발자들에게 이 명령어를 사용할 것임을 미리 알리고 충돌을 방지해야 한다.
5. 다시 한번 확인은 필수!
git push -f origin main 명령어를 실행한 후, 깃허브 저장소에서 API 키가 제거되었는지 다시 한번 확인한다.(반영된 줄 알았는데 다시 가보니 그대로인 삽질 ㅠㅠ)
히스토리에서 API 키가 포함된 커밋이 삭제되었는지, 파일에서 API 키가 제거되었는지 꼼꼼하게 확인해야 한다.
 |
| 반영이 완료된 모습 |
패키지를 다운받았더니 거기에 API 키가 들어가 있었을 줄이야... 이번 기회로 git에 대해 하나 더 배워간다.
