[Django].env (dotenv) 사용하는 분들께 (feat. 라이브러리 사용하기 전에 공식문서를 꼭 보자)

프로젝트를 개발하면서 특정 값을 저장해놓을 필요성이 있고 이런 것들을 보통 환경변수라고 지칭한다.

 

AWS SaaS를 사용하며 필요한 키들도 있고 결제를 한다고 하면 통신용 키도 필요하고 카카오라던가 네이버 인증과 같은 요소, 정부 Open API 등 셀 수 없는 곳에서 필요로 하는 특정 키값을 보관을 해야되기 때문이다.

 

Django에서는 이러한 값에 대한 파일을 관리하는 라이브러리는 국문으로 작성된 블로그 리서치 상 3개가 대표적으로 나온다.

1. python-dotenv

2. django-dotenv

3. django-environ

 

*본 글에서는 해당 라이브러리들을 사용하는 법이 아닌 여러 라이브러리 중에서 올바른 라이브러리를 선택하는 방법을 적어놓았다.

 

1. django-dotenv는 인제 떠나 보내자

해당 라이브러리는 충격적이게도 2017년 이후로 신규 버전 릴리즈가 된 적이 없다.

2017년 12월 12일이 마지막 버전 릴리즈였다

물론 단순히 키에 대한 벨류를 저장해놓는 부분을 간소화 시킨 라이브러리라고 치부하더라도 현재 2024년을 바라보는 시점에 너무 시간이 지나버린, 즉, 유지보수가 몇년간 이루어지지 않은 라이브러리를 사용한다는 것은 리스크가 너무 크다.

 

깃허브 레포에도 파이썬 3.8까지 테스트해봤다고 나와있으며 현 시점 파이썬 최신 릴리즈는 3.11.5이다...!

 

현재 2023년 9월 마무리되가는 시점임에도 django-dotenv를 검색하면 올해라던가 꽤 최신의 글에서 사용하고 사용법을 적은 블로그 후기가 보이고 있다.

 

적어도 뭔가를 본인이나 회사 프로젝트에 라이브러리를 사용하려고 하면 현재 유지보수가 잘 되어 있거나, 시간이 조금 지났어도 활발한 distribution, discussion이 진행되고 있는 라이브러리인지 한번 확인해볼 필요성은 있다라고 생각이 든다.

 

2. python-dotenv, django-environ 사용에 대한 제약은 크게 없다.

축구선수가 옷을 입을 시 바람막이를 입을 때 자기가 소속된 축구단의 바람막이를 입을 것이냐 아니면 매장에서 산 브랜드 바람막이를 입을 것이냐 정도의 차이일 것이다. 이러한 관점에서 django야 당연히 파이썬 기반의 프레임워크이기 때문에 파이썬 레벨에서의 라이브러리 사용은 당연히 가능하며, 단순히 사용법에 대한 차이만이 있다고 말할 수 있다.

 

두개의 라이브러리는 모두 유지보수 및 릴리즈가 잘 이루어지고 있는가? 

정답은 그렇다이다.

 

python-dotenv는 1.0.0 버전이다. 현재까지 큰 이슈가 없어 올해 2월 메인 1.0 버전 릴리즈가 되었다. 

https://pypi.org/project/python-dotenv/

python-dotenv

django-environ은 0.11.2 버전이다. 올해 9월 2일 최신 릴리즈가 이루어졌다.

https://pypi.org/project/django-environ/

django-environ

 

그럼에도 불구하고 Django는 django-environ이다.

python-dotenv로 만족되었다면 django-environ이 나올 이유가 없지 않았을까?

당연히 해당 라이브러리만의 고유 기능이 존재한다. 이것 또한 공식문서에 너무나도 잘 나와있다.

 

1) 파이썬과 장고 버전에 맞춘 테스트가 되어 있다.

It’s rigorously tested on Python 3.6+, and officially supports Django 1.11, 2.2, 3.0, 3.1, 3.2, 4.0, 4.1 and 4.2.

파이썬 3.6이상에서의 작동여부, 그리고 장고 4 LTS버전인 4.2에 대한 지원까지 확인할 수 있다.

 

2) 배포환경에 따른 변수분리가 편하다.

토이프로젝트에서는 개발 - 배포 2단계로만 수행되기에 이러한 내용이 와닿지는 않을 수 있으나 실무에서는 로컬-개발-운영이라는, 최소 3단계 이상의 스테이지가 존재하기에 각 스테이지별로 테스트를 수행하면서 실제 클라이언트 사용에 다가가야 한다.

 

일례로 결제 관련 예시를 들자면, 테스트 키를 발급받아 테스트 결제를 하다가 실제 배포할 때는 라이브 키를 추가하여 실제 결제가 클라이언트로부터 일어나게 해야 한다. 혹자는 수동으로 변경하면서 하면 되지 않을까? 하지만 Human Factor는 항상 실수를 유발한다.

적어도 .env, .env.dev 라던가 아니면 내부에서 분리하여 각 환경마다 처리하게 해준다면 이러한 실수는 미연에 방지할 수 있다.

 

해당 배포환경을 분리해 처리하는 방법에 대해서는 책으로는 Two Scoop of Django를 참조할 수 있으나 분리를 왜 해야하는지, 하면 어떤 효용가치만 있는지 참조해보는 것이 좋다. 왜냐면 책에서는 settings_dev.py 별도 생성 후 적용과 같이 settings.py를 분리하여 하는 방법을 제시하고 있는데 이러한 방법 대신 본 라이브러리를 사용한다면 기존 프로젝트 구조를 건드리지 않고도 분리하여 처리가 가능하기 때문이다.

 

3) 변수 타입 캐스팅

.env 파일을 적다보면 해당 데이터가 어떤 데이터 타입인지 확인이 어렵긴 하다. 대부분 문자열이나 불린 타입으로 처리되긴 해서 크게 문제된 부분은 본인 기준으로는 크게 없긴 했지만 그래도 이러한 부분까지 디테일을 써주는 것은 매우 올바른 자세라고 할 수 있다.

아울러, 자체적으로 타입 캐스팅을 해주는 옵션이 활성화가 되어 있으나 다음 메인 릴리즈에서는 해당 기능이 없어진다고 한다.

(아마 해당 옵션이 많은 분들을 괴롭힌게 아닌가 추정이 된다...)

 

https://django-environ.readthedocs.io/en/latest/types.html

Supported types - django-environ

 

4) 도커 배포용 함수 제공

도커를 사용해보시는 분들은 인지하고 계시겠지만 변수 이름에 '_FILE '을 추가하면 아래와 같이 시크릿 키등 값을 확인할 수 있는 경로를 포함할 수 있다.즉, .env('SECRET_KEY)처럼 시크릿키가 들어있다고 해도 도커에 명시된 해당값을 우선시해서 사용해줄 수 있다는 의미가 된다. 아래와 같이 FileAwareEnv()로만 변경해주면 된다.

env = environ.Env()

env = environ.FileAwareEnv()

https://django-environ.readthedocs.io/en/latest/tips.html

Tips - django-environ

 

그렇다면 결론은 이렇게 된다.

장고를 쓰는 개발자라면 django-environ이 가장 좋은 선택지가 될 것이며, 이외 다른 프레임워크를 쓰는 분들은 각 프레임워크에 종속되어 있는 환경변수 관련 라이브러리라던가 python-dotenv를 이용하여 환경변수를 관리하면 될 것이다.