[Django] 환경변수로 빼야 하는 값과 아닌 값 구분하기

배경

프로젝트 코드를 정리하면서(민감정보 제거 작업을 하던 시점에) 설정값 몇 개를 환경변수(os.getenv)로 바꿔뒀었는데, 나중에 다시 보니 경로가 이상해 보여서 놀랐다. "이거 지금은 환경변수로 안 해도 되는 거 아닌가?" 싶어서 다시 확인해봤다.

확인해본 것 — 환경별로 값이 다른 건 이미 다른 방식으로 해결되어 있었다

config/settings/development.py:  NAS_SERVER_BASE = "/nas_shared/dev_customer_files"
config/settings/production.py:   NAS_SERVER_BASE = "/nas_shared/customer_files"

base.py에 있는 값은 실제로는 development.py/production.py에서 환경별로 오버라이드되고 있었다. 즉 "개발/운영 환경마다 다른 값이어야 한다"는 문제는 os.getenv가 아니라 환경별 settings 파일 분리로 이미 해결되어 있는 구조였다. 이건 Django에서 흔히 쓰는 정석적인 패턴이다 — 환경변수 방식과 settings 파일 분리 방식, 둘 다 유효한 접근이고 이 프로젝트는 후자를 쓰고 있는 셈이다.

그럼 뭘 기준으로 env var로 뺄지 말지 판단하나

이때 정리한 기준:

env var로 빼야 하는 것 — 환경마다 다르고, 유출되면 실제로 위험한 것

• DB 비밀번호, API 키 같은 진짜 자격증명
• 이런 값들은 이미 os.getenv(...) + 컨테이너 환경변수 주입 방식으로 올바르게 분리되어 있었다

하드코딩해도 되는 것 — 내부 정보지만 유출돼도 직접적 피해가 없는 값

• 예를 들어 내부망 UNC 경로(\\내부서버명\부서폴더 같은 것)는 DB 비밀번호 같은 진짜 민감정보가 아니라, 사내망 안에서만 의미 있는 서버 이름/경로다
• 외부에서 이 값을 안다고 해서 뭘 할 수 있는 게 아니다 (사내 VPN/네트워크 접근 자체가 막혀있다는 전제 하에)
• 저장소가 사내 전용(비공개)으로 운영된다면, 이런 값까지 굳이 env var화할 필요는 없다

핵심은: "환경마다 다르고 유출되면 위험한 것"만 env var로 빼면 된다는 것. 내부 경로처럼 "정보이긴 하지만 유출돼도 별 의미 없는 값"까지 전부 env var화하면 오히려 설정이 불필요하게 복잡해진다.

왜 예전엔 env var로 빼뒀었나

돌이켜보니, 예전에 env var 버전으로 정리했던 건 아마 이 코드를 외부에 공개(오픈소스 예시, 포트폴리오 공개용 등)할 목적으로 작업했을 때였던 것 같다. 그런 목적이라면 내부 경로 하나까지도 노출을 막아야 하니 env var가 맞는 선택이었을 것이다. 반대로 지금처럼 사내 전용 저장소로 쓰는 상황에서는, 이미 settings 파일로 환경 분리가 되어 있는데 굳이 env var까지 추가하는 게 오히려 불필요한 복잡도였다.

정리

• 환경별로 값이 달라야 한다 → settings 파일 분리(development.py/production.py)로 해결 가능, 꼭 env var가 필요한 건 아니다
• 진짜 민감정보(비밀번호, API 키)만 env var로 분리하면 충분하다
• 내부 전용 경로/호스트명 같은 건, 저장소 자체가 비공개(사내 전용)라면 하드코딩해도 실질적 위험이 없다
• 다만 코드 공개 목적이 생기면(오픈소스화, 포트폴리오 등) 그때는 다시 env var나 placeholder로 분리해야 한다 — 목적에 따라 기준이 달라진다는 걸 이번에 다시 확인했다

체크리스트 삼아 하나 더: 이런 판단을 할 때는 진짜 민감한 값(비밀번호류)이 실수로 저장소에 커밋되어 있지 않은지도 같이 확인하는 게 좋다. 내부 경로는 괜찮아도, 비밀번호 파일이 커밋되어 있다면 그건 별개로 반드시 잡아야 하는 문제다.