개인 프로젝트에서 왜 모노레포를 선택했는가
최근 축덕 퀴즈 프로젝트를 관리하면서 프론트와 백엔드를 분리 운영하다가 모노레포 구조로 정리했다.
처음에는 “굳이?”라는 생각이 있었는데, 실제로 적용해 보니 생각보다 관리가 편해진 부분이 있었다.
이번 글에서는 왜 전환했고, 어떤 점이 좋아졌고, 무엇이 불편했는지 정리해 봤다.
기존 구조 — 프런트/백엔드 분리
처음 구조는 단순했다.
football-quiz-web
football-quiz-api프론트와 백엔드를 각각 관리했다.
장점:
- 이해하기 쉬움
- 배포 단위 분리
하지만 개발하면서 조금씩 불편해졌다.
예시:
API 변경
↓
프론트 타입 수정
↓
각각 커밋
↓
버전 안 맞음특히 DTO나 API 응답 구조가 자주 바뀌면서 관리 비용이 생겼다.
모노레포 구조로 전환
정리 후 구조:
football-quiz/
apps/
├── web
└── api
packages/
└── shared
pnpm-workspace.yaml구성:
- apps/web → React + Vite
- apps/api → NestJS
- packages/shared → 공통 타입
왜 모노레포를 선택했나
1. 한 번에 실행 가능
이전:
cd football-quiz-api
npm run dev
cd ../football-quiz-web
npm run dev전환 후:
pnpm dev한 번에 실행.
2. 공통 타입 관리
예전:
// web
type Ranking = {
streak:number
}
// api
class RankingDto각자 관리.
전환 후:
export interface Ranking {
streak:number
nickname:string
}공유.
프론트·백엔드 타입 불일치가 줄었다.
3. 커밋 흐름 단순화
이전:
api 수정
↓
push
↓
web 수정
↓
push전환 후:
하나의 PR관련 변경을 한 번에 볼 수 있었다.
실제로 해보니 어려웠던 점
배포 설정
프론트:
Root Directory
apps/web백엔드:
Root Directory
apps/api배포 플랫폼마다 별도 설정 필요.
node_modules 감각 바뀜
처음에는 왜 루트에 설치되는지 헷갈렸다.
root
└── node_modules하지만 익숙해지면 오히려 관리가 쉬웠다.
언제 모노레포가 좋은가
추천:
✅ 프론트 + 백엔드를 같이 관리
✅ 타입 공유 많음
✅ 혼자 운영하는 프로젝트
비추천:
❌ 완전히 독립된 서비스
❌ 팀마다 릴리즈 주기 다름
정리
모노레포가 무조건 좋은 건 아니다.
다만 개인 프로젝트처럼 프론트와 백엔드를 동시에 수정하는 경우에는 생각보다 관리 비용이 줄었다.
특히 공통 타입 공유와 변경 추적이 가장 체감됐다.
오늘의 한 줄
프로젝트가 커질수록 코드를 나누는 것보다, 관계를 관리하는 비용이 더 커진다.