★ 9. [Ubuntu] 가상환경 구현: 외부 패키지
0. 학습 목표
이번 단계에서는 앞에서 생성한 `test_venv2` 가상환경에 `PySide6` 라이브러리를 설치하고, 설치된 라이브러리가 실제로 어느 경로에 저장되는지 확인합니다.
이 실습의 핵심은 단순히 `PySide6`를 설치하는 것이 아닙니다.
`python -m pip install PySide6` 명령을 실행했을 때, 라이브러리가 시스템 Python이 아니라 현재 활성화된 가상환경 내부에 설치되는지 확인하는 것입니다.
이전 학습과의 연결
4. [Ubuntu] Python 가상환경: 생성·활성화 실습
→ Ubuntu 기본 python3로 venv 만들기
8. [Ubuntu] Python 가상환경: 특정 버전 테스트
→ 특정 버전 python3.13으로 venv 만들기
9. [Ubuntu] Python 가상환경: 라이브러리 설치
→ python3.13으로 만든 가상환경에 PySide6 설치하기이전 단계에서는 가상환경을 만들고 활성화하는 방법을 확인했다면,
이번 단계에서는 그 가상환경 안에 실제 외부 라이브러리를 설치하여 프로젝트별 독립 환경이 어떻게 구성되는지 확인합니다.
프로젝트별 환경 분리 예시
| 구분 | 가상환경 | Python 버전 | 필요한 PySide6 버전 |
| A 프로젝트 | test_venv | Python 3.12 | PySide6 6.5 |
| B 프로젝트 | test_venv2 | Python 3.13 | PySide6 6.7 |
1. 특정 버전 Python 설치
2. 가상환경 만들기
1단계: 테스트 폴더를 생성합니다.
터미널을 실행하고, 아래 명령어를 입력합니다.
mkdir -p ~/Dev/Python2cd ~/Dev/Python2
(투나 파일 탐색기에서 해당 경로에 실제 폴더가 생성된 것을 확인합니다.)
2단계: python3.13로 가상환경 생성
현재 사용 중인 Python 버전을 기준으로 test_venv2 폴더 안에, 독립된 Python 실행 환경과 패키지 설치 공간을 만듭니다.
python3.13 -m venv test_venv2
python3.13 기준으로 가상환경을 생성합니다.
(참고) 문제가 있다면, 테스트 폴더 제거 후 처음부터 다시 시작합니다.
rm -rf ~/Dev/Python2/test_venv2
python3.13 -m venv ~/Dev/Python2/test_venv2
3. 가상환경 활성화하기
3단계: 가상환경 활성화
source test_venv2/bin/activate
가상환경을 활성화하면, 현재 터미널 세션에서는 전역 Python 대신 test_venv 내부의 python 과 pip 를 우선적으로 사용합니다.
이때 가상환경의 bin 디렉터리가 PATH 환경변수의 앞쪽에 추가되므로, 같은 python 명령을 입력해도 전역 Python이 아니라 가상환경 내부 Python이 실행됩니다.
프롬프트 앞에 (test_venv) 표시가 붙으면 정상적으로 활성화된 상태입니다.
4단계: 가상환경 빠져나오기
deactivatedeactivate 명령을 입력하면 가상환경이 비활성화되고, 현재 터미널 세션은 다시 전역 Python 기준으로 돌아갑니다.
💡 학습 포인트
Ubuntu에서는 기본 Python을 직접 건드리지 않고, 프로젝트마다 가상환경을 만들어 Python과 패키지를 따로 관리하는 습관이 중요합니다.
4. 특정 버전 Python vs 가상환경 Python
4.1 비교 방법
특정 버전 Python 디렉토리 확인 방법
가상환경을 활성화하지 않은 상태에서 확인합니다.
Ubuntu에서는 Windows의 where 대신 which 명령을 사용합니다.
/usr/bin/python3.13
가상환경 Python 디렉토리 확인 방법
프로젝트 활성화 후 확인합니다.
Ubuntu에서는 Windows의 where 대신 which 명령을 사용합니다.
which python
which pip
예시 결과:
/home/사용자명/Dev/Python2/test_venv2/bin/python
/home/사용자명/Dev/Python2/test_venv2/bin/pip
즉, 같은 python 명령처럼 보여도 실제로는 시스템(전역) Python이 아니라 프로젝트 가상환경의 Python을 사용하고 있다는 뜻입니다.
이때 가상환경의 bin 디렉터리가 PATH 환경변수의 앞쪽에 추가되므로, 같은 python 명령을 입력해도 전역 Python이 아니라 가상환경 내부 Python이 실행됩니다.
pip도 마찬가지입니다. `pip install`을 실행하면 전역 Python이 아니라 test_venv 가상환경 안에 패키지가 설치됩니다.
가상환경 활성화 전
→ /usr/bin/python3
가상환경 활성화 후
→ ~/Dev/Python2/test_venv2/bin/python
4.2 생성된 가상환경 폴더 비교
아래 명령어와 투나 파일 탐색기로 실제 디렉터리 구조를 확인해 봅니다.
| 구분 | Ubuntu 예시 |
| 특정 버전 Python 실행 파일 | /usr/bin/python3.13 |
| 특정 버전 pip 실행 파일 | python3.13 -m pip --version |
| 특정 버전 패키지 위치 | python3.13 -m pip show 패키지명 |
| 가상환경 Python 실행 파일 | 프로젝트경로/test_venv2/bin/python |
| 가상환경 pip 실행 파일 | 프로젝트경로/test_venv2/bin/pip |
| 가상환경 패키지 위치 | 프로젝트경로/test_venv2/lib/python3.x/site-packages |
보통 아래와 같은 요소를 볼 수 있습니다.
- test_venv2/bin : python, pip, activate 스크립트
- test_venv2/lib/python3.x/site-packages : 가상환경 전용 패키지 설치 위치
- test_venv2/pyvenv.cfg : 가상환경 설정 정보
전역 환경은 시스템 쪽 디렉터리에 있고,
가상환경은 프로젝트 내부 디렉터리로 생성된다는 점을 직접 비교할 수 있습니다.
5. 가상환경에 외부 패키지 설치하기
5단계: 외부 패키지 설치하기
이제 가상환경이 활성화된 상태에서 PySide6를 설치합니다.
python -m pip install PySide6
여기서 `pip install PySide6` 대신 `python -m pip install PySide6` 형식을 사용하는 것이 좋습니다.
이 방식은 현재 실행 중인 Python에 연결된 pip를 사용합니다.
따라서 현재 가상환경이 활성화되어 있다면, PySide6는 시스템 전체가 아니라 `test_venv2` 가상환경 안에 설치됩니다.
6단계: PySide6 설치 위치 확인하기
설치가 끝나면 PySide6가 어느 위치에 설치되었는지 확인합니다.
python -m pip show PySide6
예시 결과는 다음과 같습니다.
Name: PySide6
Version: 6.7.x
Location: /home/basiclike/Dev/Python2/test_venv2/lib/python3.13/site-packages
여기서 가장 중요한 부분은 Location입니다.
/home/basiclike/Dev/Python2/test_venv2/lib/python3.13/site-packages
이 경로는 시스템 Python 경로가 아니라 프로젝트 가상환경 내부 경로입니다. 즉, PySide6가 test_venv2 가상환경 안에 설치되었다는 뜻입니다.
Python이 실제로 PySide6를 어디에서 불러오는지도 확인할 수 있습니다.
python -c "import PySide6; print(PySide6.__file__)"
예시 결과입니다.
/home/basiclike/Dev/Python2/test_venv2/lib/python3.13/site-packages/PySide6/__init__.py6. 가상환경 Python 에 라이브러리를 설치하는 이유
6.1. 설치 경로 비교 정리
가상환경을 활성화한 상태에서 아래 명령어를 실행하면, 현재 어떤 Python과 pip를 사용하고 있는지 확인할 수 있습니다.
| 구분 | 확인 명령어 | 예시 결과 |
|---|---|---|
| 특정 버전 Python | which python3.13 |
/usr/bin/python3.13 |
| 가상환경 Python | which python |
~/Dev/Python2/test_venv2/bin/python |
| 가상환경 pip | which pip |
~/Dev/Python2/test_venv2/bin/pip |
| PySide6 설치 위치 | python -m pip show PySide6 |
~/Dev/Python2/test_venv2/lib/python3.13/site-packages |
| PySide6 실제 import 위치 | python -c "import PySide6; print(PySide6.__file__)" |
.../site-packages/PySide6/__init__.py |
여기서 중요한 점은 python과 pip가 모두 test_venv2 가상환경 내부 경로를 가리킨다는 것입니다.
즉, 가상환경이 활성화된 상태에서 아래 명령을 실행하면,
python -m pip install PySide6PySide6는 시스템 Python이나 특정 버전 Python의 공용 경로가 아니라, 현재 프로젝트의 가상환경 안에 설치됩니다.
~/Dev/Python2/test_venv2/lib/python3.13/site-packages
6.2. 왜 공용 Python 환경에 직접 설치하면 위험할까?
1. 프로젝트 간 충돌이 생길 수 있음
공용 Python 환경에 이미 `특정 버전의 Python`과 `특정 버전의 PySide6` 설치된 상태에
A 프로젝트는 PySide6 6.5가 필요하고, B 프로젝트는 PySide6 6.7이 필요하다고 가정합니다.
그런데 가상환경을 사용하지 않고 공용 Python 환경에 `PySide6 6.5` 하나만 설치하면, 모든 프로젝트가 같은 `PySide6 6.3` 버전을 사용하게 됩니다.
공용 Python → PySide6 6.5 설치
A 프로젝트 → 공용 PySide6 6.5 버전 사용 (✅ 정상)
B 프로젝트 → 공용 PySide6 6.5 버전 사용 (⚠️ 6.7 버전 필요)
C 프로젝트 → 공용 PySide6 6.5 버전 사용 (⚠️ 6.6 버전 필요)이 상태에서 B 프로젝트 때문에 PySide6 버전을 6.7 로 업그레이드하면, A 프로젝트가 갑자기 실행되지 않을 수 있습니다.
즉, 한 프로젝트의 변경이 다른 프로젝트에 영향을 주게 됩니다.
2. 특정 버전 Python도 같은 문제 발생
추가로 설치한 python3.13이 있다고 가정해 봅시다.
하지만 가상환경 없이 아래처럼 직접 라이브러리를 설치할수는 있습니다.
python3.13 -m pip install PySide6
하지막 위 공용 Python 환경 문제와 동일하게
python3.13을 사용하는 여러 프로젝트가 같은 라이브러리를 공유하게 됩니다.
Python 3.13 → PySide6 6.5 설치
A 프로젝트 → Python 3.13의 PySide6 6.5 버전 사용 (✅ 정상)
B 프로젝트 → Python 3.13의 PySide6 6.5 버전 사용 (⚠️ 6.7 버전 필요)
C 프로젝트 → Python 3.13의 PySide6 6.5 버전 사용 (⚠️ 6.6 버전 필요)따라서 python3.13이 기본 시스템 Python이 아니더라도, 프로젝트별 독립 관리 관점에서는 직접 설치를 권장하지 않습니다.
3. 삭제할 때도 복잡해질 수 있음
공용 Python 환경에 설치한 패키지를 삭제하려고 다음 명령을 실행할 수 있습니다.
sudo python3.13 -m pip uninstall PySide6하지만 시스템 경로에 여러 패키지가 섞이면, 어떤 패키지가 apt로 설치된 것인지, 어떤 패키지가 pip로 설치된 것인지 구분하기 어려워질 수 있습니다.
그래서 나중에 환경을 정리하거나 문제를 해결할 때 더 복잡해질 수 있습니다.