인터넷에서 웹사이트를 이용하다 보면 웹서버(Web Server)와 WAS(Web Application Server)라는 용어를 접하게 됩니다. 서버를 처음 공부하는 사람에게는 두 가지가 비슷해 보이기 때문에 “웹서버와 WAS는 같은 것 아닌가?”라는 의문이 생길 수 있습니다.
실제로 웹서비스를 구성할 때 웹서버와 WAS는 서로 밀접하게 연결되어 사용되는 경우가 많습니다. 하지만 두 시스템이 담당하는 역할에는 차이가 있습니다.
간단하게 말하면 웹서버는 웹 콘텐츠를 전달하는 역할에 강하고, WAS는 프로그램의 실행과 동적인 요청을 처리하는 역할에 초점이 맞춰져 있습니다.
이번 글에서는 웹서버가 무엇인지, WAS란 무엇인지부터 두 기술의 차이점과 실제 웹서비스에서 어떻게 함께 사용되는지까지 초보자도 이해하기 쉽게 알아보겠습니다.
웹서버란 무엇인가?
웹서버(Web Server)는 클라이언트의 HTTP 요청을 받아 웹페이지와 같은 콘텐츠를 전달하는 서버입니다.
여기서 클라이언트는 웹브라우저를 생각하면 이해하기 쉽습니다.
사용자가 인터넷 브라우저에서 웹사이트 주소를 입력하면 브라우저는 해당 웹사이트의 서버에 요청을 보냅니다. 웹서버는 이 요청을 확인하고 필요한 웹 콘텐츠를 사용자에게 전달합니다.
대표적인 웹서버 소프트웨어로는 다음과 같은 것들이 있습니다.
- Apache HTTP Server
- Nginx
- Microsoft IIS
웹서버는 특히 정적인 콘텐츠(Static Content)를 제공하는 데 적합합니다.
정적인 콘텐츠란 요청하는 사용자에 따라 내용이 실시간으로 변경되지 않는 파일을 의미합니다.
대표적인 예로는 다음과 같은 것들이 있습니다.
- HTML 파일
- CSS 파일
- JavaScript 파일
- 이미지
- 동영상
- 기타 파일
예를 들어 웹사이트에 있는 로고 이미지 파일을 사용자가 요청하면 웹서버는 해당 이미지 파일을 찾아 사용자에게 전달할 수 있습니다.
WAS란 무엇인가?
WAS는 Web Application Server의 약자로, 웹 애플리케이션을 실행하고 동적인 요청을 처리하는 역할을 합니다.
웹서버가 단순히 파일을 전달하는 역할에 집중한다면 WAS는 프로그램을 실행하면서 요청에 따라 결과를 만들어낼 수 있습니다.
예를 들어 쇼핑몰에서 사용자가 로그인한다고 생각해 보겠습니다.
사용자가 아이디와 비밀번호를 입력하면 단순히 HTML 파일 하나를 전달하는 것으로 작업이 끝나지 않습니다.
사용자가 입력한 정보를 확인하고 데이터베이스에서 회원 정보를 조회한 다음 로그인 가능 여부를 판단해야 합니다.
이처럼 사용자의 요청에 따라 프로그램이 실행되고 결과가 달라지는 작업을 처리할 때 WAS가 사용될 수 있습니다.
WAS의 대표적인 예로는 다음과 같은 제품이나 기술이 있습니다.
- Apache Tomcat
- JBoss / WildFly
- WebLogic
- WebSphere
특히 Java 기반 웹 애플리케이션에서는 Tomcat을 많이 접하게 됩니다.
웹서버와 WAS의 가장 큰 차이
웹서버와 WAS의 차이를 가장 쉽게 이해하는 방법은 정적인 콘텐츠와 동적인 콘텐츠의 차이를 알아보는 것입니다.
웹서버
웹서버는 이미 만들어져 있는 콘텐츠를 빠르게 전달하는 데 적합합니다.
예를 들어 다음과 같은 파일을 전달할 수 있습니다.
index.html
style.css
logo.png
사용자가 해당 파일을 요청하면 웹서버가 파일을 찾아 전달합니다.
WAS
WAS는 요청에 따라 프로그램을 실행하고 결과를 만들어낼 수 있습니다.
예를 들어 사용자가 쇼핑몰에서 특정 상품을 검색하면 WAS가 검색 조건을 처리하고 데이터베이스에서 필요한 정보를 조회한 뒤 결과를 만들어 사용자에게 전달할 수 있습니다.
따라서 간단하게 정리하면 다음과 같습니다.
| 구분 | 웹서버 | WAS |
|---|---|---|
| 주요 역할 | 웹 콘텐츠 제공 | 웹 애플리케이션 실행 |
| 정적 콘텐츠 | 적합 | 처리 가능하지만 주 역할은 아님 |
| 동적 콘텐츠 | 제한적 | 적합 |
| 주요 처리 | 파일 전달 | 프로그램 실행 및 로직 처리 |
| 대표적인 예 | Apache, Nginx, IIS | Tomcat, WebLogic, WildFly |
다만 실제 제품의 기능은 서로 겹칠 수 있기 때문에 이 표를 절대적인 구분으로 이해하기보다는 각 기술이 주로 담당하는 역할을 비교한 것으로 이해하는 것이 좋습니다.
정적 콘텐츠와 동적 콘텐츠의 차이
웹서버와 WAS를 이해하려면 정적 콘텐츠와 동적 콘텐츠의 차이를 알아두는 것이 중요합니다.
정적 콘텐츠
정적 콘텐츠는 미리 만들어져 있는 파일을 그대로 사용자에게 제공하는 방식입니다.
예를 들어 회사 홈페이지에 있는 회사 로고나 특정 안내 페이지가 있다고 생각해 보겠습니다.
사용자가 페이지를 요청하면 서버는 저장되어 있는 HTML이나 이미지 등의 파일을 전달합니다.
사용자마다 결과가 크게 달라지지 않는다면 정적 콘텐츠라고 생각할 수 있습니다.
동적 콘텐츠
동적 콘텐츠는 사용자의 요청이나 상황에 따라 결과가 달라집니다.
예를 들어 쇼핑몰에서 로그인한 사용자의 이름을 보여주거나, 특정 사용자의 주문 내역을 표시하는 경우가 있습니다.
이러한 작업은 단순히 파일 하나를 전달하는 것으로 해결하기 어렵습니다.
프로그램이 사용자의 요청을 처리하고 필요한 데이터를 조회한 후 결과를 만들어야 합니다.
이때 WAS와 데이터베이스가 함께 사용될 수 있습니다.
웹서버와 WAS는 왜 함께 사용할까?
그렇다면 웹서버와 WAS를 하나만 사용하지 않고 함께 사용하는 이유는 무엇일까요?
가장 큰 이유 중 하나는 역할을 분리하여 웹서비스를 효율적으로 운영하기 위해서입니다.
예를 들어 사용자가 웹사이트에 접속했다고 가정해 보겠습니다.
웹페이지에 필요한 이미지나 CSS 파일은 웹서버가 빠르게 전달하고, 사용자의 로그인이나 상품 검색처럼 프로그램 실행이 필요한 요청은 WAS가 처리하도록 구성할 수 있습니다.
구조를 단순하게 표현하면 다음과 같습니다.
사용자 → 웹서버 → WAS → 데이터베이스
사용자가 요청을 보내면 먼저 웹서버가 요청을 처리합니다.
정적인 파일이라면 웹서버가 직접 응답할 수 있습니다.
반대로 프로그램 실행이 필요한 요청이라면 WAS로 요청을 전달하고, WAS가 필요한 작업을 처리합니다.
필요한 경우 WAS는 데이터베이스에서 데이터를 조회한 후 결과를 만들어 웹서버 또는 사용자에게 전달합니다.
웹서버와 WAS를 분리하면 어떤 장점이 있을까?
웹서버와 WAS를 분리해서 운영하면 여러 가지 장점이 있습니다.
1. 역할을 나눌 수 있다
웹서버는 웹 콘텐츠 전달에 집중하고 WAS는 애플리케이션 처리에 집중할 수 있습니다.
각 시스템이 자신에게 적합한 작업을 담당하도록 구성할 수 있습니다.
2. 보안을 강화할 수 있다
외부에서 직접 접근해야 하는 부분과 내부에서 애플리케이션을 처리하는 부분을 분리하면 네트워크 구조를 설계하기가 편해집니다.
예를 들어 WAS를 외부 인터넷에 직접 노출하지 않고 웹서버 뒤에 배치하는 방식으로 구성할 수도 있습니다.
3. 서버 확장이 편리해질 수 있다
사용자가 많아지면서 애플리케이션 처리량이 증가하면 WAS를 여러 대로 구성하는 방식을 사용할 수 있습니다.
이러한 구조에서는 로드밸런서를 활용하여 여러 WAS에 요청을 분산시키기도 합니다.
4. 장애 대응에 유리할 수 있다
시스템을 역할별로 분리하면 문제가 발생했을 때 어느 부분에서 문제가 발생했는지 파악하기가 상대적으로 쉬워집니다.
물론 실제 장애 대응 효과는 전체 시스템의 설계와 구성에 따라 달라집니다.
웹서버 없이 WAS만 사용할 수 있을까?
기술적으로는 가능합니다.
일부 WAS는 웹 요청을 직접 처리할 수 있는 기능을 제공합니다.
따라서 작은 프로젝트나 개발 환경에서는 별도의 웹서버 없이 WAS만 사용하는 경우도 있습니다.
하지만 실제 서비스 환경에서는 웹서버와 WAS를 분리해서 구성하는 경우가 많습니다.
웹서버를 앞단에 배치하면 정적 콘텐츠 처리, 보안 설정, SSL/TLS 처리, 요청 분산 등 다양한 기능을 별도로 구성할 수 있기 때문입니다.
다만 어떤 구조가 적합한지는 서비스 규모와 사용하는 기술, 보안 요구사항, 운영 환경 등에 따라 달라집니다.
웹서버와 WAS의 관계를 쉽게 이해하는 방법
웹서버와 WAS의 관계를 식당에 비유하면 조금 더 쉽게 이해할 수 있습니다.
식당 입구에서 손님의 주문을 받고 주방으로 전달하는 역할이 웹서버라고 생각할 수 있습니다.
그리고 실제로 주문 내용을 확인하고 음식을 조리하는 주방의 역할을 WAS에 비유할 수 있습니다.
손님이 단순히 물이나 메뉴판을 요청한다면 입구에서 바로 제공할 수 있습니다.
하지만 주문을 받아 실제 음식을 만들어야 한다면 주방의 작업이 필요합니다.
웹서비스에서도 비슷하게 정적인 파일은 웹서버가 바로 제공할 수 있고, 복잡한 프로그램 처리가 필요한 요청은 WAS가 처리할 수 있습니다.
물론 실제 웹 시스템은 식당보다 훨씬 복잡하며, 데이터베이스나 캐시 서버, 로드밸런서 등 다양한 시스템이 추가될 수 있습니다.
웹서버와 WAS를 공부할 때 알아두면 좋은 개념
웹서버와 WAS를 제대로 이해하려면 몇 가지 관련 개념도 함께 공부하는 것이 좋습니다.
먼저 HTTP와 HTTPS를 이해하면 웹 브라우저와 서버가 어떤 방식으로 통신하는지 알 수 있습니다.
그다음에는 다음 개념을 공부해 보는 것을 추천합니다.
- HTTP 요청과 응답
- IP 주소
- 포트
- DNS
- 웹서버
- WAS
- 데이터베이스
- 로드밸런서
- 리버스 프록시
- SSL/TLS
- 세션과 쿠키
특히 리버스 프록시(Reverse Proxy)는 웹서버와 WAS의 관계를 이해하는 데 도움이 되는 개념입니다.
Nginx 같은 웹서버를 리버스 프록시로 구성하고 뒤쪽에 여러 WAS를 배치하는 방식도 실제 웹서비스에서 활용됩니다.
마무리
웹서버와 WAS는 모두 웹서비스를 구성하는 중요한 기술이지만 담당하는 역할에는 차이가 있습니다.
웹서버는 웹 콘텐츠를 전달하는 역할에 초점이 있고, WAS는 웹 애플리케이션을 실행하여 동적인 요청을 처리하는 역할에 초점이 있습니다.
쉽게 정리하면 다음과 같습니다.
웹서버 = 웹 콘텐츠 전달
WAS = 웹 애플리케이션 처리
실제 서비스에서는 웹서버와 WAS를 함께 구성하는 경우가 많으며, 여기에 데이터베이스와 로드밸런서, 캐시 등의 시스템이 추가될 수 있습니다.
서버를 처음 공부하는 단계라면 웹서버와 WAS의 차이를 단순히 외우기보다는 사용자가 요청을 보냈을 때 어떤 과정을 거쳐 최종 결과가 만들어지는지를 이해하는 것이 중요합니다.
다음 단계에서는 웹서버와 WAS 사이에서 HTTP 요청이 실제로 어떻게 전달되는지, 그리고 Nginx와 Tomcat을 함께 구성하면 어떤 구조가 되는지를 공부하면 서버 구조를 이해하는 데 더욱 도움이 됩니다.
답글 남기기