GRAXEL 오픈 — 하나의 계정으로 모든 서비스를

SaaS Factory 런칭기: 1인 개발자의 모노레포(Monorepo) 생존 전략

오늘은 GRAXEL 생태계의 모든 서비스를 하나로 묶어낸 프로젝트, 'SaaS Factory 모노레포' 출범 소식을 전합니다. 1인 개발자로 활동하면서 초기에는 아이디어가 떠오를 때마다 새로운 GitHub 리포지토리를 파곤 했습니다. MyHyetaek 하나, JobFit 하나, 포털 하나... 그러다 보니 어느새 리포지토리가 5개로 늘어나 있더군요.

재앙은 그때부터 시작되었습니다. 디자인 시스템(UI 컴포넌트) 버튼 색상 하나를 바꾸려면 리포지토리 5개를 돌아다니며 복사 붙여넣기를 해야 했습니다. Next.js 보안 업데이트라도 뜨는 날엔 하루 종일 `npm install`만 치다가 하루가 다 갔습니다. "도저히 이렇게는 못 살겠다. 나 혼자서 팀처럼 일할 수 있는 구조가 필요하다." 이것이 SaaS Factory 모노레포를 결심하게 된 가장 큰 동기였습니다. 저의 고군분투기가 궁금하시다면 GRAXEL 스토리를 읽어보시길 권합니다.

도입한 기술 스택: pnpm + Turborepo + Next.js 15

구글이나 메타 같은 거대 기업이 쓰는 Bazel 같은 복잡한 도구는 저에게 과했습니다. 프론트엔드 생태계에서 가장 실용적인 조합을 찾았고, 결론은 pnpm workspaces와 Turborepo의 결합이었습니다.

pnpm은 하드 링크(Hard link) 방식을 사용하여 디스크 용량을 획기적으로 아껴주고 의존성 설치 속도가 매우 빠릅니다. Turborepo는 여러 패키지의 빌드 작업을 병렬로 처리하고, 한 번 빌드한 결과물은 강력한 캐싱(Caching) 기능으로 재사용합니다. 덕분에 코드 한 줄 수정하고 15분씩 기다리던 빌드 시간이 단 2분으로 단축되었습니다. 코어 프레임워크로는 App Router의 안정성이 높아진 Next.js 15를 일괄 적용했습니다.

첫 마이그레이션에서 마주친 지옥의 3가지 에러

물론 낭만만 있었던 것은 아닙니다. 5개의 분리된 프로젝트를 하나의 폴더 구조(apps/*와 packages/*)로 합치는 과정은 고통 그 자체였습니다.

1. 유령 의존성(Phantom Dependencies) 문제: npm을 쓸 때는 호이스팅(Hoisting) 덕분에 명시하지 않은 패키지도 몰래 가져다 쓸 수 있었습니다. 하지만 엄격한 pnpm 환경으로 오자 수백 개의 '모듈을 찾을 수 없습니다' 에러가 터져 나왔습니다. 3일 밤낮을 새며 package.json들을 정규화해야 했습니다.
2. TypeScript 설정의 지옥: 30개가 넘는 내부 패키지들 간에 타입을 공유해야 했습니다. tsconfig.json을 공통 패키지(@graxel/tsconfig)로 빼내어 상속받는 구조를 잡기 전까지 수많은 `any`의 유혹에 시달렸습니다.
3. Vercel / Cloudflare 배포 설정 꼬임: 루트 디렉토리가 바뀌면서 기존 CI/CD 파이프라인이 붕괴되었습니다. 루트의 turbo.json을 튜닝하여 각 환경에 맞는 환경변수(Env)와 빌드 아웃풋을 매핑하는 삽질을 거쳤습니다.

첫 6개월의 성과, 그리고 한계

마이그레이션을 완료한 지 6개월이 지났습니다. 현재 SaaS Factory 내부에는 5개의 라이브 서비스와 UI, Auth, DB 커넥션, 다국어 처리 등을 담당하는 30여 개의 재사용 가능한 패키지가 존재합니다. 이제 새로운 아이디어가 생기면 npx turbo gen 명령어 한 번으로 몇 분 만에 기존 인프라를 모두 상속받은 새 앱을 찍어낼 수 있습니다. 마치 공장(Factory)처럼요!

하지만 단점도 명확합니다. 프로젝트 규모가 커지면서 IDE(VS Code)가 코드를 분석할 때 가끔 버벅거리거나 메모리를 과도하게 점유하는 현상이 발생합니다. 또한 pnpm 공식 문서를 팀원(미래의 저)에게 교육해야 하는 러닝 커브도 무시할 수 없죠. 모노레포와 멀티레포 사이에서 고민했던 치열한 회고는 다른 포스팅인 모노레포 vs 멀티레포 회고기에 자세히 남겨두었으니 꼭 확인해 보세요.