정지용
기술스택 목록
도구

Monorepo

프로젝트 2에서 사용했습니다. 각 프로젝트에서 어떤 역할로 썼는지 아래에 정리했습니다.

이 기술은 무엇인가요?

여러 개의 관련 프로젝트를 하나의 저장소·워크스페이스로 통합 관리하는 개발 방식

Monorepo는 프런트엔드, 백엔드, 컨트랙트, 크롤러 등 서로 다른 역할을 가진 여러 서브 프로젝트를 하나의 코드 저장소 안에서 함께 관리하는 방식이다. 프로젝트가 늘어나면서 저장소가 분산되면 공통 코드 중복, 버전 불일치, 변경 이력 추적의 어려움 같은 문제가 생기는데, 이를 하나의 워크스페이스로 묶어 해결하려는 목적으로 사용된다. 여러 서브 프로젝트가 서로 의존하거나 함께 배포·테스트되어야 하는 경우 특히 유용하다.

이럴 때 사용합니다

  • 여러 서브 프로젝트가 코드나 타입, 설정을 공유해야 할 때
  • 프로젝트 간 변경 사항을 하나의 커밋·PR로 함께 추적하고 싶을 때
  • 전체 서비스가 여러 컴포넌트(백엔드·프런트엔드·컨트랙트 등)로 구성될 때
  • 일관된 빌드·테스트·배포 파이프라인을 여러 프로젝트에 동일하게 적용하고 싶을 때

핵심 개념

Workspace
하나의 저장소 안에 존재하는 여러 서브 프로젝트(패키지)들의 묶음으로, 공통 설정과 의존성을 함께 관리한다.
Package
워크스페이스를 구성하는 개별 단위로, 각자 독립적인 기능이나 배포 대상을 가진 하나의 서브 프로젝트를 의미한다.
Shared Dependency
여러 서브 프로젝트가 공통으로 사용하는 라이브러리나 코드로, 모노레포에서는 이를 한 곳에서 관리해 중복과 버전 불일치를 줄인다.
Build Orchestration
여러 패키지 간의 의존 관계를 파악해 빌드·테스트 순서를 자동으로 결정하고 실행하는 과정이다.
Task Runner / Cache
변경된 패키지만 골라 빌드·테스트를 다시 실행하고 결과를 캐시해 반복 작업을 줄여주는 도구 기능이다.

기본 워크스페이스 설정 예시

루트 package.json에서 workspaces 필드로 하위 packages 디렉터리의 모든 서브 프로젝트를 하나의 워크스페이스로 묶어 관리한다.

JSON
{
  "name": "my-monorepo",
  "private": true,
  "workspaces": [
    "packages/*"
  ],
  "scripts": {
    "build": "npm run build --workspaces",
    "test": "npm run test --workspaces"
  }
}

처음 쓸 때 흔한 함정

  • 서브 프로젝트 간 의존 관계를 명확히 설정하지 않으면 빌드 순서 문제가 발생한다
  • 저장소 규모가 커지면 클론·설치·빌드 시간이 늘어날 수 있다
  • 각 서브 프로젝트의 독립 배포·버전 관리 전략을 별도로 고민해야 한다

위 개요는 기술 학습을 돕기 위해 자동 생성된 일반 설명입니다. 정확한 사양과 최신 정보는 공식 문서를 확인하세요.

프로젝트별 활용 방식

위 개념이 실제 프로젝트에서 어떻게 쓰였는지 보여줍니다.

  1. 01Web3
    2026년 7월

    패션 NFT 홀더 인증 모노레포

    백엔드·프런트엔드·컨트랙트·Discord 홀더 인증을 하나의 워크스페이스로 묶은 패션 NFT 프로젝트 구조

    이 프로젝트에서의 Monorepo 활용

    백엔드, 프런트엔드, 컨트랙트 등 다수 서브 프로젝트를 단일 워크스페이스로 관리

    nft-fashion-monorepo-docs프로젝트 자세히 보기 →

함께 사용한 기술

위 프로젝트들에서 같이 쓰인 다른 기술입니다.