16.1 역사와 철학

서비스 지향 아키텍처는 1990년대 후반에 등장했다. 대기업이 중소 기업과의 인수 합병을 통해 빠른 속도로 성장했고 그런 성장을 뒷받침하기 위해 보다 세련된 IT가 필요했지만, 당시에는 지금처럼 컴퓨팅 리소스가 넉넉치 못했고 그나마 상용 제품들뿐이었다. 분산 컴퓨팅은 이제 막 궤도에 올라 수요가 늘기 시작했으나, 많은 기업들은 가변적인 확장성 등 다른 유용한 특성을 요구했다.

이 시대의 아키텍트들은 다양한 외부 여건 탓에 어쩔 수 없이 제약이 많은 분산 아키텍처를 구축했다. 오픈 소스 운영 체제를 프로덕션에서 사용해도 좋을 만큼 신뢰감을 얻기 전이었으므로 운영 체제는 많은 비용을 들여 시스템 단위로 라이센스를 구매했다. 상용 데이터베이스 역시 라이선스 체계가 복잡하기 짝이 없었고, 그러나 보니 애플리케이션 서버 벤더가 데이터베이스 벤더와 경쟁하는 구도가 형성됐다. 그 결과, 아키텍츠는 최대한 재사용하는 것을 목표로 삼게 되었고, 실제로 모든 형태의 재사용은 이 아키텍처의 중심 철학이 되었다.

16.2 토폴로지

모든 아키텍처에 위 그림과 동일한 레이어가 있는 건 아니지만, 아키텍처 내부에 서비스 택소노미(taxonomy, 분류체계)를 정립하여 레이어별로 책임을 지운다는 아이디어는 동일하다.

서비스 지향 아키텍처는 분산 아키텍처이다. 분산 아키텍처는 조직마다 다양하므로 정확한 경계선은 그림에 표현하지 않았다.

16.3 택소노미

이 아키텍처의 중심 철학은 엔터프라이즈 레벨의 재사용이다. 이 목표는 택소노미의 각 레이어를 통해 실현할 수 있다.

16.3.1 비지니스 서비스

이 아키텍처의 최상단에 위치한 비지니스 서비스는 진입점 역할을 한다.

이 서비스 정의는 코드는 전혀 없고, 입력, 출력, 스키마 정보만 갖고 있다. 서비스는 대부분 비지니스 유저가 정의하기 때문에 이름도 비지니스 서비스이다.

16.3.2 엔터프라이즈 서비스

엔터프라이즈 서비스는 세분화된 공유 구현체를 포함한다. 일반적으로 개발팀은 특정 비지니스 도메인(예: CreateCustomer, CalculateQuote)에 관한 원자적 행위를 구현하는 업무를 담당한다. 이런 서비스는 오케스트레이션 엔진을 통해 묶인, 단위가 큰 비지니스 서비스를 구성하는 요소들이다.

이 아키텍처의 재사용 목표 때문에 이렇게 책임을 분리한 것이다. 개발자가 정확한 세분도에 맞게 엔터프라이즈 서비스를 구축할 수 있다면 비지니스 워크플로의 해당 파트를 재작성할 필요가 없다. 비지니스는 재사용 가능한 엔터프라이즈 서비스 형태로 재사용 가능한 자산을 구축할 수 있을 거라고 믿었다.

16.3.3 애플리케이션 서비스

아키텍처의 모든 서비스에서 엔터프라이즈 서비스와 동일한 레벨의 세분화 또는 재사용이 필요한 것은 아니다. 애플리케이션 서비스는 한 번만 사용 가능한 단일 구현체 서비스이다. 예를 들어, 어떤 애플리케이션에 지리 공간 정보가 필요하지만 조직은 이 애플리케이션을 재사용 가능한 서비스로 구축하는 데 시간과 노력을 쏟길 원하지 않을 수 있다. 이럴 때 어느 한 애플리케이션팀이 소유한 애플리케이션 서비스로 문제를 해결할 수 있다.

16.3.4 인프라 서비스

