신규 프로젝트 [2] : 백엔드 레포 분리를 마치고

https://arin-nya.tistory.com/170

신규 프로젝트 [1] : MVP를 위한 백엔드 설계 및 구현

저번 글에서 LLM 협업 환경을 위한 설계와 Cloud Run 분리를 위한 구조를 언급했었다.

그때는 이렇게 빠르게 우선순위를 두고 진행하게 될 줄은 몰랐다.
어느 정도 경계를 나눠두고 시작했기 때문에, 생각보다 쉽게 끝날 거라고 본 것도 있었다.

 

그래서 이번에는 기존처럼 하나의 레포 안에 백엔드 모듈들을 몰아두는 방식이 아니라, 역할이 다른 여러 레포로 나누는 작업을 진행했다.
배포 단위와 실제 책임 경계를 논리적으로만 나누는 것이 아니라, 물리적으로도 강제하고 싶었기 때문이다.

이번 작업을 통해 인증과 세션, 핵심 업무 도메인, 비동기 처리와 외부 연동처럼 성격이 다른 영역이 각자의 레포와 배포 단위 안에서 동작하는 형태가 되었다.

 

핵심은 단순히 레포를 쪼갠 것이 아니다.
각 레포가 실제로 어디까지 책임지는지, 어떤 역할을 맡는지를 운영 구조 위에서 고정했다는 점이다.

이전 구조에서는 하나의 저장소 안에 여러 책임과 맥락이 공존했다.
그러다 보니 문서화도 쉽지 않았고, 핵심 업무 도메인만 수정해도 Cloud Run 인스턴스 하나를 통째로 다시 배포해야 하는 경우가 많았다.

LLM을 활용할 때도 레포 안에 맥락이 한꺼번에 섞여 있어서 흐름을 잃기 쉬웠다.

 

또 멀티모듈로 나누어 두었다고 해도, 초기 단계에서는 편의성을 이유로 모듈 간 경계가 쉽게 흐려진다.
실제로는 분리되어 있는 것처럼 보여도, 코드 레벨에서는 강한 의존성을 가져가기 쉬운 구조가 되기 때문이다.

이 부분을 초기에 더 강하게 끊어두고 싶었다.

 

그 결과, 지금은 하나의 프론트엔드 위에서 문제가 발생하더라도 어디에서 터진 문제인지 훨씬 빠르게 추적할 수 있게 되었다.
각 레포 사이에 코드 레벨 의존성이 없기 때문에 디버깅도 이전보다 편해졌다.

 

다만, 이번 작업을 하면서 다시 크게 깨달은 점도 있다.

예전에 링크드인에서 본 글이 떠올랐다.
MSA를 잘 아는 사람도 막상 자기 프로젝트에서는 규모가 커지기 전까지는 모노레포를 유지한다는 내용이었는데,

그때는 완전히 와닿지 않았다.

그런데 이번에 직접 겪어보니 왜 그런 선택을 하는지 알겠더라.

 

보기에는 구조가 정말 깔끔해진다.
그런데 실제 운영은 그만큼 더 복잡해졌다.

배포 과정은 생각보다 훨씬 번거로워졌다.

모노레포 시절과 달리 각 레포마다 환경변수를 따로 관리해야 했고, DB Flyway를 위해 배포 순서도 신경 써야 했다.
각 레포 내부의 흐름은 더 명확해졌지만, 반대로 전체 서비스의 흐름은 이전보다 한눈에 보기 어려워졌다.

 

비용도 마찬가지였다.

 

예전에는 Cloud Run 인스턴스 하나를 중심으로 보면 됐다.
하지만 이제는 여러 Cloud Run 인스턴스 사이의 호출, 프론트엔드와의 통신,

Cloud SQL 연결과 트랜잭션까지 비용이 여러 지점에 퍼져 보이기 시작했다.

논리적으로는 더 정돈된 구조인데, 실제 체감은 오히려 전체 비용 계산이 덜 직관적이었다.

결국 이번 작업을 하면서 내린 결론은 단순하다.

팀 상황에 따라 결정해야 한다는 것이다.

 

나처럼 혼자 하거나, 팀이 작거나, 프로젝트 규모가 아직 크지 않다면
“굳이 지금 해야 하나?”를 최소한 몇 번은 더 따져봐야 한다.

구조가 예쁘다는 이유만으로 바로 들어갈 작업은 아니었다.

반대로 팀이 이 복잡도를 감당할 수 있고, 그 위에서 더 효율적으로 운영할 수 있다면 서비스 분리는 분명 미래를 위한 좋은 투자다.
배포 단위와 장애 영향 범위, 책임 경계를 분명히 해야 하는 시점에는 결국 필요한 방향이기도 하다.

 

이번에 개인적으로 가장 아쉬웠던 점은 이 부분이다.

오버엔지니어링을 경계하면서 인프라 크기나 리소스 선택에서는 나름대로 트레이드오프를 고민했다.
그런데 정작 그 위에서 돌아갈 서비스 구조의 복잡도는 충분히 계산하지 못했다.

미래를 위해 구조를 챙기긴 했지만, 그 구조가 실제로 가져오는 운영 복잡도와 개발 속도 저하까지는 끝까지 냉정하게 보지 못했다.
결국 인프라 스펙만이 아니라, 서비스 분리가 만들어내는 관리 비용 자체도 설계 단계에서 같이 봐야 했던 것이다.

 

다음에도 처음부터 설계하고 구현할 기회가 주어진다면,
지금보다는 조금 더 유연하게 판단할 것 같다.
“이 구조가 맞는가”만이 아니라, “지금 이 단계에서 정말 필요한가”를 한두 번이 아니라 더 집요하게 따져보고 결정할 생각이다.

이번 작업은 단순히 구조를 깔끔하게 만든 경험이라기보다,
좋은 구조를 고르는 일은 쉽지만, 지금 감당 가능한 구조를 고르는 일은 생각보다 어렵다는것을 배울 수 있는 아주 좋은 기회였다.