본 발표는 모놀리스 아키텍처가 본질적으로 문제가 있으며 마이크로서비스가 항상 해결책이라는 일반적인 인식에 도전합니다. 발표자는 시스템의 진정한 문제는 아키텍처 선택보다는 '갓 오브젝트(God Object)'로 불리는 부실한 소프트웨어 설계 관행에 있다고 주장합니다.
발표자는 Shopify나 Facebook과 같은 실제 사례를 들어 모놀리스의 확장성과 배포 속도에 대한 일반적인 비판을 반박합니다. 또한, 마이크로서비스의 단순성과 유지보수 용이성에 대해서도 의문을 제기하며 ‘마이크로서비스 지옥’의 가능성을 언급합니다. SOA에서 마이크로서비스, 그리고 다시 모놀리스/모듈형 모놀리스로 이어지는 기술 트렌드의 역사적 흐름을 짚어보고, ThoughtWorks 보고서나 Amazon Prime Video 사례와 같이 최근 모듈형 모놀리스의 부상을 시사하는 동향을 제시합니다. 모놀리스와 마이크로서비스의 다양한 특성(언어, CI/배포, 인프라, 지연 시간, 확장성, 트레이싱, 경계, 콘웨이의 법칙)을 비교하며 각각의 장단점을 설명합니다. 발표의 핵심 주장은 아키텍처 자체가 아닌 ‘갓 오브젝트(God Object)’라는 안티 패턴에 있습니다. ‘갓 오브젝트’는 단일 객체가 너무 많은 역할을 하고, 결합도가 높으며 응집도가 낮아 유지보수가 어렵고 경계가 모호한 ‘진흙 공(ball of mud)’과 같습니다. 이러한 ‘갓 오브젝트’는 시스템을 모듈형 모놀리스나 마이크로서비스로 효과적으로 리팩토링하는 것을 방해하며, 오히려 ‘분산 모놀리스’와 같은 더 나쁜 결과를 초래할 수 있음을 지적합니다. ‘갓 오브젝트’의 일반적인 발생 원인으로 DRY(Don’t Repeat Yourself) 원칙을 코드 중복 제거에만 초점을 맞춰 지식 중복이 아닌 유사한 코드를 성급하게 통합하는 오해에서 비롯된다고 설명합니다. 고객, 송장, 영수증 모델링 예시를 통해 근본적으로 다른 도메인 지식을 가진 객체를 코드가 유사하다는 이유로 하나의 ‘Document’ 객체로 통합했을 때 발생하는 문제를 보여줍니다. 발표자는 더 나은 모델 설계를 위해 도메인 주도 설계(DDD)와 같은 접근 방식이 유용하다고 제안하며, 사용자 유형, 게시글 상태, 주문 상태 등 다른 모델링 예시를 제시합니다. 마지막으로, 기존 ‘갓 오브젝트’를 리팩토링하는 실질적인 조언을 제공합니다. 리팩토링은 시간이 걸리므로 명확한 비즈니스 가치와 연계하여 정당성을 확보하는 것이 중요하며, 전체를 한 번에 바꾸기보다 기능별로 작게 나누어(slicing by feature) 점진적으로 진행해야 함을 강조합니다. 또한, 스트랭글러 패턴(Strangler Fig), 피처 플래그(Feature Flags), 섀도우 트래픽(Shadow Traffic)과 같은 점진적 릴리스 기법을 활용하여 위험을 줄일 수 있다고 설명하며, 사용자 및 주문 객체 리팩토링 예시를 통해 구체적인 방법을 제시합니다.
결론적으로, 본 발표는 아키텍처 형태(모놀리스 vs. 마이크로서비스)보다 내부 설계의 품질이 더 중요하다는 점을 강조합니다. 근본적인 문제는 부실한 모델링의 결과인 '갓 오브젝트'입니다. 이를 해결하기 위해서는 도메인 지식의 올바른 이해, DRY 원칙의 정확한 적용, DDD와 같은 설계 원칙 활용, 그리고 구체적인 비즈니스 가치에 연결된 신중하고 점진적인 리팩토링 노력이 필수적입니다.