Python 의존성 도구의 역사

Python 의 패키징 · 의존성 관리는 오랜 시간에 걸쳐 여러 도구가 등장했다 사라졌다. 이 글은 시간 순으로 각 도구가 해결한 문제와 한계를 사실 기준으로 정리합니다.

1. 연표

연도	사건
1991	Python 0.9.0 (Guido van Rossum, 1991 년 2월).
2000	distutils 가 Python 1.6 에 표준 라이브러리로 포함. 빌드 / 배포의 첫 표준.
2003	PyPI (Python Package Index) 운영 시작. 이전 명칭 "Cheese Shop".
2004	setuptools 등장. distutils 의 한계 (의존성 선언 · 확장성) 를 보완. easy_install 동봉.
2007	virtualenv (Ian Bicking) 첫 릴리스. 격리된 Python 환경.
2008	pip (Ian Bicking 등). easy_install 의 문제 (언인스톨 어려움 등) 를 풀려는 시도.
2011	The Twelve-Factor App 공개. config 와 의존성 분리 원칙이 굳어짐.
2012	pyenv (yyuu). Python 인터프리터 버전 매니저.
2012	pip 가 Python 3.4 부터 표준 동봉 (2014 정식). PEP 453.
2012	Python 3.3 의 venv 모듈 도입. virtualenv 의 일부를 표준 라이브러리에 흡수.
2012	pip-tools (Vincent Driessen 등). pip-compile 로 락파일 (requirements.txt 고정 버전) 생성.
2016	PEP 518 — pyproject.toml 도입. 빌드 시스템 선언 표준.
2017	pipenv (Kenneth Reitz). Pipfile / Pipfile.lock 으로 npm 식 워크플로 시도.
2018	Poetry (Sébastien Eustace) 1.0-pre. pyproject.toml 기반 의존성 · 빌드 · 퍼블리시 통합.
2019	PEP 517 — 빌드 백엔드 분리 표준. setuptools 외 빌드 도구가 가능.
2020	PEP 621 — [project] 섹션 표준. 메타데이터를 pyproject.toml 에서 선언.
2021	PDM (Frost Ming). PEP 582 실험 포함. 표준 충실.
2022	Hatch (PyPA 가 추천하는 빌드 백엔드 hatchling 의 매니저) 재작성판 안정화.
2024	uv (Astral). Rust. pip / pip-tools / virtualenv / poetry 워크플로의 다수를 한 도구로 묶음.

2. virtualenv (2007)

같은 머신에서 프로젝트 A 와 B 가 다른 버전의 라이브러리를 요구할 때, 시스템 site-packages 를 공유하면 충돌. virtualenv 는 프로젝트별로 별도 lib/python*/site-packages 를 둔 격리 환경을 만듦. Python 3.3+ 의 python -m venv 는 같은 아이디어의 표준 라이브러리 버전.

3. pip (2008)

easy_install 은 언인스톨이 까다롭고 의존성 해소가 약했음. pip 은 requirements.txt 와 명령형 설치 / 제거를 표준화.

4. pip-tools (2012)

requirements.txt 만으로는 추이 의존성 (transitive) 이 핀되지 않음. 어제 빌드와 오늘 빌드가 달라지는 사고가 흔함. pip-compile 은 추상 의존성 (requirements.in) 에서 모든 추이 버전이 박힌 락파일을 생성.

5. pyenv (2012)

시스템 Python 과 프로젝트 Python 을 분리. .python-version 으로 디렉터리별 버전 자동 전환. macOS 기본 Python 의 한계 (예전에는 2.7) 를 비키는 표준 처방.

6. pipenv (2017)

"npm 처럼" Pipfile / Pipfile.lock 워크플로 도입. 한 시기 활발했으나 의존성 해소 속도와 거버넌스 이슈로 채택이 갈림.

7. Poetry (2018)

