Booil Jung

마이크로서비스 아키텍처 해부

마이크로서비스 아키텍처(Microservices Architecture, MSA)가 분산 데이터베이스와 분산 서비스에 기반하는지를 묻는 것은 이 아키텍처 스타일의 핵심을 꿰뚫는 중요한 질문이다. 결론부터 말하자면, 분산된 서비스와 데이터베이스는 MSA의 명백하고 필수적인 특성이지만, 그 자체가 근본적인 원칙은 아니다. 이들은 MSA가 추구하는 더 깊은 철학, 즉 서비스 자율성(Service Autonomy)을 실현하기 위한 필연적인 결과물이다.1

MSA의 진정한 목표는 거대하고 복잡한 애플리케이션을 작고, 자율적인 팀이 독립적으로 개발, 배포, 확장할 수 있는 서비스들의 집합으로 구성하여 비즈니스 민첩성을 극대화하는 데 있다.3 각 팀이 다른 팀의 배포 일정이나 기술 스택에 구애받지 않고 자신들의 서비스를 책임지고 운영할 수 있는 환경을 만드는 것이 핵심이다. 이러한 완전한 자율성을 달성하기 위해서는 각 서비스가 자신만의 코드베이스와 실행 환경을 가져야 하며, 이는 자연스럽게 서비스의 물리적 분산으로 이어진다. 더 나아가, 한 서비스의 데이터베이스 스키마 변경이 다른 서비스에 예기치 않은 장애를 일으키는 것을 방지하려면, 데이터 저장소 역시 서비스별로 독립적으로 소유하고 관리해야만 한다. 이 논리적 귀결이 바로 ‘분산 데이터베이스’라는 특성으로 나타나는 것이다.

따라서 MSA를 단순히 기술적 구성 요소의 분산으로만 이해하는 것은 표면적인 접근에 불과하다. 이 아키텍처의 채택은 기술적 선택을 넘어, 조직의 구조와 문화까지 아우르는 전략적 결정이다. MSA는 팀의 자율성을 기술 아키텍처로 구현하려는 시도이며, 이는 콘웨이의 법칙(Conway’s Law)이 시사하는 바와 같이 조직의 구조가 시스템의 설계에 직접적인 영향을 미친다는 점을 명확히 보여준다.2 MSA를 도입한다는 것은 단순히 애플리케이션을 나누는 것이 아니라, 개발팀의 책임과 권한, 그리고 협업 방식을 근본적으로 재편하는 사회-기술적 패러다임의 전환을 의미한다.9

본 보고서는 이러한 관점에서 출발하여, 사용자의 질문에 대한 심층적인 답변을 제공하고자 한다. 먼저 서비스 자율성의 원칙이 어떻게 분산된 서비스라는 결과를 낳는지 탐구하고(섹션 1), 이것이 다시 데이터 주권이라는 원칙으로 이어져 서비스별 데이터베이스 패턴을 요구하게 되는 과정을 분석할 것이다(섹션 2). 이후, 이러한 분산 구조가 야기하는 필연적인 복잡성, 즉 서비스 간 통신(섹션 3)과 데이터 일관성 유지(섹션 4)라는 거대한 도전 과제들을 해결하기 위해 등장한 핵심 아키텍처 패턴들을 상세히 해부할 것이다. 마지막으로, 이 모든 것을 현실에서 가능하게 하는 현대적인 기술 기반(섹션 5)을 살펴봄으로써, MSA가 단순한 기술적 유행이 아닌, 비즈니스 요구에 대응하기 위한 정교하고 복합적인 아키텍처 전략임을 명확히 밝힐 것이다.

마이크로서비스는 하나의 큰 애플리케이션을 구성하는 작고, 독립적으로 배포 가능한 소프트웨어 단위들의 모음으로 정의된다.10 각 서비스는 특정 비즈니스 기능 또는 역량에 초점을 맞춰 구성되며 10, 자신만의 코드베이스, 데이터, 그리고 종속성을 가진 독립된 개체로 존재한다.10 여기서 가장 중요한 특징은 ‘독립적인 배포 가능성(Independent Deployability)’이다.4 이는 특정 서비스의 변경 사항을 반영하기 위해 전체 애플리케이션을 재배포할 필요 없이 해당 서비스만 독립적으로 빌드, 테스트, 배포할 수 있음을 의미한다.7 이러한 철학은 “한 가지 일을 하되, 제대로 하라(Do one thing and do it well)”는 유닉스 철학과 맥을 같이 한다.8 각 서비스는 다른 서비스의 기능에 영향을 주지 않으면서 개발, 배포, 운영, 확장이 가능해야 하며, 이를 위해 서비스 간 통신은 잘 정의된 API를 통해서만 이루어진다.3

MSA의 가치를 제대로 이해하기 위해서는 그 대척점에 있는 모놀리식(Monolithic) 아키텍처를 먼저 살펴봐야 한다. 모놀리식 아키텍처는 애플리케이션의 모든 구성 요소가 하나의 거대한 코드베이스와 실행 파일로 통합된 전통적인 구조를 의미한다.10

초기 단계의 프로젝트나 소규모 애플리케이션에서는 모놀리식 접근 방식이 매우 효율적이다. 모든 코드가 한곳에 있어 개발이 단순하고, 전체 시스템을 한 번에 테스트하기 용이하며, 단일 결과물을 배포하므로 과정이 직관적이다.16 이러한 이유로 프로토타입 개발이나 새로운 도메인을 탐색하는 초기 단계에서는 모놀리식이 여전히 유효하고 권장되는 방식이다.20

하지만 애플리케이션의 규모가 커지고 복잡성이 증가함에 따라 모놀리식 아키텍처는 여러 가지 심각한 문제에 직면하게 되는데, MSA는 바로 이 문제들을 해결하기 위해 등장했다.

• 개발 속도 저하: 코드베이스가 비대해지면 전체 시스템을 이해하고 수정하기가 극도로 어려워진다. 작은 변경 하나가 시스템 전반에 미치는 영향을 파악하기 힘들어지고, 빌드 및 테스트, 배포에 소요되는 시간도 기하급수적으로 늘어나 개발 생산성을 심각하게 저해한다.16
• 장애 격리의 부재: 시스템의 한 부분에서 발생한 사소한 오류나 버그가 전체 애플리케이션의 중단으로 이어질 수 있다. 즉, 단일 장애점(Single Point of Failure) 문제를 내포하고 있어 시스템의 안정성과 가용성을 위협한다.20
• 유연하지 못한 확장성: 애플리케이션의 특정 기능(예: 이미지 처리)에만 부하가 집중되더라도, 해당 기능만 독립적으로 확장(scale-out)할 수 없다. 전체 애플리케이션을 통째로 복제하여 확장해야 하므로 자원 사용이 비효율적이다.23
• 기술 도입의 경직성: 전체 시스템이 단일 기술 스택(프로그래밍 언어, 프레임워크, 데이터베이스)에 종속된다. 이로 인해 특정 기능에 더 적합한 새로운 기술을 도입하거나 기존 기술을 현대화하는 것이 매우 어렵고 비용이 많이 든다.10

MSA로의 전환에서 가장 중요하고 어려운 과제는 서비스를 어떻게 나눌 것인가, 즉 서비스의 경계(Boundary)를 올바르게 정의하는 것이다.23 경계 설정이 잘못되면 서비스 간의 통신이 과도하게 많아지는 ‘채티(chatty)’한 관계가 형성되거나, 여러 서비스가 하나의 기능을 위해 강하게 결합되어 분산된 모놀리스(Distributed Monolith)라는 최악의 결과를 낳을 수 있다.27

이러한 문제를 해결하기 위한 가장 효과적인 전략적 도구가 바로 도메인 주도 설계(Domain-Driven Design, DDD)이다. DDD는 복잡한 비즈니스 도메인을 이해하고 모델링하는 데 초점을 맞추며, 특히 ‘경계 컨텍스트(Bounded Context)’라는 핵심 개념을 통해 서비스 경계를 식별하는 강력한 가이드라인을 제공한다.28

1. 경계 컨텍스트에서 시작: 경계 컨텍스트는 특정 도메인 모델이 유효성을 갖는 명시적인 경계를 의미한다. 이상적으로 하나의 마이크로서비스는 하나의 경계 컨텍스트를 넘어서는 안 된다. 이는 각 서비스가 일관된 비즈니스 언어와 모델을 유지하도록 강제하는 역할을 한다.28
2. 애그리거트(Aggregate)를 통한 서비스 식별: 경계 컨텍스트 내에서 ‘애그리거트’는 함께 변경되고 일관성을 유지해야 하는 관련 객체들의 묶음이다. 애그리거트는 그 자체로 트랜잭션의 경계가 되며, 높은 기능적 응집력을 가지므로 마이크로서비스의 후보로 매우 적합하다.28 예를 들어, 전자상거래 시스템에서 ‘주문(Order)’ 애그리거트는 주문 항목, 배송 정보 등을 포함하며, 이는 ‘주문 서비스’로 구현될 수 있다.
3. 비기능적 요구사항 고려: DDD를 통한 논리적 경계 설정 외에도, 확장성, 보안, 가용성 요구사항이나 팀의 구조와 같은 비기능적 요소들도 서비스 분리 및 통합에 영향을 미칠 수 있다.28

