기사 공유하기

지난 50여 년 동안 소프트웨어 아키텍처 및 애플리케이션 호스팅 모델은 메인프레임에서 마이크로서비스 및 서버리스로의 주요 전환을 경험했다. 메인프레임에서 최신 클라우드 네이티브 아키텍처(CNCF)에 이르기까지 다양한 호스팅 모델은 비즈니스 앱을 개발, 배포 및 유지 관리하는 방식에 영향을 미쳤다.

CNCF(Cloud Native Computing Foundation)는 2015년 설립된 리눅스 재단의 자회사로 클라우드 네이티브 컴퓨팅 채택을 촉진하는 오픈 소스 소프트웨어 기반 단체다. CNDF는 구성 벤더에 구애받지 않는 커뮤니티를 구축하여 오픈소스 프로젝트에 협력하는 것을 목표로 한다. (설명 출처: 솔루션 헌터) https://blog.naver.com/ki630808/221704081117
CNCF(Cloud Native Computing Foundation)는 2015년 설립된 리눅스 재단의 자회사로 클라우드 네이티브 컴퓨팅 채택을 촉진하는 오픈소스 소프트웨어 기반 단체다. CNDF는 구성 벤더에 구애받지 않는 커뮤니티를 구축하여 오픈소스 프로젝트에 협력하는 것을 목표로 한다. (설명 출처: 솔루션 헌터)

IT 서비스 업계에서 새로운 호스팅 모델을 발견할 때마다 팀은 아키텍처의 이점을 최대한 활용하는 데 어려움을 겪었다. 이로 인해 아키텍처 편차 및 안티 패턴과 같은 의도하지 않은 결과가 발생하여 상당한 기술적 부채가 발생했다.

기술 부채 관리는 팀의 건강뿐만 아니라 전체 시스템에서 중요한 역할을 한다. 기술 부채를 적시에 처리하지 않는 IT 리더는 소프트웨어 관련 및 조직적 피해를 일으킬 위험이 있다. 기술 부채는 나쁜 관행을 제도화하고 최고의 인재를 몰아내는 동시에 그 자체로 부채를 먹고 더 많은 부채를 생성할 수 있다.

한편, 마이크로서비스, 클라우드 컴퓨팅 및 컨테이너화와 같은 기술 트렌드는 최근 몇 년 동안 매우 빠르게 확대되어 이러한 기술들 대부분은 이제 최고 소프트웨어 엔지니어, 설계를 담당하는 아키텍트 및 IT 리더의 일상 업무의 일부가 되었다.

그러나 비록 클라우드가 가능한 세상에 살고 있지만, 클라우드를 지원한다고 해서 클라우드 네이티브가 되는 것은 아니다. 사실은 클라우드 네이티브 없이 클라우드를 지원하는 것은 가능할 뿐만 아니라 위험하다. 이러한 추세를 검토하고 클라우드 지원 세상을 최대한 활용하기 위해 기업이 구현해야 하는 아키텍처 및 조직적 변경 사항에 대해 논의하기 전에 현재 우리가 어디에 있고 어디로 가고 있는지 살펴보는 것이 중요하다. 그러므로 이글에서는 최신 클라우드 소프트웨어 아키텍처 설계 및 디자인 추세가 어떠한지 알아보겠다.

[box type=”info”]

‘클라우드 네이티브’란? 

  • 넓은 의미로 정의해 본다면 클라우드의 이점을 최대로 활용할 수 있도록 애플리케이션을 구축하고 실행하는 방식을 말합니다. (출처: CLOUDMATE)
  • 클라우드 네이티브 아키텍처 및 기술은 클라우드에서 빌드되고 클라우드 컴퓨팅 모델을 최대한 활용하는 워크로드를 디자인, 구성 및 운영하는 방법입니다. (출처: 마이크로소프트)
  • “클라우드 네이티브” 애플리케이션은 프라이빗, 퍼블릭 및 하이브리드 클라우드 환경 전체에 지속적인 개발과 자동화된 관리 환경을 제공하기 위해 특별히 설계된 애플리케이션을 뜻합니다. 기업은 클라우드 컴퓨팅을 채택하여 애플리케이션의 확장성과 가용성을 향상시킬 수 있습니다. (출처: 레드햇)

