모노레포가 미리캔버스 프론트엔드 아키텍처를 뒷받침 하는 방법 [2/2]

미리캔버스 모노레포 연재 2편으로, 실제로 모노레포가 어떻게 동작하고 그 플랫폼이 서비스 아키텍처를 어떻게 뒷받침하는지 다룬다. 핵심은 CI를 세 개의 독립 파이프라인으로 나눈 구조와, 그것이 가능한 이유가 각 도구가 소비하는 산출물이 다르기 때문이라는 설명이다. Lint가 실패해도 Type-check와 Test는 계속 돌아, 개발자는 PR 하나로 세 결과를 동시에 확인한다.

핵심 포인트

린터는 소스 파일의 AST를 분석할 뿐 코드를 실행하거나 컴파일하지 않아, 하위 패키지가 빌드돼 있을 필요도 타입 선언이 있을 필요도 없다.
다만 린터에 타입 검사 플러그인을 붙이면 lint도 tsc 결과에 의존하게 되므로, 의도적으로 린터에서 타입 검사를 하지 않고 역할을 분리했다.
tsc 타입 체크에는 하위 의존성의 타입 정보가 필요하지만 실행 가능한 JavaScript 번들은 필요 없다.
emitDeclarationOnly 옵션으로 .js는 만들지 않고 .d.ts만 출력하게 하면 Type-check 파이프라인이 번들러 파이프라인과 완전히 분리된다.
테스트는 코드를 실제로 실행하므로 번들러가 컴파일한 .js 결과물이 필요한 반면, 타입 선언은 런타임에 존재하지 않아 필요하지 않다.

상세 정리

1편과의 연결: 1편이 모노레포의 개념과 미리캔버스가 모노레포를 구성하는 방법을 다뤘다면, 2편은 CI/CD 흐름부터 플랫폼 관점에서 모노레포를 이해하는 방법까지 살펴본다.
순서의 논리: 아키텍처 규칙이 코드 수준에서 강제된 다음 단계가 그 코드를 안전하게 검증하는 CI 파이프라인이라는 흐름으로 이어진다.
Lint 파이프라인이 독립적인 근거: 특정 패키지가 있든 없든 대상 소스 파일만 보고 규칙을 검사할 수 있다.
Type-check 파이프라인의 요구사항: 어떤 패키지가 다른 패키지의 타입을 쓰고 있다면 tsc는 그 타입이 어떻게 생겼는지 알아야 검사를 수행할 수 있다.
타입 체크가 실행이 아니라 타입 구조 분석이라는 점이 번들 없이도 가능한 이유다.
증분 최적화: composite와 incremental 옵션을 함께 쓰면 .tsbuildinfo에 이전 빌드 결과가 캐시돼 변경된 파일만 다시 분석하므로, 패키지 수가 많아져도 타입 체크가 점진적으로 빨라진다.
Test 파이프라인의 요구사항: 테스트 러너가 특정 패키지의 테스트를 돌리려면 의존 패키지가 실제로 실행 가능한 JavaScript 모듈이어야 한다.
세 파이프라인이 각각 소스, 타입 선언, 실행 가능한 번들이라는 서로 다른 입력을 소비하기 때문에 병렬 실행이 성립한다는 것이 이 글의 구조적 설명이다.