2026년 10월 27일, 마이크로소프트가 Type Server Protocol(이하 TSP)을 공식 발표했습니다. 이번 아키텍처 개편을 통해 지난 10년간 유지되어 온 Pyright가 Pylance 내부에서 교체 가능한 모듈로 분리되었으며, Meta의 오픈소스 타입 검사기인 Pyrefly가 최초의 외부 백엔드로 완전히 연동되었습니다.
이번 변화를 통해 언어 서버 프로토콜(LSP) 상단에 타입 의미론을 전담하는 새로운 프로토콜 계층이 마련되었습니다. 코드 자동완성, 정의 이동, 인라인 힌트가 하위 소비자로 재배치되면서, 타입 시스템은 독립적인 의미론적 질의 서비스로 거듭났습니다. 이에 따라 핵심 활용 대상 역시 자동화 분석 도구와 AI 코드 에이전트로 넓어졌습니다.
10년 핵심 아키텍처 분리: Pyright 결합에서 벗어난 Pylance
이전 설계에서 Pylance는 Pyright와 강하게 결합되어 있었습니다. Pyright가 문법 트리를 순회하며 타입 추론을 계산하고, Pylance는 외부 인터페이스를 맡아 VS Code 내 자동완성, 탐색, 환경 관리를 처리했습니다. 이러한 밀결합은 별도 설정 없는 안정성을 제공했지만, 밑단에 위치한 타입 분석 엔진의 교체를 원천 차단했습니다.
TSP는 이러한 모놀리식 구조를 해체합니다. Pylance는 기존의 파이썬 인텔리전스 기능과 Copilot 연동을 계속 유지하되, 진단과 타입 계산은 독립 서비스로 추상화되었습니다. Pyright는 기본 검사기 옵션으로 물러나며, TSP 사양을 준수하는 다른 엔진이라면 무엇이든 손쉽게 교체할 수 있습니다.
이러한 분리 덕분에 개발자는 검사기를 바꾸기 위해 이미 잘 갖춰진 개발 환경을 포기할 필요가 없어졌습니다. 독립된 서드파티 플러그인을 직접 사용할 경우 가상환경 관리나 Copilot과의 유기적인 연동이 깨지기 쉽지만, Pylance가 TSP를 통해 연결을 중계하므로 기존 워크플로를 온전히 유지하면서 강력한 연산 백엔드를 활용할 수 있습니다.
초당 180만 행 처리 속도: 초대형 모노레포를 정조준한 Meta의 Pyrefly
Meta는 TSP의 첫 번째 외부 파트너로 참여하여 사양을 완벽히 충족하는 Pyrefly를 선보였습니다. 벤치마크 결과에 따르면 Pyrefly는 초당 180만 행에 달하는 타입 검사 처리량을 기록했습니다. 수백만 행 규모의 모노레포 환경에서도 전체 검사 시간이 분 단위에서 수 초 단위로 단축되어 에디터 프리징과 지연 현상이 말끔히 사라졌습니다.
이 같은 성능은 Instagram을 비롯한 대규모 파이썬 시스템을 수년간 운영해 온 Meta의 엔지니어링 역량에 뿌리를 두고 있습니다. Meta는 2017년부터 대규모 동적 언어의 정적 타입 적용을 지속적으로 탐구해 왔습니다. Pyrefly는 단순한 개념 증명용 프로젝트가 아니라 철저한 프로덕션 검증을 거친 결과물입니다.
실제 개발 환경에서 유용하게 쓰일 수 있도록 Meta는 핵심 과학 계산 라이브러리의 타입 선언 작업도 심도 있게 진행했습니다. 데이터에 따르면 NumPy의 타입 완성도는 90%에 육박하며, pandas의 공개 API 또한 완벽한 타입 정의를 갖추었습니다. 동적인 외부 서드파티 라이브러리 역시 정밀한 정적 추론이 가능해져, 명시적 타입 주석이 없는 코드 블록에서도 확실한 타입을 이끌어냅니다.
스냅샷과 다중 채널: 자동화 도구 시대를 여는 TSP 규격
규격 측면에서 TSP는 LSP 위에 구축되었으며, 동일한 JSON-RPC 통신 방식을 채택하고 있습니다. 타입 서버는 백그라운드에서 워크스페이스 상태를 유지하면서 버전 협상, 탐색 경로, 모듈 임포트 해석을 중앙 집중식으로 제어합니다. 규격과 TypeScript 인터페이스 정의는 microsoft/pylance-release 저장소의 docs/tsp 경로에 오픈소스로 공개되어 있습니다.
0.4.1 버전 규격은 스냅샷 기반의 타입 계산 결과와 다중 연결 읽기 전용 채널이라는 두 가지 핵심 구조를 제시합니다. 에디터 렌더링에는 단방향 진단 결과만으로 충분하지만, 자동화 분석 도구는 코드 상태를 동시에 읽어 들여야 합니다. 다중 채널 구조 덕분에 외부 프로세스는 메인 에디터의 편집 작업을 방해하지 않고 타입 데이터를 병렬로 읽을 수 있습니다.
프로토콜은 크게 세 가지 핵심 질의 인터페이스를 제공합니다. 추론된 타입(computed), 선언된 타입(declared), 기대되는 타입(expected)입니다. 이 세 가지 API는 복잡한 추상 문법 트리(AST)를 정형화된 데이터로 평탄화하여, 외부 도구가 가벼운 RPC 호출만으로 변수 제약 조건을 파악할 수 있도록 돕습니다. 코드 맥락이 명확한 필드로 분해되므로 자동화 에이전트가 직접 AST를 파싱하지 않고도 타입 제약을 곧바로 확인할 수 있습니다.
간편한 전환: VS Code에서 Pyrefly 연동하기
일반 개발자 관점에서 새로운 백엔드를 적용하는 과정은 매우 간단합니다. Pylance 확장 프로그램 2026.4.1 이상, Pyrefly 0.60.0 이상의 버전이 필요합니다. 이 두 버전 기준을 충족하면 프로토콜 핸드셰이크가 구성되어 읽기 전용 다중 채널 메커니즘이 안정적으로 동작합니다.
워크스페이스나 가상환경에 Pyrefly가 설치되어 있거나 설정 파일에 [tool.pyrefly]가 포함되어 있다면, VS Code가 이를 자동으로 감지하여 안내 창을 띄웁니다. 승인 버튼을 누르면 에디터의 진단 소스가 Pyrefly로 매끄럽게 교체됩니다.
그림 1: 워크스페이스 환경에 Pyrefly가 설치되면 VS Code가 타입 진단 소스로 사용할 것인지 묻는 알림을 띄웁니다. 출처: devblogs.microsoft.com
설정 메뉴에서 수동으로 선택할 수도 있습니다. Python › Analysis: Diagnostics Source 설정 항목에는 세 가지 옵션이 제공됩니다. Pylance, Pylance + Pyright, 그리고 Pylance + Pyrefly입니다. 이 설계를 통해 필요할 때마다 기본 엔진으로 자유롭게 되돌릴 수 있습니다.
그림 2: Python 확장 설정에서 Diagnostics Source를 구성하여 Pylance 내에서 사용할 검사기를 선택하는 화면. 출처: devblogs.microsoft.com
설정을 마치면 VS Code 하단 상태 표시줄에 현재 적용 중인 진단 소스로 Diagnostics Source: Pylance + Pyrefly가 표시됩니다. 이제 무거운 타입 검사 작업은 Pyrefly가 전담하며, 상위 인터페이스 조작과 단축키 환경은 Pylance가 변함없이 제공합니다.
그림 3: 하단 상태 표시줄에 활성화된 진단 백엔드가 표시되어 Pylance와 Pyrefly가 정상적으로 협업하고 있음을 보여줍니다. 출처: devblogs.microsoft.com
생태계 판도 재편: AI 인프라로 진화하는 타입 서비스
단순히 에디터 화면에 문법 오류 물결선을 긋는 일만이 목적이었다면, 마이크로소프트가 10년간 다듬어 온 Pyright를 분리할 이유는 없었을 것입니다. 이번 개편의 진정한 원동력은 대형 언어 모델(LLM) 코딩 환경이 요구하는 정밀하고 일관된 코드 맥락 정보에서 비롯되었습니다. Copilot 코드 완성, 대화형 코딩 도구, 모델 컨텍스트 프로토콜(MCP) 도구 모두 탄탄하고 안정적인 타입 의미론을 필요로 합니다.
텍스트 매칭에만 의존하는 대형 언어 모델은 복잡한 프로젝트의 동적 디스패치 구조를 명확히 파악하기 어렵습니다. 타입 서버가 프로젝트의 심볼 의존성을 그래프 형태로 미리 연산하고 스냅샷 API로 제공함으로써, 코드 에이전트는 정형화된 질의를 통해 매개변수 타입과 제약 조건을 검증하고 코드 생성 오류를 크게 낮출 수 있습니다.
마이크로소프트는 개방형 프로토콜을 통해 생태계의 중심 입지를 확보했습니다. 타입 질의 표준을 확립함으로써 지능형 도구와 코드베이스가 소통하는 의미론적 접점을 선점한 것입니다. 타입 분석이 서비스 형태로 발전하면서 차세대 AI 개발 도구 생태계의 핵심 기반이 새로이 재편되고 있습니다.
참고 링크:
- 마이크로소프트 공식 파이썬 블로그 발표문
- Pyrefly 공식 기술 문서 및 벤치마크 보고서
