Turborepo vs Nx 비교: 프론트엔드 모노레포 도입과 운영의 선택 기준

프론트엔드 조직에서 모노레포 이야기를 시작하면 자주 나오는 비교가 Turborepo와 Nx입니다. 둘 다 모노레포에서 빌드, 테스트, 린트, 캐시, 태스크 실행 속도를 개선하는 데 도움을 주기 때문에 같은 후보군으로 묶이곤 합니다.

하지만 실무에서 이 둘을 고를 때는 단순히 "누가 더 빠른가"로 보기 어렵습니다.

• 지금 우리 팀이 왜 모노레포 툴을 도입하려는가
• 지금 필요한 것이 태스크 오케스트레이션인가, 워크스페이스 운영 체계인가
• 도입 이후 누가 규칙을 만들고 유지할 것인가
• Next.js SSR 앱이 여러 개 있을 때 캐시와 affected 범위를 어디까지 믿을 것인가
• 신규 입사자가 레포 구조를 이해하는 데 얼마나 시간이 드는가

즉, Turborepo와 Nx는 "비슷한 기능을 가진 두 제품"이라기보다, 모노레포를 어디까지 운영 체계로 끌고 갈 것인가에 대한 선택지에 더 가깝습니다.

이 글에서는 두 도구를 프론트엔드, 특히 React/Next.js 중심 조직의 시선에서 비교해보겠습니다. 초점은 기능 나열보다 도입 이유, 운영 비용, DX, SSR/빌드 파이프라인 안정성입니다.

먼저 한눈에 보면

짧게 정리하면 이렇습니다.

• Turborepo: 기존 워크스페이스 위에 빠르고 단순한 태스크 실행 레이어를 얹고 싶을 때 잘 맞습니다.
• Nx: 태스크 실행뿐 아니라 프로젝트 그래프, affected 분석, 코드 생성, 경계 관리까지 포함한 운영 체계를 원할 때 잘 맞습니다.

조금 더 자세히 보면 아래처럼 볼 수 있습니다.

빠르게 정리하면, 단순하고 빠른 시작은 Turborepo, 장기적인 운영 체계까지 같이 보려면 Nx로 이해하면 크게 틀리지 않습니다.

먼저 정리해야 할 것: 모노레포에 이 도구가 꼭 필요한가?

이 질문부터 먼저 해야 합니다. 많은 팀이 pnpm workspace나 npm workspace만으로도 이미 모노레포를 운영할 수 있습니다.

예를 들어:

• apps/web
• apps/admin
• packages/ui
• packages/config-eslint
• packages/config-typescript

정도 구조라면, package manager workspace만으로도 의존성 연결과 기본 스크립트 실행은 충분히 됩니다.

repo/
  apps/
    web/
    admin/
  packages/
    ui/
    auth/
    config-eslint/
    config-typescript/

조금 더 프론트엔드스럽게 보면 실제 디렉토리 구조는 보통 아래처럼 발전합니다.

repo/
  apps/
    web/                 # 사용자 서비스
    admin/               # 운영자 서비스
    docs/                # 문서 혹은 마케팅 사이트
  packages/
    ui/                  # 공통 UI 컴포넌트
    auth/                # 인증 관련 도메인 로직
    api/                 # API client
    utils/               # 범용 유틸
    config-eslint/       # 공통 ESLint 설정
    config-typescript/   # 공통 TS 설정

이 정도까지 오면 단순 workspace만으로도 돌아가기는 하지만, 그다음부터는 아래 질문이 생깁니다.

• packages/ui가 바뀌면 어떤 앱을 다시 빌드해야 하는가
• packages/auth 변경이 web과 admin 중 어디에 영향을 주는가
• config-eslint 수정이 테스트와 빌드까지 다시 돌려야 하는가
• 이런 관계를 팀이 사람 머리로만 기억해야 하는가

그래서 Turborepo나 Nx를 도입해야 하는 이유는 보통 아래부터 시작합니다.

