대규모 시스템 구축 방식으로 빅뱅 접근은 매력적이다. 비용을 최소화할 수 있고 기간을 단축시킬 수 있다. 연결된 시스템들을 분리하여 구축할 때 드는 통합과 운영의 어려움도 피할 수 있다. 하지만 문제도 있다. 실패할 가능성도 커지고, 실패할 경우 회사에 미치는 위험도 높아진다. 무엇보다도 요구사항 분석 이후 구축까지 1년 이상 시차가 있어서 비즈니스 변화를 따라잡기가 매우 어렵다. 단계별 오픈을 추진하는 경우도 있지만, 작은 빅뱅을 여러 번 하는 것에 다름 아니다.

차세대 프로젝트의 대상 영역은 주로 고객과 상품 등 기업의 코어 비즈니스였다. 오랫동안 수행해온 업무이기 때문에 업무 요건은 충분히 알려져 있고, 변화의 폭도 크지 않다. 하지만 디지털 시대에 기업들이 주력하고 있는 디지털 탈바꿈의 영역은 새로운 비즈니스 모델이거나 서비스 도입이다. 주로 고객 접점에 디지털 마케팅 기법을 도입하는 과제가 주를 이룬다. 차세대와 비교하면 요구사항을 미리 정하기도 어렵고 변화의 범위와 빈도도 크다.

디지털 탈바꿈에는 빅뱅 방식은 유효성이 크게 떨어진다. 빠른 변화에 앞서서 대처하기 위한 시스템을 만들어가야 되는데, 빅뱅으로 접근하게 되면 요구사항을 미리 고정해야 하기 때문에 도리어 변화를 가로막는 장벽이 될 수 있다. 이러한 고민은 우리나라에만 한정된 이야기가 아니다. 클라우드 이전이 활발하게 이루어지고 있는 해외에서도 같은 문제를 겪고 있다. 최첨단 IT기업이라 할 수 있는 넷플릭스조차 클라우드 이전에 7년이 소요되었다고 한다.

이들은 이러한 패러독스를 어떻게 해결했을까? 선진기업들은 단일(Monolith) 환경의 레거시 시스템을 클라우드로 이전할 때 ‘스트랭글러(Strangler) 패턴’을 이용한다. 

 

‘스트랭글러 패턴’이란 무엇인가?

스트랭글러 패턴은 IT분야 대표적 구루인 ‘Martin Fowler’가 2004년 호주에서 커다란 기생 덩굴 식물(Strangler)이 숙주 나무와 공생하다가 수년 후 숙주 나무를 대체하는 모습에서 아이디어를 얻어 만든 방법이다. 이 식물은 숙주 나무의 가지에 씨를 뿌려 기생하다가 토양에서 뿌리를 내릴 때까지 점차 나무 아래로 내려가면서 수년 동안 환상적이고 아름다운 모양으로 자라는 한편, 주인인 숙주 나무를 서서히 교살하다가 끝내 숙주 나무를 없애고 자신이 그 자리를 대체해 버린다.

일반적으로 대규모 프로젝트는 혁신영역보다 기존 시스템이 유지되어야 하는 영역의 이전에서 더 큰 어려움에 봉착하곤 한다. 오래된 기존 시스템들은 그 구조가 비효율적일 뿐이지 복잡한 업무처리 로직 그 자체가 잘못된 경우는 많지 않으며 이러한 기능들은 대부분 신규 시스템으로 이전되어야 한다. 경우에 따라서는 오래된 버그조차도 새로운 시스템으로 이전해야 하는 경우가 발생한다.
 

[스트랭글러]

빅뱅 접근에서는 As-Is 시스템의 분석에 충분한 시간을 할애하기 어렵고(사실 충분한 시간을 할애해도 제대로 이해하기 어렵다) 이로 인해 숨겨진 엄청난 양의 비밀 로직(소스)의 존재를 통합테스트 단계에서 발견하게 되어 프로젝트가 곤경에 빠지곤 한다.

스트랭글러 패턴에서 개발자는 기존 시스템에서 기능을 떼어내 이를 다시 코딩 한다. 그러면서 특정 기능 부분을 점진적으로 대체하며 기존 앱을 해체한다. 이때 기존 시스템 구조인 모놀리틱 소프트웨어 아키텍처에서 마이크로서비스로 전환하는 방식을 보편적으로 사용한다. 마이크로 서비스 아키텍처를 택할 경우 프로그래머가 새로 구축하는 부분을 자체적인 로직, 데이터 및 구조로 캡슐화할 수 있다.

 

