Web Server 와 WAS(Web Application Server)란 ?

 

웹 서비스를 개발하다보면 자주 WAS 라는 용어가 등장하는데요. 오늘은 WAS 라는 개념에 대해 알아보려고 합니다.

 

WAS 를 이해하기 위해서는 우선, 정적 웹페이지와 동적 웹페이지의 개념을 이해할 필요가 있습니다.

 

 

---

1. 정적 웹페이지 (Static Web Page)

• 의미: 서버에 저장된 HTML 파일 그대로 브라우저에 전달되는 페이지
• 특징:
  • 내용이 고정 → 요청할 때마다 같은 HTML 응답
  • 서버는 단순히 파일을 전달만 함 (추가 연산 없음)
  • 빠르고 가볍다
• 예시:
  • about.html, contact.html 같은 단순 정보 페이지
  • GitHub Pages, S3+CloudFront에서 배포하는 정적 사이트

---

2. 동적 웹페이지 (Dynamic Web Page)

• 의미: 요청 시점에 서버가 프로그램을 실행해서 HTML을 생성해 전달하는 페이지
• 특징:
  • 요청마다 다른 결과 → 사용자/시간/상태에 따라 달라짐
  • 서버가 DB와 통신하거나 로직 실행 후 결과를 HTML로 변환
  • 상대적으로 무겁지만 개인화/실시간 서비스 가능
• 예시:
  • 로그인 후 “OOO님 환영합니다” 라고 표시되는 대시보드
  • 쇼핑몰 상품 목록 (DB에서 불러와 동적으로 출력)
  • 게시판, 블로그 플랫폼

---

비교 정리

구분

	정적 웹페이지 (Static)	동적 웹페이지 (Dynamic)
생성 방식	미리 작성된 HTML 그대로 응답	서버가 요청마다 HTML 생성
내용 변경	HTML 파일 수정 필요	DB/서버 로직에 따라 자동 변경
서버 역할	파일 전달자	연산자 (로직 수행 + DB 연동)
속도	빠름 (캐싱 쉬움)	상대적으로 느림 (연산 비용 있음)
예시	회사 소개 페이지, 블로그 템플릿	쇼핑몰 상품 페이지, 마이페이지

 

즉, 정적 페이지는 정적 자원을 바탕으로 항상 같은 것을 보여주는 페이지이고, 동적 페이지는 요청시마다 로직을 수행해서 사용자 요청에 걸맞는 HTML 을 동적으로 생성하는 페이지라고 할 수 있습니다. 

• 정적 페이지: 고정된 HTML, 변하지 않는 정보 제공.
• 동적 페이지: 요청마다 다르게 생성, 사용자 맞춤 서비스 제공.

---

현대 SPA 웹 아키텍처? 정적 vs 동적

• 현대 SPA(React, Vue, Angular)는 정적 HTML + JS를 먼저 내려주고,
  JS가 실행되면서 API를 호출해 동적으로 화면을 채웁니다.
• 즉, 정적 + 동적의 하이브리드 구조를 많이 씁니다.
• 예:
  • /index.html 자체는 정적이지만,
  • 화면 내용(피드, 댓글, 알림)은 API 호출로 동적으로 채워집니다

 

---

웹(WEB)서버란?

 

클라이언트로부터 HTTP 요청을 받아 정적인 HTML, CSS, JS 같은 파일을 내려주는 웹 서버(예: Apache, Nginx)를 말합니다.

 

WAS(Web application Server)의 정의

반면, WAS는 정적 웹서버와 달리 동적인 요청도 처리할 수 있고 비즈니스 로직을 실행해서 결과를 반환하는 Application Server 입니다.

 

 

WAS는 전통적인 모놀리식 서버 구조에서 나온 개념인데 WAS 를 활용한 아키텍처는 프론트 웹 서버 + 백엔드 애플리케이션 실행 환경을 결합한 개념이라고 볼 수 있습니다.

 

1. 웹 서버는 정적 리소스 (HTML, CSS, JS)도 서빙하고
2. WAS 는 동적 요청(로그인, DB 조회 등)을 처리합니다.

 

예를 들어 Tomcat, WebLogic, JBoss 같은 기술은 이 자체만 띄워도 HTML, CSS, JS 같은 정적 파일을 서빙할 수 있고, 동시에 Servlet/JSP 같은 동적 요청도 처리할 수 있습니다.

 

WAS 에서의 흐름 

 

 

 