[/box]

클라우드 애플리케이션 호스팅과 앱 서비스 간 종속성 문제 대두

지난 10년은 애플리케이션 호스팅이 클라우드 컴퓨팅의 형태로 서비스로 제공되었을 때 애플리케이션 호스팅에서 큰 변화를 겪었다. 분산 컴퓨팅, 네트워크, 스토리지, 컴퓨팅 등과 같은 서비스 기능이 필요한 애플리케이션 사용 사례는 기존 인프라보다 합리적인 비용으로 클라우드 호스팅으로 프로비저닝(provisioning: 사용자 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요할 때 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것)  하기가 훨씬 쉬워졌다.

또한, 소비자는 자원의 탄력성을 활용하여 수요에 따라 확장 및 축소를 가능하게 할 수 있고, 사용한 스토리지 및 컴퓨팅 리소스에 대한 비용만 지불하면 되는 형태로 바뀌었다. 클라우드 기반 호스팅의 매력은 개발 및 운영팀이 더는 서버 인프라에 대해 걱정할 필요가 없다는 것이다.

개발자는 애플리케이션을 호스팅할 서버 사양을 선택하고, 클라우드는 하드웨어, OS 및 네트워킹을 제공한다. 클라우드 서비스의 IaaS, PaaS, SaaS와 같은 세 가지 유형으로 유연하게 서버를 지정해야 하는 개발팀에 약간의 부담을 줄 수도 있다. 그리고 개발자는 애플리케이션과 환경 설정 구성에 대해서만 걱정하면 된다. 왜냐하면 클라우드 공급자가 모든 서버 인프라, 네트워크 및 모니터링 작업을 처리하기 때문이다.

출처: RedHat https://www.redhat.com/ko/topics/cloud-computing/iaas-vs-paas-vs-saas
출처: RedHat

[box type=”info”]

IaaS, PaaS 및 SaaS 비교

“서비스형(as-a-Service)”이라는 용어는 제3사에서 클라우드 컴퓨팅 서비스를 제공한다는 의미입니다. 따라서 사용자는 코드, 고객 관계 관리와 같은 더 중요한 업무에 집중할 수 있습니다. 각 유형의 클라우드 컴퓨팅을 활용하면 관리해야 할 온프레미스 인프라가 지속적으로 감소합니다.

  • IaaS: 서비스로서의 인프라 또는 IaaS는 온프레미스 인프라에서 한층 발전한 유형입니다. 이는 종량제 서비스로, 필요한 경우 제3사가 스토리지와 가상화와 같은 인프라 서비스를 인터넷을 통해 클라우드로 제공합니다.
  • PaaS: 서비스로서의 플랫폼(PaaS)은 전체 온프레미스 인프라 관리가 조금 더 발전한 형태입니다. PaaS에서는 제공업체가 자체 인프라에서 하드웨어와 소프트웨어를 호스팅하고 이러한 플랫폼을 사용자에게 통합 솔루션, 솔루션 스택 또는 인터넷을 통한 서비스로 제공합니다.
  • SaaS 비교: 서비스로서의 소프트웨어(SaaS) 또는 클라우드 애플리케이션 서비스는 가장 포괄적인 형식의 클라우드 컴퓨팅 서비스로, 모든 애플리케이션은 제공업체가 관리하며 웹 브라우저를 통해 제공됩니다. (이상 출처: RedHat, ‘IaaS, PaaS 및 SaaS 비교’에서 발췌)

[/box]

또한, 클라우드 공급자는 클라우드에서 호스팅 되는 실제 애플리케이션을 제공하므로 클라이언트 조직은 애플리케이션 코드에 대한 책임 없이 애플리케이션 전체를 사용할 수 있다. 기본적으로 소프트웨어 서비스를 제공하지만 클라이언트가 공급자가 제공하는 것 이외의 사용자가 지정한 비즈니스 기능이 필요한 경우 유연하지 않을 수도 있다.

