파이썬 가상환경 완전정복: venv vs conda 헷갈림 끝내기 (생성·활성화·비활성화·상태확인)

이 글 한 줄 요약

파이썬 가상환경이 헷갈리는 진짜 이유는 venv와 conda라는 서로 다른 도구가 동시에 켜지기 때문이다. 켜고·끄고·상태 확인하는 명령어만 정확히 구분하면 혼란의 90%는 사라진다.

최근에 터미널에서 작은 프로젝트 하나를 새로 세팅하다가, 평소 무심코 쓰던 가상환경에서 제대로 막혔다. python --version이 분명히 3.13.5라고 찍혔는데, 그걸 그대로 명령어에 넣어서 python3.13.5 -m venv .venv라고 쳤더니 command not found. 게다가 프롬프트 한쪽엔 base가 떠 있어서, 이게 conda 환경인지 venv인지도 순간 헷갈렸다.

아마 파이썬을 쓰는 사람이라면 한 번쯤 똑같이 막혀봤을 거다. 가상환경 개념 자체는 어렵지 않은데, 도구가 여러 개고 그게 겹쳐서 켜지면 "지금 내가 어디 있는 거지?"라는 상태 미아가 된다. 이번 글에서는 그 혼란을 끝내는 데 필요한 것만 추려서 정리한다. 개념 → 명령어 → 상태 확인 → 자주 하는 실수 순서다.

1. 가상환경은 왜 필요한가

가상환경을 한마디로 정의하면 프로젝트별로 격리된 파이썬 패키지 상자다. 프로젝트마다 필요한 라이브러리와 그 버전이 다른데, 시스템에 깔린 파이썬 하나에 전부 설치하면 버전이 충돌한다. A 프로젝트는 Django 4를 쓰고 B 프로젝트는 Django 5를 쓴다면, 둘을 같은 공간에 둘 수 없다.

그래서 프로젝트마다 독립된 공간을 만들어 그 안에만 패키지를 설치하는 것이다. 자바를 다뤄본 사람이라면 Maven이나 Gradle이 프로젝트별로 의존성을 알아서 격리해주던 걸 떠올리면 된다. 차이가 있다면 파이썬은 그 격리 공간을 직접 만들고, 직접 켜고, 직접 꺼야 한다는 점이다. 이 "수동" 특성이 초보자가 헷갈리는 1차 원인이다.

💡 가상환경을 안 쓰면 생기는 일

전역에 패키지를 막 깔다 보면 어느 순간 버전이 꼬여서, 멀쩡하던 프로젝트가 갑자기 import 에러를 뱉는다. 더 심하면 시스템 파이썬을 건드려서 OS 도구까지 망가진다. 가상환경은 이 모든 사고를 프로젝트 폴더 안으로 가둬주는 안전벨트다.

2. 헷갈림의 진짜 원인: 도구가 두 종류다

가상환경이 헷갈리는 가장 큰 이유는, 같은 목적의 도구가 출신이 다른 채로 두 개 존재하고 그게 동시에 켜질 수 있기 때문이다. 내가 막혔던 상황도 정확히 이거였다. 프롬프트에 뜬 base는 conda 환경이고, 내가 새로 만든 .venv는 venv였다. conda 위에 venv를 또 얹으니 환경이 두 겹이 된 것이다.

구분	venv	conda
출신	파이썬 표준 내장 모듈	Anaconda / Miniconda 배포판
생성	python -m venv .venv	conda create -n 이름
켜기	source .venv/bin/activate	conda activate 이름
끄기	deactivate	conda deactivate
환경 위치	프로젝트 폴더 안 .venv/	conda가 중앙에서 따로 관리
패키지 관리	pip	conda + pip 혼용 가능
주 용도	일반 웹·백엔드·스크립트	데이터 사이언스·머신러닝

base는 conda를 설치하면 자동으로 항상 켜지는 기본 환경이다. 그래서 터미널을 열 때마다 줄 앞에 (base)가 따라다녔던 것이고, 그 상태에서 venv를 또 켜니까 환경 스택이 2층으로 쌓인 셈이다. 이게 "지금 내가 어느 환경에 있는지" 감을 잃게 만드는 핵심 범인이다.

정리하면 — conda와 venv는 둘 다 가상환경 도구지만 켜고 끄는 명령어가 다르고, 서로 겹칠 수 있다. 한쪽으로 통일하는 게 정신 건강에 이롭다.

3. venv 실전: 생성 · 활성화 · 비활성화

일반적인 파이썬 프로젝트라면 표준 내장 도구인 venv 하나만 쓰는 게 가장 단순하고 깔끔하다. 외부 설치도 필요 없다. 실무에서 외울 흐름은 딱 네 줄이다.

# 1. 프로젝트 폴더에서 가상환경 생성 (최초 1회만)
python -m venv .venv

# 2. 활성화 (작업 시작할 때마다)
source .venv/bin/activate        # macOS / Linux
# .venv\Scripts\activate         # Windows (PowerShell)

# 3. 패키지 설치 (활성화된 상태에서)
pip install requests

# 4. 비활성화 (작업 끝나면)
deactivate

생성할 때 주의할 점

가상환경 폴더 이름은 관례적으로 .venv 또는 venv를 쓴다. 점(.)을 붙이면 숨김 폴더가 되어 파일 목록이 깔끔해지고, 대부분의 IDE가 .venv를 자동으로 인식해 인터프리터로 잡아준다. 그래서 개인적으로는 .venv를 추천한다.

활성화가 됐는지 확인하는 법

