Monorepo에서 Multi-repo로

"모든 걸 한 곳에 넣으면 편할 줄 알았다"

프로젝트를 시작할 때, 모든 코드를 한 곳에서 관리하면 편할 거라고 생각했습니다. Frontend, Backend, 심지어 nginx 설정까지 하나의 레포지토리에 넣으면 프로젝트 전체를 한눈에 볼 수 있고, 코드 공유도 쉬울 것 같았거든요. 하지만 이 결정이 얼마나 큰 고통을 가져올지는 상상도 못했습니다.

Monorepo의 달콤한 시작

처음엔 정말 편했습니다. 프로젝트 구조는 이랬죠..

"와, 한 번의 git clone으로 모든 게 준비되네!"

VSCode에서 폴더 하나만 열면 Frontend와 Backend를 동시에 작업할 수 있었고, 공통 타입이나 상수를 공유하기도 쉬웠습니다.

패키지 설치의 카오스

그런데 가장 어리석은 실수들이 반복되기 시작했습니다. 터미널에서 작업하다 보면...

더 웃긴 건 이런 경우도 있었습니다..

루트 디렉토리의 혼란

가장 큰 문제는 루트 디렉토리에 생긴 이상한 파일들이었습니다.

"아... 내가 도대체 뭘 한 거야?"

어느 날은 이런 일도 있었습니다.

의존성 파일의 중복과 충돌

더 황당한 건, 같은 도구의 설정 파일이 여러 곳에 있을 때였습니다.

ESLint, Prettier, 심지어 .gitignore 파일까지 어디에 뭘 넣어야 할지 헷갈렸습니다.

자동 완성의 배신

가장 짜증났던 건 터미널의 자동 완성이었습니다.

매번 pwd로 현재 위치를 확인하는 습관이 생겼지만, 바쁠 때는 놓치기 일쑤였죠.

배포의 악몽이 시작되다

이런 실수들이 쌓이다 보니, 배포할 때도 문제가 생겼습니다.

Frontend용 Dockerfile인지, Backend용인지도 헷갈리고, 심지어 루트에 있는 잘못된 package.json을 복사하는 경우도 있었습니다.

Git 커밋의 혼란

실수로 잘못된 위치에 패키지를 설치하면, Git 상태도 엉망이 되었습니다.

".gitignore에 다 추가했는데 왜 계속 나타나지?" 했더니, 각 폴더별로 .gitignore가 따로 필요했던 거죠.

Multi-repo로의 전환 결정

"이러다가 운영 환경에 잘못된 패키지 올라가면 큰일나겠다..."

결국 더 큰 사고가 나기 전에 레포지토리를 분리하기로 했습니다.

분리 후의 평화

이제는 실수할 여지가 없습니다.

각 프로젝트의 루트가 곧 작업 디렉토리이니, 헷갈릴 일이 없어졌죠.

터미널 작업의 단순화

이제 터미널 탭도 명확하게 구분됩니다.

탭 이름도 "Frontend", "Backend"로 설정해두니 실수가 확 줄었습니다.

QA 관점에서의 교훈

사소해 보이는 "경로 실수"가 사실은 큰 리스크였습니다:

잘못된 의존성 설치 → 보안 취약점 발생 가능

패키지 버전 충돌 → 예상치 못한 런타임 에러

빌드 실패 → 배포 지연

개발 환경 불일치 → "내 컴퓨터에선 되는데" 현상

QA 엔지니어로서 이런 환경 설정의 중요성을 몸소 체험했습니다.

"현재 내가 어느 디렉토리에 있는지"같은 기본적인 것도 놓치면 큰 문제가 될 수 있다는 걸 배웠죠. Monorepo는 편리해 보이지만, 실수의 여지를 너무 많이 만든다는 게 가장 큰 문제였습니다.

이제는 각 레포지토리가 독립적이라, 실수해도 그 프로젝트 내에서만 영향을 받습니다. 단순함이 곧 안전함이라는 걸 깨달은 순간이었어요.

"패키지 하나 잘못 설치했다고 뭐가 그렇게 큰일이야?"라고 생각할 수 있지만, 이런 작은 실수들이 쌓여서 결국 시스템의 복잡도를 높이고, 디버깅을 어렵게 만들고, 팀워크를 해친다는 걸 알게 되었습니다.

Multi-repo로 전환한 후로는 이런 걱정 없이 각자의 도메인에 집중할 수 있게 되었고, 그게 진정한 생산성 향상으로 이어졌습니다.

마무리

Monorepo에서 Multi-repo로의 전환은 단순히 코드 저장소를 나누는 것 이상의 의미가 있었습니다. 개발자로서의 기본기, 즉 "내가 지금 어디에서 무엇을 하고 있는지"를 명확히 인지하는 것의 중요성을 깨달은 경험이었죠.

11년차 QA 엔지니어였지만, 직접 개발을 하면서 이런 기초적인 실수들을 하게 될 줄은 몰랐습니다. 하지만 이런 실수들 덕분에 개발 환경 구성의 중요성을 몸소 체험할 수 있었고, 더 나은 구조로 개선할 수 있었습니다.

"완벽한 구조는 없다. 다만 현재 상황에 가장 적합한 구조가 있을 뿐이다."

프로젝트 초기에는 Monorepo가 맞을 수 있지만, 성장하면서 Multi-repo로 전환하는 것도 자연스러운 진화 과정이라는 걸 배웠습니다. 중요한 건 현재의 문제점을 인지하고, 과감하게 개선하는 용기를 갖는 것이겠죠.

NEXT..

레포지토리를 분리했으니 이제 각각 독립적으로 배포할 수 있게 되었습니다. 하지만 개발 환경과 운영 환경의 도메인이 다르다 보니 새로운 문제가 발생했는데요.

"Vercel에서는 되는데 운영에서 안 돼요!"

다음 편에서는 환경별로 다른 도메인과 CORS 정책 때문에 겪었던 고통, 그리고 Cloudflare SSL과 쿠키 설정에서 마주한 보안 이슈들을 다뤄보겠습니다.

localhost에서는 아무 문제 없던 코드가 *.vercel.app에서는 경고를 뿜고, jamescompany.kr에서는 아예 동작하지 않던 그 순간들을 생생하게 전해드리겠습니다!