모노레포 DevOps 운영 2026, 의존성 카탈로그·CI 비용·보안 기준

모노레포 DevOps 운영과 의존성 카탈로그 회의를 진행하는 개발팀 — 모노레포는 저장소 형태가 아니라 의존성, CI, 권한, 배포 책임을 한 번에 묶는 운영 체계다.

모노레포 DevOps 운영을 검토하는 팀은 저장소를 하나로 합칠지보다 합친 뒤 누가 버전을 고정하고 누가 깨진 빌드를 되돌릴지 먼저 정해야 한다.

토스 기술 글은 100명이 넘는 프런트엔드 엔지니어가 동일한 React 19와 Next.js 15 계열 개발환경을 유지하는 과정에서 모노리포와 카탈로그 운영을 어떻게 다뤘는지 보여준다.

이 글은 토스 사례를 그대로 요약하지 않고 pnpm, Yarn, Turborepo, Nx, GitHub Actions, SLSA 문서까지 묶어 기업 팀이 적용 전 확인할 운영 기준으로 재구성한다.

핵심 요약

모노레포는 저장소를 하나로 모으는 선택이 아니라 의존성 정책, CI 캐시, 경계 규칙, 공급망 보안을 함께 운영하는 구조다.
pnpm catalog와 Yarn constraints는 패키지 버전을 여러 package.json에 흩뿌리지 않기 위한 실무 장치로 볼 수 있다.
비용 판단은 월액보다 빌드 시간, 설치 시간, 캐시 적중률, 변경 전파 시간, 장애 복구 시간을 먼저 숫자로 잡아야 한다.
모노레포 DevOps 운영은 플랫폼팀 단독 업무가 아니며 서비스 오너, 보안팀, 릴리스 담당자의 승인 경계가 필요하다.

이 글이 필요한 사람

여러 프런트엔드 서비스가 서로 다른 React, Next.js, TypeScript 버전으로 흩어져 빌드와 장애 대응이 느린 팀
모노레포를 도입했지만 package.json, lockfile, CI 설정이 서비스마다 제각각인 플랫폼 담당자
pnpm catalog나 Yarn constraints를 쓰기 전에 운영 책임과 예외 승인 기준을 정해야 하는 개발 리더
GitHub Actions나 GitLab CI 시간이 계속 늘어나 의존성 캐시와 테스트 범위 최적화가 필요한 DevOps 담당자
공급망 보안 관점에서 패키지 버전, 빌드 출처, 릴리스 증적을 모노레포 안에서 통제하려는 보안 담당자

모노레포 DevOps 운영의 출발점은 저장소 통합이 아니다

Nx 문서는 모노레포를 여러 프로젝트가 잘 정의된 관계를 가진 하나의 저장소라고 설명한다.

같은 설명에서 핵심은 단순한 코드 동거가 아니라 프로젝트 사이 관계를 도구가 이해하고 빌드, 테스트, 배포를 따로 할 수 있어야 한다는 점이다.

Yarn 문서도 workspaces를 같은 프로젝트 안의 개별 패키지로 설명하고, 서로 참조를 쉽게 만들 수 있는 구조라고 정리한다.

따라서 모노레포 DevOps 운영의 첫 질문은 저장소 개수가 아니다.

서비스가 하나의 플랫폼 규칙 아래에서 빌드되고, 예외가 생겼을 때 어느 팀이 어떤 기준으로 승인하는지가 먼저다.

판단 항목	모노레포가 맞는 조건	폴리레포가 나은 조건	확인 질문
의존성 정책	핵심 라이브러리를 한 버전대 또는 카탈로그로 묶어야 한다.	서비스별 기술 스택과 릴리스 주기가 완전히 다르다.	공통 패키지 업데이트를 한 번에 검증할 수 있는가
CI 구조	변경 영향 범위를 계산해 필요한 작업만 실행할 수 있다.	각 저장소가 이미 독립 파이프라인과 비용 owner를 갖고 있다.	테스트 범위와 캐시 키를 자동으로 계산하는가
플랫폼 전파	공통 UI, 인증, 로깅, 디자인 시스템을 빠르게 전파해야 한다.	공통 플랫폼이 거의 없고 팀 간 코드 공유가 드물다.	공통 변경 실패 시 전체 영향도가 감당 가능한가
보안 통제	패키지 버전, 릴리스 증적, 취약 패키지 대응을 중앙에서 잡아야 한다.	규제상 저장소와 권한을 조직별로 분리해야 한다.	권한과 감사 로그를 프로젝트 단위로 나눌 수 있는가

