개요
쪼개는 것이 실제로 이득일 때만 모놀리스를 나눕니다. 대개는 팀들이 서로를 막고 있거나, 확장 특성이 크게 다른 구성 요소가 있을 때입니다. 이득이 없으면 그렇다고 말씀드립니다. 마이크로서비스는 복잡성을 옮길 뿐 없애지 않습니다.
핵심 이점
실제 경계를 따라 나누기
서비스는 조직도가 아니라 업무 도메인을 따릅니다. 그렇지 않으면 분산 모놀리스, 양쪽의 단점만 남습니다.
첫날부터 관측 가능하게
분산 추적, 상관관계가 잡힌 로그, 서비스별 지표를 첫 배포 전에 갖춥니다.
필요한 것만 확장
결제와 리포팅이 각각 독립적으로 자원을 받습니다. 함께 키울 이유가 없습니다.
진행 방식
- 01
현황 파악
무엇을 제안하기 전에 기존 시스템과 제약, 비즈니스 목표부터 정리합니다.
- 02
아키텍처 설계
구조와 데이터 모델, 연동 지점을 설계합니다. 결정은 문서로 남깁니다.
- 03
구현
짧은 반복 주기로 납품하며, 코드 리뷰와 상시 확인 가능한 스테이징 환경을 제공합니다.
- 04
테스트 & QA
릴리스마다 자동화 테스트와 성능·보안 점검을 수행합니다.
- 05
출시 & 지원
롤백 계획과 함께 배포하고, 이후 모니터링과 개선을 이어갑니다.
기술 스택
DockerKubernetesRabbitMQgRPCKafkaTraefikOpenTelemetry
활용 사례
배포마다 서로 막히는 팀
여러 팀이 하나의 배포 파이프라인을 공유하며 줄을 서는 상황.
특정 기능에 몰리는 트래픽
이미지 처리나 리포트 생성이 나머지 애플리케이션의 자원을 잠식하는 경우.
인수 이후의 통합
코드를 완전히 합치지 않고도 두 제품이 하나처럼 동작해야 할 때.