파이썬 가상환경은 왜 이렇게 다양하고, 개발자들은 왜 이렇게 다양한 가상환경을 만들었을까?

Ryan Kim
7 min readDec 19, 2019

--

pipenv, virtualenv, venv, pyenv 등 가상환경의 개발 배경 및 가상환경별 사용 목적을 중심으로!

올해 3월 처음으로 프로그래밍을 접했을 때, 나는 django라는 프레임워크를 사용해서 개발을 접하게 되었다. 지금은 옛날보다 조금 나아지긴 했지만 (꾸준히 개발 공부를 지속적으로 했으니,,) 당시엔 X프 투 파이썬이라는 책 갓 떼고 프레임워크 처음 다뤄보던 시기라 모든 게 익숙하지 않았다.

MTV? app? settings.py에는 뭐가 이렇게 많이 쓰여진거야? models.py는 뭐지?

기본적인 것들에 대해 다양한 삽질을 경험해보고 있었고, 그 중에 대표적인 것이 가상환경 안돌리고 로컬에 라이브러리 바로 설치하거나, 낮은 버전의 파이썬을 로컬에 그대로 설치해버리는… 이런 경우들이었다.

와,, 지금 생각해보면 정말 끔찍하지 않을 수 없다. 프로그래밍을 처음배우는 사람들의 특징일 수 있다?

옆에 누가 제대로 설명해주는 사람도 없고, 비전공생인데 그런거 아나? 까짓거 그냥하는거지~~~이러면서 무작정 설치를 일주일 정도 반복하다가 장고가 프로젝트별로 다른 가상환경이 필요하다는 것을 알게 되었고, (사실 장고 뿐만 아니라 모든 개발 환경은 프로젝트별로 요구하는 파이썬 버전, 장고 버전, 사용하는 버전들이 모두 다를 수 있다. 의존성 — dependency — 문제도 있고!) 그제서야 가상환경에 대한 것들을 찾아보게 되었다.

그래서 처음 사용해보게 된 것이 파이썬 라이브러리에서 제공하는 ‘venv’라이브러리다. 설치하는 것도 워낙 간단해서 장고 입문자에게 안성맞춤이었고,

> python -m venv <project name>

이것만 입력하면 됐었고, 윈도우와 맥 모두 source <project name>/bin/activate만 bash 환경에서 입력하면 가상환경 돌리기도 쉬웠다. 이걸 거의 5개월 동안 사용했었나?

아직 라이브러리 의존성 등을 고려하지 않은 개발을 경험해보지 않은 나로서 가상환경의 불편함을 느끼진 않았는데, 제대로된 불편함을 느꼈던 적이 있었다. 바로 장고 프로젝트를 배포할 때!

배포는 AWS EC2를 사용했는데, 당시에 무엇 때문인지 명확히 기억나지 않지만, EC2 환경에서 배포하는 과정에서 python 3.6이 설치되어 있지 않다는 문구가 발생했고 (당시 로컬 환경은 python 3.7.4, EC2는 3.5 버전이었다), 3.6 버전 파이썬은 venv를 활성화시킨 상태에서 설치했음에도, 버전은 여전히 3.5였다.

도저히 문제가 뭔지 몰랐는데, 최근 와서 알게 된 사실은 venv 가상환경은 파이썬 버전 변경이 안된다는 것이었다.

실화야? 그 때 이걸로 삽질을 10시간 넘게 했는데!!!!!

stackoverflow에 온갖 글들을 다 찾아보면서 해결책을 다 적용해봤는데 안되서 결국 친구랑 타협안으로 어찌어찌 3.5로 배포를 진행했는데, 그 날 이후 venv 가상환경은 이제 사용하지 않는다.

근데 의문인 것은 다른 가상환경을 찾는 과정에서 왜 이렇게 파이썬 가상환경이 많냐는 것이었다.

— pyenv, .evn, pipenv, virtualenv, venv 등 등 개발자들이 참 많이도 가상환경을 구성해놨었다.

최근에 한 스타트업에서 인턴을 하면서 확실한 정보는 아니지만 시니어 개발자님이 겪어본 바를 개인적인 의견으로 풀어서 설명해본 바,

일단 개발자들이 가상환경을 사용하는 주 목적은 로컬 개발 환경과 실제로 개발해야하는 소프트웨어가 요구하는 개발 환경의 괴리가 크기 때문에 사용하는 것은 이견이 없다.

하다못해 파이썬 2, 3 사이에 하나의 가상환경 내에서 호환이 안되는 차이도 상당히 많고, 정말 최악의 경우에는 print를 찍어보려고 할 때, print도 안되는 경우가 있었다고 한다.