인프라 서비스는 모니터링, 로깅, 인증/인가 등의 운영 관심사를 지원한다. 이런 서비스는 운영팀과 긴밀하게 협업하는 공유 인프라팀이 소유한 실질적인 구현체인 경우가 많다.

16.3.5 오케스트레이션 엔진

오케스트레이션 엔진은 이 분산 아키텍처의 요체이다. 이 엔진은 비지니스 서비스 구현체를 서로 엮어주며 트랜잭션 조정과 메시지 변환 등의 기능을 수행한다. 마이크로서비스 아키텍처처럼 서비스마다 데이터베이스가 있는 것은 아니며, 일반적으로 단일 관계형 데이터베이스를 사용한다. 따라서 트랜잭셔널 로직은 데이터베이스가 아닌 오케스트레이션 엔진에서 선언적으로 처리된다.

오케스트레이션 엔진은 비지니스와 엔터프라이즈 서비스의 관계, 이 둘을 매핑하는 방법, 트랜잭션 경계는 어디까지인지 등을 정의한다. 또한 이 엔진은 통합 엔진 역할도 겸하므로 아키텍트가 커스텀 코드를 패키지와 레거시 소프트웨어 시스템에 통합할 수 있다.

귀에 솔깃한 방법이었지만 실제로는 거의 재앙에 가까웠다. 트랜잭셔널 로직을 오케스트레이션 도구에 위임한다는 아이디어는 그럴 듯했으나, 트랜잭션을 정확히 어느 레벨까지 세분화해야 할지 알아내기가 더욱 더 어려워졌다.

16.3.6 메시지 흐름

모든 요청은 오케스트레이션 엔진을 흘러간다. 이 아키텍처는 모든 로직이 오케스트레이션 엔진에 있으므로 심지어 내부 호출을 할 때에도 메시지는 엔진을 경유한다.

16.4 재사용… 그리고 커플링

이 아키텍처의 주된 목표는 서비스 레벨의 재사용, 즉 시간이 지남에 따라 재사용 가능한 비지니스 행위를 점진적으로 구축하는 능력이다.

아키텍트는 보험 회사의 모든 부서에 Customer라는 개념이 포함되어 있다는 사실을 알아낸다. 서비스 지향 아키텍처 관점에서는 고객과 관련된 부분을 재사용 가능한 서비스로 빼내 원래 서비스가 표준 고객 서비스를 참조하도록 만드는 게 최선의 전략이다.

그러나 이 설계의 어두은 그림자가 서서히 드러나기 시작했다.

1. 재사용 위주로 시스템을 구축하다 보니 컴포넌트 간의 커플링이 심하게 발생한다.
2. 로직을 한 곳에 통합하는 것은 또 따른 부작용이 나타난다.
   하나의 Customer 서비스에 고객에 관한 모든 상세 정보를 담아야 한다. 자동차 보험에 가입하려면 운전 면허증이 필요한데 면허증은 사람이 소유한 것이지 차의 소유물이 아니다. 따라서 Customer 서비스는 가령 장애 보험팀에게는 전혀 관심사가 아닌 운전 면허증의 세부 정보까지 갖고 있어야 한다.

기술 분할에 집중한 아키텍처 구축이 얼마나 비현실적인지 깨닫는 과정에서 이 아키텍처의 가장 유해한 부분이 밝혀지기 시작했다. 분리와 재사용 철학의 관점에서는 일리가 있는 보였지만 실제로는 악몽이었다.

16.5 아키텍처 특성 등급

우리가 사용한 요즘의 아키텍처 평가 기준은 대부분 이 아키텍처가 인기를 끌었을 시절에는 덜 중요했다. 애자일 소프트웨어 프랙티스는 이제 막 시작된 상태였고 이 아키텍처를 사용할만한 규모의 조직까지 파고들지 못한 상태였다.

서비스 지향 아키텍처는 어쩌면 지금까지 시도된 아키텍처 중에서 가장 기술적으로 분할된 범용 아키텍처일 것이다! 실제로 이 구조의 단점에 대한 반발로 인해 마이크로서비스 같은 보다 현대적인 아키텍처가 탄생하게 되었다.