# 코드 포매팅 기능이 실험적으로 uv에 도입됨

> Clean Markdown view of GeekNews topic #22676. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=22676](https://news.hada.io/topic?id=22676)
- GeekNews Markdown: [https://news.hada.io/topic/22676.md](https://news.hada.io/topic/22676.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-08-23T10:08:58+09:00
- Updated: 2025-08-23T10:08:58+09:00
- Original source: [pydevtools.com](https://pydevtools.com/blog/uv-format-code-formatting-comes-to-uv-experimentally/)
- Points: 1
- Comments: 1

## Topic Body

- 새로운 uv 버전에서 **코드 포매팅** 기능을 실험적으로 제공함
- `uv format` 명령어는 **Ruff의 포매터**를 내부적으로 사용하여 Python 코드를 일관되게 스타일링함
- 기존에 별도의 도구 없이 **uv만으로 간편하게 코드 정리 작업** 가능함
- 사용자는 추가 인자를 통해 **형식 지정 동작을 세부 조정**할 수 있음
- 아직 **실험적인 기능**이므로 명령 방식, 에러 처리 등에서 변화 가능성이 존재함

---

### 개요

uv의 최신 릴리즈(0.8.13)는 Python 개발자가 오랫동안 기다렸던 실험적 명령어인 `uv format` 기능을 도입함. 이 기능을 통해 프로젝트 내에서 별도의 포매팅 도구를 추가로 관리하지 않고도 **uv 도구만으로 코드 스타일 정리**를 수행할 수 있음

### uv format이란?

- `uv format` 명령어는 **uv 인터페이스를 통해 Python 코드 포매팅**을 제공함
- 내부적으로는 **Ruff 포매터**를 호출하여 코드를 자동으로 일관성 있게 정리함

### 개발자 참고 사항

Charlie Marsh(uv 개발자)는 Hacker News에서 다음과 같이 설명함

> Ruff와 uv는 병합되는 것이 아니며, 여전히 별개의 도구임  
> 단순히 사용자가 포매터를 별도의 도구로 인식하지 않고도 이용하도록 경험을 향상시키는 목적임  
> Rust 생태계의 cargo fmt와 rustfmt 관계와 유사함

### 사용 방법

- uv 0.8.13 이상의 버전을 사용해야 함
- `uv format` 명령어를 프로젝트 루트에서 실행하면 **ruff format**을 수행하는 효과가 있음  
- 실행 방식은 uv의 명령어 인터페이스를 따름

### 추가 인자 전달

- `uv format -- [추가 인자]` 형태로 **Ruff에 전달할 세부 옵션**을 설정할 수 있음
- uv의 편의성과 Ruff의 세밀한 설정을 동시에 활용 가능함

### 실험 단계 안내

- 현재 기능은 **실험적인 단계**로, 향후 명령 방식이나 프로젝트 구조 통합 방식이 달라질 수 있음
- 에러 처리, 출력 형식 등도 지속적으로 개선 예정임  
- 사용자 피드백을 반영하여 기능이 진화할 예정임

### 마무리

- Python 프로젝트에 **간편하고 일관성 있는 코드 스타일링**이 필요한 경우 `uv format`을 적극적으로 시도해볼 수 있음
- **실험적 도입**인 만큼, 직접 사용 후 피드백을 제공하면 향후 uv의 발전에 기여할 수 있음

## Comments



### Comment 42801

- Author: neo
- Created: 2025-08-23T10:08:58+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=44977645) 
* `ruff`가 `ty`와 합쳐지면 더 좋을 것 같음, `uv`는 패키지나 프로젝트 관리에 집중하는 게 맞고 코드 스타일 편집까지 관여하면 안 된다는 생각임, `uv`가 코드 파일을 수정하는 유일한 경우는 의존성 업데이트(PEP 723)일 때뿐이어야 한다고 봄
  * `ruff`와 `uv`는 합쳐지는 것이 아니고, 계속 별도 도구로 남는다는 점을 명확히 하고 싶음, 이는 포매터를 따로 신경쓰고 싶지 않은 사용자를 위한 더 단순한 경험 제공 목적임, Rust의 Cargo처럼 `cargo fmt`가 내부적으로 `rustfmt`를 실행하는 것과 유사한 구성임
  * Rust의 cargo에서 `cargo fmt`가 있는 방식처럼 흉내 내는 것임
  * 본질적으로 uv를 완성형 Python 패키지 매니저로 만드는 것이 목표이고, 각 부분 도구는 필요하면 개별적으로도 쓸 수 있음, 즉 uv는 Python을 위한 cargo 같은 존재이고, 빠른 타입체커만 필요하면 ty만, 포매터/린터만 필요하면 ruff만 선택해서 사용할 수 있어야 한다는 점에서 ruff와 ty를 합치는 건 그다지 의미가 없어 보임
  * 만약 언젠가 `ty`도 `uv`에 합쳐지면 어떨지도 궁금함, 모두 astral.sh에서 나오는 만큼 이것이 비전일 수도 있지만, 아직 ty는 준비가 덜 된 상태임
  * 다음 단계로는 `uv lint` 같은 옵션을 도입해서 내부적으로 `ty`를 실행하게 만드는 것이 논리적인 진화라 생각함, 이상적으로는 하나의 표준 명령어나 일련의 커맨드로 파이썬 프로젝트를 준비(포맷, 린트, 테스트, 배포)할 수 있게 되면 좋겠음, 어쩌면 이게 여기에 담긴 비전일 것 같음
* uv를 정말 즐겨 쓰고 있지만, 불필요하게 점점 비대해지는 것 같아 조금 걱정임, 예를 들면 여러 서브 커맨드가 너무나 많은 독특한 플래그를 지원하는데, 몇몇은 거의 같은 결과를 내기도 함(`uv run --no-project`와 `uv run --active` 등), 쓸데없이 새로운 기능을 추가하기보다는 기존 도구와 문서 개선에 더 집중해 주길 바라는 마음임
  * Python 프로젝트를 안정적이고 재현 가능하며 이식성 있게 만드는 것은 정말 어려운 작업임, uv sync는 이론적으로 다시 재현 가능한 패키지 셋만 빌드해서 효용이 크지만, torch-tensorrt나 flash-attn처럼 복잡한 패키지는 환경에 따라 달라질 수밖에 없음, Python 커뮤니티는 종종 "내 컴퓨터에선 잘 된다"라는 식으로 문제를 개인화하는 경향이 있지만, 소프트웨어를 배포, 보안, 반복 가능성, 신뢰성 있게 만드는 데 드는 비용은 결코 사라지지 않고, 결국 누군가가 나중에 더 제한된 상황에서 그 비용을 치르게 됨, 이러한 다양한 사용자와 운영 요구를 모두 만족시키려고 애쓰는 것은 정말 어려운 일임
  * uv에 서브 커맨드를 추가하는 것이 왜 비대화로 여겨지는지 잘 모르겠음, 이미 uv는 복잡한 도구이고 문서화도 잘 되어 있음, 이렇게 직관적이고 자기 설명이 되는 커맨드라면 충분히 자연스럽게 추가될 수 있다고 생각함
  * uv에 대해 이야기할 때, 마치 "make 커맨드에 타겟이 너무 많다"고 말하는 것과 비슷하게 느껴짐
  * 이 옵션들이 메인 실행 파일에 내장되는지, 아니면 apt나 cargo처럼 별도 바이너리로 동작하는지 궁금함
* 이 업데이트는 확실히 좋은 선택이라 생각함, 왜 많은 사람들이 더 나은 방향에 반대하는지 잘 모르겠음, 물론 "조금 더 불편한 방법으로 이미 할 수 있다"라는 건 맞지만, 그건 '조금 더 불편한' 것임
  * "uvx ruff format"이 한 단어 더 긴 게 나쁜 건 아닌 것 같음, 오히려 실제로 실행되는 포매터가 불명확해지거나, ruff가 자동으로 설치되는 건지, 기존처럼 툴을 다운받아 캐시하는 건지가 더 헷갈릴 수 있음
  * 강하게 공감하는 부분임, 심지어 pyproject에서 포매터를 설정할 수 있게 만들어주면 더 좋겠음
  * 가장 큰 불만은 현재로서는 다른 포매터 지원이 없어 보인다는 점임, 내 프로젝트에서 black을 쓰면 uv format이 동작하지 않음
* 개인적으로 이 변경으로 내 소규모 팀(계리사들이 주요 멤버)의 코드 포매팅이 획기적으로 쉬워질 것 같아서 기대가 큼, uv가 파이썬 도입과 온보딩에 끼친 영향도 꽤 컸기 때문에, 코드품질을 더 쉽게 끌어올릴 방법은 언제나 환영임, 물론 ruff만 따로 쓰거나 pre-commit 구성을 할 수도 있지만, `uv <기능>`이라는 단순한 멘탈 모델이 팀에게 큰 도움이 됨, 다른 포매터와의 연동도 가능했으면 좋겠고, 만약 SQL/dbt 모델 포매팅까지 지원된다면 더 바랄 게 없을 듯함, 우선 써보면서 가능성을 확인해 볼 생각임
  * 그 정도로 다중 포매팅이 필요하다면 Makefile이나 justfile 같은 걸 쓰는 게 더 나을 수도 있음, 그러면 `just format`으로 Python/SQL/Bash/TypeScript까지 한번에 포매팅할 수 있음
* 약간 기능 과다로 느껴짐, 1년 넘게 uv를 점점 더 많이 사용하고 있고 장점도 알겠지만, 아직까지 내 최우선 선택지는 아니고 이런 변화가 선호도를 높여주진 않을 것 같음
  * 구체적으로 이 방식이 뭐가 문제인지 궁금함, Go, Rust, Elixir 모두 이런 방법을 채택 중이고, 해당 언어 생태계에서 프로젝트 설정과 사용을 훨씬 더 수월하게 해줌, 커뮤니티가 공통 툴셋에 집중하고, 초보자와 전문가 모두에게 일관된 진입점을 제공하는 장점이 있음
  * 혹시 그렇다면 어떤 도구를 제일 선호하는지 궁금함
* 언젠가는 ruff의 기능이 uv와 ty에 통합될 것 같음, 린팅은 코드베이스를 더 잘 이해하는 ty가 담당하면 더 똑똑해질 수 있고, 포매팅은 프로젝트 관리가 주목적인 uv가 담당하는 것이 적합함
  * ty가 이미 ruff와 같은 저장소에 있으니, 통합도 그리 먼 얘기는 아닌 듯함
* 패키지 매니저는 운영 환경용 패키지 설치에 필수지만, 개발 전용 도구와 섞이는 건 일종의 '매력적이지만 위험한 덫' 같은 느낌임, 물론 Go와 Rust도 그렇게 하고 있지만, 근본적으로 생각해 보면 그리 좋은 구조는 아닌 것 같음
  * 정말 안 좋게 들릴 수도 있지만 cargo를 많이 써본 입장에서는 이런 '안 좋은 아이디어'가 더 많아졌으면 좋겠음, 만약 uv가 Python에서 cargo 같은 역할을 하게 된다면 Python 개발 경험이 엄청나게 좋아질 것임, 25년 넘게 Python을 쓰면서 여러 부족한 부분을 돌파해 온 입장에서 이제는 별다른 고민 없이 uv 하나로 가능해지는 것이 매우 만족스러움
* 새로운 `uv format`은 사실상 `uv run --with ruff ruff`의 단축키임
* 이 흐름이 정말 맘에 듦, 만약 내 의도대로라면 `uv fmt`라고 이름 짓고, `uv vet` 같은 것도 로드맵에 추가하는 게 좋을 것 같음
* 이미 검증된 코드 포매터 도구들이 많은데 굳이 이걸 도입할 이유는 전혀 느끼지 못함, 기능만 늘어난 느낌이어서 당분간 어떤 파이프라인에도 포함하지 않을 생각임
  * `uv format`은 그냥 `ruff format`의 프론트엔드에 가까움, 새로운 포매터가 추가되는 것도 아님
  * 이미 많은 사람들이 사용하는 ruff format을 손쉽게 쓰도록 해주는 단축키에 불과하다는 점을 알고 있으면 좋겠음