Turborepo 개념 정리

 

---

Turborepo, Turbo, Vite, Yarn… 각각 어떤 역할이고 어떻게 조합해야 할까?

프런트엔드 개발을 하다 보면
Turbo / Turborepo / Vite / Yarn / Next.js / Umi 같은 용어들이 계속 등장한다.
하지만 실제로는 이 도구들이 어떤 차이가 있고, 서로 어떻게 조합되는지 헷갈리는 경우가 많다.

이 글에서는 이러한 도구들의 관계를 명확하게 정리하고,
특히 많은 개발자가 궁금해하는 **“Vite 빌드에 Turbo가 어떤 도움을 주는가?”**를 정확하게 설명한다.

---

1. Yarn, Vite, Umi, Turbo의 역할 정리

가장 중요한 사실은 네 도구의 역할이 서로 다르며 레이어(단계)가 다르다는 것이다.

Yarn — 패키지 관리자

• 라이브러리 설치, 스크립트 실행, 워크스페이스 관리
• npm의 대체 도구
• 모든 개발 환경의 기반이 되는 Layer 1 툴

Vite — 개발 서버 + 번들러

• 빠른 개발 서버 제공 (HMR)
• 빌드(dist 생성)를 담당하는 엔진
• Rollup 기반의 고속 번들러

Umi — React 프레임워크

• 빌드, 라우팅, 플러그인 구조가 포함된 React 기반 앱 프레임워크
• Next.js와 유사하나 중국권 기업에서 많이 사용

Turbo (Turborepo) — Task Runner / 모노레포 빌드 시스템

• build / dev / test / lint 같은 작업 실행을 최적화
• 영향 범위 추적(graph), 캐싱, 병렬 실행을 지원
• 빌드를 “만드는” 도구가 아니라 빌드를 언제 어떻게 실행할지 최적화하는 도구
• 모노레포에서 가장 큰 효과

---

2. Turborepo와 turbo는 같은가?

정확한 관계는 다음과 같다.

• Turborepo = 제품 이름 (전체 시스템)
• turbo = Turborepo의 CLI 명령어

즉,

Turborepo 시스템을 turbo 명령어로 사용한다.

Node.js 플랫폼을 node 명령어로 실행하는 것과 동일한 구조다.

---

3. Vite와 Turbo는 어떤 관계인가?

이 부분에서 많은 오해가 생긴다.

핵심 정리

Vite는 실제 빌드를 수행하는 엔진이고,
Turbo는 그 빌드를 효율적으로 실행하게 해주는 orchestrator(조율자)다.

Turbo가 Vite의 빌드 속도를 높이거나 내부 로직을 바꾸는 것이 아니다.

Turbo가 하지 않는 일

• Vite 내부 빌드 최적화
• HMR 개선
• CSS/HTML live reload 가속
• 번들링 속도 향상

Vite는 Turbo가 있든 없든 동일하게 동작한다.

Turbo가 하는 일

• 어떤 패키지가 변경되었는지 감지
• 변경된 대상만 build 실행
• 변경 없는 패키지는 캐시된 결과를 재사용
• 멀티 앱/멀티 패키지를 병렬 빌드
• CI/CD에서 작업을 1~2초로 단축 가능

따라서 Turbo의 효율은 다음과 같은 상황에서 크게 드러난다:

모노레포 + 여러 패키지 + 서로 의존성 있는 구조

단일 앱에서는 효과가 거의 없다.

---

4. 그럼 Turbo는 모노레포에서만 필요한가?

결론: **Turbo는 모노레포에서 강력하지만 단일 레포에서도 사용 가능하다.

다만 실익은 매우 적다.**

Turbo가 제공하는 성능 향상 포인트는 다음 두 가지뿐이다.

1) 작업 캐싱

첫 빌드만 실행하고, 이후는 캐시에서 결과를 읽어오는 방식.

2) 병렬 실행

다수의 패키지에서 작업을 동시에 실행.

하지만 단일 프로젝트에서는:

• 빌드 자체가 이미 빠름
• dev 서버는 Turbo 캐싱 불가
• 변경이 자주 발생해 캐시 무효화가 지속됨

결과적으로 Turbo는 단일 프로젝트에서는 거의 체감 효과가 없다.

그래서 실제로 Turbo는 “모노레포 도구”로 인식된다.

---

5. Vite 최신 버전에서 Turbo 호환성 문제는 없는가?

문제없다.
Vite는 Turbo를 전혀 방해하지 않으며
Turbo도 Vite의 동작에 간섭하지 않는다.

오히려 Turborepo 공식 문서에도 Vite 연동 가이드가 존재한다.

Vite가 최신 버전이든 Turbo가 최신 버전이든 호환은 유지된다.

이 둘은 역할이 아예 다르기 때문에 충돌할 이유가 없다.

---

6. Turbo가 Vite 빌드를 “빠르게” 만들어 주는 것이 아니라, “불필요하게 다시 빌드하지 않게” 만들어 주는 이유

다음 두 상황을 비교해보면 Turbo의 본질이 선명해진다.

1) Vite 단독 빌드

vite build
vite build
vite build

→ 매번 전체 빌드
→ 변경 없어도 다시 빌드
→ 시간이 쌓여서 느려짐

2) Turbo + Vite

turbo run build

Turbo는 이렇게 동작한다:

• A 패키지만 수정됨 → A만 Vite build
• B/C 패키지는 수정 없음 → 캐시 사용
• 여러 패키지 build → 병렬 실행
• CI 환경 → 대부분 캐시로 처리

이 방식 때문에 속도가 “엄청 빠르게 느껴지는” 것이다.

하지만 핵심은:

Turbo가 Vite의 빌드 속도를 높인 게 아니라

Vite 빌드 자체가 불필요하게 실행되는 일을 줄인 것이다.

매우 중요한 차이다.

---

7. 결론

Turbo는 빌드 엔진이 아니다

실제 빌드(dist)를 만드는 것은 Vite다.

Turbo는 빌드 실행을 효율적으로 관리하는 도구

캐싱, 병렬 실행, 의존성 그래프 기반 실행.

Turbo의 진짜 효율은 모노레포에서 나온다

단일 프로젝트에서는 효과가 거의 없다.

Vite와 Turbo는 충돌하지 않으며 최신 버전에서도 완전 호환

Turbo는 Vite의 내부에 개입하지 않는다.

---

마무리

프런트엔드 개발 스택은 이름이 비슷하고 기능이 겹칠 때가 있어 혼란스럽지만,
각 도구의 역할 레이어를 정확히 이해하면 어떤 조합이 적절한지 명확해진다.

• Yarn → 의존성 관리
• Vite → 개발 서버 및 빌드
• Umi / Next.js → 앱 프레임워크
• Turbo → 빌드·테스트·개발 작업을 실행하는 방식 최적화

이 구조를 이해하면
모노레포 구조를 구축할지, 단일 앱에서 간단히 끝낼지
혹은 Turbo를 도입해야 할지 판단이 쉬워진다.

원한다면 이 글에 이어서
Turbo + Vite 모노레포 실전 구조 템플릿
또는
터보 적용 전/후 CI 속도 비교 사례도 정리해줄 수 있다.