Service-Oriented Architecture (SOA) & ESB

1. Overview

서비스 지향 아키텍처(SOA)와 엔터프라이즈 서비스 버스(ESB)는 2000년대 대형 엔터프라이즈(은행, 통신사 등)를 지배했던, 전사적 재사용성과 중앙 통제에 극도로 집중한 분산 시스템의 역사적 이정표를 해부합니다.

학습자는 분산된 시스템 간의 통신 규격을 통일하기 위해 등장한 묵직한 XML 기반의 SOAP 프로토콜과 **WSDL(웹 서비스 기술 언어)**의 철학을 뜯어봅니다. 나아가 수백 개의 서비스가 N 통신하며 만들어내는 스파게티 네트워크를 하나로 묶어(Hub and Spoke) 라우팅, 데이터 변환, 보안을 전담하는 중앙 집중형 미들웨어 **ESB(Enterprise Service Bus)**의 구조를 해부합니다. 마지막으로, 중앙 통제의 정점이었던 SOA가 왜 실패(또는 진화)하여 '스마트 엔드포인트와 단순한 파이프(Smart endpoints, dumb pipes)'를 지향하는 현대의 마이크로서비스(MSA)로 대체되었는지, 그 결정적 트레이드오프를 장악합니다.

2. Scope & Boundaries

In-Scope

• SOA (Service-Oriented Architecture): 서비스 재사용성(Reusability), 전사적 통합, 중앙 집중식 거버넌스.
• Web Services Standards (WS-*): SOAP (Simple Object Access Protocol), WSDL, XML 스키마.
• ESB (Enterprise Service Bus): 메시지 라우팅, 프로토콜 변환(Protocol Translation), 오케스트레이션(Orchestration).
• SOA vs MSA: 전사적 재사용성(SOA)과 조직적 독립 배포(MSA)의 설계 철학 비교.

Out-of-Scope

• 경량형 RESTful API 설계: JSON 기반 API 및 MSA 통신 규약 $\rightarrow$ 08-03 API Architecture & RPC 영역으로 위임.
• Kafka 등 현대적 Event Bus: ESB와 결이 다른 무상태(Dumb Pipe) 메시지 큐 $\rightarrow$ 07-04 Event-Driven Systems 영역.

Boundaries

• 중앙 통제(ESB) vs 분산 독립성(API Gateway): SOA의 ESB는 서비스 간 통신 시 단순히 길만 열어주는 게 아니라, 내부에서 XML을 파싱하고, 비즈니스 룰을 태워 라우팅하며, 데이터 포맷을 변환(스마트 파이프)합니다. 이로 인해 모든 서비스의 변경 사항이 ESB 팀의 승인과 수정을 거쳐야만 배포될 수 있는 최악의 **중앙 병목(Single Point of Bottleneck)**이 발생했습니다. 반면 MSA는 파이프라인(네트워크)은 단순히 데이터를 나르기만 하고, 비즈니스 로직은 철저히 각 마이크로서비스(스마트 엔드포인트) 내부로 밀어 넣는 방식으로 진화했습니다.

3. Counterexample

• ESB 병목 지옥 (The ESB Bottleneck): A팀(결제)이 B팀(배송)의 API를 호출하기 위해 데이터 규격을 JSON에서 XML로 바꿉니다. 그런데 A팀과 B팀은 코드를 다 짰는데, 중앙 ESB 미들웨어를 관리하는 인프라팀이 바빠서 라우팅 룰을 업데이트해 주지 않습니다. 두 달 동안 배포를 못 하고 기다립니다. "모든 통신을 중앙에서 관리하겠다"는 훌륭한 이상이 현실에서는 최악의 애자일(Agile) 파괴자로 돌변한 안티 패턴입니다.
• 재사용성의 저주 (The Curse of Reusability): SOA는 '전사적 코드 재사용'을 1원칙으로 삼습니다. 은행의 10개 부서가 공통 '고객 정보 서비스'를 공유합니다. 특정 부서가 기능을 하나 추가해달라고 요청하면, 나머지 9개 부서에 버그가 터지지 않을지 검증하느라 6개월이 걸립니다. 차라리 코드를 중복(Duplication)해서라도 각 팀이 따로 가져가는 것(MSA)이 변화 속도 측면에서 압도적으로 유리함을 증명하는 사례입니다.

4. Prerequisites

• 네트워크 통신 기초 (Basic): XML과 JSON의 차이, HTTP 통신. (08-01 Network Fundamentals)
• 모놀리식 아키텍처 (Basic): 거대 시스템의 코드 결합도 한계. (07-01-01 Monolithic Evolution)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 전사적 통합의 꿈, SOA (The Rise of SOA)

