마이크로서비스를 사용하지 말아야 할 때는 언제인가요?

Question

Accepted Answer

마이크로서비스는 종종 **잘못된** 시작 선택입니다. 흔한 규칙은 **"monolith first(모놀리스 먼저)"**입니다. 잘 구조화된 모놀리스로 시작하고, 구체적인 이유가 있을 때에만 서비스를 추출하세요.

## 마이크로서비스를 피해야 할 때

```text
✗ 소규모 팀 — 운영할 사람보다 서비스가 더 많음
✗ 초기 단계 제품 — 도메인 경계가 아직 변하는 중
✗ CI/CD, 모니터링, 트레이싱이 갖춰지지 않음
✗ 낮은 트래픽 — 실질적인 확장 압박이 없음
✗ 단순한 도메인 — 분할이 가치가 아니라 비용을 더함
```

## 성급한 분할의 비용

인프로세스 메서드 호출을 네트워크 호출로 옮기면 지연 시간, 장애 양상, 직렬화, 그리고 배포 단위가 추가됩니다. 경계가 잘못되면 이 모든 비용을 치르고 **게다가** 서비스를 넘나들며 리팩터링까지 해야 합니다.

```text
메서드 호출        →  마이크로초, 실패할 수 없음
네트워크 호출       →  밀리초, 타임아웃 가능, 다운 가능
```

## 더 나은 경로

```text
시작: 모듈형 모놀리스(명확한 내부 경계)
  └─▶ 다음 경우에만 서비스 추출:
         · 독립적 확장이 필요하거나, 또는
         · 별도 팀이 독립적 배포를 필요로 하거나, 또는
         · 다른 기술/SLA가 필요
```

## 왜 중요한가

마이크로서비스를 너무 일찍 도입하는 대부분의 팀은 필요하기도 전에 분산 시스템의 부담을 떠안기 때문에 더 빨라지기는커녕 더 느려집니다.

먼저 모놀리스 안에 경계를 유지하면 도메인을 저렴하게 학습하고 나중에 올바른 이음새를 따라 분할할 수 있습니다.