이 조건이면 모노레포를 검토한다.

공통 프런트엔드 플랫폼이 있고 서비스가 오래된 의존성 때문에 제품 개선을 놓치는 상황이다.

이 경우는 보류한다.

모든 팀이 한 저장소에 들어오지만 플랫폼팀이 카탈로그, 경계 규칙, CI 실패 대응 권한을 갖지 못하는 상황이다.

토스 사례에서 볼 숫자: 카탈로그는 개발 시간 비용 문제다

토스 글은 모노리포만으로는 문제가 해결되지 않았고 서비스별 의존성 버전 차이가 설치 시간과 개발 경험 파편화를 만들었다고 설명한다.

글에서 카탈로그 도입 후 Yarn PnP 정보 파일 크기는 96MB에서 15MB로 줄어 약 84% 절감된 사례가 제시된다.

같은 글은 개발 서버 실행 속도가 26.7초에서 20.3초로 약 23% 개선되고, 전체 의존성 설치 시간이 528.4초에서 249.9초로 약 52% 줄었다고 적는다.

이 숫자는 모든 조직에 그대로 보장되는 성능표가 아니다.

다만 의존성 카탈로그가 추상적인 개발문화가 아니라 설치 시간, 빌드 시간, 리뷰 시간 같은 비용 항목과 연결된다는 근거로 쓸 수 있다.

비용 항목	공식·기술 출처 숫자	운영 해석	대시보드 지표
의존성 정보 파일	토스 사례 기준 96MB → 15MB, 약 84% 절감	중복 의존성과 파편화된 버전이 줄면 설치와 분석 부담이 낮아진다.	lockfile 크기, 의존성 그래프 노드 수, 중복 버전 수
개발 서버 시작	토스 사례 기준 26.7초 → 20.3초, 약 23% 개선	서비스 개발자의 반복 대기 시간이 줄어든다.	dev server cold start p50/p90
전체 설치 시간	토스 사례 기준 528.4초 → 249.9초, 약 52% 절감	CI와 로컬 온보딩 시간 비용이 동시에 줄어든다.	install duration, cache hit ratio
GitHub 캐시 키	GitHub 문서 기준 key 최대 길이 512자	캐시 키를 lockfile과 OS 기준으로 짧고 예측 가능하게 설계한다.	cache hit, cache miss, restored key
카탈로그 변경 주기	토스 사례는 월 단위 stable-26.07, stable-26.08 형식을 설명	파괴적 변경은 새 카탈로그로 분리하고 적용 대상을 추적한다.	catalog adoption percent, exception count

비용 절감의 실무 결론은 단순하다.

모노레포 DevOps 운영에서 돈은 러너 사용 시간만이 아니라 개발자가 기다리는 설치 시간과 플랫폼팀이 예외를 처리하는 시간으로도 빠져나간다.

이 조건이면 카탈로그 도입을 우선한다.

동일한 라이브러리가 서비스별로 서로 다른 버전으로 반복되고, 한 패키지 업그레이드가 여러 팀의 수동 조율로 이어지는 경우다.

pnpm catalog와 Yarn constraints를 어떻게 나눠 볼까

pnpm 문서는 catalogs를 workspace에서 의존성 버전 범위를 재사용 가능한 상수처럼 정의하는 기능으로 설명한다.

pnpm의 catalog 프로토콜은 package.json의 dependencies, devDependencies, peerDependencies, optionalDependencies에서 직접 버전 범위 대신 참조될 수 있다.

Yarn constraints 문서는 workspace 패키지 전반에 같은 의존성 버전을 강제하거나 특정 의존성을 금지하는 규칙을 둘 수 있다고 설명한다.

따라서 둘은 경쟁이라기보다 역할이 다르다.

도구·기능	주요 역할	적합한 사용처	주의점
pnpm catalog	버전 범위를 pnpm-workspace.yaml에서 중앙 정의	React, Next.js, TypeScript 같은 핵심 의존성 고정	카탈로그 밖 직접 버전을 어떻게 막을지 별도 정책이 필요하다.
Yarn workspaces	여러 패키지를 같은 프로젝트 안에서 연결	사내 패키지와 앱을 한 저장소에서 함께 개발	workspace 경계가 느슨하면 거대한 단일 앱처럼 엉킨다.
Yarn constraints	workspace별 package.json 규칙을 선언적으로 강제	engines.node, 금지 의존성, 버전 통일 규칙	팀 고유 규칙이 많아지면 유지보수 owner가 필요하다.
Turborepo	작업 캐시와 스케줄링으로 monorepo task 실행을 최적화	lint, test, build가 많은 JS·TS 저장소	캐시 신뢰성과 원격 캐시 접근 권한을 같이 관리해야 한다.
Nx	프로젝트 관계와 영향 범위를 이해하는 monorepo 도구	앱·라이브러리 관계가 복잡한 조직	도구가 관계를 알도록 경계를 꾸준히 선언해야 한다.