결론적으로, 성공적인 MSA는 기술적 분리가 아닌, 비즈니스 도메인에 대한 깊은 이해를 바탕으로 한 논리적 분리에서 시작된다. DDD는 이러한 논리적 분리를 위한 체계적인 접근법을 제공함으로써 MSA 설계의 핵심적인 역할을 수행한다.

아래 표는 모놀리식 아키텍처와 마이크로서비스 아키텍처의 핵심적인 차이점을 다각도로 비교하여, 각 아키텍처의 근본적인 트레이드오프를 명확히 보여준다. 이는 아키텍처 선택에 있어 중요한 의사결정의 근거를 제공한다.16

특성	모놀리식 아키텍처	마이크로서비스 아키텍처
아키텍처 구조	단일 통합 단위(Single Unified Unit)	독립적인 서비스들의 집합
데이터베이스 관리	공유 데이터베이스(Shared Database)	서비스별 데이터베이스(Database per Service)
배포 단위	전체 애플리케이션	개별 서비스
확장성	전체 애플리케이션 단위의 수직적 확장	개별 서비스 단위의 수평적 확장
장애 격리	낮음 (단일 장애점이 전체 시스템에 영향)	높음 (개별 서비스 장애가 격리됨)
기술 스택	단일 기술 스택 (Homogeneous)	다양한 기술 스택 혼용 가능 (Polyglot)
개발 속도	초기에는 빠르나, 규모 증가 시 급격히 저하	초기에는 복잡하나, 팀 단위로 확장 시 속도 유지
운영 복잡성	초기에는 낮으나, 규모 증가 시 관리 어려움	처음부터 높음 (분산 시스템 관리 필요)
팀 구조	크고, 상호 의존적인 팀	작고, 자율적인 교차 기능 팀 (Cross-functional)

서비스 자율성을 확보하기 위한 논리적 흐름은 필연적으로 데이터 관리 방식으로 이어진다. 진정한 자율성을 위해서는 각 서비스가 자신의 데이터에 대한 완전한 통제권, 즉 ‘데이터 주권(Data Sovereignty)’을 가져야 한다. 이를 구현하는 핵심적인 아키텍처 패턴이 바로 “서비스당 데이터베이스(Database per Service)” 패턴이다.14

이 패턴의 핵심 규칙은 명확하다: 각 마이크로서비스는 자신만의 영구 데이터 저장소를 소유하고 관리해야 한다.33 다른 서비스는 이 데이터베이스에 직접 접근할 수 없으며, 반드시 데이터를 소유한 서비스가 제공하는 공개 API(Public API)를 통해서만 통신해야 한다.33 이는 데이터베이스를 서비스 구현의 내부적인 세부사항으로 취급함으로써, 완벽한 캡슐화(Encapsulation)와 느슨한 결합(Loose Coupling)을 강제하는 강력한 메커니즘이다.

이 패턴이 반드시 서비스마다 별도의 물리적 데이터베이스 서버를 프로비저닝해야 함을 의미하는 것은 아니다. 비용과 관리 효율성을 고려하여 다음과 같은 여러 수준으로 구현될 수 있다 33:

• 서비스별 프라이빗 테이블(Private-tables-per-service): 공유 데이터베이스 서버 내에서 각 서비스가 소유한 테이블 집합에 대한 접근을 논리적으로 제한한다.
• 서비스별 스키마(Schema-per-service): 각 서비스에 전용 데이터베이스 스키마를 할당하여 소유권을 더 명확히 한다.
• 서비스당 데이터베이스 서버(Database-server-per-service): 처리량이 매우 높거나 특별한 성능 요구사항이 있는 서비스를 위해 완전히 독립된 데이터베이스 서버를 할당한다.

여러 마이크로서비스가 단일 데이터베이스를 공유하는 것은 MSA 도입 시 흔히 저지르는 치명적인 실수이며, 이는 MSA가 해결하려던 바로 그 문제들을 다시 야기하는 안티패턴(Anti-pattern)이다.

• 강한 결합(Tight Coupling)의 부활: 한 팀이 담당하는 서비스의 요구사항을 충족시키기 위해 공유 데이터베이스의 스키마를 변경하면, 해당 데이터베이스에 의존하는 다른 모든 서비스들이 예기치 않게 중단될 수 있다.35 이는 결국 모든 관련 팀 간의 긴밀한 조율과 동시 배포를 요구하게 되어, MSA의 핵심 가치인 독립적 배포와 팀 자율성을 완전히 훼손한다.
• 캡슐화 원칙 위반: 개발자들은 공식 API를 통해 통신하는 것보다 공유 데이터베이스에 직접 쿼리를 날리는 손쉬운 방법을 택하려는 유혹에 빠지기 쉽다.33 이는 서비스 간의 보이지 않는 숨겨진 의존성을 만들어내고, 시스템의 복잡성을 증가시키며 유지보수를 극도로 어렵게 만든다.

데이터를 분산 관리하는 “서비스당 데이터베이스” 패턴은 중요한 이점을 제공하는데, 바로 폴리글랏 퍼시스턴스의 실현이다.3 이는 각 서비스의 고유한 요구사항과 데이터 특성에 가장 적합한 데이터 저장 기술을 자유롭게 선택할 수 있음을 의미한다.

예를 들어, 다음과 같은 구성이 가능하다 33:

• 주문 서비스: 트랜잭션의 일관성이 중요하므로 PostgreSQL과 같은 관계형 데이터베이스(RDBMS)를 사용한다.
• 제품 카탈로그 서비스: 복잡하고 비정형적인 데이터를 유연하게 저장하기 위해 MongoDB와 같은 문서 데이터베이스(Document DB)를 사용한다.
• 검색 서비스: 전문(full-text) 검색 기능이 핵심이므로 Elasticsearch를 사용한다.
• 추천 서비스: 사용자 간의 관계나 상품 간의 연결성을 분석하기 위해 Neo4j와 같은 그래프 데이터베이스(Graph DB)를 사용한다.

이처럼 각 서비스가 최적의 도구를 선택함으로써 전체 시스템의 성능과 개발 효율성을 극대화할 수 있다. 이는 단일 데이터베이스 기술에 모든 것을 맞춰야 하는 모놀리식 아키텍처에서는 불가능한 유연성이다.

“서비스당 데이터베이스” 패턴은 서비스 간의 결합 문제를 효과적으로 해결하지만, 동시에 MSA에서 가장 어렵고 본질적인 도전 과제를 만들어낸다: 바로 여러 독립된 데이터베이스에 걸쳐 데이터의 일관성을 유지하는 문제이다.7

고객이 주문을 생성하는 비즈니스 트랜잭션을 생각해보자. 이 과정은 ‘주문 서비스’에서 주문을 생성하고, ‘고객 서비스’에서 고객의 신용도를 확인하며, ‘재고 서비스’에서 상품 재고를 차감하는 등 여러 서비스에 걸쳐 있다. 모놀리식 환경에서는 이 모든 과정을 단일 데이터베이스의 원자적(Atomic) ACID 트랜잭션으로 묶어 간단히 처리할 수 있었다. 하지만 MSA에서는 각 서비스가 별도의 데이터베이스를 가지므로, 전통적인 방식의 트랜잭션은 더 이상 작동하지 않는다.35

이처럼 MSA는 아키텍처 패턴의 연쇄 반응을 일으킨다. ‘서비스 자율성’을 위해 ‘서비스당 데이터베이스’ 패턴을 선택하는 순간, 우리는 ‘분산 트랜잭션 관리’라는 새로운 문제를 해결해야만 하는 상황에 직면한다. 이 문제를 해결하지 못하면 시스템의 데이터는 무결성을 잃고 신뢰할 수 없게 된다. 이 중대한 과제를 해결하기 위한 아키텍처 패턴들이 바로 다음 섹션들에서 다룰 사가(Saga) 패턴과 이벤트 소싱(Event Sourcing)이다. 아키텍트는 단순히 “데이터베이스를 분산하자”고 결정하는 것이 아니라, 그 결정이 필연적으로 가져오는 사가 패턴, 이벤트 버스, 최종적 일관성 관리 등의 후속적인 복잡성과 비용까지 모두 고려하고 계획해야 한다. 이는 MSA가 독립적인 선택들의 메뉴가 아니라, 긴밀하게 연결된 패턴들의 시스템임을 명확히 보여준다.

마이크로서비스 아키텍처는 본질적으로 분산 시스템이다. 모놀리식 아키텍처에서 컴포넌트들이 프로세스 내부의 함수 호출(in-process function call)을 통해 빠르고 안정적으로 통신하는 것과 달리, 마이크로서비스들은 네트워크를 통해 상호작용해야 한다.23 이로 인해 네트워크 지연 시간(latency)과 부분적 장애(partial failure)라는 새로운 변수가 시스템의 복잡성을 증대시킨다.4 이 섹션에서는 분산된 서비스들 간의 상호작용을 관리하기 위한 핵심적인 통신 패러다임과 아키텍처 패턴들을 분석한다.

서비스 간 통신 방식은 크게 동기식(Synchronous)과 비동기식(Asynchronous)으로 나뉜다. 각 방식은 뚜렷한 장단점을 가지며, 사용 사례에 따라 적절히 선택해야 한다.

