발표자는 먼저 모놀리스에 대한 비판이 항상 사실이 아님을 구체적인 사례를 들어 반박합니다. 예를 들어, Shopify는 2023년 블랙프라이데이 기간 동안 분당 6천만 건의 요청을 처리하며 모놀리스의 뛰어난 확장성을 입증했으며, Facebook과 Shopify는 각각 75분 및 하루 30~40회 배포를 통해 모놀리스 환경에서도 빠른 배포가 가능함을 보여주었습니다. 이는 마이크로서비스가 항상 단순하고 유지보수가 용이하다는 주장과 대조되며, 오히려 ‘마이크로서비스 지옥’에 빠질 수 있음을 경고합니다.
아키텍처 트렌드가 진자처럼 움직이는 주기성을 역사적 관점에서 설명합니다. 2004년 Ruby on Rails의 등장, Twitter와 GitHub의 Rails 기반 초기 성공, 그리고 1998년 XML-RPC에서 SOAP, SOA(Service-Oriented Architecture)로 이어진 흐름, Amazon의 모놀리스에서 SOA로의 성공적 전환(AWS로 발전) 등을 언급합니다. 최근에는 ThoughtWorks 보고서에서 모놀리스의 재부상을 언급하고 있으며, Amazon Prime Video가 마이크로서비스에서 모놀리스로 전환하여 비용을 90% 절감한 사례를 들어 이러한 트렌드의 변화를 뒷받침합니다.
모놀리스와 마이크로서비스의 장단점을 비교하며, 언어, CI/CD 속도, 인프라 복잡성, 지연 시간, 스케일링 전략, 트레이싱, 그리고 경계의 명확성 등 다양한 측면에서 각 아키텍처의 특성을 분석합니다. 특히 마이크로서비스는 ‘콘웨이의 법칙’에 따라 조직의 소통 구조를 반영하며 조직의 확장성에는 유리할 수 있지만, 새로운 제품이나 스타트업에는 적합하지 않을 수 있고, 서비스 간 통신으로 인한 ‘본질적 복잡성’(재시도, 서킷 브레이커 등)을 추가한다고 설명합니다.
발표의 핵심은 ‘모놀리스가 문제가 아니라, 갓 오브젝트(God Object)가 문제’라는 점입니다. 갓 오브젝트는 너무 많은 역할을 수행하고, 응집도가 낮으며, 결합도가 높아 유지보수와 디버깅을 어렵게 만드는 안티패턴입니다. 이러한 갓 오브젝트는 심지어 마이크로서비스 환경에서도 ‘분산형 모놀리스(Distributed Monolith)’라는 더 나쁜 결과를 초래할 수 있습니다.
갓 오브젝트 문제 해결을 위한 두 가지 단계를 제시합니다. 첫째, 더 나은 모델 설계입니다. DRY(Don’t Repeat Yourself) 원칙을 코드 중복이 아닌 ‘지식의 중복’ 관점에서 이해하고, 도메인 주도 설계(DDD)를 통해 도메인 지식을 바탕으로 객체 간의 자연스러운 경계와 응집도를 찾아야 한다고 강조합니다. 둘째, 점진적인 리팩토링입니다. 기술 부채가 쌓인 갓 오브젝트를 한 번에 해결하기보다는 명확한 비즈니스 목표와 연계하여 점진적으로 기능을 분할하고(slicing the feature), Strangler Fig Pattern, Feature Flag, Shadow Traffic과 같은 기술을 활용하여 위험을 최소화하며 배포해야 한다고 조언합니다.