Web Server
- Client(browser)로부터 요청을 받았을 때, 정적 페이지를 전달해 주는 역할을 한다.
- Apache, Nginx
Web Application Server
- 흔히 줄여서 WAS 라고 부르기도 한다.
- 백엔드 서버라고 이해하면 편할 듯하다. (비즈니스 로직 수행 후 데이터 전달)
- SpringBoot에서는 Tomcat을 내장서버로 가지고 있고, 이를 WAS라고 부른다.
- WAS 는 사실 Web Server의 역할도 수행할 수 있다.
개념은 위와 같다. 그렇다면 예시를 통해, 각자 무슨 역할을 하는지 조금 더 자세히 알아보자!
정적, 동적 파일 전달하기
예시) https://www.naver.com 에 접속한다면 무슨 일이 일어날까?
(사실 설명하는 것 외에 많은 일이 일어나겠지만 지금은 Web Server, WAS의 역할에만 집중해 보자.)
정적 파일 전달
먼저, Web Server가 정적 파일을 브라우저에게 전달한다. 동적인 파일을 전달하는 경우는 몇 가지 방법이 있는데, 아래의 내용을 참고해 보자.
동적 파일 전달
SSR (Server Side Rendering)
- WAS 서버에서 렌더링을 마친 후, 완성된 정적 페이지를 브라우저에 전달하는 기법
CSR (Client Side Rendering)
- 뼈대 HTML 페이지와 js 코드를 보내고, 이후에 브라우저에서 js 코드를 실행해 HTML 페이지를 완성시키는 방법
사실 위의 개념을 이해하는 데 시간이 많이 걸렸다. 내가 느끼기에는 꽤 어려운 개념이라 생각해 그림으로 쉽게 이해해 보자!
SSR 예시
위와 같은 흐름으로 진행이 된다.
필자가 헷갈렸던 부분은 동적 페이지가 어디서 완성되는지가 매우 헷갈렸었다. WAS에서 동적 페이지를 완성시키는 건지, Web Server에서 동적 페이지를 완성시키는지 헷갈렸다. 서버 사이드 렌더링이라고 하니, Web Server에서 동적 페이지를 완성시킬 수도 있지 않을까?
-> Web Server에는 동적 페이지를 완성시켜 주는 기능이 따로 없다. 즉, SSR 방식을 사용한다고 할 경우, WAS에서 동적 페이지를 완성시킨다.
필자는 보통 프론트 개발자 / 백엔드 개발자가 나뉘어 있는 환경에서 개발을 해왔다. 이런 상황에서 SSR은 어떤 식으로 이루어질까?
방법 1
SpringBoot에서 동적 페이지 완성 시키기
첫 번째는 기존과 같은 방법일 것이다. 다만 이 경우 SpringBoot 환경에서 정적페이지를 만들어야 하는 책임 또한 가지고 있기에, 서버의 부담이 커질 수 있다.
방법 2
서버 책임을 분리하기
새로운 WAS 서버를 하나 더 도입해 정적 페이지를 완성시킬 수도 있을 것이다. 다만 방법 2의 경우 서버의 책임이 분리되어 있지만, 아키텍처가 복잡해지고 프로젝트 자체가 무거워진다는 단점 또한 존재한다.
SSR 방식의 장점은 뭐가 있을까?
방법 1, 2 전부 명확한 단점이 존재하는데 꼭 SSR을 사용해야 할까?
- SSR 방식은 완성된 정적 페이지가 전달되기에 검색 엔진 최적화와 초기 로딩 속도가 향상된다고 한다. 무작정 CSR를 사용해야 돼!라는 생각은 옳지 않은 것 같고, 비즈니스 요구사항을 토대로 어떤 방식을 선택할지 고민이 필요한 부분인 것 같다.
CSR 예시
CSR의 경우, 위에서 설명했듯이 뼈대만 가지고 있는 HTML을 우선 만든 다음에, 이후 browser에서 js 코드를 실행시켜 정적 페이지를 만든다. CSR의 경우, 아키텍처가 SSR에 비해 단순해지고 책임 분리가 명확한 것을 확인할 수 있다.
위에서도 학습하는 과정에서 4,5번이 헷갈렸다. Browser -> Web Server -> WAS와 같은 순서로 Web Server를 거쳐서 데이터 요청을 보낼 줄 알았는데, Browser에서 직접 WAS 서버로 데이터 요청을 하는 모습을 확인할 수 있다. 하지만 얼핏 듣기로는 Web Server는 Browser의 요청을 받아 WAS 서버에 작업을 전달해 주는 역할을 한다고 했는데.. 이 이야기는 뭘까?
Web Server의 추가적인 역할
Web Server는 정적 페이지 전달 외에도 다양한 역할을 수행할 수 있다.
예를 들어, WAS를 외부에 직접 노출하는 것은 보안이나 구조적 이유로 바람직하지 않을 수 있다. 이 경우 Web Server가 브라우저로부터 요청을 받아, 내부 네트워크에 있는 WAS로 요청을 전달하고 응답을 다시 클라이언트에게 전달하는 방식이 사용된다. 이러한 기능을 Reverse Proxy라고 한다. 말로 하면 어려울 수 있으니, 이것도 그림을 통해 이해해 보자.
위와 같이 Browser는 Web Server에게 요청을 보내고, Web Server는 WAS에게 요청을 보낸다. 응답도 마찬가지다.
보통 웹서버는 Apache, Nginx를 사용한다고 하는데, 이 기술들 말고 다른 건 없을까?
주변 프런트엔드 개발자분들에게 물어본 결과, 상황에 따라 다른 것 같다. 단순히 정적 페이지만 전달할 목적이라면 S3를 웹서버로 사용하는 경우가 많은 것 같다. 다만 이 경우에는 Load Balancer, Reverse Proxy 같은 부가의 웹서버 기능을 사용할 수 없다. 그에 비해, Reverse Proxy를 도입하고 보안을 강화해야겠다! 하는 경우에는 Nginx 하나 띄워놓으면 좋아 보인다. 이 부분에 대해서는 나중에 프로젝트를 진행하면서 프런트 개발자분들과 소통하면서 공부를 해봐야 할 것 같다.
잘못된 부분에 대한 조언은 언제나 환영입니다!
'Web' 카테고리의 다른 글
| Web Client / Server 통신 과정 파헤치기 (0) | 2025.04.22 |
|---|