동기식 통신은 클라이언트가 서비스에 요청을 보낸 후, 응답을 받을 때까지 대기(blocking)하는 방식이다.47

• 대표 프로토콜: HTTP/REST 23, gRPC.47
• 장점: 요청과 응답의 흐름이 명확하여 초기 구현이 비교적 간단하고 이해하기 쉽다.2 특히 클라이언트가 데이터를 조회하고 즉각적인 결과를 화면에 표시해야 하는 경우에 적합하다.
• 단점: 서비스 간의 시간적 결합(temporal coupling)을 야기한다. 요청을 받은 서비스가 응답하기 전에 다른 서비스를 동기적으로 호출해야 한다면, 이 호출 체인(chain)에 묶인 모든 서비스가 동시에 가용한 상태여야 한다. 만약 체인 중 하나의 서비스라도 장애가 발생하거나 응답이 지연되면, 그 영향이 연쇄적으로 전파되어 전체 요청이 실패하는 ‘연쇄적 장애(cascading failures)’를 유발할 수 있다.47 이러한 취약성 때문에 서비스 내부 간의 핵심적인 명령 처리에는 동기식 통신을 지양하는 것이 일반적인 안티패턴으로 간주된다.48

비동기식 통신은 클라이언트가 메시지나 이벤트를 발행한 후, 응답을 기다리지 않고 즉시 자신의 작업을 계속하는 방식이다. 통신은 보통 메시지 브로커(Message Broker)와 같은 미들웨어를 통해 중재된다.23

• 대표 기술: RabbitMQ, Apache Kafka와 같은 메시지 큐 또는 이벤트 스트리밍 플랫폼.
• 장점:
  • 느슨한 결합: 송신자는 수신자가 누구인지, 현재 동작하고 있는지 알 필요가 없어 서비스 간 결합도를 크게 낮춘다.47
  • 탄력성 및 장애 격리: 수신 서비스가 일시적으로 다운되더라도 송신자는 메시지 브로커에 메시지를 보내는 데 성공할 수 있다. 수신 서비스가 복구되면 쌓여있던 메시지를 처리하면 되므로, 시스템 전체의 가용성과 탄력성이 향상된다.47
  • 부하 평준화(Load Leveling): 메시지 큐가 버퍼 역할을 하여 특정 시간에 요청이 폭주하더라도 수신 서비스가 자신의 처리 능력에 맞게 메시지를 순차적으로 소비할 수 있게 한다.49
• 단점: 메시지 브로커라는 추가적인 시스템 구성요소를 관리해야 하는 복잡성이 따른다. 또한, 메시지가 중복으로 전달될 가능성에 대비하여 수신측 로직을 멱등성(Idempotency)을 갖도록 설계해야 하며, 요청에 대한 결과를 다시 받아야 하는 경우 응답을 위한 별도의 큐와 상관관계 ID(Correlation ID)를 관리해야 하는 등 구현이 복잡하다.47

아래 표는 각 통신 스타일의 핵심적인 특성을 비교하여 아키텍트가 특정 사용 사례에 가장 적합한 방식을 선택하는 데 도움을 준다.47

특성	동기식 통신 (REST/gRPC)	비동기식 통신 (메시징)
서비스 결합도	높음 (시간적 결합)	낮음 (시간적, 공간적 분리)
성능/지연시간	단일 호출은 지연시간이 낮으나, 호출 체인에서 누적됨	종단 간 지연시간은 높을 수 있으나, 시스템 전체 처리량은 향상됨
장애 내성	낮음 (연쇄적 장애 발생 가능성 높음)	높음 (장애가 격리되고, 메시지 브로커가 버퍼 역할 수행)
구현 복잡성	초기 구현이 상대적으로 낮음	높음 (메시지 브로커, 멱등성, 보상 트랜잭션 등 고려)
주요 사용 사례	클라이언트-백엔드 간의 데이터 조회, 간단한 읽기 작업	서비스 내부 간의 명령 전달, 이벤트 알림, 비동기 작업 처리

마이크로서비스 환경에서 클라이언트 애플리케이션(예: 웹 프론트엔드, 모바일 앱)이 수많은 내부 마이크로서비스들과 직접 통신하는 것은 여러 문제를 야기한다. 클라이언트는 내부 서비스들의 복잡한 주소와 구조를 모두 알아야 하고, 하나의 화면을 구성하기 위해 여러 서비스에 수십 번의 네트워크 호출을 보내야 하며(Chatty I/O), 모든 서비스가 외부에 직접 노출되어 보안에 취약해진다.52

API 게이트웨이(API Gateway) 패턴은 이러한 문제들을 해결하기 위해 시스템의 단일 진입점(Single Entry Point) 역할을 하는 서버를 두는 것이다.55 객체 지향 디자인의 퍼사드(Facade) 패턴과 유사하게, API 게이트웨이는 다음과 같은 핵심적인 역할을 수행한다 55:

• 요청 라우팅(Request Routing): 클라이언트로부터 받은 요청을 분석하여 적절한 내부 마이크로서비스로 전달한다.55
• 요청 집계(Request Aggregation): 여러 내부 서비스에 대한 호출을 게이트웨이에서 수행하고, 그 결과를 조합하여 단일 응답으로 클라이언트에게 반환한다. 이를 통해 클라이언트와 백엔드 간의 불필요한 네트워크 왕복을 줄여 성능을 개선한다.53
• 공통 기능 처리(Cross-cutting Concerns): 인증/인가, SSL 암호화 종료, 요청 로깅, 사용량 제한(Rate Limiting), 캐싱과 같은 공통적인 기능들을 게이트웨이에서 중앙 집중적으로 처리함으로써, 각 마이크로서비스가 핵심 비즈니스 로직에만 집중할 수 있도록 한다.52

또한, 클라이언트의 종류에 따라 최적화된 API를 제공하기 위해 BFF(Backend for Frontend) 패턴을 적용하여 모바일 앱용 게이트웨이, 웹 프론트엔드용 게이트웨이를 별도로 둘 수도 있다.53 하지만 API 게이트웨이는 그 자체로 또 다른 관리 대상이며, 모든 요청이 집중되므로 단일 장애점이나 성능 병목이 되지 않도록 신중한 설계와 확장이 요구된다.52

클라우드와 컨테이너 기반 환경에서 서비스 인스턴스들은 오토스케일링(Auto-scaling) 등으로 인해 동적으로 생성되고 소멸하며, IP 주소나 포트 번호가 계속해서 바뀐다. 따라서 서비스 클라이언트는 호출하려는 서비스의 네트워크 위치를 정적으로 설정해 둘 수 없다.34

서비스 디스커버리(Service Discovery) 패턴은 이 문제를 해결하기 위한 메커니즘이다. 핵심 구성 요소는 서비스 레지스트리(Service Registry)로, 이는 현재 사용 가능한 모든 서비스 인스턴스들의 네트워크 위치(IP, 포트) 정보를 담고 있는 데이터베이스 역할을 한다.62 서비스 인스턴스는 시작될 때 자신의 정보를 레지스트리에 등록(Register)하고, 종료될 때 등록을 해제(Deregister)한다.

서비스 디스커버리를 구현하는 방식은 크게 두 가지로 나뉜다:

• 클라이언트 측 디스커버리(Client-Side Discovery): 서비스 클라이언트가 직접 서비스 레지스트리에 질의하여 호출할 서비스의 인스턴스 목록과 주소를 받아온다. 그 후, 클라이언트에 내장된 로드 밸런싱 로직(예: Round-robin, Hashing)을 사용하여 목록 중 하나의 인스턴스를 선택해 직접 요청을 보낸다.62 Netflix Eureka(서비스 레지스트리)와 Ribbon(클라이언트 측 로드 밸런서) 조합이 대표적인 예다.
  • 장점: 클라이언트가 로드 밸런싱 전략을 직접 제어할 수 있고, 중간 프록시가 없어 네트워크 홉(hop)이 하나 줄어든다.
  • 단점: 서비스 검색 및 로드 밸런싱 로직이 모든 클라이언트에 구현되어야 하므로, 클라이언트가 서비스 레지스트리에 강하게 결합되고, 다양한 언어와 프레임워크를 사용하는 경우 구현 부담이 커진다.62
• 서버 측 디스커버리(Server-Side Discovery): 클라이언트는 서비스 레지스트리의 존재를 알지 못한다. 대신, 잘 알려진 고정 주소를 가진 라우터나 로드 밸런서에 요청을 보낸다. 그러면 이 라우터가 서비스 레지스트리를 조회하여 가용한 서비스 인스턴스로 요청을 전달(proxy)한다.62 AWS의 Elastic Load Balancer(ELB)나 Kubernetes의 서비스(Service)와 프록시(Proxy)가 이 패턴의 대표적인 예다.
  • 장점: 서비스 검색의 복잡성이 클라이언트로부터 완전히 분리(캡슐화)되어 클라이언트 구현이 단순해진다.67
  • 단점: 라우터라는 추가적인 인프라 구성요소가 필요하며, 이 라우터가 고가용성을 갖추도록 관리해야 한다. 또한 클라이언트에서 라우터를 거쳐 서비스로 가는 추가적인 네트워크 홉이 발생한다.67 현대적인 컨테이너 오케스트레이션 플랫폼인 Kubernetes는 이 서버 측 디스커버리 패턴을 플랫폼 수준에서 기본적으로 제공하여 복잡성을 크게 줄여준다.67

