neozest : neo+zest

파이썬에는 다양한 패키지 관리 도구가 존재합니다. pip, venv, virtualenv, pipenv, poetry 등 각 도구들은 가상환경 생성, 패키지 설치, 의존성 관리 등의 역할을 분담합니다. 최근 이 모든 기능을 하나로 통합하면서도 빠른 속도를 자랑하는 새로운 도구가 등장했습니다. 바로 uv입니다.

uv

uv는 Astral에서 개발한 초고속 파이썬 패키지 관리 도구입니다. 러스트(Rust)로 개발되었기 때문에 네이티브 툴의 매우 빠른 속도와 러스트 메모리 모델이 제공하는 높은 안정성이 제공합니다. Astral은 uv뿐만 아니라 파이썬 코드 린터인 Ruff도 러스트로 개발하고 있습니다. uv는 여러 파이썬 도구들이 제공하던 다양한 기능을 하나로 통합한 스위스 군대 칼같은 멀티툴로, 단일 명령어를 사용하여 가상환경을 만들고 패키지를 설치하며, 프로젝트의 의존성을 관리할 수 있습니다.

특징

• 매우 빠른 속도: 러스트로 구현되었기 때문에 기존 도구보다 월등히 빠릅니다. pip보다 10배~100배 빠르다고 홍보하고 있죠.
• 올인원 도구: pip, venv, virtualenv, pip-tools, poetry의 기능을 모두 갖추고 있습니다.
• 자동 가상환경 생성: 패키지를 설치할 때 가상환경이 없으면 자동으로 생성합니다.
• PEP 582 지원: .venv 없이도 프로젝트 로컬 디렉터리에 패키지를 설치할 수 있습니다.
• Python과의 높은 호환성: 표준 파이썬 워크플로와 충돌 없이 동작할 수 있습니다.

무엇을 대체할 수 있을까?

uv는 아래 도구들을 모두 대체할 수 있습니다:

• pip (패키지 설치/제거)
• venv, virtualenv (가상환경 생성)
• pip-tools, pipenv, poetry (의존성 관리 및 고정)

따라서 여러 도구를 설치하여 설정하지 않아도, uv 하나만으로 파이썬 프로젝트를 효율적으로 관리할 수 있습니다.

설치

uv는 다음 명령어만 실행하면 간편하게 설치됩니다.

curl -Ls https://astral.sh/uv/install.sh | sh

설치 후에는 터미널에서 uv 명령어가 동작하는지 확인해 봅니다:

uv --version

가상환경

파이썬에서 가상환경(Virtual Environment)은 서로 다른 프로젝트마다 독립적인 패키지 공간을 제공하는 기술입니다. 프로젝트마다 필요한 패키지 버전이 다를 수 있기 때문에, 시스템 전체에 영향을 주지 않고 프로젝트별로 격리된 환경을 만드는 것이 중요합니다.

가상환경이 필요한 이유

• 서로 다른 프로젝트가 서로 다른 패키지 버전을 필요로 할 수 있습니다.
• 전역 파이썬 환경에 설치된 패키지는 다른 프로젝트에 영향을 줄 수 있습니다.
• 개발과 배포 환경 간에 일관성을 유지하기 위해서도 중요합니다.

예를 들어, A 프로젝트는 Django 4.2, B 프로젝트는 Django 5.2.5를 사용한다고 가정해 봅시다. 전역 환경에서 패키지를 설치하면 의존성 충돌이 일어날 수 있지만, 따로 가상환경을 분리하여 패키지를 설치하면 이 문제가 일어나지 않습니다.

가상환경의 구조

보통 가상환경은 .venv 또는 env라는 폴더로 구성되어 있고, 내부에 아래와 같은 구조를 가집니다:

.venv/
├── bin/ (또는 Scripts/ - 윈도우)
├── lib/
├── pyvenv.cfg

가상환경 사용법

가상환경 만들기

현재 디렉터리에 .venv 폴더를 만들고 가상환경을 생성하려면 다음 명령어를 실행합니다:

uv venv

가상환경의 이름을 지정하여 만들고 싶다면 다음 명령어를 실행합니다:

uv venv myenv

