대기 시간이 사라질 때 무슨 일이 벌어지는가
프론트엔드 개발자의 하루를 떠올려보면, 생각보다 많은 시간이 '기다림'으로 소비된다. 저장 후 타입 에러를 확인하기까지의 2~3초, 대형 스프레드시트를 스크롤할 때마다 발생하는 1~2초의 렌더링 지연. 숫자만 보면 사소해 보이지만, 이 대기 시간은 개발자의 플로우 상태를 끊고, 사용자의 신뢰를 조금씩 갉아먹는다. 최근 공개된 두 가지 기술 업데이트—TypeScript 7.0 Beta와 Canvas 렌더링 최적화 사례—는 각각 다른 레이어에서 이 문제를 정면으로 건드리고 있다.
TypeScript 7.0: 컴파일러를 Go로 다시 쓴다는 것의 의미
Microsoft가 공개한 TypeScript 7.0 Beta(출처: GeekNews)의 핵심은 단순하다. 기존 JavaScript로 구현된 컴파일러를 Go로 네이티브 포팅했고, 결과적으로 TypeScript 6.0 대비 약 10배의 성능 향상을 달성했다. 여기서 중요한 뉘앙스가 있다—이건 '재작성(rewrite)'이 아니라 '포팅(porting)'이다. 타입 체크 로직의 구조적 동일성을 유지하면서 실행 엔진만 교체했기 때문에, 기존 코드베이스와의 호환성 리스크를 최소화했다.
성능 향상의 메커니즘도 주목할 만하다. 단순히 언어를 바꾼 것이 아니라, 파싱·타입 체크·emit 각 단계를 병렬화했다. --checkers, --builders 옵션으로 워커 수를 조절할 수 있어 모노레포나 대형 코드베이스에서 특히 효과적이다. Bloomberg, Figma, Notion, Vercel 등 수백만 라인 규모의 코드베이스에서 이미 사전 테스트를 마쳤다는 점도 신뢰를 더한다.
CLI를 넘어 에디터까지—DX가 바뀌는 실제 지점
10배 빠른 컴파일 속도가 주는 체감은 단순히 빌드 시간 단축이 아니다. VS Code용 TypeScript Native Preview 확장을 통해 에디터 내 타입 체크, auto-import, hover, inlay hints까지 동일한 성능 개선이 적용된다. 즉, 코드를 치는 매 순간의 피드백 루프가 빨라진다는 뜻이다.
현재 npm install -D @typescript/native-preview@beta로 설치하고 tsc 대신 tsgo를 실행하는 방식으로 즉시 써볼 수 있다. 다만 주의할 점이 있다. 안정적인 programmatic API는 TypeScript 7.1 이후를 목표로 하고 있어, TypeScript API에 직접 의존하는 도구나 플러그인을 운영 중인 팀이라면 전환 타이밍을 신중하게 잡아야 한다. strict, rootDir, types 등 일부 기본값도 변경됐기 때문에, 기존 프로젝트는 TS6로 먼저 정리한 뒤 마이그레이션하는 경로를 권장한다.
Canvas 95% 개선기—측정이 먼저, 최적화는 그 다음
한편 Velog에 공개된 Canvas 스크롤 지연 95% 개선 사례(출처: velog/@sonyk9919)는 프론트엔드 성능 최적화의 교과서적 흐름을 잘 보여준다. xlsx 파일을 브라우저에서 열람하는 스프레드시트 서비스에서, 벡터가 많은 문서를 스크롤할 때 1~2초의 지연이 발생했다. 원인은 명확했다—스크롤 이벤트마다 뷰포트 내 모든 셀의 테두리, 텍스트, 배경을 처음부터 다시 그리고 있었다.
1단계 최적화는 Path2D 배치 처리였다. 셀마다 개별 draw 호출을 하던 구조를, 작업 단위로 묶어 한 번에 stroke/fill하는 방식으로 변경했다. 결과는 1,000~2,000ms에서 600~800ms로 의미 있는 개선이었지만, 근본 문제—스크롤할 때마다 전체를 재연산한다는 구조—는 그대로였다.
OffscreenCanvas 캐싱—'연산을 줄이는 것'과 '연산을 안 하는 것'의 차이
2단계는 접근 방식 자체를 바꿨다. OffscreenCanvas를 캐시 레이어로 활용한 것이다. 한 번 그린 셀은 화면에 표시되지 않는 별도 캔버스에 저장해두고, 같은 셀이 다시 뷰포트에 들어오면 재연산 없이 복사만 한다. draw 비용을 줄이는 것이 아니라 draw 자체를 생략하는 전략이다.
메모리 문제도 영리하게 해결했다. 전체 문서 크기로 단일 OffscreenCanvas를 만들면 브라우저 메모리 한계로 크래시가 발생한다. 대신 문서를 뷰포트 크기 기준으로 분할하고, 각 영역마다 OffscreenCanvas를 1:1로 대응시켜 동적 생성하는 방식을 택했다. 최종 수치는 스크롤 지연 50~100ms—초기 대비 95% 이상 개선이다.
줌 레벨 변경 시에는 픽셀 기반 렌더링 특성상 캐시 전체를 무효화하고 재생성해야 한다는 점, 그리고 무한히 쌓이는 캐시에 대한 LRU 전략이 다음 과제로 남아 있다는 점도 솔직하게 공유하고 있어 실무 참고 가치가 높다.
두 사례가 함께 가리키는 것—DX와 UX는 같은 문제다
표면적으로 TypeScript 7.0과 Canvas 최적화는 전혀 다른 레이어의 이야기처럼 보인다. 하나는 개발 도구의 성능이고, 다른 하나는 런타임 렌더링 성능이다. 하지만 두 사례가 공유하는 본질은 동일하다—대기 시간을 없애면 사람이 집중할 수 있다는 것.
컴파일러가 10배 빨라지면 개발자는 타입 에러 피드백을 기다리는 대신 다음 코드를 생각할 수 있다. 스크롤 지연이 95% 줄어들면 사용자는 데이터를 탐색하는 데 집중할 수 있다. 이 두 가지 집중의 회복이 결국 Core Web Vitals 숫자를 올리고, 팀의 개발 사이클을 단축시키고, 제품이 사용자에게 전달하는 신뢰를 쌓는다.
지금 팀이 취해야 할 행동
TypeScript 7.0은 지금 당장 @typescript/native-preview@beta로 CI 파이프라인에서 병렬 실행해보며 성능 체감을 확인할 수 있다. programmatic API에 의존하는 도구가 없는 팀이라면 에디터 확장도 함께 테스트해볼 만하다. Canvas 기반 복잡한 렌더링을 다루는 팀이라면 Path2D 배치 처리 → OffscreenCanvas 캐싱의 2단계 접근을 순서대로 적용하되, 반드시 performance.now() 기반 측정을 먼저 선행해 병목 지점을 특정하는 것이 핵심이다.
도구 성능이 올라가는 속도와 제품의 DX가 올라가는 속도를 나란히 두고 바라볼 때, 우리가 진짜 투자해야 할 곳이 어디인지 더 선명하게 보인다.