15년 만에, World Wide Web은 현대 기술의 한 축을 형성하게 되었다. 사람들이 쉽게 정보를 공개하고 연결할 수 있도록 고안된 웹은 소프트웨어 애플리케이션을 위한 플랫폼으로 성장했다. 하지만, 리치 애플리케이션 모델을 사용하고 개인화된 콘텐트를 생성하는 등, 애플리케이션이 점점 이머시브 경향을 띠면서, 아키텍처는 웹 아키텍처 스타일인 Representational State Transfer (REST)를 위반하게 되었다. 결국, 애플리케이션 확장성은 떨어지고, 시스템만 복잡하게 되었다.

Ajax Web 클라이언트 아키텍처 스타일은 이머시브 웹 애플리케이션들이 REST 아키텍처 스타일과 조화를 이룰 수 있도록 한다. 애플리케이션이 REST 원리를 거스를 때 생기는 부작용을 줄이고, REST의 바람직한 속성들을 누릴 수 있다. 이 글에서는 이머시브 웹 애플리케이션에 Ajax와 REST가 어떤 효과를 주는지를 설명한다.

REST: 웹의 아키텍처

World Wide Web이 수 십년의 연구 끝에 구현되었지만, 이것이 세상에 빛을 보게 된 것은 1990년 12월이었다. 이때, Tim Berners-Lee는 웹의 주요 컴포넌트의 프로토타입을 완성했다. (Unified Resource Identifiers (URI), HTTP, HTML, 브라우저, 서버) 웹의 폭발적인 채택은 개척자들의 기대를 초월했다. Roy Fielding의 유명한 논문에서 (참고자료)는 그 당시의 분위기를 다음과 같이 설명하고 있다.

"성공을 통해서 사기는 높아졌지만, 인터넷 개발자 커뮤니티는 웹 사용의 급속한 증가와 더불어, 초기 HTTP의 빈약한 네트워크 기능이 인터넷 인프라스트럭처의 용량을 초과하고, 결국 총체적인 붕괴를 가져올 것을 염려했다."

Fielding을 비롯하여 여러 사람들은 거대한 팽창과 사용을 지원할 수 있는지에 대해 웹의 아키텍처와 적합성을 재검토 했다. 재검토의 결과, URI와 HTTP 같은 중요한 표준이 업데이트 되었다. 눈에 보이지는 않지만 의미 있는 결과는 하이퍼미디어(hypermedia) 애플리케이션에 대한 새로운 아키텍처 스타일의 규명이었다. Fielding은 이것을 Representational State Transfer (REST)라고 명명했다. Fielding은 REST의 디자인 제약 조건들을 수락하는 웹 상에 전개된 컴포넌트들은 웹의 바람직한 속성들을 향유할 수 있을 것이라고 단언했다. 그는 또한, REST 원리에서 이탈한 웹 컴포넌트들은 이러한 효과를 누릴 수 없을 것이라고 경고했다.

초기에, 대부분의 웹 사이트와 단순한 웹 애플리케이션들은 REST의 원리를 따랐다. 하지만, 웹 애플리케이션이 점점 이머시브 경향을 띠면서, 웹 애플리케이션 아키텍처는 REST의 원리를 거스르고, 그것에 대한 결과로 인해 고통을 받고 있다. 이머시브 서버 측 웹 아키텍처의 문제는 파괴적이다. 십 년 동안 이러한 아키텍처를 사용해 오는 동안, 이러한 문제들이 웹 애플리케이션 아키텍처 고유의 문제라는 인식을 심어주었기 때문이다. 하지만 이것은 사실이 아니다. 오히려, 이것은 서버 측 웹 애플리케이션 아키텍처 스타일에서 기인한다. 이러한 편견을 깨기 위해서, 현재가 있기까지, 아키텍처의 발달 과정을 살펴보는 것도 도움이 된다. Ajax 애플리케이션 구현이 가능해 지면서, 우리가 받아들였던 많은 가설들이 더 이상 유효하지 않은지에 대해 설명할 것이다.

위로

웹 애플리케이션의 역사

