우리는 웹페이지를 이용할 때, 환영받는 느낌을 받는다.
현아님 안녕하세요~ 뭐 이런 문구도 있고,
요즘은 내 취향에 맞는 컨텐츠들을 추천해 메인 페이지에 띄워주기도 한다.

이렇게 상황에 따라 매번 다른 화면을 보여줘야 하는 것을 '동적 컨텐츠 dynamic contents'라고 한다.

웹 서버에서는 동적 컨텐츠를 어떻게 처리할까?
다양한 방식이 있다. 이번 포스팅에서는 동적 컨텐츠를 어떻게 처리하는 지 알아보자.

---

CGI Common Gateway Interface

이 방식은 초기 웹 방식이다.

client(브라우저)에서 요청을 보낸다면, 웹서버에서는 동적 컨텐츠를 처리하기 위해 CGI 프로그램을 실행한다. 이 때 프로그램은 '/cgi-bin' 디렉터리 하위에 저장되어있다.

CGI는 사용자의 요청이 올 때마다 새로운 프로세스를 생성하여, 외부 프로그램을 실행해 응답을 생성하는 방식이다.
만약, 요청 수가 많아진다면 성능이 엄청나게 저하된다는 단점이 있다.

이를 개선한 방식이 나온다!

Fast CGI

CGI의 단점인 "요청마다 새 프로세스를 생성"하는 구조를 개선하며 등장한다.
미리 실행 중인 프로세스 풀에서 요청을 빠르게 처리한다.

대표적으로 Nginx 웹 서버에서 php 환경으로 FastCGI 방식을 사용한다.
이 방식은 현재까지도 널리 사용되는 방법이다.

---

처리 방식은 크게 1.CGI 2.Fast CGI 로 구분할 수 있다.
다만, 현대에서 Framework이 등장하면서 웹 서버와 웹 애플리케이션을 연결하기 위한 추가적인 도구와 실행 환경이 등장하였다.

그리고 이 방법이 대부분의 현대 웹 서버의 구조이다.

WSGI

Python 생태계에서 사용되는 웹 애플리케이션 인터페이스 표준이다.
웹 프레임워크들이 등장하면서 웹 서버와 표준적으로 연결하기 위해 만들어진 인터페이스이다.
+) 참고로, 다른 언어에서도 표준 인터페이스를 둔다. Java의 Servlet, Ruby의 Rack이 이와 같은 개념이다.

그런데 의문이 생길 수 있다.
아니 왜? 왜 애초에 알잘딱깔센 연동되게 만들지 않은 거지?

이유는, 웹 애플리케이션(Django, Flask 등)과 웹 서버(Apache, Nginx 등)는 독립적으로 발전되었기 때문이다. 그렇다보니, 웹 서버에서 각 프레임워크의 반환 정보를 예측할 수 없다는 문제점이 생겨났다. 그래서 이 사이에서 둘을 연결해주는 WSGI가 등장했다.
개발 환경에서는 필요없지만, 배포 실행 환경에서는 필수적이다.

이렇게 웹 서버와 웹 애플리케이션(프레임워크) 사이에 위치하여 일관된 표준으로 번역해준다.

WAS

현대에 많이 사용하는 실행 환경이다.

클라이언트 요청에 따라 동적인 비즈니스 로직을 수행하고, 데이터베이스와 통신하며 응답을 생성하는 실행 환경을 의미한다.

Node.js, Python(Django with WSGI 등) 등의 다양한 언어 생태계에서 구현된다.

언어	WAS 역할을 하는 것
Java	Tomcat, Jetty, Spring Boot
Python	uWSGI, Gunicorn
Node.js	Node 자체가 WAS (http 서버 내장)
PHP	PHP-FPM (FastCGI 기반)

WAS를 이해하기 어려워서 GPT에게 물어본 비유이다.

구성 요소	역할	비유
Web Server (NGINX)	정적 파일 처리 + 요청을 전달	식당의 접수대
CGI / FastCGI	요청을 요리사에게 전달하는 방식	“벨 울려서 요리사 부름” / “무전기 시스템”
WAS	요청을 처리하는 주방/요리사	실제로 요리하고 서빙하는 사람들

---

이제 동적 컨텐츠 마스터다.