1 도구별 개요

1.1 pip

Python 기본 패키지 관리자. Python 설치 시 함께 제공된다.

pip install requests
pip install -r requirements.txt
pip freeze > requirements.txt

특징:

Python 표준 도구 (별도 설치 불필요)
requirements.txt로 의존성 목록 관리
의존성 해결(resolution) 기능이 제한적
가상환경은 venv를 별도로 사용해야 함

1.2 Conda

데이터 과학 중심의 패키지 및 환경 관리자. Python뿐 아니라 C/C++, R 등 비-Python 패키지도 관리한다.

conda create -n myenv python=3.11
conda activate myenv
conda install pandas numpy

특징:

Python 외 바이너리 패키지도 관리 (CUDA, MKL 등)
environment.yml로 환경 공유
Anaconda/Miniconda 별도 설치 필요
PyPI와 다른 자체 채널(conda-forge) 사용
패키지 용량이 크고, 의존성 해결이 느릴 수 있음

1.3 Pipenv

pip + virtualenv를 하나로 합친 도구. Pipfile과 Pipfile.lock으로 의존성을 관리한다.

pipenv install requests
pipenv shell
pipenv run python main.py

특징:

Pipfile + Pipfile.lock으로 결정적 빌드
가상환경 자동 관리
.env 파일 자동 로드
의존성 해결이 느릴 수 있음
패키지 빌드/배포 기능 없음

1.4 Poetry

의존성 관리 + 가상환경 + 빌드/배포를 통합한 도구.

poetry add requests
poetry install
poetry run python main.py
poetry build && poetry publish

특징:

pyproject.toml + poetry.lock으로 관리
의존성 해결이 빠르고 정확
빌드/배포까지 하나의 도구로 완결
PEP 표준(pyproject.toml) 기반
풍부한 CLI 명령어

1.5 setuptools

Python 전통 빌드/패키징 도구. setup.py, setup.cfg, pyproject.toml을 혼용하여 프로젝트를 구성한다.