• 앱과 패키지가 늘어나서 전체 빌드 시간이 길어졌을 때
• 변경되지 않은 프로젝트까지 매번 같이 테스트/빌드하는 비용이 커졌을 때
• CI에서 cache hit 여부가 전체 생산성을 크게 좌우할 때
• 어떤 변경이 어느 앱에 영향을 주는지 추적하기 어려울 때
• 공통 코드 생성, 정책 관리, 경계 통제를 팀 차원에서 하고 싶을 때

즉, 이 도구들은 "모노레포를 가능하게 만드는 도구"라기보다, 모노레포의 운영 비용이 커졌을 때 그 비용을 줄이기 위한 도구입니다.

두 도구는 무엇을 다르게 바라볼까?

Turborepo는 태스크 실행을 단순하게 만든다

Turborepo의 핵심 감각은 비교적 단순합니다.

• workspace는 package manager가 관리하고
• turbo.json으로 task dependency를 선언하고
• 각 task의 입력과 출력에 따라 캐시를 재사용합니다

여기서 중요한 기준점은 package graph입니다. 즉, package manager가 이미 알고 있는 의존성 관계를 바탕으로 task 실행 순서를 잡는 감각에 가깝습니다.

예를 들어 아래 같은 구조라면:

apps/web -> packages/ui -> packages/utils
apps/admin -> packages/ui -> packages/utils
apps/docs -> packages/ui

Turborepo는 이 관계를 기반으로 build, lint, test 같은 task를 엮어 실행합니다.

package graph
 
apps/web -----> packages/ui -----> packages/utils
apps/admin ---> packages/ui -----> packages/utils
apps/docs ----> packages/ui

예를 들어:

{
  "$schema": "https://turbo.build/schema.json",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "dist/**"]
    },
    "lint": {},
    "test": {
      "dependsOn": ["^build"]
    }
  }
}

이 방식의 장점은 명확합니다.

• mental model이 비교적 단순하고
• 기존 package.json scripts를 크게 바꾸지 않아도 되며
• 캐시와 병렬 실행 효과를 빠르게 체감할 수 있습니다

실제로 graph를 보는 감각도 비교적 단순합니다.

turbo run build --graph

즉, "어떤 패키지가 어떤 패키지를 참조하고, 그 위에서 build task가 어떤 순서로 도는가"를 보는 데 집중하는 편입니다.

즉, Turborepo는 이미 있는 워크스페이스를 더 효율적으로 실행하는 도구에 가깝습니다.

Nx는 프로젝트 그래프를 중심으로 본다

Nx는 태스크 실행 도구이기도 하지만, 감각은 조금 다릅니다.

• 레포 안의 프로젝트들을 그래프로 보고
• 어떤 프로젝트가 누구를 참조하는지 분석하고
• 그 그래프를 바탕으로 task graph와 affected 범위를 계산합니다

여기서 중요한 것은 project graph라는 감각입니다. Nx에서는 앱과 라이브러리를 단순 package 관계로만 보지 않고, 워크스페이스 안의 프로젝트 단위로 더 적극적으로 해석합니다.

예를 들어 같은 구조라도 Nx 쪽에서는 아래처럼 읽히는 느낌에 가깝습니다.

project graph
 
web ---------> ui ----------> utils
web ---------> auth --------> api
admin -------> ui ----------> utils
admin -------> auth --------> api
docs --------> ui

즉, 단순히 "의존성이 있다"를 넘어서:

• 어떤 프로젝트가 어떤 프로젝트를 참조하는지
• 어떤 target이 누구에게 전파되는지
• 어떤 변경이 affected 범위를 넓히는지

를 같이 보게 됩니다.

그래서 Nx는 단순히 "스크립트를 빨리 돌린다"보다, 레포를 구조적으로 이해하고 통제하는 도구에 더 가깝습니다.

예를 들어 팀이 관심을 갖는 지점도 달라집니다.

• 어떤 앱이 어떤 shared package에 의존하는가
• 어떤 변경이 어느 프로젝트들에 영향을 주는가
• 경계를 어긴 import가 있는가
• 생성 규칙을 어떻게 자동화할 것인가

즉, Nx는 속도뿐 아니라 워크스페이스를 하나의 시스템으로 운영하는 감각이 더 강합니다.

그래프를 눈으로 확인하는 흐름도 자주 등장합니다.

nx graph

