config 파일, 환경변수, DB — 어디에 둘지 헷갈릴 때 쓰는 기준

막상 쓰다 보면 섞인다

프로젝트 초반엔 .env 하나로 버티다가, 어느 순간 config YAML도 생기고, DB 테이블에 settings 같은 게 슬그머니 자라 있다. 세 군데 다 “설정”이라 부르지만 용도가 다르다. 구분 없이 쌓으면 배포할 때마다 “이거 어디 바꾸면 되지?” 소리가 나온다.

세 가지 기준: 변경 주기 / 비밀 여부 / 재배포 허용 여부

config 파일 (YAML, TOML, JSON)

• 변경 주기: 배포 단위. 코드 리뷰와 함께 간다.
• 비밀 아닌 것. 레포에 커밋해도 무방한 값.
• 예: 로그 레벨, 타임아웃 기본값, feature flag 초기값, 리전 코드.
• 재배포 없이 못 바꾼다 — 그게 장점이기도 하다. 변경 이력이 git에 남는다.

환경변수

• 비밀이거나, 환경(dev/staging/prod)마다 달라지는 값.
• DB URL, API 키, OAuth secret. 전부 여기.
• 2026년 기준 대부분의 플랫폼이 secret manager와 연동해 주입한다. .env 파일을 레포에 커밋하는 순간 이 카테고리의 의미가 없어진다.
• 주의: 환경변수가 50개 넘어가면 분류가 무너졌다는 신호다.

DB (runtime 설정 테이블)

• 재배포 없이 즉시 바꿔야 하는 값.
• 예: 사용자별 알림 on/off, A/B 테스트 비율, 긴급 점검 배너 노출 여부.
• 읽기 비용이 있다. 캐시 레이어 없이 매 요청마다 조회하면 병목이 된다. TTL 60초짜리 in-memory cache 하나로 대부분 해결된다.
• 변경 감사(audit)가 필요하면 updated_at + updated_by 컬럼은 처음부터 넣어야 한다. 나중에 추가하면 이력이 없다.

요약하면 이렇게 된다:

	config 파일	환경변수	DB
변경 반영	재배포	재배포 or 재시작	즉시
비밀 보호	✗	✓	별도 처리
변경 이력	git	플랫폼 로그	직접 구현
운영 중 수정	✗	△	✓

다음 한 가지

지금 프로젝트의 환경변수 목록을 열어서 “이게 왜 여기 있지?” 싶은 것 하나만 config 파일이나 DB로 옮긴다. 전체 정리는 안 해도 된다. 하나면 충분하다.

---

🛒 이 글과 어울리는 추천 상품

• 노트북 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 사무용의자 쿠팡에서 보기 →

위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.