이 조건이면 pnpm catalog부터 시작한다.

버전 파편화가 주된 문제이고 패키지 매니저를 pnpm으로 통일할 수 있는 팀이다.

이 조건이면 Yarn constraints나 별도 점검 스크립트를 같이 둔다.

팀이 직접 버전을 넣는 실수를 CI에서 막아야 하고 engines, license, forbidden package 같은 규칙도 함께 검사해야 하는 경우다.

실전 순서: 한 번에 합치지 말고 카탈로그부터 만든다

모노레포 전환은 모든 저장소를 한 번에 이동하는 빅뱅 작업으로 시작하면 실패 확률이 높다.

운영팀 입장에서는 먼저 표준 의존성 세트와 CI 게이트를 만들고, 참조 앱 몇 개로 검증한 뒤 서비스별 적용률을 올리는 쪽이 안전하다.

현재 서비스별 React, Next.js, TypeScript, ESLint, 테스트 도구 버전을 목록으로 만든다.
중복 버전 수, lockfile 크기, 설치 시간, dev server 시작 시간, CI build 시간을 기준선으로 저장한다.
stable 카탈로그 하나와 다음 후보 카탈로그 하나를 만들고 파괴적 변경 여부를 분리한다.
참조 앱 2~3개에서 catalog 참조로 바꾼 뒤 로컬 설치, 개발 서버, 테스트, 빌드를 확인한다.
package.json 직접 버전 입력을 막는 constraints 또는 점검 스크립트를 CI에 넣는다.
캐시 키는 OS, 패키지 매니저, lockfile hash, catalog 이름을 기준으로 짧게 구성한다.
카탈로그 변경 PR에는 영향 workspace 목록, migration script, rollback catalog, 서비스 오너 확인을 필수로 둔다.
보안 패치는 긴 승인 흐름을 기다리지 않도록 긴급 카탈로그 경로를 따로 정한다.
적용률이 80%를 넘기 전까지는 예외 서비스 목록과 제거 예정일을 매주 갱신한다.

이 순서에서 가장 중요한 지점은 기준선 측정이다.

기준선 없이 카탈로그를 도입하면 성공 여부가 개발자 만족도 설문으로만 남는다.

CI 비용을 줄이는 기준: 캐시보다 영향 범위가 먼저다

GitHub dependency caching 문서는 cache action이 key의 정확한 일치, 부분 일치, restore keys 순서로 캐시를 찾는다고 설명한다.

같은 문서는 기존 cache 내용을 변경할 수 없고 새 key로 새 cache를 만들어야 한다고 안내한다.

이 사실은 모노레포 DevOps 운영에서 캐시 키 설계가 운영 정책이라는 뜻이다.

캐시 키가 너무 넓으면 오래된 의존성이 살아남고, 너무 좁으면 모든 PR이 cache miss를 만든다.

CI 항목	좋은 기준	나쁜 신호	조치
캐시 키	OS, 패키지 매니저, lockfile hash, catalog 이름을 포함	서비스명만 넣어 lockfile 변경을 반영하지 못함	키 설계를 문서화하고 miss 원인을 대시보드로 본다.
작업 범위	변경된 workspace와 의존 workspace만 test/build	모든 PR에서 전체 저장소를 매번 빌드	Nx, Turborepo, 자체 graph script 중 하나로 영향 범위를 계산한다.
필수 게이트	catalog check, lint, affected test, security check를 분리	하나의 거대한 job이 실패 원인을 숨김	job을 목적별로 나누고 실패 owner를 지정한다.
러너 사용 시간	install, test, build, deploy 시간을 단계별 기록	월말 비용만 보고 원인을 모름	PR별 duration과 cache hit을 함께 기록한다.
예외 처리	예외 서비스와 제거 예정일을 PR에 남김	오래된 서비스가 계속 직접 버전을 사용	backlog와 owner를 카탈로그 정책에 연결한다.

이 조건이면 캐시 최적화가 먼저다.

설치 시간이 전체 CI 시간의 절반 이상이고 lockfile 변경이 잦은 저장소다.

이 경우는 영향 범위 계산이 먼저다.

테스트와 빌드가 수천 개 task로 늘어나 캐시가 맞아도 전체 실행 시간이 줄지 않는 저장소다.