마이크로서비스 아키텍처에서 ‘서비스당 데이터베이스’ 패턴을 채택하는 순간, 우리는 분산 시스템이 가진 가장 근본적인 난제와 마주하게 된다. 바로 여러 서비스에 걸쳐 있는 비즈니스 프로세스에서 데이터의 일관성을 어떻게 보장할 것인가 하는 문제이다. 이 섹션에서는 전통적인 분산 트랜잭션의 한계를 살펴보고, 이를 극복하기 위해 MSA 환경에서 핵심적인 역할을 하는 사가(Saga) 패턴과 이벤트 소싱(Event Sourcing) 패턴을 심층적으로 분석한다.

모놀리식 환경에서 여러 테이블에 걸친 데이터 변경은 데이터베이스가 제공하는 ACID(원자성, 일관성, 고립성, 지속성) 트랜잭션으로 간단하게 묶을 수 있었다. 그러나 여러 서비스가 각자의 데이터베이스를 소유하는 MSA에서는 이러한 접근이 거의 불가능하다.

이 문제를 해결하기 위해 고안된 전통적인 방식이 2단계 커밋(Two-Phase Commit, 2PC) 프로토콜이다. 2PC는 트랜잭션 코디네이터(Transaction Coordinator)가 모든 참여 서비스(데이터베이스)에게 커밋 준비가 되었는지 묻고(1단계), 모두 ‘준비 완료’라고 응답하면 최종 커밋 명령을 내리는 방식이다.71 하지만 2PC는 MSA 환경에서 다음과 같은 치명적인 단점 때문에 거의 사용되지 않는다 71:

• 가용성 저하: 2PC는 동기식 통신을 기반으로 하며, 트랜잭션이 완료될 때까지 모든 참여 서비스의 관련 데이터에 락(Lock)을 건다. 이는 시스템 전체의 성능을 저하시키고, 참여 서비스 중 하나라도 장애가 발생하면 전체 트랜잭션이 중단되어 시스템 가용성을 심각하게 해친다.71
• 기술적 제약: 많은 NoSQL 데이터베이스와 최신 메시지 브로커들은 2PC를 지원하지 않는다.71 이는 폴리글랏 퍼시스턴스의 이점을 활용하는 MSA의 철학과 상충된다.
• 강한 결합: 모든 서비스가 중앙의 코디네이터에 의존하게 되어 서비스 간의 강한 결합을 유발한다.73

따라서 MSA는 가용성을 희생하는 강한 일관성(Strong Consistency) 대신, 느슨한 결합과 비동기 통신을 기반으로 하는 새로운 데이터 일관성 유지 메커니즘을 필요로 하며, 그 해답이 바로 사가 패턴이다.

사가 패턴은 분산 환경에서 데이터 일관성을 유지하기 위한 강력한 메커니즘이다. 사가는 하나의 거대한 글로벌 트랜잭션 대신, 여러 개의 로컬 트랜잭션(Local Transaction) 의 순차적인 집합으로 비즈니스 프로세스를 구성한다.76 각 로컬 트랜잭션은 단일 서비스 내에서 원자적으로 실행되어 자신의 데이터베이스를 업데이트하고, 성공적으로 완료되면 다음 서비스를 호출하기 위한 이벤트나 메시지를 발행한다.76

사가의 핵심은 실패 처리 방식에 있다. 만약 시퀀스 중간의 로컬 트랜잭션이 실패하면, 사가는 이미 성공적으로 완료된 이전 단계의 트랜잭션들을 취소하기 위한 보상 트랜잭션(Compensating Transaction) 을 역순으로 실행한다.77 예를 들어, ‘주문 생성’과 ‘결제 처리’는 성공했지만 ‘재고 차감’이 실패했다면, ‘결제 취소’와 ‘주문 취소’라는 보상 트랜잭션이 실행되어 시스템의 데이터 일관성을 최종적으로 맞추게 된다.

사가 패턴은 구현 방식에 따라 크게 두 가지 모델로 나뉜다.

코레오그래피(Choreography, 안무) 방식은 중앙의 지휘자(Orchestrator) 없이, 각 서비스가 자율적으로 이벤트를 발행하고 구독하며 전체 프로세스를 완성해 나가는 모델이다.75

• 동작 방식: 첫 번째 서비스가 로컬 트랜잭션을 완료한 후 ‘주문 생성됨(OrderCreated)’ 이벤트를 메시지 브로커에 발행한다. 이 이벤트를 구독하고 있던 결제 서비스가 이를 수신하여 자신의 로컬 트랜잭션(결제 처리)을 수행하고, 다시 ‘결제 완료됨(PaymentProcessed)’ 이벤트를 발행한다. 이 과정이 연쇄적으로 일어나 전체 비즈니스 트랜잭션이 완료된다.75
• 장점:
  • 느슨한 결합: 서비스들은 서로를 직접 호출하지 않고 오직 이벤트에만 의존하므로 결합도가 매우 낮다.75
  • 단순성: 참여하는 서비스가 적고 워크플로우가 단순할 경우, 별도의 오케스트레이터 없이 간단하게 구현할 수 있다.75
  • 단일 장애점 부재: 중앙 관제탑이 없으므로 단일 장애점이 발생할 위험이 없다.75
• 단점:
  • 복잡성 증가: 참여하는 서비스가 많아지면 전체 트랜잭션의 흐름을 파악하고 디버깅하기가 매우 어려워진다. “어떤 이벤트가 어떤 서비스를 트리거하는가?”를 추적하기 위해 여러 서비스를 넘나들어야 한다.73
  • 순환 의존성 위험: 서비스들이 서로의 이벤트를 구독하다 보면 A –» B –» A와 같은 순환 의존성이 발생할 위험이 있다.75

오케스트레이션(Orchestration, 지휘) 방식은 사가 오케스트레이터(Saga Orchestrator) 라는 중앙 컨트롤러가 전체 비즈니스 트랜잭션의 흐름을 명시적으로 관리하고 지휘하는 모델이다.75

• 동작 방식: 클라이언트 요청을 받은 서비스(또는 오케스트레이터 자신)가 사가 오케스트레이터를 생성한다. 오케스트레이터는 첫 번째 서비스에 ‘주문 생성’이라는 명령(Command)을 보내고 응답을 기다린다. 성공 응답을 받으면 다음 서비스에 ‘결제 처리’ 명령을 보내는 식으로 순차적으로 작업을 지시한다. 만약 어느 단계에서든 실패 응답을 받으면, 오케스트레이터는 해당 단계까지 성공했던 서비스들에게 보상 트랜잭션을 실행하라는 명령을 보낸다.80
• 장점:
  • 중앙 집중적 관리: 트랜잭션의 모든 흐름과 상태가 오케스트레이터에 중앙 집중화되어 있어, 전체 워크플로우를 이해하고 모니터링하기 쉽다.82
  • 복잡한 워크플로우에 적합: 참여하는 서비스가 많거나, 조건부 분기 등 복잡한 로직이 필요한 경우에 매우 적합하다.75
  • 결합도 관리 용이: 참여 서비스들은 오케스트레이터와만 통신하면 되므로, 서비스 간의 직접적인 의존성이 발생하지 않는다.75
• 단점:
  • 단일 장애점 가능성: 오케스트레이터 자체가 단일 장애점이 될 수 있다. 오케스트레이터에 장애가 발생하면 관련된 모든 트랜잭션이 중단된다.73
  • 과도한 책임 집중 위험: 비즈니스 로직을 참여 서비스에 두지 않고 오케스트레이터에 너무 많이 구현하게 되면, 오케스트레이터가 모든 것을 아는 ‘똑똑한’ 컨트롤러가 되고 참여 서비스들은 단순히 데이터만 처리하는 ‘멍청한’ 서비스로 전락하여 MSA의 분산된 책임 원칙을 해칠 수 있다.74

아래 표는 사가 패턴의 두 가지 구현 모델을 비교하여, 특정 시나리오에 어떤 방식이 더 적합한지 판단하는 데 도움을 준다.73

특성	코레오그래피 (Choreography)	오케스트레이션 (Orchestration)
제어 흐름	분산됨 (이벤트 기반)	중앙 집중됨 (명령 기반)
서비스 결합도	낮음 (서비스 간 직접 의존성 없음)	오케스트레이터에 결합됨
복잡성	로직은 분산되나, 전체 흐름은 복잡함	로직은 중앙 집중되어 단순하나, 오케스트레이터 자체는 복잡함
이해 용이성	낮음 (전체 흐름 추적 어려움)	높음 (명시적인 워크플로우)
확장성/장애점	단일 장애점 없음	오케스트레이터가 단일 장애점 가능성 있음
적합한 사용 사례	참여자가 적고(2~4개) 단순한 워크플로우	참여자가 많고 복잡한 워크플로우, 조건부 로직 필요 시

이벤트 소싱은 데이터 일관성 문제를 해결하는 또 다른 강력한 패턴으로, 종종 사가 패턴과 함께 사용된다. 이 패턴의 핵심 아이디어는 데이터의 현재 상태(current state)를 저장하는 대신, 해당 상태에 도달하기까지 발생한 모든 상태 변경 이벤트를 시간 순서대로 불변의 로그(immutable log)로 저장하는 것이다.17

