▲

파이썬의 두 신규 Rust 기반 타입 체커 Pyrefly와 Ty 비교

 (blog.edward-li.com)
2P by GN⁺ 8일전 | ★ favorite | 댓글 2개
  • 최근 Meta의 Pyrefly와 Astral의 Ty 두 Rust 기반 파이썬 타입 체커가 공개되며, 기존 mypy와 pyright 대비 압도적 성능과 새로운 타이핑 패러다임을 보여줌
  • Pyrefly는 적극적 타입 추론 및 오픈소스를 지향하고, Ty는 “** gradual guarantee**” 원칙을 도입해 타입 에러 발생 최소화에 중점을 둠
  • 두 도구 모두 초기 알파 버전이지만, 다양한 프로젝트에서의 벤치마크 결과 Ty가 평균적으로 더 빠른 수행 속도를 기록함
  • 증분 분석에서 Pyrefly는 모듈 단위, Ty는 함수 타겟의 세밀한 증분화를 제공해 사용성과 구조가 상이함
  • Ty는 교차 타입 및 부정 타입 등 혁신적 타입 시스템을 선보이고, 더 직관적이고 명확한 오류 메시지를 제공함

Pyrefly와 Ty 소개

  • Pyrefly와 Ty는 Rust로 개발된 파이썬 타입 체커임
  • Pyrefly는 Meta(구 Facebook)에서 개발했으며, 기존의 OCaml 기반 Pyre를 대체함
  • Ty는 Astral이 개발했으며, Astral은 uv, ruff 등 파이썬 도구로 유명함
  • 두 프로젝트 모두 오픈 소스로 공개 중이지만 아직 공식 릴리즈 전 알파 단계임
  • 두 팀 모두 파이콘 2025 타이핑 서밋에서 각각의 비전, 목표, 접근법을 소개함

공통점

  • 모두 Rust로 개발되어 있으며, 증분 분석(Incremental Checking)을 지원함
  • 파이썬 코드의 AST 파싱에 ruff를 활용함
  • 커맨드라인 타입 검사와 LSP/IDE 통합 지원 등 개발 환경과의 연결성도 뛰어남

차이점 1: 속도

PyTorch 벤치마크

  • Ty가 Pyrefly보다 약 2~3배 더 빠르며, 둘 다 기존 mypy, pyright보다 10~20배 빠름
  • Pyrefly는 Pyre 대비 35배, mypy/pyright 대비 14배의 성능 향상을 목표로 함
  • Ty는 현 세대 타입 체커보다 한두 자릿수 빠른 성능을 목표로 설계됨

Django 벤치마크

  • Ty가 가장 빠르며, Pyrefly가 그 뒤를 이음
  • Pyright는 확연히 느린 결과를 보임

mypy 저장소 벤치마크

  • 비슷한 결과로 Ty가 가장 빠르고, Pyrefly가 근소한 차이로 뒤따름
  • mypy와 pyright는 현저히 느린 수행시간을 기록함

차이점 2: 타이핑 목표

Pyrefly

  • 코드에 별도 명시적 타입이 없어도 최대한 타입을 추론해 오류를 포착하는 전략 추구
  • 더욱 적극적인 타입 유추로 코드 안정성 극대화 지향

Ty

  • Gradual guarantee(점진적 보장) 원칙 적용
  • 작동하는 코드에서 명시적 타입 제거 시 타입 에러가 발생하지 않도록 설계됨
  • 타입 어노테이션 없이도 에러를 유발하지 않으며, 필요한 경우에만 추가 어노테이션 요구
  • 예: 명시적 타입이 없는 필드에 값을 할당해도 타입 에러를 일으키지 않고, 'Unknown | None' 등으로 처리

차이점 3: 증분 분석 방식

  • Pyrefly: 변경된 파일(모듈) 및 해당 종속 모듈만 재분석 (모듈 단위 증분화)
  • Ty: Rust의 Salsa 프레임워크를 활용해 함수 단위까지 세밀한 증분화
  • 모듈 단위는 속도가 충분하다는 판단, 함수 단위는 코드베이스가 복잡해질 수 있음(각 도구의 전략 차이)