여러 버전의 파이썬 설치하기

uv에서는 파이썬을 설치할 수 없습니다. 따라서 파이썬 런타임은 따로 설치해야 하며, 설치된 파이썬 버전을 기반으로 가상환경을 만듭니다.

uv에서 특정 파이썬 버전으로 가상환경을 만들려면 해당 버전이 시스템에 먼저 설치되어 있어야 합니다. 파이썬은 공식 웹사이트나 pyenv, 패키지 매니저를 통해 여러 버전을 한 컴퓨터에 설치할 수 있습니다.

macOS / Linux의 경우 pyenv를 사용할 수 있습니다.

brew install pyenv         # macOS의 경우
sudo apt install pyenv     # Ubuntu의 경우

pyenv install 3.11.6
pyenv install 3.10.13

설치된 버전은 pyenv versions로 확인하고, 특정 버전을 기본값으로 설정할 수 있습니다.

pyenv global 3.11.6

Windows의 경우 python.org에서 설치본을 다운로드 받아 설치하거나 winget 명령어로 설치할 수 있습니다.

winget install Python.Python.3.11
winget install Python.Python.3.10

설치 후 python3.11 --version 과 같이 확인할 수 있고, uv에서 사용할 때는 해당 경로 또는 명령어를 지정하면 됩니다.

다른 파이썬 버전으로 가상환경 만들기

사용하고 싶은 파이썬 버전을 --python 매개변수로 지정합니다.

uv venv --python=python3.11

Windows에서는 파이썬의 전체 경로를 지정합니다.

uv venv --python="C:\Python311\python.exe"

가상환경을 활성화하는 방법은 기존과 동일합니다.

macOS/Linux에서는 다음 명령어를 실행합니다.:  .venv/bin/activate

Windows에서는 다음 명령어를 실행합니다.: .venv\Scripts\Activate.ps1

가상환경을 비활성화하려면 다음 명령어를 실행합니다.: deactivate

패키지 설치 및 의존성 관리

uv는 pip의 역할을 빠르고 효율적으로 수행합니다. 아래는 uv pip를 사용하는 주요 예제입니다.

패키지 설치 관리

패키지 설치

uv pip install requests

이 명령어는 requests 패키지를 설치합니다. 사용중인 가상환경이 없으면 자동으로 .venv 가상환경을 만들고 거기에 해당 패키지를 설치합니다.

설치된 패키지 목록 저장하기

uv pip freeze > requirements.txt

requirements.txt 기반으로 패키지 설치하기

uv pip install -r requirements.txt

더 빠르고 깔끔하게 동기화하고 싶다면 sync 명령어를 사용할 수 있습니다:

uv pip sync requirements.txt

패키지는 어디에 설치될까?

uv pip install로 설치한 패키지는 가상환경 내부의 site-packages 폴더에 저장됩니다.
예를 들어, .venv 폴더를 가상환경으로 사용하고 있다면 다음 경로에 설치됩니다:

macOS/Linux에서는 다음 경로에 설치됩니다. : .venv/lib/python3.x/site-packages/

Windows에서는 다음 경로에 설치됩니다. : .venv\Lib\site-packages\

이 경로는 파이썬이 모듈을 찾을 때 사용하는 sys.path에 자동 등록됩니다.
즉, 가상환경을 활성화하면 해당 디렉터리에 설치된 모든 모듈을 바로 import해서 사용할 수 있습니다.

import site
print(site.getsitepackages())

import sys
print(sys.path)

uv는 일반적인 파이썬 가상환경 구조를 준수하므로 기존 venv, virtualenv와 완벽히 호환됩니다.

이제 uv로 빠르고 깔끔한 파이썬 개발 환경을 구성해보세요.

가상환경에 대한 보다 자세한 이야기는 제가 번역하고 인사이트 출판사에서 펴낸 <파이썬다운 코드를 개발하는 63가지 실용기법> 488쪽부터 493쪽까지 설명되어 있습니다.

알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=369848931

교보: https://product.kyobobook.co.kr/detail/S000217294649

YES24: https://www.yes24.com/product/goods/151253343