pyproject.toml 한 파일에 의존성 · 메타데이터 · 빌드 백엔드 (poetry-core) 를 통합. poetry.lock 의 안정성과 명령 일관성으로 가장 널리 채택된 통합 도구. PEP 621 표준화 이전에 자체 [tool.poetry] 섹션을 사용한 점이 후일 표준 호환 작업의 부담.

8. PDM · Hatch (2021 ~ 2022)

PDM — PEP 표준 충실. 한때 PEP 582 (__pypackages__) 의 격리를 옹호했으나 PEP 자체가 거부되며 일반 가상환경 모드 위주로 정착.

Hatch — PyPA 가 추천하는 빌드 백엔드 hatchling 을 갖춘 매니저. 환경 매트릭스 (여러 Python 버전에 대한 테스트 환경) 운영이 강점.

9. uv (2024)

Rust 로 작성. pip / pip-tools / virtualenv 호환 모드를 갖춰 기존 워크플로의 드롭인 대체가 가능하고, 동시에 uv add / uv sync / uv run 으로 Poetry 류의 프로젝트 워크플로 제공. Python 인터프리터 자체도 uv python install 로 받음. 속도와 한 도구로의 통합을 강조 (03-python-uv).

10. conda

위 흐름과 별개로 Anaconda / Conda (Continuum Analytics → Anaconda Inc., 2012) 는 Python 외에 C / C++ 라이브러리 · 컴파일러까지 묶어 관리하는 다언어 패키지 매니저. 과학 계산 · 머신러닝 진영에서 표준격. NumPy / SciPy 등 네이티브 의존이 많은 환경에서 pip 로는 빌드가 어려울 때 conda 가 해법.

Mambaforge / Miniforge 는 conda 호환의 빠른 구현으로, 같은 채널 정책을 유지하면서 해소 속도를 개선.

11. 도구별 동일 작업

# venv + pip
python -m venv .venv
# Windows
.venv\Scripts\activate
# macOS · Linux
source .venv/bin/activate
pip install -r requirements.txt

# pip-tools
pip-compile requirements.in
pip-sync

# Poetry
poetry add fastapi
poetry install
poetry run python -m pytest

# uv
uv add fastapi
uv sync
uv run pytest

12. 자주 걸리는 자리

흔적 혼재 — 같은 프로젝트에 두 도구의 흔적이 섞여 있는 경우 (requirements.txt + pyproject.toml + poetry.lock + uv.lock). 어느 파일이 SSOT 인지 README 에 명시.

[project] vs [tool.poetry] 동거 — Poetry 1.x 까지의 자체 섹션과 PEP 621 표준 섹션은 의도 · 해석이 다름. Poetry 2.0 이후로 PEP 621 호환이 강화됐지만 마이그레이션은 의도적으로 한 번에 정리.

시스템 Python 에 글로벌 설치 — macOS 의 Apple Python, Linux 의 OS Python 을 건드리면 시스템 도구가 깨질 수 있음. pipx 또는 사용자 venv.

conda + venv 동시 활성화 — PATH 가 꼬여 어느 Python 이 잡히는지 헷갈림. 한쪽만 활성화.

락파일 머지 충돌 — 텍스트 머지보다 한쪽을 채택한 뒤 도구의 재해소 명령 (poetry lock · uv lock) 을 다시 돌리는 편이 안전.

하고픈 말

Python 의 의존성 도구는 17 년 동안 distutils → pip → virtualenv → pip-tools → pipenv → Poetry → uv 의 흐름. 각 도구는 앞 단계의 한계 위에 서 있습니다. 현 시점에는 uv 가 통합도가 가장 높지만, Poetry · pip-tools 가 잘 돌고 있다면 갈아탈 강한 동기는 없는 자리. 한 프로젝트 안에 도구 두 종류의 흔적이 섞이지 않게.

Next

• regex
• git-submodule-lfs

Python Packaging User Guide (PyPA) · PEP 518 · PEP 621 · pip 공식 문서 · Poetry 공식 문서 · uv 공식 문서 · Anaconda 공식 사이트 · pipx · Python Packaging History (PyPA discuss) 를 참고합니다.