▲

ty 베타 출시 발표

 (astral.sh)
7P by GN⁺ 3일전 | ★ favorite | 댓글 2개
  • 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를 개발함
▲
iolothebard 1일전  [-]

Astral은 파이썬빠인가 러스트빠인가…
아스트랄하구만~

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견들

  • 이 비교표에 Ty가 추가되면 좋겠음
    Python typing conformance 결과표를 보면 Pyright의 성능을 과소평가하면 안 된다고 생각함
    Emacs에서 Ty(LSP)를 잠깐 써봤는데 꽤 잘 작동함. 다만 메서드 시그니처가 표시될 때 일부 파라미터의 타입 주석이 너무 장황하게 보이는 점이 조금 거슬림
    그래도 장기적으로 Ty를 쓸 가능성이 높다고 봄. 첫 베타 출시 축하함

    • 사양 준수도 중요하지만, 그걸로 타입 체커를 선택하는 건 추천하지 않음
      실제 사용자들이 중요하게 여기는 부분과는 거리가 있음. (나는 Python Typing Council에서 스펙과 테스트를 함께 만들었음)
    • 우리도 곧 그 표에 추가할 예정임. Pyright 수준의 conformance를 따라잡으려면 시간이 좀 걸리겠지만, 정식 출시 전까지 그게 목표임
    • Pyright도 훌륭하지만 BasedPyright이 그 위에 더 개선된 버전임
      그래도 나는 uv의 만족스러운 사용자라 Ty가 충분히 안정되면 옮길 생각임
    • 이 PR은 아직 WIP 상태지만, 다시 OSS 기여를 시작할 동기부여가 됐음
    • Pyright는 좋지만 속도가 느림. LSP의 반응 속도는 UX에 큰 영향을 주기 때문에 Ty가 얼마나 개선했을지 기대됨

  • Astral이 훌륭한 도구를 만들고 있으니, 파괴적인 수익화 없이 잘 성장하길 바람

    • Astral의 첫 상용 제품은 pyx임. 성공해서 계속 멋진 오픈소스 도구를 만들어가길 바람
    • 지금까지의 작업은 Python 커뮤니티에 대한 공공 서비스 수준이라고 생각함
    • 방향성은 bun과 비슷하게 가는 느낌임
    • 다만 기존 도구를 완전히 대체한다고 주장하면서 실제로는 기능을 다 구현하지 않는 점이 아쉬움
      결국 기존 도구로 되돌아가야 하는 경우가 생김. 나에게는 속도보다 정확한 타입 검사가 더 중요함

  • Astral 팀에게 감사함. 우리는 Pydantic을 많이 쓰고 있어서 Ty의 정식 릴리스에서 1급 지원이 예정되어 있다니 기대됨
    현재는 Pyright와 Mypy를 함께 돌리고 있는데, 서로 다른 오류를 잡아내서 중복된 느낌임
    이 표에 따르면 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 저장소에 이슈로 남겨주면 좋겠음

  • 아직도 한 언어에 이렇게 많은 타입 체커가 존재하는 이유를 모르겠음
    라이브러리 제작자는 모든 체커에 대해 테스트해야 하나? 개발자는 특정 체커를 지원하는 라이브러리만 써야 하나?

    • 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라는 새로운 Ruby 관리 도구가 있음. 이게 그 대안이 될 수도 있음
답변달기