Microservices Architecture

📌 Brief 단기 Summary

Microservices Architecture는 애플리케이션을 비즈니스 기능(Business Capabilities)을 중심으로 구성된 독립적이고 분산된 서비스들의 집합으로 분할하여 구축하는 아키텍처 스타일이다. [1] 이는 대규모 팀의 개발 확장성 한계를 극복하고 개별 컴포넌트의 독립적인 빌드, 테스트, 배포를 가능하게 하여 조직의 기민성을 높인다. [2, 3] 하지만 시스템 내부의 복잡성을 서비스 간 통신 복잡성으로 전이시키므로, 설계 시 고도의 자동화와 실패를 고려한 방어적 설계(Design for failure)가 필수적이다. [1, 3, 4]

📖 Core Content

철학 및 기본 특성: 마이크로서비스는 "한 가지 일을 잘 수행한다(Do one thing and do it well)"는 유닉스 철학을 따른다. [1] 중앙 집중화된 거버넌스와 데이터 관리를 탈피하고, 분산된 데이터 관리 및 스마트 엔드포인트와 단순한 파이프(Smart endpoints and dumb pipes)를 지향하여 진화하는 설계(Evolutionary design)를 가능하게 한다. [1]
프레임워크별 실전 접근 패턴:
- Spring Boot 및 Spring Cloud: 대규모 분산 시스템 구축을 위한 이상적인 도구로 평가받는다. [5] 서비스 디스커버리(Eureka), 서킷 브레이커(Hystrix), 지능형 라우팅(Zuul), 클라이언트 사이드 로드 밸런싱(Ribbon)과 같은 분산 시스템의 일반적인 패턴을 신속하게 구축할 수 있는 도구를 제공한다. [5, 6] 마이크로서비스 생태계를 선도했던 Netflix 역시 자체 솔루션을 Spring Boot 프레임워크 에코시스템에 통합하며 커뮤니티 표준을 적극 수용하는 방향으로 실전 패턴을 정립했다. [6-8]
- NestJS: Node.js 진영에서 엔터프라이즈급 백엔드를 구축하기 위해 사용되며 마이크로서비스 전환에 강력한 강점을 지닌다. [9, 10] 기본적으로 TCP, Redis, NATS, RabbitMQ, Kafka, gRPC 등 다양한 트랜스포트 레이어 통신을 내장하여 지원한다. [9] 또한, 모듈 시스템 구조 자체가 모놀리스를 분해할 때 마이크로서비스의 경계로 자연스럽게 매핑되는 아키텍처적 이점을 제공한다. [9]
모놀리스 선행 원칙 (Monolith-First): 실전 소프트웨어 아키텍처의 대가 마틴 파울러(Martin Fowler)의 조언에 따르면, 처음부터 마이크로서비스 아키텍처로 시작하는 것은 권장되지 않는다. [11] 대신 모놀리식 아키텍처로 시작하여 모듈성을 엄격하게 유지하고, 기존 모놀리스 구조가 확장성에 문제를 일으키는 시점에 도달했을 때 비로소 마이크로서비스로 분리하는 점진적 패턴이 실무에서 성공 확률을 높인다. [11]

⚖️ Trade-offs & Caveats

분산 모놀리스(Distributed Monolith)의 위험성: 여러 마이크로서비스 간에 데이터베이스 엔티티(Entity)를 직접 공유하거나 모듈 경계를 잘못 설정하면, 독립적 배포가 불가능한 '분산 모놀리스' 형태가 되어 아키텍처의 장점을 모두 잃게 된다. [12]
복잡성의 이동과 오케스트레이션 부담: 마이크로서비스로의 전환은 복잡성을 줄여주는 것이 아니라, 단일 컴포넌트 내부의 복잡성을 분산된 컴포넌트 간의 연결 복잡성으로 전가(Shifting)하는 것이다. [3, 4] 따라서 배포, 프로세스 모니터링, 데이터 일관성 유지를 위한 자동화와 오케스트레이션 인프라 구축 비용이 기하급수적으로 증가한다. [3, 13]
네트워크 통신 병목 및 프로토콜 제약: 트래픽이 많은 분산 시스템에서 HTTP와 같은 동기식(Synchronous) 프로토콜은 시스템 처리량의 한계 요인이 될 수 있다. [14] 이를 극복하기 위해 자동 백프레셔(Back pressure)를 지원하는 비동기 메시징 시스템 도입이 필수적으로 요구된다. [14]
횡단 관심사(Cross-Cutting Concerns) 관리의 난해함: 단일 앱에 비해 로깅, 인증, 에러 핸들링, 캐싱 등 횡단 관심사를 여러 서비스와 노드에 걸쳐 일관되게 적용하고 추적하는 것이 매우 까다롭다. [15] 이를 위해 Netflix의 Vector나 Mogul 같은 정교한 고해상도 시스템 분산 추적 모니터링 툴이 필요하다. [16, 17]

🔗 Knowledge Connections

[관계 유형 A (아키텍처/기반 기술)]

