갑자기 타입 체커가 왜 이렇게 많아졌을까요
파이썬 좀 만져본 분이라면 mypy라는 도구를 한 번쯤 들어보셨을 거예요. 파이썬은 원래 변수에 타입을 안 적어도 되는 언어잖아요. x = 3 이렇게만 써도 알아서 정수로 인식하거든요. 편하긴 한데, 프로젝트가 커지면 "이 함수에 문자열을 넣어야 하나 숫자를 넣어야 하나" 헷갈리고, 엉뚱한 타입을 넣어서 런타임에 펑 터지는 일이 생겨요.
그래서 등장한 게 타입 힌트예요. def add(a: int, b: int) -> int: 처럼 "이 함수는 정수를 받아서 정수를 돌려줍니다" 하고 미리 적어두는 거죠. 그런데 적어두기만 하면 파이썬이 검사를 안 해줘요. 실제로 맞는지 확인해주는 별도의 검사기, 그게 바로 타입 체커입니다.
문제는 요즘 이 타입 체커가 한두 개가 아니라는 거예요. 이번 글의 출발점이 된 질문이 딱 그거거든요. "이제 우리가 다섯 개나 돌려야 하는 거냐?"
다섯 개의 정체
현재 실무에서 마주칠 수 있는 타입 체커를 정리해보면 이래요.
- mypy: 원조예요. 파이썬 타입 힌트(PEP 484)를 만든 사람들이 직접 만든 레퍼런스 같은 존재죠.
- Pyright: 마이크로소프트가 만들었어요. VS Code의 파이썬 확장(Pylance)이 내부에서 이걸 써요. 그래서 알게 모르게 가장 많이 쓰이는 체커이기도 하고, 속도도 빠릅니다.
- Pyre / Pyrefly: 메타(페이스북)가 만든 거예요. Pyre가 구버전이고, 이걸 러스트(Rust)로 새로 짠 게 Pyrefly예요.
- ty:
Ruff라는 초고속 린터를 만든 Astral이라는 회사가 내놓은 신상이에요. 역시 러스트로 만들어서 엄청 빨라요.
그런데 정말 다섯 개를 다 돌려야 할까요
핵심은 여기예요. 이 글이 던지는 진짜 메시지는 "여러 개를 돌릴 필요가 없어야 정상" 이라는 거예요.
왜냐면 파이썬 타입에는 이미 공식 명세(typing spec) 가 있거든요. "타입 힌트는 이런 상황에서 이렇게 해석해야 한다"는 규칙집이 정해져 있고, 그걸 검증하는 적합성 테스트(conformance test suite) 도 있어요. 이론적으로는 모든 체커가 같은 코드를 보면 같은 결론을 내야 한다는 뜻이에요.
하지만 현실은 도구마다 해석이 조금씩 달라요. mypy는 통과시키는데 Pyright는 에러를 뱉고, ty는 또 다른 소리를 하는 식이죠. 그래서 라이브러리를 만드는 사람 입장에선 "내 코드가 모든 체커에서 깨끗하게 통과하나?"를 신경 쓰느라 여러 개를 돌리게 되는 거예요. 이건 도구가 좋아서가 아니라, 명세가 아직 완벽히 합의되지 않아서 생기는 비용이에요.
한국 개발자에게 주는 시사점
실무에서는 우선 하나만 잘 고르면 됩니다. VS Code 쓰신다면 이미 Pyright가 돌아가고 있을 거고, 여기에 CI에서 mypy 정도 추가하면 충분해요. 다섯 개 다 돌리는 건 라이브러리 메인테이너의 고민이지, 일반 서비스 개발자의 일은 아니에요.
다만 신상 도구들의 속도는 한 번 체험해볼 가치가 있어요. 수십만 줄짜리 모노레포에서 mypy가 몇 분씩 걸리던 게 ty로 바꾸면 몇 초로 줄기도 하거든요. 팀 빌드 시간이 길어서 고민이라면 Pyrefly나 ty를 사이드로 깔아서 비교해보세요.
그리고 한 가지 더. 도구를 바꿔도 "타입 힌트를 제대로 써둔 코드"는 그대로 자산으로 남아요. 어떤 체커를 쓰든 결국 같은 명세를 보거든요. 그러니 도구 전쟁에 너무 휘둘리지 말고, 일단 함수 시그니처에 타입부터 꼼꼼히 달아두는 습관이 제일 남는 장사예요.
마무리
타입 체커가 다섯 개로 늘어난 건 파이썬 타입 생태계가 그만큼 뜨겁다는 증거이자, 아직 표준이 완전히 자리 잡지 못했다는 신호이기도 해요. 결국엔 명세가 더 단단해지면서 "아무거나 써도 같은 결과"로 수렴할 거예요.
여러분은 지금 어떤 체커를 쓰고 계세요? mypy를 고수하시나요, 아니면 러스트 기반 신상으로 갈아타셨나요?
🔗 출처: Hacker News
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공