결론 먼저

서비스 분리는 비즈니스 도메인에 따라 수행하는 것이 적합하다. 이는 각 서비스가 특정 도메인에 집중할 수 있게 해주며, 서비스 간 의존성을 낮추는 장점이 있다. 대신, 이런 결정을 통해 기술적 복잡도와 서비스 간의 인터페이스 관리의 어려움을 포기하게 된다.

맥락

이 글은 모놀리스를 마이크로서비스로 분해하거나 기존 서비스를 더 작게 쪼갤 때 "어떤 기준으로 자를 것인가" 를 정해야 하는 상황을 가정한다. 트래픽 규모, 팀 규모, SLO 같은 구체 수치는 시스템마다 다르므로 이 글에서는 결정 축만 정리하고, 가중치는 각자의 맥락에서 조정한다.

비교한 대안들

• 기능 기반 분리: 기능 모듈에 따라 서비스를 나누는 방식.
• 팀 구조 기반 분리: 각 팀의 구조에 따라 서비스를 운영하기 위한 분리.
• 기술 스택 기반 분리: 기술 스택이나 사용 언어에 따라 서비스 분리.

N축 비교

채택한 이유

비즈니스 도메인에 따라 서비스를 분리하면 장애 격리와 각 서비스의 배포 주기를 효율적으로 관리할 수 있다. 특히, 장애가 발생하더라도 해당 도메인에 집중한 서비스만 영향을 받기 때문에 시스템의 전체적인 안정성을 높이는 데 주안점을 두었다.

살아남는 위험

1. 서비스 간의 의존성이 생길 경우, 변경 시 예기치 않은 이슈가 발생할 수 있다. 완화책으로, 서비스 간의 계약을 명확히 하고 지속적인 테스트를 통해 검증해나가야 한다.
2. 도메인 분리에 따른 기술적 복잡성이 증가할 수 있다. 이 부분은 충분한 문서화와 팀 내 교육으로 경감시킬 수 있다.
3. 초기 구축에 많은 시간과 비용이 소요될 수 있다. 이를 해결하기 위해 프로토타입을 통해 간단한 모델을 먼저 구현해 테스트할 수 있다.

되돌리는 조건

서비스 분리에 따른 피드백을 반드시 수집하고, 서비스간 의존성 문제가 발생하거나 장애가 빈번해질 경우 즉시 점검해야 한다. 또한, 일정 기간 내에 서비스가 명확한 비즈니스 가치를 제공하지 못하면 이 결정은 다시 고려되어야 한다.