저자 서문

이 책의 작업을 시작했을 때만 해도 나는 SOA와 REST가 무엇인지 완전히 확신하지 못했다. 이런 식으로 느끼는 이가 나뿐만이 아니라는 사실을 알고 있었다. SOA와 REST에 관한 대부분의 논의에서는 모호성과 과장법, 잘못된 정보, 이성이 아닌 감성에 호소하는 주장이 만연했다. 하지만 난 분산 객체 기술로 골머리를 앓고 있는 개발자로서 웹 서비스에 매료됐고, 시스템을 통합하고 공통된 비즈니스 로직을 재사용하는 실용적인 방법으로서 웹 서비스를 바라보게 되었다.
그 후로부터 REST는 굉장한 탄력을 받았고, WS* 서비스는 굳건한 기반을 마련했으며, SOA는 사망 선고를 받게 됐다[Manes]. 이 모든 과정에서 웹 서비스를 향한 나의 열정은 조금도 줄어들지 않았다. 모바일과 클라우드, 서비스형 소프트웨어(SaaS, Software-as-a-Service) 플랫폼은 소프트웨어가 점차 분산되는 원인이 되었고, 이에 따라 웹 서비스의 중요성은 점차 커져만 갈 것이다. 우린 정말 흥분되는 시점에 서있다.

옮긴이의 말

우리는 소프트웨어 패턴의 홍수 속에 살아가고 있다. ‘갱 오브 포(gang of four)’의 디자인 패턴이 일으킨 이 물결은 순식간에 ‘패턴’이라는 제목의 수많은 논문과 책을 쏟아내는 데 기여했고, 프로그래머들은 패턴의 유용함과 중요성을 심도 깊게 논의하는 단계에 이르렀다. 하지만 이렇게 범람하는 패턴의 물결이 프로그래머를 패턴에 의존적인 사고방식에만 얽매이게 하는 문제점도 있다. 구조적으로 동일하지만 이름이 여러 가지인 패턴을 두고 어떤 이름이 더 올바른 선택인지 무의미한 고민을 하는 데 시간을 쏟거나, 정확한 의미는 알지 못한 채 단순히 암기한 패턴을 과용하기도 한다.
패턴은 소프트웨어의 구조적인 성공과 실패의 경험이 쌓여서 만들어진 요체다. 이러한 패턴의 속성을 통해 프로그래머는 패턴을 학습하면서 자신이 아직 경험하지 못한 상황을 간접적으로 경험하거나 제대로 해결하지 못한 문제의 해결에 적용할 수 있다. 그런데 이 과정에서 놓치지 말아야 할 중요한 점은, 패턴의 일반적인 해결책 뒤에 숨어 있는 소프트웨어 공학의 근본적인 원칙이 어떤 형태로 패턴에서 표현되는지 파악하려는 노력이 필요하다는 것이다.
패턴은 반복적으로 나타나는 다양한 문제에 대처하기 위해 일반적인 해결책을 보여주므로 프로그래밍의 근본적 원칙의 골자가 표면에 드러난다. 즉 추상화나 모듈화, 결합도, 캡슐화, 복잡도 같은 소프트웨어 공학적 원칙에 관한 고민이 패턴의 구조에 그대로 표현된다. 패턴을 학습하는 프로그래머나 아키텍트에게는 이러한 원칙적인 시각에서의 접근이 반드시 필요하고, 이에 대한 충분한 고민 없이는 패턴을 제대로 이해하고 활용하기 어렵다. 패턴의 명칭을 구분하고 속성을 분류하는 지엽적인 부분에 얽매여 중심을 보지 못하는 이에게는 이러한 시각을 갖고자 하는 노력이 중요한 전환점이 될 것이다.
이 책 『서비스 디자인 패턴 Service Design Patterns』은 웹 서비스 디자인에 필요한 원칙을 명쾌하게 정리했다는 점에서 의미가 있다. ‘갱 오브 포’에서부터 마틴 파울러에 이르는 여러 패턴과 소프트웨어 공학적 원칙을 기반으로, 웹 서비스라는 도메인에서 발생하는 디자인 문제의 효과적이고 근본적인 해결책을 제시한다. 독자는 이 책을 통해 웹 서비스의 디자인에 필요한 실질적인 경험과 지식을 쌓을 수 있을 뿐만 아니라, 그 바탕이 되는 근본적인 원칙을 함께 이해해 깊이 있는 안목과 실제 디자인에 적용 가능한 유연성을 기를 수 있다.

윤창석, 조성배

