항상 사용하고 있는 웹에 대해 알아보자, [웹 개발자를 위한 웹을 지탱하는 기술]

 

웹 없이는 살아갈 수 없는 세상이 되었다.

우리는 하루에도 수십 번 이상 검색을 하고, 영상을 보면서 웹을 사용한다.

웹은 웹 사이트, 유저 인터페이스, 웹 API 등 다양한 용도로 사용된다.

공기처럼 어디에나 존재하는 웹에 대해 알아보자.

https://miro.medium.com/max/1200/1*bMdzfjPsvXIh3sR0DEnDpQ.jpeg

기본적으로 웹은 HTTP, URI, HTML 등의 기술로 구성되어 있다.

HTTP는 웹 상의 정보를 가져오거나 내보낼 때 사용하는 프로토콜이고,

URI는 웹 상의 정보를 가리킬 수 있는 식별자이고,

HTML은 웹 상의 정보를 표현하는 문서 형식이다.

어떤 웹 페이지 주소를 웹 브라우저 주소창에 치면

웹 브라우저는 HTML로 기술된 문서를 URI로 지정해서 HTTP로 통신해서 받아와서 보여준다.

 

웹은 분산시스템이면서 하이퍼미디어 시스템이다.

복수의 컴퓨터를 조합해 처리를 분산하는 방식을 분산 시스템이라고 하는데,
분산 시스템은 여러 개의 컴퓨터와 프로그램을 네트워크에 분산해서 한 대로 처리할 때보다 효율적으로 처리한다.
웹은 전 세계에 있는 서버에 전 세계의 브라우저가 액세스하는 분산 시스템이다.

 

웹 페이지는 다른 웹페이지와 삽입된 이미지, 동영상 등으로의 링크가 포함된 하이퍼 미디어이다.
하이퍼미디어는 텍스트와 이미지, 음성, 영상 등 다양한 미디어를 하이퍼링크로 연결해 구성한 시스템을 말한다.

하이퍼미디어에서는 사용자가 스스로 링크를 선택해서 비선형적으로 정보를 습득하게 된다.

웹은 인터넷을 이용한 하이퍼미디어로 설계되었다.
인터넷을 사용한다는 점이 기존의 하이퍼미디어와 달랐고, 불특정 다수의 정보를 서로 연결하고, 시스템을 확장하기 쉬웠다.

하지만 인터넷을 사용한다는 것은 정보의 집중적 관리가 어려워지고, 연결이 끊어지기 쉽다는 단점을 가지고 있긴 하다.

하지만 단점보다는 장점이 더 크기 때문에 웹이 지금처럼 보급되었다.

즉, 개방된 네트워크 환경에서 불특정 다수를 상대로 하는 시스템이 웹이고,

이는 클라이언트와 서버의 통신을 항상 HTTP라는 간단한 프로토콜을 이용하기 때문에 실현되었다.

 

웹의 핵심 아키텍처 스타일은 REST이다.

REST는 웹 네트워크 시스템 아키텍처 스타일이다.

주의할 점은 아키텍처 스타일은 구현이나 아키텍처가 아니다.

구현을 추상화한 것이 아키텍처이고, 아키텍처를 추상화한 것이 아키텍처 스타일이다.

아키텍처 스타일은 아키텍처를 어떻게 설계할 것인지에 대한 가이드라고 보면 된다.
그리고, REST는 복수의 아키텍처 스타일을 조합한 복합 아키텍처 스타일이다.

웹은 HTTP라는 프로토콜을 이용해 클라이언트와 서버가 서로 통신하는 클라이언트/서버의 아키텍처 스타일을 채택하고 있다.
클라이언트/서버 아키텍처 스타일은 하나의 컴퓨터에서 모든 것을 처리하지 않고

클라이언트와 서버로 분리해서 처리할 수 있다는 장점이 있다.

클라이언트/서버 아키텍처 스타일에 몇가지 제약을 더 추가한 것이 REST아키텍처 스타일이다.
REST아키텍처 스타일은 먼저 클라이언트/서버 아키텍처에 스테이트리스 서버 아키텍처 스타일을 추가한다.
스테이트리스라는 것은 클라이언트의 애플리케이션 상태를 서버에서 관리하지 않는다는 것이다.
서버는 클라이언트 요청에 응답한 뒤 서버의 자원을 해제할 수 있다는 장점을 가지고 있다.
하지만, 로그인이 필요한 서비스 등 상태 관리가 필요한 경우도 있어서 이런 경우 Cookie를 이용하게 되는데,

