발견을 위한 모놀리식, 최적화를 위한 마이크로서비스

Source: Dev.to

나는 안다, 안다. 또 다른 마이크로서비스 vs. 모놀리식 포스트다. 이 논쟁은 이제 지쳐버린 느낌이다. 하지만 새로운 프로젝트를 시작할 때마다 나는 같은 질문들을 고민하게 된다. 답이 명확하지 않아서가 아니라, 답이 실제로는 당신이 어디에 있느냐와 무엇을 배우고자 하느냐에 달려 있기 때문이다.
여기에는 보편적인 정답이 없다. 내가 배운 것은 선택이 추상적인 “올바른” 아키텍처를 찾는 문제가 아니라, 당신의 상황, 제약, 그리고 가장 중요한 발견에 필요한 것을 고르는 문제라는 것이다.

1. 마이크로서비스는 최적화, 모놀리식은 발견을 가능하게 함

마이크로서비스는 특정 문제에 대한 최적화이다: 팀 규모 확장, 독립적인 배포, 기술 다양성 등. 이미 식별된 제약에 대한 해결책이다.
반면 모놀리식은 발견을 가속한다. 경계가 어디에 있어야 하는지 배우고, 도메인이 스스로 드러나는 것을 이해하며, 분산 시스템의 오버헤드 없이 가정을 빠르게 검증할 수 있게 해준다.

가장 빨리 배울 수 있는 방법부터 시작하고, 실제로 최적화가 필요한 부분을 이해했을 때 최적화를 진행하라.

2. 모놀리식이 나쁜 코드 품질을 변명하게 하지 말라

모놀리식에 대한 부정적인 인식은 아키텍처 자체가 아니라 형편없는 관행에서 온다. 형편없는 모놀리식이 존재하듯이 형편없는 마이크로서비스도 존재한다. 차이는 배포 모델이 아니라 SOLID 원칙과 명확한 경계를 유지하는 설계 규율을 지키느냐에 있다.

3. 시장 출시 속도 vs. 완벽한 아키텍처

배포하고 배우라. 팀은 “완벽한” 아키텍처를 두고 몇 달씩 제품 개발을 차단하곤 한다. 더 나은 접근법은 되돌릴 수 있는 결정을 내리고, 명확한 경계를 설정한 뒤 실제 사용으로부터 배운 것을 기반으로 반복하는 것이다. 완벽함은 움직이는 목표물일 뿐; 모멘텀이 더 중요하다.

4. 데이터 경계는 첫날부터 중요

모놀리식으로 시작하더라도 데이터 소유권을 일찍 정의하라. 시작 단계에서 서비스 간에 데이터베이스를 공유하는 것이 본질적으로 틀린 것은 아니지만, 향후 분리를 가능하게 하는 깨끗한 경계가 필요하다. 얽힌 데이터 모델은 팀을 레거시 아키텍처에 가두어 버린다.

5. 인프라를 일찍 추상화하라

API 게이트웨이와 서비스 추상화를 초기에 도입하라—비록 모든 것이 뒤에서 모놀리식으로 동작하더라도—최종 인프라가 어떻게 될지 모르는 시점에서도 유연성을 확보할 수 있다. 이는 작은 초기 투자가 나중에 큰 선택권을 제공한다.

도메인 기반 서비스: 모듈형 모놀리식

도메인 기반 서비스, 즉 자연스러운 비즈니스 경계(DDD 용어로는 bounded contexts)에 따라 조직된 모듈형 모놀리식을 시작하라. 이렇게 하면 다음을 얻을 수 있다:

• 처음부터 명확한 관심사 분리
• 각 도메인 내 팀의 자율성
• 필요 시 마이크로서비스로의 쉬운 마이그레이션 경로
• 처음부터 분산 시스템을 구축하는 것보다 빠른 초기 개발

실제 증거가 있을 때 마이크로서비스로 전환하라: 독립적인 스케일링 요구, 팀 협업이 병목이 되는 경우, 혹은 운영 복잡성을 감수할 만큼의 특정 기술 요구가 있을 때.