모노레포, 언제 도입하고 언제 참아야 하나

모노레포는 유행이지만 공짜가 아니다. 도입해서 좋았던 경우와 후회한 경우를 모두 겪고 나서 정리한 기준이다.

도입 신호

• 코드 공유가 실제로 일어난다: 웹/어드민/앱이 같은 타입, 같은 API 클라이언트, 같은 UI 컴포넌트를 쓴다
• 원자적 변경이 필요하다: API 스키마 변경이 서버와 클라이언트에 동시에 반영돼야 한다. 레포가 나뉘면 이게 PR 2개 + 배포 순서 조율이 된다
• 버전 지옥을 겪고 있다: 내부 패키지를 npm에 올려 쓰는데 "shared 0.3.2가 어디까지 배포됐더라"를 매주 확인한다

세 개 중 두 개에 해당하면 도입이 맞다.

참아야 하는 신호

• 서비스가 하나뿐이다 — 폴더 구조로 충분하다
• 팀/서비스 간 배포 주기가 완전히 다르고 공유 코드가 거의 없다
• CI 인프라에 손댈 여력이 없다 — 모노레포의 비용은 대부분 CI에서 나온다

도입한다면 최소 구성

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

pnpm workspace + turborepo면 충분하다. 처음부터 changesets, 원격 캐시, 커스텀 제너레이터까지 깔지 말자. 핵심은 두 가지 — ①영향 범위 빌드(바뀐 패키지만) ②태스크 캐시. 이것만으로 CI가 레포 통합 이전보다 빨라져야 정상이다.

흔한 실패 패턴

shared 패키지가 "잡동사니 서랍"이 되는 것. 유틸, 타입, 컴포넌트, 상수가 한 패키지에 뒤엉키면 아무 앱이나 건드려도 전체가 재빌드된다. shared는 용도별로 잘게(ui / types / config) 나누고, 의존 방향을 한쪽으로만 흐르게 하자.