따라서 서비스로서의 인프라 및 서비스로서의 플랫폼에 도입된 탄력적 기능을 통해 서비스의 단일 인스턴스를 필요에 따라 확장할 수 있으므로 확장성을 위해 인스턴스의 중복을 제거할 수 있다. 그러나 이러한 기능은 여러 버전을 보유하거나 모놀리스 기반의 애플리케이션 배포의 부산물과 같은 다른 목적으로 인스턴스를 복제하는 것에 추후 문제가 발생할 여지가 있다.

애플리케이션 아키텍처 진화 및 애플리케이션 호스팅 모델 (출처: InfoQ)
애플리케이션 아키텍처 진화 및 애플리케이션 호스팅 모델 (출처: InfoQ)

더욱이, 서비스로서의 플랫폼은 개발자가 기본 인프라를 프로비저닝 하거나 유지 관리하는 것에 대해 걱정할 필요 없이 자신의 맞춤형 비즈니스 애플리케이션을 호스팅할 수 있게 해주기 때문에 클라우드 옵션 중에서 최적의 장소가 되었다. 그러나 클라우드 호스팅이 모듈식 애플리케이션 설계 및 배포를 장려했지만, 많은 조직에서는 탄력적인 분산 아키텍처에서 작동하도록 설계되지 않은 레거시 애플리케이션을 클라우드로 직접 리프트 앤 시프트하여 ‘모놀리스 지옥(Monolith Hell)’문제가 발생했다.

또한 클라우드로의 전환은 타사 라이브러리 및 기술에 대한 애플리케이션 종속성을 관리해야 하는 업계에 과제를 안겨주었다. 개발자들은 옵션이 너무 많고 타사 도구를 선택하기 위한 기준이 충분하지 않아 어려움을 겪기 시작했고 애플리케이션 서비스 간의 ‘종속성 지옥(Dependency Hell)’을 보기 시작했다. 종속성 지옥에 관해 조금 더 상세히 알아보자면, 크게 라이브러리, 클래스, 서비스 등의 수준에서 발생하는 것을 알 수 있다.

  • 첫째, 자바의 JAR 및 .NET 의 DLL과 같은 라이브러리 종속성을 부적절하게 관리하면 문제가 발생할 수 있다. 예를 들어, 일반적인 스프링 부트 앱에는 140개 이상의 라이브러리 JAR 파일이 포함되어 있다. 애플리케이션에 불필요한 라이브러리를 패키징하지 않았는지 개발자들은 한 번 더 확인해 볼 필요가 있다.
  • 둘째, 애플리케이션 내 개체의 모든 종속성을 명확히 해야 한다. 예를 들어, 컨트롤러 클래스는 비즈니스 서비스 클래스에 종속되고, 서비스 클래스는 리포지토리 클래스에 종속되어 있다고 가정해보자. 소스 코드를 검토하는 동안 애플리케이션 내의 종속성을 검토하고 잘못된 종속성이 없는지 확인해 나중에 각 클래스에 대해 업데이트나 버전 업그레이드를 할 때 하나 또는 다중으로 배포할 수 있도록 해야 한다.
  • 셋째, 시스템에서 마이크로서비스를 사용하는 경우 서로 다른 서비스 간에 직접적인 종속성이 없는지 확인한다. 라이브러리 기반 종속성 지옥은 패키징 문제이고 클래스와 서비스 두 가지는 디자인 문제이다. 다양한 종속성 지옥 시나리오를 더 자세히 조사하고 의도하지 않은 결과를 방지하여 기술의 확산을 방지하기 위한 설계 패턴으로 설계해야 한다.

세분화된 재사용성의 마이크로서비스로 발전

이러한 모놀리스 지옥과 종속성 지옥을 탈피하기 위해 앱 서비스를 조금 더 세분화하여 재사용하기 시작했다. 도메인 주도 개발(DDD) 및 엔터프라이즈 통합 개발(EIP)와 같은 소프트웨어 설계 방식은 2003년 정도부터 사용할 수 있었고 일부 팀은 애플리케이션을 모듈식 서비스로 개발했지만 자바 애플리케이션용 헤비급 J2EE 애플리케이션 서버 및 .NET 애플리케이션용 IIS와 같은 기존 인프라는 모듈식 배포에 도움이 되지 않았다.

