brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Feb 28. 2023

전략적인 마이크로 서비스 채택 방안

MSA 기술과 적용 연구 18

웹 앱의 미래에 대한 글을 쓰면서 영감의 기초가 된 원문 저자의 또 다른 글 <Monoliths to Microservices>를 다시 읽었다. 전에는 크게 흥미를 느끼지 못했다. 이번에는 아마도 <Cloud Native가 만드는 규모의 경제> 그리고 <Cloud Native 승자는 집적이 가능한 개발 조직> 등의 쓰면서 클라우드 환경에서 소프트웨어 개발 조직에게 MSA는 이제 선택의 문제가 아니라 지속 가능성을 확보하기 위한 필수 과제란 생각에 <Monoliths to Microservices>를 다시 읽어 보았다.

모놀리스는 혁신에 한계가 되는가?

개발 속도가 더딘 문제와 기술 부채와 모노리스 아키텍처를 연결하는 설명이다.

Engineering velocity has slowed. Monolithic applications are hindering innovation due to compounding technical debt.

주의할 점은 모놀리스 아키텍처는 나쁘고 마이크로 서비스는 좋다는 식의 이분법은 사실이 아니란 점이다. 모놀리스와 마이크로 서비스는 현실적으로도 공존할 가능성이 높다. 무엇보다 어떤 현상을 모놀리스라고 부르느냐는 '쟁점화'가 더 중요하다. 그것은 조직마다 다른 문제 정의이기 때문이다. 일단, 보편적으로도 모놀리스에 대한 공감은 필요하다. 무엇이 모놀리스인가?

아키텍처 전문가가 아닌 개발자에게 모노리스를 설명하는 가장 좋은 방법은 데이터베이스가 하나인 응용 프로그램이라는 설명이다. 데이터베이스에 모든 프로그램이 접속할 수 있다면 기술 부채가 자라기 가장 좋은 환경이 된다. 언제든지 데이블 조인으로 접근할 수 있기 때문에 경계라는 것이 의미가 없다. 설계에서 하는 약속들은 대부분 개발자들이 설정한 경계에 의존한다. 프로그램 코드를 아무리 객체 지향 형태를 취한다고 해도 아주 쉽게 경계 즉, 어렵게 만든 질서를 무너트릴 수 있다.

이 지점에서 모놀리스는 기술 부채를 만드는 환경이 될 수 있다. 하지만, 이때에도 데이터베이스를 새로 만들어 빠른 속도로 비즈니스를 전개할 수 있다.[1] 그렇게 되면 모놀리스와 마이크로 서비스가 공존하게 되는데, 조직 전체로 보면 이 상황 자체가 이미 마이크로 서비스 아키텍처를 취한 격이 된다.

다만, 비즈니스 변화가 많지 않은 기업이라면 마이크로 서비스 아키텍처를 채택한다고 해서 모놀리스보다 개발 속도가 높아진다고 단정할 수 없다. 그래서 기업에 혁신이 필요할 때, 다시 말해 현재 응용 프로그램에서 커버할 수 없는 새로운 비즈니스 기능을 도입하는 경우에 한하여 모놀리스가 혁신을 저해한다고 말할 수 있을 것이다.

마이크로서비스 도입 이렇게 한다

이전에 지인이 번역한 <마이크로서비스 도입 이렇게 한다> 서평을 쓴 일이 있다. 그 책에서 인상 깊었던 내용이 '2장. 마이그레이션 계획하기' 내용이었다. 다시 읽는 <Monoliths to Microservices>에서도 기본 전제는 점진적인 마이그레이션이다.

기사에서는 마이그레이션 단계를 아래와 같은 네 단계로 제시한다.

Re-host

Re-platform

Refactor/Rearchitect/Rewrite

Continuous Modernization

먼저 앞선 두 단계는 흔히 말하는 코드 수정 없이 인프라 개선 차원에서 먼저 접근하는 일이다.

Re-host and re-platform involve containerization. Containerization improves security and simplifies DevOps.

containerization은 '컨테이너 도입' 정도로 번역할 수 있을 텐데, Cloud Native 진입을 위한 초기 작업이라고 해도 틀린 표현은 아니다. 데브옵스가 등장하는 표를 다시 보자.

데브옵스는 조직적인 준비라고 할 수도 있다. 기술 부채는 결국 속도의 문제란 점을 생각하면 조직적인 준비를 선행하는 일과 보안 문제를 먼저 다루는 이유는 납득할 수 있을 것이다.

저자는 이들 두 단계에서는 다음 작업이 없다고 친절하게 기술한다.

Code modernization

Technical debt removal

Architectural changes

Scalability/elasticity

Accelerated engineering velocity

Strangler Fig Pattern

점진적으로 하더라도 결국은 코드 수정(Refactor/Rearchitect/Rewrite)이 본 게임이다. 기사 마무리[2]는 마틴 파울러가 소개했다는 'the strangler fig pattern'으로 마무리한다. 생소한 영어 단어인데 마침 이름이 은유하는 바를 잘 설명한 문서가 있으니 이름에 대한 설명은 링크로 대신한다.

사실 중국에서 내가 택한 전략도 비슷했다. 물론, 조직의 역량과 비즈니스 상황에 따라 양상은 달라지겠지만, 기술 부채로 손대기 어려운 코드를 점차 사라지게 하는 방식은 너무나 자연스러운 일이기도 하다. 패턴으로 명명하여 솔루션의 방향성을 소통하는 일은 나름의 의미가 있겠지만, 조직(Domain-driven)에서 실행할 때는 그저 중요한 것에 자원을 투자한다는 원칙만 따르면 자연스러운 실행 지침을 찾을 수 있다고 믿는다.

중요한 것은 어떻게 의사결정을 하고 합의에 이르느냐에 대한 부분이다. 이에 대해서는 베터코드 인사이트 연재에서 지속적으로 고민하고 있는 주제들과 만난다.

추적성(Traceability)과 그 쓰임새: 어떻게 추적하고 측정할 것인가?

건강한 조직이 만들어지는 배경: 합리적인 결정은 가능한 문화인가?

의사결정과 협업의 기준이 되는 모델 만들기: 공통의 비전을 논하는 일이 가능한가?

그리고, 굉장히 도전적인 과제이지만 드러커가 주장한 '새로운 제조 회계'를 쫓다 보면 무언가 발견할 수 있을 듯하다.