1. 웹 브라우저가 HTTP 요청을 날리면 웹 서버는 정적 파일을 빠르게 응답합니다.

2. 동적 요청(GET /users, POST /login)은 WAS로 위임합니다. 

3. WAS는 내부에서 비즈니스 로직 실행 → DB와 통신 → HTML/JSON 응답을 생성합니다.

4. 웹 서버는 이를 반환받아 웹 브라우저에게 응답합니다.

 

---

📌 FE/BE 분리 구조 vs WAS (전통적/통합 구조) 비교

현대의 일반적인 웹은 종종 FE와 BE를 아예 독립된 배포 단위로 나눈 아키텍처를 취합니다.

현대 웹 서비스에서 흔히 사용하는 방식이고 다음처럼 FE는 화면과 관련한 정적 자원 배포 + BE는 API 서버로 완전히 역할을 나누고 별도로 배포하는 방식인데요.

 

그러면 현대에 와서는 BE API 서버 = WAS 라고 볼 수 있는건가? 궁금증이 들었어요.

 

이에 대한 저의 의견은 어느정도 역할이 겹치는 부분도 있지만 완전히 같다고 하기는 어렵다는 것입니다. 

 

• WAS(Web Application Server) 는 원래 웹 서버(Web Server) + 애플리케이션 실행 환경을 합친 개념이에요.
• 예전에는 Tomcat, JBoss, WebLogic 같은 WAS가 정적 리소스 서빙 + 동적 페이지 생성 + 비즈니스 로직 실행을 한꺼번에 맡았어요.
• 따라서 현대 SPA 아키텍처에서는 BE는 “WAS에서 정적 리소스/SSR 역할을 제거한, API 전용 서버라고 보는 것이 더 정확할 것 같습니다. ( 페이지 생성은 안해주고 오로지 API만 응답하기 때문 ) 

 

 

또한, 이외에도 FE/BE 분리구조와 전통적인 WAS 간의 핵심적인 차이점은

정적 파일을 제공하는 서버와 애플리케이션 로직을 처리하는 서버를 독립적으로 배포하고

정적 자원 / API 요청이 각각 다른 서버로 요청이 가게끔 하는가 vs 모든 요청을 하나의 entry point 서버로 보내고, 거기서 정적/동적 리소스를 구분해서 정적 리소스는 바로 제공하고, 동적 요청은 WAS 로 보내어 처리하는가 라고 이해했습니다. 

 

어떻게 보면 WAS 구조는 항상 모든 요청이 웹 서버를 거쳐가야하니 바로 BE 로  동적 요청을 보낼 수 있는 구조에 비해 더 비효율적인거 아닌가? 하는 생각을 하게 되었습니다. 이게 동적 요청인 것을 판단할 수 만 있다면 애초부터 BE 서버에 API 요청을 바로 날릴 수 있으면 더 효율적이기에 이게 현대에 와서 FE/BE를 독립적으로 배포하는 이유가 아닐까 생각해보게 되었습니다. 

 

	FE/BE 분리 구조	WAS (전통적/통합 구조)
FE 역할	정적 빌드 결과물만 제공 (CDN/정적 서버)	서버에서 HTML까지 생성해서 제공
BE 역할	API 전용 서버 (JSON, GraphQL)	API + HTML + 정적 리소스 모두 처리
장점	확장성, 배포 독립, 프론트-백 분업 명확	간단한 배포, 한 서버에서 완결
단점	인프라 복잡, CORS 문제 고려	서버 부하 집중, 확장성 떨어짐
예시	React + Nginx + Express	JSP+Tomcat, Spring Boot, Node.js EJS

 

 

 

• FE/BE 분리 구조: FE는 CDN에 올려놓고, BE는 API만 제공 → 현대 SPA 구조
• WAS 구조: 한 서버가 정적 파일 + API + HTML 모두 담당 → 전통적 모놀리식 구조

 

 

---

 

 

웹 서비스 구조 - WEB 서버와 WAS 의 분리

 

 

생각해보면 단순히 WAS 에서 정적 자원을 제공하는 역할을 같이 수행해도 될텐데, 왜 굳이 웹서버와 애플리케이션 서버를 분리했을까요?

 

 

WAS가 너무 많은 역할을 담당하기 때문에 서버 과부하 위험이 있을 수 있고 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있기 때문입니다. 그리고 만약 WAS에 장애가 발생했다면 정적 리소스를 전달할 수 없기 때문에 오류 화면도 노출이 불가능하다는 단점이 있습니다.

 

 