이 책은 웹 서비스를 사용하면서 반복적으로 직면하게 되는 문제의 해결책을 제시한다. 이를 위해 REST 아키텍처 스타일을 따르거나 SOAP/WSDL를 활용한 디자인 방안을 제시하며, 풍부한 예제 코드로 독자의 이해를 돕는다. 여러 문제를 핵심 주제별로 분류해서 근본적 디자인 구성요소를 바탕으로 설명하고 있기 때문에, 패턴의 동작 원리를 쉽고 분명하게 이해하고 효과적으로 적용할 수 있게 해준다. 서비스 개발자나 솔루션 아키텍트, 엔터프라이즈 아키텍트 모두에게 가치 있는 내용을 전달할 것이다. <br/><br/><b>이 책에서 다루는 내용</b><br/><br/>■ 어떻게 웹 서비스 API를 만들며, 어떤 공통 API 스타일이 있고, 특정 스타일을 사용해야 하는 시점은 언제인가?<br/>■ 어떻게 클라이언트와 웹 서비스가 통신할 수 있고, 여러 관계자가 오랜 시간에 걸쳐 서로 데이터를 교환할 수 있도록 복잡한 대화를 생성하는 기반은 무엇인가?<br/>■ 웹 서비스 로직을 구현하는 옵션에는 무엇이 있으며, 특정 접근법을 사용해야 할 때는 언제인가?<br/>■ 서비스가 사용하는 하위 시스템과 클라이언트가 더 낮은 결합도를 갖게 하는 방법은 무엇인가?<br/>■ 웹 서비스에 관한 정보는 어떻게 찾을 수 있는가?<br/>■ 클라이언트나 서비스에서 인증과 유효성 검증, 캐싱, 로깅 같은 범용 함수를 지원하는 방법은 무엇인가?<br/>■ 클라이언트의 중단을 가져오는 서비스의 변경은 무엇인가?<br/>■ 서비스에 버전을 부여하는 일반적인 방법은 무엇인가? 클라이언트를 즉시 갱신할 필요 없이, 웹 서비스가 비즈니스 로직의 지속적인 변화를 지원할 수 있도록 디자인하는 방법은 무엇인가?<br/><br/><b>이 책의 대상 독자</b><br/><br/>이 책은 전문적인 엔터프라이즈 아키텍트와 솔루션 아키텍트, 웹 서비스를 사용 중이거나 사용할 생각이 있는 개발자를 대상으로 한다. 이 전문가들은 크게 두 집단으로 나눌 수 있다. 첫 번째는 소프트웨어 제품(예: 상용 애플리케이션, 오픈소스 SaaS 애플리케이션)을 생산하는 집단이다. 두 번째는 IT 부서와 협력해 엔터프라이즈 애플리케이션을 개발하는 집단이다. 비록 이 카탈로그는 소프트웨어 업계의 종사자를 대상으로 하지만 학계에도 마찬가지로 적용할 수 있다. <br/><br/><b>이 책의 구성</b><br/><br/>1장, 객체에서 웹 서비스로 1장에서는 일반적인 소개를 설명한다. 1장 내용에 이어, 이 카탈로그에 수록된 패턴은 다음과 같은 6개의 장으로 나눠 알아본다.<br/><br/>2장. 웹 서비스 API 스타일 2장은 웹 서비스에서 사용하는 주요 API 스타일을 알아본다. 일단 스타일을 선택하고 나면 방향을 변경하기가 무척 어려워서, 올바른 스타일을 선택하는 일에 따른 결과는 결코 간과할 수 없다.<br/><br/>3장. 클라이언트와 서비스의 상호작용 3장에서는 모든 클라이언트/서버 통신의 기반을 서술한다. 여기서 알아볼 패턴은 어떤 서비스 디자인 스타일과도 함께 사용할 수 있다. 여러분은 이 패턴에 대한 이해를 바탕으로 여러 주체가 특정 주제로 데이터를 교환하는 복잡한 대화를 만들 수 있다.<br/><br/>4장. 요청과 응답의 관리 소프트웨어 애플리케이션은 논리적으로 연관된 엔터티를 포함하는 여러 계층으로 구성되기 마련이다. 4장에서는 웹 요청과 응답에 사용하는 일반적 서비스 계층[POEAA] 엔터티를 알아본다. 여기서 소개하는 패턴의 의도는 서비스가 사용하는 하위 시스템으로부터 클라이언트를 분리(decouple)하는 것이다.<br/><br/>5장. 웹 서비스 구현 스타일 서비스는 다양한 방법으로 구현할 수 있다. 서비스는 데이터베이스 테이블 같은 자원의 지식과 밀접히 연관됐을 수 있고, 객체 관계형 매퍼(ORM, Object Relational Mapper)의 활동이나 레거시 API의 직접 호출 등을 조율할 수 있으며, 외부 엔터티로 작업을 전달할 수 있다. 5장에서는 각 접근에 따른 결과를 살펴본다.<br/><br/>6장. 웹 서비스 인프라 어떤 작업은 너무 일반적이어서 끊임없이 다시 사용되곤 한다. 6장은 가장 일반적이며 기본적인, 클라이언트와 서비스 개발자에게 유용한 인프라 고려사항을 논의한다. 기업 SOA 인프라에 일반적으로 적용되는 여러 패턴도 함께 살펴본다.<br/><br/>7장. 웹 서비스의 진화 개발자는 각기 다른 속도로 변화하는 여러 클라이언트와 지속해서 함께 동작하는 서비스를 만들고자 노력한다. 하지만 이러한 목표는 달성하기가 상당히 힘들다. 7장에선 클라이언트 파괴적 변경(breaking change)을 유발하는 요소와 두 가지 일반적인 버전 관리 전략을 확인한다. 결국, 여러분은 어떻게 소프트웨어 메이저 릴리스를 피하며 클라이언트 요구사항을 만족하도록 서비스를 확장할 수 있는지 보게 된다.<br/><br/>또한 부록과 참고문헌, 용어집을 통해 추가 정보가 제공된다.

