서비스 지향 아키텍처(SOA)란 무엇인가요?

SOA는 이전에 기존 기능을 재개발 또는 복제했거나 기존 기능과 상호 운용성을 연결하거나 제공하는 방법을 알아야 했던 애플리케이션 개발자의 작업을 제거합니다.

SOA의 각 서비스는 완전하고 개별적인 비즈니스 기능(예: 고객 신용 조회, 월별 대출금 지불 계산, 모기지 애플리케이션 처리)을 실행하는 데 필요한 코드와 데이터를 구현합니다. 서비스 인터페이스는 느슨한 결합을 제공합니다. 즉, 서비스가 어떻게 구현되는지에 대한 지식이 거의 없거나 전혀 없이 호출할 수 있으므로 애플리케이션 간의 종속성이 줄어듭니다.

이 인터페이스는 서비스 공급자와 서비스 소비자 간의 서비스 계약입니다. 서비스 인터페이스의 기반이 되는 애플리케이션은 Java, Microsoft .Net, Cobol 또는 기타 프로그래밍 언어로 작성되었을 수 있으며, 공급업체(예: SAP)가 패키지 소프트웨어 애플리케이션이나 SaaS 애플리케이션(예: Salesforce CRM) 또는 오픈 소스 애플리케이션 형태로 제공할 수 있습니다.

서비스 인터페이스는 확장 가능한 마크업 언어(XML)를 기반으로 하는 표준 태그 구조인 웹 서비스 정의 언어(WSDL)를 사용하여 정의되는 경우가 많습니다.

이 서비스는 SOAP(Simple Object Access Protocol)/HTTP 또는 RESTful HTTP(JSON/HTTP)와 같은 표준 네트워크 프로토콜을 사용하여 데이터 읽기 또는 변경 요청을 전송하여 노출됩니다. 서비스 거버넌스는 개발 수명 주기를 제어하며, 서비스가 적절한 단계에서 레지스트리에 게시되므로 개발자가 신속하게 서비스를 찾아 재사용하여 새로운 애플리케이션 또는 비즈니스 프로세스를 조립할 수 있습니다.

이러한 서비스는 처음부터 빌드할 수 있지만 레거시 레코드 시스템의 기능을 서비스 인터페이스로 노출하여 생성되는 경우가 많습니다.

이러한 점에서 SOA는 지난 수십 년간 애플리케이션 개발 및 통합의 진화 과정에서 중요한 단계를 의미합니다. 1990년대 후반 SOA가 등장하기 전에는 다른 시스템에 있는 데이터나 기능에 애플리케이션을 연결하려면 복잡한 지점 간 통합이 필요했으며, 이러한 통합은 개발자가 각각의 새로운 개발 프로젝트마다 일부 또는 전체를 다시 생성해야 했습니다. SOA 서비스를 통해 이러한 기능을 노출하여, 개발자는 기존 기능을 단순히 재사용하고 SOA ESB 아키텍처(아래 참조)를 통해 연결할 수 있게 되었습니다.

SOA와 최신 마이크로서비스 아키텍처는 '서비스'와 '아키텍처'라는 공통 단어를 공유하기 하지만, 이 문서의 뒷부분에서 설명하는 것처럼 느슨하게 관련되어 있을 뿐이며 실제로 다른 범위에서 작동합니다.

ESB(엔터프라이즈 서비스 버스)는 중앙 집중식 소프트웨어 구성 요소가 애플리케이션 간 통합을 수행하는 아키텍처 패턴입니다. 데이터 모델의 변환을 수행하고, 연결을 처리하고, 메시지 라우팅을 수행하고, 통신 프로토콜을 변환하고, 잠재적으로 여러 요청의 구성을 관리합니다.

ESB는 이러한 통합 및 변환을 새로운 애플리케이션에서 재사용할 수 있는 서비스 인터페이스로 제공할 수 있습니다. ESB 패턴은 일반적으로 최상의 생산성을 보장하도록 특별히 설계된 통합 런타임 및 툴 세트를 사용하여 구현됩니다.

