brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 May 19. 2023

Strangler Fig 패턴과 점진적 IT 투자

베터코드 인사이트의 시작 22편

최근에 시스템을 활용한 비즈니스 혁신을 도모하는 일에 참여하고 있습니다. 레거시 시스템이 존재하고, 새로운 기능 구현은 당연하게 클라우드 위에 구현한다는 전제로 비즈니스 기능에 대한 이야기와 시스템 구조에 대한 이야기가 섞여서 논의되는 상황에서 어떻게 의사소통을 개선할 수 있을까 고민하는 중에 저에게만 익숙한 두 가지 개념이 떠올랐습니다. 이들을 다른 분들에게 설명할 수 있는 언어로 바꾸기 전에 스스로 정리하는 차원에서 글을 씁니다.

Strangler Fig 패턴

한다 하는 여러 사람들이 문헌으로 알린 패턴이고, 제 경험에서도 확신하는 패턴입니다. 거대한 레거시 시스템이 있는 상황에서 마이크로 서비스 아키텍처 혹은 분산 아키텍처를 활용하여 시스템 구조를 현대화(modernization)할 때 필수 패턴이라고 확신합니다.

왜 저런 생소한 단어를 쓸까 찾아본 일이 있습니다. 열대 지방에서 자라는 일종의 무화과나무인 Strangler fig를 은유로 쓰고 있습니다. 다른 나무에 기생하여 성장하는 식물인데, 아래 이미지를 보면 자신이 성장하면서 숙주가 된 나무를 죽음에 이르게 합니다.

이러한 자연 현상을 메타포로 레거시 시스템을 점진적으로 대체하는 과정을 설명하는 방식이죠.

'strangler'를 키워드로 구글링 해보면 쉽게 다양한 자료를 확인할 수 있습니다. 그중에서 직관적인 이미지 두 개를 가져왔습니다. 하나는 AWS 상에서 MSA를 적용하는 글에서 따온 그림입니다.[1] 레거시와 마이크로 서비스로 새로 만든 응용 프로그램의 공존을 묘사하면서 Facade라는 빌딩 블록에 초점을 맞춘 그림입니다.

두 번째 그림은 MSA 구루 크리스 리차드슨의 블로그에서 가져온 것입니다. 단계적이고 점진적인 적용을 시각화 한 그림입니다.

빅뱅은 절대 금물

이전에 <실전 마이크로서비스 아키텍처 적용>에서 당시 CTO 님이 <마이크로서비스 도입 이렇게 한다> 책에서 2장 제목 '마이그레이션 계획하기'를 보고 이렇게 말했던 상황을 다룬 일이 있습니다.

마이그레이션을 하지 말아야지

많은 사람들이 '마이그레이션'이라고 말하면 프로그램 수정에 따라 과거 데이터를 함께 바꾸는 일을 떠올립니다. 하지만, 그 책에서 말하는 '마이그레이션'은 많은 우리나라 IT 관계자들이 생각하는 그(?) 마이그레이션이 아닙니다. 그래서, '마이그레이션'이라는 표현 자체가 오해의 소지가 많은 좋지 않은 표현이라고 생각합니다.

대안은 무엇일까요? <프로덕트 매니저의 가장 어려운 역할>에서 제가 인용한 이미지를 또 불러 보겠습니다. 릴리즈를 통해 사용자 혹은 고객 피드백을 받으면서 진행해야 합니다. 다시 말해서 시장 가치를 꼭 확인하면서 시스템에 돈과 시간을 투자해야 합니다.

이 부분은 해당 글에서 다룬 프로덕트 개념 즉, 프로그램을 제품의 일부로 보는 시각을 가진 기업이 아니라도 마찬가지라고 생각합니다. IT 시스템을 잘 몰라서 비용으로만 보는 현업들이나 경영자에게도 비용을 쓴 명분 혹은 ROI에 입각해서 당위성을 설명하려면 반드시 그렇게 해야 합니다.