이 명령은 단순히 "예쁘게 보인다"가 아니라, 실무에서는 아래 질문을 빠르게 확인하는 데 도움을 줍니다.

• 왜 web이 ui 변경의 영향을 받는가
• 왜 admin까지 같이 다시 도는가
• 특정 shared package가 너무 많은 앱에 붙어 있지는 않은가
• 도메인 경계가 생각보다 넓게 새고 있지는 않은가

예를 들어 Nx에서는 아래처럼 target과 입력을 명시해 task를 다루는 구성을 자주 보게 됩니다.

{
  "name": "web",
  "targets": {
    "build": {
      "executor": "@nx/next:build",
      "outputs": ["{workspaceRoot}/dist/apps/web"]
    },
    "lint": {
      "executor": "@nx/eslint:lint"
    },
    "test": {
      "executor": "@nx/jest:jest"
    }
  }
}

또는 최근에는 inferred tasks를 기반으로, 설정 파일을 읽어 target을 자동으로 추론하는 방식도 많이 사용합니다.

도입 관점에서 보면 무엇이 다를까?

1. 시작 속도

새 레포 혹은 비교적 단순한 모노레포라면 Turborepo가 더 빠르게 안착하는 경우가 많습니다.

• 구조 설명이 짧고
• 기존 npm scripts와 연결이 쉽고
• "일단 빨라진다"는 체감이 빠르게 옵니다

반면 Nx는 도입 초기에 이해해야 할 개념이 더 많습니다.

• project graph
• target
• affected
• generator
• plugin
• boundary rule

물론 최근의 Nx는 inferred tasks처럼 설정을 줄이는 방향으로 많이 발전했지만, 여전히 도입 시 이해해야 할 범위는 Turborepo보다 넓습니다.

2. 조직이 기대하는 수준

도입 시점에서 중요한 것은 기능이 아니라 기대치입니다.

Turborepo가 잘 맞는 기대치

• "지금 있는 레포를 크게 바꾸지 않고 더 빠르게 돌리고 싶다"
• "CI 시간을 줄이고 remote cache를 붙이고 싶다"
• "Next.js 앱과 공유 패키지를 편하게 묶고 싶다"

turbo run build lint test
turbo run build --filter=web

Nx가 잘 맞는 기대치

• "어떤 프로젝트가 왜 영향을 받는지 구조적으로 알고 싶다"
• "공통 generator와 규칙으로 개발 흐름을 표준화하고 싶다"
• "앱/패키지 수가 많아져도 운영 체계를 유지하고 싶다"

nx graph
nx affected -t build,lint,test
nx g @nx/react:library ui

즉, Turborepo는 실행 효율 도입에 가깝고, Nx는 운영 체계 도입에 가깝습니다.

3. 온보딩 비용

시니어 관점에서 보면 이 부분이 생각보다 중요합니다. 도구가 아무리 좋아도 새 팀원이 구조를 이해하지 못하면 유지비가 올라갑니다.

Turborepo는 설명이 비교적 간단합니다.

• workspace는 package manager가 관리
• turbo run build
• 캐시는 task 단위로 재사용

Nx는 더 많은 설명이 필요합니다.

• project graph가 어떻게 만들어지는가
• affected는 어떤 기준으로 계산되는가
• generator는 언제 쓰는가
• workspace rule은 어디에 있는가

그래서 팀 문서화 수준이 낮다면 Turborepo가 더 편하고, 반대로 팀이 규칙을 문서화하고 장기 운영할 준비가 되어 있다면 Nx의 투자 가치가 올라갑니다.

운영 관점에서 차이는 어디서 커질까?

도입보다 중요한 것은 도입 이후입니다. 실제 비용은 운영에서 드러납니다.

1. 캐시를 얼마나 신뢰할 수 있는가

둘 다 로컬 캐시와 원격 캐시를 활용해 중복 작업을 줄이는 데 강합니다. 하지만 운영 관점에서는 단순히 "cache hit가 난다"보다 아래 질문이 더 중요합니다.

• 어떤 파일 변경이 cache invalidation을 일으키는가
• .env, next.config, tsconfig, shared config package 변경이 어디까지 영향을 주는가
• 브랜치와 CI 환경 차이 때문에 cache miss가 반복되지는 않는가

