무슨 일이 있었냐면
VS Code에서 파이썬 코드를 짜다 보면 자동완성, 마우스를 올리면 뜨는 타입 정보, ‘정의로 이동’ 같은 기능을 당연하게 쓰잖아요. 이걸 뒤에서 처리해주는 게 마이크로소프트의 Pylance 확장이에요. 최근 마이크로소프트가 Pylance 저장소에 Type Server Protocol(TSP) 문서를 공개했어요. 한 줄로 말하면 “언어 서버와 타입 검사기가 서로 주고받는 대화 규칙”을 표준으로 만들겠다는 거예요.
이게 지금 중요한 이유는 파이썬 타입 검사기 판이 요즘 정말 뜨겁기 때문이에요. 오랫동안 mypy와 Pyright 두 강자가 버티고 있었는데, 최근 1~2년 사이 Meta의 Pyrefly, uv와 Ruff를 만든 Astral의 ty, Jedi 개발자가 만든 Zuban처럼 Rust로 짠 초고속 타입 검사기가 줄줄이 나왔어요. 선택지가 늘어난 건 좋은데, 이 도구들이 저마다 자동완성, 리팩터링, 호버 같은 편의 기능을 처음부터 다시 만들어야 한다는 문제가 있었어요.
LSP와 TSP는 뭐가 다른데요?
LSP(Language Server Protocol)부터 짚고 갈게요. LSP는 ‘에디터’와 ‘언어 지능’을 떼어놓은 프로토콜이에요. 예전에는 VS Code용, Vim용, Emacs용 파이썬 플러그인을 하나하나 따로 만들어야 했는데, LSP가 나온 뒤로는 언어 서버 하나만 만들면 모든 에디터에서 쓸 수 있게 됐어요. 에디터 M개 × 언어 N개 문제를 M + N 문제로 줄인 셈이죠.
TSP는 이 분리를 한 단계 더 안쪽으로 가져와요. 언어 서버 안을 들여다보면 사실 두 가지 일이 섞여 있거든요.
- 타입 평가: “이 변수 타입이 뭐지?”, “이 함수 호출이 타입상 맞나?”를 계산하는 무거운 두뇌
- 언어 기능: 그 결과로 자동완성 목록을 만들고, import를 자동으로 넣어주고, 심볼 이름을 바꿔주는 손발
어떻게 동작하나요
흐름을 그려보면 VS Code ⇄(LSP)⇄ Pylance ⇄(TSP)⇄ 타입 서버 순서예요.
사용자가 변수에 마우스를 올리면 VS Code가 LSP로 Pylance에 “여기 호버 정보 줘”라고 요청해요. Pylance는 TSP로 타입 서버에 “이 위치에 있는 노드의 타입이 뭐야?”, “이 심볼은 어디서 선언됐어?”, “이 import는 어떤 파일을 가리켜?” 같은 질문을 보내요. 그렇게 받은 답을 사람이 읽기 좋은 모양으로 다듬어서 화면에 보여주는 거예요.
여기서 눈여겨볼 점은 TSP가 “화면에 뭘 보여줄까”가 아니라 “타입 시스템이 알고 있는 사실” 수준의 질문을 다룬다는 거예요. 덕분에 타입 서버를 만드는 사람은 UI 기능을 신경 쓰지 않고 타입 추론의 정확도와 속도에만 집중할 수 있어요. 그리고 코드는 계속 바뀌니까 조금 전에 받은 답이 금방 낡은 정보가 되잖아요. 그래서 이런 프로토콜은 “어느 시점의 코드 기준으로 나온 답인지”를 맞추는 일도 함께 챙겨야 해요.
업계 흐름에서 보면
마이크로소프트의 입장을 보면 흥미로운 부분이 있어요. Pylance의 엔진인 Pyright는 오픈소스지만, Pylance는 클로즈드 소스이고 라이선스상 마이크로소프트의 공식 VS Code에서만 쓸 수 있거든요. 그래서 Cursor 같은 VS Code 포크 에디터에서는 basedpyright 같은 대안을 쓰는 경우가 많았어요.
TSP는 반대쪽으로 문을 연 거예요. “편의 기능은 우리가 잘 만들어 놨으니 타입 엔진은 원하는 걸 꽂아 쓰세요”라는 메시지로 읽혀요. Pyrefly나 ty 같은 빠른 엔진이 Pylance의 성숙한 리팩터링, 자동 import, 노트북 지원과 합쳐지면 사용자 입장에서는 꽤 좋은 조합이 될 수 있어요.
물론 걱정되는 부분도 있어요. 프로토콜이 Pyright 내부 구조를 너무 닮았다면 다른 타입 검사기들은 그 모양에 억지로 맞춰야 할 수 있거든요. 결국 “사용자가 만나는 앞단은 Pylance가 쥔다”는 구도가 굳어질 수 있다는 시각도 있고요. LSP는 마이크로소프트가 주도했어도 충분히 중립적이었기 때문에 성공했어요. TSP도 커뮤니티가 얼마나 참여하느냐에 따라 앞날이 갈릴 거예요.
한국 개발자에게는
아직은 도구 제작자를 위한 스펙에 가까워서 당장 설정을 바꿀 일은 없어요. 그래도 이런 변화는 머지않아 체감하실 수 있을 거예요.
먼저 대형 파이썬 모노레포에서 Pylance가 느려서 고생하셨던 분들께는 반가운 소식이에요. 엔진만 Rust 기반 검사기로 바꿔서 같은 편의 기능을 더 빠르게 쓸 수 있는 길이 열리거든요.
CI는 mypy, 에디터는 Pyright라서 타입 오류가 미묘하게 다르게 나와 헷갈렸던 경험도 있으시죠? 엔진을 하나로 통일할 수 있으면 이런 불일치도 줄어들어요.
언어 툴링에 관심 있는 분이라면 이 문서를 교과서처럼 읽어보셔도 좋아요. 언어 서버가 안에서 어떤 질문을 주고받는지 보면 타입 검사기가 어떤 식으로 생각하는지 감이 오거든요.
마무리
TSP는 LSP가 에디터와 언어를 떼어놓았던 것처럼, 언어 기능과 타입 엔진을 떼어놓으려는 시도예요. 파이썬 타입 검사기가 쏟아지는 지금, ‘엔진을 바꿔 끼우는 Pylance’가 정말 현실이 될지 지켜볼 만해요.
여러분 팀은 지금 어떤 타입 검사기를 쓰고 계세요? Rust 기반 검사기로 갈아탈 생각이 있으신가요, 아니면 아직 타입 힌트 도입부터 고민 중이신가요?
🔗 출처: Hacker News