팀 단위의 env 환경변수 중앙 관라 구축하기

By Lee Jin-Sung
project

사내 프론트엔드 챕터 회의에서 개발 팀원들과 함께 작업하면서 겪었던 고충을 공유하는 시간을 가졌다.

여러 가지 의견이 나왔지만, 그중에서도 가장 시급하게 해결해야 할 문제로 ‘env 환경변수’가 꼽혔다. 현재 프로젝트마다 API 키 및 API 주소 등 환경변수 정보들은 컨플루언스를 활용하여 관리 중이었다.

해당 방식으로 관리할 경우 나타난 문제를 요약 하자면,

1. 컨플루언스는 문서화 도구이지, CI/CD 파이프라인과 직접 연동할 수 있는 구조가 아님.
2. 각 프로젝트별 환경변수에 대한 변경 사항 추적 불편
3. GitHub Actions secrets에 설정된 환경변수는 보안상 한 번 입력하면 다시 볼 수 없음. <📎 이미지 참조>

캡쳐_이미지 📎 누가 어떤 값을 설정했는지 파악이 어려움

결론은 현재처럼 __Confluence__에서 관리하고 __GitHub Actions__에서 따로 설정하면 관리 포인트가 분산되므로 중앙 관리 시스템이 필요하다고 판단되었다.

중앙 관리 시스템 도입에 앞서 도입하고자 한 기술 및 클라우드 서비스는 아래와 같다.

  1. Dotenv Vault
  2. Doppler
  3. AWS Secrets Manager

환경 변수 관리 시 비용까지 고려하지는 않았으며, 관리해야 할 환경 변수의 수가 많지 않기 때문에 AWS Secrets Manager는 무료 버전을 지원하지 않아 도입 대상에서 제외되었다.

Dotenv Vault

캡쳐 이미지2

Dotenv Vault는 .env 파일을 암호화하고 안전하게 공유할 수 있도록 도와주는 환경 변수 관리 도구이며, 기존의 .env 파일을 그대로 사용하면서 보안을 강화할 수 있도록 설계되었다.

즉 해당 서비스는 기존 .env 파일을 그대로 사용하면서도 보안을 강화하고 싶다면 Dotenv Vault가 매우 적합하다.

해당 서비스의 테스트 셋팅 중 우리는 문제를 빨리 발견하였다.

캡쳐 이미지3

Dotenv Vault 파일을 생성하면 기본적으로 development, staging, production 환경이 자동으로 추가되는데, 이걸 직접 수정하려면 유료 플랜($4/월)이 필요하다.

프론트엔드 챕터팀에서는 환경변수 관리에 있어 비용까지 고려하지 않았고, 일부 프로젝트에서는 dev, stage, prod 외에도 추가적인 환경이 필요할 수 있다. 결국 적용에 어려움이 있다고 판단되어 최종적으로 선택하지 않기로 결정했다.

Doppler

캡쳐 이미지4

Doppler는 환경 변수와 비밀 키(Secrets)를 중앙에서 안전하게 관리할 수 있도록 도와주는 Secrets Manager이다. GitHub Actions, AWS, Vercel, Docker 등 다양한 환경과 쉽게 연동할 수 있어서 개발자들이 환경 변수를 편리하게 관리할 수 있도록 설계되었다.

팀에서 궁극적으로 원하는 목표는 환경 변수의 중앙 관리였고, Dotenv Vault와 달리 프론트엔드 챕터 공용 계정 하나로 각 환경에 따른 커스텀 기능(배포 환경 이름 수정 및 추가)을 지원하고 있어, 검토한 서비스 중 Doppler가 가장 적합한 선택지로 보였다.

우선 개인 계정으로 가입 후 테스트 셋팅을 진행해 보았다.

Doppler setting 하기

doppler 회원가입 후 환경 변수 셋팅하기

캡쳐 이미지5

캡쳐 이미지6 환경변수 셋팅된 화면

확실히 Dotenv Vault와 달리, 무료 계정에서도 각 프로젝트 환경과 하위 환경을 모두 커스텀할 수 있어 자유도가 높다. 또한, 환경변수 설정하면서 직관적인 UI/UX 덕분에 사용자 편의성이 뛰어난 클라우드 서비스라고 느꼈다.

캡쳐 이미지7 다양한 환경변수 타입 제공

환경변수 설정 시 문자열뿐만 아니라 JSON, UUID 등 다양한 형식도 지원하여 유연하게 활용할 수 있고, 등록하거나 수정시 히스토리도 있어 현황 파악에 매우 유용하다.

설치

brew install gnupg
brew install dopplerhq/cli/doppler

설치가 완료되면 아래 프롬프트 명령어를 통해 버전을 확인할 수 있다.

doppler --version

로그인 인증하기

doppler login

명령어를 입력시 자동으로 doppler 인증 페이지가 접속된다. (계정 서비스 환경 연결 후 터미널에 인증코드가 출력되니 괜히 무의식적으로 구글 메일로 들어가 기다리고 있는 시간 낭비 하지 말자..😅)

Doppler 셋업 설정

우선 명령어 입력 전 셋팅할 프로젝트 경로로 이동해야 한다.

doppler setup

캡쳐 이미지8

Doppler 셋업 명령어를 입력하면, GIF 이미지처럼 연결할 프로젝트를 선택할 수 있는 옵션이 제공된다.

연결이 잘됐는지 확인을 하고 싶다면 본인이 Doppler 서비스에 설정한 환경변수 이름을 작성해보자

doppler run -- printenv | grep "환경변수명"

캡쳐 이미지9

터미널 창에 위 사진처럼 내가 Doppler 클라우드 사이트에서 등록한 환경변수가 찍혀 있는 것을 확인할 수 있다.

로컬 개발 서버 실행 시 환경 변수 적용

doppler run -- npm run dev

이처럼 Next.js, React, Express 등 다른 프레임워크에서도 doppler run을 붙이면 환경 변수가 적용된 상태로 실행된다. 따라서 Doppler를 설정해두면 .env 파일을 생성하지 않고도 직접 변수를 주입할 수 있어, 별도로 .env 파일을 관리할 필요가 없다.

결론

이렇게 임시로 Doppler 환경을 설정해보면서 편리한 점을 몇 가지 느꼈다.

  • 환경 변수 관리의 용이함: .env 파일 없이도 변수를 직접 주입할 수 있어 관리가 편리하다.
  • 프로젝트별 설정: 각 프로젝트와 하위 환경을 손쉽게 커스텀할 수 있어 유연하다.
  • 직관적인 UI/UX: 웹 사이트 환경변수 설정 과정이 직관적이고 사용자 친화적이다.
  • 다양한 변수 형식 지원: 문자열뿐만 아니라 JSON, UUID 등 다양한 형식의 변수를 지원하여 유연하게 활용할 수 있다.
  • 중앙 집중식 관리: 모든 환경 변수와 설정을 중앙에서 관리할 수 있어 여러 프로젝트를 관리할 때 효율적이며, 프론트엔드 챕터 팀원들이 공동으로 작업할 때 일관성 있는 설정을 유지하는 데 유리하다.

우선, 회사에서 중요도가 낮은 프로젝트들을 단계별로 등록하여 설정을 진행할 예정이다.

현재는 회사에 프로젝트가 많지 않아 프론트엔드 챕터 공용 계정 하나로 관리하고 있으며, 향후 회사의 운영 서비스가 증가하면 경영팀에 제안하여 유료 버전으로 관리하는 방안을 고려하고 있다.