레거시 시스템 구조개선 고민

하나의 거대한 모놀리스로 되어 있는 오래된 시스템을 구조 개선을 하기 위해 분석중이다. 분석을 시작하기 전에는 마이크로서비스에 대한 언급이 많았다. 마이크로서비스는 훌륭한 방법이긴 하다. 모듈식이며 확장 가능하고 내결함성도 좋다. 이름만 들어도 익히 알고 있는 유명한 곳에서 이 모델을 사용하여 큰 성공을 거두었기에 마이크로서비스로 아키텍처를 잡는 것이 훌륭하게 보일 수 있다.

그러나 마이크로서비스로 성공한 대부분의 기업은 처음부터 마이크로서비스로 시작하진 않았다. 트위터나 에어비앤비 같은 경우는 마이크로서비스로 전환을 했지만, 현재 복잡성과 대면을 하고 있다. 마이크로서비스를 사용해서 성공한 회사도 최선의 방법을 계속 찾고 있는 것이다.

모놀리스에서 마이크로서비스로 개선하는 것은 간단한 작업도 아니고… 더군다나 PL/SQL, DB Custom Function, Trigger, EAI로 도배되어 있는 현 시스템을 바로 전환하기에는 무리가 있다. 궁극적으로는 향후에는 마이크로서비스로 갈 것이지만, 기술 부채를 먼저 해결하는 Goal을 설정했다. 그 이유는 아래와 같다.

마이크로서비스는 성숙한 제품이어야 가능

  1. 성공적인 마이크로서비스는 너무 거대해서 부서지게된 모놀리스에서 시작한 경우
  2. 처음부터 마이크로서비스로 구축된 시스템이 실패로 끝나는 경우

초기 설계를 제대로 하지 못한다면 모놀리스보다 마이크로서비스를 리팩토링하는 것이 훨씬 어렵기에 초기 설계를 잘해야 한다. 현재는 마이크로서비스로 전환한다라고 얘기할 단계가 아니고, 더욱 성숙되게 만드는 작업이 우선시되어야 한다.

내가 일하고 있는 회사는?

반면, 이미 운영되고 있는 서비스는 얘기가 달라진다. 확장성과 유연성이 필요할 것이다. (현재 내 상황이 이렇다.) 그래서 DB에 집중되어 있는 비즈니스 로직을 애플리케이션으로 이동시키면서 Miniservice 형태의 서비스 분리를 고려중이다. (서비스별 DB 분리는 어려운 상황이다.)

어르신 시스템 생명 주기

모듈화에도 많은 공수가 들어가지만, 개발을 보다 간단하게 만들기 때문에 가치는 충분하다. 모듈화라는 것은 큰 모놀리스를 작게 만들기 때문이다. 모듈화는 마이크로서비스로 전환하기 전에 꼭! 필요한 단계이다. 모듈식 모놀리스로 만들면 코드는 독립적인 모듈로 분할하여 얽혀있는 코드 문제를 해결해야 한다. 모듈식 모놀리스는 마이크로서비스와는 달리 네트워크 통신이 아닌 내부 API 호출로 통신하게 된다. 기존 소스를 활용하진 않지만, 모듈형태로 구성이 되어 있는지 확인해야 하고, 되어 있지 않다면 모듈화를 설계상 고려해야 한다.

준비가 안되거나 견고한 설계 없이 마이크로서비스로 여정을 시작한다면 매우 힘든 시간을 겪을 것이다. 결국 바꾸고 싶은 모습으로 가기 위한 선행 작업들을 진행해야 한다. 최종 Goal로 가기위한 선행 조건을 만족시키는 것이 이번 프로젝트의 목표이다.(기반이 튼튼해야 하기에…)

Originally published at https://giljae.com.

--

--

Slow, Slow (Run Run)… 내일을 사랑하오! https://giljae.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store