Cookie를 이용한 세션 관리는 HTTP를 stateful하게 만들고, 스테이트리스 서버의 이점을 버리므로 최소한으로 이용해야 한다.

스테이트리스 서버를 이용할 때 아키텍처 스타일을 클라이언트/스테이트리스 서버라고 한다.

 

클라이언트/스테이트리스 서버 스타일에 캐시를 추가하게 되면 클라이언트/캐시/스테이트리스 서버 아키텍처 스타일을 갖게 된다.

캐시는 리소스를 한 번 가져온 뒤로 클라이언트 쪽에서 기존의 리소스를 신선도에 기반해서 이용하는 방식이다.

캐시를 이용하면 클라이언트와 서버 사이의 통신량을 줄여 처리시간을 줄이고 효율적으로 처리할 수 있다는 장점이 있다.

하지만 오래된 캐시를 이용하는 것은 정보의 신뢰성이 떨어질 수 있기 때문에 주의해야 한다.

 

클라이언트/캐시/스테이트리스 서버 스타일에 유니폼 인터페이스를 추가하게 되면

유니폼/클라이언트/캐시/스테이트리스 서버 아키텍처 스타일이 된다.

유니폼 인터페이스는 URI로 지정한 리소스에 대한 조작을 통일성있는 인터페이스로 수행하는 아키텍처 스타일이다.

HTTP1.1은 8개의 메소드만 사용해야 한다는 제약이 있고,

인터페이스의 유연성을 제한함으로써 전체적인 아키텍처가 간결해진다.

 

계층화 시스템은 시스템을 몇 개의 계층으로 분리하는 아키텍처 스타일이고,

유니폼 인터페이스를 사용하게 되면 서버나 프록시 등 각 컴포넌트 간 인터페이스를 HTTP로 통일하게 되기 때문에

모두 동일한 인터페이스를 사용해서 계층화하기 쉬워진다.

유니폼/클라이언트/캐시/스테이트리스 서버 스타일에 계층화 시스템을 추가한 아키텍처 스타일을 유니폼/계층화/클라이언트/캐시/스테이트리스 서버 라고 한다.

 

코드 온 디맨드는 프로그램 코드를 서버에서 다운받아 클라이언트에서 실행하는 아키텍처 스타일이고, 선택적으로 사용하면 된다.

코드 온 디맨드 아키텍처 스타일을 추가하면 유니폼/계층화/코드 온 디맨드/클라이언트/캐시/스테이트리스 서버 스타일이 된다.

코드 온 디맨드는 네트워크 통신에서 프로토콜 가시성이 저하된다는 결점이 있지만, 클라이언트를 차후에 확장할 수 있게 된다.

 

각각의 아키텍처 스타일을 아래와 같이 요약할 수 있다.

클라이언트/서버: 유저 인터페이스와 처리를 분리한다.

스테이트리스 서버: 서버 측에서 애플리케이션의 상태를 가지지 않는다.

캐시: 클라이언트와 서버의 통신횟수와 양을 감소한다.

유니폼 인터페이스: 인터페이스를 통일한다.

계층화 시스템: 시스템을 계층 별로 분리한다.

코드 온 디맨드: 프로그램을 클라이언트에 다운로드하여 실행한다.

그리고 이 아키텍처 스타일들이 합쳐진 ULCODC$SS 아키텍처 스타일을 REST 아키텍처 스타일이라고 부른다.

 

REST이전의 분산 시스템은 함수나 메서드 단위로 서버 쪽의 처리를 호출했기 때문에 오버헤드가 심하고,

호출 횟수가 많아질수록 시스템 전체 성능이 저하됐다.

하지만 REST에 기반한 웹 서비스는 리소스를 링크로 연결하여 하나의 애플리케이션을 구성하도록 하고,

리소스는 그 자체로 의미를 가진 하나의 데이터이고, 입도가 크기 때문에 REST 스타일을 이용하면 전체적인 성능 저하를 억제할 수 있다.

또한 REST에 기반을 두면 유니폼 인터페이스에 의해 인터페이스가 고정되어 업데이트를 하더라도 호환성 문제가 발생하지 않는다.

따라서 REST 아키텍처 스타일을 최대한 지키는 것이 중요하다.

 

URI는 뭘까?

리소스는 웹상에 존재하는 이름을 가진 모든 정보이다.