엔터프라이즈 애플리케이션을 이야기할 때 빼놓을 수 없는 진부한 이야기 중 하나는 엔터프라이즈 애플리케이션은 서로 동떨어져 있는 섬이 아니라는 말이다. 여러분은 특정 비즈니스 문제를 해결하기 위해 노력하겠지만, 여러분이 필요한 모든 데이터를 스스로 모으거나 모든 프로세싱을 직접 개발할 수는 없다. 충분한 시간이 있더라도 이런 데이터와 프로세싱은 어디에선가 이미 이뤄지는 중일 수 있고, 중복된 처리는 낭비일 뿐만 아니라 어지러운 불일치를 초래한다. 그 결과 대부분의 엔터프라이즈 애플리케이션은 여타 애플리케이션과의 통신이 필요하다. 그리고 이런 외부 시스템은 종종 동일한 조직 내에 있지 않을 뿐만 아니라, 때론 서드파티 조직이 제공하기도 한다.
지난 여러 해 동안, 이런 유형의 협력에서 가장 어려웠던 부분은 통신 경로의 확보 같은 일이었다. 이런 애플리케이션은 각기 다른 운영체제에서, 각기 다른 언어로, 각기 다른 플랫폼에서 작성됐기 때문에 지원하는 통신 프로토콜이 다른 경우가 많았다. 하지만 지난 10년 사이에 웹이 연결 문제를 해결하는 방법으로 떠올랐으며, 이제 대부분의 시스템은 80번 포트를 열고 이를 통해 텍스트로 이야기할 수 있다.
하지만 여전히 애플리케이션이 서로 어떻게 이야기해야 하는지와 관련한 많은 문제가 남아 있다. RPC 스타일 API나 메시지 지향 API, 최근에 주목받고 있는 REST 등을 사용해야 하는가? 로직은 서비스에 바로 포함해야 하는가, 아니면 하위 객체에 위임해야 하는가? 어떻게 클라이언트를 중단시키지 않고 사용 중인 서비스를 변경할 수 있는가?
일반적으로 내 시그너처 시리즈 책들은 다른 곳에서 많이 다루지 않은 주제를 담고 있지만, 이미 웹 서비스의 갖가지 측면을 다룬 매우 다양한 책들이 출간됐다. 그래서 어느 날 로버트의 초고가 도착했을 때 내가 그의 원고에 흥미를 느끼리라고는 생각지 않았다. 내 생각을 바꾼 것은 그의 초고가 앞서 언급한 주요 질문을 단 하나의 책 안에서 다뤘다는 점이었다. 이는 책을 읽는 데 투자하는 시간을 충분히 가치 있게 하는, 내가 늘 기술 서적에 기대해온 특징이었다.
우선 로버트는 주제 분야를 패턴으로 쪼개어가고, 우리는 이를 통해 함께 이야기할 때 사용할 용어집을 얻는다. 이어서 그는 각 패턴을 파고들며 패턴이 어떻게 동작하며, 여러 패턴 중 올바른 패턴을 선택하는 방법은 무엇인지 설명한다. 결국, 여러분은 웹 서비스 디자인의 다양한 접근법을 살펴보며, 여러분이 놓인 상황에 어떤 패턴이 적합한지를 결정할 수 있다. 그는 여러 예제 코드를 통해 실제로 어떻게 패턴을 사용하는지를 보여주며, 패턴은 일반적이기 때문에 다양한 기술 스택에 폭넓게 적용할 수 있다.
기술의 변화 속에서도 언제나 그 가치를 잃지 않을 원칙에 초점을 맞추며, 웹 서비스 사용의 중요 디자인 결정 지점을 한곳에 모은 책이 여기에 탄생했다.

- 마틴 파울러(Martin Fowler)

