마틴 파울러 형은 뭐라 할까 ? What is the strangler pattern and how does it work?

Strangler 패턴은 소프트웨어 팀이 레거시 시스템을 점진적으로 폐기하고 대규모 재작성의 함정을 피할 수 있게 해줍니다. 이 패턴을 검토하고 관련된 단계를 자세히 살펴보겠습니다.

레거시 응용 프로그램 시스템에서의 Migration은 종종 중대한 코드 재작성 과정을 필요로 합니다. 그러나 전체 시스템을 대대적으로 개선하고 시스템을 오프라인 상태로 가져가는 대신, 기존 레거시 시스템을 점진적으로 폐기하고 동시에 새로운 기능을 점진적으로 추가하는 패턴을 구현할 수 있을 것입니다.

이 접근법은 Martin Fowler가 Strangler 패턴으로 명명한 것으로, 일반적으로 "큰 덩어리의 똥"으로 불리는 단일 응용 프로그램 시스템을 점진적으로 업데이트하면서 여전히 운영 중인 상태로 유지합니다. 오늘은 Strangler 패턴이 무엇인지, 어떻게 구현하는지 및 사용 사례 예시와 함께 살펴보겠습니다.

What is the strangler pattern?

상태가 좋지만 더 나은 동작을 위해 철저한 개조가 필요한 모터사이클을 상상해보세요. 하나의 옵션은 모든 부분을 완전히 분해하고 여러 달 동안 재건축하는 것입니다. 그러나 모든 부품을 교체한 후에도 정말로 작동할 것을 얼마나 확신할 수 있을까요? 그리고 차고에 있는 동안 모터사이클을 사용하고 싶지만 사용할 수 없다면 어떻게 할까요?

해결책은 하나씩 부품을 교체하고 예상대로 작동하는지 확인한 다음 다음 부분으로 넘어가는 것입니다. 이것에는 두 가지 주요 이점이 있습니다. 첫 번째 이점은 부품을 점진적으로 교체하면 모터사이클을 여전히 사용할 수 있을 가능성이 높다는 것입니다. 완전히 재건축을 기다릴 필요가 없습니다. 두 번째 이점은 수정 또는 교체가 작동하지 않는 경우, 모든 것을 동시에 검사할 필요가 없으므로 문제를 식별하기가 훨씬 쉽다는 것입니다. 결국, 작동 중지하지 않고 업데이트된 모터사이클을 얻게 될 것입니다.

Strangler 패턴은 매우 유사한 방식으로 작동합니다. 응용 프로그램 시스템을 완전히 분해하고 코드를 다시 작성하는 대신, 이 패턴은 개발 팀에게 시스템을 완전히 중단할 필요 없이 코드와 기능의 일부를 점진적으로 업데이트할 수 있는 방법을 제공합니다. 결국, 모든 서비스와 구성 요소가 새로운 응용 프로그램 시스템과 통합되도록 리팩터링되고 레거시 시스템은 폐기됩니다.

이렇게 하면 마이그레이션 프로세스가 복잡한 뜯어 고치기 대신 반복적인 프로세스로 진행될 수 있습니다. 개발 팀은 두 번째 코드 베이스를 구현하는 데 너무 많은 걱정을 할 필요가 없으며, 대신 한 번에 하나의 서비스 또는 기능을 리팩터링하는 데 집중할 수 있습니다. 이것은 또한 이전 코드를 관리하는 팀과 새로운 코드를 관리하는 또 다른 팀을 만들 필요가 없다는 것을 의미합니다.

How to implement the strangler pattern

표면적으로 Strangler 패턴은 복잡해 보일 수 있습니다. 그러나 올바른 절차를 따른다면 실제로 구현하기가 매우 간단합니다.

아래 다이어그램은 Strangler 패턴 구현과 관련된 단계를 설명합니다.

Strangler 패턴의 가장 큰 구성 요소 중 하나는 외부 앱 및 시스템과 상호 작용하는 주요 지점인 퍼사드 인터페이스입니다. 코드가 여러 서비스를 긴밀하게 결합한 단일 모듈에 위치할 때, 외부 시스템은 특정 기능과 관련된 코드 블록을 식별할 수 없어 응답 시간이 느려지며 개별 서비스에 대한 정확한 테스트를 수행하기 거의 불가능해집니다. 이것이 퍼사드가 해결하는 문제입니다.