클라우드 호스팅, 특히 헤로쿠(Heroku) 및 클라우드 파운더리와 같은 PaaS 제품의 등장으로 개발자 커뮤니티는 진정한 모듈식 배포 및 확장 가능한 비즈니스 앱에 필요한 모든 것을 갖추게 되었다. 이는 마이크로서비스의 발전을 가져왔는데, 마이크로서비스는 세분화되고 재사용 가능한 기능과 환경 설정과 같은 비기능 서비스의 가능성을 제공했다.

헤로쿠는 여러 프로그래밍 언어를 지원하는 클라우드 컴퓨팅 플랫폼이다. Git과 GitHub 등을 지원하고, 많은 서비스를 애드온과 API로 지원한다.출처 2011년에는 세일즈포스가 인수했다. itworld.co.kr/news/63519
헤로쿠는 여러 프로그래밍 언어를 지원하는 클라우드 컴퓨팅 플랫폼이다. 깃(Git)과 깃허브(GitHub) 등을 지원하고, 많은 서비스를 애드온과 API로 지원한다. 2011년 세일즈포스가
인수했다.

마이크로서비스는 2013~2014년에 더욱 인기를 얻었다. 마이크로서비스는 강력하며 소규모 팀이 특정 비즈니스 및 기술 기능의 전체 주기 개발을 소유할 수 있도록 했다. 개발자는 클라이언트 응용 프로그램 또는 기타 서비스와 같은 시스템의 다른 부분에 부정적인 영향을 주지 않고 언제든지 코드를 배포하거나 업그레이드할 수 있다. 서비스는 개별 서비스 수준에서 수요에 따라 확장 또는 축소할 수도 있다. 특정 비즈니스 기능을 사용해야 하는 클라이언트 애플리케이션은 개발자가 솔루션을 처음부터 코딩하거나 애플리케이션에서 솔루션을 라이브러리로 패키징 할 필요 없이 적절한 마이크로서비스를 호출할 수 있다.

마이크로서비스 접근 방식은 서비스 제공자와 서비스 소비자 간의 계약 중심 개발을 장려했다. 이는 전체 개발 시간을 단축하고 팀 간의 종속성을 줄였다. 즉, 마이크로서비스는 팀을 더욱 느슨하게 결합하고 조직, 특히 비즈니스 스타트업에 중요한 솔루션 개발을 가속화했다. 예를 들어, 고객 대 주문 대 재고와 같은 마이크로서비스는 비즈니스 프로세스와 도메인 간의 명확한 경계를 설정하는 데 도움이 된다. 조직에서 ‘제한된 컨텍스트’로 알려진 수직 모듈성 내에서 독립적으로 개발할 수 있다.

고유한 마이크로서비스 아키텍처 문제

이러한 진화는 데브옵스와 같은 다른 모범 사례의 진화를 가속했으며 조직 수준에서 민첩성과 더 빠른 출시 시간을 제공했다. 각 개발팀은 해당 도메인에서 하나 이상의 마이크로서비스를 소유하고 설계, 코딩, 프로덕션 배포, 포스트 프로덕션 지원 및 유지 관리의 전체 프로세스를 책임진다. 그러나 이전 아키텍처 모델과 유사하게 마이크로서비스 접근 방식은 고유한 문제에 봉착했다.

개발 (소프트웨어 공학), 오퍼레이션, 품질 보증(QA)의 조사로서 데브옵스를 나타낸 벤 다이어그램. (출처: 위키미디어 공용, CC BY 3.0)
개발 (소프트웨어 공학), 오퍼레이션, 품질 보증(QA)의 조사로서 데브옵스를 나타낸 벤 다이어그램. (출처: 위키미디어 공용, CC BY 3.0)

