0. 개요
- venv가 왜 필요한지(개념)
- 언제 venv를 쓰는 게 좋은지 (사용 시나리오)
- venv를 생성 / 활성화 / 비활성화 / 삭제하는 방법
- 여러 개 venv를 관리하는 패턴과 팁
1. venv란 무엇인가?
1.1. 한 줄 정의
venv는 “프로젝트별로 분리된, 독립적인 Python 실행 환경”이다.
조금 풀어서 말하면:
- OS 하나 위에 여러 개의 독립적인 Python + 라이브러리 설치 공간을 만들어주는 기능
- 각 공간은 서로 다른 패키지 버전을 가질 수 있고, 서로 영향을 거의 주지 않는다.
1.2. 왜 필요한가?
여러 프로젝트가 있을 때를 생각해보자.
- 프로젝트 A:
Django==2.x필요 - 프로젝트 B:
Django==4.x필요
만약 시스템 전체에 하나의 Python 환경만 있다면:
- A 때문에 Django 2.x를 설치 → B가 깨짐
- B 때문에 Django 4.x를 설치 → A가 깨짐
이런 문제를 막기 위해 **프로젝트마다 자기 전용 Python 환경(venv)**을 갖도록 하는 것.
1.3. 리눅스/서버 관점 비유
- OS 전체는 공용이지만,
/opt/app1/은 앱1 전용 실행파일/라이브러리,/opt/app2/는 앱2 전용 실행파일/라이브러리
이렇게 서비스별로 디렉터리를 분리해서 설치하듯이, Python도 venv를 통해 디렉터리별로 독립된 환경을 만든다고 보면 된다.
2. venv의 구조와 동작 원리
2.1. 기본 구조
예시로 다음 명령을 실행하면:
python3 -m venv /opt/myenv
/opt/myenv 안에는 대략 이런 구조가 생긴다.
/opt/myenv/
├─ bin/ # python, pip 등 실행 파일
├─ lib/ # 설치된 패키지들 (site-packages)
└─ pyvenv.cfg # venv 설정 파일
2.2. 활성화의 의미
source /opt/myenv/bin/activate
를 실행하면 쉘의 환경 변수가 바뀌어서:
python→/opt/myenv/bin/pythonpip→/opt/myenv/bin/pip
을 가리키게 된다.
이 상태에서 pip install XXX를 하면:
- 시스템 전체가 아니라 “** 안에만** 패키지가 설치된다.
2.3. 비활성화
deactivate
를 실행하면:
- PATH 등이 원래 상태로 돌아가고
- 다시
python을 치면 시스템 기본 python이 실행된다.
3. venv 기본 사용법 (명령어 정리)
3.1. 1) venv 생성하기
# 형식
python3 -m venv <venv_dir>
# 예시
python3 -m venv /opt/netbox-scripts/venv
<venv_dir>위치는 자유롭게 선택 가능- 예:
/opt/myenv,/home/alpha/venv/testenv,./venv등
- 예:
3.2. 2) venv 활성화하기
# bash / zsh 기준
source /opt/netbox-scripts/venv/bin/activate
# 프롬프트 예시
(venv) [root@host ~]#
- 보통 프롬프트 앞에
(venv)같은 표시가 붙어서 **“지금 venv 안이다”**를 눈으로 확인할 수 있다.
3.3. 3) venv 안에서 패키지 설치하기
(venv) pip install pynetbox
(venv) pip install requests
- 이때 설치되는 패키지는 전부 “ 안에만 깔림
- 시스템 전체 파이썬에는 영향 없음
3.4. 4) venv 비활성화 (빠져나오기)
(venv) deactivate
# 이후에는 venv가 아닌, 원래 환경으로 복귀
[root@host ~]#
3.5. 5) venv 삭제하기
venv는 그냥 디렉터리 하나이기 때문에, 필요 없으면 통째로 지우면 끝이다.
rm -rf /opt/netbox-scripts/venv
※ 지울 때는 정말 그 경로가 맞는지 항상 두 번 확인할 것.
4. 여러 개 venv를 사용하는 패턴
4.1. venv는 여러 개 만들어도 된다
venv는 프로젝트/용도별로 여러 개 만들어 쓰는 것이 정상적인 패턴이다.
예를 들어:
/opt/netbox/venv # NetBox 애플리케이션 전용 venv
/opt/netbox-scripts/venv # NetBox 관리/자동화 스크립트 전용 venv
/opt/ansible-scripts/venv # Ansible 기반 스크립트 전용 venv
/home/alpha/test-venv # 테스트용 venv
각 venv마다 설치된 패키지는 서로 독립적이다.
4.2. 한 번에 “활성화”하는 venv는 하나
여러 개 venv가 있어도, 현재 쉘에서 활성화해서 쓰는 venv는 한 번에 하나다.
# NetBox 스크립트용 venv 사용
source /opt/netbox-scripts/venv/bin/activate
(venv) python my_script.py
(venv) deactivate
# Ansible 스크립트용 venv 사용
source /opt/ansible-scripts/venv/bin/activate
(ansible) python another_script.py
(ansible) deactivate
4.3. 어떤 venv가 활성화되어 있는지 확인하는 법
- 프롬프트 확인
(venv)같은 표시가 있으면 해당 venv 활성화 상태
which python,which pip명령으로 경로 확인
(venv) which python
/opt/netbox-scripts/venv/bin/python
(venv) which pip
/opt/netbox-scripts/venv/bin/pip
5. venv를 쓸지 말지 판단하는 기준
5.1. venv를 쓰는 게 좋은 경우
- 하나의 서버에서 여러 Python 프로젝트를 함께 운영할 때
- 각 프로젝트가 서로 다른 버전의 라이브러리를 요구할 때
- 시스템 Python을 깨끗하게 유지하고 싶을 때
- 공공기관/보안 환경에서, 특정 서비스/스크립트의 영향 범위를 제한하고 싶을 때
5.2. 굳이 venv가 필요 없을 수도 있는 경우
- 아주 간단한 테스트 스크립트 하나만 잠깐 돌릴 때
- 서버 역할이 명확하고, Python 패키지가 소수이며,
전체를 하나의 환경으로 관리해도 상관 없을 때
그래도 운영/장기 관점에서는 웬만하면 venv를 쓰는 편이 안전하다.
6. 실무 예시: NetBox 관리 스크립트용 venv
예를 들어, NetBox에 자동으로 Site/Location/Rack을 만드는 스크립트를 돌리고 싶다면:
- venv 생성
python3 -m venv /opt/netbox-scripts/venv - venv 활성화
source /opt/netbox-scripts/venv/bin/activate - (폐쇄망이라면 오프라인 번들 경로를 사용해서) 필요한 패키지 설치
pip install --no-index --find-links=/opt/offline/pip/pkgs pynetbox - 스크립트 실행
python /opt/netbox-scripts/scripts/netbox_bootstrap_topology.py - 작업 후 venv 종료
deactivate
이렇게 하면:
- 시스템 전체 Python, NetBox 앱 venv에 영향 없이
- “** 안에서만** pynetbox 및 관련 패키지가 사용된다.
7. 요약
- venv = 독립된 Python 실행/패키지 환경을 만들어주는 기능이다.
- 프로젝트/용도별로 venv를 나누면 라이브러리 충돌과 운영 리스크를 줄일 수 있다.
- 기본 사용 패턴은:
python3 -m venv <dir>→ 생성source <dir>/bin/activate→ 활성화pip install ...→ venv 안에만 설치deactivate→ 원래 환경으로 돌아가기
- venv는 여러 개 만들어도 되며, 한 번에 한 venv만 활성화해서 사용한다.
- 운영 환경에서는 각 서비스/스크립트 별로 전용 venv 하나씩 두는 패턴이 가장 관리하기 좋다.
이 문서를 기본 참조용으로 두고, 실제 프로젝트(예: NetBox 자동화, Ansible 스크립트 등)에 맞게 venv 디렉터리 경로만 바꿔서 사용하면 된다.
