home..

Spring MVC 1주차

March 2025 (834 Words, 5 Minutes)

1주차

✅ HTTP 기반 데이터 전송

클라이언트 → 서버, 서버 ↔ 서버 간 데이터 전송에 HTTP 사용
텍스트(html), 이미지, 영상, 음성, JSON 등 모두 HTTP 메시지로 전송

✅ 웹 서버(Web Server)

역할: 정적 리소스(HTML, 이미지 등) 제공
예시: Nginx, Apache
특징:
- 정적 파일을 클라이언트에게 직접 전달
- 애플리케이션 로직은 처리하지 않고, 필요시 WAS로 위임
- 단순한 구조 → 장애 발생 확률 낮음

✅ WAS (Web Application Server)

역할: 애플리케이션 로직 실행 (동적 처리)
예시: Tomcat, 스프링 MVC, 서블릿 컨테이너 등
특징:
- 사용자마다 다른 화면이나 데이터 제공 가능 (동적)
- REST API 제공
- 정적 리소스도 제공 가능하지만, 비효율적
- 프로그램 코드 실행 → DB 연결, 외부 서버 호출 등 복잡하고 리소스 소모 큼
- 과부하 위험 있음 → 과중한 역할 X

✅ 웹 서버와 WAS의 관계

웹 서버: 정적 리소스 처리 전담
WAS: 동적 로직 전담 (비용 높은 처리)
웹 서버는 처리 못 하는 요청만 WAS에 위임
구조 분리 장점:
- 정적 리소스는 가볍고 빠름 → 웹 서버에서 처리
- WAS는 무거운 로직만 집중 처리 → 성능 향상
- 웹 서버는 잘 죽지 않지만, WAS는 죽을 수 있음 → 오류 대응 가능하게 설정해야 함

✅ API 서버는 웹 서버 없이도 가능

API 서버는 정적 리소스를 제공할 필요가 없으므로 WAS만으로도 충분

✅ 핵심 요약: 왜 서블릿이 필요하고, 어떻게 동작하는가?

📌 1. POST 요청 처리 흐름

클라이언트가 form에 데이터를 입력하고 제출 (POST)

→ 웹 브라우저가 HTTP 메시지 생성

→ 서버로 전송

→ 서버는 이를 파싱하고 비즈니스 로직 처리 + DB 저장 + 응답 HTML 생성 필요

이걸 일일이 직접 구현하려면 TCP/IP 연결부터 시작해서 너무 복잡하니까 서블릿(Servlet)이 이 과정을 대부분 자동화해줌!

📌 2. 서블릿과 서블릿 컨테이너(WAS)

서블릿(Servlet): 클라이언트 요청이 올 때 실행되는 자바 클래스 HttpServlet을 상속하고 doGet, doPost 같은 메서드를 구현함.
서블릿 컨테이너 (톰캣 등 WAS): 서블릿을 관리하고 HTTP 요청/응답 처리를 도와줌.

📌 4. 서블릿 컨테이너가 하는 일

요청 처리 자동화: TCP/IP 연결, 파싱, 요청 방식(GET/POST), Content-Type 처리 등
Request/Response 객체 생성: 개발자가 쉽게 HTTP 정보 다루도록 도와줌
서블릿 실행: @WebServlet(urlPatterns="/hello") 같은 URL 매핑으로 실행

📌 5. 싱글톤 서블릿 관리 (중요)

서블릿 객체는 한 번만 생성 → 모든 요청이 동일한 인스턴스를 공유
성능 ↑, 메모리 ↓
BUT! 멤버 변수에 상태 저장 금지 ⚠️
- 여러 요청이 동시에 들어와도 하나의 인스턴스를 여러 쓰레드가 같이 사용하기 때문
멀티 쓰레드 기반 처리 → 동시 요청을 빠르게 처리 가능

📌 5. 쓰레드 풀

요청 마다 쓰레드 생성의 단점 보완

특징
- 필요한 쓰레드를 쓰레드 풀에 보관하고 관리한다
- 쓰레드 풀에 생성 가능한 쓰레드의 최대치를 관리한다.
- 톰캣 서버- 최대 200개 기본 설정 (변경 가능)
사용: 쓰레드가 필요하면, 이미 생성되어 있는 쓰레드를 쓰레드 풀에서 꺼내서 사용한다, 사용을 종료하면 쓰레드 풀에 해당 쓰레드를 반납한다.
최대 쓰레드가 모두 사용중이어서 쓰레드 풀에 쓰레드가 없으면? → 기다리는 요청은 거절하거나 특정 숫자만큼만 대기하도록 설정할 수 있다.
장점 : 쓰레드가 미리 생성되어 있으므로, 쓰레드를 생성하고 종료하는 비용(CPU)이 절약되고, 응답 시간이 빠르다.
생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있다.