python setup.py sdist bdist_wheel
twine upload dist/*

특징:

Python 패키징의 사실상 표준이었던 레거시 도구
setup.py / setup.cfg / pyproject.toml 세 파일이 혼재할 수 있음
의존성 관리는 requirements.txt로 별도 수행 (pip 의존)
Lock 파일 없음 (pip freeze로 수동 생성)
가상환경 관리 기능 없음 (venv, conda 별도 사용)
빌드/배포 시 twine 등 별도 도구가 필요

1.6 PDM

PEP 표준을 가장 충실히 따르는 차세대 도구. PEP 582 (__pypackages__) 지원.

pdm add requests
pdm install
pdm run python main.py
pdm build && pdm publish

특징:

PEP 621 ([project] 섹션) 기본 사용
가상환경 없이도 동작 가능 (PEP 582)
Poetry와 유사한 기능 세트
비교적 새로운 도구 (생태계 작음)

2 기능 비교표

기능	setuptools	pip	Conda	Pipenv	Poetry	PDM
설정 파일	setup.py/cfg 혼재	requirements.txt	environment.yml	Pipfile	pyproject.toml	pyproject.toml
의존성 설치	X (pip 의존)	O	O	O	O	O
Lock 파일	X	X	X	O	O	O
가상환경 관리	X	X (별도)	O	O	O	O
의존성 해결	X (pip 의존)	제한적	O	O (느림)	O (빠름, SAT solver)	O (빠름)
빌드/배포	O (+ twine)	X	X	X	O	O
pyproject.toml	부분 지원	X	X	X	O	O
의존성 그룹	X	X	X	dev만	O	O
비-Python 패키지	X	X	O	X	X	X
PEP 621 지원	X	-	-	-	2.x부터	O
설치 용이성	기본 내장	기본 내장	별도 설치	pip 설치	별도 설치	pip 설치

3 의존성 파일 비교

3.1 pip: requirements.txt

requests==2.31.0
pandas>=2.0,<3.0
numpy~=1.24

직접 의존성과 하위 의존성의 구분이 없음
pip freeze는 모든 패키지를 나열

3.2 Conda: environment.yml

name: myenv
channels:
  - conda-forge
  - defaults
dependencies:
  - python=3.11
  - pandas=2.0
  - pip:
    - requests==2.31.0

3.3 Pipenv: Pipfile

[[source]]
url = "https://pypi.org/simple"

[packages]
requests = "~=2.31"
pandas = ">=2.0"

[dev-packages]
pytest = "*"

[requires]
python_version = "3.11"

3.4 Poetry: pyproject.toml

[tool.poetry.dependencies]
python = "^3.11"
requests = "^2.31"
pandas = "^2.0"

[tool.poetry.group.dev.dependencies]
pytest = "^7.4"

4 상황별 도구 선택 가이드

4.1 pip을 선택해야 할 때

간단한 스크립트나 일회성 프로젝트
도구 설치 없이 빠르게 시작해야 할 때
레거시 프로젝트 유지보수
Docker에서 가볍게 패키지만 설치할 때

4.2 Conda를 선택해야 할 때

데이터 과학/머신러닝 프로젝트 (CUDA, cuDNN 등 필요)
C/Fortran 확장이 필요한 과학 패키지 (scipy, OpenCV 등)
비-Python 의존성이 많은 프로젝트
Jupyter Notebook 기반 분석 환경

4.3 Pipenv을 선택해야 할 때

이미 Pipenv을 사용 중인 프로젝트
패키지 배포가 필요 없는 애플리케이션 프로젝트
.env 파일 자동 로드가 필요할 때

4.4 Poetry를 선택해야 할 때

라이브러리/패키지를 만들어 배포해야 할 때
팀 프로젝트에서 재현 가능한 환경이 중요할 때
의존성 그룹 관리가 필요할 때 (dev, test, docs)
현대적인 Python 프로젝트 표준을 따르고 싶을 때
하나의 도구로 전체 워크플로를 관리하고 싶을 때

4.5 PDM을 선택해야 할 때

PEP 표준 준수가 최우선일 때
Poetry의 [tool.poetry] 방식 대신 표준 [project] 방식 선호
새 프로젝트에서 최신 도구를 사용하고 싶을 때

5 setuptools에서 Poetry로 전환

기존 setup.py / setup.cfg 기반 프로젝트를 Poetry로 전환하는 과정:

# 1. 프로젝트 디렉토리에서 Poetry 초기화
cd my_project
poetry init

# 2. setup.py/setup.cfg의 install_requires를 확인하여 의존성 추가
poetry add requests pandas numpy

# 3. 개발 의존성 추가 (setup.py의 extras_require['dev'] 등)
poetry add --group dev pytest black mypy

# 4. entry_points가 있다면 pyproject.toml의 [tool.poetry.scripts]로 이전
# setup.py:  entry_points={'console_scripts': ['mycli=mypackage.cli:main']}
# → pyproject.toml:
#   [tool.poetry.scripts]
#   mycli = "mypackage.cli:main"

# 5. 가상환경 생성 및 설치
poetry install

# 6. 기존 setup.py, setup.cfg, MANIFEST.in 삭제 (선택)

전환 시 장점:

단일 파일 관리: setup.py + requirements.txt + MANIFEST.in → pyproject.toml 하나로 통합
재현성: poetry.lock이 모든 하위 의존성 버전을 고정하므로 “내 PC에서는 되는데” 문제가 감소한다
의존성 충돌 사전 감지: SAT solver가 설치 전에 호환성을 검증한다
dev/prod 의존성 분리: [tool.poetry.group.dev.dependencies]로 깔끔하게 구분
버전 관리 통합: poetry version patch/minor/major로 버전 bump

전환하지 않아도 되는 경우:

이미 conda 환경에서 잘 돌아가고 있고, 패키지 배포(PyPI)할 일이 없는 경우
C extension이 많아서 setuptools의 ext_modules가 필요한 경우
팀 전체가 conda 기반 워크플로우에 익숙한 경우

6 pip에서 Poetry로 마이그레이션

기존 pip 기반 프로젝트를 Poetry로 전환하는 과정:

# 1. 프로젝트 디렉토리에서 Poetry 초기화
cd my_project
poetry init --no-interaction

# 2. requirements.txt에서 패키지 추가
# Linux/macOS
cat requirements.txt | grep -v '^#' | grep -v '^$' | xargs poetry add

# 3. 개발 의존성 추가
cat requirements-dev.txt | grep -v '^#' | grep -v '^$' | xargs poetry add --group dev

# 4. 가상환경 생성 및 설치
poetry install

# 5. 기존 requirements.txt 삭제 (선택)
# → 하지만 Docker 등에서 필요하면 poetry export로 생성 가능

힌트

마이그레이션 후에도 poetry export -f requirements.txt로 언제든 requirements.txt를 생성할 수 있으므로, 기존 도구와의 호환성 걱정은 없다.

7 Conda에서 Poetry로 전환 시 주의사항

Conda와 Poetry는 역할이 다르다. 완전한 대체가 아닌 부분 전환이 적절할 수 있다.

상황	권장
순수 Python 패키지만 사용	Poetry로 전환 가능
CUDA/cuDNN 필요	Conda로 시스템 라이브러리 관리 + Poetry로 Python 패키지 관리
과학 패키지 (numpy, scipy 등)	pip/Poetry로도 wheel 설치 가능 (대부분)
Jupyter Notebook 환경	Conda 유지 또는 Poetry + jupyterlab 설치

# Conda + Poetry 혼용 예시
conda create -n myenv python=3.11 cudatoolkit=11.8
conda activate myenv
poetry config virtualenvs.create false  # Conda 환경 사용
poetry install

8 요약

도구	핵심 강점	핵심 약점
setuptools	레거시 표준, 기본 내장	설정 파일 혼재, Lock 없음, 가상환경 없음
pip	기본 내장, 단순함	Lock 파일 없음, 의존성 해결 약함
Conda	비-Python 패키지 관리	무거움, PyPI와 별도 생태계
Pipenv	pip + venv 통합	느림, 빌드/배포 없음
Poetry	올인원 (의존성+빌드+배포)	별도 설치, 학습 곡선
PDM	PEP 표준 최우선	생태계 작음, 자료 부족

실무에서는 웹/API 서비스, 라이브러리 개발 → Poetry, 데이터 과학/ML → Conda (+ Poetry 혼용)이 가장 일반적인 조합이다.