본문으로 건너뛰기
Advertisement

정적 콘텐츠 vs 동적 콘텐츠

웹 서버가 클라이언트에게 전달하는 콘텐츠는 크게 정적(Static) 과 동적(Dynamic) 두 가지로 나뉩니다. 이 차이를 이해하면 왜 웹서버와 WAS를 별도로 두는지, 각각 어느 단계에서 어떤 역할을 맡는지가 명확해집니다.

정적 콘텐츠란?​

정적 콘텐츠 는 서버 디스크에 미리 저장된 파일을 변경 없이 그대로 클라이언트에게 전달하는 것입니다. 누가 요청해도, 언제 요청해도 항상 동일한 내용 이 반환됩니다.

정적 콘텐츠 종류​

파일 유형예시Content-Type
HTMLindex.html, about.htmltext/html
CSSstyle.css, bootstrap.min.csstext/css
JavaScriptapp.js, react.min.jsapplication/javascript
이미지logo.png, banner.webpimage/png, image/webp
폰트NanumGothic.woff2font/woff2
문서manual.pdfapplication/pdf
동영상intro.mp4video/mp4

정적 콘텐츠 처리 흐름​

브라우저: GET /images/logo.png
     │
  [Nginx]
     │  1. /images/logo.png 경로에 파일 존재 확인
     │  2. 디스크에서 파일 읽기
     │  3. HTTP 응답 헤더(Content-Type, Cache-Control) 추가
     │
  [응답]: 200 OK + PNG 바이너리 데이터
     │
  브라우저에 이미지 표시

Nginx 설정 예시:

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    # 정적 파일 직접 서빙
    location /static/ {
        expires 30d;                        # 30일 브라우저 캐시
        add_header Cache-Control "public";
    }
}

동적 콘텐츠란?​

동적 콘텐츠 는 요청이 들어올 때 서버에서 프로그램을 실행하여 그 결과를 생성 하는 응답입니다. 요청 시점, 요청자, 파라미터에 따라 응답 내용이 달라집니다.

동적 콘텐츠 예시​

요청: GET /api/user/profile
 → 로그인한 사용자 정보를 DB에서 조회
 → JSON 생성: {"name": "홍길동", "email": "hong@example.com"}

요청: GET /api/products?category=laptop
 → DB에서 노트북 카테고리 상품 조회
 → 그 시점의 재고·가격·이벤트 정보 포함하여 반환

요청: POST /api/order
 → 결제 처리 → 주문 DB 저장 → 이메일 발송
 → 주문번호 생성 후 응답

동적 콘텐츠 처리 흐름​

제품 목록 요청 및 응답 흐름

CGI에서 WAS로 — 동적 처리 기술의 발전사​

오늘날의 WAS가 탄생하기까지 동적 웹 처리 기술은 여러 단계를 거쳐 발전했습니다.

1단계: CGI (Common Gateway Interface, 1993년)​

초기 웹에서 동적 콘텐츠를 만드는 방법은 CGI 였습니다. 웹서버가 HTTP 요청을 받으면 외부 프로그램(Perl, C, Shell 스크립트 등)을 실행하고, 그 프로그램이 표준 출력(stdout)으로 HTML을 출력하면 웹서버가 이를 클라이언트에게 전달하는 방식입니다.

브라우저: GET /cgi-bin/hello.pl
     │
  [Apache] → fork() → [Perl 프로세스] → stdout: "Content-Type: text/html\n\nHello!"
     │
  Apache가 stdout을 읽어 응답 반환

CGI의 문제점: 요청마다 새 프로세스(fork)를 생성합니다. 동시 요청이 100개라면 프로세스 100개가 생성됩니다. 메모리·CPU 자원 낭비가 심하고 응답 속도가 느립니다.

2단계: FastCGI / mod_perl (1996년~)​

CGI의 프로세스 생성 오버헤드를 줄이기 위해 FastCGI 가 등장했습니다. 프로세스를 미리 띄워놓고 요청을 소켓으로 전달하는 방식으로, 프로세스를 매번 생성하지 않아도 됩니다. PHP가 이 방식(php-fpm)을 현재도 사용합니다.

