[Web] Web Server & Web Application Server

오늘 할 얘기는 서버라는 말을 좀 집중적으로 파볼건데, 최근 인프라에 대해서 좀 알아보다보니, 내가 잘못 이해하고 있던 것들이 꽤나 있어서 이 부분을 제대로 정리하고 넘어갈 예정이다. 

위에 있는 그림이 이제 웹 어플리케이션이 동작하는 방식을 명확히 보여주는 예시인데, 그림만 보면 그냥 골머리가 썩을거다. 웹 서버는 뭐며, 웹 어플리케이션 서버는 뭐고, 클라이언트는 무엇인가? 라는 부분에서 일단 상당한 혼란이 올 것으로 예상된다. 인프라나, NEXT.js의 SSR 기능을 잘 사용하려면 이런 부분에 대한 이해가 확실히 필요하니 한번 제대로 알아보자. 

 

1. 용어 정리

일단 시작 전에 용어 정리를 간단히 하고 넘어가도록 하자. 사실 이 혼란들은 신입, 초급 개발자 입장에서 용어를 올바른 쓰임새로 쓰지 않기 때문에 발생하는 문제들이기도 한데, Server, Client, Front-end, Back-end 얘네가 혼용돼서 그렇다고 보면 된다. 이걸 명확히 정리할거다. 

1) Server
Resource를 가지고 있고, 이 Resource를 Clinet가 요청할 때마다 전달해주는 역할을 하는 것이 서버다. 

2) Client
웹 어플리케이션에서 클라이언트는 그냥 브라우저 그 자체다. 실제로 요청을 보내는 것은 모두 브라우저가 하는 행동이기 때문에, 웹 개발 분야에서 Client라는 워딩이 나오면 브라우저(Chrome, Safari, firefox 등) 를 생각해주면 좋을 것 같다. 

3) Front-end
Client에서 사용자와 상호작용할 수 있는 화면을 보여주는 행위, 그 행위와 연관되어있는 모든 개발 영역을 프론트엔드라고 보면 될 것 같다. UI / UX 영역, 그리고 데이터를 요청하고 돌아온 데이터를 활용해 동적으로 다른 데이터를 보여줄 수 있는 영역까지 이 모든게 프론트엔드다.

4) Back-end
실제로 DataBase에 접근하고, 그 데이터들을 가공, 처리하는 비즈니스 로직에 관련한 개발 영역을 모두 Back-end라고 생각하면 될 것 같다. 

사실 이 모든 워딩들이, 잘 모르는 입장에선 경계가 상당히 모호하다고 느껴지기 때문에 혼용하는 것은 어쩔 수 없을 것이라고 생각한다. 허나, 이 정리를 통해서 명확히 경계를 지어둬야 이후에 설명하는 것들을 명확하게 따라올 수 있다. 

 

2. Server

이제 본론으로 돌아와서 Server에 대한 이야기를 할건데, 헷갈리지 않게 한가지 명확하게 짚고 넘어가야하는 것이 있다. 

Front-end 서버라고 부르는 것이 있다는 것이다. 대부분 Front-end 영역이 브라우저 내부적으로 HTML, CSS, JS를 읽어서 그 내용들을 사용자에게 보여주는 것이다보니, 막연히 Client에 집중을 하게 되는데, Front-end의 저 Resource들 역시 어떤 서버에서 받아오는 것이라고 생각해야한다. 더 자세히 이야기 해보자. 

 

1) Web Server (CSR, SSR까지 한번에 부시기)

당연하게도 개발자라면 Apache, Nginx라는 것들을 들어봤을 것이라고 생각한다. 이것들이 Web Server라고 불리는 것들인데, 이 녀석들의 역할은 HTML, CSS, JS, Image와 같은 정적자원을 전달해주는 역할을 한다. 그럼 당연히 Front-end와 연관되어있을 것이라는 생각이 자동으로 들어야한다. 

이 Web Server가 하는 일을 순서대로 잘 정리해보면, 사용자가 브라우저를 켜고 URL을 통해 원하는 웹 사이트의 주소를 입력한다. 그리고, 브라우저는 해당 주소(이게 웹 서버의 주소다.) 를 향해서 정적자원을 요청하게 된다. 그럼 이 웹 서버는 요청이 들어왔으니 모듈 번들러(Webpack)가 효율성있게 잘 정리해둔 HTML, CSS, JS 등을 브라우저에게 보내주게 되는 것이다. 

(정확하게는 3-hand-shaking이라는 방식으로 진행이 되는데 이건 브라우저 포스팅 작성할 때 예쁘게 잘 정리해보도록 하겠다. )

그러니까 즉, Front-end개발자가 개발한 Resource들을 웹 서버가 가지고 있고, Client가 요청할 때마다 그 Resource를 전달해주게 되는 것이다. 

 

이러면 CSR (Clinet Side Rendering), SSR(Server Side Rendering)을 이해하는게 상당히 쉬워진다. 일단 브라우저가 Resource를 받아온 다음 JS 인터프리터를 통해 JS를 실행하면서 비어있는 HTML을 채워주기 때문에, 클라이언트가 화면을 그려준다는 의미로 CSR이 되는 것이고, SSR의 경우엔 이미 서버에서 처리가 이뤄져 무언가 그려져있는 HTML을 전달하기 때문에,  SSR이 되는 것이다.

2) Web Application Server

WAS는 이제 Web Server가 하는 일을 넘어서 동적 컨텐츠까지 할 수 있는 서버라고 얘기하면 될 것 같다. 사실 WAS는 Web Server 와 Web Container가 합쳐진건데, 복잡하니까 간단하게 설명하자면, 우리가 Java/Spring으로 개발한 어플리케이션이 DB를 활용하고, 비즈니스 로직을 수행할 수 있는 환경을 갖춰준다고 보면 된다. Jsp/Servlet을 실행 시킬 수 있는 미들웨어 프로그램이라고 얘기하기도 하는데 어려운 말이 너무 많으니까 초급개발자 정도라면 일단 지금은 동적 처리가 가능한 환경, 그 정도로만 이해해도 괜찮을 것같다.

 

근데 요정도만 설명해도 이제 대충 감이 딱 잡힐거다. 이거 백엔드(API) 프로그램이랑 상당히 연관이 있어보인다. 웹 서버와 프론트 Resource의 관계처럼, api 주소를 향해 요청을 주면, WAS가 Back-end Resource에 해당 요청을 전달하고, 요청에 따라 처리된 값을 다시 브라우저에게 돌려주는 방식이다. 

 

 

3. 정리

자 그러면 정리를 해보자. 일단 나도 그랬고, 다른 누군가도 이렇게 착각을 하고 있을 가능성이 상당히 높을 것 같은데,

난 계속 학원 프로젝트에 갇혀서 당연히 Tomcat하나에 들어있는 웹서버, 웹 컨테이너만을 단독으로 사용한다고 생각해왔었다. 하지만 Front, Back 분리한 순간부터 아니었다는 거지..

Front, Back이 분리되어있는 프로젝트의 경우에, 브라우저는 두 가지의 서버에 접근을 한다. 왜냐면, 최초에 정적자원을 받아오기 위한 서버에 먼저 요청을 한 뒤 돌아오는 정적자원, JS 를 읽고 화면에 그려준 다음, 사용자와 UI 간 동적인 데이터 변경이 발생해야하는 상호작용이 발생하면 동적 컨텐츠를 관리하고 있는 서버에 요청을 해야하기 때문이다.