웹 서비스 구조 확장

Network - 웹 서비스 구조 확장

목차

• Network - 웹 서비스 구조 확장
  • HTTP 1.0 시절 웹 서비스 통신
    • 클라이언트와 서버의 통신의 근간
  • 정적인 문서에 동적 요소를 추가 - JavaScript
    • JavaScript는 서버에서 생성되지만 클라이언트에서 실행된다(중요)
      • CORS에 대해서
  • WAS(Web Application Server)와 MVC 아키텍처의 등장
  • 서버에서 View 의존성이 제거되다
• 참고 자료

HTTP 1.0 시절 웹 서비스 통신

버너스리가 고안한 HTML 문서는 화면에 필요한 정보를 구조화하여 보여줄 수 있는 최초의 기술이었다. 이를 통해, 사람들은 데이터를 문서에 작성하고, 이후에 이미지가 추가되며, 디자인을 입히는 CSS가 추가되기도 하였다. 어쨌든, 이러한 정적 파일을 사용자가 요청하면 반환할 수 있는 시스템이
필요했으며 이를 웹 서버가 도맡았다.

또한, 이들은 HTTP라는 비연결성(Stateless) 통신을 하였는데, 아이러니하게도 HTTP의 기반이 되는 통신 기술인 TCP/IP는 연결성 통신을 한다는 것이다. 따라서 초기 HTTP 버전(1.0)에서는
매번 요청과 응답이 끝날 때마다, TCP 연결이 종료되었기에 웹 페이지가 복잡해지고 다수의 요청이 발생할 경우, 속도가 느려졌다.

(https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x)

위 사진에서 첫 번째 사진이 초기 HTTP 통신이었으며, 두 번째 사진이 Persistent Connection이라는 하나의 TCP 연결로 복잡한 HTTP 요청/응답을 주고 받는다는 개념이다. (HTTP 1.1)

클라이언트와 서버의 통신의 근간

우리가 웹 서비스를 구축하고, 운영할 때 기본적으로 알아야 할 사항은 다음과 같다.
앞으로 확장될 웹 서비스 구조에서도 변함없는 사실이기도 하다.

1. 클라이언트는 서버에게 Resource를 요청한다. 여기서 Resource란 서버에서 생성하고 관리하는 자원을 뜻한다.
2. 서버는 요청받은 클라이언트의 메시지를 바탕으로 적절한 Resource를 응답한다.

React, Vue와 같이 브라우저에서 동적으로 렌더링하는 기술이 발전하였음에도 서버에서 정적인
파일을 클라이언트에게 반환한다는 사실을 변하지 않고 있다. 따라서 이러한 개념은 가장 기본적이면서도 웹 서비스를 이해하는데 필수적이라고 생각한다.

정적인 문서에 동적 요소를 추가 - JavaScript

HTML, CSS, Image를 통해 각 문서(웹 페이지)를 구조화하고, 다양한 이미지를 통해
정보를 제공하는 것이 가능해졌다. 하지만 이러한 요소들이 추가될수록, 정적인 문서의 한계는
커져만 갔을 것이다.

정적인 요소가 계속해서 추가되는 것이 아니라 특정 버튼을 눌렀을 때, 정적인 요소가 나타나는 것과 같이 웹 문서에 동적인 작업을 추가하는 것이 필요해졌다. 이러한 작업들을 일종의 규칙(스크립트)을 정해 문서에 정의하고, 이를 브라우저에서 해석하여 실행할 수 있도록 하였다.
이로써 Resource에 JavaScript가 추가되었다.

JavaScript는 서버에서 생성되지만 클라이언트에서 실행된다(중요)

이제 서버는 HTML, CSS, Image 그리고 JavaScript를 클라이언트에게 Resource로 전달하게 되었다. JavaScript도 여전히 Resource의 한 종류이기 때문에 이를 관리하는 것은 서버이다.
하지만 JavaScript가 물리적으로 실행되는 공간은 클라이언트이다. 즉, 웹 페이지가 동적으로 변하는 규칙(스크립트)을 정의한 Resource는 서버에서 관리하되, 이것이 실제 실행되는 곳은 해당 Resource를 전달받은 클라이언트의 웹 브라우저라는 것이다. 이는 CORS를 이해하는 데에 매우 중요한 개념이다.

CORS에 대해서

A.com이라는 서버에서 만든 JavaScript가 클라이언트에게 전달되었다고 하면, 클라이언트가 받은 JavaScript의 출처는 A.com이다. 그런데 만약, A.com으로부터 전달받은 JavaScript를 통해 다른 도메인의 API를 호출하는 작업을 수행하면 어떻게 될까? 이는 보안상의 큰 문제가 될 수 있다.

만약, A.com을 만든 개발자가 B.com이라는 곳에 악의를 품고, B.com의 특정 API에 요청을 보내는 JavaScript를 만들었다고 하자. 그러면 A.com에 접속하는 사용자는 B.com에 API 요청을 보내는 코드가 담긴 JavaScript 파일을 받게 될 것이다. 즉, A.com에 접속한 사용자는 B.com에 API 요청을 보낼 수 있게 된다. 만약, B.com과의 세션이 유지되고 있는 사용자가 A.com에 접속했다면, A.com에서 작성한 악의적인 JavaScript 코드로 인해 사용자가 의도하지 않은 요청을 보낼 수도 있을 것이다. 이는 보안상의 큰 문제가 될 수있다.