활성화에 성공하면 프롬프트 맨 앞에 (.venv)가 붙는다. 이게 가장 빠른 시각적 신호다. 만약 프롬프트에 아무 표시가 없다면 활성화가 안 된 것이니, source 경로를 다시 확인하자.

4. 비활성화 — 두 겹이면 두 번 꺼야 한다

여기서 많이들 막힌다. venv와 conda는 끄는 명령어가 다르기 때문이다. 그리고 내가 겪은 것처럼 conda base 위에 venv를 얹은 상태라면, 한 번 꺼서는 base로 돌아갈 뿐이다.

# venv만 끄기 → conda base로 복귀
deactivate

# base까지 완전히 빠져나오기
deactivate          # 먼저 venv 끄고
conda deactivate    # 그 다음 base 끄기

💡 헷갈리지 않는 규칙

프롬프트 맨 앞을 보면 된다. (.venv)가 보이면 deactivate, (base)가 보이면 conda deactivate. 둘 다 보이면 venv부터 끄고 conda를 끈다. 끄는 순서는 켠 순서의 역순이라고 기억하면 쉽다.

5. 지금 상태 확인하는 3가지 방법

"내가 지금 어느 환경에 있지?"가 헷갈릴 때, 다음 세 명령으로 확실하게 확인한다.

which python              # 지금 실행되는 python의 실제 경로
echo $VIRTUAL_ENV         # venv 활성화 시 경로 출력, 아니면 빈 값
echo $CONDA_DEFAULT_ENV   # 활성 conda 환경 이름 (base 등), 아니면 빈 값

가장 신뢰할 수 있는 건 which python이다. 출력 경로가 .../프로젝트/.venv/bin/python이면 venv 안에 제대로 들어와 있는 것이고, .../anaconda3/bin/python이면 conda를 쓰고 있는 것이다. 시스템 경로(/usr/bin/python)가 나오면 아무 가상환경도 안 켜진 맨바닥 상태다.

확인 명령	의미
which python	실제로 어떤 파이썬이 실행되는지 (가장 확실)
echo $VIRTUAL_ENV	값이 있으면 venv 활성, 비어 있으면 비활성
echo $CONDA_DEFAULT_ENV	conda 환경 이름. base면 기본 환경
프롬프트 앞 표시	(.venv) / (base) 시각 확인

6. 자주 하는 실수와 해결

실수 1: 버전 번호를 명령어로 착각

이번에 내가 한 실수가 정확히 이거다. python --version이 3.13.5를 출력하니까 그걸 그대로 python3.13.5 -m venv .venv라고 쳤다. 결과는 command not found.

명령어 이름에 들어가는 버전은 메이저.마이너까지만이다. 즉 python3, python3.13은 존재해도 패치 버전까지 붙은 python3.13.5는 명령어로 존재하지 않는다. 다음 중 하나를 쓰면 된다.

python -m venv .venv      # --version으로 이미 3.13.5 확인됐다면 가장 확실
python3 -m venv .venv
python3.13 -m venv .venv

실수 2: base가 자꾸 켜져서 거슬림

conda를 설치한 뒤로 터미널만 열면 (base)가 따라붙어 venv와 섞이는 게 싫다면, base 자동 활성화를 꺼버리면 된다.

conda config --set auto_activate_base false

이 한 줄이면 새 터미널을 열어도 base가 뜨지 않는다. conda 환경이 필요할 때만 직접 conda activate로 켜고, 평소엔 venv만 깔끔하게 쓸 수 있다. conda와 venv를 섞어 쓸 때 가장 효과 좋은 설정이다.

실수 3: 가상환경을 깃에 올림

.venv 폴더는 용량도 크고 OS·파이썬 버전에 종속적이라 절대 깃 저장소에 올리면 안 된다. 대신 .gitignore에 추가하고, 의존성은 목록 파일로만 관리한다.

# .gitignore에 추가
.venv/

# 현재 설치된 패키지를 목록으로 저장
pip freeze > requirements.txt

# 다른 환경에서 그대로 복원
pip install -r requirements.txt

7. 한 걸음 더: 요즘은 uv도 많이 쓴다

최근 파이썬 생태계에서는 Rust로 만든 uv라는 도구가 빠르게 자리 잡고 있다. 가상환경 생성과 패키지 설치를 훨씬 빠른 속도로 처리하고, 명령어도 직관적이다.

# uv로 가상환경 생성
uv venv

# 패키지 설치 (pip보다 훨씬 빠름)
uv pip install requests

다만 처음 가상환경 개념을 익히는 단계라면, 표준 내장 도구인 venv로 흐름을 확실히 잡은 뒤에 uv로 넘어가는 걸 권한다. 개념이 같아서 venv를 이해하면 uv는 금방 적응된다.

정리

① 가상환경 = 프로젝트별 격리 상자. ② 헷갈림의 원인은 venv와 conda가 겹쳐 켜지는 것. ③ python -m venv .venv → source .venv/bin/activate → deactivate 이 흐름만 외우면 된다. ④ 상태가 헷갈리면 which python으로 확인. ⑤ 섞여서 짜증나면 conda config --set auto_activate_base false로 base 자동 활성화를 끄자. 이 다섯 가지면 가상환경 미아가 될 일은 없다.

본 글은 실제 개발 환경 설정 경험을 바탕으로 작성했습니다. 명령어는 macOS / Linux(zsh·bash) 기준이며, Windows의 경우 활성화 경로가 .venv\Scripts\activate로 다릅니다. 사용하는 셸과 파이썬 버전에 따라 동작이 다를 수 있으니 본인 환경에서 확인 후 적용하시기 바랍니다.