따라서 다음과 같이, Web Server 와 WAS 를 독립적으로 분리하게 됩니다.

 

 

 

Web 서버는 정적인 리소스를 처리하고, 애플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청을 합니다.

WAS는 중요한 애플리케이션 로직을 전담하여 처리합니다.

 

이렇게 Web과 WAS를 분리한다면 다음과 같은 장점을 얻을 수 있습니다.

• WAS에 장애가 발생하더라도 Web 서버가 오류화면 HTML을 제공 가능 => 정적 리소스만을 제공하는 Web서버는 잘 죽지 않지만 애플리케이션 로직을 수행하는 WAS 서버는 잘 죽음.
• 효율적인 리소스 확장 => 각각, 수요에 따라 수평 확장(Load Balancing) 가능
  • 정적 트래픽 급증 시 → Web 서버만 확장
  • 동적 요청 급증 시 → WAS 인스턴스만 확장

또한, 정적 리소스 서빙은 빠른 I/O, 캐싱, SSL 처리 최적화 처리가 된 웹 서버(Nginx, Apache)가 더 효율적으로 처리할 수 있기도 합니다.

그래서 대규모 서비스에서는 WAS를 정적 자원 서빙에 쓰지 않고, 오로지 애플리케이션 실행 환경(비즈니스 로직 처리, DB 연동)으로만 사용합니다. 

 

이때는 Web ↔ WAS를 분리해서

• Web 서버: 정적 파일 제공, 리버스 프록시
• WAS: API, 동적 처리 전담

정적 리소스는 Web 서버에 위임하고, WAS는 사실상 동적 로직 전용으로 운영합니다.

그래서 “WAS = 애플리케이션 실행 환경”이라고 이해하는 게 더 현실적인 이해 같습니다.

또한, 과거의 WAS 는 Tomcat 같은 기술으로 웹페이지를 생성해주는 역할까지 제공했지만,

실무/현대적인 관점에서는 SPA 가 많이 발전하면서 WAS 역할이 많이 축소되고, SSR 은 제외하고 API 를 JSON 형태로 응답해주는 WAS 구조가 자리잡게 됩니다. 

---

WAS 에서의 폴더구조

 

WAS에서 SPA를 만든다고 했을 때 폴더 구조가 어떻게 구성하면 좋을까요?

 

우선 1. 정적 파일을 제공해줄 서버 2. 동적 API 를 제공해줄 서버가  필요합니다.

 

그래서 프론트엔드 빌드 결과물(dist)이 WAS 안에 들어가고, 이를 서버 코드와 함께 배포해야 합니다.

 

다음은 예시 WAS + SPA 폴더 구조입니다. 

project-root/
 ├─ backend/                  # 서버 소스코드 (Java, Node.js 등)
 │
 ├─ frontend/             # SPA 소스 (React, Vue, Angular 등)
 │   ├─ src/              # FE 컴포넌트, 라우터
 │   └─ public/           # index.html (개발용)
 │
 ├─ build/ or dist/       # FE 빌드 산출물 (index.html, bundle.js, css 등)
 │   ├─ index.html
 │   ├─ assets/
 │   │    ├─ bundle.js
 │   │    ├─ style.css
 │   │    └─ images/
 │
 ├─ static/ or public/    # WAS가 정적 파일 서빙하는 폴더
 │   └─ (빌드 산출물이 복사됨)
 │
 ├─ app.js   # WAS 실행 엔트리포인트 ( 정적 웹 서빙 + 동적 요청 리다이렉트 )

 

 

동작 방식

1. 사용자가 브라우저에서 / 또는 /index 접속
   → WAS가 static/index.html (빌드된 SPA entry point)을 응답
2. 브라우저가 로드된 index.html 안에서 JS 번들(bundle.js) 실행
   → SPA 라우터가 /register, /login, /mypage 같은 클라이언트 라우팅 처리
3. 만약 데이터 요청 필요 → WAS의 /api/** 엔드포인트 호출 (JSON 응답)

---

 

 

 

 

 

 

 

 

 

Ref

 

https://hstory0208.tistory.com/entry/Web%EA%B3%BC-WAS%EB%9E%80-%EC%9B%B9-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%9D%98-%EA%B5%AC%EC%A1%B0%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

Web과 WAS란 ? 웹 서비스의 구조에 대해 알아보자

 

 

https://helloworld-88.tistory.com/71