프론트 구조, 지금 모노레포로 가야 할까

차세대 프로젝트 초반, 구조 회의에서 가장 오래 갈렸던 주제가 있었다. 모노레포냐, 멀티레포냐, 일단 단일 레포냐.

모노레포가 끌렸던 이유

• 공통 타입/유틸 공유가 쉬워 보였다.
• 린트/포맷 기준을 한 번에 맞출 수 있었다.
• 프론트·문서·스크립트를 같이 볼 수 있었다.

망설였던 이유

• CI 시간이 늘어날 수 있었다.
• 팀 경험치가 고르지 않았다.
• 초기에 경계가 흐려 “다 공유”로 흐를까 봤다.
• 배포 단위가 커질 수 있었다.

당시 결론

“이상적인 구조”보다 지금 팀이 유지할 수 있는 구조를 택했다. 당장은 도메인 분리와 타입 경계를 먼저 맞추고, 레포 전략은 변경 비용이 보일 때 다시 본다고 적어뒀다.

모노레포라는 새로운 구조에 끌리면서도, 나는 ‘지금 도입하면 팀이 감당할 수 있나’를 먼저 물었다. 결정을 미룬 게 아니라, 되돌릴 수 있는 형태로 보류한 것에 가깝다. 도메인·타입 경계만 먼저 잡아두면, 나중에 어느 쪽으로 가든 비용이 작아질 거라고 봤다.

비슷한 경험 — 결정을 ‘되돌릴 수 있게’ 미룬 패턴

이 “지금 정하지 않고, 되돌릴 수 있게 준비만 해두기”는 내가 반복해 온 방식이었다.

• SSO 롤아웃에서도 일괄 전환 대신 단계적 통합 + 롤백 루트를 먼저 깔았다.
• ES5→ES6 이전에서도 한 번에 SPA로 가지 않고 iframe으로 얹고 넓히는 길을 택했다.
• 이유: 새로움이 주는 이득은 확실치 않지만, 잘못된 큰 결정의 비용은 확실히 컸다. 그래서 “큰 결정을 작게 쪼개고, 신호가 보일 때 진짜로 정한다”를 기준으로 삼았다.
• 공통된 결론: 중요한 건 정답을 빨리 맞히는 게 아니라, 틀렸을 때 싸게 되돌릴 수 있게 설계하는 것이었다.

개선점 (지금 부족한 것)

• ‘변경 비용이 보일 때 다시 본다’고 적어뒀지만, 그 ‘보일 때의 신호(트리거)‘를 구체적으로 정의하지 못했다. 자칫 무한 보류가 된다.
• 단일 레포 안에서 도메인 경계가 흐려지면, 막상 분리하려 할 때 의존이 엉켜 비용이 커진다.
• 결정을 보류한 만큼, 그 보류 사유와 재검토 시점을 기록으로 남기는 습관이 약하다.

앞으로 나가야 할 방향

1. 레포 전략 재검토의 트리거를 구체화한다. 예: 빌드 시간 N분 초과, 패키지 간 순환 의존 발생, 배포 주기 분리 필요 등.
2. 지금부터 import 경계를 ESLint로 강제해, 나중에 모노레포로 쪼갤 때 의존이 깔끔히 끊기도록 준비한다(클린코드 플레이북 연계).
3. 구조 결정을 ADR(결정 기록) 로 남겨, “왜 보류했고 언제 다시 볼지”를 팀이 추적할 수 있게 한다.
4. 공통 타입·유틸의 소유 경계를 React 아키텍처 기준과 맞춰, 전환 시점에 흔들림을 줄인다.

지금 돌아보면

구조 논쟁은 기술 선택이 아니라, 의사결정 속도와 책임 범위 싸움이었다.

아직 정답은 없다. 다만 “유행 구조”보다 “읽히는 구조”를 우선했다. 다음 목표는, 그 선택을 감으로 미루는 게 아니라 기준으로 미루는 것. 즉 “언제 다시 볼지”까지 적어두는 데까지 가는 것이다.