“타입스크립트가 10배 빨라집니다” 그리고 불이 났다

자바스크립트에 정적 타입 문법을 추가한 ‘타입스크립트’가 네이티브 언어로 전환된다.

타입스크립트 수석 설계자인 아네르스 하일스베르 마이크로소프트 테크니컬 펠로우는 지난 11일 블로그를 통해 타입스크립트 성능을 근본적으로 개선하기 위해 컴파일러와 도구의 네이티브 이식 작업을 시작했다고 발표했다.

그는 “타입스크립트의 핵심 가치 제안은 뛰어난 개발자 경험”이라며 “코드베이스가 커질수록 타입스크리트 자체의 가치는 커지지만 이경우 가장 큰 코드베이스까지 확장할 수 없었다”고 설명했다.

그는 “대규모 프로젝트에서 작업하는 개발자는 긴 로드 및 확인 시간을 경험하고, 합리적인 편집기 시작 시간과 소스코드 전체 보기 중에서 선택해야 한다”며 “개발자는 자신있게 변수 이름을 바꾸고, 특정 함수에 대한 모든 참조를 찾고, 코드베이스를 쉽게 탐색하고, 지연 없이 모든 작업을 수행할 수 있을 때 좋아한다”고 덧붙였다.

그에 따르면, 마이크로소프트는 타입스크립트 컴파일러 도구의 네이티브 포팅 작업을 시작했다.

기계어 수준의 언어로 작성해 코드편집기에서 시작 시간을 크게 개선하고, 빌드 시간을 10배 단축하며, 메모리 사용량을 상당히 줄일 수 있게 된다고 안데르스 하일스버그는 설명했다. 그는 현재 코드베이스를 포팅해 2025년 중반까지 명령줄 유형 검사가 가능한 네이티브 구현의 미리보기를 선보일 것으로 예상했다. 연말까지 프로젝트를 위한 완벽한 기능을 갖춘 솔루션과 언어 서비스를 제공할 예정이라고 덧붙였다.

새로운 타입스크립트 컴파일러와 도구는 구글에서 개발한 프로그래밍 언어 ‘고(Go)’로 만들어진다. 마이크로소프트는 고 코드로 이뤄진 새로운 작업 리포지토리를 공유했다.

마이크로소프트는 현재의 자바스크립트 기반의 타입스크립트 5.8 버전과 곧 출시될 5.9 버전까지 기존 코드베이스를 유지하고, 타입스크립트 6 버전에서 향후 네이티브 코드베이스에 맞춰 일부 지원 중단과 중단 변경 사항을 도입한다. 새로운 네이티브 컴파일러와 도구로 이식된 버전은 타입스크립트7으로 불린다. 고 코드베이스 기반인 타입스크립트7 버전이 현재의 수준과 동등해지면 출시될 예정이다. 타입스크립트7 이후 성숙도가 충분히 올라갈 때까지 자바스크립트 코드베이스의 6.X 버전을 유지한다고 한다.

타입스크립트는 자바스크립트 엔진과 언어를 사용하면서 객체지향언어처럼 정적 타입을 활용할 수 있다. 2012년부터 만들어지기 시작해 2014년 1.0 버전으로 오픈소스로 공개됐다.

타입스크립트는 웹 언어로 클라이언트와 서버 애플리케이션을 개발할 수 있어 큰 인기를 끌고 있다. 하지만 코드 규모가 커지면 편집기 고급 기능을 활용해 작업할 때 전반적인 속도가 느려지는 문제가 있다.

특히 최근 들어 생성형 인공지능(AI) 기반의 코드 어시스턴트 기능을 코드 편집기에서 적극 활용하게 되면서 타입스크립트의 문제점이 커졌다.

일례로 비주얼스튜디오코드(VS코드)는 단순한 에디터면서 신택스 지정, 코드 자동완성, 코드 추천 등의 인텔리전스 기능을 확장 설치로 이용할 수 있다. 여기에 깃허브 코파일럿, 커서 등 다양한 생성형 AI 기반 코드 어시스턴트 기능도 붙여 이용할 수 있다.

VS코드에서 AI 기능을 이용하려면 프로그래밍 언어별 ‘랭귀지서버(LS)’를 연결해 언어 서비스를 받아야 한다. 편집기와 LS 간 정보 교환에 활용되는 프로토콜이 ‘랭귀지서버프로토콜(LSP)’이다. 타입스크립트도 LS와 LSP를 활용해 AI 보조 기능을 이용할 수 있다.

그러나 타입스크립트의 경우 AI 기능을 이용할 때마다 LS에서 자바스크립트 코드 전체를 읽고 컴파일하게 돼 긴 코드베이스 환경에서 AI 기능이 빠르게 작동하기 힘들다.

아네르스 하일스베르가 네이티브 전환 계획을 밝히며 편집기 성능과 AI 도구를 언급한 이유다. 만약 자바스크립트 대신 기계어에 가까운 언어로 타입스크립트 백엔드를 대체하면 대규모 코드베이스에서 나타난 문제점을 해결할 수 있다.

그에 의하면, VS코드에서 네이티브 타입스크립트를 활용할 경우 전체 프로젝트를 로드하는 데 걸리는 시간이 9.6초에서 1.2초로 줄어든다. 깃허브의 150만5000라인 규모의 코드베이스를 VS코드에서 이용할 때 현재 77.8초에서 7.5초로 10배 이상 로드 성능이 빨라진다.

하일스베르는 “모든 언어 서비스 작업(완성 목록, 빠른 정보, 정의로 이동, 모든 참조 찾기)에 대한 편집기 응답성도 상당한 속도 향상을 보일 것”이라며 “다른 언어와 구현을 더 잘 일치시키기 위해 오랜 인프라 작업 항목인 LSP로 이동할 것”이라고 밝혔다.