Berners-Lee는 광범위한 지역으로 분산된 연구원들이 문서를 공유하고, 문서들 간 링크를 만들어서 지식과 아이디어의 보급 속도를 높이는 수단으로서 웹을 만들었다. 하지만, URI 표준의 아키텍처 특성들로 인해 정적인 문서 이상의 것들을 공유하는 것도 가능했다.

정적 문서를 제공하는 웹 사이트

최초의 웹 콘텐트는 정적 HTML 문서들과, 다른 정적 문서들로의 링크로 구성되었다. (그림 1)

REST는 정적 문서들을 매우 효율적으로 검색한다. 이들은 URI와 최근 수정된 날짜를 기반으로 쉽게 캐싱될 수 있기 때문이다. 개발자들은 정적 문서들을 넘어, 동적 콘텐트 공급까지 지원하게 되었다.

초기 동적 웹 애플리케이션

Berners-Lee와 다른 사람들은 URI 표준을 만들어서 고유한 리소스 구분을 지원하면서, 이것의 표현(HTML, 텍스트)이 웹 클라이언트(주로, 웹 브라우저)와 웹 서버 간 협상에 기반하여 변할 수 있도록 했다. URI는 리소스 구분과 리소스의 기반 스토리지 메커니즘을 구분하기 때문에, 웹 개발자는 URI의 신택스를 검사하고, 문서를 생성하는 프로그램을 만들고, 사전 정의된 UI 엘리먼트와, 관계형 데이터베이스에서 동적으로 검색된 데이터를 결합한다. (그림 2) 문서들은 생성되지만, 이들의 캐싱 특성은 정적 파일의 그것과 동일하다.

이러한 초기 애플리케이션의 예가 대학의 디렉토리 웹 애플리케이션이다. 이 애플리케이션은 다음과 같이 작동한다.