상향식 마이크로서비스로 설계되지 않은 레거시 애플리케이션이 마이크로서비스 아키텍처로 강제 전환되면서 잠식되기 시작하여 모놀리스 지옥으로 알려진 안티 패턴이 발생했다. 다른 시도는 하나로 단단하게 짜인 애플리케이션을 여러 마이크로서비스로 인위적으로 나누려고 시도했지만, 이러한 결과로 생성된 마이크로서비스는 기능 면에서 분리되지 않고 여전히 동일한 방식의 애플리케이션에서 분리된 다른 마이크로서비스에 크게 의존하는데, ‘마이크로리스(microliths)’라고 하는 안티 패턴으로 불린다.

모놀리스와 마이크로서비스는 두 가지 다른 패턴이며 마이크로리스가 항상 모놀리스 지옥을 대체하는 것은 아니다. 주의하지 않으면 밀접하게 결합하고 뒤섞인 마이크로서비스를 만들 수 있다. 애플리케이션 기능의 비즈니스 및 확장성 요구사항에 따라서 올바른 선택은 다 다르다.

마이크로서비스 폭발의 또 다른 원치 않는 부작용은 소위 ‘데스스타(Death Star)’ 안티 패턴이다. 서비스 상호 작용 및 인증 및 권한 부여와 같은 서비스 간 보안 측면에서 거버넌스 모델 없이 마이크로서비스가 확산되면 모든 서비스가 기꺼이 다른 서비스를 호출할 수 있는 상황이 종종 발생한다. 또한, 이러한 서비스 호출을 적절히 조정하지 않고 서로 다른 클라이언트 애플리케이션에서 얼마나 많은 서비스를 사용하고 있는지 모니터링하는 것도 문제가 된다. 한편, 넷플릭스 및 트위터와 같은 조직이 이 악몽 같은 시나리오에 직면하고 ‘데스 바이 데스 스타’ 문제에 대처하기 위해 새로운 패턴을 제시해야 하는 방법을 보여준다.

넷플릭스

 

이러한 예는 빅테크 서비스 업체에만 발생하는 극단적인 경우처럼 보일 수 있지만, 클라우드 안티 패턴의 기하급수적인 파괴력을 가진다. 그러므로 IT 서비스 업계는 이전에 세계에서 본 것보다 훨씬 더 큰 무기를 작동하는 방법을 배워야 한다. 서비스 메시, 사이드카, 서비스 오케스트레이션 및 컨테이너와 같은 새로운 아키텍처 패턴은 클라우드 지원 세계에서 잘못된 관행에 대한 효과적인 방어 메커니즘이 될 수 있다. 조직은 이러한 패턴들을 이해하고 더 빨리 채택을 추진해야 한다.

MSA 문제를 보완하는 설계 패턴과 트렌드

마이크로서비스 아키텍처의 문제를 보완해 줄 수 있는 설계 패턴들은 서비스 메시, 서버리스, 컨테이너 기술들을 활용하는 것이다.

1. 서비스 메시 

클라우드 플랫폼, 특히 쿠버네티스와 같은 컨테이너 오케스트레이션 기술의 등장으로 ‘서비스 메시(Service Mesh)’가 주목받고 있다. 서비스 메시는 트래픽 제어, 서비스 검색, 로드 밸런싱, 탄력성, 관찰 가능성, 보안 등과 같은 추가 기능을 추가하는 애플리케이션 서비스 간의 브릿지이다. 이를 통해 애플리케이션이 애플리케이션 수준 라이브러리에서 이러한 기능을 오프로드하고 개발자가 비즈니스 논리에 집중할 수 있게 한다.

또한 istio와 같은 일부 서비스 메시 기술은 기존의 시나리오 테스트 방식으로는 모든 장애를 예측할 수 없어 다양한 오류를 시뮬레이션해 주는 카오스 엔지니어링의 ‘혼돈 주입(chaos injection)’과 같은 기능도 지원하므로 개발자는 애플리케이션과 잠재적으로 상호 의존적인 수십 개의 마이크로서비스의 탄력성과 견고성을 테스트할 수 있다. 따라서, 서비스 메시는 서비스로서의 플랫폼과 서비스로의 컨테이너 위에 잘 맞으며 클라우드 플랫폼 서비스를 통해 클라우드 채택 경험을 향상시킨다.