Monolithic Architecture
- 연결 이유: 마이크로서비스 아키텍처를 도입하기 전에 선행되어야 할 초기 구조이자 상반되는 아키텍처 개념이다.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 마이크로서비스 도입의 적절한 시점과 시스템을 쪼개기 전 모듈 경계를 정의하는 기초 방법론을 이해할 수 있다. [11]
Cross-Cutting Concerns
- 연결 이유: 분산된 마이크로서비스 아키텍처에서 반드시 중앙집중식/표준화 방식으로 해결해야 할 핵심 과제이다.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 로깅, 보안, 에러 핸들링 등의 비기능적 요구사항이 여러 시스템 컴포넌트에 걸쳐 어떻게 일관되게 주입되고 관리되는지 파악할 수 있다. [15, 18, 19]

[관계 유형 B (구현/활용 도구)]

Spring Cloud
- 연결 이유: Java/Spring Boot 생태계에서 마이크로서비스 아키텍처의 여러 복잡한 패턴을 추상화하여 제공하는 핵심 도구 모음이다.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서비스 디스커버리, 라우팅, 서킷 브레이커 등 분산 시스템의 표준 패턴들이 실제 코드 수준에서 어떻게 자동화되고 구현되는지 알 수 있다. [5, 6]
NestJS Microservices
- 연결 이유: TypeScript 생태계에서 백엔드를 마이크로서비스로 분할할 때 사용할 수 있는 고도화된 전송 계층 및 메시징 통신 구현체이다.
- 이 개념을 통해 더 깊게 이해할 수 있는 부분: gRPC, Kafka, Redis 등 비동기 메시지 브로커가 서비스 간 통신 패턴에 어떻게 매핑되며 코드 상에서 의존성 주입과 어떻게 결합되는지 파악할 수 있다. [9]

Deeper Research Questions

대규모 마이크로서비스 환경에서 동기식 HTTP 방식이 갖는 성능적 한계를 극복하기 위한 비동기 이벤트 기반 메시징 구조(Event-Driven Messaging)는 어떻게 설계되어야 하는가?
마이크로서비스로 분리된 시스템 환경에서 횡단 관심사(보안, 모니터링)를 처리하기 위해, API Gateway 패턴 또는 Service Mesh 인프라는 어떤 역할을 수행하는가?
각기 다른 데이터베이스를 사용하는 분산 서비스 간에 트랜잭션의 원자성(Atomicity)과 데이터 무결성(Consistency)을 유지하기 위한 패턴(예: Two-phase commit)은 무엇인가?
모놀리스 시스템의 스파게티 코드를 도메인 주도 설계(DDD)를 통해 헥사고날 아키텍처로 분리하고, 이를 마이크로서비스 경계로 매핑하는 구체적인 실무 절차는 어떻게 되는가?
마이크로서비스 환경에서 발생하는 장애를 추적하기 위해 Netflix의 사례처럼 매크로에서 마이크로 수준까지 지원하는 분산 시스템 추적 및 고해상도 지표 모니터링 환경을 어떻게 구성할 것인가?

Practical Application Contexts

Implementation: Spring Boot 환경에서는 @EnableDiscoveryClient 및 Feign 클라이언트를 활용하여 서비스 레지스트리 기반 통신을 구현하고, NestJS에서는 @nestjs/microservices를 기반으로 Kafka/gRPC 전송 계층을 설정한다. [9, 20, 21]
System Design: 모듈화된 모놀리스 시스템을 운영하다가, 성능 병목이나 팀 규모 확장에 의한 배포 충돌이 발생하는 도메인(예: 인증, 결제, 사용자 관리)을 선별해 물리적으로 분할된 서비스 아키텍처로 재구성한다. [3, 11]
Operation / Maintenance: 각각 독립적으로 분리된 마이크로서비스들의 안정적인 통합 배포 및 오케스트레이션을 위해 Docker 컨테이너화 및 Kubernetes, Cloud Foundry 같은 인프라 관리 도구 체계를 운영한다. [5, 22]
Learning Path: 단일 앱 내의 모듈/레이어 분리 학습(헥사고날/클린 아키텍처 등) → 분산 시스템의 네트워크 통신(HTTP, RPC, 메시지 큐) 및 장애 대응(Circuit Breaker) 학습 → 도커 오케스트레이션 및 CI/CD 파이프라인 숙달의 흐름으로 진행한다. [5, 11, 14]
My Project Relevance: 현재 진행하는 프레임워크(Spring Boot 혹은 NestJS)의 프로젝트가 당장 마이크로서비스를 필요로 할 정도의 규모인지 평가하고, 만약 초기 단계라면 철저하게 모놀리식 모듈 구조를 유지하되 각 모듈 간 결합도를 낮추는 방향으로 실전 패턴을 설계하는 지침으로 활용할 수 있다.

Adjacent Topics

Event-Driven Architecture
- 확장 방향: 마이크로서비스들이 강하게 결합하는 것을 피하고 시스템 확장성을 극대화하기 위해 비동기 이벤트 스트림(Kafka, RabbitMQ 등)을 통해 통신하는 구조로 학습을 확장한다.
Domain-Driven Design (DDD)
- 확장 방향: 복잡한 비즈니스 로직 속에서 마이크로서비스로 분할하기 위한 정확한 경계(Bounded Context)를 식별하고 비즈니스 모델을 도출해내는 핵심 소프트웨어 설계 기법으로 확장한다.

Last updated: 2026-05-03

9.7 KiB Raw Blame History