.env 파일을 통해 API 키를 유출했습니다 — 비밀 관리(Secret Management)에 대해 배운 점

지난달, 저는 .env.production 파일이 포함된 커밋을 푸시했습니다.

.env.example도 아니었습니다. 가려진 템플릿도 아니었습니다. 실제 API 키, 데이터베이스 자격 증명(Credentials), 그리고 웹훅 비밀값(Webhook secrets)이 담긴 실제 파일이었습니다.

제가 무엇을 저질렀는지 깨닫기 전까지 그 파일은 리포지토리(Repo)에 정확히 4분 동안 머물러 있었습니다.

그 4분은 제 개발자 커리어 중 가장 긴 시간이었습니다.

".env는 안전하다"라는 신화

우리 모두는 똑같은 말을 들어왔습니다: ".gitignore에 .env를 추가하기만 하면 괜찮다"라고 말이죠.

이 조언은 기술적으로는 맞지만 실질적으로는 위험합니다. 이는 제가 저지른 것과 똑같은 실수를 유발하는 잘못된 보안 의식을 만듭니다.

대부분의 개발자가 깨닫지 못하는 사실은 다음과 같습니다: .env는 구성 관리 시스템(Configuration management system)이 아닙니다. 그것은 언제든 샐 수 있는 구멍 난 양동이와 같습니다.

제가 매일 목격하는 5가지 .env 실수

1. .env 파일 커밋하기 (네, 정말로요)

가장 명백한 실수입니다. 하지만 생각보다 자주 발생합니다. GitHub의 비밀 스캐닝(Secret scanning)이 많은 것을 잡아내지만, 전부는 아닙니다. 프라이빗 리포지토리(Private repos)는 안전하다고 느껴지지만, 그렇지 않은 순간이 옵니다.

# .gitignore
.env
.env.*
...

만약 이 라인들이 없다면, 지금 당장 추가하세요. 나중에가 아니라, 지금 말입니다.

2. 비밀값이 아닌 것을 .env에 저장하기

.env 파일은 오직 비밀값(Secrets)만을 위한 것입니다. 기능 플래그(Feature flags)가 아닙니다. API 엔드포인트(API endpoints)도 아닙니다. 환경 이름(Environment names)도 아닙니다.

저는 항상 이런 것을 봅니다:

# 잘못된 예 - .env는 비밀값용입니다
NODE_ENV=production
API_URL=https://api.example.com
...

올바른 접근 방식:

# config/production.ts - 비밀값이 아닌 설정
export const config = {
  apiUrl: "https://api.example.com",
...

3. 모든 환경에서 동일한 .env 구조 사용

개발(Development), 스테이징(Staging), 운영(Production) — 모두가 동일한 .env 템플릿을 공유합니다. CI에서 오타 하나만 발생해도 테스트 스위트(Test suite)를 운영 환경에 연결하게 됩니다.

대신, 환경 변수(Environment variables)에 네임스페이스(Namespace)를 지정하고 시작 시점에 검증(Validate)하세요:

// config/env.ts
const required = [
  "STRIPE_SECRET_KEY",
...

필수 키가 없는 상태로 앱이 시작되면 즉시 충돌(crash)이 발생합니다. 사용자가 테스트되지 않은 코드 경로(code path)를 실행하는 새벽 3시가 아니라 말이죠.

4. 순환 정책(Rotation Policy)의 부재

2년 전에 .env에 넣어둔 그 Stripe 키요? 아직도 거기 있습니다. 오래된 Sentry DSN은요? 여전히 활성화되어 있습니다. 폐기된 API 서비스는요? 그 자격 증명(credentials)이 여전히 당신의 저장소(repo)에 남아 있습니다.

비밀 정보(Secrets)에는 만료 날짜가 있어야 합니다. 캘린더 알림을 설정하세요. 최소한 분기별로는 순환(Rotate)시켜야 합니다.

5. Slack이나 이메일로 .env 공유하기

"운영(production) 키는 그냥 DM으로 보내줄게요."

안 됩니다. 비밀 관리자(secrets manager)를 사용하세요. 간단한 것이라도 좋습니다. 무료 티어라도 괜찮습니다. 채팅으로 자격 증명을 복사해서 붙여넣고 있다는 사실 자체가 당신의 비밀 관리(secret management)가 망가졌음을 의미합니다.

현재 내가 하는 방식

4분간의 패닉 이후, 저는 제 접근 방식을 재구축했습니다:

1. .env는 오직 비밀 정보만을 위해 사용 — 기능 플래그(Feature flags)와 설정(config)은 코드에 포함합니다.
2. 저장소에 .env.example 포함 — 모든 신입 개발자가 2분 안에 환경을 설정할 수 있게 합니다.
3. 시작 시 Zod 검증 수행 — 키가 누락되면 미스터리한 런타임 에러(runtime errors)가 발생하는 대신 즉시 충돌(crash)을 일으킵니다.
4. 비밀 정보 순환(Secret rotation) 캘린더 — 분기별 알림을 설정하고, 가능한 경우 자동화합니다.
5. 채팅으로 비밀 정보를 절대 입력하지 않기 — 플랫폼에서 제공하는 비밀 공유 기능(Pulumi, Doppler, 심지어 1Password까지)을 사용합니다.

진짜 교훈

.env 파일이 문제는 아닙니다. 문제는 단순한 텍스트 파일을 보안 경계(security boundary)로 취급하는 것입니다.

당신의 .gitignore는 방화벽(firewall)이 아닙니다. 당신의 프라이빗 저장소(private repo)는 금고(vault)가 아닙니다. 당신의 기억력은 비밀 관리자(secrets manager)가 아닙니다.

코드를 작성하듯 비밀 관리를 구축하세요. 명시적(explicit)이고, 검증(validated)되며, 검토(reviewed)된 방식으로 말이죠.

여러분의 최악의 .env 이야기는 무엇인가요? 댓글로 남겨주세요. 고통은 나누면 반이 되고, 우리는 서로의 아찔한 실수로부터 배울 수 있습니다.