uv는 정말 빠르지만, 패키지 관리 UX는 왜 이렇게 헷갈릴까

uv가 파이썬 생태계를 바꾸고 있는데요

혹시 파이썬으로 개발하시다가 pip install이 너무 느려서 답답했던 경험 있으신가요? 가상환경 만들고, 패키지 설치하고, requirements.txt 관리하는 과정이 항상 어딘가 모르게 매끄럽지 않았죠. 그런 상황에서 등장한 게 바로 uv라는 도구거든요. Rust로 만들어진 초고속 패키지 매니저인데, 기존 pip보다 10배에서 100배까지 빠르다는 게 큰 매력이에요.

그런데 이번에 Loopwerk 블로그에 올라온 글은 uv의 속도가 아니라 사용 경험(UX) 자체에 문제를 제기하고 있어요. 작성자는 uv를 충분히 써본 뒤에 "빠른 건 인정하지만, 명령어 체계가 너무 혼란스럽다"고 지적했어요. 이게 단순한 불평이 아니라, 파이썬 도구 생태계가 안고 있는 구조적인 문제를 잘 보여주는 사례라서 한 번 짚어볼 만해요.

뭐가 그렇게 헷갈리는 걸까요

핵심 문제는 uv가 두 가지 서로 다른 워크플로우를 하나의 CLI 안에 섞어 놓았다는 점이에요. 하나는 uv pip로 시작하는 명령어들인데, 이건 기존 pip를 그대로 흉내 낸 거예요. uv pip install requests 이렇게 쓰면 pip와 거의 똑같이 동작하죠. 다른 하나는 uv add, uv sync, uv lock 같은 프로젝트 중심 명령어들인데, 이건 Poetry나 Cargo처럼 pyproject.toml을 중심으로 의존성을 관리하는 방식이에요.

문제는 이 두 방식이 같은 일을 하는 것 같으면서도 결과가 다르다는 거예요. 예를 들어 uv pip install을 쓰면 가상환경에는 패키지가 들어가지만 pyproject.toml에는 기록이 안 남아요. 반대로 uv add를 쓰면 pyproject.toml과 lock 파일까지 자동으로 갱신되죠. 초보자가 둘 다 "패키지 설치 명령어"라고 생각하고 섞어 쓰다 보면, 어느 순간 의존성 파일이 실제 환경과 완전히 어긋나 있는 상황을 만나게 돼요.

또 다른 불편함은 암묵적인 동작이 너무 많다는 점이에요. uv는 기본적으로 .venv 폴더를 자동으로 만들고, 명령을 실행할 때마다 알아서 동기화를 시도해요. 편리하긴 한데, 내가 지금 무슨 일이 일어나고 있는지 파악하기 어려워지죠. "왜 갑자기 패키지가 다시 깔리지?", "내 가상환경은 어디 갔지?" 같은 의문이 자꾸 생긴다는 거예요.

왜 이렇게 만들었을까

uv를 만든 Astral 팀의 입장도 이해는 가요. 기존 pip 사용자를 한 번에 끌어들이려면 uv pip 같은 호환 명령어가 필요하고, 동시에 Poetry 같은 현대적인 워크플로우도 제공해야 경쟁력이 있거든요. 그래서 두 마리 토끼를 다 잡으려다가 결과적으로 명령어 체계가 비대해진 거예요.

비슷한 사례를 다른 언어에서 찾아보면, Node.js 진영의 npm, yarn, pnpm 경쟁이 떠올라요. Rust의 Cargo는 처음부터 하나의 통일된 워크플로우만 제공해서 깔끔한 평을 받고 있죠. 파이썬은 역사적으로 pip, virtualenv, pipenv, poetry, conda, hatch, rye 등 너무 많은 도구가 난립해 왔고, uv는 그걸 통합하겠다는 야심을 가지고 출발했어요. 그런데 통합하는 과정에서 "기존 방식도 지원하고 새 방식도 지원한다"가 되어버리면서 학습 곡선이 오히려 가팔라진 면이 있어요.

한국 개발자라면 어떻게 받아들여야 할까

실무에서 uv를 도입하려고 고민 중이라면, 일단 하나의 워크플로우만 정해서 팀 전체가 통일하는 게 중요해요. 신규 프로젝트라면 uv init으로 시작해서 uv add, uv sync, uv run만 사용하는 프로젝트 모드를 추천해요. pyproject.toml을 단일 진실 공급원으로 삼으면 의존성 추적이 훨씬 명확해지거든요.

반대로 기존 pip 기반 프로젝트를 점진적으로 옮기는 중이라면 uv pip 명령어로 시작해서 점차 프로젝트 모드로 마이그레이션하는 전략이 안전해요. 두 방식을 혼용하지 마세요. CI/CD 파이프라인에서도 마찬가지로 한 방식으로 통일해야 디버깅이 쉬워져요.

그리고 uv는 아직 빠르게 변하고 있는 도구라는 점도 기억해 두세요. 메이저 버전이 올라가면서 기본 동작이 바뀌는 경우가 종종 있으니, 프로덕션에서는 버전을 핀으로 고정하고 변경 로그를 챙겨 보는 습관을 들이는 게 좋아요. 속도라는 압도적인 장점 때문에 단점을 감수할 가치는 충분하지만, 도구를 도입할 때는 "빠르다"만큼이나 "명확하다"도 중요한 평가 기준이라는 걸 잊지 않으면 좋겠어요.

마무리

좋은 도구가 반드시 좋은 UX를 보장하지는 않아요. uv는 분명 파이썬 패키지 관리의 미래를 보여주는 도구지만, 지금 시점에서는 사용자가 스스로 워크플로우를 정리하고 들어가야 진가를 누릴 수 있어요. 여러분은 uv를 쓰면서 어떤 부분이 가장 헷갈렸나요? 아니면 아직 Poetry나 pip로 충분하다고 느끼시나요?