트위터에서 우연히 다음과 같은 이미지를 봤습니다. 이걸 깨닫는데 20년 이상이 걸렸다라는 부제가 있습니다.

스르륵 읽어보니 마음에 듭니다. 제 생각을 곁들여 우리말로 풀어 봅니다. 제가 이해한 대로 뜻풀이+제 생각 덧대기를 한 것이므로, 원 저자의 생각과 다른 부분이 있을 수 있습니다.

1. 단지 배우기만 하는 것에는 덜 집중하고, 행동으로 옮기는데 더 집중하라.

개발자가 새로운 기술을 익힐 때 종종 빠지는 함정이 있다. 튜토리얼을 완주하고, 문서를 읽고, 강의를 듣는 것으로 학습이 끝났다고 여기는 것이다. 하지만 실제로는 그때부터 진짜 학습이 시작된다.

우리가 무언가를 배운다는 것은 지금 알고 있는 지식으로 해결하지 못한 문제를 풀기 위한 것이다.따라서 Doing, 지식을 이용하여 문제를 해결하는데 좀 더 집중해야 한다. 학습이란 무언가를 배우는 행위(學)에 그것을 실제로 적용해 보면서 몸에 익히는 과정(習)이다.

<머신러닝 마스터클래스>의 저자 민재식 박사가 언급한 접근법이 인상적이었다. 머신러닝을 학습할 때 필요한 수학 분야를 먼저 파악하고, 해당 영역을 공부하면서 동시에 머신러닝을 익혔다는 것이다. 목적이 명확할 때 학습의 효율성이 달라진다는 점을 보여주는 사례다.

뭔가를 배울 때에는 배우는 목적을 상기할 필요가 있고(가르치는 사람 입장에서), 문제를 해결하기 위해 무엇을 배워야 하는지 순서를 바꿔보면 도움이 되겠다(배우는 사람 입장에서)는 생각이 든다.

2. 버그를 고치다보면 빠르게 배운다.

완벽한 코드를 처음부터 작성하는 개발자는 존재하지 않는다. 버그는 단순한 실수가 아니라 우리가 문제를 완전히 이해하지 못했다는 신호다.

디버깅 과정에서 우리는 처음 문제를 분석할 때 놓쳤던 부분들을 발견하게 된다. 이 과정에서 일어나는 학습은 일반적인 이론 학습보다 훨씬 깊은 이해와 통찰을 얻을 수 있고 지속적인 성장이 가능하다. 이 과정이 실제 맥락 안에서 일어나는 학습이기 때문이다.

3. 해결책은 항상 간단하게 시작해서 반복하면서 발전시켜나가자.

습(習)이라는 글자는 새끼 새가 날개짓을 연습하는 모습을 형상화한 것이라고 한다. 하얀 날개를 가진 새끼 새도 처음부터 완벽하게 날지 못한다. 작은 동작부터 시작해서 점진적으로 복잡한 비행을 익혀간다.

소프트웨어 개발도 마찬가지다. 처음부터 완벽한 아키텍처를 설계하려 하기보다는, 작동하는 최소한의 것부터 만들어서 점진적으로 개선해나가는 것이 현실적이다. 이런 접근법이 실패의 리스크도 줄이고 학습의 기회도 늘린다.

4. 자주 실패하는 것이 비싼 댓가를 치르지 않는다.

큰 단위로 개발하고 나서 실패하면 그 댓가는 크다. 시간, 비용, 그리고 심리적 타격 모두 상당하다. 반면 작은 단위로 자주 시도하고 빠르게 피드백을 받으면, 개별 실패의 비용은 작지만 전체적으로는 더 안전한 경로를 걸을 수 있다.

이론적으로는 당연한 이야기지만, 실제로 실행하기는 쉽지 않다. 특히 완벽주의 성향이 있거나 실패에 대한 두려움이 클 때는 더욱 그렇다. 하지만 경험상 미루고 묵혀두면 결국 더 큰 문제가 되는 경우가 많았다.

5. 계획을 세운 뒤 코드를 작성하자.

개발과 코딩은 다르다. 개발은 문제를 이해하고 해결 방법을 설계하는 것이고, 코딩은 그 설계를 프로그래밍 언어로 구현하는 것이다. 순서가 바뀌면 좋은 결과를 기대하기 어렵다.

