SOA 서비스 지향 아키텍처(Service Oriented Architecture)

마이크로 서비스의 근간이 되는 SOA아키텍처를 통해서 아키텍처의 발전과 실패원인을 분석하여 인사이트를 얻자!
세부 구현기술은 변했지만 MSA등 분산 시스템의 아키텍처 사상은 그래도 반영 됨.
SOA의 본질적인 개념을 파악하여 대용량 시스템 구현에 활용하자!

1. SOA(Service Oriented Architecture)란?

 서비스 단위로 기능을 쪼개서 재사용하자!
 2000년대 초반 대기업·금융권에서 유행했던 아키텍처 입니다.

• Business Service
  • 주문, 결제, 배송 같은 업무 단위 서비스
• Task Centric Service
  • 특정 업무 단계에 집중한 서비스
• Entity Centric Service
  • 고객, 상품 같은 데이터 중심 서비스
• Intermediary Service (중간 서비스)
  • 아키텍처에 유연성을 더해주는 서비스
    기존 서비스 변경 없이 비즈니스 로직을 변경할 수 있음
  • 라우팅, 메시지 변환, 기능 추가 (ESB 안에서 주로 함)

출처 : 조대협의 대용량 아키텍처 설계 로드맵

출처 : 조대협의 대용량 아키텍처 설계 로드맵

출처 : 조대협의 대용량 아키텍처 설계 로드맵

• Process Centric Service
  • 기존 비즈니스 서비스를 조합(Orchestraion)하여 비즈니스 시나리오를 구현

즉, 부품(서비스)들을 잘게 쪼개서, 필요할 때마다 조립해서 큰 서비스를 만들자 → 이게 SOA의 철학!

 

2. SOA의 실패 원인

개념은 멋졌지만 현실에서는 문제가 많았음!

1. Enterprise Service Bus(ESB) 의존
   • 서비스들이 모두 중앙 버스(ESB)를 거쳐야 해서, 버스가 고장나면 전체가 마비(SPOF)
   • XML/SOAP 같은 무거운 포맷을 써서 파싱 비용↑, 성능↓
2. Intermediary Service 남용
   • 라우팅, 변환 같은 로직을 다 ESB에 몰아넣음 → 중앙이 비대해짐
   • 결국 서비스 간 연결이 많아져서 유연성↓
3. 중앙집중형 거버넌스
   • 모든 팀의 서비스를 중앙에서 통제 → 속도 느림, 민첩성 사라짐
   • 개발자들이 비즈니스에 가까워지기보다, 규정·절차만 지켜야 했음

결론:  좋은 구조이고 개념은 좋았지만, 중앙 집중·무거운 기술·관리 복잡성 때문에 실패!

 

3. 어떻게 MSA(Microservices Architecture)로 발전했나?

MSA는 SOA에서 좋은 점은 가져오고, 실패한 점은 버렸습니다.

• ESB → API Gateway & Service Mesh
  • 중앙 버스를 없애고, 경량화된 API Gateway(REST/JSON)로 외부 트래픽 관리
  • 서비스 간 통신은 Service Mesh로 분산 관리 (중앙 SPOF 제거)
• SOAP/XML → REST/JSON → gRPC/Avro/Protobuf
  • 무거운 포맷 대신 가볍고 빠른 포맷으로 전환
• 중앙집중 거버넌스 → 분산 거버넌스(DevOps)
  • 각 팀이 자신의 서비스에 책임
  • 조직도 서비스 단위로 분리 → 민첩성 확보
• Orchestration → Event Driven Architecture
  • 서비스 간 동기 연결(Orchestration) 대신, 이벤트 기반 비동기(Even-driven) 모델로 확장성↑
  • Netflix, 우버 등 대규모 시스템이 채택