쿠버네티스 https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/
쿠버네티스

2. 서버리스 

둘째, 지난 2014년 AWS에서 처음으로 선보인 MSA의 문제를 보완해 줄 수 있는 설계 패턴은 ‘서버리스 컴퓨팅(serverless computing)’ 이라고도 하는 서버리스 아키텍처이다. 서버리스는 애플리케이션 개발자로부터 서버 인프라를 완전히 추상화한다는 점에서 서비스로서의 플랫폼 모델보다 한 걸음 더 나아갔다. 서버리스에서는 비즈니스 서비스를 기능으로 작성하고 해당 기능을 클라우드 인프라에 배포하는 방식이다. 서버리스 기술의 몇 가지 예로는 아마존 람다, 스프링 클라우드 함수, 구글 클라우드 함수 및 애저 함수 등이 있다.

서버리스 컴퓨팅

 

3. 컨테이너 기술 활용 

셋째, 컨테이너 기술과 같은 보완 설계 패턴은 비즈니스 서비스의 진정한 격리와 개별 서비스의 확장성을 제공하는 마이크로서버 환경에서 서비스와 앱을 배포하는 데 도움이 되는 마이크로서비스와 거의 같은 시기에 나타났다. 도커, 컨테이너드 및 쿠버네티스와 같은 컨테이너 기술은 마이크로서비스 개발을 매우 잘 보완할 수 있다. 오늘날 마이크로서비스나 컨테이너들 중 하나를 언급하지 않고는 다른 하나를 언급할 수 없다.

Dapr와 OAM 

최근 앱 설계 추세로 볼 때, 마이크로서비스의 발전으로 클라우드 기반의 분산 시스템을 구축하기가 더 쉬워졌다. 그러나 약방의 감초처럼 마이크로서비스를 모든 문제를 해결하기 위한 시도로 마이크로서비스의 남용에 대한 일부 반발을 계속 보고 있다. 따라서 분산 시스템 또는 모듈식 모놀리식 구축과 관련된 일부 추세는 모두 높은 응집력 및 낮은 결합과 같은 기본 아키텍처 원칙으로 돌아간다.

도메인 주도 설계는 이미 많이 알려져 지금은 후기 다수 추세로 간주하지만, 컨텍스트 매핑 및 시스템 내 경계 식별에 대한 좋은 지침을 찾는 설계자들에 의해 계속 강조되고 있다. 마찬가지로 컨텍스트, 컨테이너, 컴포넌트 및 코드를 C4 모델은 시스템을 이해하는 데 도움이 되는 계층적 아키텍처 다이어그램 집합을 만드는 데 매우 유용할 수 있다.

또한, 개발자들에게 이벤트 기반의 탄력적인 분산 애플리케이션을 구축할 수 있도록 지원하는 Dapr는 온프레미스, 클라우드 또는 엣지 장치와 관계 없이 마이크로서비스 구축과 관련된 문제를 해결하고 코드 플랫폼에 구애받지 않는 상태를 유지하도록 도와준다.

Dapr은 클라우드 네이티브 및 서버리스 컴퓨팅을 지원하도록 설계된 무료 오픈 소스 런타임 시스템 (출처: 위키백과 'Dapr')
Dapr은 클라우드 네이티브 및 서버리스 컴퓨팅을 지원하도록 설계된 무료 오픈 소스 런타임 시스템이다. (출처: 위키백과 ‘Dapr’)

Dapr과 함께 오픈 애플리케이션 모델(OAM)은 모두 2019년 말에 마이크로소프트에서 도입했다. 따라서, OAM은 클라우드 네이티브 애플리케이션을 정의하기 위한 사양으로 컨테이너나 오케스트레이터가 아닌 애플리케이션에 중점을 두는 것이 차이점이다.

