엔터프라이즈 애플리케이션을 이야기할 때 빼놓을 수 없는 진부한 이야기 중 하나는 엔터프라이즈 애플리케이션은 서로 동떨어져 있는 섬이 아니라는 말이다. 여러분은 특정 비즈니스 문제를 해결하기 위해 노력하겠지만, 여러분이 필요한 모든 데이터를 스스로 모으거나 모든 프로세싱을 직접 개발할 수는 없다. 충분한 시간이 있더라도 이런 데이터와 프로세싱은 어디에선가 이미 이뤄지는 중일 수 있고, 중복된 처리는 낭비일 뿐만 아니라 어지러운 불일치를 초래한다. 그 결과 대부분의 엔터프라이즈 애플리케이션은 여타 애플리케이션과의 통신이 필요하다. 그리고 이런 외부 시스템은 종종 동일한 조직 내에 있지 않을 뿐만 아니라, 때론 서드파티 조직이 제공하기도 한다.
지난 여러 해 동안, 이런 유형의 협력에서 가장 어려웠던 부분은 통신 경로의 확보 같은 일이었다. 이런 애플리케이션은 각기 다른 운영체제에서, 각기 다른 언어로, 각기 다른 플랫폼에서 작성됐기 때문에 지원하는 통신 프로토콜이 다른 경우가 많았다. 하지만 지난 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)