분산 애플리케이션의 개발은 보통 순탄하게 출발하지만, 그만큼 결국엔 좋지 않게 끝나는 경우도 많다. “가리키고, 웹 참조를 추가해, 클릭한다.” 이 말은 여러분이 신중히 만든 서비스 인터페이스가 있을 때, 어느 개발자가 이에 로드된 클라이언트를 가리키는 행위를 묘사한다. 우리는 왠지 모르게 디자인을 위한 도구의 사용을 대신해, 모든 느슨한 결합(loose coupling)을 단순하고 무책임한 난장판 속으로 몰아넣고야 만다. 결국, 릴리스할 시점이 다가오면, 우리는 모두가 같은 작업에 매달려 함께 밤을 새워야 하는 상황에 처한다.
좀 더 조심스러웠던 시대에 살고 있었다면, 아마도 그저 “안돼. 분산하지 마.”라고 말했을지도 모른다. 그리고 오늘날의 많은 경우에서도 여전히 이 조언은 옳다. 레이어(layer)는 티어(tier)와는 다르며, 여러분이 구현한 다양한 공개 표준이 무엇이든 3단 레이어 애플리케이션 아키텍처를 무너트리고 여러 부분으로 나눠 분산시키는 행동은 분명 바보 같은 짓이다.
하지만 오늘날에는 애플리케이션이 섬처럼 고립된 경우가 드물다. 비즈니스 역량이 조직의 경계를 넘어 흩어져 있다면, 이를 자동화하는 시스템 역시 그러하다. 우리가 기업 내부든 기업 간이든 현대 공급망의 분산적 특징을 지원하고자 한다면, 서비스 지향을 따르는 형태가 필요하다.
웹과 웹을 지탱하는 다양한 기술은 이런 면에서 굉장히 유용하다는 점이 증명됐다. 분산 시스템의 역사에서 웹이 차지하는 중요한 위치를 알지 못하거나 아예 무관심하더라도, 여러분이 직접 만들었거나 이제까지 사용해온 매우 다양한 서비스를 보면 웹이 반드시 필요한 존재임을 부인할 수 없다. 웹 전송 불가지론(transport agnosticism)으로 알려진 모든 사례는, SOAP 같이 HTTP라는 열차를 얻어타려는 경향을 보인다. 웹은 드러나지 않더라도 사라질 수는 없으며, 그렇게 몇 년 동안이나 서비스라는 무거운 짐을 어깨에 짊어지고 있다.
오늘날 웹 서비스의 모습을 바라보면, 우리가 구축하는 소프트웨어가 웹을 수용하는 방법이 적어도 세 가지 이상 있음을 알 수 있다. 웹의 성공은 웹을 구성하는 요소의 절대적 정확성 때문이 아니라, 그 경계에 서 있고 때론 경계를 넘나드는 다양한 아키텍처 스타일을 허용하는 내구성 때문이다. 어떤 서비스나 애플리케이션은 그저 웹의 뒤편에 숨어 있다. 이들은 웹을 반가워하지 않지만, 그럼에도 웹을 객체와 프로시저에 접근하는 데 필요한 좁은 관문으로 사용할 수밖에 없다. 눈을 돌려보라. 여러분은 웹상의 여러 서비스를 발견할 것이며, 이는 서비스가 HTTP를 단순한 전송 수단 정도로 대하는 데 머무르지 않고, RFC 2616에서 설명하는 강건한 조정(coordination)과 전송의 프로토콜로 활용함을 의미한다. 마지막으로, 여러분은 웹을 구성하는 일부(아주 소수의) 요소를 발견할 것이다. 이들은 컨슈머에게 데이터(어떻게 더 많은 데이터에 접근하고 조작할 수 있는지를 설명하는 데이터를 포함한)의 웹을 제공하기 위해, 웹을 구축하는 데 사용된 URI와 HTTP, 일반화된 하이퍼미디어 표현 형식(예: HTML) 등의 웹 초기 기반 기술을 사용한다.
이 책은 분산 환경을 지원하는 다양한 웹 사용법을 바탕으로, 시스템을 분산시킬 때 필요한 신중하고 방어적인 디자인의 필요성을 다룬다. 전략과 기술의 믿을 만한 지침서로서, 이 책은 내 소트웍스(ThoughtWorks)의 여러 친구나 동료가 어렵게 얻은 경험에 상응하는 내용을 담고 있다. 웹상에서 진행되는 일을 어떻게 해치울지 설명하며, 여러분이 어려움에 빠지지 않도록 돕는다. 내부 품질과 서비스 지속성을 높이는 단순성(simplicity)을 통해 엉망인 클라이언트 군단으로부터 서비스 도메인과 데이터를 보호하기 위한 복잡성(complexity)의 균형을 이룬다면, 한밤의 배포 작업에 모두가 함께 지쳐가는 상황을 피할 수 있다.
이안 로빈슨(Ian Robinson)