보안 기준: 카탈로그는 공급망 통제 지점이다

SLSA 문서는 소프트웨어 공급망 보안을 점진적으로 개선하기 위한 수준과 provenance를 포함한 권장 증적 형식을 설명한다.

모노레포에서 카탈로그는 단순한 편의 기능이 아니라 취약 패키지 대응, 출처 검증, 릴리스 증적을 연결하는 지점이 된다.

Toss 글도 공급망 공격으로 서드파티 패키지 보안 문제가 발생했을 때 패치 버전을 카탈로그에 적용해 신속히 대응할 수 있었다고 설명한다.

보안 항목	확인 기준	위험 신호	실무 조치
패키지 버전 통제	보호 의존성은 catalog 참조만 허용	서비스가 직접 버전을 넣어 패치 전파가 끊김	CI에서 직접 버전을 실패 처리한다.
변경 증적	카탈로그 변경 PR에 영향 범위와 승인자를 남김	보안 패치가 어느 서비스에 적용됐는지 모름	catalog adoption report를 저장한다.
빌드 출처	릴리스 job과 커밋, 빌드 환경이 추적 가능	로컬 빌드 산출물이 배포됨	CI 기반 릴리스와 증적 보관을 기본으로 둔다.
권한 경계	플랫폼 카탈로그 owner와 서비스 owner 권한 분리	모든 개발자가 stable 카탈로그를 바꿈	CODEOWNERS와 branch protection을 적용한다.
긴급 패치	보안 패치 카탈로그는 빠른 경로와 사후 리뷰를 둠	월간 릴리스까지 취약 버전이 방치됨	emergency catalog와 rollback catalog를 함께 만든다.

이 조건이면 중앙 통제를 강화한다.

공통 인증, 결제, 디자인 시스템, 로깅 패키지가 여러 서비스에 깔려 있고 보안 패치가 빠르게 전파되어야 하는 경우다.

이 경우는 중앙 통제를 줄인다.

실험 서비스나 연구 저장소까지 같은 카탈로그 승인 흐름에 묶어 제품팀 속도를 불필요하게 늦추는 경우다.

실무 스켈레톤 1: 카탈로그 변경 정책

아래 YAML은 바로 붙여 쓰는 정답이 아니라 모노레포 DevOps 운영 회의에서 owner와 실패 조건을 정리하기 위한 출발점이다.

# monorepo-catalog-policy.yaml
# 목적: 모노레포 DevOps 운영에서 의존성 카탈로그 변경을 배포 리스크로 관리한다.
# 실제 패키지명과 담당 조직명은 내부 기준으로 바꾼다.

catalog_policy:
  owner: frontend-platform
  default_catalog: stable-26.08
  release_window: monthly
  emergency_patch_window: security-only
  allowed_package_managers:
    - pnpm
    - yarn
  protected_packages:
    react: catalog-only
    next: catalog-only
    typescript: catalog-only
    eslint: catalog-only
    design-system: catalog-only

change_rules:
  patch_change:
    required_checks:
      - impacted_workspace_list
      - lockfile_diff_review
      - smoke_test_on_reference_apps
      - ci_cache_key_refresh
  major_change:
    required_checks:
      - new_catalog_name
      - migration_script
      - service_owner_acknowledgement
      - rollback_catalog
      - release_note

ci_gates:
  fail_when:
    - package_uses_direct_version_for_protected_dependency
    - workspace_depends_on_forbidden_package
    - cache_key_uses_outdated_lockfile
    - package_json_changed_without_owner_review

실무 스켈레톤 2: package.json 규칙 점검

Yarn constraints를 쓰는 팀은 workspace 전반의 의존성 규칙을 선언적으로 강제할 수 있다.

// yarn.config.cjs
// 목적: 워크스페이스별 package.json에서 핵심 의존성 정책을 자동 점검한다.
// 실제 패키지명과 버전은 카탈로그 정책에 맞춰 조정한다.

module.exports = {
  async constraints({ Yarn }) {
    for (const dep of Yarn.dependencies({ ident: 'react' })) {
      dep.update('catalog:stable');
    }

    for (const dep of Yarn.dependencies({ ident: 'typescript' })) {
      dep.update('catalog:stable');
    }

    for (const workspace of Yarn.workspaces()) {
      workspace.set('engines.node', '>=22');
    }
  },
};

pnpm 팀이라면 같은 목적을 별도 점검 스크립트와 catalog check 명령으로 구현할 수 있다.