이 지점에서 체감 차이는 이렇게 나뉩니다.

• Turborepo: task input/output을 비교적 직관적으로 이해하고 조정하기 좋음
• Nx: affected 분석과 project graph를 함께 보며 왜 이 task가 실행되는지 추적하기 좋음

즉, 둘 다 캐시는 강하지만 Turborepo는 단순한 캐시 운영, Nx는 캐시와 영향 범위를 함께 보는 운영에 더 가깝습니다.

예를 들어 Turborepo에서는 task 출력물을 명시해서 캐시 범위를 비교적 직관적으로 맞추는 편입니다.

{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["$TURBO_DEFAULT$", ".env.production"],
      "outputs": [".next/**", "dist/**"]
    }
  }
}

Nx에서는 target input과 named input을 통해 어떤 변경이 다시 실행을 유발하는지 더 세분화해서 보는 구성이 자주 나옵니다.

{
  "namedInputs": {
    "default": ["{projectRoot}/**/*"],
    "production": ["default", "!{projectRoot}/**/*.spec.tsx"]
  },
  "targetDefaults": {
    "build": {
      "inputs": ["production", "^production"]
    }
  }
}

2. 변경 영향 범위를 어디까지 자동화할 것인가

프론트엔드 모노레포가 커질수록 중요한 질문은 이것입니다.

• packages/ui 변경이 web과 admin에 모두 영향을 주는가
• eslint-config 수정이 테스트까지 다시 돌려야 하는가
• shared/auth 수정이 어떤 SSR 앱에 배포 영향을 주는가

이 지점을 graph로 보면 감이 더 잘 옵니다.

changed: packages/auth
 
packages/auth
  ├─> apps/web
  └─> apps/admin
 
affected targets
  - web:build
  - web:test
  - admin:build
  - admin:test

Nx는 affected 개념이 워크스페이스 운영에 깊게 들어와 있어서, 변경 영향 범위를 정책적으로 다루기에 더 유리합니다.

nx affected -t build,test,lint

Turborepo도 변경 기반 실행과 필터링을 활용할 수 있지만, 감각은 조금 다릅니다. Nx가 "영향 분석을 운영 모델로 끌어들인다"면, Turborepo는 "빠른 실행과 캐시를 중심에 둔다"는 느낌에 더 가깝습니다.

즉, 둘 다 그래프를 사용하지만 읽는 방식이 조금 다릅니다.

• Turborepo: package graph 위에서 task 실행 순서와 cache hit를 보는 감각
• Nx: project graph 위에서 영향 범위와 운영 규칙을 같이 보는 감각

Turborepo 쪽에서 자주 보게 되는 실행 예시는 이런 형태입니다.

turbo run build --filter=./apps/web
turbo run test --filter=@repo/ui

Nx 쪽에서는 base/head 기준으로 affected 범위를 계산해 CI를 줄이는 흐름이 자주 나옵니다.

nx affected -t build --base=origin/main --head=HEAD
nx affected -t test --base=origin/main --head=HEAD

3. 경계 관리와 코드베이스 건강도

모노레포는 편하지만, 조금만 시간이 지나도 아래 문제가 생깁니다.

• 앱이 shared package 내부 구현에 과하게 의존하고
• 패키지 간 import 경계가 흐려지고
• 공통 패키지가 점점 커지며
• 결국 "shared"가 잡동사니 폴더가 됩니다

이 지점에서 시니어가 보는 핵심은 구조를 누가 지키게 할 것인가입니다.

Turborepo는 이 문제를 직접 해결해주기보다, 팀 규칙과 리뷰 프로세스로 풀어야 하는 부분이 많습니다.

Nx는 project graph와 boundary rule 쪽으로 더 확장하기 쉬워서, 구조적 제약을 코드베이스 운영 규칙으로 끌고 가기에 유리합니다.

예를 들어 레이어 간 import 제한을 lint rule로 관리하는 식의 구성이 가능합니다.

{
  "rules": {
    "@nx/enforce-module-boundaries": [
      "error",
      {
        "depConstraints": [
          {
            "sourceTag": "scope:web",
            "onlyDependOnLibsWithTags": ["scope:shared", "scope:web"]
          }
        ]
      }
    ]
  }
}

