모놀리식 아키텍처 vs 마이크로서비스: 어떤 것이 가장 적합할까요?

모놀리식 접근 방식은 전통적인 소프트웨어 모델입니다. 마이크로서비스는 이후의 소프트웨어 개발을 반영하지만, 그렇다고 해서 모놀리식 아키텍처가 쓸모없어진 것은 아닙니다.

예를 들어, 여러분이 기술 스타트업에서 일하기 시작했고 새로운 회사의 IT 계획을 구현하는 업무를 맡았다고 가정해 보겠습니다. 여러분은 수많은 결정에 직면하게 되지만, 모놀리식 아키텍처나 마이크로서비스 아키텍처를 선택하는 것만큼 기본적이고 광범위한 결정은 없습니다. 소프트웨어 아키텍처를 선택할 때는 조직의 초기 및 장기적인 데이터 처리 요구 사항을 명확히 이해하지 못한 채, 또는 주변 맥락 없이 결정해서는 안 됩니다. 어떤 아키텍처 방식을 선택하느냐에 따라 조직이 비즈니스 목표를 실질적으로 수행할 수 있는 역량에 큰 영향을 미치기 때문입니다.

따라서 여기에는 상당한 위험이 따릅니다. 그리고 새롭게 IT 디렉터로 임명된 만큼, 이 결정은 개인적으로도 매우 중요합니다. 현명하게 선택한다면 앞으로 상상 이상으로 커리어가 성장하는 길로 이어질 수도 있기 때문입니다.

어떤 것을 선택하시겠어요? 먼저 선택할 수 있는 옵션들을 살펴보겠습니다.

앞서 언급했듯이 모놀리식 아키텍처는 전통적인 소프트웨어 개발 모델입니다. 이 방식에서는 하나의 코드베이스가 여러 기능(즉, 비즈니스 기능)을 수행합니다. 컴퓨터 커널이 모든 기능을 제어합니다. 모놀리식 애플리케이션에서는 애플리케이션 전체를 구성하는 모든 코드가 중앙에 있는 하나의 위치에서 관리됩니다.

모놀리식 애플리케이션에는 일반적으로 다음과 같은 구성 요소가 포함됩니다.

• 클라이언트 측 사용자 인터페이스(UI): “클라이언트 측”은 사용자의 컴퓨팅 기기에 표시되는 내용을 의미합니다. UI는 이미지, 텍스트, 브라우저 동작 관련 정보 등 화면을 통해 전달되는 모든 요소를 사용자에게 보여주는 역할을 합니다.

• 데이터베이스: 모놀리식 아키텍처는 데이터를 행과 열로 구성하는 관계형 DBMS(RDMS)를 사용합니다. 이 행과 열은 서로 연관된 데이터 포인트로 구성된 테이블을 형성합니다.

• 서버 측 애플리케이션: 서버 측 애플리케이션은 메모리, CPU, 스토리지 같은 서버 자원을 관리합니다.

모놀리식 아키텍처를 사용하면 여러 가지 장점이 있습니다.

• 간단한 애플리케이션 개발: 하나의 코드베이스로 구축되는 애플리케이션은 개발이 더 쉽고 빠릅니다.

• 기본적인 배포 용이성: 모놀리식 아키텍처는 하나의 실행 파일 또는 디렉토리로 작동하므로 배포가 더 간단합니다. 모놀리식 아키텍처는 구성 요소가 적기 때문에 유지 관리도 더 쉽습니다.

• 간단한 디버깅: 모놀리식 아키텍처에서는 테스트 및 디버깅 작업이 덜 복잡합니다. 엔드 투 엔드 테스트도 중앙 로깅 시스템에서 일괄적으로 수행됩니다

• 보안 강화: 모놀리식 아키텍처는 폐쇄형 시스템이기 때문에 데이터 처리 활동이 완전히 통제되고 사이버 위협으로부터 보호됩니다.

하지만 모놀리식 아키텍처에는 잠재적인 문제점도 있습니다.