• Why to Learn: 대기업의 레거시 시스템을 통합하려는 시도가 마이크로서비스 이전에 이미 2000년대에 존재했음을 이해하고, 당시의 '재사용성(Reusability)' 철학을 인지하기 위함입니다.
• What to Learn:
  • Concepts: Service-Oriented Architecture, 비즈니스 서비스 캡슐화, 전사적 거버넌스(Enterprise Governance), 시스템 통합(System Integration).
  • Skills: 사일로(Silo)화된 레거시 시스템을 논리적 서비스 단위로 묶어내는 거시적 뷰 설계.
• How to Learn:
  • 1단계: 사일로의 붕괴: 인사부 시스템(C언어)과 재무부 시스템(Java)이 아예 소통이 안 됩니다. 이를 해결하기 위해 각 시스템의 기능을 '급여 조회 서비스', '근태 기록 서비스'라는 표준 인터페이스로 포장하여, 전사적으로 누구나 호출할 수 있게 만드는 SOA의 이상을 해부합니다.
  • 2단계: 공유의 함정: "코드를 한 번만 짜서 전사가 공유하자"는 철학이 어떻게 조직 간의 의존성 결합(Coupling)을 낳고 배포를 지연시키는지 뜯어봅니다.
• Implement: 논리적 통합 아키텍처 다이어그램 스크립팅. 서로 다른 언어로 짜인 시스템 3개가 각각의 직접적인 쿼리(DB 직접 접근)를 포기하고, Global_Service_Registry를 통해 서로를 찾고 표준 API 포맷으로만 통신하도록 추상화하는 모형 렌더링.

Recommended

Core Topic 02: 무겁고 엄격한 계약, SOAP과 WS-* (Web Services)

• Why to Learn: 현재의 가벼운 REST/JSON 기반 API가 탄생하기 전, 보안과 트랜잭션을 강제하기 위해 은행과 공공기관이 의존했던 SOAP 프로토콜의 엄격성을 이해하기 위함입니다.
• What to Learn:
  • Concepts: SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), UDDI, WS-Security.
  • Skills: XML 페이로드(Payload) 구조 분석 및 엄격한 스키마(Schema) 검증.
• How to Learn:
  • 1단계: WSDL (계약서): 함수 이름은 무엇이고 인자는 Int형인지 String형인지 묘사하는 거대한 XML 문서(WSDL). 서버 A가 이 문서를 주면 서버 B는 클라이언트 코드를 자동 생성합니다. 강타이핑(Strong Typing)을 네트워크 위로 끌어올린 원리를 해부합니다.
  • 2단계: SOAP 봉투(Envelope): 메시지 하나를 보내는데 헤더, 바디, 에러 처리(Fault) 등 태그가 수십 개 붙습니다. JSON보다 페이로드 크기가 5배는 커지는 네트워크 낭비와 파싱 오버헤드를 뜯어봅니다.
• Implement: XML vs JSON 페이로드 크기 비교 데모. 1) {"name": "Kim", "age": 30} 2) <soapenv:Envelope>...<user><name>Kim</name><age>30</age></user>...</soapenv:Envelope> 두 문자열의 바이트 크기를 재고, 네트워크 대역폭(Bandwidth) 낭비율을 수치로 출력.

Practical

Core Topic 03: 똑똑한 파이프의 역습, ESB (Enterprise Service Bus)

• Why to Learn: $N \times M$ 스파게티 통신망을 해결하기 위한 가장 강력한 무기였던 중앙 통제 버스가 어떻게 최악의 병목 지점으로 전락했는지 물리적 한계를 장악하기 위함입니다.
• What to Learn:
  • Concepts: ESB (Enterprise Service Bus), Point-to-Point vs Hub-and-Spoke, Message Transformation (XML $\rightarrow$ JSON), Content-based Routing.
  • Skills: 중앙 버스 미들웨어의 라우팅 병목 지점 분석.
• How to Learn:
  • 1단계: 스파게티 끊기: 서비스가 100개면 Point-to-Point 연결선은 4,950개가 됩니다. 이를 멈추고 모든 서비스는 중앙 ESB 하나와만 연결(Hub-and-Spoke)하게 만들어 선을 100개로 줄이는 위대한 물리적 단순화를 해부합니다.
  • 2단계: 스마트 파이프(Smart Pipe)의 독: ESB 내부에서 'A팀은 XML을 주고 B팀은 JSON을 원하니 여기서 변환해주자', '사용자 등급이 VIP면 C서버로 보내주자' 같은 비즈니스 로직(Transformation & Routing)을 수행합니다. ESB 코드가 기하급수적으로 복잡해져 블랙박스가 되어버리는 과정을 뜯어봅니다.