C# 창시자의 ‘고’ 채택에 커뮤니티는 “왜?”

타입스크립트에 고 백엔드를 도입한다는 발표 후 반응이 폭발했다. 각종 커뮤니티 게시판의 관련 포스트와 토론 스레드에 ‘불’ 이모지가 연이어 붙었다.

반응은 세갈래로 나뉜다. 일단 타입스크립트의 편집기 성능이 획기적으로 개선된다는 점에서 환영하는 입장이다.

다음은 왜 ‘고’를 백엔드 언어로 택했느냐는 반응이다. 이는 다시 ‘왜 러스트가 아니냐’와 ‘왜 C#이 아니냐’로 나눠진다.

특히 C#의 창시자인 아네르스 하일스베르가 ‘고’를 택했다고 발표했다는 것 자체에 실망감을 표한 반응이 다수를 이뤘다. 지난 수년 사이 마이크로소프트의 닷넷 플랫폼 기반 프로그래밍 언어 투자가 축소되고, 커뮤니티도 방치되고 있다는 불만이 누적돼왔다. 커뮤니티 내부의 불만이 쌓여있던 와중에 C# 닷넷의 창시자가 경쟁 플랫폼을 선택했다고 하자 불만이 격하게 표출된 것이다.

마이크로소프트 타입스크립트팀의 라이언 카바노프는 깃허브 F&Q에서 왜 ‘고’를 선택했는지 설명했다. 그는 “의미론과 코드 구조 측면에서 새로운 코드베이스를 가능한 한 호환되게 유지해야 한다는 것이 가장 중요한 측면”이라며 “구조적으로 유사한 코드베이스를 허용하는 언어는 두 코드베이스 간 변경 사항을 쉽게 이식할 수 있기 때문에 코드를 변경하는 모든 사람에게 상당한 이점을 제공한다”고 밝혔다.

이어 “고는 관용적인 언어로 타입스크립트 코드베이스의 기존 코딩 패턴과 매우 유사해 이식 작업이 훨씬 더 수월하다”며 “또한 고는 전체 코드베이스가 메모리 관리에 지속적으로 관여할 필요없이 메모리 레이아웃과 할당을 탁월하게 제어한다”고 덧붙였다.

타입스크립트의 네이티브 이식에서 여러 언어 가운데 고가 가장 목표 달성에 유리하고 성능 개선에서 우월했다는 것이다.

C# 창시자의 설명 “C#도 좋지만 호환성, 메모리 관리, 그래프 처리 때문에 고 선택”

이후에도 유사한 질문과 불만제기가 이어지자 아네르스 하일스베르가 직접 해명했다.

그는 “고로 이식하기로 한 결정은 실용적인 엔지니어링 선택”이라며 “우리의 초점은 사용된 언어와 관계없이 최상의 결과를 달성하는 것이었다”고 밝혔다.

이어 “타입스크립트 컴파일러의 고로 이동은 기존 자바스크립트 기반 코드베이스와 구조적 호환성, 메모리 관리의 용이성, 복잡한 그래프 처리 등을 효율적으로 관리할 수 있는 능력 같은 특정 기술적 요구사항의 영향 때문”이라며 “수많은 언어를 평가하고 C#을 포함한 여러 프로토타입을 만든 후 고가 최적의 선택으로 결정된 것”이라고 했다.

그러면서 “C#에서 컴파일러를 처음부터 재설계할 수 있고 효과도 있었을 것”이라며 “하지만 이것은 컴파일러 재설계가 아니었고, 타입스크립트에서 고로 이동은 훨씬 더 자동화가 가능했으며, 매핑에서 일대일로 더 많이 이뤄졌다”고 덧붙였다.

또한 “이 결정이 C#과 닷넷에 대한 우리의 깊고 지속적인 투자를 약화시키지 않는다”며 “마이크로소프트의 서비스와 제품 대부분은 타의 추종을 불허하는 생산성, 강력한 생태계, 강력한 확장성으로 인해 C#과 닷넷에 크게 의존하며, C#은 빠르고 유지 관리 가능하며 확장 가능한 개발을 요구하는 시나리오에서 뛰어나고 중요한 시스템과 수많은 내부 및 외부 마이크로소프트 솔루션을 구동한다”고 강조했다.

그는 이번 선택이 정치적 고민보다 철저한 실용주의에 입각해 이뤄졌다는 점을 밝혔다. 마이크로소프트가 내부 정치적 토론에서 닷넷과 C#을 포기한 게 아니란 것이다.

그는 “현실적으로 보면, 마이크로소프트가 고를 사용해 타입스크립트 컴파일러를 작성하는 건 몇년 전만 해도 불가능하거나 상상조차 할 수 없었다”며 “지난 수십년 간 마이크로소프트는 오픈소스 소프트웨어에 대한 강력하고 지속적인 헌신을 보였으며 무엇보다 개발자 생산성과 커뮤니티 협업을 우선시했다”고 설명했다.

이어 “당사의 목표는 내부 정치나 좁은 제약에 얽매이지 않고 개발자에게 최상의 도구를 제공하는 것”이라며 “각 특정 작업에 적합한 도구를 선택할 수 있는 이런 자유는 궁극적으로 전체 개발자 커뮤니티에 이롭게 작용해 혁신, 효율성, 개선된 결과를 촉진한다”고 강조했다.

타입스크립트에 대한 마이크로소프트의 결정에 너무 많은 토론이 진행되자 깃허브 F&Q 페이지의 댓글 기능은 중단됐다. 래딧, 해커뉴스 등에선 여전히 이번 타입스크립트 네이티브 전환에 대한 결렬한 토론이 이어지고 있다.

글. 바이라인네트워크

<김우용 기자>yong2@byline.network