쓰레드 풀 <실무 팁="">

• WAS의 주요 튜닝 포인트는 최대 쓰레드(max thread) 수이다. 이 값을 너무 낮게 설정하거나(CPU 너무 적게 사용하는는 것 ) 너무 높게 설정하면( 요청 다 받아버리면 서버가 죽어버림. 적정 값을찾는게 중요) 안됨! • 동시 요청이 많으면, CPU, 메모리 리소스 임계점 초과로 서버 다운. • 장애 발생시? 클라우드면 일단 서버부터 늘리고, 이후에 튜닝, 클라우드가 아니면 열심히 튜닝

적정 숫자는 어떻게 찾나요?

• 애플리케이션 로직의 복잡도, CPU, 메모리, IO 리소스 상황에 따라 모두 다름

<성능 테스트=""> - 트래픽이 있는 서비스라면 성능 테스트를 해봐야함., 최대한 실제 서비스와 유사하게 성능 테스트 시도- 툴: 아파치 ab, 제이미터, nGrinder

WAS의 멀티 쓰레드 지원

멀티 쓰레드에 대한 부분은 WAS가 처리- 개발자가 멀티 쓰레드 관련 코드를 신경쓰지 않아도 됨

개발자는 마치 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스 코드를 개발.
멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)는 주의해서 사용

HTML, HTTP,

정적 리소스 제공 → 고정된 파일등을 제공 . 웹 서버에서 폴더에 있는 이미 생성될 파일들.

html 페이지→ 동적으로 필요한 html 파일들: DB를 통해서 주문정보 조회, 동적 html 생성을 웹브라우저에 내려줌. (주문내역과 정보들)
http api: html이 아니라 데이터를 전달, 주로 JSON 형식 사용, 다양한 시스템에서 호출. JSON 에 대한 데이터—> 보여줌. 이런 모양으로 http api 는 다양한 시스템들에서 호출할때 사용, 데이터만 주고 받음, UI 화면이 일표하면 클라이언트가 별도로 처리. 앱, 웹 클라이언트, 서버 to 서버 . was : 주문 서버 (데이터를 바로 내려줌: HTTP API ) 자바 스크립트- 자바스크립트의

HTTP API 다양한 시스템 연동 • 주로 JSON 형태로 데이터 통신 • UI 클라이언트 접점 • 앱 클라이언트(아이폰, 안드로이드, PC 앱) • 웹 브라우저에서 자바스크립트를 통한 HTTP API 호출 • React, Vue.js 같은 웹 클라이언트 • 서버 to 서버 • 주문 서버 -> 결제 서버 • 기업간 데이터 통신

백엔드 개발자가 고민해야 할 3가지

정적 리소스
동적 html 페이지 어떻게 제공
http api 어떻게 주고받을지

서버사이드 렌더링, 클라이언트 사이드 렌더링

• SSR - 서버 사이드 렌더링

• HTML 최종 결과를 서버에서 만들어서 웹 브라우저에 전달 • 주로 정적인 화면에 사용 • 관련기술: JSP, 타임리프 -> 백엔드 개발자 • CSR - 클라이언트 사이드 렌더링 • HTML 결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용 • 주로 동적인 화면에 사용, 웹 환경을 마치 앱 처럼 필요한 부분부분 변경할 수 있음 • 예) 구글 지도, Gmail, 구글 캘린더 • 관련기술: React, Vue.js -> 웹 프론트엔드 개발자 • 참고 • React, Vue.js를 CSR + SSR 동시에 지원하는 웹 프레임워크도 있음 • SSR을 사용하더라도, 자바스크립트를 사용해서 화면 일부를 동적으로 변경 가능

어디까지 알아야 하나요?

백엔드 개발자 입장에서 UI 기술 • 백엔드 - 서버 사이드 렌더링 기술- 필수 (강의에서는 타임리프) • 웹 프론트엔드 - 클라이언트 사이드 렌더링 기술 • 선택과 집중- 백엔드 개발자는 서버, DB, 인프라 등등 수 많은 백엔드 기술을 공부해야 한다.

풀스택에 대한 환상이 좀 있을 수 있는데, 현업에서 잘 하는 사람을 거의 못 봤다고 함 , 선택과 집중이 필요하다고 함 → 사람마다 다름 ,