요약
1. NX를 활용해 Monorepo 환경에서 FE/BE 공용 라이브러리와 여러 서비스를 효율적으로 관리한 경험 공유
2. Cache 기반 빌드 성능, 라이브러리 구조화 등의 장점과 함께 플러그인 구조의 한계 및 잦은 Breaking Change를 다룸
서론
이전에 MSA 프로젝트를 개발하면서 Backend Repository가 많아지는데, 공용 라이브러리나 타입을 공유하기가 어려운 문제가 있었다.
그러다 NX 16 버전부터 본격적으로 Monorepo 환경을 도입해서 운영해왔다.
Monorepo 자체의 장점도 있었지만, 특히 NX의 캐시 기반 빌드 성능은 프로젝트 운영 방식에 큰 변화를 가져왔다.
이번 글에서는 NX를 Monorepo 도구로 사용하면서 느꼈던 장점과 단점, 그리고 실전에서 고려해야 했던 부분들을 정리해보려고 한다.
Monorepo가 필요한 이유
초기에는 FE나 BE의 다양한 프로젝트가 가 각각 독립된 저장소로 운영되고 있었고, 동일한 도메인 로직이나 API 타입을 서로 복사해서 사용하는 일이 잦았다.
이 방식의 문제점은 다음과 같다.
- 코드 중복으로 인해 유지보수 비용 증가
- 공통 모듈을 수정할 때 모든 프로젝트를 일일이 반영해야 함
- 프로젝트별 설정 편차가 커서 통일된 개발 환경 유지가 어려움
Monorepo의 핵심 목적은 “변경을 단일한 워크스페이스에서 관리하고, 중복 로직을 최소화하는 것”이었다.
NX는 이를 체계적으로 지원하는 훌륭한 도구였다.
NX를 사용하면서 느낀 장점
1. 라이브러리 구조화를 통한 체계적인 코드 관리
NX는 라이브러리를 쉽게 만들고 앱 간에 공유할 수 있는 구조를 제공한다.
이를 활용하면 다음과 같은 구조로 코드를 정리할 수 있다.
- FE ↔ BE 공용 API 타입 모듈
- 인증/인증 관련 공통 모듈
- 도메인별 유틸 라이브러리
- 여러 서버에서 공유하는 공용 데이터베이스 모듈
이 덕분에 중복 코드가 사라지고, 변경을 한 곳에서 관리할 수 있게 되었다.
2. NX의 강력한 Build Cache
NX의 가장 큰 장점은 캐시 기반 빌드 성능 최적화다.
- 변경되지 않은 라이브러리/앱의 빌드 결과를 자동 캐싱
- 의존하고 있는 라이브러기가 변경 시, 자동을오 의존하고 있는 앱들에 대해서 재 빌드/테스트 실행
- 테스트, 빌드, 린트 모두 캐싱 적용 가능
- CI에서는 NX Cloud를 활용한 Remote Cache로 속도 ↑
대규모 워크스페이스일수록 이 효과는 더 크게 체감된다.
실제 프로젝트에서는 CI 시간이 절반 이하로 줄어드는 경험도 있었다.
NX Plugin – 장점과 단점이 극명한 기능
NX Plugin은 초기 세팅을 매우 빠르게 만들어준다.
예를 들면:
nx g @nx/nest:application apinx g @nx/js:library shared-types
이런 방식으로 FE/BE 환경을 통일된 구조로 생성할 수 있다.
그러나 이 기능은 동시에 가장 큰 단점이 되기도 한다.
1. Customizing 난이도가 매우 높음
플러그인의 설계 구조를 크게 벗어나지 않으면 편한데,
조금 특별한 요구사항이 생기면 설정 파일이 급격히 복잡해진다.
- 빌드 파이프라인 조정 어려움
- 플러그인이 강제하는 디렉토리/구조 존재
- Webpack/Vite 설정을 깊이 수정해야 할 때 난이도 급상승
- 아예 불가능한 경우도 존재
즉, 가이드대로 사용할 때는 최고지만 벗어나면 가파르게 어려워지는 구조다.
그러다보니, 초기 러닝 커브가 어느정도 존재한다.
2. 잦은 Breaking Change
개인적인 경험으로는 NX는 메이저 버전 변화가 잦고, 그에 따른 Breaking Change도 많은 편이다.
- 설정 파일 포맷 변경
- 플러그인 동작 방식 변경
- Deprecation 증가
- Migration 스크립트가 항상 완벽하진 않음
그래서 버전 업그레이드를 할 때마다 추가적인 수동 조정이 필요했다.
적용하면서 느낀 점
NX는 Monorepo 환경을 구축하고 운영하는 데 있어 분명 강력한 도구다.
다만 NX의 마이그레이션 비용이나 커스터마이징 난이도는 실제 운영 단계에서 큰 고려 요소였다.
그럼에도 불구하고 다음과 같은 이유로 계속 NX를 사용할 것 같다.
- 대규모 프로젝트 구조를 일관성 있게 유지 가능
- 공용 모듈을 체계적으로 관리할 수 있음
- 캐시 기반 빌드 성능 개선이 매우 큼
결론적으로 NX는 "정해진 방식으로 운영하면 최고의 생산성을 주는 도구"라고 생각한다.
현재 사용중인 NX Cloud는 한달동안 CI 시간을 대략 50시간정도 단축해주고 있다.
그만큼 CI를 개선하고 싶거나, 공통 라이브러리에 대한 고민이 있으면 도입을 추천할 것 같다.
마무리
이번 글에서는 NX를 기반으로 Monorepo 환경을 구축하면서 좋았던 점과 어려웠던 부분들을 정리해보았다.
다음 글에서는 실제 프로젝트 구조, library 분리 기준, CI 최적화 과정 등을 더 상세하게 다뤄볼 예정이다.