[Strangler Pattern 예시] (출처 : https://www.michielrook.nl/2016/11/strangler-pattern-practice /)

이때 중요한 것은 구 시스템과 신모듈(Strangler)간에 상호 공생 상태를 유지하면서 교살하는 방법이다. 기본적인 전략은 ‘이벤트 가로채기’다. 떼어낼 기능을 동작시키는 이벤트를 가로채서 신모듈에서 처리하고 다시 구 시스템에 결과를 전달하는 방식으로 공생을 하는 것이다. 구 시스템이 기본적으로 이벤트에 연결되는 메시징 기반 시스템일 경우는 더 손쉽겠지만 그렇지 않다 하더라도 테이블에 대한 업데이트를 모니터링 하여 새로운 이벤트를 합성하는 방식을 써서 해결이 가능하다.

이러한 방식을 활용할 때 초기에는 이전이 용이한(타 기능과의 연계가 느슨한) 기능부터 접근하는 전략이 좋다. 이를 통해 충분한 노하우가 축적되고 나서 좀더 난이도가 높은 기능 영역에 도전하는 것이 바람직하다.

보험 계산 모듈과 같이 한번에 이전이 불가능하고 기능을 분리해 내기도 어려운 경우에는 스트랭글러패턴의 변형인 ‘데이터 주도 스트랭글러 패턴(Data Driven Strangler Pattern)’을 사용할 수 있다. 즉 신/구 시스템의 IN/OUT 로그를 기반으로 지속적으로 비교하면서 점진적으로 이전하는 것이다. 예를 들어 보험 계산 모듈의 경우 상품별 계산 결과가 일치하는지를 신/구 시스템간 로그를 통해 비교하면서 이전이 완료된 상품과 그렇지 않은 상품을 확인하면, 점진적으로 이전할 수 있다.

[Data Driven Strangler Pattern] (출처 : Pivotal Labs)

빅뱅 방식의 컷 오버 전략보다 스트랭글러 패턴을 활용해야 하는 중요한 이유는 현저하게 위험을 감소시킬 수 있다는 점이다. 작은 규모의 개발과 빈번한 출시를 통해 진행과정을 신중하게 모니터링 할 수 있으며 이 과정에서 새롭게 유입되는 현업 부서의 요건을 유연하게 반영할 수 있다.

이러한 방식으로 새로운 응용 프로그램을 설계할 때 고려할 것은 미래에 쉽게 ‘Strangled’ 될 수 있도록 프로그램을 만드는 것이다. 이벤트 주도 아키텍처(EDA, Event Driven Architecture)를 적용하는 것이 좋은 대안이 될 수 있다. 새로운 시스템은 내일의 레거시 소프트웨어가 될 것이므로 손쉽게 스트랭글러 패턴을 활용하여 새로운 시스템을 위해 우아하게 사라지게 만들어야 한다.

 

스트랭글러 패턴을 도입하려면 무엇을 준비하고 어떻게 접근해야 하는가?

이러한 방식으로 신 시스템 구축을 진행할 때 상당히 많은 기존 관행들을 바꾸어야 한다. 또한 프로젝트 진행 중에도 신/구 시스템이 같이 병행 가동되어야 하므로 자체 인력으로 프로젝트를 진행하는 것이 아니라면 보안 및 운영 측면을 고려한 외부 업체와의 계약 형태를 고민해야 한다.

1. 예산 확보와 집행 측면

스트랭글러 패턴 기반 구축은 일반적인 차세대 구축과 같이 구축에 소요되는 총비용을 산정하고 예산 승인 후 프로젝트를 진행하는 방식을 적용하는 것은 바람직하지 않다. IT과제 도출 및 예산 확보는 년 단위로 이니셔티브를 도출하고 작은 단위 프로젝트로 진행하는 방법이 더 타당하다. 기존 시스템 분석의 중요성과 프로젝트 진행 중에 빈번한 출시를 통해 신/구 시스템이 병행 운영되어야 하는 특수성은 외부 업체와의 계약에 반영되어야 한다. 경우에 따라서는 RFP에 의한 프로젝트 방식 계약보다 일정 규모 이상의 개런티를 보장하는 사후 정산(릴리즈 된 프로그램 규모에 따라)방식의 계약이 갈등을 최소화 시키는 방법이 될 수 있다.

2. 거버넌스 측면

‘스트랭글러 패턴 마이크로서비스 아키텍처’ 적용은 데브옵스 체계를 구축하는 절호의 기회로 활용 가능하다. 즉, 숙주나무가 될 레거시 시스템 개발 운영팀은 Slow Speed IT 팀으로 새로운 신모듈을 만드는 팀은 Fast Speed IT팀으로 조직하여 점진적인 디지털 조직으로의 이전을 도모하는 것이다. 이러한 측면을 고려할 때 내부 인력의 육성 전략이 고려되어야 하며 외부 전문가의 도움이 필요하다.

3. 기술 아키텍처 측면

스트랭글러 패턴의 적용은 당연히 ‘마이크로 서비스 아키텍처, 이벤트 드리븐 아키텍처, 클라우드 네이티브 앱’과 같은 신기술 습득이 동반되어야 한다. 하지만 이보다 더 중요한 것은 현행 시스템의 분석 및 리팩토링 역량의 확보와 모니터링 환경의 구축이다. 이를 위해서는 적정 도구도 갖추어야 한다.

예를 들어 프로세스 마이닝 도구 적용을 통해 실 데이터 기반의 프로세스 별 부하를 모니터링 하면서 스트랭글러 패턴 적용 전략 또는 적용 후 변화를 관찰 할 수 있다. 엔터프라이즈 리팩토링 도구는 전체 아키텍처 관점에서 신/구 시스템의 공존 관계를 모니터링 가능하고 특히 스트랭글러 패턴을 적용할 영역을 식별하고 이를 분리해낼 방법을 강구하는데 필수적이다.

4. 요구 공학 측면

점진적 구축 전략인 스트랭글러 패턴의 적용은 요구사항의 지속적 관리(이왕이면 툴을 통한 관리를 권장한다)와 BDD(Behaviour-Driven Development)와 같은 테스트 주도 개발, 테스트 자동화에 대한 투자가 필요하다. 이를 등한시 할 경우 새로운 릴리즈 마다 기존 시스템과의 충돌 여부를 확인하는 통합테스트에 엄청난 노력이 소요될 수 있다.

스트랭글러 패턴의 적용대상을 식별하여 마이크로 서비스로 전환할 때 그 단위를 식별하는 문제를 기능중심으로만 접근할 경우 비즈니스 대응 측면에서 문제가 발생할 우려가 있다. 즉 비즈니스 프로세스의 지속적 관리를 통해 비즈니스 아키텍처와 어플리케이션 아키텍처간의 상관관계가 관리되어야 하며 이를 고려한 마이크로 서비스 아키텍처로의 이전이 필요하다는 의미다.

즉 전사 프로세스 관리 체계하에서 요구사항이 관리되고 프로세스 단위의 테스트 자동화를 통해 새로운 기능이 출시될 때 빠른 시간 내에 검증이 가능한 체계를 갖추어야 한다.

마이크로 서비스 아키텍처로의 변화는 중앙 집중형 구조에서 지방 분권형 구조로의 변화를 의미한다. 효율적인 분권화가 이루어지지 않은 경우 오히려 중앙 집중형 구조보다 훨씬 관리에 어려움을 겪게 된다.

 

마치면서

최근 대한항공이 전사 시스템을 약 3년에 걸쳐 클라우드로 전면 전환하는 것을 선언하여 이목이 집중되고 있다. 하지만 해외 사례에 비추어 볼 때 3년은 클라우드 이전에 너무나 빠듯한 시간이다. 스트랭글러 패턴이 클라우드 이전 전략으로 널리 활용되는 점을 감안할 때 대한항공이 대규모 프로젝트 접근법의 새로운 방향성을 제시할 수 있지 않을까 하는 기대와 동시에 우려도 있다.

디지털 탈바꿈은 기존 접근법의 탈바꿈으로부터 시작해야 한다. 기존 시스템을 유지하면서 혁신적인 디지털 서비스와 기술을 도입할 수 있는 체계를 갖추어야 한다. 조직의 애자일화는 여러 금융회사들이 앞다투어 시도하고 있다. 더불어서 스트랭글러 접근법을 도입하면 효과를 크게 높일 수 있을 것이다.

 

[스트랭글러와 마이크로서비스]

- 끝 -