차이점 4: 기능(타입 시스템 및 지원)

Pyrefly의 장점

  • 암묵적 타입 추론이 매우 강력함
  • 명시적 타입 없이도 함수 반환값, 딕셔너리, 리스트 등 복잡한 타입을 분석해 오류를 잡아냄
  • 제네릭 및 오버로드, 와일드카드 import 등 복잡한 타이핑 문제를 중점적으로 설계함
  • 제네릭 타입 추론 정확도가 Ty보다 더 높음

Ty의 특이점

  • “gradual guarantee”로 인해 명시적 타입 미부재 시에도 자유롭게 타입 변화 허용
  • 교차 타입(Intersection Types) 및 부정 타입(Negation Types) 등 혁신적 타입 시스템 지원
  • 오류 메시지가 매우 명확하고 직관적으로 설계됨
  • 리스트 등에 다양한 타입 할당을 자유롭게 허용하며, 타입의 'Unknown' 값을 시스템적으로 도입

한계점/알파 상태

  • 두 제품 모두 알파 단계로, 타입 추론 또는 기능 일부가 미완성 상태임
  • 예를 들어 Ty의 리스트 타입 추론 등 일부 결과는 완성도가 부족함

상세 기능 비교

암묵적 타입 추론

  • Pyrefly는 반환 타입, 컬렉션 객체 타입을 능동적으로 추론해 revealed type과 오류를 명확히 제시함
  • Ty는 inference가 부족하면 Unknown 또는 @Todo로 반환함

제네릭

  • Pyrefly와 Ty 모두 일반적인 제네릭 타입 문제를 잘 해결함
  • Pyrefly는 타입 파라미터 없이 생성된 인스턴스의 타입 해석에서 우위를 가짐
  • 두 체커 모두 공변/반공변성(covariance/contravariance) 문제에서는 mypy, pyright 대비 약점을 보임

오류 메시지

  • Ty는 concise하고 읽기 쉬운 에러 메시지에 중점을 둠
  • Pyrefly, mypy, pyright 대비 한눈에 이해하기 쉬운 메시지 제공

교차/부정 타입

  • Ty만이 교차 타입(&) 및 부정 타입(~) 을 지원해 아래와 같은 복잡한 타입 연산을 처리함

    • 예: WithX | Other 타입에서 'x' 속성이 있을 때, Ty는 WithX로 자동 분기
    • 예: 특정 서브클래스가 아닌 경우, MyClass & ~MySubclass로 타입 해석

  • 이러한 교차 및 부정 타입은 유형 이론에서 매우 진보적인 기능임

기타 고급 예시

  • Ty는 타입 시스템으로 디오판틴 방정식 등 복합 연산에도 활용 가능
  • 테스트가 마크다운 문서로 작성됨(참조: Astral ruff의 mdtest 리소스)

결론 및 전망

  • 파이썬 생태계에 압도적으로 빠르고, 새로운 타입 체커가 등장한 상황임
  • Ty는 점진적 타입 안정성을, Pyrefly는 능동적 타입 추론을 각각 주된 전략으로 삼음
  • 두 도구 모두 초창기라 향후 기능이 수렴하거나 진화할 여지가 많음
  • 공식 사이트에서 체험해볼 수 있으며, VSCode·Cursor 등 주요 에디터 플러그인도 제공함
  • 향후 Google 역시 Go 기반 타입 체커를 오픈 소싱할 예정이다는 소문이 있어, 파이썬 타입 분석 분야가 더욱 풍부해질 전망임

활용/참고

  • Pyrefly: pyrefly.org/sandbox
  • Ty: play.ty.dev
  • Astral의 Ty는 마크다운 기반 테스트 활용(자세한 경로는 ruff repo mdtest 참고)
  • 공식 문서, 에디터 플러그인, 패키지 설치 명령도 모두 제공됨
▲
q8840 7일전  [-]