ESB 없이 SOA를 구현할 수도 있지만, 이는 단순히 여러 서비스를 보유하는 것과 다르지 않습니다. 각 애플리케이션 소유자는 필요한 서비스에 직접 연결하고, 각 서비스 인터페이스를 충족하기 위해 필요한 데이터 변환을 수행해야 합니다.

이 작업은 (인터페이스가 재사용 가능하더라도) 매우 많은 노력이 필요하며, 각 연결이 지점 간 연결이므로 향후 유지보수에도 상당한 어려움이 발생합니다. 실제로 ESB는 시간이 지나면서 사실상 SOA를 구현하는 데 필수적인 요소로 간주되었으며, 이로 인해 두 용어가 때때로 동의어처럼 사용되며 혼란을 야기하기도 했습니다.

기존 아키텍처와 비교했을 때, SOA는 엔터프라이즈에 상당한 이점을 제공했습니다.

• 비즈니스 민첩성 향상 및 시장 출시 시간 단축: 재사용성이 핵심입니다. 매번 새로운 개발 프로젝트마다 다시 작성하고 재통합하는 대신, 재사용 가능한 서비스(즉, 빌딩 블록)로 애플리케이션을 조립하는 효율성 덕분에 개발자는 새로운 비즈니스 기회에 대응하여 애플리케이션을 훨씬 더 빠르게 구축할 수 있습니다.
  서비스 지향 아키텍처 접근 방식은 애플리케이션 통합, 데이터 통합 및 비즈니스 프로세스나 워크플로의 서비스 오케스트레이션 방식 자동화 시나리오를 지원합니다. 이를 통해 개발자는 통합에 소요되는 시간을 획기적으로 줄이고 애플리케이션 개선 및 제공에 집중할 수 있는 시간을 더 많이 확보하여 소프트웨어 설계와 개발 속도를 높일 수 있습니다.
• 신규 시장에서 레거시 기능을 활용할 수 있는 능력: 잘 설계된 SOA를 통해 개발자는 한 컴퓨팅 플랫폼이나 환경에 ‘잠겨 있던’ 기능을 새로운 환경과 시장으로 손쉽게 가져와 확장할 수 있습니다. 예를 들어, 많은 기업은 SOA를 사용해 메인프레임 기반 금융 시스템의 기능을 새로운 웹 애플리케이션에 노출했습니다. 이를 통해 고객은 이전에는 회사 직원 또는 비즈니스 파트너와의 직접적인 상호 작용을 통해서만 접근 가능했던 프로세스와 정보를 스스로 이용할 수 있게 되었습니다.
• 비즈니스와 IT 간의 협업 개선: SOA에서는 서비스를 ‘보험 견적 생성’ 또는 ‘자본 장비 ROI 계산’과 같은 비즈니스 용어로 정의할 수 있습니다. 이를 통해, 비즈니스 분석가는 서비스를 사용하여 정의된 비즈니스 프로세스의 범위 또는 프로세스 변경이 비즈니스에 미치는 영향과 같은 중요한 인사이트에 대해 개발자와 더 효과적으로 협력하여 더 나은 결과를 얻을 수 있습니다.

2010년경에는 사실상 모든 산업의 선도 기업에서 SOA 구현이 본격적으로 진행되고 있었습니다. 예를 들면 다음과 같습니다.

Delaware Electric은 SOA를 도입하여 이전에 서로 통신하지 않았던 시스템들을 통합했으며, 그 결과 개발 효율성이 향상되어 주에서 전기 요금 인상을 5년간 금지한 상황에서도 조직이 재정 건전성을 유지하는 데 도움이 되었습니다.

Cisco는 주문 프로세스를 서비스로 노출해 Cisco의 여러 부서, 인수한 회사, 비즈니스 파트너가 해당 서비스를 자사 웹사이트에 통합할 수 있도록 하여 모든 제품과 채널에서 일관된 제품 주문 경험을 보장하기 위해 SOA를 채택했습니다.