퍼사드 인터페이스는 외부 앱 및 시스템이 특정 기능과 관련된 코드를 식별하고 기밀성 있는 레거시 시스템 코드를 숨기는 데 도움을 줄 것입니다. 이를 해결하기 위해 Strangler 패턴은 개발자들이 단일체(monolith)에서 이러한 개별 서비스와 기능을 분리할 때 개발자들이 이들을 노출할 수 있도록 도와주는 퍼사드 인터페이스를 생성하는 것을 포함합니다. 결국, 퍼사드 뒤에 있는 코드는 개발자들이 새로운 코드를 작성, 테스트 및 배포함에 따라 축소될 것입니다.

The strangler pattern in practice

Example 1: Object-oriented programming 

수천 또는 수만 줄의 코드를 포함하는 단일 클래스는 종종 "갓 클래스(god class)"로 지칭됩니다. 이러한 종류의 클래스를 수정하는 것은 종종 코드 업데이트 프로젝트에서 가장 고통스러운 부분 중 하나입니다. 이러한 클래스는 메소드들 위에 존재하며, 어떤 메소드든 변수에 액세스하고 그 변수를 변경할 수 있습니다. 이는 한 곳에서의 변경이 다른 곳에서 의도치 않은 결과를 초래할 수 있음을 의미합니다.
  객체 지향 시스템에 Strangler 패턴을 적용하려면 모든 변수를 객체 기반 데이터 구조로 묶어야 합니다. 특정 기능과 관련된 코드 청크를 수정해야 할 때, 해당 코드를 적절한 데이터 구조에 링크된 객체에 저장하십시오. 그 구조를 새로운 시스템을 위해 생성하는 클래스에 구현하고, 레거시 코드에도 해당 구현을 반영하십시오. 결국 프로그래머들은 이러한 새로운 잘 구조화된 코드에 변경을 가할 것이며, 갓 클래스는 천천히 붕괴될 것입니다.

Example 2: Web applications 

Strangler 패턴은 전통적인 서버 기반 Java 응용 프로그램을 동적인 웹 기반 서비스로 변환할 수 있습니다. 이를 시작하기 위해 하드 코딩된 SQL 문을 점진적으로 JSON과 같은 웹 서비스를 지원하고 직접 호출할 수 있는 언어로 대체하는 것이 가능합니다. 결국 레거시 Java 코드는 새로운 언어로 리팩터링됩니다. 응용 프로그램 전체가 웹 서비스로 변환되면 전통적인 서버 기반 로직을 단순히 "끌 수" 있습니다.

Example 3: Database

대부분의 기업용 데이터베이스는 이제 이벤트에 응답하여 코드를 실행하고 발생하는 변경 사항을 자동으로 기록하는 트리거 기반 메커니즘에서 작동합니다. (?) 이로써 변경 사항을 실행하고 추적할 수 있는 두 번째 시스템을 유지할 수 있습니다.
  레거시 시스템에서 변경이 발생할 때마다 새로운 시스템을 설정하여 해당 변경 사항을 캡처하고 보고서를 제공하도록 구성합니다. 시간이 지남에 따라 이러한 이벤트를 직접 두 번째 시스템으로 라우팅할 수 있게 수정할 수 있습니다. 결국 오래된 데이터베이스를 완전히 폐기할 수 있을 것입니다.

Moving forward

미관적인 코드(ugly code)나 복잡한 코드를 변경하려고 할 때, 변경 사항을 추출하고 더 나은 위치로 이동하는 방법을 고려해야 한다는 것을 잊지 말아야 합니다. 위의 몇 가지 예제 중 일부는 플랫폼을 이동하는 것을 포함하고 있지만 다른 몇 가지는 그렇지 않습니다. 충분히 자주 수행하면 언젠가는 이전 시스템 주위에 새로운 것을 성장시킬 수 있습니다.

또는 계속해서 전체 시스템을 조금씩 악화시키는(분해해 버리는, 기존의 틀에서 벗어나 새로운 틀로 전환하는) 패치를 만들어도 됩니다. 결정은 여러분에게 달려 있습니다.