피드백 루프가 바뀌면, 개발자의 행동이 바뀐다
Microsoft가 공개한 TypeScript 7.0은 단순한 버전 업이 아니다. 컴파일러 전체를 Go 기반 네이티브 코드로 다시 썼다. VS Code 코드베이스 기준으로 전체 빌드 시간이 125.7초에서 10.6초로 줄었고, Slack은 CI 타입 검사 시간을 7.5분에서 1.25분으로 단축했다. Microsoft News Services 팀은 CI 빌드 대기 시간을 월 400시간 절감했다고 밝혔다. 숫자만 보면 성능 개선처럼 읽히지만, 실제로는 개발자의 사고 리듬 자체가 바뀌는 변화다.
피드백 루프가 빠르면 개발자는 더 자주 실험한다. 타입 오류를 확인하기 위해 17초를 기다리던 개발자와 1.3초 안에 결과를 보는 개발자는 코드를 작성하는 방식부터 다르다. AI 코딩 도구—Cursor, Copilot, Claude—를 쓸 때도 마찬가지다. 에이전트가 코드를 생성하고 타입 검사를 돌리는 루프가 빨라지면, AI와 개발자 사이의 반복 검증 사이클이 훨씬 촘촘해진다. TypeScript 7.0은 AI 워크플로우 시대에 딱 맞는 인프라 업그레이드다.
속도 이면의 구조: 병렬화와 트레이드오프
성능 향상의 핵심은 공유 메모리 기반 멀티스레딩이다. 파싱, 타입 검사, emit을 병렬로 실행하며, --checkers 옵션으로 타입 검사 워커 수를 조정할 수 있다. 기본값은 4개지만 --checkers 8로 늘리면 vscode 코드베이스에서 16.7배 속도 향상도 가능하다. 반대로 메모리가 제한된 CI 환경에서는 값을 낮춰 오버헤드를 줄이는 전략이 유효하다. --singleThreaded 플래그는 디버깅이나 TypeScript 6과 7의 성능 비교 시 유용하다.
한 가지 현실적인 주의사항이 있다. TypeScript 7.0은 아직 프로그래밍 API를 포함하지 않는다. typescript-eslint, Vue, MDX, Astro, Svelte, Angular 템플릿 타입 검사처럼 TypeScript를 내부적으로 import하는 도구들은 TypeScript 6.0 병행이 필요하다. @typescript/typescript6 호환 패키지와 npm alias를 활용하면 두 버전을 함께 운용할 수 있으며, TypeScript 7.1에서 새 API가 제공될 예정이다. 전환은 TypeScript 6.0 변경 사항을 먼저 적용한 뒤 순차적으로 밟는 것이 안전하다.
절약된 시간으로 무엇을 할 것인가
빌드가 빨라졌다는 건 개발자에게 여유가 생겼다는 뜻이기도 하다. 그 여유를 어디에 쓸지가 중요하다. 한 개발자가 자신의 포트폴리오를 직접 접근성 감사한 사례(dev.to)는 이 맥락에서 시사하는 바가 크다. 발견된 문제는 세 가지였다. 이미지에 alt 속성이 없었고, 헤딩이 h1에서 h3으로 건너뛰었으며, <html> 태그에 lang 속성이 없었다.
이 문제들은 코드 품질 도구가 잡아주지 않는다. 타입 에러도 아니고, 빌드 에러도 아니다. 스크린 리더를 쓰는 사용자가 이미지 파일명을 날것으로 듣거나, 페이지 구조를 잃어버리는 경험으로 이어진다. 시각적으로 완성된 것처럼 보이는 화면 뒤에 숨어 있는 문제들이다. <div class="navigation-bar">로 쌓은 내비게이션은 마우스 사용자에게는 아무 문제가 없지만, 키보드나 보조 기술을 쓰는 사용자에게는 존재하지 않는 구조나 다름없다.
DX와 a11y, 같은 방향을 가리키는 두 나침반
개발자 경험(DX)과 접근성(a11y)은 종종 다른 맥락에서 언급된다. 하지만 두 가지 모두 피드백의 품질을 높이는 문제라는 점에서 근본적으로 닮았다. DX는 개발자가 더 빠르게 실수를 발견하고 수정하도록 돕는다. a11y는 더 많은 사용자가 제품을 온전히 경험하도록 보장한다. TypeScript 7.0이 컴파일 단계의 피드백 루프를 단축했다면, 접근성 감사는 사용자 경험 단계의 피드백 루프를 닫는 작업이다.
실무에서 두 가지를 함께 챙기는 방법은 생각보다 단순하다. 빌드 파이프라인에 타입 검사와 함께 axe-core나 eslint-plugin-jsx-a11y를 통합하는 것이 첫 번째다. TypeScript 7.0으로 빌드 시간이 줄었다면, 그 절약된 시간 안에 접근성 린트가 추가되어도 전체 CI 시간은 오히려 줄어든다. 두 번째는 컴포넌트 설계 단계에서 시맨틱 HTML을 기본값으로 가져가는 것이다. <button> 대신 <div onClick>을 쓰는 순간 키보드 접근성, 포커스 관리, 스크린 리더 지원을 따로 복원해야 한다. 처음부터 올바른 엘리먼트를 쓰는 것이 가장 효율적인 접근성 전략이다.
지금 팀이 준비해야 할 것
TypeScript 7.0으로 전환을 준비하는 팀이라면, strict: true, module: esnext, target: esnext 같은 새 기본값 변화부터 점검하자. rootDir과 types 설정 변화가 가장 예상치 못한 충격을 줄 수 있다. target: es5와 moduleResolution: node/node10은 더 이상 지원되지 않으므로 레거시 설정을 먼저 정리해야 한다. TypeScript 6.0 마이그레이션을 거치지 않고 바로 7.0으로 건너뛰는 것은 권장하지 않는다.
접근성 측면에서는 지금 당장 간단한 감사부터 시작할 수 있다. 브라우저 개발자 도구의 Accessibility 탭, Lighthouse, 혹은 axe DevTools 확장만으로도 alt 누락, 헤딩 계층 오류, lang 속성 부재 같은 기본 문제를 5분 안에 찾아낼 수 있다. AI 도구에 '이 컴포넌트의 접근성 문제를 찾아줘'라고 요청하는 것도 유효한 출발점이다. 중요한 건 이 루틴을 개인의 관심사에 맡기지 않고 팀의 정의된 프로세스로 만드는 것이다.
빌드가 10배 빨라졌다는 건 단순히 커피를 덜 마셔도 된다는 뜻이 아니다. 지금까지 시간이 없어서 미뤄왔던 것들—접근성 감사, 코드 품질 개선, 더 촘촘한 테스트—을 이제 파이프라인 안으로 끌어들일 수 있는 여지가 생겼다는 뜻이다. TypeScript 7.0 시대, DX 향상의 수혜를 사용자 경험 품질로 전환하는 팀이 진짜 이득을 가져간다.