배포 전 .env 값을 확인할 때 실제 프로세스 기준으로 보는 체크리스트

파일은 맞는데 앱은 틀린 값을 쓰고 있었다

결제 테스트용 URL을 운영 URL로 바꿨는데도 서버는 계속 테스트 서버로 요청을 보냈다. .env 파일을 열어 보면 분명히 값은 맞았다. 한참 뒤에야 실행 중인 프로세스가 예전 환경 변수를 들고 있다는 걸 확인했다.

이후로는 배포 전 점검을 "파일 확인"에서 끝내지 않고 "프로세스 기준 확인"까지 이어가고 있다.

1. 서비스가 어떤 방식으로 뜨는지 먼저 본다

systemd인지 Docker Compose인지, PM2인지에 따라 환경 변수가 들어가는 위치가 다르다.

systemctl status my-app.service

Docker Compose라면 컨테이너가 언제 다시 만들어졌는지도 본다.

docker compose ps

2. systemd 서비스 파일의 EnvironmentFile 확인

서비스 파일에 다른 env 파일이 연결돼 있을 수 있다.

systemctl cat my-app.service

여기서 EnvironmentFile=/etc/my-app/app.env처럼 적혀 있는데 프로젝트 폴더의 .env만 수정했다면 앱은 바뀐 값을 모른다.

3. 변경 뒤에는 reload와 재시작을 구분한다

서비스 파일 자체를 바꿨다면 daemon reload가 필요하다.

sudo systemctl daemon-reload
sudo systemctl restart my-app.service

단순히 env 파일 내용만 바꾼 경우에도 실행 중인 프로세스는 자동으로 값을 다시 읽지 않는다. 결국 프로세스를 새로 띄우는 과정이 필요했다.

4. 애플리케이션에서 안전하게 확인용 로그를 남긴다

민감한 값은 절대 그대로 찍지 않는다. 대신 host나 모드처럼 노출돼도 되는 일부만 확인했다.

console.log('[config]', {
  nodeEnv: process.env.NODE_ENV,
  apiHost: new URL(process.env.API_BASE_URL ?? 'http://invalid').host,
});

배포 직전 체크리스트

• 수정한 파일이 실제 서비스가 읽는 파일인지 확인했다.
• systemctl cat 또는 compose 설정에서 env 경로를 봤다.
• 프로세스를 새로 띄워야 하는 변경인지 판단했다.
• 로그에는 비밀번호, 토큰, 전체 DB URL을 남기지 않았다.
• 배포 후 프로세스 기준 설정값을 한 번 더 확인했다.

.env는 파일 하나처럼 보여도, 운영에서는 주입 경로가 여러 개가 된다. 나는 이제 "파일에 맞게 적혀 있다"보다 "지금 떠 있는 프로세스가 그 값을 쓰고 있다"를 완료 기준으로 둔다.