212. 서비스 지향 아키텍처 (SOA, Service Oriented Architecture) - ESB 기반 웹 서비스 컴포넌트 재사용 버스 구조 SOAP UDDI WSDL 마이크로서비스의 조상

핵심 인사이트: 2000년대 초반, 대기업 전산실의 악몽. 인사팀 시스템(C언어)과 회계팀 시스템(자바)을 엮으려니 언어가 달라서 통신이 1도 안 됐다. 할 수 없이 두 시스템 사이에 1:1로 맞춤형 번역기(스파게티 선)를 짰다. 시스템이 10개면 45개의 스파게티 선이 꼬여서 서버가 폭발했다(EAI P2P의 한계). "야! 미친 스파게티 선 다 뽑아버려! 모든 프로그램을 작고 독립적인 기능(예: '직원 정보 조회')으로 쪼개서, 그걸 인터넷 웹 링크(URL)를 찌르면 결과가 툭 떨어지는 '서비스(Service)'라는 블록 장난감으로 싹 다 포장해! 그리고 회사 복도 한가운데에 거대한 통역 버스(ESB)를 1대 깔아서, 누구나 저 버스에 올라타기만 하면 언어 벤더 상관없이 블록(서비스)들을 레고처럼 조립해서 새 프로그램을 뚝딱 만들 수 있게 해!!" 마이크로서비스(MSA)를 낳은 전설적인 할아버지 뼈대, SOA다.

Ⅰ. 사일로(Silo) 시스템의 끔찍한 파편화

  • 상황: 영업팀은 윈도우(C#) 서버를 쓰고, 물류팀은 리눅스(Java) 서버를 씁니다(Silo 현상).
  • 서로 "재고 좀 알려줘!"라고 요청하려는데, 코드가 다르니 말(Protocol)이 안 통합니다. 개발자들은 매번 두 시스템을 연결하는 일회용 땜질 코드를 수천 줄씩 새로 짰습니다(Point-to-Point 결합도 폭발). 코드 한 줄 바꾸면 회사가 멈춥니다.

Ⅱ. SOA (Service Oriented Architecture)의 개념 🌟

  • 개념: 소프트웨어 시스템을 무식한 통짜 덩어리로 짜지 않고, 독립적으로 수행할 수 있는 업무 단위의 '서비스(Service)'라는 작은 기능 조각들로 쪼갠 뒤, 표준화된 인터페이스(웹 서비스)를 통해 이 조각들을 레고 블록처럼 유연하게 조립하고 재사용(Reuse)하여 거대한 시스템을 구축하는 아키텍처 설계 철학입니다.

Ⅲ. SOA를 구동하는 3대 핵심 마법 🌟 핵심 기출 🌟

독일어(Java)와 일본어(C#)가 어떻게 대화할까요? 통일된 규격이 필요합니다. (웹 서비스 3총사)

1. SOAP (단일 통신 규격) - "만국 공통어 XML"

  • 언어가 달라도 텍스트(글자)는 다 읽을 수 있습니다.
  • 모든 서비스(레고 블록)는 데이터를 쏠 때 무조건 낡고 뚱뚱한 XML(태그로 된 텍스트) 껍데기에 담아서 쏘기로 전 세계가 합의를 봤습니다. 이게 SOAP(Simple Object Access Protocol)입니다. 언어가 달라도 XML만 뜯어보면 되니 기적처럼 말이 통합니다.

2. WSDL (서비스 설명서)

  • 10만 개의 서비스가 생겼습니다. 이 서비스가 무슨 값을 넣으면 무슨 값을 뱉어주는지 어떻게 알까요?
  • WSDL (Web Services Description Language): "내 서비스는 [사번]을 입력하면 [월급]을 토해내는 놈입니다"라고 XML로 적어놓은 **제품 사용 설명서(메뉴얼)**입니다. 이 설명서만 보면 초보 개발자도 남의 서비스를 쉽게 호출할 수 있습니다.

3. UDDI (서비스 전화번호부)

  • 그 10만 개의 WSDL 설명서들을 허공에 뿌릴 순 없으니, 중앙에 거대한 전화번호부(Registry)를 만듭니다. UDDI에 검색하면 전 세계/전 사내의 모든 서비스(레고 블록) 목록과 주소를 1초 만에 찾을 수 있습니다.

Ⅳ. ESB (Enterprise Service Bus) - SOA의 척추 🌟

  • 수백 개의 서비스가 거미줄처럼 얽히는 걸 막기 위해, 회사 정중앙에 **ESB(기업 서비스 버스)**라는 굵고 거대한 통신 미들웨어 파이프를 딱 1개 깝니다.
  • 모든 서비스는 남의 서버로 직접 가지 않고, 이 ESB 버스에 데이터를 던집니다. ESB는 중간에서 XML을 번역해 주고, 목적지로 배달해 주는 중앙 우체국 역할을 완벽하게 해내어 시스템 간의 결합도를 바닥으로 부숴버립니다.

Ⅴ. SOA의 몰락과 MSA(213번)로의 진화

  • 이 아름다운 철학(SOA)은 치명적인 단점 때문에 몰락했습니다.
  • XML(SOAP) 포장지가 미치도록 무거워서 성능이 떡락했고, 중앙 통제 버스(ESB) 1대가 뻗으면 회사 전체가 마비(SPOF)되었으며, 너무 거창한 사상이라 개발자들이 지쳐버렸습니다.
  • 결국 ESB와 뚱뚱한 XML을 다 쓰레기통에 찢어버리고, **"그냥 가벼운 JSON이랑 쌩 인터넷(REST API)으로 쪼개진 서비스끼리 다이렉트로 통신하자!"**며 등장한 가벼운 닌자 버전이 바로 현대 클라우드를 제패한 **MSA(마이크로서비스 아키텍처)**입니다.

📢 섹션 요약 비유: 기존의 기업용 시스템은 각 부서가 언어가 전혀 다른 **'폐쇄적인 외딴 섬(Silo)'**들이어서, 서로 소통하려면 바다에 배를 띄워 매번 힘겹게 맞춤형 통역사를 대동해야 했습니다(포인트-투-포인트). 이를 부수기 위해 도입된 **SOA(서비스 지향 아키텍처)**는, 모든 부서의 기능을 '어디서나 규격이 똑같은 콘센트 플러그(웹 서비스, SOAP)' 형태로 깎아내어 표준화시킨 것입니다. 그리고 회사 복도 한가운데에 거대한 **'멀티탭 공용 버스(ESB)'**를 하나 쫙 깔아버렸습니다. 영업부든 회계부든 상관없이 자기가 쓰던 언어를 버리고, 이 표준 콘센트 플러그만 멀티탭(ESB)에 딱 꽂으면 회사 전체의 모든 기능(서비스)을 레고 조립하듯 마음대로 가져다 붙일 수 있게 된 융합의 혁명입니다. 하지만 이 거대 멀티탭이 너무 무겁고(XML 병목) 멀티탭 하나 고장 나면 전 회사가 뻗는 단점 때문에, 결국 훗날 더 가볍고 날렵한 마이크로서비스(MSA)라는 위대한 손자에게 왕위를 물려주고 역사 속으로 사라진 비운의 개척자입니다.