Microservices

📌 Brief Summary

마이크로서비스(Microservices)는 애플리케이션을 비즈니스 기능 단위로 구성된 작고 독립적인 서비스들로 분할하는 분산 시스템 아키텍처 스타일입니다 [1, 2]. 각 컴포넌트는 개별적으로 작동하고 테스트 및 배포될 수 있어 대규모 개발 팀에 민첩성을 제공하며 시스템의 장애 복구 능력(failover)과 복원력을 향상시킵니다 [1, 3]. 그러나 내부의 복잡성이 서비스 간의 네트워크 통신으로 이동하기 때문에, 고도의 자동화와 오케스트레이션이 필수적으로 요구되는 접근 방식입니다 [4, 5].

📖 Core Content

핵심 철학 및 설계 원칙
- 마이크로서비스 아키텍처는 **"한 가지 일을 잘 수행하라(Do one thing and do it well)"**는 유닉스 철학과 일맥상통합니다 [1].
- 이 아키텍처의 주요 특징으로는 서비스를 통한 컴포넌트화, 비즈니스 기능 중심의 조직 구성, 스마트 엔드포인트와 단순한 파이프(dumb pipes), 분산된 거버넌스와 데이터 관리, 인프라 자동화, 장애를 고려한 설계(Design for failure) 등이 있습니다 [1].
- 각 서비스는 언어에 구애받지 않으므로(Language agnostic) HTTP나 경량 메시징과 같은 프로토콜을 통해 Java, Node.js, Go 등 다양한 플랫폼으로 구현될 수 있습니다 [2].
백엔드 프레임워크별 마이크로서비스 구현
- Spring Boot & Spring Cloud: 서비스 디스커버리(Eureka), 회로 차단기(Hystrix), 지능형 라우팅(Zuul), 클라이언트 사이드 로드 밸런싱(Ribbon) 등 분산 시스템의 공통 패턴을 신속하게 구현할 수 있는 Netflix OSS 통합을 지원합니다 [6, 7]. 현재는 Spring Cloud Load Balancer와 같은 커뮤니티 주도의 솔루션으로 진화하며 엔터프라이즈 마이크로서비스의 핵심 뼈대를 제공하고 있습니다 [8].
- NestJS: TCP, Redis, Kafka, RabbitMQ, gRPC 등 다양한 전송 계층(Transport layers)을 내장하여 마이크로서비스 간의 원활한 통신(요청-응답 및 이벤트 기반 메시지 패턴)을 완벽하게 지원합니다 [9]. 대규모 팀에서 모놀리스를 마이크로서비스 경계로 분할할 때 자연스러운 모듈 시스템을 제공합니다 [9].
- Django & DRF: 논리적 컨텍스트를 개별 앱으로 분리하고, 전체 프로젝트를 여러 개의 Django 프로젝트로 분할하여 독립적인 마이크로서비스로 구성한 후 Docker-compose나 Kubernetes를 통해 오케스트레이션하는 방식으로 확장할 수 있습니다 [10].
대규모 분산 시스템의 성능 분석 및 모니터링
- Netflix와 같은 대규모 시스템에서는 단일 관점으로 전체의 성능을 파악하는 것이 불가능합니다 [11].
- 이를 해결하기 위해 업스트림 및 다운스트림 종속성을 시각화하는 Slalom, 인프라의 성능 병목 현상을 파악하는 Mogul, 인스턴스 수준의 초고해상도 메트릭을 제공하는 Vector 등 매크로에서 마이크로 뷰를 자유롭게 전환할 수 있는 정밀한 분석 도구들이 필수적으로 동반되어야 합니다 [11-15].

⚖️ Trade-offs & Caveats

복잡성의 이동과 운영 오버헤드 증가: 마이크로서비스로의 전환이 시스템의 절대적인 복잡성을 줄여주지는 않습니다. 컴포넌트 내부의 복잡성을 컴포넌트 간의 통신 복잡성으로 이동시킬 뿐입니다 [4, 5]. 따라서 효율적인 배포, 디버깅, 로깅을 위해 반드시 고도화된 오케스트레이션과 자동화 인프라를 먼저 구축해야 합니다 [5, 16].
추적 및 디버깅의 난해함: 단일 애플리케이션 내에서 모든 것이 처리되는 모놀리스와 달리 분산 시스템에서는 오류 추적이 매우 어렵습니다. 이 때문에 추적성(Traceability)을 확보하기 위해 모든 로깅 이벤트에 **요청 ID(Request ID)**를 반드시 기록해야 하는 추가적인 설계 부담이 발생합니다 [5, 16].
컴포넌트 경계 분할의 위험성: 명확한 컴포넌트 경계를 정의하지 못하면 개발과 유지보수가 오히려 퇴보하게 됩니다 [4]. 이와 관련하여 업계 전문가인 마틴 파울러(Martin Fowler)는 **"처음부터 마이크로서비스 아키텍처로 시작하지 말고 모놀리스로 시작하라"**고 권장하며, 모놀리스가 문제를 일으킬 때 비로소 마이크로서비스로 분할할 것을 조언합니다 [17].
조직 규모에 따른 제약: 20명 미만의 소규모 개발팀이라면 마이크로서비스를 도입하기보다는 모놀리스로 시작하는 것이 유지보수에 유리합니다 [16]. 또한 고부하 환경에서는 동기식 HTTP 통신이 병목이 될 수 있으므로, 초기부터 메일, 알림, 로깅과 같은 작업에 자동 백프레셔(Back pressure)가 가능한 비동기 메시징을 도입하는 것이 권장됩니다 [16].

Last updated: 2026-05-03

📚 Legacy Insights & Additional Context

Note

Below is content merged from previous versions of this documentation.

📌 한 줄 통찰 (The Karpathy Summary)

"단단한 한 덩어리의 성(Castle)인가, 유기적으로 연결된 수많은 기지(Off-post)인가." 전체 서비스를 하나의 실행 단위로 묶을 것인지, 아니면 기능별로 쪼개어 네트워크로 통신하게 할 것인지에 대한 아키텍처의 거대한 양갈래 길이다.

📖 구조화된 지식 (Synthesized Content)

Monolithic (모놀리식):
- Pros: 개발이 단순하고, 통합 테스트가 쉬우며, 배포가 간편함.
- Cons: 하나만 고장 나도 전체 서비스 다운. 코드 베이스가 커지면 빌드 시간이 기하급수적으로 늘어남.
Microservices (MSA):
- Pros: 기능별 독립적인 기술 스택 사용 가능. 특정 기능만 부분적 스케일링 가능. 장애 격리 우수.
- Cons: 네트워크 지연 발생. 분산 데이터 무결성 보장 어려움. 인프라 구축 비용 폭증.
Decision Rule: "서비스가 충분히 커서 팀 간 소통 비용이 개발 비용을 압도할 때만 MSA로 간다."

⚠️ 모순 및 업데이트 (RL Update)

최근에는 MSA의 과도한 복잡성에 실망한 기업들이 다시 모놀리식으로 돌아오는 '회귀 현상'이 있다. 하지만 단순히 과거로 가는 것이 아니라, 모놀리식의 편의성과 마이크로서비스의 명확한 경계(Bounded Context)를 결합한 **'Modular Monolith'**가 현실적인 최적 대안으로 급부상하고 있다.

🔗 지식 연결 (Graph)

Related: Event-Driven-Architecture , Domain-Driven-Design
Pattern: Saga-Pattern

7.2 KiB Raw Blame History