서비스 확장 모노리스 vs 마이크로

[개발 고민]서비스를 합쳐야한다. 마이크로냐, 모노리스냐.

“서비스를 합쳐야 한다. 기존 모노리스로 진행할 것인가. 마이크로로 바꿔 진행할 것인가.”

상황: 이미 만들어진 서비스(이제부터 A라 부르겠다)가 존재하고, 이번에 새로운 서비스(B라고 부르겠다.)가 시작됐다. 두 서비스가 합쳐져야한다는 회의 결과가 나왔다.

합치는 방식은 B 디자인에 A 기능을 추가하는 것으로 정해졌다.

A의 구성: mysql로 구성된 Nodejs 백엔드 + react 프론트 엔드
B의 구성: mongoDB로 구성된 Nodejs 백엔드 + react 프론트 엔드

선택지1. 모노리스로 진행한다.

“B의 구성대로 A의 기능을 새로 만든다. mysql => nosql”

장점:
1. 구성 방식이 통일이 되니 새로운 사람이 투입되도 공부할게 적어진다.
2. 관리하기 쉬운 코드가 된다. A는 오래전(3년전에) 만들어진 코드라 제대로 까보지 않았다. 코드의 질도 좋지 않다. B를 만든 사람이 “나”이다. 앞으로 내가 관리해야하는 코드이니 A의 기능을 내가 쓴 코드로 새로 만드는 것이 관리면에서는 편해진다. rdb를 쓰지 않고 nosql만 쓰기 때문에 코드짜기가 편해진다.

단점:
1. 이미 잘돌아가는 A를 버리고 새로 만들 필요가 있나? 시간적 비용.

선택지2. 마이크로로 바꿔 진행한다.

“마이크로: A의 백엔드를 살려 마이크로 서비스로 진행한다.”

A, B 기존 백엔드를 모두 이용한다. B의 프론트에 A의 백엔드를 이용하여 서비스를 확장한다.

장점:

1. A기능을 새로 개발할 비용이 줄어든다.

단점:

1. A의 코드가 관리가 잘되지않았던 코드라 까보면 시행착오가 발생할 것이다. (홈페이지가 어떻게 돌아가나 확인해보니 한 화면당 요청하는 api 갯수가 필요이상으로 많았다. 제대로 구성되어있지 않다는 것이다.)

결론은 나지 않았지만 선택지는 확실히 정해졌다.

“A 코드의 난해함을 참고 잘 파악해서 이용할 수 있느냐. 파악하고 이용하는데 시간이 얼마나 들지.”

vs

“새로 만드는데 얼마나 시간이 들런지”

이 둘을 파악해보는 다음주가 되겠다.