• 동작 방식: 예를 들어, 고객의 주소를 변경할 때 데이터베이스의 주소 필드를 직접 업데이트(UPDATE)하는 것이 아니라, ‘주소 변경됨(AddressChanged)’이라는 이벤트를 생성하여 이벤트 저장소(Event Store)에 추가(APPEND)한다. 고객의 현재 주소를 알고 싶으면, 해당 고객과 관련된 모든 이벤트를 처음부터 순서대로 다시 실행(replay)하여 메모리상에서 현재 상태를 재구성한다.84
• 장점:
  • 완벽한 감사 추적: 시스템에서 발생한 모든 변경 내역이 이벤트로 기록되므로, 누가, 언제, 무엇을 변경했는지 완벽하게 추적할 수 있는 감사 로그(audit log)를 제공한다.84
  • 시간적 질의(Temporal Query) 가능: 특정 시점의 시스템 상태를 쉽게 재구성할 수 있어 “과거 특정 날짜에 이 상품의 재고는 몇 개였는가?”와 같은 질의를 쉽게 처리할 수 있다.84
  • 이벤트 발행 보장: 상태 변경 자체가 이벤트 생성이므로, 서비스 간 통신을 위한 이벤트를 누락 없이 안정적으로 발행할 수 있는 자연스러운 기반이 된다.84
• 단점: 구현이 개념적으로 복잡하고, 시간이 지남에 따라 이벤트의 스키마가 변경될 때 이를 처리하는 ‘버전 관리’ 문제가 발생할 수 있다. 또한, 매번 이벤트를 리플레이하여 상태를 재구성하는 것은 성능에 부담을 줄 수 있으므로, 주기적으로 현재 상태의 스냅샷(snapshot)을 저장하거나 CQRS(Command Query Responsibility Segregation) 패턴을 함께 사용하여 읽기 성능을 최적화해야 한다.17

사가와 이벤트 기반 통신을 채택한다는 것은, 분산 시스템의 모든 노드가 항상 동일한 데이터를 가지는 강한 일관성을 포기하고, 최종적 일관성 모델을 수용하는 것을 의미한다.28 최종적 일관성이란, 시스템에 더 이상 새로운 변경이 없을 때 일정 시간이 지나면 모든 복제본이 결국 동일한 값으로 수렴하게 되는 것을 보장하는 모델이다.

이는 기술적 선택일 뿐만 아니라 비즈니스적 결정이기도 하다. 즉, 아주 짧은 시간 동안 시스템의 다른 부분들이 약간 다른 데이터를 볼 수 있다는 가능성을 비즈니스가 수용해야 함을 의미한다.89 예를 들어, 고객이 주문을 취소한 직후 배송 서비스에서는 아직 해당 주문이 ‘처리 중’으로 보일 수 있다. 하지만 대부분의 비즈니스 시나리오에서 이러한 일시적인 불일치를 감수하는 대신 얻게 되는 시스템 전체의 높은 가용성과 성능, 확장성의 이점이 훨씬 크다.91 개발자는 이러한 일시적 불일치 상황을 사용자 인터페이스나 비즈니스 로직 수준에서 적절히 처리하도록 시스템을 설계해야 한다(예: “주문 취소 처리 중입니다. 잠시 후 확인해 주세요.”).92

마이크로서비스 아키텍처의 복잡한 개념들을 현실 세계에서 효과적으로 구현하고 운영하기 위해서는 강력한 기술적 기반이 필수적이다. 컨테이너화, 컨테이너 오케스트레이션, 그리고 서비스 메시는 오늘날 MSA를 지탱하는 3대 핵심 기술로, 각각의 기술은 MSA가 직면한 특정 문제들을 해결하며 계층적인 추상화를 제공한다.

• 역할과 개념: 도커(Docker)는 애플리케이션과 그 실행에 필요한 모든 종속성(라이브러리, 시스템 도구, 런타임 등)을 ‘컨테이너(Container)’라는 표준화된 패키지로 묶는 기술이다.93 컨테이너는 운영체제(OS) 수준의 가상화를 통해 격리된 환경을 제공하며, “내 컴퓨터에서는 되는데, 서버에서는 안돼”와 같은 고질적인 환경 불일치 문제를 해결한다.93
• MSA와의 시너지: 컨테이너는 마이크로서비스를 위한 이상적인 배포 단위이다. 각 마이크로서비스를 컨테이너로 패키징함으로써 다음과 같은 이점을 얻는다.
  • 독립성과 격리: 각 서비스는 다른 서비스에 영향을 주지 않는 격리된 환경에서 실행된다. 이는 완전한 가상 머신(VM)의 무거운 오버헤드 없이 프로세스 수준의 격리를 제공하여 자원을 효율적으로 사용하게 한다.94
  • 이식성: 컨테이너는 도커가 설치된 어떤 환경에서든 동일하게 동작하므로, 개발, 테스트, 운영 환경 간의 일관성을 보장하고 클라우드 간 이동을 용이하게 한다.
  • 신속한 배포와 확장: 컨테이너는 가볍고 시작 속도가 매우 빨라, MSA가 추구하는 신속한 배포와 탄력적인 스케일링을 기술적으로 뒷받침한다.93
• 문제 해결: 도커가 단일 컨테이너를 실행하고 관리하는 도구라면, 쿠버네티스(Kubernetes)는 수백, 수천 개의 컨테이너들을 여러 서버 클러스터에 걸쳐 자동으로 배포, 관리, 확장하는 ‘컨테이너 오케스트레이션’ 플랫폼이다.93 수동으로 컨테이너를 관리하는 것은 사실상 불가능하며, 쿠버네티스는 이러한 운영 복잡성을 자동화한다.
• 핵심 기능: 쿠버네티스는 마이크로서비스 운영에 필수적인 다양한 기능을 플랫폼 수준에서 제공한다.
  • 자동 배포 및 스케줄링: 컨테이너를 클러스터 내의 가용한 서버(노드)에 자동으로 배치한다.93
  • 자가 치유(Self-healing): 실행 중인 컨테이너의 상태를 지속적으로 모니터링하여, 장애가 발생한 컨테이너를 자동으로 재시작하거나 교체한다.97
  • 자동 확장(Auto-scaling): CPU 사용량과 같은 지표에 따라 서비스의 컨테이너 수를 자동으로 늘리거나 줄인다.96
  • 서비스 디스커버리 및 로드 밸런싱: 쿠버네티스는 내장된 DNS 시스템과 프록시를 통해 서버 측 서비스 디스커버리(Server-side Service Discovery)와 기본적인 로드 밸런싱 기능을 제공한다. 이를 통해 서비스들은 고정된 서비스 이름을 통해 서로를 찾아 통신할 수 있다.67
• 문제 해결: 애플리케이션이 수십, 수백 개의 마이크로서비스로 구성되면, 이들 간의 네트워크 통신을 관리하는 것 자체가 거대한 도전이 된다. 서비스 간의 안정적인 라우팅, 통신 암호화, 접근 제어, 장애 대응(재시도, 서킷 브레이커), 그리고 전체 시스템의 동작을 파악하기 위한 모니터링 등은 모든 서비스에 공통적으로 필요한 기능이다. 서비스 메시(Service Mesh)는 이러한 복잡한 네트워크 관련 기능들을 애플리케이션 코드에서 분리하여, 인프라 계층에서 처리하도록 하는 기술이다.99
• 동작 원리: 이스티오(Istio)와 같은 서비스 메시는 쿠버네티스 환경에서 사이드카 프록시(Sidecar Proxy) 패턴을 사용한다. 각 마이크로서비스 컨테이너와 함께 엔보이(Envoy)와 같은 경량 네트워크 프록시 컨테이너를 동일한 파드(Pod) 내에 자동으로 주입(inject)한다.101 서비스의 모든 네트워크 트래픽(Inbound/Outbound)은 이 사이드카 프록시를 통과하게 된다.
• 데이터 플레인과 컨트롤 플레인:
  • 데이터 플레인(Data Plane): 실제로 네트워크 트래픽을 처리하는 사이드카 프록시들의 집합이다.102
  • 컨트롤 플레인(Control Plane): 운영자가 설정한 정책에 따라 모든 사이드카 프록시의 동작을 중앙에서 제어하고 구성하는 두뇌 역할을 한다.99
• 주요 기능: 서비스 메시는 개발자가 비즈니스 로직에만 집중할 수 있도록 다음과 같은 강력한 기능들을 인프라 수준에서 제공한다.
  • 트래픽 관리: A/B 테스트, 카나리(Canary) 배포와 같은 점진적 롤아웃, 요청 재시도, 타임아웃, 서킷 브레이커(Circuit Breaker) 등 정교한 트래픽 제어가 가능하다.100
  • 보안: 서비스 간의 모든 통신을 상호 TLS(mTLS)를 통해 자동으로 암호화하고, 강력한 ID 기반의 인증 및 인가 정책을 적용할 수 있다.99
  • 관찰 가능성(Observability): 코드 수정 없이도 모든 서비스 간 호출에 대한 상세한 분산 추적(Distributed Tracing), 측정 지표(Metrics), 접근 로그(Access Logs)를 자동으로 수집하여 시스템의 동작을 깊이 있게 파악하고 문제를 신속하게 진단할 수 있게 한다.100

