Read Original
#Frontend

모노레포가 미리캔버스 프론트엔드 아키텍처를 뒷받침 하는 방법 [1/2]

모노레포가 미리캔버스 프론트엔드 아키텍처를 뒷받침 하는 방법 [1/2]
01

Summary

당신의 모노레포는 진짜 독립적인가요? '모노레포 모놀리스' 탈출기

미리캔버스가 변화율 기반 레이어드 아키텍처로 거대 코드베이스의 복잡성을 정복한 전략을 공개합니다.

모노레포 도입 후 흔히 겪는 '공통 패키지의 늪'과 결합도 문제를 해결하기 위한 구조적 접근법을 다룹니다. 클린 아키텍처의 안정된 의존성 원칙(SDP)을 프론트엔드에 이식하여, 단순한 코드 공유를 넘어 지속 가능한 확장성을 확보하는 실전 가이드를 제시합니다.

  • 01공통 패키지에 도메인 지식이 섞일 때 발생하는 '공통 패키지 함정' 분석
  • 02변화율(Rate of Change)을 기준으로 설계된 6단계 프론트엔드 레이어드 아키텍처
  • 03단방향 의존성 및 동일 계층 참조 금지 규칙을 통한 복잡도 제어
  • 04Public API 패턴과 린터를 활용한 아키텍처 규칙의 실질적 강제화
  • 05Stable Dependencies Principle(SDP) 기반의 안정적인 컴포넌트 설계 철학

RECOMMENDATION

모노레포를 사용 중이지만 서비스 간 간섭이 심해 고민인 시니어 엔지니어나, 대규모 프론트엔드 아키텍처 설계를 고민하는 팀 리더에게 강력히 추천합니다.

The Problem

모노레포 환경에서 '공통(common)' 패키지가 비대해지며 도메인 로직과 결합되는 '모노레포 모놀리스' 현상이 발생했습니다. 이로 인해 유틸리티 함수 수정 시에도 수십 분의 CI 시간이 소요되고, 한 팀의 변경이 다른 팀의 개발을 방해하는 병목 현상이 심화되었습니다.

The Solution

변화율(Rate of Change)을 기준으로 shared, entity, feature, service, fragment, application의 6개 계층으로 나누는 레이어드 아키텍처를 도입했습니다. 계층 간 단방향 의존성 및 동일 계층 참조 금지 규칙을 설정하고, Public API 패턴과 린터를 통해 이를 강제했습니다.

The Result

논리적 독립성을 확보하여 도메인 지식의 무분별한 전파를 막고 변경 범위를 예측 가능한 수준으로 격리하는 데 성공했습니다. 아키텍처 규칙을 도구가 직접 강제하게 함으로써 개발자의 실수를 방지하고 팀별 개발 자율성을 회복했습니다.

Trade-off

엄격한 계층 분리와 Public API 패턴 적용으로 인해 단순 기능을 구현할 때도 더 많은 파일 생성과 구조적 검토가 필요해져 초기 개발 복잡도가 증가했습니다. 또한 아키텍처 규칙을 검증하기 위한 CI 단계의 자동화 도구 구축 및 유지보수 비용이 발생합니다.

03

Key Concepts

Concept · 01

모노레포 모놀리스 (Monorepo Monolith)

코드는 물리적으로 하나의 저장소에 모여 있으나, 내부 모듈들이 강하게 결합되어 논리적으로는 거대한 덩어리처럼 동작하는 상태입니다.

  • 공통 패키지에 도메인 로직이 섞여 의존성 전파가 심화되는 현상
  • 한 곳의 수정이 전체 서비스의 재빌드와 예상치 못한 오류를 유발하는 구조적 결함
Concept · 02

안정된 의존성 원칙 (Stable Dependencies Principle)

컴포넌트는 항상 자신보다 더 안정적인, 즉 변화율이 낮은 컴포넌트에 의존해야 한다는 아키텍처 설계 원칙입니다.

  • 미리캔버스 레이어드 아키텍처의 계층 순서를 결정하는 핵심 근거
  • 변화가 잦은 상위 계층이 도메인 중립적인 하위 계층을 참조하도록 설계
Concept · 03

Public API 패턴

각 패키지의 내부 구현 세부사항은 은닉하고, index.ts와 같은 지정된 진입점을 통해서만 기능을 노출하는 방식입니다.

  • 패키지 내부 리팩터링 시 외부 코드에 미치는 영향을 최소화하는 캡슐화 기법
  • 린터(Linter)를 통해 내부 파일에 대한 직접 접근을 원천 차단하여 결합도 제어