즉, 레포가 커질수록 차이는 "누가 더 빨리 빌드하느냐"보다, 누가 레포 건강도를 더 오래 유지하게 돕느냐에서 드러납니다.

프론트엔드, 특히 Next.js SSR 관점에서 보면

이 부분은 생각보다 중요합니다. Turborepo와 Nx는 렌더링 방식을 직접 바꾸는 도구는 아니지만, SSR 앱을 어떻게 빌드하고 검증하고 배포하느냐에는 큰 영향을 줍니다.

1. SSR 앱은 빌드 산출물과 환경 의존성이 크다

Next.js SSR/App Router 앱은 일반적인 정적 프론트엔드보다 영향을 주는 요소가 많습니다.

• .next 빌드 산출물
• 서버/클라이언트 번들 분리
• 환경 변수
• shared package transpilation
• RSC 관련 컴파일 경계

그래서 모노레포 툴 선택 시 중요한 것은:

• web 앱이 packages/ui와 packages/auth 변경을 어떻게 따라가는가
• admin 앱만 바뀌었는데 web의 SSR 빌드까지 다시 도는가
• 공통 ESLint/TS 설정 변경이 어느 정도까지 전파되는가

이때 Turborepo는 Next.js 앱 여러 개를 가진 프론트엔드 레포에서 비교적 자연스럽게 받아들이기 쉽습니다. 반면 Nx는 여기서 한 단계 더 들어가서, 이 변경이 실제로 누구에게 영향을 주는지를 더 구조적으로 보고 싶을 때 강점이 커집니다.

예를 들어 Turborepo 기반 Next.js 레포는 아래처럼 시작하는 경우가 많습니다.

{
  "tasks": {
    "dev": {
      "cache": false,
      "persistent": true
    },
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**"]
    }
  }
}

Nx에서는 Next.js 앱 target을 기준으로 build, serve, lint를 명시적으로 운영하는 구성을 자주 봅니다.

{
  "name": "web",
  "targets": {
    "build": {
      "executor": "@nx/next:build"
    },
    "serve": {
      "executor": "@nx/next:server"
    },
    "lint": {
      "executor": "@nx/eslint:lint"
    }
  }
}

2. SSR에서는 단순한 실행보다 재현성이 중요하다

SSR 앱 운영에서는 빌드 속도도 중요하지만, 그보다 더 중요한 것은 같은 입력에서 같은 결과가 나오는가입니다.

즉, 캐시 적중률보다 아래가 더 중요해집니다.

• 환경 변수 차이 때문에 캐시가 잘못 재사용되지 않는가
• shared package 변경이 누락되지 않는가
• preview 환경과 production 환경의 task 입력이 어긋나지 않는가

이 지점은 도구의 기능보다도 팀의 설정 역량 문제지만, Nx는 그래프와 affected 관점에서 설명하기 쉽고, Turborepo는 단순한 task 설계를 유지할수록 운영이 깔끔해집니다.

CI에서도 감각 차이가 드러납니다.

Turborepo 예시

- run: pnpm turbo run build lint test

Nx 예시

- run: pnpm nx affected -t lint,test,build --base=origin/main --head=HEAD

3. 여러 Next.js 앱을 운영하는 팀에서는 무엇이 갈릴까?

Turborepo가 잘 맞는 경우

• apps/web, apps/admin, apps/docs 정도 구조
• 공유 UI, eslint, tsconfig 패키지 몇 개
• CI 시간을 줄이는 것이 1차 목표
• 레포 운영 규칙은 리뷰와 팀 합의로도 충분히 관리 가능

Nx가 잘 맞는 경우

• 앱과 shared library 수가 계속 늘어남
• 어떤 앱이 어떤 도메인 패키지에 의존하는지 추적이 중요
• 변경 영향 기반 CI 최적화를 더 강하게 가져가고 싶음
• 생성 규칙, 경계 규칙, 구조 규칙까지 체계화하고 싶음

