Monorepo + Turborepo로 블로그 & Admin 구축 - Turborepo 왜 씀?

처음 Turborepo를 접했을 때,

많은 글에서 "monorepo 도구"라고 설명하는 것을 볼 수 있다.

공식 문서에서도 monorepo를 중심으로 설명하고

pnpm dlx create-turbo@latest --example [...]

해당 명령어로 작성하는 template 또한 monorepo 구조를 그대로 제공한다.

하지만 Turborepo는 monorepo 시스템을 구성하는 도구 그자체는 아니다.

• workspace를 직접 만들어 주지도 않으며

• 패키지를 연결해주지도 않으며

• 의존성을 관리해주지도 않는다.

해당 역할의 기본은 모두 패키지 매니저(npm, pnpm, yarn)가 담당한다.

그럼 Turborepo는 뭐하는 도구일까?

👉 Turborepo는 monorepo 도구가 아니라, task를 관리하는 도구에 가깝다.

Turborepo를 도입하기 전 문제들

monorepo는 pnpm만으로도 충분히 구성이 가능하다.

하지만 실제로 프로젝트를 운영하기 시작하면

몇가지 불편함이 시작된다.

1. 패키지간 의존성 순서를 직접 관리해야한다.

예를들어

• @ui를 admin에서 사용하고 있거나

• ui가 먼저 build되거나 watch가 된 상태여야한다.

하지만 이걸 패키지 매니저만으로 자동 관리 해주지 않기에

어떤 패캐지가 먼저 실행 되어야 하는지에 따른 의존성 트리를 항상 신경써야한다.

2. 불필요한 빌드를 통한 시간 낭비

모노레포는 대개 공용 시스템을 두고 상이한 여러 어플리케이션을 한 저장소에 같이 위치시키며, 여러 모듈들을 공유하는 시스템이다.

하지만 특정 어플리케이션은 변경이 없는 상태에서도 ci/cd 절차에 따라 다른 어플리케이션의 변경 사항에 의해 함께 절차를 실행하게 된다.

그럼 변경이 없는 상태에서도

• build

• test

와 같은 작업을 매번 실행하게 되고

👉 “변경된 것만 다시 실행할 수 없을까?”라는 고민이 당연히 생길 것이다.

특히 모노레포 환경의 ci/cd에서 git hook 기반 동작시, 전체 build를 하게 되며 build 타임을 감당하지 못하는 수준까지 넘어가기도 한다.

물론 사내에서 이를 구분할 수 있는 diff를 통해 특정 app만 빌드하겠다는 식으로 컨트롤 할 수 있겠지만 공유하는 하위 패키지가 많아지고 앱이 많아지면 diff에 대한 부담은 늘어나게 된다.

Turborepo가 문제를 해결하는 방식

1. task graph 기반 실행

Turborepo는 각 패키지의 `package.json`을 기반으로 패키지 간 의존성을 분석한다.

예를들어

• admin -> @ui를 의존하고 있다면

turborepo는 admin의 테스크 그래프를 그려

admin의 build task는

자동으로 @ui의 build 이후 실행된다.

(물론 turbo.json 설정 파일에 build task가 ^build로 의존성 처리가 되어 있어야 한다는 가정)

이를 통해 사용자는 더이상 실행 순서를 직접 관리할 필요가 없다.

특히 단순히 패키지 순서만 보는 것이 아니라

각 패키지의 등록된 script (dev, build, test)를 기준으로 task graph를 구성한다.

이를 기반으로

• 어떤 작업을 먼저 실행할지

• 어떤 작업을 건너뛸 수 있는지

를 판단한다.

2. 캐싱

Turborepo의 큰 장점은 바로 캐싱이다.

• 의존성을 포함한 변경되지 않은 task는 다시 실행하지 않고

• 이전 결과를 그대로 재사용한다.

이 덕분에

• 로컬에서는 빠른 반복 작업이 가능하고

• CI/CD에서는 불필요한 전체 build를 피할 수 있다.

특히 공유 모듈이 많은 프로젝트의 경우, 컴파일 패키지로 설정하여 CI/CD 과정에서 이 이점을 극대화 시킬 수 있다.

결론

Turborepo는 monorepo를 구성하는 도구가 아니다.

하지만 monorepo를 "운영"하는 순간부터

필요해지는 도구라고 느낀다.