환경변수
Environment Variables
환경변수란?
- 코드 밖에 보관하는 설정값
- API 키·비밀번호를 안전하게
- 환경마다 값 교체
환경변수를 쓰기 시작하면 코드의 성격 자체가 바뀝니다. 키를 걷어낸 코드는 외부에 보여줘도 되는 자산이 되고, 개발·스테이징·운영 서버에 같은 코드를 그대로 올려도 각 서버가 자기 환경의 값을 읽어 동작합니다. 배포할 때마다 파일을 열어 서버 주소나 비밀번호를 손으로 고치는 일이 사라지니, 테스트용 설정이 운영 서버에 그대로 따라 올라가는 사고도 함께 줄어듭니다.
환경변수에 담는 값은 성격이 둘로 갈립니다. 하나는 API 키·DB 비밀번호·토큰처럼 새어나가면 돈과 고객 데이터가 걸리는 비밀값이고, 다른 하나는 서버 주소·로그 레벨·기능 on/off 같은 환경별 설정값입니다. 앞의 것은 보관 등급을 올려야 합니다. 혼자 쓰는 단계에서는 .env 파일로 충분하지만, 팀이 붙으면 GitHub Actions Secrets나 배포 플랫폼의 환경변수 화면으로, 고객 데이터까지 다루면 AWS Secrets Manager 같은 전용 금고와 분기 1회 키 교체 규칙으로 넘어가는 것이 보통입니다.
주의할 경계가 하나 있습니다. .env는 암호화가 아닙니다. 그냥 이름과 값을 적어둔 텍스트 파일이라, 그 서버나 그 노트북에 접근할 수 있는 사람은 누구나 열어볼 수 있습니다. 그래서 실무에서는 파일 분리와 함께 누가 그 서버에 들어갈 수 있는지를 같은 무게로 관리하고, 키마다 월 사용 한도와 호출 알림을 걸어 유출되더라도 피해가 한도 안에서 멈추게 합니다.
현장에서 가장 자주 어긋나는 지점은 '.env 파일을 만들었으니 이제 안전하다'는 믿음입니다. gitignore를 나중에 추가해도 한 번 올라간 키는 커밋 히스토리에 그대로 남아 있어, 저장소를 비공개로 돌려도 이전 기록을 뒤지면 나옵니다. 브라우저에서 쓰는 프런트엔드 변수(NEXT_PUBLIC_ 류)는 이름만 환경변수일 뿐 사용자에게 다 보인다는 점, 그리고 에러 로그를 통째로 AI 채팅창에 붙여넣는 순간 키가 함께 넘어간다는 점도 자주 놓칩니다. 유출된 키는 지우는 게 아니라 폐기하고 새로 발급하는 것이 유일한 해법입니다.
운영체제가 프로그램에 설정을 전달하는 오래된 방식으로, 코드와 설정·비밀값을 분리하는 실무 원칙으로 자리잡았습니다.
가상의 사례로 살펴보겠습니다. 임직원 140명 규모의 화장품 유통사 A사에서, 개발자가 없는 마케팅팀이 AI에게 물어가며 상품 문의 챗봇을 2주 만에 만들었습니다. 코드는 팀원끼리 돌려보려고 GitHub 공개 저장소에 올렸습니다. 열흘 뒤, 평소 월 18만 원이던 AI API 사용료가 470만 원으로 청구됐습니다.
- 마케팅팀 박 대리가 결제 알림을 보고 '저희 챗봇 써본 사람이 300명도 안 되는데요'라고 보고했고, IT팀이 로그에서 해외 IP 4만여 건의 호출을 확인했습니다.
- IT운영 김 차장은 30분 만에 기존 키를 폐기하고 새 키를 발급했지만, 커밋 히스토리에 남아 있던 키까지 지우느라 저장소를 아예 새로 만들어야 했습니다.
- 이후 팀은 키를 .env 파일로 옮기고 gitignore에 등록했으며, 값 이름만 적은 .env.example을 저장소에 남겨 새 팀원이 15분이면 세팅을 끝내도록 했습니다.
- 김 차장은 개발용과 운영용 키를 따로 나누고 계정당 월 30만 원 한도와 사용량 알림을 걸어, 한도를 넘으면 호출이 자동으로 멈추게 설정했습니다.
- 비개발 직원 26명에게 40분짜리 사내 교육을 돌린 뒤 6개월간 키 유출은 0건이었고, API 요금은 월 470만 원에서 21만 원으로 내려갔습니다.