게다가 특성 가상환경 세팅이 내가 원하는 개발환경 세팅을 못맞춰 주는 경우도 있다고 한다.

결정적으로 배포 환경과 개발 환경을 일치시키는 것이 제일 중요한데, 가상환경 개발 환경이 배포 환경과 맞지 않으면 말짱 도루묵이다.

그래서 초기에 개발에 들어가기에 앞서 어떤 개발 환경에서, 라이브러리 또는 언어 버전이 어떤 것을 사용할 것이며, 각 각의 의존성은 어떻게 연관되는지 미리 따져보고 개발 환경을 선택하는 과정을 거친다고 한다. 미리 개발부터 시작해버리면 의존성 문제와 배포 환경 등에 대한 고려를 배제하는 것이 되기 때문이다.

django를 사용하다보면 pip freeze > -r requirements.txt를 사용해서 현재 가상환경에 설치된 파이썬 모듈들을 모두 requirement.txt로 버전과 패키지명이 표시되는데 이 파일 하나로 의존성 부분을 개발자들이 이해하기 쉽게 표기하는 것이라 보면 된다.

그냥 라이브러리 간편하게 다운 받는 용도로만 사용하는 줄 알았는데, 사소한 폴더 하나에도 이렇게 개발자들의 깊은 고민과 의도가 반영되어 있다는 것을 새삼 다시 이해하는 순간이었다.

깨달음의 순간이랄까?

그럼 글 마지막에 각 가상환경별 차이점을 중심으로 서술하는 것으로 이번 글을 마무리 짓겠다.

virtualenv는 스택오버플로우와 django 관련 문서들을 읽어보면 가장 많이 추천하는 가상환경이다. 초심자들이 파이썬 가상환경을 접할 때 굉장히 사용을 추천하고 있으며, 장고걸스 및 많은 장고 관련 블로그들에서도 심심치 않게 virtualenv를 추천하는 경우를 볼 수 있다. (관련 reference도 풍부해 가상환경 관련 오류에 대한 문서 찾기도 쉽다.)

pyenv의 경우 파이썬 3.6부터는 중요도가 점점 떨어져서 파이썬 최신 배포 버전부터는 많이 사용되지 않고 있지만, 이 가상환경과 정확히 동일한 환경을 제공하는 것이 python -m venv <project name>이다. 하지만 파이썬 2.6, 2.7, 3.3, 3.4 그리고 3.5 버전에서 자유롭게 버전을 변경할 수 있는 것이 특징이고, 가상환경을 한 번 활성화 시키면, python, pip 등의 파이썬 명령어들을 특정 파일들과 매칭해주는 역할을 담당한다.

pipenv를 사용해서 개발 관련 문서나 블로그에 흔적을 보긴 힘들었는데 (한국 말고 외국 사이트들이 특히) pipenv shell을 입력해서 가상환경을 설치하면 Pipfile라는 파일이 설치된다. pip과 virtualenv 모두 사용할 수 있는 것이 특징. 다만 virtualenv와 구분되는 점은 virtualenv가 전형적으로 ~/.local/share/virtualenvs/XXX 형태로 가상환경 위치 지정을 한다면 XXX 위치가 프로젝트 파일 경로의 해시값으로 표기된다는 점이다. 다만pipenv는 Pipfile이 형성되는 위치가 현재 가상환경이 설치된 현재 working directory라는 점이다.

.env는 아직까지 사용하는 사람들을 직접적으로 목격하지는 못했다. 인턴 근무 시작하면서 시니어 개발자님도 요새 많이 사용한다고 하는데, 본인도 사용하는 사람을 직접 목격해본 적은 없다고. 언젠가 사용하는 글이 자주 목격된다면 한 번 비교 글을 편집할 필요가 있겠다.

venv 가 프로젝트 하면서 가장 걸림돌이 될 수 있는 부분은 파이썬 3에서 제작되면서 파이썬 2가 지원이 안된다는 것이다. 거기다 파이썬 버전 변경도 안되지만, 그 외의 것들은 virtualenv랑 똑같다.

가상 환경도 프로젝트 배포 목적에 맞게 써야 더 Fit이 좋은 소프트웨어가 만들어진다. 배우면서 항상 느끼지만프로그래밍도 정말 섬세한 것을 요구하는 분야다.

결론

초심자에게 추천하는 스택 오버플로우의 개발환경 : virtualenv

--

--

Ryan Kim
Ryan Kim

No responses yet