• 신기술 도입의 어려움: 모놀리식 애플리케이션은 일반적으로 강하게 결합되어 있어 새로운 기술을 통합하기 어렵습니다.

• 확장성 제한: 단일 기능을 조정하는 정도의 작은 확장이 필요하더라도, 변경 사항을 반영하기 위해 시스템 전체를 분해하고 다시 구축해야 할 수도 있습니다. 이는 많은 시간과 인력이 소요될 수 있습니다.

다른 소프트웨어 개발 모델인 마이크로서비스는 클라우드 네이티브 아키텍처 스타일입니다. 마이크로서비스는 여러 개의 느슨하게 결합된 개별 구성 요소나 서비스로 애플리케이션을 구성합니다. 마이크로서비스 애플리케이션은 특정 작업을 수행하기 위해 함께 작동하는 자체 기술 스택을 보유합니다.

마이크로서비스의 주요 장점은 전체 시스템에 영향을 주지 않고 애플리케이션 내에서 새로운 비즈니스 기능을 처리할 수 있도록 시스템을 쉽게 업데이트할 수 있다는 점입니다. 이를 통해 시간과 인력을 크게 절약할 수 있습니다.

마이크로서비스의 장점은 무궁무진합니다. 지속적인 비즈니스 성장과 새로운 기술 변화를 모두 수용합니다.

• 확장성 향상: 마이크로서비스는 모놀리식 아키텍처에 비해 확장성이 뛰어납니다. 마이크로서비스 아키텍처 내의 개별 서비스는 모듈로 세분화되며, 하나의 확장 명령이 여러 서비스에 동시에 전송될 수 있습니다. 또한 마이크로서비스는 큰 복잡한 애플리케이션을 다루는 데 적합합니다.

• 자동화 가능: 운영 중인 마이크로서비스는 조직이 자동화를 통해 지속적 통합과 지속적 전달(CI/CD) 프로세스를 구현할 수 있도록 지원합니다. 이를 통해 지속적인 일정에 따라 발생하는 코드 업데이트를 개발할 수 있습니다.

• 독립적인 운영: 마이크로서비스 아키텍처는 각 서비스를 운영 셀로 분할합니다. 이러한 독립성 덕분에 하나의 마이크로서비스 애플리케이션이 다른 애플리케이션의 워크플로에 영향을 미칠 위험이 없습니다.

마이크로서비스는 확실한 이점을 제공하지만 복잡성으로 인해 다음과 같은 문제가 발생합니다.

• 테스트 어려움: 마이크로서비스에서는 애플리케이션의 여러 구성 요소가 먼저 테스트되어야 디버깅을 시작할 수 있습니다. 여기에는 종속성 검사, 활동 캐싱 및 데이터 액세스가 포함됩니다.

• 잠재적인 보안 노출: 마이크로서비스 시스템 내의 다양한 프로세스 간에 이루어지는 데이터 교환은 애플리케이션 프로그래밍 인터페이스(API) 게이트웨이를 사용합니다. API 게이트웨이는 인증 및 기타 중요한 활동에서 보안 취약점을 만들 수 있습니다.

• 지연 시간 증가: 마이크로서비스는 애플리케이션을 놀랍도록 확장하지만, 이로 인해 추가적인 지연 및 지연 시간 문제가 발생할 수 있습니다. 시스템이 확장될 때마다 전송되는 데이터의 복잡성과 양이 늘어나 처리 속도가 느려질 수 있습니다.

모놀리식 아키텍처와 마이크로서비스 아키텍처를 본격적으로 비교하기 전에, 더 넓은 맥락을 위해 역사적 배경을 살펴볼 필요가 있습니다.

모놀리식 아키텍처의 기원을 특정 시점으로 규정하기는 어렵습니다. 기술이 복잡할수록 그 출발점을 정확히 짚기 어려워지기 때문입니다. 20세기 중반경 개발되기 시작한 모놀리식 아키텍처도 마찬가지입니다.