• Implement: 파이썬 가상 ESB 라우터 봇. Service_A가 "User123"을 평문으로 ESB에 던짐. ESB 클래스 내부에 if VIP: route to B 로직과 XML_Wrap() 변환 로직이 잔뜩 들어있음. 로직이 추가될수록 ESB 클래스의 코드 라인 수가 폭발하여 유지보수가 불가능해지는(Single Point of Failure) 양상 데모.

Advanced

Core Topic 04: 진화의 갈림길, SOA vs MSA (SOA vs Microservices)

• Why to Learn: 현대 아키텍트가 단순히 "MSA가 최신 유행이니까"가 아니라, 두 아키텍처의 설계 철학과 트레이드오프를 이해하여 적재적소에 시스템을 채택하기 위함입니다.
• What to Learn:
  • Concepts: Smart Endpoints & Dumb Pipes (MSA), Smart Pipes & Dumb Endpoints (SOA), Bounded Context vs Enterprise Model, Orchestration vs Choreography.
  • Skills: 비즈니스 요구사항에 따른 SOA(중앙 통제)와 MSA(독립 배포) 도입 전략 평가.
• How to Learn:
  • 1단계: 데이터 공유 vs 데이터 격리: SOA는 한 회사 내의 데이터 중복을 혐오하여 하나의 통합 DB나 통일된 데이터 모델을 추구합니다. MSA는 데이터가 중복되더라도 각 서비스가 독자적인 DB를 가지는 것을 강제(격리)하여 결합도를 끊어내는 철학 차이를 해부합니다.
  • 2단계: Dumb Pipes의 승리: MSA는 네트워크(Pipe)는 철저히 데이터를 나르기만 하고, 변환과 비즈니스 로직(Smart)은 각 서비스 내부(Endpoint)에서 처리하게 만듭니다. 이로 인해 중앙 ESB 팀의 승인 없이 각 팀이 하루에 100번씩 배포할 수 있게 된 조직적 혁명을 뜯어봅니다.
• Implement: 아키텍처 트레이드오프 결정 매트릭스 구현. 입력: 팀 규모(10명 vs 500명), 도메인 복잡도(낮음 vs 높음), 배포 주기(월 1회 vs 일 10회). 조건문에 따라 Monolith, SOA(재사용/중앙통제), MSA(독립/분산) 중 가장 적합한 아키텍처를 추천하고, 선택으로 인해 감수해야 할 대가(Cost)를 출력하는 룰 엔진 스크립트.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Software Architecture (SOA)
• [P5] SFIA - Enterprise IT Architecture (ARCH) - Integration Architecture

Secondary

• [Enterprise Integration Patterns] Gregor Hohpe - Messaging, Routing, and Transformation
• [Microservices vs. Service-Oriented Architecture] Mark Richards - Architecture Comparison

Industry

• [IBM Architecture Center] - SOA and Web Services
• [Martin Fowler's Bliki] - Microservices and the Smart Endpoints, Dumb Pipes principle

9. Final Checklist

Primary

• 다수의 서비스가 그물망처럼 통신하는 Point-to-Point(N) 방식의 한계와, 이를 ESB(Hub-and-Spoke)가 어떻게 물리적으로 단순화시키는지 설명할 수 있는가?
• SOAP 기반의 통신이 JSON 기반의 REST API에 비해 페이로드 크기가 비대해져 유발하는 네트워크 대역폭(Bandwidth) 낭비를 증명할 수 있는가?

Secondary

• WSDL이 제공하는 '강타이핑(Strong Typing) 계약' 메커니즘을 묘사하고, 이것이 클라이언트 스텁(Stub) 코드를 자동 생성할 수 있게 해주는 원리를 해부할 수 있는가?
• ESB(Enterprise Service Bus)가 프로토콜 변환(XML $\leftrightarrow$ JSON)과 라우팅 등 '스마트 파이프(Smart Pipe)' 역할을 수행할 때 발생하는 유지보수 병목(Bottleneck) 현상을 논증할 수 있는가?

Industry

• "전사적 자원의 완벽한 재사용(Reusability)"을 목표로 한 SOA 철학이, 왜 애자일(Agile)한 "빠르고 독립적인 배포" 앞에서는 안티 패턴이 될 수밖에 없는지 아키텍처 관점으로 설계할 수 있는가?
• 현대의 마이크로서비스(MSA)가 ESB를 버리고 API Gateway와 Dumb Pipes(가벼운 메시지 큐)를 채택함으로써 획득한 조직 공학적(콘웨이의 법칙) 이점을 평가할 수 있는가?