필라델피아의 Independence Blue Cross(IBC)는 SOA를 구현하여 IBC 고객 서비스 직원, 의사 진료실, IBC 웹사이트 사용자 등 환자 데이터를 다루는 다양한 구성원이 동일한 데이터 소스(‘신뢰할 수 있는 단일 소스’)를 기반으로 작업하도록 지원했습니다.

전문가들은 SOA와 마이크로서비스를 비교하고 그 상호 관계에 존재하는 미묘한 차이를 정의하는 데 수천 페이지에 달하는 인쇄 및 디지털 자료를 작성해 왔습니다. 이 글의 목적상, 두 가지의 주요 차이점은 구성 요소의 결합 및 사용 범위입니다.

SOA는 통합 아키텍처 스타일이자 전사적 개념입니다. SOA를 사용하면 기존 애플리케이션을 느슨하게 결합된 인터페이스를 통해 노출할 수 있습니다. 각 인터페이스는 비즈니스 기능에 해당하며, 확장된 엔터프라이즈의 한 부분에 있는 애플리케이션이 다른 애플리케이션의 기능을 재사용할 수 있도록 지원합니다.

마이크로서비스 아키텍처는 애플리케이션 아키텍처 스타일이자 애플리케이션 범위의 개념입니다. 이를 통해 단일 애플리케이션의 내부를 독립적으로 변경, 확장 및 관리할 수 있는 작은 조각으로 나눌 수 있습니다. 이 아키텍처는 애플리케이션 간의 통신 방식을 정의하지는 않으며, 해당 부분은 SOA가 제공하는 서비스 인터페이스의 엔터프라이즈 범위에서 다루는 영역입니다.

마이크로서비스는 가상화, 클라우드 컴퓨팅, 애자일 개발 관행 및 DevOps와 함께 등장하여 이들의 부상으로 힘을 얻었습니다. 이러한 맥락에서 마이크로서비스의 대부분의 이점은 구성 요소의 분리에서 비롯되며, 이를 통해 다음을 단순화하고 개선합니다.

• 개발자의 민첩성과 생산성: 마이크로서비스를 사용하면 개발자는 애플리케이션의 나머지 부분에 영향을 주지 않고 애플리케이션의 한 부분에만 새로운 기술을 통합할 수 있습니다. 모든 구성 요소는 다른 구성 요소와 독립적으로 수정, 테스트 및 배포할 수 있으므로 반복 주기가 빨라집니다.
• 확장성: 마이크로서비스는 클라우드 확장성을 최대한 활용할 수 있습니다. 즉, 워크로드 요구에 가장 빠르게 대응하고 컴퓨팅 리소스를 가장 효율적으로 사용하기 위해 모든 구성 요소를 다른 구성 요소와 독립적으로 확장할 수 있습니다.
• 탄력성: 다시 말해, 디커플링 덕분에 하나의 마이크로서비스가 실패하더라도 다른 서비스에는 영향을 미치지 않습니다. 또한 각 마이크로서비스는 다른 구성 요소나 전체 애플리케이션을 가장 높은 공통 가용성 요구 사항에 묶어두지 않고도 자체 가용성 요구 사항에 맞춰 성능을 발휘할 수 있습니다.

SOA와 마이크로서비스의 차이점에 대해 자세히 알아보려면 SOA와 마이크로서비스: 차이점이 무엇인가요?를 참조하세요.

마이크로서비스 아키텍처가 애플리케이션 설계에 민첩성, 확장성 및 복원력 향상을 가져올 수 있는 것과 같은 방식으로, 이러한 동일한 기법을 통합에도 적용할 수 있습니다.

이는 시간이 지나면서 고도로 중앙 집중화된 ESB 패턴과 관련 중앙 집중식 통합 전문가 팀이 병목 현상이 될 수 있기 때문에 중요합니다. 마이크로서비스 원칙을 차용하면 ESB를 더 세분화된, 분산형 통합으로 분할할 수 있습니다. 이게 바로 애자일 통합의 핵심 전제 중 하나입니다.