# catalog_guard.py
# 목적: 보호 의존성이 직접 버전으로 들어간 package.json을 찾는 사전 점검 예시다.
# 운영 반영 전에는 pnpm/Yarn 공식 기능과 함께 사용한다.

import json
from pathlib import Path

protected = {'react', 'next', 'typescript', 'eslint'}
violations = []

for path in Path('.').glob('packages/*/package.json'):
    data = json.loads(path.read_text())
    for section in ['dependencies', 'devDependencies', 'peerDependencies']:
        deps = data.get(section, {}) or {}
        for name, spec in deps.items():
            if name in protected and not str(spec).startswith('catalog:'):
                violations.append(f'{path}:{section}:{name}:{spec}')

if violations:
    raise SystemExit('
'.join(violations))

print('catalog policy ok')

실무 스켈레톤 3: CI 캐시와 카탈로그 게이트

GitHub Actions를 쓰는 팀은 lockfile과 카탈로그 변경 파일을 캐시와 PR trigger의 중심에 둬야 한다.

name: monorepo-catalog-ci

on:
  pull_request:
    paths:
      - 'package.json'
      - 'packages/**/package.json'
      - 'pnpm-workspace.yaml'
      - 'yarn.config.cjs'
      - 'pnpm-lock.yaml'
      - 'yarn.lock'

jobs:
  catalog-guard:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'pnpm'
          cache-dependency-path: 'pnpm-lock.yaml'
      - run: corepack enable
      - run: pnpm install --frozen-lockfile
      - run: pnpm catalog:check
      - run: pnpm test --filter './packages/*'

실무 시나리오 1: 레거시 서비스가 최신 React 전환을 막을 때

10개 서비스 중 2개만 오래된 React 버전을 쓰지만 공통 UI 패키지가 그 2개 때문에 메이저 개선을 못 하는 상황을 가정하자.

이 조건이면 기존 stable 카탈로그를 그대로 두고 새 stable-next 카탈로그를 만들어 참조 앱에서 먼저 검증한다.

서비스 오너에게는 변경 PR, 자동 수정 스크립트, 실패 시 되돌릴 카탈로그를 함께 제공한다.

이 경우는 보류한다.

카탈로그 이름만 바꾸고 실제 UI 회귀 테스트나 서비스별 owner 확인 없이 전체 저장소에 일괄 적용하는 경우다.

실무 시나리오 2: CI 시간이 월 단위로 계속 늘 때

모노레포의 PR 하나가 전체 lint, 전체 test, 전체 build를 매번 돌려 20분 넘게 걸리는 상황을 가정하자.

이 조건이면 먼저 task별 시간을 나누고 cache hit, cache miss, affected workspace 수를 같은 표에 기록한다.

그 다음 Turborepo나 Nx 같은 도구 또는 자체 graph script로 변경 영향 범위를 줄인다.

이 경우는 캐시만 늘려도 효과가 약하다.

모든 PR이 여전히 전체 task를 실행하면 캐시가 맞아도 runner 대기열과 실패 원인 추적 시간이 남는다.

실무 시나리오 3: 취약 패키지 긴급 패치가 필요할 때

공통 패키지에서 취약점이 발견되어 모든 서비스가 같은 날 패치를 받아야 하는 상황을 가정하자.

이 조건이면 emergency catalog를 만들고 보호 의존성을 catalog 참조로 바꾼 서비스만 빠르게 패치 적용률을 계산한다.

SLSA 관점에서는 어떤 커밋과 어떤 빌드 환경에서 산출물이 만들어졌는지 증적을 남겨야 한다.

이 경우는 위험하다.

서비스마다 직접 버전을 들고 있어 어떤 앱이 취약 버전을 계속 쓰는지 lockfile 검색 말고는 확인할 방법이 없는 상태다.

도입 전 체크리스트

공통 의존성 10개를 골라 서비스별 버전 분포와 예외 이유를 표로 만든다.
카탈로그 owner, 승인자, 긴급 패치 담당자, 실패 시 되돌릴 권한자를 분리한다.
CI 기준선으로 install, lint, test, build, cache hit, affected workspace 수를 2주 이상 저장한다.
카탈로그 변경 PR에는 성능 숫자와 실패 서비스 목록을 자동으로 붙인다.
직접 버전 입력, 금지 의존성, engines.node 불일치를 CI에서 실패 처리한다.
공급망 보안팀과 릴리스 증적 보관 기간, 서명, SBOM, 취약점 대응 경로를 합의한다.
예외 서비스는 예외 승인일, 제거 예정일, 담당자를 notes가 아니라 추적 가능한 이슈로 남긴다.