서론

어제 오후 5시, 긴급 핫픽스 배포를 앞두고 로컬 환경에서 배포 스크립트를 테스트하던 상황을 상상해 보십시오. 테스트가 실패했습니다. 패키지 버전 호환성 문제입니다. 그런데 막상 확인해 보니, 활성화된 가상환경이 3달 전 진행하던 레거시 프로젝트의 것이었습니다. 결국 cd 명령어로 디렉토리를 이동하고, 복잡한 상대 경로를 타이핑해 source 명령어로 가상환경을 활성화하는 과정에서 오타가 발생했고, 소중한 시간이 낭비되었습니다.

여러 Python 프로젝트를 오가며 작업하는 개발자라면 이런 경험이 한 번쯤은 있을 것입니다. 도커(Docker)와 쿠버네티스(Kubernetes) 환경이 구축된 서버 사이드라면 몰라도, 로컬 개발 환경이나 데이터 사이언스 작업, 혹은 간단한 유틸리티 스크립트 관리에서는 여전히 venv가 필수적입니다. 하지만 프로젝트가 늘어날수록 .venv, env, venv 등 제각각인 이름으로 생성된 가상환경 경로를 기억하는 것은 인지부하를 유발합니다. 특히 CI/CD 파이프라인 구축 시 로컬에서의 테스트 환경 일관성을 보장하는 것은 SRE의 중요한 과제입니다.

이러한 혼란을 해결하기 위해 등장한 pvm은 Go로 작성된 경량의 CLI 도구입니다. 단순히 가상환경을 생성하는 것을 넘어, 별칭(Alias)을 부여하고 TUI(Text User Interface)를 통해 직관적으로 환경을 전환할 수 있게 하여, 개발자가 코드 작성에만 집중할 수 있는 환경을 제공합니다.

본론

기술적 구조와 작동 원리

기존의 virtualenvwrapper나 conda는 주로 Python 자체나 Shell Script로 작성되어 있어, 추가적인 Python 환경 설치가 필요하거나 실행 속도가 느릴 수 있습니다. 반면, pvm은 Go(Golang)로 작성된 단일 바이너리입니다. 이는 의존성 없이 시스템에 즉시 배포할 수 있음을 의미하며, 다양한 운영체제(Linux, macOS, Windows)에서 동일한 성능을 보장합니다.

pvm의 핵심 동작 원리는 **“경로의 추상화”**입니다. 사용자는 물리적으로 복잡한 가상환경의 경로(~/projects/A/.venv/bin/activate) 대신, 직관적인 별칭(project-a)을 등록합니다. pvm은 이 별칭과 실제 경로를 매핑하는 설정 파일(YAML)을 관리하며, Shell과 통합(Hook)하여 명령어 한 줄로 환경을 전환합니다.

다음은 pvm을 통해 가상환경을 활성화하고 관리하는 전체 흐름을 간단화한 다이어그램입니다.

1
2
3
4
5
6
7
8
9

graph LR
    A[User Command] --> B[pvm CLI]
    B --> C[Config File YAML]
    C --> D[Alias Lookup]
    D --> E{Action Type?}
    E -- List/TUI --> F[Display Menu]
    E -- Use Alias --> G[Activate Script]
    G --> H[Shell Integration source activate]
    F --> H

이 구조를 통해 사용자는 실제 파일 시스템의 복잡성을 알 필요 없이, pvm이 제공하는 인터페이스만으로 환경을 제어할 수 있습니다.

기존 도구와의 비교

DevOps 관점에서 도구를 선택할 때는 확장성, 유지보수성, 그리고 학습 곡선이 중요합니다. pvm과 기존에 널리 쓰이는 가상환경 관리 방식을 비교해 보겠습니다.

| 비교 항목 | 기본 venv (Shell 기능) | virtualenvwrapper (Python) | pvm (Go CLI) | | :— | :— | :— | :— | | 설치 방식 | Python 내장 | pip install 필요 | 단일 바이너리 다운로드 | | 의존성 | Python | Python, setuptools | 없음 (Go Binary) | | 별칭 관리 | 직접 스크립트 작성 필요 | mkvirtualenv 이름 사용 | 유연한 YAML 설정 및 TUI | | 성능 | 빠름 | 상대적으로 느림 (Python 부팅) | 매우 빠름 (Compiled Go) | | 이동성 | 높음 (경로만 앎) | 중간 (시스템 Python 의존) | 높음 (단일 파일 배포) | | 사용자 경험 | CLI (경로 기억 필요) | CLI (명령어 기반) | CLI + TUI (시각적 선택) |