이 세 가지 기술은 서로 경쟁하는 관계가 아니라, 현대적인 MSA를 구축하기 위한 계층적이고 상호 보완적인 기술 스택을 형성한다. 개발자는 비즈니스 로직을 담은 마이크로서비스를 작성하고, 도커는 이를 이식 가능한 컨테이너로 포장한다. 쿠버네티스는 이 컨테이너들의 생명주기를 클러스터 전체에서 관리하며, 이스티오는 그 위에서 컨테이너 간의 복잡한 네트워크 상호작용을 관리한다. 이러한 강력한 플랫폼의 등장은 개발팀이 분산 시스템의 고질적인 문제들을 직접 해결하는 부담에서 벗어나 비즈니스 가치 창출에 집중할 수 있게 함으로써, MSA의 대중화를 이끈 핵심 동력이 되었다.

본 보고서는 “마이크로서비스 아키텍처는 분산 데이터베이스와 분산 서비스가 핵심인가?”라는 질문에서 출발하여, 이들이 MSA의 본질 그 자체가 아니라 더 근본적인 원칙인 서비스 자율성을 달성하기 위한 필연적인 결과임을 밝혔다. MSA는 기술적 특성들의 단순한 집합이 아니라, 비즈니스 민첩성을 극대화하기 위해 조직과 기술을 정렬하는 정교한 아키텍처 전략이다.

MSA 도입의 결정은 근본적인 트레이드오프(Trade-off)를 수반한다. 이는 거대하고 단단하게 결합된 모놀리식의 내부적, 개발적 복잡성을, 수많은 독립적인 서비스들로 구성된 분산 시스템의 외부적, 운영적 복잡성과 교환하는 행위이다.7 모놀리식에서는 단일 코드베이스 내에서의 의존성 관리가 주된 고민이라면, MSA에서는 서비스 간 통신, 데이터 일관성, 장애 추적, 배포 자동화 등 분산 컴퓨팅의 모든 난제를 정면으로 마주해야 한다.

따라서 MSA로의 전환이 항상 성공을 보장하는 것은 아니다. 성공적인 도입을 위해서는 상당한 수준의 조직적, 기술적 성숙도가 전제되어야 한다.

• 조직적 준비: 아키텍처와 팀 구조를 일치시키는 것, 즉 콘웨이의 법칙을 긍정적으로 활용하는 것이 필수적이다. 각 마이크로서비스를 전담하는 작고 자율적인 교차 기능 팀을 구성하고, 이 팀이 개발부터 운영까지 모든 책임을 지는 데브옵스(DevOps) 문화를 정착시켜야 한다(“You build it, you run it”).2
• 기술적 전문성: 분산 시스템에 대한 깊은 이해, CI/CD 파이프라인과 같은 고도의 자동화 역량, 그리고 쿠버네티스, 서비스 메시와 같은 플랫폼 기술에 대한 전문 지식이 반드시 필요하다.7 이러한 역량 없이는 MSA가 제공하는 자율성의 이점보다 운영의 복잡성으로 인한 비용이 더 커지게 된다.

결론적으로, MSA는 모든 프로젝트의 기본 선택지가 되어서는 안 된다. 이는 개발 속도, 팀 자율성, 그리고 독립적인 확장성이 비즈니스의 핵심 경쟁력이 되는 대규모의 복잡한 애플리케이션을 위한 강력한 패턴이다.7 반면, 규모가 작고 요구사항이 단순한 애플리케이션이나, 아직 분산 시스템 운영 경험이 부족한 팀에게는 잘 구조화된 모놀리식 아키텍처가 여전히 더 실용적이고 효과적인 선택일 수 있다.23

MSA로의 여정은 ‘빅뱅’ 방식의 전면적인 재작성보다는, 기존 모놀리식 시스템에서 새로운 기능을 마이크로서비스로 분리해 내거나, 가장 변화가 잦은 부분을 점진적으로 전환하는 방식이 현명하다.34 궁극적으로 MSA는 기술적 유행을 좇는 것이 아니라, 조직의 비즈니스 목표와 기술적 역량을 신중하게 평가하여 내리는 전략적 아키텍처 결정이어야 한다.

1. 마이크로 서비스 4가지 원칙 - velog, accessed July 13, 2025, https://velog.io/@idnnbi/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C-%EC%84%9C%EB%B9%84%EC%8A%A4-4%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99
2. 마이크로 서비스란 무엇인가? - 한윤석 개발 블로그, accessed July 13, 2025, https://hannut91.github.io/blogs/micro-service/overview

3. 마이크로서비스란 무엇입니까?

   AWS, accessed July 13, 2025, https://aws.amazon.com/ko/microservices/

4. [MSA] 마이크로서비스 심화(1) - 길은 가면, 뒤에 있다. - 티스토리, accessed July 13, 2025, https://12bme.tistory.com/517
5. 마이크로서비스(Microservice) 정의, 구축, 장단점, 사례 - Red Hat, accessed July 13, 2025, https://www.redhat.com/ko/topics/microservices/what-are-microservices

6. 마이크로서비스란 무엇이고 어떻게 작동합니까?

   Okta Identity Korea, accessed July 13, 2025, https://www.okta.com/kr/blog/2021/02/microservices/

7. 마이크로서비스의 장점 및 알아야 할 단점 - Atlassian, accessed July 13, 2025, https://www.atlassian.com/ko/microservices/cloud-computing/advantages-of-microservices
8. 마이크로서비스 - 위키백과, 우리 모두의 백과사전, accessed July 13, 2025, https://ko.wikipedia.org/wiki/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4
9. 1.2. 마이크로서비스 아키텍처(MSA)란 무엇인가? - MSAP.ai, accessed July 13, 2025, https://www.msap.ai/docs/msa-expert-from-concepts-to-practice/part-1-msa-fundamentals/chapter-1-introduction-to-msa/section-1-2-what-is-microservices-architecture/

10. 마이크로서비스 아키텍처란?

    Google Cloud, accessed July 13, 2025, https://cloud.google.com/learn/what-is-microservices-architecture?hl=ko