마찬가지로 Dapr은 클라우드 네이티브 개발을 더 쉽게 만들기 위한 플러그인 가능한 구성 요소가 있는 프레임워크이다. 물론 마이크로소프트가 생성에 참여했지만, 둘 다 오픈 소스 프로젝트이고 모든 클라우드 제공업체에서 작동하며 Dapr은 CNCF 프로젝트가 될 수 있다. Dapr과 OAM은 모두 아직 주요 클라우드 네이티브 애플리케이션 채택을 보지 못했기 때문에 계속 주시해야 할 혁신 추세다.

끝으로 소프트웨어 아키텍처와 데이터 아키텍처 간의 교차점에서 혁신적인 트렌드는 ‘데이터 메시(Data Mesh)’다. 데이터 메시는 API 게이트웨이와 다소 비슷하지만 데이터 측면에 중점을 둔 데이터 게이트웨이로 연결된다. 마이크로서비스가 다중 언어 지속성 계층으로 이어짐에 따라 API 게이트웨이는 추상화, 보안, 확장, 연합 및 계약 기반 개발 기능을 제공한다.

마치며

시간이 지남에 따라 소프트웨어 아키텍처 및 코드에서 개발될 수 있는 안티 패턴을 주시하는 것이 무엇보다도 중요하다. 안티 패턴은 기술적 부채를 유발할 뿐만 아니라 더 중요하게는 해당 도메인 전문가를 사내 조직에서 몰아내기 때문이라고 서론에서 언급했었다. 따라서 사내 조직은 아키텍처 편차나 안티 패턴에 신경 쓰지 않는 사람들만 남을 수 있다.

클라우드 소프트웨어 설계 및 디자인 트렌드에서 보듯이, 성급한 마이크로서비스 채택의 일부로 나타날 수 있는 안정화 격차와 안티 패턴에 초점을 맞추어야 한다. 또한 조직의 팀 구조, 비즈니스 도메인 및 팀의 기술과 같은 특정 요소에 따라 마이크로서비스로 구현해야 하는 애플리케이션과 모놀리식 솔루션으로 유지해야 하는 애플리케이션이 결정된다.

MSA(마이크로서비스 아키텍처)와 모놀리식 비교 (출처 미상)
MSA(마이크로서비스 아키텍처)와 모놀리식 비교 (출처 미상)

몇몇 서비스 회사들은 마이크로서비스에서 모놀리식 아키텍처로 돌아간 경우도 있다. 이러한 모든 아키텍처 모델, 안티 패턴 형태의 안정화 격차, 진화된 디자인 패턴 및 모범 사례로부터 우리가 배운 것은 기술 부채를 가속화하는 새로운 패러다임의 모범 사례를 알지 못하는 초기 단계를 포함하여 아키텍처 진화의 단계로 먼저 실험해 보는 것이다. 클라우드 소프트웨어 업계가 안정화 격차를 해결하기 위해 새로운 디자인 패턴을 개발함에 따라 팀은 아키텍처에 새로운 표준과 패턴을 채택한다.

그러므로, IT 리더는 끊임없이 발전하고 최적화하는 기술 기반에서 실행되는 안정적인 비즈니스 애플리케이션을 제공하는 동시에 끊임없이 성장하는 기술의 급속한 변화로부터 투자를 보호해야 한다. 전 세계의 IT 경영진은 이러한 문제를 점점 더 자주 해결해 왔다. 또한, 기술의 발전을 수용해야 하지만 비즈니스를 지원하는 앱의 지속적인 불안정성을 희생해서는 안 된다. 규율을 지키는 체계적인 아키텍처가 바로 이를 제공할 수 있어야 한다. 새로운 디자인 패턴이 발전하여 새로운 호스팅 모델에 의해 열린 안정화 격차를 해결했기 때문에 위에서 논의된 패턴을 비즈니스 앱을 변동성으로부터 보호하면서 급속한 기술 발전을 선호하는 전략으로 고려하기 바란다.

 

[divide style=”2″]

[box type=”note”]

본 글은 한국지능정보사회진흥원의 지원을 받아 작성되었으며, 디지털서비스 이용지원시스템에 동시 게재합니다. 이 글의 필자는 서진호 인공지능 산업 전문가 & 하이테크 칼럼니스트입니다.

[/box]

 

관련 글