pvm은 특히 **“단일 바이너리”**라는 점에서 강력한 이점을 가집니다. 서버 관리자가 여러 개발자의 작업 환경을 셋업하거나, Docker 이미지 내부에 환경 관리자를 설치해야 할 때, 별도의 Python 패키지 인덱스 설정이나 의존성 문제 없이 바이너리 하나만 복사하면 되므로 운영 효율성이 크게 향상됩니다.

실무 적용 가이드: Step-by-Step

이제 pvm을 실제 프로젝트에 적용하여 효율성을 높이는 구체적인 방법을 살펴보겠습니다.

Step 1: 설치 및 초기화

Go로 작성된 도구답게 설치는 매우 간단합니다.

1
2
3
4
5
6

# GitHub Releases에서 바이너리 다운로드 (Linux/macOS 예시)
curl -sL https://github.com/skovsgaard/pvm/releases/download/v0.x.x/pvm_0.x.x_linux_amd64.tar.gz | tar xz
sudo mv pvm /usr/local/bin/

# 또는 Go가 설치되어 있다면
go install github.com/skovsgaard/pvm@latest

설치 후, Shell의 프롬프트에 pvm을 통합해야 합니다. 사용 중인 셸(zsh, bash, fish)에 따라 다음 줄을 .zshrc 또는 .bashrc에 추가합니다.

1
2

# ~/.zshrc 또는 ~/.bashrc 추가
eval "$(pvm init)"

변경 사항을 적용하기 위해 터미널을 재시작하거나 source ~/.zshrc를 실행합니다.

Step 2: 가상환경 등록 및 별칭 부여

이미 존재하는 가상환경을 pvm에 등록해 보겠습니다. 물리적인 경로를 직접 입력하는 것은 이번이 마지막입니다.

1
2
3
4
5
6
7
8

# 가상환경 생성 (없는 경우)
python -m venv ~/projects/payment-service/.venv

# pvm에 별칭으로 등록
pvm add payment ~/projects/payment-service/.venv

# 다른 프로젝트 등록
pvm add user-auth ~/projects/auth-service/.env

이제 설정 파일인 ~/.pvm.yaml이 생성되고, 다음과 같이 경로가 매핑되어 저장됩니다.

1
2
3
4

# ~/.pvm.yaml 예시
environments:
  payment: /home/user/projects/payment-service/.venv
  user-auth: /home/user/projects/auth-service/.env

Step 3: TUI를 이용한 환경 전환

pvm의 진짜 매력은 복잡한 명령어 없이 환경을 전환하는 TUI 환경입니다.

1

pvm use

위 명령어를 입력하면 터미널에 등록된 가상환경 목록이 인터랙티브하게 나타납니다. 키보드 방향키(또는 vi 키 바인딩)로 이동하여 Enter를 누르면 즉시 해당 가상환경으로 전환됩니다. 이는 vscode의 명령 팔레트나 fzf의 퍼지 검색과 유사한 사용성을 제공하여, 수십 개의 프로젝트를 전환하는 상황에서도 생산성을 유지하게 해줍니다.

명령줄 인자를 사용해 직접 별칭으로 전환하는 것도 가능합니다.

1
2

pvm use payment
# Executing: source /home/user/projects/payment-service/.venv/bin/activate

Step 4: 운영 환경에서의 활용 (Automation)

단순히 개발 편의성을 넘어, 배포 스크립트 내에서 특정 Python 버전이나 의존성이 격리된 환경을 실행해야 할 때 유용합니다. 예를 들어, 젠킨스(Jenkins)나 GitLab CI의 스크립트 단계에서 로컬 테스트를 수행할 때 pvm을 활용할 수 있습니다.

1
2
3
4
5

# .gitlab-ci.yml 예시
script:
  - pvm use payment
  - python -m pytest tests/
  - python manage.py migrate --noinput

이러한 접근 방식은 CI 서버 전체에 특정 Python 패키지를 설치하여 환경을 오염시키는 것을 방지하고, 프로젝트별로 격리된 환경을 순차적으로 활용할 수 있게 합니다.

트러블슈팅 및 고려사항

pvm을 도입할 때 발생할 수 있는 문제점과 해결책을 정리합니다.

1. Shell Hook 문제: eval "$(pvm init)"이 실행되지 않으면 pvm use 명령어가 현재 셸 환경을 변경하지 못합니다. 터미널이 열리자마자 pvm use가 작동하지 않는다면 셸 설정 파일을 확인하십시오. 2. 경로 이동: 프로젝트 폴더 자체를 이동한 경우, pvm update 명령어나 직접 ~/.pvm.yaml을 수정하여 경로를 갱신해야 합니다. 3. **버전

출처: https://news.hada.io/topic?id=28714