키보드를 두드리기 전에 먼저 생각하는 시간을 갖는 것. 간단해 보이지만 실제로는 상당한 훈련이 필요한 습관이다.

6. 뭔가 잘 안된다면 새로운 것을 배우는 중이라는 뜻이다.

어려움에 부딪혔을 때 좌절하기보다는 성장의 기회로 받아들이는 관점이 중요하다. 모든 것이 순조롭게 진행된다면 새로 배우는 것이 없다는 뜻이기도 하다.

물론 일상적인 업무는 안정적으로 처리해야 하지만, 의도적으로 자신의 역량보다 조금 높은 수준의 도전을 찾아가는 자세도 필요하다.

7. 코드 품질이 중요하다. 의도가 명확히 드러나는 코드를 작성하자.

코드는 일종의 번역 작업의 결과물이다. 인간의 언어로 표현된 문제와 해결책을 컴퓨터가 이해할 수 있는 언어로 옮기는 것이다. 좋은 번역이 원문의 의도를 정확히 전달하듯, 좋은 코드는 개발자의 의도를 명확히 드러내야 한다.

의도가 명확한 코드는 별도의 문서 없이도 스스로를 설명한다. 이런 코드는 유지보수 비용을 크게 줄여준다.

8. 피드백을 받고, 도움을 요청하자.

성장의 핵심은 도전과 피드백의 순환 구조를 만드는 것이다. 혼자서 모든 것을 해결하려고 하는 것은 비효율적일 뿐만 아니라 성장 기회를 놓치는 일이기도 하다.

코드 리뷰, 페어 프로그래밍, 멘토링 등 다양한 형태로 피드백을 받을 수 있다. 중요한 것은 도움을 요청하는 것을 부끄러워하지 않는 것이다. 적절한 도움 요청은 프로페셔널의 자질이다.

9. 항상 작성한 코드를 테스트해보아야 한다. 테스트 자동화를 배워라.

AI가 코드 작성을 도와주는 시대가 되어도 테스트의 중요성은 변하지 않는다. 오히려 더 중요해질 수도 있다. 자신이 작성한 코드에 대한 책임은 여전히 개발자에게 있기 때문이다.

반복적인 테스트 작업을 자동화하는 것은 단순히 시간을 절약하는 것 이상의 의미가 있다. 코드의 품질을 지속적으로 보장하는 안전망 역할을 한다. 이광근 교수님이 운영하는 쉬운용어 사전에서 회귀 테스트를 퇴행 방지, 여전히 동작하는지 검사하는 것이라 풀어낸 것을 봤다. 우리가 작성한 코드가 쉽게 상하지 않도록 테스트하고, 자동화해야 한다.

10. 문제를 푼 다음에 코드를 작성하자.

코드를 작성하기 전에 해결하려는 문제를 정확히 이해해야 한다. 때로는 코드를 작성하지 않는 것이 가장 좋은 해결책일 수도 있다.

문제를 제대로 이해하지 못한 채 작성된 코드는 결국 다시 작성해야 할 가능성이 높다. 처음에 시간을 충분히 투자해서 문제를 분석하는 것이 전체적으로는 더 효율적이다.

11. 디버깅은 어렵다. 디버깅하는 방법부터 숙달하자.

코드를 작성할 때와 디버깅할 때는 다른 종류의 사고 과정이 필요하다. 전자는 구성적이고 창조적인 사고라면, 후자는 분석적이고 추론적인 사고다.

디버깅 능력은 단순히 도구 사용법을 아는 것 이상이다. 체계적으로 문제를 분석하고, 가설을 세우고, 검증하는 방법론을 익혀야 한다. 이런 프레임워크가 있으면 복잡한 문제 상황에서도 당황하지 않고 차근차근 접근할 수 있다.

이 11가지 관찰은 완성된 원칙이라기보다는 개발 과정에서 지속적으로 되돌아볼 만한 지점들이다. 기술은 빠르게 변하지만, 문제를 해결하는 근본적인 접근법은 상당히 일관된 면이 있다는 생각이다.