[영상공유] Spring for the Architecturally Curious Developer by Oliver Drotbohm

이번 영상은 Oliver Drotbohm이 Spring Monolith에 대해서 설명하는 영상이다.

전체적으로 Josh Long 처럼 말이 빠르지 않아서 나 같은 사람도 꽤 알아들을 수 있었던 영상이다.

시간은 50정도지만 실제로 들어보면 그렇게 길게 느껴지지는 않는다.

2015년 즈음 Spring Boot 와 Spring Cloud  프로젝트가 본격화 되면서 Microservice Architecture(MSA)가 개발의 기본 아키텍처로 자리를 잡았고, 당시 거의 모든 개발자들이 MSA를 도입하려고 많은 노력을 해 왔다고 생각한다.

필자도 최근 몇개의 프로젝트(또는 회사)에서 프로젝트를 진행하면서 MSA를 변형해서라도 프로젝트에 도입해보고자 노력을 했던 것 같다.

그런데, 최근 Modular Monolith 라는 용어가 개발 커뮤니티에서 많이 보이고 있다.

Monolith 가 다시 화두에 올라오고 있는 이유를 정확히 알수 있을 정도의 경험과 실력은 없지만 Simon Brown 이 유튜브 강의(여기에서 볼 수 있다)와 그 간의 경험을 바탕으로 약간 정리해볼까 한다.

일단은 모두가 MSA를 도입하려고 했던 이유부터 아주 간단하게 알아보면 다음과 같다.(사실은 필자가 MSA를 좋아했던 이유다)

Monolith 는 회사 전체 시스템을 하나의 모듈로 보고 개발이 되다보니 개발 조직간의 협업의 어려움, 수평확장의 어려움과 비효율성 및 비용증가, 시스템이 커짐에 따라 발생하는 유지보수 문제성 등이 있었고 이로 인해 발전해 온 SOA의 경우는 무겁고 비싼 ESB를 기반으로 개발되다보니 비용적인 측면과 이후 거의 모두가 ESB 지옥을 경험하는 경험들이 발생했다. 그에 MSA는 SOA의 기본 이점을 유지하면서도 가볍고 클라우드 환경에 적합한 개발이 가능하다는 이점이 있었다.

서비스간 통신에 기본적이고 단순한 프로토콜(일반적으로는 Rest API)을 이용해서 통신하다보니 다른 서비스들이 특정 프레임워크나 언어에 구애받을 필요가 없었다.

병목지점이 될만한 서비스들만 확장을 할 수 있다보니 전체적인 시스템 구성에서 이점이 컸다.

Monolith Architecture는 시스템 규모가 커짐에 따라 커다란 진흙(보통은 똥이라고 했지만)이 되버려서 어느 순간 리팩터링이 이루어지지 않으면서 결국 어느 시점에서는 리뉴얼 프로젝트라는 이름으로 완전히 새로 만들어야 했다. 그에 비해 MSA 는 충분히 작은 서비스들이 독립적으로 있기 때문에 리팩터링이 수월하고 시스템 개선에도 이점이 있었다.

 

사람마다 다른 이유를 가지고 도입하려고 했을 수도 있지만,  필자가 도입하려고 했던 이유는 이런 이유들이었다.

몇개 프로젝트에서 유사 MSA 환경에서 개발을 진행해 보았다. 여기서 유사 MSA 라고 하는 이유는 제대로 MSA 로 발전시켜본적이 없기 때문인데 그때 어려움으로 느꼈던 것 몇가지만 정리하면 다음과 같다.

• 업무 도메인에 대한 명확한 정의와 분류 등의 작업을 진행한 후에 개발을 시작할 수 없었다. 그러다보니 개발이 어느정도 진행한 후에 서비스들의 구분에 문제가 생기고 서비스간의 이상한 의존성들이 발생하는 경우들이 생기곤 했다. 이게 생각보다 늦게 발견이 되서 나중에 두개의 개별 서비스가 서로를 의존해서만 존재가 가능한 경우들이 발생하게 된다.
• 몇번의 업무도메인 분리에 실패하고 나면 어느 순간 특정 서비스에 대부분의 업무도메인을 배정해 버리는 상황이 발생한다. 결국 충분히 작은 모듈 몇개와 Monolith에 버금가는 커다란 진흙덩어리 하나가 존재하는 시스템이 만들어지게 되었다. (최악은 적당히 작은 진흙덩어리 여러개와 커다란 진흙덩어리 몇개가 존재하는 시스템이 되는 경우도 있다)
• 중간급의 프로젝트들이다보니 모든 서비스를 하나의 팀이 개발하는 상황에서 MSA가 오히려 개발의 장애물이 되는 경우들도 발생했다.
• MSA에는 필수적인 요소로 다양한 모니터링 시스템을 동반해야만 그 진가가 발휘되는데, 그런 모니터링 시스템을 검토하고 구성할만한 여력을 허용해주는 프로젝트는 거의 없었다.

뭐 굉장히 창피하지만 이런 자기 합리화를 위한 핑계같은 이유들이 실제 프로젝트에서 발생할때 개발 스케쥴을 맞추면서 아키텍처를 유지하기가 굉장히 힘들었다. (그냥 개인 역량부족으로 못한거지 절대 핑계를 대는건 아니다.) 다른 회사의 개발자들과 얘기를 나눠보면 개발팀 한개 또는 두개로 이루어진 회사에서 MSA 도입에 어려움을 겪는 경우는 대충 위와 같은 이유들이 많은걸 보면 필자만의 문제는 아니었을지도 모르겠다. 

아무튼 위 실패 요인 중 가장 큰 부분을 차지하는게 첫번째가 아닐까 생각한다.

이런 경우의 대안으로서 가져갈 수 있는 부분이 Modular Monolith 이지 않을까 싶다.

실제로 ChatGPT 에게 Modular Monolith에 대한 설명을 부탁해보니 MSA 전단계의 아키텍처로 도입하면 좋다는 이야기를 한다.

간단히 얘기하면 MSA 를 구성하다보면 쉽게 구분이 되어서 분리가 가능한 부분과 그렇지 않은 부분들이 존재한다. 이 경우 쉽게 구분 가능한 부분들은 일단 MSA 구성을 하고 분리가 애매한 경우는 Monolith 로 개발한 후에 시스템을 몇번 리팩터링을 진행하고 정리하다 필요한 시점에 MSA 로 분리해내는 방법인 것 같다. 여기서 같다라는 표현을 쓴 이유는 아직 Modular Monolith 에 대한 다양한 경우를 충분히 학습하지 못해서다. 

아무튼 Monolith도 모듈을 잘 정리해 놓는다면 충분히 훌륭한 아키텍처다. MSA는 선, Monolith는 악이 아니라는 이야기다. 다만, 경험상 개발자 1인 프로젝트가 아니라면, 어느 순간에 이 부분이 무너져 버리기가 MSA보다 더 수월하다. 또한 Monolith로도 충분한 프로젝트를 억지로 MSA로 만드는 것도 역시나 별로 바람직하지 않다.  그래서 최근에는 이 Monolith 구조를 모듈별로 잘 구별해서 개발을 할 수 있도록 다양한 지원툴들이 나오고 있는 모양이다. 그 중 하나가 JDK9에서 발표된 Jigsaw 였고, 또 다른 것이 위 동영상에서 설명하는 Spring Modulith 라는 프로젝트로 보인다. 그런 배경이 있다는 것을 보고 위 동영상을 본다면 조금은 더 도움이 되지 않을까 해서 길게 풀어봤다.

언젠가 Modular Monolith 에 대한 내용을 좀 더 정리할 기회가 된다면 좋겠다.