venv가 거짓말을 할 때: Ubuntu에서 유령 Python 3.4 디버깅

Source: Dev.to

배경

가상 환경은 프로젝트를 격리하도록 설계되었습니다.
venv가 조용히 오래된 파이썬 인터프리터를 사용하면 모든 것이 깨질 수 있습니다.

증상

python3 -m venv venv
source venv/bin/activate

• venv 안에 pip이 없음
• ensurepip이 SSL 오류로 실패
• get-pip.py가 실행을 거부
• pip freeze가 아무것도 보여주지 않음
• ssl 모듈을 import 하면 실패

핵심 단서:

python3 --version
# Python 3.4.10

하지만 Ubuntu에서는 다음과 같이 보고합니다:

sudo apt install python3
# python3 is already the newest version (3.12.3)

진단

PATH 우선순위

Linux는 $PATH를 사용해 실행 파일을 찾습니다. 일반적인 순서는 다음과 같습니다:

/usr/local/bin
/usr/bin

만약 오래된 파이썬을 수동으로 컴파일해서 다음 위치에 설치했다면:

/usr/local/bin/python3
/usr/local/lib/python3.4

시스템이 관리하는 /usr/bin/python3보다 먼저 찾아지게 됩니다.

다음 명령을 실행하면:

python3 -m venv venv

Python 3.4를 사용해 가상 환경이 생성됩니다(3.12가 아니라).
Python 3.4는 2019년에 EOL(지원 종료) 되었으며, 최신 SSL 지원이 없고 현재 pip을 실행할 수 없으며 오늘날의 도구와 호환되지 않습니다.

어떤 인터프리터가 사용되는지 확인해 보세요:

which python3
# /usr/local/bin/python3   ← 문제

올바른 시스템 인터프리터는 다음과 같아야 합니다:

which python3
# /usr/bin/python3

경로가 다르면 여러 버전이 설치된 것입니다.

SSL 지원 여부를 테스트해 보세요:

python3 -c "import ssl"
# ImportError: No module named '_ssl'

venv 안에서:

python --version
which python
which pip

버전이 3.4.x이면 잘못된 인터프리터로 venv가 만들어진 것입니다.

venv가 보호하지 못한 이유

venv는 단순히 그 인터프리터를 복제합니다:

pythonX -m venv venv

pythonX가 오래된 바이너리를 가리키면, 결과 환경도 같은 문제를 물려받습니다. “입력이 나쁘면 출력도 나쁘다.”

해결 방법

1. 구식 인터프리터 제거

   sudo rm /usr/local/bin/python3
   sudo rm /usr/local/bin/python
   sudo rm -rf /usr/local/lib/python3.4
   hash -r   # 명령 해시 캐시 정리

2. 시스템 파이썬 확인

   which python3
   # /usr/bin/python3
   python3 --version
   # Python 3.12.3

3. 올바른 인터프리터로 가상 환경 재생성

   /usr/bin/python3 -m venv venv
   source venv/bin/activate

4. 환경 확인

   python --version
   # Python 3.12.3
   which python
   # .../venv/bin/python
   which pip
   # .../venv/bin/pip

이제 ssl이 정상 작동하고, pip으로 패키지를 설치할 수 있으며, 환경이 재현 가능합니다.

교훈

문제가 미묘한 이유는 시스템이 SSL, pip, 혹은 의존성 오류가 발생하기 전까지는 정상적으로 보이기 때문입니다. Linux에서 파이썬 환경을 디버깅할 때는:

• pip, venv, Ubuntu를 비난하기 전에 항상 인터프리터 경로(which python3, python3 --version)를 확인하세요.
• 대부분의 환경 문제는 실제로 PATH 문제입니다.