레거시 서비스를 모노레포로 묶을 때 분류 기준 (API와 배치를 가르는 법)

여러 저장소에 흩어져 있던 오래된 서비스들을 저장소 하나로 모으면서, 폴더를 어떤 기준으로 나눌지 정했던 과정입니다.

서비스별로 따로 있던 저장소를 하나로 합치기로 하고 폴더 구조를 잡기 시작했는데, 막상 해보니 어려운 건 폴더 모양이 아니라 이 서비스를 어디에 넣을지였습니다.

API 와 배치로 나누자는 큰 틀은 금방 정해졌습니다. 그런데 오래된 서비스일수록 요청도 받고 스케줄도 도는 애매한 것들이 많았고, 이름만 보고 넣었다가는 같은 성격의 서비스가 양쪽에 흩어지게 됐습니다.

- 기준은 이름이나 기술이 아니라 "무엇을 제공하는가"로 잡는다

- 한 제품이라도 역할이 다르면 나눠서 넣을 수 있다

- DB 도 다르고 연동도 거의 없는 제품은 따로 떼어 둔다

- 합친 뒤 섞이는 커밋은 접두어와 경로 지정 로그로 구분한다

1. 먼저 전체 모양부터

폴더 구조는 단순하게 갔습니다. 코드는 역할별 묶음 아래에 서비스 이름 폴더로 두고, 문서는 코드와 섞이지 않게 따로 뺐습니다.

서비스 폴더 이름은 배포 잡이 참조하는 경로와 똑같이 맞췄습니다. 빌드 서버가 이 폴더만 골라 받아서 빌드하기 때문에, 이름이 한 글자라도 다르면 빌드가 엉뚱한 곳을 보게 됩니다.

2. 분류 기준: 무엇을 제공하는가

애매한 서비스를 만날 때마다 "이건 API 야, 배치야?"를 따지다 보면 끝이 나지 않습니다. 그래서 질문을 하나로 바꿨습니다. 이 서비스는 다른 쪽에 무엇을 제공하는가.

- 포트를 열고 요청을 받는다 -> API

- 다른 시스템들이 거쳐 가는 중계 역할을 한다 -> API

- 정해진 시간에 스스로 돌아 데이터를 처리한다 -> 배치

이 기준으로 보면 이름에 "매니저"가 붙은 비슷한 서비스 두 개도 갈립니다. 하나는 여러 시스템의 메시지를 받아 넘겨주는 중계 역할이라 API, 다른 하나는 주기적으로 쌓인 메시지를 처리하는 쪽이라 배치로 들어갔습니다.

테스트용 시뮬레이터도 처음엔 애매했는데, 결국 포트를 열고 요청을 받아 응답하는 역할이라 API 로 넣었습니다. 이렇게 정리하고 나니 예상과 달리 API 쪽이 배치보다 많았습니다.

3. 한 제품을 둘로 나눠도 된다

분류하다 보면 한 제품 안에 화면도 있고 알림 배치도 있는 경우가 나옵니다. 이걸 제품 단위로 한 폴더에 몰아넣으면 기준이 다시 흐려집니다.

그래서 제품이 아니라 구성요소의 역할을 따랐습니다. 관리 화면은 백오피스 묶음에, 알림을 보내는 배치는 배치 묶음에 넣는 식입니다. 제품 이름은 두 폴더에 같이 나타나지만, 각 폴더는 역할 하나만 갖게 됩니다.

반대로 통째로 떼어낸 제품도 있습니다. 쓰는 DB 가 아예 다르고 다른 서비스와 연동도 거의 없는 제품은 억지로 역할별로 쪼개지 않고 따로 한 덩어리로 두었습니다. 반면 성격은 비슷해도 규모가 작은 제품은 굳이 떼지 않았습니다. 떼어낼지 말지는 DB 와 연동이 얼마나 얽혀 있는지로 판단했습니다.

4. 같이 배포되는 것은 같이 둔다

사용자 웹과 관리자 화면처럼 같은 소스로 빌드되는 것들은 나누지 않고 한 폴더에 두었습니다. 소스가 같은데 폴더를 나누면 같은 코드를 두 번 관리하게 되기 때문입니다.

이런 경우는 폴더가 아니라 태그를 서비스별로 나눠서 구분합니다(같은 소스를 두 서비스로 배포할 때 태그 붙이는 법). 웹 배포와 관리자 배포가 섞이지 않게 하는 건 저장소 구조보다 태그 규칙이 맡는 게 자연스럽습니다.

5. 합친 뒤에 생기는 문제: 커밋이 섞인다

저장소를 합치면 여러 서비스의 커밋이 한 줄로 뒤섞여 올라옵니다. 로그만 봐서는 어느 서비스를 고친 커밋인지 알기 어렵고, 저장소 단위로 권한을 나누던 것도 폴더 단위로는 나누기 어렵다는 점이 걱정으로 나왔습니다.

그래서 한때 뺐던 서비스 접두어를 이름에 다시 넣기로 했습니다. 커밋 메시지에도 같은 접두어를 붙여 두면 로그에서 바로 구분되고, 특정 서비스 이력만 볼 때는 경로를 지정해서 로그를 보면 됩니다.

경로를 지정하면 그 폴더를 건드린 커밋만 나오니, 저장소가 합쳐져도 서비스별 이력은 따로 읽을 수 있습니다. 권한 분리는 저장소 구조만으로 풀기 어려운 부분이라, 합치기 전에 팀 안에서 감수할지 먼저 정해두는 편이 좋습니다.

6. 정리

모노레포 전환에서 폴더를 몇 단으로 할지는 금방 정해지지만, 서비스를 어디에 넣을지는 기준 없이는 계속 흔들립니다.

- 분류 질문은 하나로: 무엇을 제공하는가

- 요청을 받거나 중계하면 API, 스스로 주기적으로 돌면 배치

- 한 제품도 역할이 다르면 나눠서 넣는다

- DB 와 연동이 따로 노는 제품은 통째로 떼어 둔다

- 같은 소스로 빌드되는 것은 같이 두고 태그로 나눈다

- 섞이는 커밋은 접두어와 경로 지정 로그로 구분한다

기준을 한 줄로 정해두면 새 서비스가 생겼을 때도 넣을 자리를 바로 정할 수 있고, 무엇보다 다음에 이 저장소를 여는 사람이 폴더 이름만 보고 서비스의 역할을 짐작할 수 있게 됩니다.

여기까지 레거시 서비스를 모노레포로 묶을 때의 분류 기준에 대해서 작성해봤습니다. 여기까지 읽어주셔서 감사합니다!