여기서는 활성화 명령을 외우기보다 프로젝트마다 Python 실행 환경을 분리하는가, 그리고 지금 어느 인터프리터와 pip를 쓰는가를 먼저 봅니다.
가상환경의 핵심은 쉘 장식이 아니라, 프로젝트별 의존성과 실행 경로를 안정적으로 분리하는 데 있습니다.
빠른 흐름
python -m venv .venv
# Windows
.venv\Scripts\activate
# macOS / Linux
source .venv/bin/activate
python -m pip install requests pytest
python -m pip list기본 흐름
기본형은 가상환경 생성, 활성화, python -m pip 설치, 설치 목록 확인, 의존성 기록까지 같이 보면 됩니다.
python -m venv .venv
# Windows
.venv\Scripts\activate
# macOS / Linux
source .venv/bin/activate
python -m pip install requests
python -m pip list
python -m pip freeze > requirements.txt핵심은 명령 자체보다 "이 프로젝트 전용 Python과 pip를 쓰고 있는가"입니다.
가상환경 문제 대부분은 활성화 실패보다 인터프리터 불일치에서 시작합니다.
환경 분리
프로젝트마다 의존성을 분리할 때 가상환경을 만든다
Python 패키지를 전역으로 계속 설치하면 프로젝트끼리 버전 충돌이 나기 쉽습니다. 가상환경은 프로젝트 전용 Python 실행 환경을 만들어 이런 충돌을 막습니다.
python -m venv .venv즉 가상환경은 편의 기능이라기보다, 여러 프로젝트를 안정적으로 관리하기 위한 기본 분리 장치입니다.
설치 방식
설치와 조회는 python -m pip로 읽는 편이 안전하다
가상환경을 활성화한 뒤 pip install을 실행해도 되지만, 실전에서는 python -m pip가 더 분명합니다.
현재 Python 인터프리터와 같은 pip를 쓴다는 뜻이기 때문입니다.
python -m pip install requests
python -m pip show requests어느 pip가 실행되는지 헷갈리는 문제를 줄이려면 이 습관이 좋습니다.
인터프리터 확인
핵심은 활성화 자체보다 IDE와 터미널의 인터프리터 일치다
터미널 활성화 스크립트는 편의를 주지만, 더 중요한 건 터미널과 IDE가 같은 .venv를 보고 있는가입니다.
# Windows
.venv\Scripts\activate
# macOS / Linux
source .venv/bin/activate
python --version
python -m pip list즉 가상환경 문제는 쉘 명령보다 "지금 어느 Python을 쓰고 있나"를 확인하는 문제에 가깝습니다.
재현과 확장
의존성 기록은 환경을 다시 만들기 위한 것이다
혼자 작업하든 CI를 돌리든, 설치 패키지 목록을 파일로 남겨야 같은 환경을 다시 만들 수 있습니다.
python -m pip freeze > requirements.txt
python -m pip install -r requirements.txtpip freeze는 하위 의존성까지 모두 적기 때문에, 팀이나 프로젝트 성격에 따라 직접 requirements를 관리할지 같이 판단해야 합니다.
venv + pip는 출발점으로 아주 좋지만, 잠금 파일과 개발/운영 의존성 분리가 중요해지면 uv, poetry 같은 도구로 넘어갈 수도 있습니다.
여기서는 그 전 단계의 기본 환경 분리 감각을 먼저 다룹니다.
주의할 점
가상환경을 만들고도 IDE나 터미널이 전역 Python을 바라보면 설치/실행 결과가 엇갈립니다.
# ❌ 어느 pip가 실행되는지 불분명
pip install requests
# ✅ 현재 Python과 같은 pip를 사용
python -m pip install requests참고 링크
2 sources