728x90

정적 페이지, 동적 페이지

정적 페이지 (Static Page)

서버에 저장된 `고정된 HTML 파일`을 그대로 클라이언트에 전달하는 페이지

페이지 내용이 사용자나 상황에 따라 변하지 않음

특징

  • 빠르고 가벼움
  • 서버 부하 少
  • 수정하려면 직접 HTML을 고쳐야 함
  • 예전 방식의 홈페이지 & 블로그 등에 사용

예시

  • about.html, contact.html, index.html 등
  • 정적인 기업 소개 페이지, 간단한 프로필 사이트
파일 구성: `/index.html`, `/style.css`,  `/script.js` 

👉 클라이언트가 요청하면 그대로 응답

동적 페이지 (Dynamic Page)

클라이언트의 요청이나 상황에 따라 서버에서 실시간으로 생성되는 웹 페이지

사용자마다 다른 내용을 보여줄 수 있음

특징

  • 서버가 HTML을 실시간 Rendering
  • DB 연동 가능
  • 사용자 정보, 로그인 상태, 게시글 목록 등 동적으로 처리 가능
  • 처리 로직이 복잡하고 성능 튜닝이 필요할 수 있음

예시

  • 로그인 후 '홍길동 님 환영합니다!` 페이지
  • 게시판, 블로그, 쇼핑몰의 상품 목록 페이지
  • 뉴스 사이트 등 실시간 정보 제공

 

항목 정적 페이지  동적 페이지
생성 시점 개발자가 미리 작성 요청 시 서버가 생성
콘텐츠 고정됨 상황에 따라 변경됨
서버 부하 낮음 상대적으로 높음
사용자별 맞춤 불가능 가능
사용 기술 HTML, CSS, JS JSP, PHP, Node.js, React, DB 등
예시 회사 소개, 랜딩페이지 쇼핑몰, 게시판, 사용자 대시보드

웹서버 & WAS

웹 서버 (Web Server)

정적인 콘텐츠 (HTML, CSS, JS, 이미지 등)를 클라이언트에 전달하는 역할을 함

클라이언트(웹 브라우저)로부터 요청을 받아 정적인 파일을 반환 (HTTP Response)

특징

  • 빠르고 가벼움
  • 정적인 파일 처리 최적화
  • 리버스 프록시, 로드 밸런싱 기능을 포함하기도 함
📌 대표적인 웹 서버
Apache HTTP Server, Nginx, Miscrosoft IIS 등

WAS (Web Application Server)

웹 서버보다 더 고도화된 기능 수행, 동적인 콘텐츠 (DB 조회, 사용자 인증 등)를 처리

자바 서블릿, JSP, 스프링 같은 웹 애플리케이션 로직을 실행

특징

  • 비즈니스 로직 처리
  • DB 연동, 세션 관리 등 가능
  • 웹 서버와 연동되어 사용되는 경우 多
📌 대표적인 WAS
Tomcat (Java 기반 was)
JBoss / WildFly
WebLogic/ WebSpehre
Node.js 기반 Express (Node는 웹 서버 & WAS 역할 동시 수행 가능)
항목 웹 서버  WAS
주 역할 정적 파일 처리 동적 로직 처리
처리 대상 HTML, CSS, JS, 이미지 JSP, Servlet, 스프링 등
리소스 소비 낮음 상대적으로 높음
예시 Nginx, Apache Tomcat, JBoss

차이점 & 효율적인 사용

WAS가 웹 서버 기능의 많은 부분을 포함하여 수행하기도 하지만, 사용의 `목적`이 다름

  • 웹 서버: 정적인 데이터를 처리하는 서버, 이미지나 단순 HTML 같은 정적 리소스들을 전달
    👉 WAS만을 이용할 경우보다 빠르고 안정적인 기능 수행
  • WAS: 동적인 데이터를 위주로 처리하는 서버, DB와 연결되어 사용자와 데이터를 주고 받고 조작이 필요한 경우 활용
정적인 콘텐츠만을 제공하는 웹 사이트를 서버에 배포한다면 웹 서버만으로 충분함
웹 서버가 할 수 있는 일을 WAS가 전부 가능하다면, WAS만 사용해도 되는 거 아닌가?

비효율적인 웹 시스템 구성

만일 WAS가 정적 콘텐츠 요청까지 처리한다면, 부하가 커지고 동적 컨텐츠 처리가 지연되면서
수행 속도 저하 & 페이지 노출 시간 증가 = 효율설 대폭 저하

효율적인 웹 시스템 구성

WAS는 DB 조회 및 다양한 로직을 처리하는 데 집중해야 함
∴ 단순한 정적 콘텐츠는 웹 서버에 맡기며 기능을 분리해 서버 부하를 방지해야 함

❓ 장애 극복 기능
컴퓨터 서버, 시스템, 네트워크 등에서 이상이 생겼을 때 예비 시스템으로 자동전환될 수 있도록 처리하는 기능
수동 전환 = 스위치 오버
예시)
사용중 WAS에 문제가 생겨 WAS를 재시작해야 하는 경우.
재시작 하기 위해 웹 서버에서 WAS를 사용하지 못하도록 요청을 차단한 후 WAS를 재시작
= 사용자들은 WAS에 문제가 발생한지 모르고 이용 가능

정리

분리해서 사용하는 이유

  1. 성능 분산: 정적 자원을 웹 서버가 담당함으로써 WAS 부하 줄임
  2. 보안 강화: 외부에 직접 노출되는 건 웹 서버, WAS는 내부망에서 보호
  3. 유연한 구성: 로드 밸런싱, 캐시, Gzip 압축 등 웹 서버가 다양한 최적화 기능 제공

실제 예시

SpringBoot + Tomcat + Ngnix 구조

  • Ngnix가 80포트에서 요청 수신 → 정적 파일 직접 응답
  • `/api`, `/login` 같은 요청은 8080포트의 톰캣으로 프록시
  • 톰캣은 Spring MVC 등으로 동적 응답 생성 → Ngnix를 통해 브라우저로 전송

웹 서버와 WAS 협업 구조

기본 구조

리버스 프록시

웹 서버가 중계자 역할을 하며, 클라이언트의 요청을 내부 서버(WAS)로 전달하는 구조

클라이언트는 실제로 WAS가 아닌, 웹 서버와만 통신

정적 요청

GET /assets/logo.png → Nginx가 직접 응답

동적 요청

GET /user/123 → Nginx가 Tomcat으로 전달 → Spring Controller → DB 조회 → HTML 응답 생성

Ngnix 설정 예시 (Spring Boot WAS로 리버스 프록시)

server {
    listen 80;

    server_name example.com;

    # 정적 파일 요청은 직접 처리
    location /static/ {
        root /var/www/html;
    }

    # 모든 API 요청은 WAS(Spring Boot, Tomcat)로 전달
    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

장점 요약

항목  설명
성능 최적화 정적 리소스를 웹 서버에서 빠르게 처리
보안 강화 WAS는 내부망에 위치하여 외부 직접 접근 차단
유연한 확장 여러 WAS 인스턴스를 로드밸런싱 가능
유지보수성 향상 역할 분리로 시스템 구조가 명확함

 

728x90

티스토리툴바