URI는 리소스 이름이고, 수명이 길고, 브라우저 검색창에 표시되므로 매우 중요하다.

URI로 리소스가 같은 리소스인지 구분이 되고, URI를 이용해서 리소스가 표현하는 정보에 접근할 수 있다.
또한 URI는 구조를 가지기 때문이 리소스를 간단히 가리킬 수 있는 어드레스 가능성을 가지고 있다.

 

URI로 리소스에 접근하기 때문에 URI는 매우 중요한데,

기억하기 쉽고 사용하기 쉬운, 간단하고 좋은 URI를 Cool URI라고 부른다.

Cool URIs don't change라는 웹 페이지가 만들어질 때는 웹 페이지의 URI가 바뀌는 일이 많았는데,

웹은 리소스끼리 링크로 연결된 하이퍼미디어 시스템이기 때문에

URI가 바뀐다는 것은 하이퍼미디어 시스템이 동작하지 않는다는 심각한 문제였다.

 

따라서 URI가 변하지 않을 수 있어야 좋은 URI이다.

URI가 바뀌지 않으려면 프로그래밍 언어에 의존적인 부분(확장자 등)을 배제해야하고,

구현에 의존적인 부분(servlet 등)을 제외해야하고,

메서드명이나 세션id를 포함하면 안된다.

만약 어쩔 수 없이 URI를 바꿔야 한다면 redirection을 최대한 이용해야 한다.

또한 URI는 리소스의 식별자이기 때문에 명사여야 한다.

또한 메서드를 URI에 드러내지 말고 HTTP 메서드를 이용해야 한다.

이 때 만약 하나의 리소스가 여러 언어나 형식으로 표현되는 등 복수의 표현을 가진다면

리소스의 표현을 나타내는 URI에 '.ko'나 '.html'등의 확장자를 사용하여 여러 표현을 나누는 것은 바람직하다.

 

리소스는 어떻게 설계할까?

리소스를 설계할 때는 리소스 지향 아키텍처를 사용할 수 있다.

리소스 설계란 웹 서비스와 웹 API의 인터페이스 설계를 가리키는데,

리소스를 어떻게 분할하고 어떻게 URI로 이름을 붙이고,

어떻게 하이퍼링크를 가지게 할 지가 리소스의 설계의 핵심이 된다.

이 때 주의할 점은 같은 기술을 사용하는 웹상의 리소스인 웹 서비스와 웹 API를 나누어 생각하지 말아야 한다는 것이다.

 

리소스를 설계할 때는 리소스의 표현, 리소스 조작 방법, 리소스와 리소스의 링크 관계를 설계 해야 하는데,

리소스 설계 지침인 리소스 지향 아키텍처의 설계 방법의 순서는 아래와 같다.

1. 웹 서비스에서 제공할 데이터를 특정한다.

2. 데이터를 리소스로 나눈다.

 

그리고 각 리소스에 대해 다음 작업을 수행한다.

3. 리소스에 URI로 이름을 붙인다.

4. 클라이언트에 제공할 리소스의 표현을 설계한다.

5. 링크와 폼을 이용해 리소스와 리소스를 연결한다.

6. 이벤트의 표준적인 코스를 검토한다. 

7. 에러에 대해 검토한다.

 

RESTful한 웹서비스는 어드레스 가능성, 접속성, 유니폼 인터페이스, 스테이트리스성을 갖추고 있다.

어드레스 가능성은 URI만 있으면 리소스를 항상 취득할 수 있는 성질이다.

접속성은 리소스를 링크로 접속해서 어플리케이션을 이용할 수 있는 성질이다.

유니폼 인터페이스는 인터페이스가 통일되어 있다는 특성이다.

스테이트리스성은 서버가 클라이언트의 상태를 기억하고 있지 않다는 특성이다.

리소스 지향 아키텍처는 위 특성들을 갖추고 있기 때문에 리소스 지향 아키텍처의 설계 방법에 따라 리소스를 설계하는 것이 중요할 것 같다.

 

이 책에는 웹과 관련된 기술들에 관한 개념과 웹 서비스를 어떻게 설계하면 좋을지에 대한 내용들이 자세히 나와있다.

RESTful한 웹 서비스를 만드는 게 중요하다는 말을 정말 많이 들어봤는데,

개발할 때 책의 내용들을 적용해서 RESTful한 웹 서비스를 만들면 좋을 것 같다.