따라서 기본적으로 브라우저는 SOP(Same Origin Policy) 정책을 수행하고 있다. 이는 JavaScript가 생성된 Origin(프로토콜 + 도메인 + 포트)과 다른 곳에 요청을 보낼 경우, 이를 거부하는 정책이다. 이를 통해 앞서 언급한 것과 같은 보안 문제를 해결하는 것이다.

CORS는 Cross Origin Resource Sharing으로 전달받은 JavaScript가 생성된 Origin이 아닌 다른 곳으로 요청을 보내는걸 허용하는 것이며, 이는 다른 서버 측에서 CORS 관련 헤더를 사용자에게 전달함으로써 허용할 수 있다. (위 예시대로라면 B.com에서 CORS 관련 헤더에 A.com을 지정하는 것)

그러면 다시 돌아와서 JavaScript는 서버에 생성되지만 클라이언트에서 실행된다라는게 시사하는 바가 무엇인지 정리해보자.

• JavaScript를 생성한 곳과 실행되는 곳이 다를 수 있다.
  • JavaScript를 통해 여러 클라이언트의 요청을 조작할 수 있는 위험이 발생한다.
    • 이를 방지하기 위한 브라우저의 정책 중 SOP가 있으며, 이를 부분적으로 허용하는 것이 CORS이다.

이처럼 JavaScript가 생성되는 곳과 실행되는 곳이 다르다는 점을 통해 SOP와 CORS를 이해할 수 있다.

WAS(Web Application Server)와 MVC 아키텍처의 등장

WebServer는 사용자가 요청한 Resource를 전달하는 용도로 사용되었다. 하지만 이제는 사용자가 직접 값을 입력해서 서버에 전달하는 행위(POST Method)가 추가되었다. 서버는 사용자가 전달한 값을 100% 신뢰해서는 안된다. 반드시 요청한 값에 대한 검증을 해야한다. 하지만 기존의 WebServer는 저장되어 있는 Resource를 전달하기만 했기에 이러한 입력 값을 처리하는 새로운 요소가 필요하게 되었다. 이러한 작업을 하는 프로그램(Application)을 개발하게 되고, 이것을 서버(Server)에 올리게 되며 이는 웹(Web)에서 구동된다. 이것이 WAS의 등장이다.

이제 WebServer 뒷 단에 WAS 그리고 데이터 영속화를 담당하는 DB까지 존재하게 되었다.
그러면 WAS는 앞 쪽에서는 정적인 Resource를 전달하는 WebServer, 뒤 쪽에서는 데이터를 전달하는 DB와 연결되어 있다.

즉, WAS는 앞 쪽(WebServer)과는 사용자 화면과 관련된 View 로직을 처리하고, 뒤 쪽(DB)과는 각 사용자가 갖고 있는 고유의 데이터가 담긴 Model 로직을 처리한다. 그리고 각 사용자별로 어떠한 요청을 하느냐에 따라 특정 코드가 실행되도록 하는 제어체계 Controller 로직도 처리해야 한다. 이렇게 WAS는 세 가지 영역을 담당하게 되는데, 이들을 각각 모듈화한 MVC가 적용되어 있다.

WAS의 등장으로 더 이상 단방향 통신이 아닌 양방향 통신으로 웹 서비스는 변화하게 된다. 이제 서버는 사용자가 요청한 Resource만 전달하는 것이 아니라 사용자와 상호작용을 통해 상태를 영구적으로 저장(DB)하기도 하고, 요청에 따라 사용자의 상태를 전달하기도 한다. 하지만 HTTP는 Stateless라는 특징이 있기에 프로토콜 단에서는 상태를 저장할 수 없기에 클라이언트가 자신의 상태를 전달하는 쿠키가 등장하기도 했다. 이처럼 프로토콜 단에서 상태를 보장하지 않기에 클라이언트와 서버가 웹 상에서 상태를 다룰 수 있는 다양한 장치가 등장하게 된다.

서버에서 View 의존성이 제거되다

서버에서 일명 3-Tier(웹 서버, WAS, DB를 각각 1개의 Tier라고 했을 때 이 구조를 3-Tier라고 한다) 구조가 성립되었을 때, 클라이언트 단에서도 많은 변화가 일어나게 된다.
기존에는 서버 측에서 웹 문서를 생성하여 전달하였고, 웹 브라우저는 이를 구조화하고, 렌더링하여 JS 엔진을 통해 JavaScript를 실행했었다.
하지만 PC, 모바일, 태블릿 등 인터넷 기기의 다양화에 따라 각 기기에 맞는 문서를 생성해야 되는 일종의 View 의존성이 서버 측에서 생기게 되었다. 사실 사용자가 보는 웹 문서에서의 핵심은 문서가 아닌 데이터다. 따라서 서버는 어떻게 하면 사용자에게 데이터를 전달할 수 있을지에만 집중할 수 있었고, JavaScript의 발전으로 서버가 아닌 웹 브라우저 환경에서 HTML 같은 문서를 동적으로 생성할 수 있게 되었다. (대표적으로 JS 기반 React, Vue가 있다)

참고 자료

1. 면접 전에 알고 가면 좋을 것들