서비스 세분성: 마이크로서비스는 언제 진정으로 “마이크로”인가?

Source: Dev.to

마이크로서비스 초창기에는 “작고 독립적”이라는 말이 충분히 간단해 보였습니다. 팀들은 모놀리스를 분리하고, 열두 개 정도의 새로운 서비스를 만들고, 승리를 선언했습니다.

그런데 현실은 달랐습니다: 서비스가 너무 많아지고, 끝없는 통합 고통, 중복된 로직, 그리고 아무도 원하지 않았던 분산 복잡성이 나타났습니다.

어느 순간 “micro”라는 단어가 오해받게 되었습니다. 이것은 크기에 관한 것이 아니라 경계에 관한 것이었습니다.

그렇다면 “micro”는 실제로 무엇을 의미할까요? 그리고 어느 정도가 너무 작은 걸까요?

The Size Myth

먼저 오해를 바로잡아 봅시다: 마이크로서비스는 코드 라인 수로 정의되지 않습니다.

• 500 라인의 마이크로서비스라도 도메인을 섞고 있다면 여전히 너무 클 수 있습니다.
• 50,000 라인의 마이크로서비스라도 응집력 있고 자율적이라면 괜찮을 수 있습니다.

마이크로서비스의 핵심은 독립성에 있습니다:

• 독립적으로 개발·배포될 수 있다.
• 자신의 데이터를 소유한다.
• 명확한 계약을 제공한다.
• 핵심 기능을 수행하기 위해 다른 서비스가 필요하지 않다.

중요한 것은 코드 양이 아니라 컨텍스트를 얼마나 소유하고 있느냐입니다. 마이크로서비스는 가능한 한 작아야 하지만, 도메인이 허용하는 한도 이하로는 작아서는 안 됩니다.

The Domain Lens: Finding Natural Boundaries

좋은 서비스 granularity는 코드가 아니라 도메인에서 시작됩니다.

Domain‑Driven Design (DDD)은 bounded contexts—자신만의 언어, 모델, 규칙을 가진 비즈니스 영역—를 식별하도록 가르칩니다. 이러한 컨텍스트는 자연스럽게 마이크로서비스와 매핑되는 경우가 많습니다.

예시: 전자뱅킹 시스템

• Accounts 컨텍스트는 잔액과 계좌 유형을 관리합니다.
• Payments 컨텍스트는 거래와 이체를 처리합니다.
• Notifications 컨텍스트는 메시지와 알림을 담당합니다.

이것이 명확한 경계입니다. Payments를 Payment Initiation, Payment Validation, Payment Execution, Payment Logging 등으로 더 세분화하면 보통 지나친 세분화가 됩니다. 더 이상 도메인을 모델링하는 것이 아니라 워크플로우를 모델링하는 것이며, 이는 서비스가 너무 미세하게 나뉘었다는 신호입니다.

The Cost of Small

Granularity에는 비용이 따릅니다. 서비스 하나당:

• 새로운 배포 파이프라인이 필요합니다.
• 네트워크 오버헤드와 지연이 발생합니다.
• API 버전 관리와 호환성 문제가 생깁니다.
• 운영 및 모니터링 복잡성이 증가합니다.

이를 50개 혹은 100개로 곱하면 “micro”가 “micromanagement”가 됩니다. 서비스를 관리하기 위해 도구를 만들게 된다면, 너무 성급하게 나눴을 가능성이 높습니다. 마이크로서비스의 목표는 독립성을 가능하게 하는 것이지, 서비스 간 대화를 유지하기 위해 오케스트레이션 프레임워크가 필요하도록 만드는 것이 아닙니다.

아키텍처 다이어그램이 지하철 노선도처럼 보인다면, 서비스는 아마도 마이크로가 아니라 파편화된 상태일 것입니다.

The Signs of Healthy Granularity

적절한 크기의 마이크로서비스는 보통 다음과 같습니다:

• 도메인의 명확한 부분( bounded context )을 소유한다.
• 변경 이유가 하나이며 응집도가 높다.
• 조정 없이 독립적으로 배포할 수 있다.
• 기능을 수행하는 데 필요한 모든 로직을 포함한다.
• 외부 계약은 안정적이고 내부는 자유롭다.

The Organizational Mirror

“올바른” granularity는 팀 구조에 따라 달라집니다.

Conway’s Law는 시스템이 조직의 커뮤니케이션 구조를 반영한다고 말합니다.

• 작고 자율적이며 도메인에 맞춰진 팀은 더 미세한 서비스를 감당할 수 있다.
• 규모가 크고 교차 기능을 가진 팀은 더 거친 서비스가 도움이 될 수 있다.

즉, 완벽한 서비스 크기는 조직이 실제로 운영할 수 있는 크기입니다. Granularity는 고립된 설계 결정이 아니라 독립성과 조정 사이의 사회‑기술적 트레이드오프입니다.

Evolving Granularity Over Time

서비스 경계는 영구적인 것이 아니라, 이해가 깊어짐에 따라 진화합니다.

초기 단계: 더 거칠게 시작한다.

• 관련 기능을 하나의 서비스에 묶는다.
• 도메인 경계가 명확해질 때까지 과도한 세분화를 피한다.

후기 단계: 필요에 따라 분리한다.

• 팀이 배포 조정에 어려움을 겪을 때.
• 서비스 모델이 일관성을 잃을 때.
• 확장성이나 성능 요구가 달라질 때.

이러한 진화적 접근은 아키텍처를 이론적 순수성보다는 현실에 맞추게 합니다. 마이크로서비스는 설계되는 것이 아니라, 반복적으로 발견되는 것입니다.

Conclusion – “Micro” Is About Autonomy, Not Size

microservice라는 단어는 언제나 다소 오해의 소지가 있었습니다. 목표는 서비스를 작게 만드는 것이 아니라 시스템을 독립적으로 만드는 것이었습니다.

올바른 granularity는 다음이 충족될 때 달성됩니다:

• 팀이 서로 방해받지 않고 빠르게 움직일 수 있다.
• 서비스가 응집력 있고 안정적이며 실제 도메인에 맞춰져 있다.
• 시스템 복잡도가 지수적으로가 아니라 선형적으로 증가한다.

이 균형을 맞추면 서비스는 “micro”가 아니라 의미 있는 것이 됩니다. 결국 마이크로서비스는 작아서가 아니라 집중돼 있기 때문에 micro라고 할 수 있습니다.