11. www.redhat.com, accessed July 13, 2025, https://www.redhat.com/ko/topics/microservices/what-are-microservices#:~:text=%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4%20%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EB%8A%94%20%ED%95%98%EB%82%98,%EC%84%9C%20%ED%98%91%EB%A0%A5%ED%95%A0%20%EC%88%98%20%EC%9E%88%EC%8A%B5%EB%8B%88%EB%8B%A4.
12. cloud.google.com, accessed July 13, 2025, [https://cloud.google.com/learn/what-is-microservices-architecture?hl=ko#:~:text=%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4%20%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98(%EC%A3%BC%EB%A1%9C%20%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C,%EC%9A%94%EC%86%8C%EB%A1%9C%20%EA%B5%AC%EB%B6%84%ED%95%A0%20%EC%88%98%20%EC%9E%88%EC%8A%B5%EB%8B%88%EB%8B%A4.](https://cloud.google.com/learn/what-is-microservices-architecture?hl=ko#:~:text=마이크로서비스 아키텍처(주로 마이크로,요소로 구분할 수 있습니다.)
13. 마이크로서비스 란? (구조 및 특징, 아키텍처 구현, 서버리스) - chanstory - 티스토리, accessed July 13, 2025, https://chance-story.tistory.com/34
14. 마이크로서비스란? - ServiceNow, accessed July 13, 2025, https://www.servicenow.com/kr/products/itsm/what-are-microservices.html
15. aws.amazon.com, accessed July 13, 2025, https://aws.amazon.com/ko/microservices/#:~:text=%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4%EC%9D%98%20%ED%8A%B9%EC%A7%95&text=%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4%20%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EC%9D%98%20%EA%B0%81,%EA%B3%B5%EC%9C%A0%ED%95%A0%20%ED%95%84%EC%9A%94%EB%8A%94%20%EC%97%86%EC%8A%B5%EB%8B%88%EB%8B%A4.
16. [MSA] 마이크로서비스 아키텍처(MSA)란 뭘까? - 우당탕탕 - 티스토리, accessed July 13, 2025, https://mozzi-devlog.tistory.com/34
17. 마이크로서비스(Microservice?) 란? - FreeEnd - 티스토리, accessed July 13, 2025, https://freeend.tistory.com/115
18. 모놀리식 아키텍처 vs 마이크로서비스 아키텍처 장단점 비교 - 김징어의 Devlog - 티스토리, accessed July 13, 2025, https://kimjingo.tistory.com/181
19. Monolithic vs Microservices - Difference Between Software Development Architectures, accessed July 13, 2025, https://aws.amazon.com/compare/the-difference-between-monolithic-and-microservices-architecture/
20. 모놀리식 vs 마이크로서비스, 어떤 아키텍처를 선택할까? - 요즘IT, accessed July 13, 2025, https://yozm.wishket.com/magazine/detail/1813/
21. Microservices vs. monolithic architecture - Atlassian, accessed July 13, 2025, https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith
22. Monolithic Application vs Microservices Architecture Guide - OpenLegacy, accessed July 13, 2025, https://www.openlegacy.com/blog/monolithic-application
23. [간단정리] MSA란?(등장배경, 특징, 장단점) - 넌 잘하고 있어 - 티스토리, accessed July 13, 2025, https://hahahoho5915.tistory.com/71
24. 모놀리식 vs 마이크로서비스, 어떤 아키텍처를 선택할까? - Giljae Joo (주길재), accessed July 13, 2025, https://giljae.medium.com/%EB%AA%A8%EB%86%80%EB%A6%AC%EC%8B%9D-vs-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%96%B4%EB%96%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EB%A5%BC-%EC%84%A0%ED%83%9D%ED%95%A0%EA%B9%8C-e73b25d93bc2?source=rss——architecture-5
25. MSA가 좋지만은 않은 이유 - Sungho’s Blog, accessed July 13, 2025, https://sgc109.github.io/2021/10/22/about-msa/
26. 마이크로서비스 아키텍처란? 주요 개념 및 예제 - PayPro Global, accessed July 13, 2025, https://payproglobal.com/ko/%EB%8B%B5%EB%B3%80/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EB%9E%80/
27. Micro Service Architecture(MSA)의 장단점 - 내가 보기 위한 기록 - 티스토리, accessed July 13, 2025, https://sunrise-min.tistory.com/entry/Micro-Service-ArchitectureMSA%EC%9D%98-%EC%9E%A5%EB%8B%A8%EC%A0%90

28. 마이크로서비스 경계 식별 - Azure Architecture Center

    Microsoft Learn, accessed July 13, 2025, https://learn.microsoft.com/ko-kr/azure/architecture/microservices/model/microservice-boundaries

29. [아키텍처] 모놀리식 아키텍처 VS 마이크로 서비스 아키텍처(MSA) - 개발 메모용 블로그, accessed July 13, 2025, https://memodayoungee.tistory.com/155
30. 모놀리식 아키텍처 vs 마이크로서비스 아키텍처(MSA) - 두두네 데브옵스 - 티스토리, accessed July 13, 2025, https://dodo-devops.tistory.com/19
31. Monolithic vs. Microservices Architecture - IBM, accessed July 13, 2025, https://www.ibm.com/think/topics/monolithic-vs-microservices
32. 모놀리식과 마이크로서비스 비교 - 소프트웨어 개발 아키텍처의 차이 - AWS, accessed July 13, 2025, https://aws.amazon.com/ko/compare/the-difference-between-monolithic-and-microservices-architecture/
33. [번역글] MSA 서비스별 데이터베이스 패턴(Database per service pattern) - 코딩하는 흑구, accessed July 13, 2025, https://sas-study.tistory.com/464
34. 마이크로서비스 아키텍처(MSA) 패턴의 이해 - NGINX STORE, accessed July 13, 2025, https://nginxstore.com/blog/microservices/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98msa-%ED%8C%A8%ED%84%B4%EC%9D%98-%EC%9D%B4%ED%95%B4/
35. 마이크로 서비스당 데이터 주권 - .NET - Learn Microsoft, accessed July 13, 2025, https://learn.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-applications/data-sovereignty-per-microservice
36. Pattern: Database per service - Microservices.io, accessed July 13, 2025, https://microservices.io/patterns/data/database-per-service.html
37. [마이크로서비스] MSA의 특징 - velog, accessed July 13, 2025, https://velog.io/@gun_123/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-MSA%EC%9D%98-%ED%8A%B9%EC%A7%95

38. Database per service, shared instance or shared database?

    by Francesca Motisi - Medium, accessed July 13, 2025, https://medium.com/@mts88/database-per-service-or-shared-database-e73cfb756aa1

39. 클라우드 네이티브 데이터 패턴 - .NET - Learn Microsoft, accessed July 13, 2025, https://learn.microsoft.com/ko-kr/dotnet/architecture/cloud-native/distributed-data
40. Database-per-service pattern - AWS Prescriptive Guidance, accessed July 13, 2025, https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/database-per-service.html
41. MSA란? (2) 장점과 단점 - 메타넷글로벌, accessed July 13, 2025, https://metanetglobal.com/bbs/board.php?bo_table=tech&wr_id=136

42. 마이크로서비스 Microservices (5) 이벤트 주도 데이터 관리

    Eric Han’s IT Blog, accessed July 13, 2025, https://futurecreator.github.io/2018/10/19/microservices-and-event-driven-data-management/

43. 마이크로서비스 사가 패턴 - Medium, accessed July 13, 2025, https://medium.com/@greg.shiny82/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%82%AC%EA%B0%80-%ED%8C%A8%ED%84%B4-544fc1adf5f3
44. 마이크로 서비스에서 분산 트랜잭션 - Giljae Joo (주길재), accessed July 13, 2025, https://giljae.medium.com/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%97%90%EC%84%9C-%EB%B6%84%EC%82%B0-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-347af5136c87

45. 마이크로서비스 Microservices (3) 프로세스 간 통신

    Eric Han’s IT Blog, accessed July 13, 2025, https://futurecreator.github.io/2018/10/04/inter-process-communication-in-microservices/

46. [Spring Cloud] 마이크로서비스간 통신 (RestTemplate vs FeignClient), accessed July 13, 2025, https://minnseong.tistory.com/23
47. 마이크로서비스 간 통신 과정에서 주의해야할 점 - velog, accessed July 13, 2025, https://velog.io/@suhongkim98/MSA%EC%99%80-DDD-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B0%84-%ED%86%B5%EC%8B%A0-%EB%B0%A9%EB%B2%95-4-%EC%9E%91%EC%84%B1-%EC%A4%91

48. 마이크로 서비스 아키텍처의 통신 - .NET

    Microsoft Learn, accessed July 13, 2025, https://learn.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-applications/communication-in-microservice-architecture

49. 마이크로 서비스의 서비스 간 통신 - Azure Architecture Center

    Microsoft Learn, accessed July 13, 2025, https://learn.microsoft.com/ko-kr/azure/architecture/microservices/design/interservice-communication

50. 마이크로서비스에서 안정적인 운영을 위한 통신 구현 방안 - Medium, accessed July 13, 2025, https://medium.com/@greg.shiny82/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4%EC%97%90%EC%84%9C-%EC%95%88%EC%A0%95%EC%A0%81%EC%9D%B8-%EC%9A%B4%EC%98%81%EC%9D%84-%EC%9C%84%ED%95%9C-%ED%86%B5%EC%8B%A0-%EA%B5%AC%ED%98%84-%EB%B0%A9%EC%95%88-2e60bbff49f0
51. 마이크로서비스 관계 패턴 - 통신 패턴과 Event driven architecture, accessed July 13, 2025, https://engineering-skcc.github.io/microservice%20outer%20achitecture/inner-architecture-conn/

52. API 게이트웨이 패턴과 직접 클라이언트-마이크로 서비스 통신 비교 - .NET

    Microsoft Learn, accessed July 13, 2025, https://learn.microsoft.com/ko-kr/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern

53. API Gateway - msaschool, accessed July 13, 2025, https://www.msaschool.io/operation/architecture/architecture-one/
54. API 게이트웨이 - Azure Architecture Center - Learn Microsoft, accessed July 13, 2025, https://learn.microsoft.com/ko-kr/azure/architecture/microservices/design/gateway
55. 마이크로서비스 구축을 위한 API Gateway 패턴 사용하기 - NGINX STORE, accessed July 13, 2025, https://nginxstore.com/blog/api-gateway/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B5%AC%EC%B6%95%EC%9D%84-%EC%9C%84%ED%95%9C-api-gateway-%ED%8C%A8%ED%84%B4-%EC%82%AC%EC%9A%A9%ED%95%98%EA%B8%B0/

56. API Gateway Pattern. In this article, we are going to talk…

    by Mehmet Ozkaya

    Design Microservices Architecture with Patterns & Principles

    Medium, accessed July 13, 2025, https://medium.com/design-microservices-architecture-with-patterns/api-gateway-pattern-8ed0ddfce9df

57. API Gateway Patterns in Microservices - GeeksforGeeks, accessed July 13, 2025, https://www.geeksforgeeks.org/system-design/api-gateway-patterns-in-microservices/
58. API Gateway Pattern: 5 Design Options and How to Choose - Solo.io, accessed July 13, 2025, https://www.solo.io/topics/api-gateway/api-gateway-pattern
59. Introduction to API Gateway in Microservices Architecture - IMESH, accessed July 13, 2025, https://imesh.ai/blog/introduction-to-api-gateway-in-microservices-architecture/
60. API Gateway Patterns for Microservices - Oso, accessed July 13, 2025, https://www.osohq.com/learn/api-gateway-patterns-for-microservices
61. The API gateway pattern versus the direct client-to-microservice communication - .NET, accessed July 13, 2025, https://learn.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern
62. 서비스 디스커버리 패턴 - msaschool, accessed July 13, 2025, https://www.msaschool.io/operation/design/design-six/
63. MSA에서 Service discovery 패턴 - 조대협의 블로그 - 티스토리, accessed July 13, 2025, https://bcho.tistory.com/1252

64. Microservices: Service Discovery Patterns and 3 Ways to Implement

    Solo.io, accessed July 13, 2025, https://www.solo.io/topics/microservices/microservices-service-discovery

65. www.solo.io, accessed July 13, 2025, https://www.solo.io/topics/microservices/microservices-service-discovery#:~:text=A%20service%20discovery%20pattern%20enables,service%20registry%20at%20set%20intervals.

66. Microservices Patterns: Service Discovery Patterns

    Cloud Native Daily - Medium, accessed July 13, 2025, https://medium.com/cloud-native-daily/microservices-patterns-part-03-service-discovery-patterns-97d603b9a510

67. 마이크로서비스 패턴 - 서비스 디스커버리 - velog, accessed July 13, 2025, https://velog.io/@hoonki/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%ED%8C%A8%ED%84%B4-%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%94%94%EC%8A%A4%EC%BB%A4%EB%B2%84%EB%A6%AC
68. 서비스 디스커버리 (Service Discover)란? - 매일 조금씩 - 티스토리, accessed July 13, 2025, https://gimmesome.tistory.com/227
69. Pattern: Server-side service discovery - Microservices.io, accessed July 13, 2025, https://microservices.io/patterns/server-side-discovery.html

70. Understanding Service Discovery for Microservices Architecture

    Kong Inc., accessed July 13, 2025, https://konghq.com/blog/learning-center/service-discovery-in-a-microservices-architecture

71. SAGA 패턴을 통해 MSA에서의 데이터 일관성 보장하기 - hudi.blog, accessed July 13, 2025, https://hudi.blog/saga-pattern/
72. 마이크로서비스 패턴: 4.1.2 분산 트랜잭션의 문제점 - 1 - 더북(TheBook), accessed July 13, 2025, https://thebook.io/007035/0211/
73. [MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (8) 분산 트랜잭션 환경에서 트랜잭션 처리하기(feat. 2PC, Saga 패턴, Choreographed Saga), accessed July 13, 2025, https://ksh-coding.tistory.com/143
74. [마이크로서비스 패턴] 4. 트랜잭션 관리: 사가 - velog, accessed July 13, 2025, https://velog.io/@daehoon12/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%ED%8C%A8%ED%84%B4-4.-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EA%B4%80%EB%A6%AC-%EC%82%AC%EA%B0%80
75. [마이크로서비스] Saga Pattern 자세히 알아보기 (feat. orchestration, choreography), accessed July 13, 2025, https://devyonghee.github.io/theory/2022/09/24/orchestration-vs-choreography/
76. [MSA] 마이크로서비스 - 분산 트랜잭션 처리를 위한 Saga 패턴 - 피터의 개발이야기, accessed July 13, 2025, https://peterica.tistory.com/581
77. Saga 분산 트랜잭션 패턴, accessed July 13, 2025, https://learn.microsoft.com/ko-kr/azure/architecture/patterns/saga
78. 사가 패턴(saga pattern)과 분산 트랜잭션(distributed transaction) - Junhyunny’s Devlogs, accessed July 13, 2025, https://junhyunny.github.io/msa/design-pattern/distributed-transaction/
79. # 마이크로 서비스 데이터 설계 - source - 티스토리, accessed July 13, 2025, https://skysoo1111.tistory.com/133
80. [Saga 패턴] 마이크로서비스에서 Saga 패턴이란? - 해피주 블로그, accessed July 13, 2025, https://joobly.tistory.com/69
81. 마이크로서비스 패턴: 코레오그래피 사가의 장단점, accessed July 13, 2025, https://thebook.io/007035/0225/

82. (KR) Saga 의 두 가지 패턴 설명

    엔지니어링 로그, accessed July 13, 2025, https://ghkdqhrbals.github.io/portfolios/docs/msa/2022-09-04-micro-service-architecture1/

83. 마이크로서비스 패턴: 핵심패턴만 빠르게 이해하기, accessed July 13, 2025, https://happycloud-lee.tistory.com/154
84. [마이크로서비스 패턴] 6. 비즈니스 로직 개발: 이벤트 소싱 - velog, accessed July 13, 2025, https://velog.io/@daehoon12/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%ED%8C%A8%ED%84%B4-6.-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EB%A1%9C%EC%A7%81-%EA%B0%9C%EB%B0%9C-%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EC%86%8C%EC%8B%B1
85. 이벤트 소싱 패턴 - Azure Architecture Center - Learn Microsoft, accessed July 13, 2025, https://learn.microsoft.com/ko-kr/azure/architecture/patterns/event-sourcing
86. 이벤트 소싱 패턴 - AWS 권장 가이드, accessed July 13, 2025, https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/cloud-design-patterns/event-sourcing.html
87. 이벤트 소싱과 마이크로서비스 아키텍처 - 에이콘출판사, accessed July 13, 2025, http://www.acornpub.co.kr/book/microservices-eventsourcing

88. 마이크로 서비스에 대한 데이터 고려 사항 - Azure Architecture Center

    Microsoft Learn, accessed July 13, 2025, https://learn.microsoft.com/ko-kr/azure/architecture/microservices/design/data-considerations

89. 마이크로서비스 간의 데이터 일관성

    데릭 코마틴 - 읽을 거리 - 닷넷데브, accessed July 13, 2025, https://forum.dotnetdev.kr/t/topic/1924

90. 마이크로서비스 데이터 공유 전략: 동기 호출을 넘어, 점진적 일관성으로 - velog, accessed July 13, 2025, https://velog.io/@sangjinsu/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EA%B3%B5%EC%9C%A0-%EC%A0%84%EB%9E%B5-%EB%8F%99%EA%B8%B0-%ED%98%B8%EC%B6%9C%EC%9D%84-%EB%84%98%EC%96%B4-%EC%A0%90%EC%A7%84%EC%A0%81-%EC%9D%BC%EA%B4%80%EC%84%B1%EC%9C%BC%EB%A1%9C
91. 일관성: 분산 애플리케이션에서 데이터 일관성 유지 - FasterCapital, accessed July 13, 2025, https://fastercapital.com/ko/content/%EC%9D%BC%EA%B4%80%EC%84%B1–%EB%B6%84%EC%82%B0-%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98%EC%97%90%EC%84%9C-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%9D%BC%EA%B4%80%EC%84%B1-%EC%9C%A0%EC%A7%80.html
92. [마이크로서비스 패턴] 7. 마이크로서비스 쿼리 구현 - velog, accessed July 13, 2025, https://velog.io/@daehoon12/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%ED%8C%A8%ED%84%B4-7.-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EC%BF%BC%EB%A6%AC-%EA%B5%AC%ED%98%84
93. Docker & Kubernetes - velog, accessed July 13, 2025, https://velog.io/@zxzz45/Docker-Kubernetes
94. 컨테이너화, 도커의 장점, accessed July 13, 2025, https://brunch.co.kr/@@aWDV/5

95. 마이크로서비스란 무엇인가요?

    IBM, accessed July 13, 2025, https://www.ibm.com/kr-ko/topics/microservices

96. Kubernetes와 Docker 비교 - 컨테이너 기술 간의 차이점 - AWS, accessed July 13, 2025, https://aws.amazon.com/ko/compare/the-difference-between-kubernetes-and-docker/
97. Kubernetes와 Docker 비교 - Atlassian, accessed July 13, 2025, https://www.atlassian.com/ko/microservices/microservices-architecture/kubernetes-vs-docker
98. Kubernetes 예시, 애플리케이션 및 사용 사례 - IBM, accessed July 13, 2025, https://www.ibm.com/kr-ko/think/topics/kubernetes-use-cases
99. 서비스 메시란 무엇인가요? - AWS, accessed July 13, 2025, https://aws.amazon.com/ko/what-is/service-mesh/
100. Azure Kubernetes Service에 대한 Istio 기반 서비스 메시 추가 기능 - Learn Microsoft, accessed July 13, 2025, https://learn.microsoft.com/ko-kr/azure/aks/istio-about
101. [마이크로서비스 아키텍처 : 패턴과 핵심 기술] MSA를 위한 기술 - Service Mesh와 Istio, accessed July 13, 2025, https://yummy0102.tistory.com/372
102. Istio service mesh 소개 & 설치방법. 서비스메쉬(Service Mesh) : sidecar pattern사용, accessed July 13, 2025, https://medium.com/csk6124-walter/istio-service-mesh-%EC%86%8C%EA%B0%9C-%EC%84%A4%EC%B9%98%EB%B0%A9%EB%B2%95-1a541593c789
103. [Architecture] MSA : Istio 개념 잡기 - Azderica, accessed July 13, 2025, https://azderica.github.io/00-architecture-istio/
104. Istio란 무엇인가요? - Google Cloud, accessed July 13, 2025, https://cloud.google.com/learn/what-is-istio?hl=ko
105. 모놀리식 vs 마이크로서비스 아키텍처: 차이점 - AppMaster, accessed July 13, 2025, https://appmaster.io/ko/blog/monolrisig-dae-maikeuroseobiseu-akitegceo
106. [INFCON Tech Series #5] 모놀리식 vs 마이크로서비스 아키텍처, 우리 팀에 맞는 선택은?, accessed July 13, 2025, https://www.inflearn.com/pages/infcon-2023-tech-msa
107. [MSA 알아보기] 1. MSA란 무엇인가 - velog, accessed July 13, 2025, https://velog.io/@mrcocoball2/MSA-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-1.-MSA%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80