1. 사용자가 이름(예를 들어, Bill Higgins)을 웹 폼에 입력하고, Submit 버튼을 클릭한다.
2. 이 폼은 입력된 이름에 따라 URI를 만들고, 서버에서 이 URI의 콘텐트를 요청한다. (예, GET http://psu.edu/Directory/Bill+Higgins).
3. 서버는 URI를 검사하고, 학생의 전화 번호와 주소가 있는 웹 페이지를 생성한다.
4. 서버는 생성된 페이지를 사용자 브라우저로 보낸다.

이러한 인터랙션의 중요한 속성은 멱등 원리(idempotent)이다. 기반 리소스들이 변하지 않는 한(예를 들어, Bill이 전화 번호를 바꾸는 경우), 아웃풋은 요청과 동일하다. 브라우저나 프록시 서버는 Bill Higgins 문서를 로컬에서 캐싱할 수 있고, 기반 리소스가 변하지 않았다면, 원격 서버 보다는 로컬 캐시에서 리소스를 검색한다. 이러한 방식은 응답성을 향상시키고, 전체적인 시스템 효율성과 확장성을 늘린다. 이러한 초기 동적 웹 애플리케이션들은 잘 작동했고, 사용자의 손 안에 무수한 정보를 가져다 주었다.

이머시브 웹 애플리케이션

차세대 웹 애플리케이션은, 개인화 된 콘텐트와 리치(rich) 애플리케이션 모델을 제공하는 이머시브(immersive) 특성을 띠게 되었다. 10년 동안, 웹 개발자들은 이러한 이머시브 애플리케이션 구현에 성공했다. 대표적인 예가 Amazon.com e-commerce 사이트이다. 사용자는 Amazon 웹 애플리케이션과 인터랙팅 하면서, 특정 제품들을 추천하고, 검색 목록을 보여주고, 사용자 쇼핑 카트에 놓인 아이템 가격을 디스플레이 하는 복잡한 커스텀 페이지를 만든다.

위로

이머시브 서버 측 애플리케이션과 REST

이머시브 웹 애플리케이션은 확실히 유용하지만, 서버 측 이머시브 웹 애플리케이션 스타일은 REST 아키텍처 원리와 근본적으로 일치하지 않는다. 특히, 핵심적인 REST 제약 조건을 위반하고, REST의 가장 중요한 장점들을 활용할 수 없기 때문에, 새로운 문제를 만들어 낸다.

"STATELESS 서버" 제약 조건 위반

REST의 "client-stateless-server" 제약 조건은 서버 상의 세션 상태를 허용하지 않는다. 이러한 제약 조건 하에서 디자인을 하면 시스템의 가시성, 신뢰성, 확장성이 높아진다. 하지만, 이머시브 서버 측 웹 애플리케이션은 하 명의 사용자에게 많은 개인화를 제공해야 하기 때문에, 두 디자인 사이에서 선택해야 한다. 첫 번째는, 각각의 클라이언트 요청과 함께 많은 상태 정보를 보내서, 각 요청이 완성된 콘텐트를 갖고, 서버는 STATELESS 상태로 될 수 있다. 두 번째는, 더 단순한 것으로서, 애플리케이션 개발자와 미들웨어 벤더들이 모두 선호하는 솔루션이기도 하다. 바로 간단한 사용자 아이디 토큰을 보내서, 이 토큰과, 서버 측의 "user session" 객체와 제휴하는 것이다. (그림 3) 두 번째 디자인은 client-stateless-server 제약 조건을 위반하는 것이다. 이는 원하는 사용자 기능을 실행하지만(개인화), 아키텍처에는 상당한 부담을 안겨준다.

Java™ Servlet의 HttpSession API도 한 예이다. HttpSession은 세션 상태를 특정 사용자와 제휴시킨다. 이 API는 신참 개발자에게는 단순하게 보인다. HttpSession에 어떤 객체라도 저장할 수 있고, 특별한 검색 로직을 코딩하지 않고도 가져올 수 있는 것처럼 보인다. 하지만, HttpSession에 더 많은 객체들을 놓기 시작하면, 여러분의 애플리케이션 서버가 더 많은 메모리와 프로세싱 리소스들을 사용하고 있음을 깨닫게 된다. 클러스터 환경에 애플리케이션을 전개하여 증가하는 리소스에 대한 필요를 맞출 것을 결정한다. 그리고 나서, HttpSession이 클러스터 환경에서 작동하도록 하려면, 각 객체는 자바의 Serializable 인터페이스를 구현하여, 세션 데이터들이 클러스터 환경의 서버들 간 전송되도록 해야 한다는 것도 깨닫는다. 그리고 나서, 셧다운/재시작 사이클의 경우, 애플리케이션 서버가 세션 데이터를 보존하는지의 여부를 결정해야 한다. 곧, 여러분은 client-stateless-server 제약 조건을 위반하는 것이 과연 옳은 일인지에 대해 의심을 하게 된다. (실제로, 많은 개발자들은 이러한 제약 조건에 무지하다.)

분산 캐싱 방지

이머시브 서버 측 웹 애플리케이션의 또 다른 심각한 결과는 리소스 캐싱에 REST의 일급 지원을 활용할 수 없다는 것이다. Fielding의 말을 인용하면, "캐시 제약 조건의 장점은 몇 가지 인터랙션을 부분 또는 전체적으로 제거하여, 인터랙션의 평균 레이턴시를 줄임으로써, 효율성, 확장성, 성능을 높일 수 있다는 점이다. 하지만, 단점은, 캐시 내의 오염된 데이터가 서버로 직접 보내진 요청에서 얻은 데이터와 매우 다르다면, 캐시는 신뢰성을 잃게 된다."

이머시브 웹 애플리케이션을, 사용자가 제공하는 새로운 인풋, 다른 사람들이 제공한 새로운 인풋, 새로운 백엔드 데이터에 의해 지속적으로 변하는 활성 엔터티로 간주할 수 있다. 서버는 여러 사용자들과 애플리케이션의 인터랙션에 기반하여 각 페이지를 만들어야 하기 때문에, 같은 문서를 두 번 만드는 것은 불가능 하다. 결국, 웹 브라우저나 프록시 서버는 서버 리소스를 캐싱할 수 없다.

캐싱할 수 없는 리소스 문제를 해결할 수 있는 여러 솔루션이 있다. 하나는 소단위 리소스들의 서버 측 캐시를 만들어서, 서버가 기본 엘리먼트(HTML과 데이터) 보다는 사전 조합된 부분들에서 대단위 페이지를 구현할 수 있도록 한다. 하지만 문제가 있다. 모든 요청은 간단하지 않는 서버 프로세싱을 야기하면서, 확장성에 영향을 미치고, 응답 시간에도 영향을 미친다.

캐싱 가능한 리소스 제공을 금지할 경우 생기는 또 다른 결과는 매우 동적인 웹 애플리케이션이 검색 엔진과 요청을 만드는 다른 "장치"를 막는다는 점이다. 각 요청에는 값비싼 프로세싱이 개입되기 때문이다. REST 애플리케이션에서, 각 장치에 한번만 리소스를 제공하고, 후속 장치에는 "Not-modified" 메시지를 보낸다.

과부하 서버에 그렇게 많은 리소스 소비를 집중키는 이유와, 프로세싱과 메모리를 클라이언트로 분산할 수 있는 시기는? 그 해답은 전통적인 웹 브라우저 제약 조건인데, 이것은 불가능 했다. (Ajax를 사용하지 않는 클라이언트 측 프로세싱 참조) 하지만, Ajax 아키텍처 스타일에서는 프로세싱과 상태 요구 사항들을 클라이언트로 분산할 수 있다. Ajax 스타일 아키텍처를 선택했던 이머시브 애플리케이션이 REST와 조화를 이루고, 그 효과를 누릴 수 있었는지를 알아보자.

Ajax와 REST

앞에서 설명했지만, 전통적인 서버 측 웹 애플리케이션은 서버에 표현과 동적 데이터 엘리먼트를 결합하고, 완전한 형태의 HTML 문서를 브라우저로 리턴한다. Ajax 애플리케이션은 대부분의 UI와 애플리케이션 로직이 브라우저 내에 있다는 점이 다르다. 브라우저 기반 애플리케이션 코드는 새로운 서버 데이터를 필요할 때 마다 보내고, 이 데이터를 현재 페이지에 구성한다. (참고자료 - Jesse James Garrett의 세미나 자료) 표현과 데이터 바인딩 위치는 구현 상세처럼 보이지만, 이러한 차이점은 완전히 다른 아키텍처 스타일로 이끈다.

STATEFUL 웹 클라이언트 활용하기

사람들은 Ajax 애플리케이션을 전체 페이지 리프레쉬를 수행할 필요가 없는 웹 페이지라고 말한다. 이러한 설명은 정확하지만, 전체 페이지 리프레쉬는 이머시브 사용법과는 다른 개념이다. 전체 페이지 리프레쉬는 아키텍처 관점에서 볼 때 더 나쁜 것이다. 이는 애플리케이션 상태를 클라이언트에 저장할 수 없고, 결국, 애플리케이션들은 웹의 강력한 디자인 포인트를 활용할 수 없게 된다.

Ajax는 전체 리프레쉬 없이 서버와 인터랙팅 할 수 있기 때문에, 테이블에 STATEFUL 클라이언트 옵션을 둘 수 있다. 이것은 동적 이머시브 웹 애플리케이션의 토대가 된다. 애플리케이션 리소스와 데이터 리소스 바인딩은 클라이언트 측으로 옮겨갔기 때문에, 이러한 애플리케이션은 두 가지 세계에서 좋은 것만 취할 수 있다. 이머시브 웹 애플리케이션의 동적이고, 개인화 된 사용자 경험과, REST 애플리케이션의 단순하고 확장성 있는 아키텍처를 모두 취할 수 있다.

Ajax 엔진 캐싱하기

Amazon.com이 순수한 Ajax 애플리케이션으로 재구현 된다고 상상해 보라. 서버에서 동적으로 모든 데이터를 내보내는 하나의 웹 페이지를 말이다. (Amazon은 이렇게 하기를 원치 않을지도 모른다. 어쨌든 이 문제는 이 글에서 거론할 것은 아니다.) 많은 UI와 애플리케이션 로직이 서버 보다는 클라이언트에서 실행되기 때문에, 초기 페이지 로드는 Amazon의 Ajax "엔진"을 다운로드 해야 한다. (Garrett의 설명 참조). 이 엔진에는 (JavaScript 코드로서 구현된) 많은 애플리케이션 로직과, 나중에 서버에서 비동기식으로 발송된 비즈니스 데이터로 채워지는 UI가 포함된다. (그림 4)

Ajax 엔진의 재미있는 부분은 여기에 많은 애플리케이션 로직과 표현 프레임웍 엘리먼트가 포함되더라도, 올바르게 구현된다면, 어떤 비즈니스 데이터나 개인화된 콘텐트도 들어있지 않을 수 있다. 애플리케이션과 표현은 전개 시 동결된다. 전형적인 웹 환경에서, 애플리케이션 리소스는 6개월에 한 번식 바뀐다. 애플리케이션 리소스와 데이터 리소스를 분리하는 Ajax 엔진은 캐싱 가능하다.

Dojo Toolkit이 좋은 예이다. (참고자료) Dojo는 구현 툴을 제공하여 모든 애플리케이션의 로직, 표현, 스타일을 포함하고 있는 압축된 JavaScript 파일을 만든다. 이것은 어디까지나 파일이기 때문에, 웹 브라우저는 이를 캐싱할 수 있다. 다시 말해서, Dojo 실행 웹 애플리케이션을 두 번째 방문하면, 서버가 아닌 브라우저의 캐시에서 Ajax 엔진을 로딩한다는 의미이다. 이것을 고도의 이머시브 서버 측 웹 애플리케이션과 비교해 보라. 이 경우 모든 요청은 엄청난 서버 프로세싱을 요구하면서, 브라우저와 네트워크는 늘 변하는 리소스들을 캐싱할 수 없을 것이다.

Ajax 애플리케이션 엔진은 단순한 파일이기 때문에, 프록시가 가능하다. 대형 기업 인트라넷에서, 단 한 명의 사원이 특정 버전의 애플리케이션의 Ajax 엔진을 다운로드 할 수 있고, 다른 사람들은 인트라넷 게이트웨이에서 캐싱 카피를 얻을 수 있다.

애플리케이션 리소스의 경우, 잘 구현된 Ajax 애플리케이션 엔진은 REST 원리와 잘 조화를 이루고, 서버 측 웹 애플리케이션에 비해 확장성도 우수하다.

Ajax 데이터 캐싱

사용자들은 Ajax 웹 사이트를 검색하고, Ajax 애플리케이션 엔진을 로딩한다. 아마도 브라우저의 캐시에서 또는 로컬 프록시 서버에서 가져올 것이다. 비즈니스 데이터는 어떤가? 애플리케이션 로직과 상태가 브라우저에 있고, 또 실행되므로, 애플리케이션과 서버의 인터랙션은 전통적인 웹 애플리케이션과 매우 다르다. 콘텐트의 혼합된 페이지들을 내보내는 대신, 비즈니스 데이터만 내보내면 된다.

Amazon.com 예제로 다시 돌아가서, 디자인 패턴과 관련된 책 정보를 보기 위해 링크를 클릭한다. Amazon.com의 현재 애플리케이션에서, 링크 클릭 액션은 요청된 리소스를 구분하면서 많은 정보를 보낸다. 또한, 이전 세션 데이터(최신에 검색한 아이템), 개인 정보("you purchased this book in 1999"), 실제 비즈니스 리소스를 포함한 새로운 페이지를 서버가 만들도록 하는 세션 상태 생성물들을 보낸다. 이 애플리케이션은 매우 동적이고 개인화 되었지만, 확장성은 없다. (이러한 아키텍처 문제는 수백만 달러를 들여 인프라스트럭처 엔지니어링으로 극복할 수 있다.) 이러한 액션을 Ajax 버전의 애플리케이션으로 실행한다고 생각해 보자. "최근 검색한 아이템"과 관련하여 어떤 프로세싱도 발생하지 않는다. 이것은 페이지에 이미 존재하는 정보이기 때문에, 링크를 통해 다른 페이지로 갈 필요가 업다. 다음 두 개의 요청들은 디자인 패턴 서적과 관련되어 있다.

• /Books/0201633612 (where 0201633612 is the design pattern book's ISBN number)
• /PurchaseHistory/0201633612/bhiggins@us.ibm.com

첫 번째 가상 요청은 책에 대한 정보(저자, 제목, 설명)를 리턴한다. 사용자 관련 데이터가 없다. 사용자 관련 데이터가 없다는 것은, 더 많은 사용자들이 같은 리소스를 요청하면, 원래 서버가 아닌 인터넷 상의 중개 노드에서 캐싱 버전을 가져오게 된다는 것을 의미한다. 이러한 특성은 서버와 전체적인 네트워크 부하를 줄인다. 반면, 두 번째 요청에는 사용자 고유의 정보가 있다. (Bill Higgins의 구매 이력) 이 데이터에는 개인화된 정보가 들어있기 때문에, 오직 한 명의 사용자만이 이 URI에서 데이터를 가져와서 캐싱 할 수 있다. 이 개인화된 데이터에는 개인화 되지 않은 데이터에 대한 확장성은 없지만, 이 정보는 뚜렷한 URL에서 검색되고, 다른 애플리케이션과 캐싱 가능한 데이터 리소스들의 캐싱을 방해하지 않는다.

Ajax의 강력함

Ajax 아키텍처 스타일의 또 다른 장점은 서버 오류를 쉽게 다룰 수 있다는 점이다. 앞서 언급했지만, 서버 측 웹 애플리케이션과 이머시브 사용자 경험은 서버 상에서 많은 양의 사용자 세션 상태를 보유하고 있다. 서버 오류가 생기면, 세션 데이터 상태는 없어지고, 사용자는 이상한 브라우저 작동을 경험하게 된다. (홈 페이지로 다시 돌아온다거나, 쇼핑 카트에 아이템이 없어진다.) STATEFUL 클라이언트와 STATELESS 서비스를 가진 Ajax 애플리케이션에서, 서버 충돌/재시작은 사용자에게 투명하다. 서버 충돌은 세션 상태에 영향을 주지 않고, 사용자의 브라우저에 살아있다. STATELESS 서비스 작동은 사용자 요청 콘텐트에 의해서만 결정된다.

위로

전망과 문제점

이머시브 웹 애플리케이션의 경우, 잘 디자인 된 Ajax/REST 애플리케이션은 사용자 경험, 응답성, 확장성 측면에서 볼 때, 전통적인 서버 측 웹 애플리케이션 보다 훨씬 앞선다. 하지만, 아키텍처 스타일만이 소프트웨어 프로젝트와 웹 애플리케이션의 성공 요인은 아니다. 애플리케이션에 Ajax를 채택하는 방법, 대규모 JavaScript 개발, 문화적 문제, 패키징 문제 등 Ajax/REST 애플리케이션을 만드는 것과 관련된 런타임 외적인 문제들도 있다. Part 2에서는, Ajax 성공을 위한 다양한 채택 옵션과 고려 사항들을 설명하겠다.

감사의 말

기술적인 측면으로 도움을 준, Chris Mitchell, Josh Staiger, Pat Mueller, Scott Rich, Simon Archer에게 감사의 말을 전하고 싶다. 또한, REST 스타일의 웹 서비스를 생각할 수 있도록 도움을 준, Redmonk의 James Governor와 Steve O'Grady에게도 감사한다.

기사의 원문보기

• Ajax and REST, Part 1

참고자료

교육

• "Architectural Styles and the Design of Network-based Software Architectures" (Roy Fielding, University of California - Irvine, 2000)
  
  
• Weaving the Web (Tim Berners-Lee, HarperCollins, 2000)
  
  
• "Ajax: A New Approach to Web Applications" (Jesse James Garrett, Adaptive Path, February 2005)
  
  
• All Things Distributed: Werner Vogels' weblog on building scalable and robust distributed systems (Werner Vogels, Amazon.com)
  
  
• developerWorks 아키텍처 존 (한글페이지)
  
  
• 필자 블로그
  
  
• Ajax Resource Center
  
  

제품 및 기술 얻기

• The Dojo Toolkit
  
  

토론

• Ajax 토론 포럼
  
  

필자소개

Bill Higgins는 IBM Rational Software 부서에서, 개발 지원 툴 관련 일을 하고 있다. 2000년, Penn State University의 컴퓨터 공학과를 졸업했다. 여가 시간에는 아내와 두 아이들과 시간을 보내거나, developerWorks 블로그, 독서, 농구 등 취미를 즐긴다.

아티클 순위

의견

위로

목차

• REST: 웹의 아키텍처
• 웹 애플리케이션의 역사
• 이머시브 서버 측 애플리케이션과 REST
• Ajax와 REST
• 전망과 문제점
• 참고자료
• 필자소개
• 의견