나는 .env Files가 Security Theater라서 Rust로 Zero-Config Secret Manager를 구축했다

발행: (2026년 3월 30일 PM 03:21 GMT+9)
3 분 소요
원문: Dev.to

Source: Dev.to

.env의 실제 문제점

구체적으로 무엇이 잘못됐는지 말씀드리겠습니다:

  1. 평문 파일이다. DATABASE_URL이 코드 옆에 있는 텍스트 파일에 저장됩니다. 노트북이 탈취당하면 모든 비밀도 함께 노출됩니다.
  2. 안전하지 않은 채널을 통해 전달된다. 새로운 개발자는 어떻게 비밀을 받나요? Slack DM, 이메일, 때로는 Google Docs. 이들은 저장 시 암호화되지 않으며, 색인되고 영구히 남습니다.
  3. 정적이다. 2022년에 만든 .env 안의 STRIPE_SECRET_KEY가 아직도 유효한가요? 아직도 오래된 노트북 백업에 남아 있습니다. 만료되지 않는 정적 자격 증명은 공격자에게 계속해서 선물이 됩니다.
  4. Git은 영원하다. .gitignore를 사용해도 비밀이 레포에 들어갑니다. 실수로 커밋하고 삭제해도 git log는 모든 것을 기억합니다. GitHub은 이러한 상황이 빈번히 발생하기 때문에 비밀 스캔 기능을 제공하고 있습니다.
  5. 감사 로그가 없다. 지난 화요일 새벽 3시에 PROD_DATABASE_URL에 누가 접근했나요? .env 파일로는 전혀 알 수 없습니다. 가시성이 전무합니다.

내가 대신 만든 것

이 문제에 지쳐 주말을 투자해 zenv 를 만들었습니다 — 개발자를 위한 제로‑컨피그 비밀 주입 런타임입니다. 소스 코드는 GitHub에서 확인할 수 있습니다: github.com/arvytechnolgies/zenv.

아이디어는 간단합니다: .env 파일을 런타임에 비밀을 주입하는 암호화된 금고로 교체하는 것입니다.

# Before zenv
cp .env.example .env
# edit .env with secrets from Slack...
npm start

# After zenv
zenv init
zenv vault import .env  # one‑time migration
zenv run -- npm start   # secrets injected at runtime
0 조회
Back to Blog

관련 글

더 보기 »

손상된 Git 저장소 복구 방법

손상된 Git 저장소 복구 git status가 fatal: bad object HEAD error: objec... 와 같은 메시지를 반환할 때 느껴지는 특별한 두려움이 있다.