Private 저장소인데 .env.local 파일 그냥 올리면 안 될까?
개발 중 빌드 에러를 해결하기 위해 환경변수 파일을 Git에 통째로 올리는 실수를 방지합니다. Private 저장소라도 환경변수를 분리해야 하는 보안적 이유와 하드코딩의 위험성을 다룹니다.
Q: Git 저장소가 Private이면 그냥 올려도 되지 않나요?
많은 초보 개발자들이 "어차피 나랑 우리 팀원들만 보는 비공개 저장소인데, .env.local을 올리면 안 되나?"라는 의문을 가집니다.
A: 절대 안 됩니다. Private 저장소라도 코드를 올리는 순간 심각한 보안 위험에 노출됩니다.
GitHub는 코드를 저장하는 곳이지 비밀번호를 보관하는 금고가 아닙니다.
상세 설명: 왜 위험할까?
첫째, 팀원 중 한 명의 깃허브 계정만 털려도 모든 데이터베이스와 클라우드 인프라가 털립니다. 해커가 코드를 읽을 수 있게 되는 순간, DB 비밀번호와 AWS 키까지 모두 가져갈 수 있습니다.
둘째, 퇴사자가 발생했을 때 코드는 두고 가더라도 서버 접속 권한은 즉시 회수해야 하는데, 소스코드에 비밀번호가 적혀있으면 대처가 매우 힘들어집니다.
Q: 임시방편으로 파일 없이 빌드를 통과시키면 어떤 문제가 발생하나요?
GitHub Actions에서 빌드가 자꾸 실패해서, 소스코드 안에 API 키를 하드코딩해버리는 "임시방편"을 쓸 수도 있습니다.
A: 운영 환경과 개발 환경의 분리가 불가능해지고, 나중에 원인을 알 수 없는 런타임 에러가 터집니다.
상세 설명: 하드코딩이 낳는 파국
코드 안에 `const dbUrl = "실제DB주소"`처럼 박아두면, 나중에 테스트 서버(Staging)를 새로 띄워야 할 때 똑같은 코드가 실제 운영 DB를 건드리는 대참사가 일어납니다.
따라서, GitHub Actions를 돌릴 때는 GitHub Repository Settings > Secrets 메뉴에 변수들을 안전하게 등록하고, 워크플로우(`.yml`)에서 불러와 주입하는 것이 유일한 정답입니다.
이정마 에디터
DevOps Engineer
당장의 빌드 에러를 덮기 위해 .env.local을 커밋하거나 코드에 하드코딩하는 것은 "기술 부채"를 넘어선 "보안 시한폭탄"입니다. 반드시 GitHub Secrets를 활용하세요.