#모노레포 전환기: 플러그링크의 코드 통합 여정

플러그링크는 초기에 서비스별로 독립된 레포지토리를 운영했습니다. 하지만 서비스가 성장하면서 코드 중복, 의존성 관리의 어려움, 그리고 팀 간 협업의 비효율이 심각해졌습니다.

#왜 모노레포인가

멀티레포 환경에서 가장 큰 문제는 공통 코드의 동기화였습니다. 디자인 시스템, API 클라이언트, 유틸리티 라이브러리 등 여러 서비스에서 공유하는 코드가 각 레포에 복사되어 있었고, 하나를 수정하면 나머지도 수동으로 업데이트해야 했습니다.

# 기존 멀티레포 구조
pluglink-web/
pluglink-api/
pluglink-admin/
pluglink-shared/   # 이 패키지의 버전 관리가 악몽이었습니다

#Turborepo 도입

저희는 여러 모노레포 도구를 비교한 끝에 Turborepo를 선택했습니다.

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

#핵심 이점

빌드 캐싱: Remote caching으로 CI 시간을 60% 단축
의존성 그래프: 변경된 패키지만 빌드하는 incremental build
태스크 파이프라인: 병렬 실행으로 로컬 개발 경험 개선

#마이그레이션 전략

한 번에 모든 레포를 통합하는 것은 위험하다고 판단했습니다. 점진적 마이그레이션을 선택했고, 총 3단계에 걸쳐 진행했습니다.

#1단계: 공통 패키지 통합

가장 먼저 pluglink-shared를 모노레포의 packages/ 디렉토리로 이동했습니다.

#2단계: 신규 서비스부터 모노레포에 생성

새로 만드는 서비스는 모노레포 안에서 시작하도록 정책을 변경했습니다.

#3단계: 기존 서비스 순차 이관

트래픽이 적은 서비스부터 순차적으로 이관하며, 각 단계마다 충분한 모니터링 기간을 두었습니다.

#결과

CI/CD 파이프라인 실행 시간: 12분 → 5분
공통 코드 업데이트 시간: 수일 → 수분
코드 리뷰 효율성: 한 PR에서 관련 변경사항을 모두 확인 가능

모노레포 전환은 결코 쉬운 결정이 아니었지만, 팀의 생산성과 코드 품질 모두에서 긍정적인 변화를 가져왔습니다.