[Apache/Nginx] ─── FastCGI 소켓 ───→ [php-fpm 프로세스 풀]
                                          (미리 생성된 PHP 워커들)

3단계: Java Servlet (1997년) — WAS의 시작​

Java 진영에서는 Servlet 스펙이 등장했습니다. Servlet은 Java 클래스로 작성된 서버 사이드 프로그램입니다. CGI처럼 프로세스를 새로 생성하는 대신, JVM 위에서 스레드 단위로 요청을 처리합니다.

// 간단한 Servlet 예시
@WebServlet("/hello")
public class HelloServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse res)
            throws IOException {
        res.setContentType("text/html; charset=UTF-8");
        PrintWriter out = res.getWriter();
        out.println("<html><body>");
        out.println("<h1>안녕하세요, " + req.getParameter("name") + "!</h1>");
        out.println("</body></html>");
    }
}

Servlet의 장점:

  • 프로세스가 아닌 스레드 기반 → 자원 효율 대폭 향상
  • JVM에서 실행 → 플랫폼 독립성
  • 객체지향 설계 가능

Servlet 컨테이너 가 Servlet의 생명주기(생성 → 초기화 → 서비스 → 소멸)를 관리합니다. Apache Tomcat이 대표적인 Servlet 컨테이너입니다.

4단계: JSP (JavaServer Pages, 1999년)​

Servlet으로 HTML을 생성하면 Java 코드 안에 HTML을 문자열로 작성해야 하는 불편함이 있었습니다. JSP 는 HTML 파일 안에 Java 코드를 삽입하는 방식으로, 프론트엔드 개발자가 HTML을 작성하기 쉽게 했습니다.

<%@ page language="java" contentType="text/html; charset=UTF-8" %>
<!DOCTYPE html>
<html>
<body>
  <h1>상품 목록</h1>
  <ul>
  <%
    List<Product> products = productService.findAll();
    for (Product p : products) {
  %>
    <li><%= p.getName() %> - <%= p.getPrice() %>원</li>
  <%
    }
  %>
  </ul>
</body>
</html>

JSP 파일은 Tomcat이 자동으로 Servlet 클래스로 변환·컴파일 한 뒤 실행합니다.

5단계: MVC 프레임워크 (2003년~)​

비즈니스 로직과 뷰(HTML)가 JSP 한 파일에 섞이는 문제를 해결하기 위해 MVC 패턴 과 Spring MVC, Struts 같은 프레임워크가 등장했습니다. 현재 대부분의 Java 웹 애플리케이션은 Spring Boot + 내장 Tomcat 조합으로 개발됩니다.

6단계: REST API + SPA (2010년대~)​

현대 웹 아키텍처는 서버가 HTML을 렌더링하는 대신 JSON API 를 제공하고, 프론트엔드(React, Vue 등)가 JavaScript로 UI를 그리는 SPA(Single Page Application) 방식이 주류가 되었습니다.

[React/Vue SPA] ←── GET /static/app.js ──→ [Nginx]  (정적 파일)
[React/Vue SPA] ←── POST /api/login ─────→ [Nginx] → [Tomcat]  (동적 API)

정리: 정적 vs 동적 처리 담당 비교​

항목정적 콘텐츠동적 콘텐츠
처리 주체웹서버(Nginx·Apache)WAS(Tomcat)
처리 방식디스크 파일 그대로 반환프로그램 실행 후 결과 생성
응답 시간매우 빠름 (수 ms)상대적으로 느림 (DB 조회 등)
캐싱적극 캐싱 가능주의 필요 (데이터 변경 가능)
서버 부하매우 낮음높음 (연산, DB I/O)
예시HTML·CSS·JS·이미지로그인, 주문, 검색, 마이페이지

웹서버가 정적 파일을 앞에서 처리하면 WAS의 부담이 크게 줄어들어 전체 시스템 처리 성능이 향상됩니다.

Advertisement
Advertisement