Monolith를 MSA로 전환을 계획할때 필요한 세가지

시스템을 오랫동안 운영하다보면 자연스럽게 모노리스가 됩니다. 얼마 안됐는데 코드가 이렇게 많아졌어? 라고 생각하신다면 비즈니스가 잘 성장하고 있다는 의미입니다. (자축하셔도 좋습니다.) 하지만 기쁜 마음도 잠시, 간단한 수정을 하더라도 어디에 Side Impact가 있을지 몰라 주저하는 마음이 든다면 이미 시스템에는 신호등에 빨간불이 들어왔다고 보셔야 합니다. 유지보수의 효율성이 떨어지고 있다는 이야기니까요. 자. 그럼 어떻게 해야 할까요? 특정 부분을 MSA로 분리할때가 온겁니다. 그럼 Monolith를 MSA로 전환을 계획할때 필요한 세가지를 알아보시죠.

 

1. 조직장으로 부터 꼭! 리소스 지원을 받아야 합니다.

MSA 전환이나 서비스 분리는 리소스와 시간을 많이 요구하는 작업입니다. 디펜던시가 크던 작던 무관하게 기본적으로 많은 리소스가 투입되야하는 작업이니 조직장으로 부터 꼭! 리소스 지원을 받으셔야 합니다.

 

2. 무엇을 분리할까?

제일 복잡하고 덩치가 제일 큰걸로 골라서 분리하는게 제일 좋습니다. 왜냐하면 분리후에 효과가 확실하기 때문입니다. 대부분의 사람들은 디펜던시가 가장 적은 것부터 분리하는게 좋지 않을까? 그러면 쉽고 빠르게 분리할 수 있을텐데.. 라고 생각할 수 있습니다. 하지만 업무의 성과 측면에서 보면 인력과 시간이 많이 들지라도 분리후 효과를 극대화할 수 있는 도메인을 채택하는 것이 좋습니다.

 

3. 단기전이 아닌 장기전으로 생각하세요.

시스템 분리라 레고 블럭 떼어내듯이 한다면 제가 이런 포스트를 작성하지도 않았겠죠. 조직장으로 부터 리소스 펀딩을 최대한 많이 받아야 합니다. 그리고 개발 작업도 하나의 코드안에 참조하는 외부 클래스가 30개씩 있는 것들이 몇십, 몇백개가 있을텐데 이걸 분리한다고 생각하면 참... 난감하죠? 게다가 DB도 들여다 보면 한숨만 나올 수도 있습니다. 하지만 걱정마세요. 끝이 안보여도 지금 한발자국 앞으로 가는게 중요합니다. 코드 한줄을 옮기면, 함수 하나, 클래스 하나로 가속도가 붙을 겁니다.

 

 

Thanks

Hans