즉, Next.js 중심 프론트엔드 조직에서는 앱 수가 적고 구조가 단순하면 Turborepo, 앱과 라이브러리 조합이 복잡해지고 운영 정책이 중요해질수록 Nx 쪽으로 기울 가능성이 큽니다.

DX 관점에서는 무엇이 다르게 느껴질까?

Turborepo의 DX

Turborepo의 DX는 비교적 즉각적입니다.

• 설치하고
• turbo run build
• task graph와 cache hit를 보고
• 속도 개선을 바로 체감합니다

이 단순함은 큰 장점입니다. 시니어 입장에서도 "팀 전체가 빠르게 따라오게 만드는 DX"는 꽤 중요합니다.

다만 단순함의 반대편에는 이런 점도 있습니다.

• 코드 생성과 레포 자동화는 별도 툴에 의존하게 되고
• 경계 규칙은 따로 설계해야 하며
• 구조가 커졌을 때 레포 관리 체계는 팀이 직접 만들어야 합니다

즉, Turborepo의 DX는 배우기 쉬운 DX에 가깝습니다.

Nx의 DX

Nx의 DX는 처음엔 더 무겁게 느껴질 수 있습니다.

• 명령어 체계가 더 많고
• 그래프 기반 사고가 필요하고
• 레포 운영 개념을 같이 익혀야 합니다

하지만 일정 규모를 넘어서면 장점이 바뀝니다.

• 어떤 프로젝트가 영향을 받는지 설명하기 쉬워지고
• 공통 generator로 생성 편차를 줄일 수 있으며
• 규칙을 사람이 아니라 시스템으로 일부 옮길 수 있습니다

즉, Nx의 DX는 초반엔 학습 비용이 있지만, 규모가 커졌을 때 유지보수 DX로 전환되는 면이 있습니다.

개발자가 매일 보게 되는 명령어 감각도 조금 다릅니다.

# Turborepo
turbo run dev --filter=web
turbo run build --filter=@repo/ui
 
# Nx
nx serve web
nx build web
nx affected -t lint

어떤 팀에 어떤 선택이 맞을까?

Turborepo가 잘 맞는 팀

• React/Next.js 중심의 프론트엔드 모노레포
• 앱 수와 패키지 수가 아직 폭발적으로 많지 않음
• 빠른 도입과 빠른 성과가 중요함
• 팀이 복잡한 운영 모델보다 단순한 스크립트 실행 모델을 선호함
• 규칙 관리보다는 실행 속도 개선이 먼저임

Nx가 잘 맞는 팀

• 앱, 패키지, 도메인 라이브러리 수가 많음
• 변경 영향 분석과 구조 통제가 중요함
• 공통 생성 규칙과 워크스페이스 정책이 필요함
• 장기적으로 레포 운영 체계를 시스템화하고 싶음
• 프론트엔드 단독 레포를 넘어 더 넓은 범위의 워크스페이스로 갈 가능성이 있음

실무에서는 어떻게 판단하면 좋을까?

아래 질문으로 정리하면 비교적 판단이 쉽습니다.

정리하면

Turborepo와 Nx는 둘 다 좋은 도구입니다. 하지만 잘 맞는 문제는 조금 다릅니다.

• Turborepo: 모노레포를 빠르고 단순하게 실행하고 싶을 때
• Nx: 모노레포를 구조적으로 이해하고 장기 운영 체계까지 끌고 가고 싶을 때

제 경험 기준으로 프론트엔드 팀에 더 직접적으로 정리하면 이렇습니다.

• 지금 필요한 것이 속도와 단순함이면 Turborepo
• 지금 필요한 것이 영향 분석과 운영 체계면 Nx
• Next.js SSR 앱이 몇 개 안 되는 프론트엔드 레포라면 Turborepo가 더 자연스러울 수 있음
• 여러 앱과 도메인 라이브러리를 장기적으로 통제해야 한다면 Nx의 투자 가치가 커짐

중요한 것은 어느 쪽이 더 유명한가가 아니라, 우리 팀이 지금 해결하려는 모노레포 문제의 종류가 무엇인가입니다. 실행 속도를 먼저 해결하려는 팀과, 구조와 운영 체계를 먼저 해결하려는 팀은 같은 답을 선택하지 않을 가능성이 큽니다.