IBM®은 이러한 초기 발전 과정에서 중요한 역할을 했습니다. DZone 기고가 Pier-Jean Malandrino는 “1960년대와 1970년대에 메인프레임 컴퓨터를 개발한 IBM 같은 기업들이 초기 소프트웨어 아키텍처를 정의하는 데 핵심적인 역할을 했다”고 설명합니다.¹

모놀리식 아키텍처는 완벽하지 않았습니다. 초창기에는 매우 기초적인 언어로 작성되었고 하나의 기계에서만 실행되도록 설계되곤 했습니다. 전체 시스템이 단 하나의 기계에 포함되어 있었기 때문에 모든 컴퓨터 구성 요소가 강하게 결합되어 있었습니다. 확장은 거의 불가능하거나 불가능에 가까웠으며, 대개 시스템 전체를 재구축해야 했습니다.

한편, 모놀리식 아키텍처가 지금 와서 보면 다소 원시적으로 보일 수 있는 이유는, 다른 어떤 소프트웨어 아키텍처보다 먼저 등장했기 때문이기도 합니다. 그리고 시간이 지나도 꾸준히 유용하고, 심지어 매우 탄력적인 것으로 증명되었습니다. 도입된 지 70년이 지난 지금도 모놀리식 아키텍처가 사용되고 있다는 사실은, 변화만이 유일한 상수인 IT 산업에서 많은 것을 시사합니다.

모놀리식 아키텍처는 오랫동안 사용되어 왔지만, 이제는 유일한 선택지가 아니며 이미 꽤 오래전부터 그랬습니다. 1980년대에 접어들면서 소프트웨어 공학은 모듈화와 객체 지향 프로그래밍 언어 사용으로 변화하는 움직임을 겪었습니다. 1990년대에는 네트워크 컴퓨팅의 발전을 활용할 수 있는 분산 시스템이 등장할 기반이 마련되었습니다.

이러한 흐름은 결국 마이크로서비스의 개발로 이어졌고, 2000년대 클라우드 컴퓨팅과 컨테이너 기술이 본격화되면서 널리 사용되기 시작했습니다. 마이크로서비스 아키텍처는 모놀리식 모델을 개선하기 위해 빠른 확장성과 분산 시스템에 최적화된 구조로 개발되었습니다.

2020년대인 현재 소프트웨어 개발은 모놀리식 아키텍처와 마이크로서비스 아키텍처 두 가지 방향 가운데 하나를 중심으로 이루어지고 있습니다. 기술 발전 속도를 보면 최신 기술이 더 우수하다고 생각하기 쉽고, 실제로 일부 상황에서는 그렇습니다.

하지만 그런 일반화는 위험하며, 실제로 사실이 아닙니다. 모놀리식 아키텍처 특유의 단순성 덕분에 여전히 큰 이점을 얻는 컴퓨팅 환경도 많기 때문입니다.

두 아키텍처는 각각 장단점이 있으며, 기업은 시스템을 선택하기 전에 두 방식을 신중히 평가하고 앞으로의 애플리케이션 개발 요구를 고려해야 합니다.

핵심 운영 단계 관점에서 모놀리식 아키텍처와 마이크로서비스 아키텍처는 어떻게 비교될까요?

• 구성 단계: 두 아키텍처의 큰 차이는 시스템을 구상하는 초기 단계부터 나타납니다. 모놀리식 시스템은 더 기본적인 설계를 사용하기 때문에 구축이 더 간단합니다. 마이크로서비스는 훨씬 더 복잡하며, 구현을 위해 더 많은 계획이 필요합니다.

• 구조: 모놀리식 아키텍처는 하나의 단위로 설계 및 구축됩니다. 마이크로서비스 아키텍처는 여러 개의 작고 배포 가능한 애플리케이션을 조합해 독립적인 서비스 운영을 가능하게 하는 모듈성을 강조합니다.

• 복잡성: 시스템이 복잡해질수록 마이크로서비스 아키텍처에 더 적합합니다. 모듈형 마이크로서비스는 복잡성이 증가하며 따라오는 새로운 기능과 기술을 수용하기 좋습니다.

