# ty 베타 출시 발표 > Clean Markdown view of GeekNews topic #25148. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25148](https://news.hada.io/topic?id=25148) - GeekNews Markdown: [https://news.hada.io/topic/25148.md](https://news.hada.io/topic/25148.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-12-17T15:32:58+09:00 - Updated: 2025-12-17T15:32:58+09:00 - Original source: [astral.sh](https://astral.sh/blog/ty) - Points: 7 - Comments: 2 ## Summary **Rust로 구현된 초고속 Python 타입 체커** **ty**가 베타 버전으로 공개되었습니다. 기존 mypy·Pyright 대비 최대 60배 빠른 성능을 내며, **증분형 아키텍처**를 통해 코드 수정 시 필요한 부분만 재계산해 실시간 응답 속도를 극대화합니다. Astral은 ty를 Ruff·uv와 함께 Python 개발 환경의 핵심 도구로 발전시켜, 정확성과 생산성을 동시에 높이는 생태계를 구축할 계획입니다. ## Topic Body - **Rust**로 작성된 **초고속 Python 타입 체커 및 언어 서버**인 **ty**가 베타 버전으로 공개됨 - **mypy**, **Pyright**, **Pylance**의 대안으로 설계되었으며, **10~60배 빠른 성능**을 제공 - **증분형 아키텍처**를 통해 코드 수정 시 필요한 부분만 재계산하여 실시간 응답 속도를 극대화 - **정확성과 사용성**을 중시해 교차 타입, 고급 타입 축소, 도달 가능성 분석 등 최신 타입 시스템 기능을 지원 - Astral은 ty를 **Ruff**, **uv**와 함께 Python 생태계의 핵심 개발 도구로 발전시킬 계획 --- ### ty 개요 - **ty**는 Astral이 개발한 **Python 타입 체커 및 언어 서버**로, Rust로 구현됨 - 기존의 **mypy**, **Pyright**, **Pylance**보다 훨씬 빠른 대안으로 설계 - Astral 내부 프로젝트 전반에서 이미 사용 중이며, 베타 단계에서 외부 사용자에게도 추천됨 - Astral은 Python 생태계를 위한 고성능 개발 도구를 제작하는 팀으로, **uv**(패키지 관리자)와 **Ruff**(린터 및 포매터)로 알려져 있음 ### 성능과 아키텍처 - ty는 **언어 서버 중심 구조**로 설계되어, 파일 수정 시 필요한 연산만 재실행하는 **증분 처리 방식**을 채택 - 이로 인해 편집기 내 실시간 업데이트 속도가 매우 빠름 - 캐시 없이 실행할 경우에도 **mypy 및 Pyright보다 10~60배 빠름** - 예시: PyTorch 저장소의 주요 파일 수정 시, 진단 재계산 속도는 **4.7ms**로 Pyright(386ms)보다 80배, Pyrefly(2.38초)보다 500배 빠름 - 대규모 프로젝트에서도 **증분 업데이트 시 성능 격차가 수십 배 이상** 발생 ### 타입 시스템과 정확성 - ty는 **교차 타입(intersection types)** , **고급 타입 축소(advanced type narrowing)** , **타입 기반 도달 가능성 분석(reachability analysis)** 등을 지원 - 이러한 기능을 통해 **정확한 타입 피드백**을 제공하고, 불필요한 오탐(false positive)을 줄임 - 목표는 단순한 속도 향상이 아니라, **정확성과 사용자 경험을 모두 개선한 타입 체커** 구축 ### 진단 시스템 - ty는 **Rust 컴파일러의 오류 메시지 시스템**에서 영감을 받은 **고급 진단 시스템**을 포함 - 단일 진단 메시지에서 여러 파일의 문맥을 함께 제시하여 문제 원인과 해결 방향을 명확히 보여줌 - 예: 잘못된 딕셔너리 키 할당 시, 타입 불일치 위치와 선언 위치를 함께 표시 - 진단 출력은 ty의 핵심 인터페이스로, **사람과 AI 모두가 이해하기 쉬운 구조**로 설계됨 ### 언어 서버 기능 - ty는 **VS Code**, **Cursor** 등 LSP(Language Server Protocol)를 지원하는 모든 편집기에서 사용 가능 - **정의로 이동**, **심볼 이름 변경**, **자동 완성**, **자동 임포트**, **의미 기반 구문 강조**, **인레이 힌트** 등 현대적 언어 서버 기능을 모두 지원 - **VS Code 확장**을 통해 설치 가능하며, `uv tool install ty@latest` 명령으로 CLI 설치도 가능 ### 향후 계획 - 베타 이후 단기 목표는 **안정성 강화와 버그 수정**, **Python 타입 명세 완성**, **Pydantic 및 Django 지원** - 장기적으로는 ty를 Astral 도구 체인의 **의미 기반 기능 엔진**으로 확장 - **죽은 코드 제거**, **미사용 의존성 탐지**, **보안 취약점(CVE) 도달성 분석**, **타입 인식 린팅** 등 기능 예정 - Astral은 ty를 지속적으로 개선해 **Python을 가장 생산적인 프로그래밍 생태계**로 만드는 것을 목표로 함 ### 감사 인사 - ty 개발에는 수십 명의 오픈소스 기여자가 참여했으며, **MIT 라이선스**로 공개됨 - **Salsa**, **Elixir**, **Python typing 커뮤니티**의 여러 인물과 팀이 기술적 협력 및 영감을 제공 - Astral 핵심 팀은 **타입 이론**, **Python 런타임 의미론**, **생태계 활용 패턴**에 대한 깊은 이해를 바탕으로 ty를 개발함 ## Comments ### Comment 47969 - Author: iolothebard - Created: 2025-12-19T02:14:48+09:00 - Points: 1 Astral은 파이썬빠인가 러스트빠인가… 아스트랄하구만~ ### Comment 47906 - Author: neo - Created: 2025-12-17T15:32:58+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46294289) - 이 비교표에 Ty가 추가되면 좋겠음 [Python typing conformance 결과표](https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html)를 보면 **Pyright**의 성능을 과소평가하면 안 된다고 생각함 Emacs에서 Ty(LSP)를 잠깐 써봤는데 꽤 잘 작동함. 다만 메서드 시그니처가 표시될 때 일부 파라미터의 타입 주석이 너무 **장황하게** 보이는 점이 조금 거슬림 그래도 장기적으로 Ty를 쓸 가능성이 높다고 봄. 첫 베타 출시 축하함 - 사양 준수도 중요하지만, 그걸로 타입 체커를 선택하는 건 추천하지 않음 실제 사용자들이 중요하게 여기는 부분과는 거리가 있음. (나는 Python Typing Council에서 스펙과 테스트를 함께 만들었음) - 우리도 곧 그 표에 추가할 예정임. Pyright 수준의 **conformance**를 따라잡으려면 시간이 좀 걸리겠지만, 정식 출시 전까지 그게 목표임 - Pyright도 훌륭하지만 [BasedPyright](https://docs.basedpyright.com/latest/)이 그 위에 더 개선된 버전임 그래도 나는 **uv**의 만족스러운 사용자라 Ty가 충분히 안정되면 옮길 생각임 - [이 PR](https://github.com/python/typing/pull/2137)은 아직 WIP 상태지만, 다시 **OSS 기여**를 시작할 동기부여가 됐음 - Pyright는 좋지만 **속도**가 느림. LSP의 반응 속도는 UX에 큰 영향을 주기 때문에 Ty가 얼마나 개선했을지 기대됨 - Astral이 훌륭한 도구를 만들고 있으니, **파괴적인 수익화** 없이 잘 성장하길 바람 - Astral의 첫 상용 제품은 [pyx](https://astral.sh/pyx)임. 성공해서 계속 멋진 오픈소스 도구를 만들어가길 바람 - 지금까지의 작업은 Python 커뮤니티에 대한 **공공 서비스** 수준이라고 생각함 - 방향성은 **bun**과 비슷하게 가는 느낌임 - 다만 기존 도구를 완전히 대체한다고 주장하면서 실제로는 기능을 다 구현하지 않는 점이 아쉬움 결국 기존 도구로 되돌아가야 하는 경우가 생김. 나에게는 속도보다 **정확한 타입 검사**가 더 중요함 - Astral 팀에게 감사함. 우리는 **Pydantic**을 많이 쓰고 있어서 Ty의 정식 릴리스에서 1급 지원이 예정되어 있다니 기대됨 현재는 Pyright와 Mypy를 함께 돌리고 있는데, 서로 다른 오류를 잡아내서 중복된 느낌임 [이 표](https://htmlpreview.github.io/?https://github.com/python/typing/blob/main/conformance/results/results.html)에 따르면 Pyright가 superset이라는데, 실제 경험은 달랐음 2년 전 분석이라 지금은 다를 수도 있음. 대규모 코드베이스에서 Pyright 하나로 통합한 사례가 있는지 궁금함 - 나도 **mypy 초기 사용자**로서 Pyright가 VS Code에 추가되었을 때 비교해봤음 mypy가 더 유연하고 정확하게 추론하는 경우가 많았고, Pyright는 **false positive**가 많아서 꺼둔 적도 있음 요즘은 Pyright가 많이 발전했겠지만, BasedPyright는 오히려 비생산적이었음 커뮤니티에서 mypy를 깎아내리고 Pyright를 찬양하는 분위기가 강한데, 내 경험과는 좀 다름 - 다시 말하지만, **스펙 준수 테스트**는 실제 사용자 경험을 반영하지 않음 주로 주석의 의미론에 집중하기 때문에 타입 체커 선택 기준으로 삼기엔 부적절함 (나도 Python Typing Council에서 이 스펙과 테스트를 만들었음) - 제목은 “Ty 베타 릴리스 발표”가 더 적절했을 것 같음 나는 **Pyrefly**를 Pyright보다 선호했는데, 최근 버그로 이전 버전에 고정해야 해서 불편했음 Ty를 설치하려 했더니 Cursor 버전 호환 오류가 발생했음 - 혹시 추가 오류 메시지가 있다면 **이슈 등록** 부탁함. 나는 Cursor에서 Ty 확장을 몇 주째 잘 쓰고 있어서 재현이 어려움 - (Pyrefly 메인테이너임) 그 크래시도 [Pyrefly 저장소](https://github.com/facebook/pyrefly)에 이슈로 남겨주면 좋겠음 - 아직도 한 언어에 이렇게 많은 **타입 체커**가 존재하는 이유를 모르겠음 라이브러리 제작자는 모든 체커에 대해 테스트해야 하나? 개발자는 특정 체커를 지원하는 라이브러리만 써야 하나? - Python은 **덕 타이핑 + 선택적 타입 주석** 언어라서 다양한 구현이 생길 수밖에 없음 - 일부는 호출자 추론 범위나 **명시적 타입 요구 정책**이 달라서 생긴 차이임 패키지 경계에서는 명시적 타입이 필요하지만, 내부 코드에서는 모호함이 많음 Astral은 특히 **증분 처리 성능**을 주요 설계 목표로 삼고 있음 - 실제로는 대부분 **mypy** 기준으로 테스트함. Pyright는 VS Code 기본 확장 덕분에 점점 영향력을 넓히는 중임 필요하면 직접 **type stub**을 제공해서 호환성을 확보할 수도 있음 - Ty가 “타입 체커를 만족시키기 위해 주석을 추가할 필요가 없다”는 입장을 취한 게 마음에 듦 이전 체커는 사소한 경고로 귀찮게 했지만, Ty는 실제 **논리적 오류**를 잘 잡아줌 - Ty가 **언어 서버(LSP)** 역할도 한다는 걸 오늘 처음 알았음 즉, Neovim이나 VSCode에서 mypy와 Pyright를 모두 대체할 수 있음 - Django 지원은 어떤지 궁금함. Django는 **매직 코드**가 많아서 타입 체커가 다루기 어려움 - Ty는 아직 Django를 지원하지 않으며 **플러그인 시스템**도 없음 Django를 쓴다면 당분간은 mypy나 Pyright를 유지하는 게 좋음 - Ty가 빠르지 않더라도 **교차 타입(A & B)** 지원만으로도 쓸 만하다고 생각함 표준 Python 타입 시스템에서 빠져 있는 기능이라 반가움 - Ruby에도 **uv** 같은 게 있는지 궁금함. Python이나 TypeScript에서는 uv나 bun을 쓰는데, Ruby는 뒤처진 느낌임 - [Rv](https://news.ycombinator.com/item?id=45023730)라는 새로운 Ruby 관리 도구가 있음. 이게 그 대안이 될 수도 있음