CGI, WSGI, ASGI 정리

CGI, WCGI, ASGI 정리

파이썬 플라스크로 개발된 서버를 로컬에서 실행해보면 Use a production WSGI server instead라는 표현이 콘솔창에 실행되는 걸 확인할 수 있습니다. WSGI가 뭐길래 이걸 쓰라고 하는 걸까요? 또 요즈음 많이 사용하는 FastAPI의 경우에는 ASGI를 사용하는데 얘는 WSGI랑 또 뭐가 다른 걸까요?

CGI

WSGI와 ASGI에 대해서 이야기하기 전에 우선 CGI를 먼저 짚고 넘어가야 합니다. 서버와 사용자가 존재한다고 생각해봅시다. 사용자는 서버로 요청을 보내고, 서버에서 이 요청에 대한 응답을 보냅니다. 사용자가 정적인 페이지, 예를 들어 index.html을 요청한다면 이를 그대로 반환해주면 됩니다. 그런데 만약 요청이 동적인 경우라면 어떻게 할까요? 로그인이나 회원가입 요청과 같이 그때그때 그 값이 달라지는 때에는 어떻게 처리해야 할까요?

웹 어플리케이션이 서버에서 실행되어 어떤 동작(데이터베이스에 접근 등)을 처리하고 그에 맞는 html을 리턴해주면 될 것 같습니다. 이를 위해서는 결국 서버로 들어온 요청을 웹 어플리케이션으로 넘겨줄 수 있어야 합니다. 이때 만약 서버마다 애플리케이션 언어마다 다른 형태를 가진다면 매우 번거로운 일이 될 테니 가능한 공통의 표준 인터페이스를 제공해주어야 합니다. 이 인터페이스가 CGI, Common Gateway Interface입니다.

이런 CGI에는 큰 단점이 존재하는데, 요청이 들어올 때마다 애플리케이션 프로세스를 다시 실행해야 한다는 점입니다. 만약 다량의 요청이 동시에 들어온다면 그 때마다 새로운 프로세스를 생성하고, 사라졌다가 다시 생성해야 합니다. 매우 비효율적이죠. 특히 이러한 비효율성은 파이썬과 같은 스크립트 언어에서 두드러지는데 C와 같이 컴파일된 언어의 프로그램을 실행하는 것보다 더 많은 시간이 필요하기 때문입니다.

WSGI

WSGI는 Web Server Gateway Interface의 약자입니다. 이름만 봐서는 범용적인 기술처럼 보이지만 파이썬에서 사용되는 개념입니다. 앞에서 CGI의 가장 큰 단점은 요청이 들어올 때마다 새로운 프로세스를 생성한다는 점인데요. 이런 단점을 보완하기 위해서 고안된 개념입니다.

앞서서 설명한 CGI의 경우에는 요청에 대한 정보를 환경 변수나 STDIN 등으로 처리했지만 WSGI에서는 Callable object, 함수나 객체로 처리합니다. 서버에서 Callable object를 통해서 요청에 대한 정보와 Callback 함수를 전달하면 애플리케이션은 이 요청을 처리하고 Callback 함수를 실행합니다. 이런 인터페이스를 구현하는 서버나 어플리케이션을 WSGI compatible 하다고 하는데요, 그 중 특히 어플리케이션의 경우에는 WSGI application이라고 합니다.

또 이 중간에서 인증이나 쿠키 등을 관리하는 역할을 하는 것을 WSGI Middleware라고 하는데요, 이 또한 WSGI application의 일종입니다. 여기에는 흔히 사용하는 gunicorn 등이 포함됩니다.

ASGI

이런 WSGI의 경우에는 비동기적인 요청 처리에 단점이 있었습니다. 하나의 동기적인 callable이 요청을 받아 응답을 리턴하는 방식이었는데, 이런 방식은 길게 유지되어야 하는 연결 - long-poll HTTP나 웹 소켓에는 적합하지 않았습니다.

ASGI는 이를 개선하기 위해 만들어졌습니다. ASGI 공식 설명을 보면 “ASGI는 WSGI의 정신적 계승자입니다. 파이썬 웹 서버, 프레임워크, 어플리케이션 사이에 비동기적인 표준 인터페이스를 제공합니다. WSGI가 파이썬 앱에 대한 동기성에 대한 표준을 제공했다면 ASGI는 동기성과 비동기성 모두에 대한 표준을 제공합니다”라고 되어 있는데요. ASGI는 곧 WSGI에 대한 호환성을 가지면서 비동기적인 요청을 처리할 수 있는 인터페이스입니다.

ASGI 서버로는 보통 Uvicorn 등을 많이 사용합니다.