웹을 지탱하는 기술1 - 웹 개론

이 책의 목적

• 웹 아키텍처의 관점에서 HTTP, URI 그리고 각종 하이퍼미디어 포맷의 스펙을 설명합니다.
• 웹 서비스의 구체적인 설계방법을 보여줍니다.

웹 구현을 지탱하는 기본적인 지식을 알고 싶었는데 이 책의 목적을 보면서 어느정도 그 갈증을 해결할 수 있겠다라는 생각이 듭니다. 그리고 두번째 목적인 구체적인 설계방법에서 제가 해오던 것과 좀 비교하면서 읽을 수도 있을 것 같네요.

이 책은 총 5부로 이루어져있습니다. 1부. 웹의 기술적인 백그라운드와 아키텍처 2부. URI 3부. HTTP 4부. 하이퍼미디어 포맷 5부. 웹 서비스와 웹 API의 설계

책의 목적에서 첫번째 목적이 제일 크게 1부~4부, 두번째 목적이 5부에서 설명되고 있는 것 같네요. 하루에 1부씩 읽으면 될 것 같습니다.

 

1부. 웹 개론

Chapter01. 웹이란 무엇인가?

한 마디로 말하자면 ‘거대한 정보 시스템’이라고 할 수 있겠죠. 그런데 이렇게 말하면 좀 추상적이니 그것을 구성하고 있는 것을 설명해보겠습니다. 크게 HTTP, URI, HTML이라는 기술을 통해 웹을 지탱하고 있는데요. HTTP는 통신의 수단으로, URI는 해당 리소스에 대한 고유한 정보로, HTML은 그 정보를 표현하는 형식으로 사용되고 있습니다.

 

또 웹을 특징짓는 2가지 측면이 있습니다. ‘하이퍼미디어’와 ‘분산 시스템’이라는 것인데요. 하이퍼미디어는 다양한 리소스를 하이퍼링크로 연결해 구성한 시스템입니다. 이를 통해 선형적인 정보 탐색이 아닌 사용자에 의해 선택에 의해 정보가 제공되는 비선형적 정보 탐색이 이루어졌습니다. 또 분산 시스템을 통해 하나의 컴퓨터가 아닌 전 세계에 흩어져있는 서버들을 통해 웹을 접속할 수 있게 되었습니다. 만약 하나의 컴퓨터였다면 지금 제공되는 정보의 양은 상상도 못했을 것입니다.

 

Chapter02. 웹의 역사

이번 장은 생소한 용어, 기술들이 많이 나와 차근차근 이해하기가 쉽지 않았습니다. 그래서 좀 인상깊었던 내용들만 정리해볼게요.

• 하이퍼미디어, 분산 시스템 개념은 이전부터 있었지만 이를 이용하여 웹을 만든 사람이 ‘팀 버너스-리’ 입니다.
• 웹을 지탱하는 기술인 HTTP, URI, HTML 에 대한 표준이 이를 제공하는 회사들마다 달랐습니다. 그래서 버너스-리가 중심이 되어 표준화를 수행하는 단체를 만들었는데 이것이 W3C(World Wide Web Consortium)입니다.
• 저는 웹 아키텍처 스타일 중 하나인 REST(Representatinal State Transfer)가 한참 후에 나온 개념인 줄 알았는데요. 웹이 나오고 그쯔음 논의된 것이더라구요. 이때 REST와 논쟁이 되었던 개념 중 SOAP가 있었습니다. 하지만 SOAP는 복잡도가 크고 벤더 회사간 경쟁으로 인해 표준화가 되기 힘들었다고 하네요.

 

Chapter03. REST 웹의 아키텍처 스타일

아키텍처 스타일이란 복수의 아키텍처의 공통된 성질, 양식, 규정 혹은 독특한 방식을 가리키는 말 입니다. 제가 이해하는 말로 쉽게 말하자면 아키텍처에 대한 제약조건의 모음 이라고 할 수 있을 것 같습니다. 아키텍처 스타일은 아키텍처를 결정할 때 이정표의 역할을 하게 됩니다.

 

구현, 아키텍처, 아키텍처 스타일은 추상의 정도로 나타낼 수 있습니다. 즉 구현에서 한층 추상화된 것이 아키텍처, 그리고 더 추상화된 것이 아키텍처 스타일인 것이지요.

• 아키텍처 스타일 : REST
• 아키텍처 : 브라우저, 서버, 프록시, HTTP, URI, HTML
• 구현 : Apache, Firefox, Internet Explorer

네트워크 시스템에서 가장 유명한 아키텍처 스타일은 당연 ‘클라이언트 / 서버’이고 웹에 사용됩니다. 하지만 REST도 같은 네트워크 시스템으로 웹에서 사용되는데요. 이 2개가 공존할 수 있는 이유는 ‘클라이언트 / 서버’ 아키텍처 스타일에서 좀 더 구체화된 것이(파생된 것이) REST이기 때문입니다.

 