ty는 사용하는 함수에 반환 타입이 안 적히면 무조건 unknown인가보군요, 저장해야지만 확인해주고
pyrefly는 안 적혀도 추론해주고, 타이핑 중에도 확인해줍니다

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

  • ty 개발자로서 ty와 pyrefly가 점점 주목받는 점에 대해 기뻐하는 입장 강조, 하지만 두 프로젝트 모두 아직 완성 단계가 아니라는 점을 다시 한 번 강조, 기능 미구현으로 인한 예시도 보고 있고 “이건 이상하다” 싶을 때 실은 아직 개발이 안 된 부분일 수도 있다는 점 이해 부탁, Python이 워낙 크고 다양한 언어라는 점 인지 필요

    • ty의 markdown 스타일 테스트 방식이 정말 마음에 든다는 의견, 테스트가 문서 역할까지 한다는 점이 굉장히 훌륭한 아이디어, 이 방식의 아이디어가 Rust의 문서화된 코드 예시에서 영감을 받은 건지 궁금함

    • 타입을 드러내는 부분을 @TODO로 표시한 점에서 웃음이 났지만 생각해보니 꽤 재치 있고 유용한 장치라는 감상

    • TypeScript 경험자로서, 타입 추론이나 타입 내로잉, 그리고 각 python 타입체커마다 거동이 다르다는 점 등 다양한 시도 자체에 흥미, 여전히 빠르고 신뢰할 만한 타입체커가 꼭 필요하지만 Python은 이런 면에서 크게 뒤처져 있는 느낌, 타입체커가 코드 생산성과 신뢰성을 높여야 한다고 생각하며 이런 프로젝트를 응원

    • Rust 개발자 관점에서 “러스트용 스크립트 언어”에 관한 질문, Rust와 문법이 잘 어울리면서도 Rust 타입을 네이티브로 임포트하고, 빠르게 컴파일/핫 리로드 가능한 언어 연구를 하는 네트워크가 있는지 궁금, 혹시 문법은 다르더라도 Python이 이 역할을 대신할 가능성에 대한 의견 요청, 관련 링크 첨부 https://news.ycombinator.com/item?id=44050222

  • Python 경험이 많지 않은 외부 시선에서의 의견, 타입 힌트 활용에 관심 있다면 Reddit 글 https://reddit.com/r/Python/… 참고 권장, 해당 글을 너무 진지하게 받아들이면 안 되지만, 아무리 좋은 타입 도구가 있다 해도 “좋은 관행”이 먼저라는 점을 강조, 예시로 Django나 Meta처럼 대규모 코드베이스에서 일관된 사용과 엄격한 타입체크가 가능하려면 개발자에게 권장되는 관습을 지키게 해야 한다는 점, Python은 C++처럼 너무 많은 기능과 관대한 런타임을 지녀 결국 일부만 제한적으로 써야 관리가 용이, 그러나 그 제한적 부분이 사람과 목적마다 다를 수 있다는 점 지적, Rust 개발자들이 더 엄격한 타입 시스템으로 Linux 커널 개발자들과 부딪히는 사례와도 비교

    • 해당 Reddit 글의 상위 댓글에서 “‘Any’를 쓰면 되니 논의가 무의미하다”는 식으로 일축, 실제 사례에서도 더 명확한 타입 선언이 있었으면 라이브러리 함수의 미래 변경이나 예기치 않은 입력값에 대해 미리 오류를 방지할 수 있다는 점, Python 코드가 유지성과 신뢰성을 지니려면 타입체크가 필수라는 강한 주장

    • Python 타입체크에 너무 많은 시간과 노력을 들이기보다는, 아예 더 적합한 정적 타입 언어로 이주한 뒤 interop 레이어로 필요한 부분만 Python을 쓰는 게 더 낫다는 결론, 언제나 가능한 건 아니지만 Python을 억지로 맞추는 데 시간 낭비가 심하다는 고민

    • Python의 강력하고 복잡한 기능들(예: meta class, descriptor, call 사용, object.new, 이름 맹글링, self.dict)은 너무 많은 마법이 들어가 코드 가독성을 크게 떨어뜨린다는 비판, 개인적으로 이런 기능들은 쓰지 않겠다는 선언

    • 실제로 해당 언어를 사용하지 않고 의견을 내는 점이 어디서 비롯된 것인지 궁금, Python 개발자는 실 사용을 하면서 깊이 이해하고 있는데 비사용자가 외부적 근거로 언어를 비판하는 점이 신기, contrived example(억지 사례)로 논쟁하는 분위기 지적

    • 다년간 Python을 써 온 경험자로서, 가장 큰 실수는 타입힌트와 타입체커를 아예 쓰지 않는 것이라는 단언

  • ty의 “점진적 보장(gradual guarantee)”에 대해 흥미로움, 즉 타입 애노테이션 하나를 제거해도 타입에러가 발생하지 않아야 한다는 점이 매력, 동적코드가 많은 Python에 가장 적합한 방식이라 생각

    • 점진적 타입은 코드 어디든 “any”(미확정 타입)가 들어가 있어도 경고조차 없는 구조, 중요한 코드까지도 완전한 타입 안정성을 보장하지 않아 제대로 보호받지 못하는 문제가 있었다는 회상, mypy 사용 경험에서도 이런 점이 치명적이었고 “이 파일은 완전정적으로 타입체크한다”는 선언 기능이 꼭 필요, “점진적” 타입은 오히려 anti-pattern에 가깝다는 개인 의견, 아예 “soft typing”이라는 용어가 더 적합할 수도 있다는 생각

    • 기존 코드 베이스에선 점진적 타입 외에는 방법이 없다는 입장, 실제로 mypy로 여러 레거시 Python 코드베이스에 타입힌트를 적용해본 경험상 “모듈 단위 opt-in”이 가장 합리적, pyrefly가 이걸 지원하지 않으면 실용도가 한계적일 듯, 다만 llm(대규모 언어모델) 코드제너레이션 각도라면 매우 빠르고 엄격한 타입체커의 유용성 존재

    • Typescript 초창기 도입과 유사함, 기존 대규모 프로젝트의 부드러운 온보딩을 중시, 점차 noImplicitAny 또는 strict 옵션을 모듈별로 키면서 최종적으로 강력한 타입검증 환경으로 변환 가능

    • Rust 프로그래머로서도 “점진적 보장”이 가장 합리적이라고 생각

    • 점진적 타입 지원 방식은 개인적으로 큰 매력이 없다고 밝힘, 애초에 Python의 동적 타입 시스템이 불안하므로 타입 애노테이션을 추가하는 목적의 절반은 그 오작동을 제어하기 위한 것, no-implicit-any나 strict 모드 선택 옵션이 반드시 필요하다는 바람

  • Astral의 툴링은 Python 생태계에 신선한 에너지를 주고 있지만 “긴 안목”에 대한 의문 제기, 앞으로 Python에 직접 통합될까? 5년 내 사라질까? 구독 기반 rug pull이 될까?

    • 비즈니스 소스 라이선스를 통해, Astral 툴을 사용하는 프로덕션 배포에는 기업용 구독 등을 필수로 유도할 가능성 큼, 현 제품은 해당 목적에 딱 맞는 것은 아니나, 벤처캐피털의 투자 관점상 유사한 모델로 갈 듯

    • 공식 발표에서 Astral은 툴 위에 다양한 서비스를 판매할 것임을 명시, 참고 링크 https://astral.sh/blog/announcing-astral-the-company-behind-ruff

    • 사실 이런 걱정은 Astral에만 해당하는 것이 아니라 모든 프로젝트에 적용되고, 특히 Facebook의 툴링은 시간이 지나면 관리되지 않는 “방치” 위험이 크다는 점 경고, 결국 사용자는 항상 스스로 리스크를 감수해야 한다는 조언

    • reddit의 한 이용자 의견 인용, VC 기본 모델은 결국 FAANG(빅테크)에 인수되길 바라거나 위협적으로 키워서 “acqui-hire”를 노리는 방식이라는 분석, Astral도 인수합병 후 인재유입 등의 시나리오 가능성

    • 최근 Astral이 대기업 전용 툴, 예를 들어 호스팅된 private 패키지 registry 등도 준비 중이라는 소문

  • “my_list = [1, 2, 3]” 예시에서 mypy, pyrefly, pyright는 my_list.append("foo")를 타입에러로 보지만, ty만 별도 명시 없이 허용하는 점을 두고, 실무에서는 항상 단일 타입 리스트 사용이 일반적이니 타입체커가 이를 전제로 삼아야 한다는 주장, Python이 허용한다고 해서 타입검증이 허술해져선 안 된다고 강력 비판, 초보 코드에 최적화된 정책 아니냐는 의견

    • ty 개발자로서 “아직 리스트 리터럴 타입 추론이 완성되지 않았다”는 해명, 현재는 단순히 list[Unknown]만 사용하고 Unknown이 Any와 유사한 gradual 타입이라 append가 다 허용되는 구조, 앞으로 더 정밀한 추론 계획이 있으며, 관련 논의 이슈 링크 첨부 https://github.com/astral-sh/ty/issues/168

    • 초보용 최적화라기보다는 레거시 코드 호환성을 위해 불가피하다는 의견, 대규모 비타입 코드에 타입체커를 도입하려면 기존 코드가 최대한 그대로 동작해야 부담이 적다는 현실 설명

    • “Python이 허용하는 것을 무시하고 개인적 의견으로 tooling을 만들자는 건 설득력 없다”는 반론

    • pyrefly 방식의 문제로 “대규모 무타입 코드베이스에선 전면 도입이 어렵다”는 점, 일일이 코드를 수정해야 하므로 조직에서 이 작업에 공감대가 없으면 쉽지 않다는 우려, 메타같이 내부적으로 강제할 수 있는 곳엔 괜찮지만 점진적 도입을 생각하면 ty처럼 더 관대한 방식이 현실적, 다만 개인적으로는 mixed 타입에 대해 경고해주는 도구를 선호한다는 복합적 입장

    • “실행 가능한 Python 코드라면 명시적으로 타입을 제한하지 않는 한 타입에러가 나지 않는 게 맞다”는 의견, 보다 엄격한 정적 서브셋을 원할 경우 타입 애노테이션을 직접 추가하면 된다는 입장

  • Pyrefly 방식이 타입추론을 더 강하게 추구해 실제로 대규모 타입 안정 코드에는 필요한 애노테이션이 훨씬 적어 초기 도입은 힘들어도 장기적으로 효율적이라는 경험자 의견, ty는 사실상 noImplicitAny 옵션이 해제된 상태

  • 진지한 notebook(live coding) 통합 지원이 되는 타입체커를 바라는 기대, 정적 검사로 긴 셀 실행 전에 오류를 미리 잡아주는 게 엄청난 효율

    • VSCode의 Jupyter notebook 활용 경험 묻기, pylance와 같은 타입체커 적용으로 실험 코드엔 오히려 방해가 되기도 한다는 지적

    • notebook 통합과 라이브 코딩 시 바로 피드백이 가능한 VSCode의 Language Server 경험을 권장, notebook 통합 및 라이브 인터랙티브 타입체크 요구를 해결해준다고 설명

  • Pyrefly의 설계는 Typescript의 타입추론 방식과 유사해서 개인적으로 더 합리적이라고 느끼며, 모듈 단위 점진적(incemental) 도입이 이상적이라고 평가, 함수 단위까지 들어가면 너무 세분화되어 오히려 필요 이상이라는 의견, 성능 측면에서도 모듈 단위면 충분하다고 판단

  • 프로젝트에 동적성이 많아도 Pyrefly처럼 더 강한 타입추론을 선호한다고 생각, 그로 인한 불편함이 있더라도 그 편을 들 거라는 입장

  • 현재는 basedpyright를 IDE와 CI 환경에서 쓰고 있고, 기본적으로 안정성 만족, mypy는 단순한 타입작업도 종종 실패하는 면에서 불호

답변달기