• 성장: 모놀리식 아키텍처와 마이크로서비스 아키텍처는 모두 초기 사용 시 효과적일 수 있습니다. 하지만 조직이 초기 시스템을 넘어서 확장해야 한다는 시점이 오면 상황이 크게 달라집니다. 이 시점에서 기업은 더 큰 운영 무대가 필요하며, 마이크로서비스는 모놀리식보다 훨씬 다양한 확장 방식을 제공합니다.

• 시장 출시 시간: 제품을 제작해 시장에 출시하기까지 걸리는 시간을 측정하는 중요한 지표입니다. 출시 속도 면에서는 모놀리식 아키텍처가 마이크로서비스보다 뛰어납니다. 단일 코드베이스만 사용하므로 여러 소스의 소프트웨어를 통합하는 데 드는 시간과 노력을 아낄 수 있습니다.

• 확장성: 마이크로서비스 아키텍처는 모듈 형태로 분리 가능한 개별 서비스 기반으로 구성되며, 느슨한 결합과 API 기반 통신의 장점을 갖습니다. 반면 모놀리식 아키텍처는 두껍고 촘촘하게 구성된 핵심 구조와 강하게 결합된 소프트웨어 때문에 확장성과 유연성이 떨어집니다.

• 디버깅: 디버깅은 소프트웨어를 사용하여 코딩 문제를 감지하고 찾아낸 다음 해당 문제를 해결하는 프로세스입니다. 모놀리식 아키텍처는 마이크로서비스보다 디버깅을 더 잘 처리합니다. 더 간단하고 직관적이기 때문입니다. 마이크로서비스 아키텍처를 디버깅하는 것은 상당히 느리고 복잡하며 노동 집약적입니다.

모놀리식 아키텍처나 마이크로서비스 아키텍처를 사용하여 달성할 수 있는 사용 사례는 거의 무제한에 가깝습니다. 다음은 가장 널리 사용되는 몇 가지 예입니다.

• 스타트업: 막 시작하는 회사에는 유연성과 초기 자금, 두 가지 모두가 많이 필요합니다. 초기 단계의 기업에는 모놀리식 아키텍처가 가장 적합합니다. 또한 소규모 개발팀도 큰 학습 곡선 없이 비용 효율적으로 구축할 수 있습니다.

• 기본 프로젝트: 단일 코드베이스는 범위가 단순한 프로젝트에서 특히 유용합니다. 여러 소스의 데이터를 통합할 필요 없이 소프트웨어가 개발 프로세스를 진행할 수 있다면 조직에 큰 도움이 됩니다.

• 엔터테인먼트 플랫폼: 글로벌 엔터테인먼트 플랫폼을 운영하려면 수요가 가벼운 워크로드로 바뀌든 무거운 워크로드로 바뀌든 워크로드의 변화하는 흐름을 따라갈 수 있는 능력이 필요합니다. 넷플릭스의 경우, 이 거대 스트리밍 비디오 업체는 모놀리식 아키텍처에서 클라우드 기반 마이크로서비스 아키텍처로 전환했습니다. 새로운 넷플릭스 백엔드에는 충분한 로드 밸런서 지원 기능이 포함되어 있으며, 이를 통해 작업 부하를 최적화하려는 넷플릭스의 노력을 효과적으로 뒷받침합니다.

• 전자상거래: 전자상거래는 마이크로서비스 아키텍처를 활용하여 원활한 사용자 경험을 통해 전자 마켓플레이스의 매력을 생생하게 구현합니다. Amazon(AWS)과 같은 공격적인 성장 전략을 펼치는 대형 리테일러들이 더 높은 편의성과 더 빠른 배송으로 판매를 촉진하고 있는 상황에서, 2023년 전자상거래 매출 시장이 5조 8천억 달러를 돌파한 이유는 쉽게 이해할 수 있습니다.²