REST에 있어 중요한 개념 중 하나가 리소스(Resource)입니다. 리소스는 ‘웹상에 존재하는 이름을 가진 모든 정보’ 로 말할 수 있는데요. 웹상에서 각각의 고유한 정보를 나타내기 위해 리소스에 이름을 부여하는데요. 그것이 URI입니다. URI를 통해 프로그램은 리소스가 표현하는 정보에 접근할 수 있습니다.

하나의 리소스는 복수의 URI를 가질 수 있습니다. 즉 http://weather.example.com/seoul/today 라는 URI를 가지고 오늘이 2019년 2월 7일이었다면 http://weather.example.com/seoul/2019-02-07 로 같은 리소스를 가리킬 수 있는 것입니다.

서버와 클라이언트 간의 실제로 데이터를 주고 받을 때 주고받는 데이터를 ‘Resource Representation’이라고 합니다. 리소스는 표현과 상태라는 개념이 있는데요. 표현은 하나의 리소스로 여러 형식(텍스트, PDF, 이미지 등)으로 표현할 수 있다는 것 이구요. 상태는 리소스 상태값이 변함에 따라 표현도 변한다는 것 입니다. 이는 웹상에서 그때그때 상태값이 변화하는 모습을 보면 이해할 수 있을 것입니다.

 

REST는 복수의 아키텍처 스타일이 조합되어 구축된 복합 아키텍처 스타일이라고 하는데요. 밑에선 여러 아키텍처 스타일을 언급하면서 정리해볼게요.

• 클라이언트/서버

  • 클라이언트가 서버에게 요청을 보내면, 서버는 클라이언트에 대해 응답을 돌려줍니다.
  • 클라이언트와 서버가 분리되어 있기 때문에 클라이언트를 여러 플랫폼(PC, 휴대전화, 게임기)으로 구성할 수 있습니다. 또 서버는 복수의 서버를 조합해 구성할 수 있습니다.

• 스테이트리스 서버(Stateless Server)

  • 클라이언트의 애플리케이션 상태를 서버에서 관리하지 않는다는 것 을 말합니다.
  • 하지만 폼 인증을 하기 위해 Cookie를 사용해 세션 관리를 많이 하는데요. 이는 HTTP를 stateful하게 만듭니다. 그렇기 때문에 스테이트리스의 이점을 살리기 위해 Cookie를 최소한으로 사용하려는 노력이 필요합니다.

• 캐시

  • 리소스 이용도, 최신성에 기초해 한번 가져온 리소스를 클라이언트 쪽에서 재사용하는 방식 입니다.

• 유니폼 인터페이스

  • URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일 을 말합니다.
  • 이러한 제약들이 엄격해보이지만 실은 이 덕분에 아키텍처가 간단해지고 이를 통해 더욱 다양한 클라이언트와 서버가 연결될 수 있었습니다.

• 계층화 시스템

  • 시스템을 몇 개의 계층으로 분리하는 아키텍처 스타일 을 말합니다.
  • 이 덕분에 클라이언트와 서버 사이에 로드 밸런서를 설치해 부하를 분산시키고, 프록시를 설치해 액세스를 제어할 수 있습니다. 서버와 같은 동일한 인터페이스로 접속하기 때문에 가능한 일입니다.

• 코드 온 디맨드

  • 프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍처 스타일 입니다. JavaScript, Flash, Java 애플릿 등이 이에 속합니다.
  • 클라이언트 프로그램에 미리 준비해둔 기능뿐 아니라 새로운 기능을 계속 추가할 수 있습니다.

REST 논문을 발표한 필딩은 코드 온 디맨드는 옵션으로 두었지만 위의 총 6개를 조합한 아키텍처 스타일을 REST라 하였습니다. 하지만 REST를 염두해두고 아키텍처를 만들더라구도 현실적으로 6가지 모두 만족시키는 것은 어려운 일입니다. 저자는 몇 가지 제외하더라도 가치있는 서비스를 만드는 것이 더 중요한 일이라고 강조하네요.

 

이번 장을 읽으면서 이해되지 않는 개념들이 좀 많았습니다. 그 이유를 생각해보면 앞에서 설명한 웹의 역사를 이해를 충분히 하지 못해서 그런 것 같습니다. 그치만 좋았던 점은 REST에 대한 한층더 깊은 이해를 할 수 있었다는 것입니다. 최근 REST에 대해 궁금한 것들이 좀 많았는데 이번 장을 통해 좀 더 정리되는 계기가 되었습니다. 그리고 아키텍처와 아키텍처 스타일의 관계에 대해 알게된 것, 그리고 REST가 여러 아키텍처 스타일의 조합으로 구성된 것도 큰 수확인 것 같네요.