[Spring 완전 정복 시리즈 - MVC편] 1편 - 웹 애플리케이션의 이해

이번 편에서는 스프링 MVC의 시작점인 웹 애플리케이션의 기본 구조와 개념을 살펴본다.

서블릿, WAS, 스레드, SSR과 CSR까지, 우리가 백엔드 개발자로서 반드시 알고 있어야 할 기반 지식을 먼저 짚고 넘어가자.

---

1. 웹 서버 vs 웹 애플리케이션 서버(WAS)

• 웹 서버: 정적인 HTML, CSS, JS, 이미지 같은 리소스를 클라이언트에게 그대로 전달
• WAS (Web Application Server): 클라이언트 요청에 따라 동적으로 비즈니스 로직을 실행하고 결과 데이터를 만들어 전달

⟶ 둘을 함께 사용하면

웹 서버는 정적인 리소스를 처리하고, WAS는 복잡한 비즈니스 로직을 전담하여 시스템 효율을 높일 수 있다.

---

2. 서블릿(Servlet)의 등장과 역할

HTTP 요청/응답의 처리 과정을 보면 다음과 같은 반복적이고 저수준의 작업들이 있다:

• 요청 메시지 파싱
• 헤더, 파라미터 추출
• 응답 메시지 생성

이 모든 것을 매번 직접 작성하는 것은 비효율적이다.

⟶ 그래서 등장한 것이 바로 서블릿이다!

 

서블릿의 특징

• HttpServletRequest, HttpServletResponse 등을 통해 HTTP 스펙을 쉽게 다룰 수 있게 해줌
• WAS가 서블릿 객체의 생명주기를 관리 (생성, 호출, 종료)
• 싱글톤으로 관리되므로 멀티 쓰레드 환경에서 공유 변수 주의 필요

---

3. 동시 요청 처리와 스레드

멀티쓰레드 지원은 백엔드 개발자가 반드시 이해해야 할 개념

• 자바 애플리케이션은 최소 하나의 쓰레드(main)가 필요
• 동시에 여러 요청이 들어오면 쓰레드를 새로 생성해 처리
• 하지만 쓰레드는 생성 비용이 높다
  • 컨텍스트 스위칭 발생
  • 자원이 제한된 상황에서 과도한 쓰레드 생성은 시스템 과부하로 이어짐

해결 방법

스레드 풀(Thread Pool)

• 미리 일정 수의 쓰레드를 생성 후 재사용
• 초과 요청은 대기열(Queue) 또는 거절(Reject) 처리
• → WAS의 튜닝 핵심 포인트는 최대 스레드 수 설정

---

4. 정적 리소스 vs 동적 HTML vs HTTP API

백엔드 개발자가 제공해야 할 세 가지

1. 정적 리소스 제공: 이미지, JS, CSS 등
2. 동적 HTML 페이지 제공: 서버에서 렌더링된 HTML
3. HTTP API 제공: JSON 형태의 응답

SSR vs CSR

구분	SSR (Server Side Rendering)	CSR (Client Side Rendering)
위치	서버에서 HTML 생성	클라이언트에서 JS가 HTML 생성
장점	SEO에 유리, 초기 로딩 빠름	동적 UI 구성에 유리
단점	서버 부하 증가	JS 실행 전까지는 내용 없음

 

백엔드 개발자는 SSR 학습은 필수, CSR은 선택이다.

---

5. 핵심 정리

• 서블릿은 저수준 HTTP 처리 로직을 대신 수행해주는 표준 API
• WAS는 스레드 풀을 통해 성능 최적화 가능
• SSR, CSR 개념을 이해하고 각각의 역할과 상황에 따라 판단할 수 있어야 함
• 성능 테스트는 운영 전 필수로 진행해야 한다

---

6. 퀴즈 정리

1. 웹 서버와 WAS의 핵심 차이점은?
   → 정적 리소스 vs 동적 처리
2. 서블릿이 개발자에게 주는 이점은?
   → 반복적인 HTTP 파싱/응답 로직을 추상화하여 비즈니스 로직에 집중할 수 있게 해줌
3. WAS에서 스레드 풀을 사용하는 이유는?
   → 스레드 생성 비용 최소화 및 자원 효율성 향상
4. SSR이란?
   → 서버에서 HTML을 조립해 클라이언트에 보내는 방식
5. 웹 서버와 WAS를 함께 쓰는 이유는?
   → 역할 분리로 리소스 절약 및 안정성 확보

---

마무리

이번 내용을 통해 단순히 “웹 요청을 받아 처리한다”는 행위 뒤에 얼마나 많은 개념과 구조가 숨어있는지를 알게 되었다.

서블릿과 WAS의 관계, 멀티쓰레드 구조, SSR과 CSR의 차이까지, 백엔드 개발자로서 반드시 이해하고 있어야 할 핵심 개념들이었다.

 

특히 WAS의 스레드 풀 구조나 성능 튜닝 포인트는 실무에 바로 적용 가능한 내용이라 인상 깊었고,

단순한 코드 작성 이전에 시스템 구조를 바라보는 눈을 키우는 게 얼마나 중요한지 다시금 느꼈다.

 

지금까지는 동작만 확인하면 넘어갔던 부분들이었지만, 이제는 “왜 그렇게 설계되었는가?“를 함께 고민하게 된다.

이해의 깊이가 늘수록 개발자로서의 성장도 따라온다는 걸 실감한 시간이었다.