• 가장 어려운 업무: 마이크로서비스를 지속적으로 활용하려면 해당 아키텍처에 필요한 특정 서비스를 직접 설계하고 구현할 수 있는, 훈련된 DevOps 팀의 구축 및 운영 역량이 요구됩니다. 이러한 기술은 복잡한 애플리케이션을 다룰 때 특히 유용합니다.

모놀리식 아키텍처 또는 마이크로서비스 아키텍처를 본격적으로 구현할 때 가장 중요한 부분인 기술 스타트업의 특정 요구 사항을 먼저 고려하지 않고 사실상 ‘공백 상태’에서 설계를 진행한다면, 그 어떤 전체 규모의 구현도 잘못될 수밖에 없습니다.

IT 디렉터로서, 소프트웨어 인프라 결정을 내릴 때 가장 중요한 활동이 바로 이것입니다. 어떤 상황에서 어떤 아키텍처 스타일을 사용해야 하는지 아는 것뿐 아니라,사용 목적에 가장 적합한 시스템이 무엇인지 이해하는 것 또한 필수적입니다.

이러한 자기 분석 과정은 매우 중요합니다. 조직에 가장 적합한 아키텍처 시스템을 선택하는 것뿐 아니라, 앞으로 몇 달, 몇 년 뒤에 회사가 필요로 하게 될 아키텍처 시스템을 정확하게 예측해야 하기 때문입니다. 어떤 의미에서는 미래를 예측하는 역할까지 맡고 있는 셈입니다.

그래서 모놀리식 아키텍처가 지금의 스타트업 상황에서는 완벽해 보일 수 있지만, 미래의 성장 규모를 예상하는 일은 결국 스스로 판단해야 합니다. 그리고 큰 폭의 확장이 예상된다면, 미리 마이크로서비스 아키텍처에 투자하는 것이 더 현명한 선택이 될 수 있습니다. 고려해야 할 변수는 매우 많습니다.

• 사용 중인 비즈니스 논리: 컴퓨터 로직이 컴퓨터에서 무엇이 가능한지와 불가능한지를 결정하듯, 비즈니스 로직도 비즈니스를 어떻게 운영할 수 있고 없는지를 규정하는 비즈니스 규칙에 기반합니다. 기술적으로는, 데이터베이스와 사용자 인터페이스 간에 정보가 전달되는 방식을 정의하는 알고리즘으로 구현됩니다.

• 프런트엔드 개발: 소프트웨어 아키텍처의 프런트엔드를 계획하는 초기 단계부터 어떤 아키텍처 방식을 따를지 정해야 합니다. 각 아키텍처는 고유한 구조를 가지고 있기 때문입니다. 모놀리식 아키텍처에서는 프런트엔드 애플리케이션이 모든 애플리케이션 코드를 담은 하나의 거대한 코드베이스로 구성됩니다. 마이크로서비스 기반 프런트엔드에서는 서로 독립적으로 동작하는 여러 개의 마이크로서비스를 운영할 수 있습니다.

• 장애 허용성: 고려해야 할 또 다른 사항은 얼마나 많은 장애 허용성이 필요한가입니다. 장애 허용성은 매우 까다로운 문제로, 시스템의 단 하나의 구성 요소만 실패해도 전체 애플리케이션이 중단될 수 있습니다. 모놀리식 아키텍처는 구성 요소 간 격리가 전혀 없어 장애 허용성 부족을 심화시키며, 이는 장기간의 다운타임으로 이어질 수 있습니다.

• 예상되는 변화 속도: 모놀리식 아키텍처와 마이크로서비스 아키텍처의 선택은 단순한 소프트웨어 아키텍처의 문제가 아닙니다. 이는 즉시 운영을 시작하는 데 초점을 둔 사고방식과, 실질적인 비즈니스 성장을 이루는 데 중점을 둔 사고방식 중 하나를 선택하는 문제입니다. 성장은 복잡할 수 있지만, 더 빠른 개발 주기와 뛰어난 확장성 같은 마이크로서비스의 특성이 이런 성장을 강하게 뒷받침합니다.