Python의 WSGI(Web Server Gateway Interface) - Node와 비교하며 이해하기

728x90

서론

Python의 GIL(Global Interpreter Lock) - Node와 비교하며 이해하기

서론Node를 처음 접할 때, 가장 먼저 이해해야하는 것들 중에는 아래와 같은 개념들이 있습니다.JS 실행은 기본적으로 싱글 스레드다.대신 이벤트 루프와 비동기 I/O로 동시성을 만든다.CPU를 갈아

mag1c.tistory.com

이전글에서 Python의 GIL에 대해 정리했습니다. Node에서 Python으로 전환하면서 동시성 처리의 차이점을 이해하는 것이 중요하다고 생각했기 때문입니다.

이번에는 제가 Python의 레거시 스택을 사용하면서 또 다른 혼동의 원인이었던 WSGI(Web Server Gateway Interface)에 대해 정리해보려 합니다.

Node로 웹 서버를 만들 때는 아래처럼 만들죠.

const express = require('express');
const app = express();

app.get('/', (req, res) => {
    res.send('Hello World');
});

app.listen(3000);

express의 app.listen()은 내부적으로 Node의 http.createServer()을 호출합니다.

런타임에 HTTP 서버가 내장되어 있어서, 별도 서버 없이 바로 띄울 수 있죠.

// express/lib/application.js
app.listen = function listen() {
    var server = http.createServer(this)  // Node.js 내장 http 모듈 사용
    return server.listen.apply(server, arguments)
}

그런데 Django는...

python manage.py runserver
# "WARNING: This is a development server. Do not use it in production."

# django 소스코드 일부
# django/core/management/commands/runserver.py
self.stdout.write(
  self.style.WARNING(
      "WARNING: This is a development server. Do not use it in a "
      "production setting. Use a production WSGI or ASGI server "
      "instead.\nFor more information on production servers see: "
      f"https://docs.djangoproject.com/en/{docs_version}/howto/"
      "deployment/"
  )
)

소스코드를 확인해보니 무슨 SGI를 사용하라고하네요. ~~서울보증보험인가..~~ 별도의 서버가 필요하다는 것은 확실해 보였습니다.

Java기반의 Spring을 짧게 사용했을 때도 당연히 Tomcat을 별도로 사용했기 때문에 그런가보다 했습니다.

그런데 공부하다보니 2025년을 살아가는 저에게는 꽤나 독특한 녀석이라고 생각했습니다.

왜 Python 웹 생태계는 GIL 뿐 아니라 WSGI 같은 녀석도 표준이 되어 지금까지도 사용되고 있을까요?

애플리케이션과 서버의 분리

다시 말하지만 Node는 개발자가 웹 서버를 별도 구성할 필요가 없습니다.

런타임에 HTTP 서버가 내장되어 있어 별도 서버를 구성하지 않고도 바로 웹 서버를 띄울 수 있죠.

왜 이렇게 분리되었을까요?

2000년대 초반에는 Python 웹 생태계에는 Zope, Quixote, Webware 등의 다양한 프레임워크가 있었다고 합니다.

문제는 프레임워크 선택이 서버 선택이 되어, Zope를 쓰려면 Zope 서버를, Quixote를 쓰려면 또 다른 서버를 써야 했다고 해요.

Java에서는 Servlet API가 이 문제를 해결했어요.

어떤 서블릿 컨테이너(Tomcat, Jetty 등)에서든 서블릿 스펙을 따르는 웹 앱을 실행할 수 있습니다.

Python도 비슷한 표준이 필요했고, 그렇게 WSGI가 탄생했다고 합니다.

(이와 관련된 자세한 내용은 PEP-333에 나와있습니다.)

WSGI

WSGI(Web Server Gateway Interface)는 웹 서버 게이트웨이의 표준 인터페이스입니다.

웹 서버와 Python Application 사이의 표준 인터페이스 인 셈이죠.

Python이 그러한 것 처럼, WSGI 또한 단순하고 간결한 것이 원칙이었다고 합니다.

Thus, simplicity of implementation on both the server and framework sides of the interface is absolutely critical to the utility of the WSGI interface, and is therefore the principal criterion for any design decisions.

the goal of WSGI is to facilitate easy interconnection of existing servers and applications or frameworks, not to create a new web framework

Phillip J. Eby (PEP 333 - https://peps.python.org/pep-0333)

WSGI Application 구조

단순하고 간결한 원칙 때문이었을까요? WSGI 애플리케이션은 단순합니다.

def application(environ, start_response):
    """단순한 WSGI Application"""
    status = '200 OK'
    response_headers = [('Content-Type', 'text/plain')]
    start_response(status, response_headers)
    return [b'Hello World']

두 개의 파라미터를 받는 callable* 객체면 충분합니다. 이게 전부에요.

callable은 말 그대로 호출할 수 있는 객체를 뜻해요. application() 처럼요.

참고로 응답이 리스트(iterable)인 이유가 있어요.
대용량 파일을 한 번에 메모리에 올리지 않고 chunk 단위로 스트리밍할 수 있게 하려는 설계입니다.

environ

이름만 봐도 감이 오죠? .env를 생각하면 될 것 같아요.

environ은 CGI 스타일의 환경 변수 딕셔너리에요. CGI(Common Gateway Interface)는 1990년대 웹 서버가 외부 프로그램을 실행하던 방식이에요. WSGI가 이 변수 컨벤션을 그대로 사용한 이유는, 당시 Python 프레임워크들이 이미 CGI 방식을 구현해뒀기 때문입니다.

아래의 값들을 통해 웹 서버를 설정해야해요.

start_response

start_response는 응답 상태와 헤더를 설정하는 callable 이에요.

start_response(status, response_headers, exc_info=None)

status = '200 OK'  # HTTP 상태코드 + 메시지 (문자열)
response_headers = [
  ('Content-Type', 'text/plain'),
  ('Content-Length', '12')
]
start_response(status, response_headers)  # 서버에게 알림
return [b'Hello World!']  # 그 다음 본문 반환

WSGI 실제 구현 예시

제가 사용하는 Django를 예로 들어볼게요. 개발자는, Response안에 응답 데이터와 상태를 넣어줘요.

return Response(data=serializer.data, status=status.HTTP_200_OK)

위에서 언급한 WSGI Application에 들어가는 환경 변수나 응답 헤더 등의 설정은 하지 않았는데요.

Django 내부에서는 이 저수준의 WSGI를 래핑한 고수준의 API를 제공합니다. 아래는 간략화한 예시입니다.

class WSGIHandler:
  def __call__(self, environ, start_response):
      # 1. environ을 Django Request로 변환
      request = self.request_class(environ)

      # 2. View 실행 → Response 객체 반환
      response = self.get_response(request)

      # 3. Response를 WSGI 형식으로 변환
      status = '%d %s' % (response.status_code, response.reason_phrase)

      start_response(status, response_headers)
      return response

WSGI를 사용한 HTTP Request LifeCycle

위 시퀀스 다이어그램은 WSGI를 사용한 HTTP 요청이 처리되기 까지를 요약한 다이어그램입니다.

실제 프로덕션 환경에서는

리버스 프록시: HTTPS, static serving, LB, Buffering 등의 역할
WSGI 서버: HTTP 요청을 WSGI 프로토콜(environ, start_response)로 변환하여 애플리케이션에 전달, 응답을 클라이언트에 반환, 동시 요청 처리
WSGI 애플리케이션: WSGI 스펙을 따르는 callable(wsgi.py)을 통해 요청을 받아 비즈니스 로직 수행

위와 같은 플로우로 동작하게 됩니다.

WSGI의 한계

WSGI는 2003년에 만들어졌다고 해요. ~~틀딱인거죠~~

GIL이 멀티스레드 CPU 연산을 제한하는 것처럼, WSGI도 요청-응답 모델에서 제약이 있습니다. 다만 문제의 성격은 달라요. GIL은 스레드 병렬성의 문제이고, WSGI는 연결 유지와 양방향 통신이 불가능한 설계의 문제입니다

def application(environ, start_response):
    result = do_something_slow()  # 블로킹!
    start_response('200 OK', [('Content-Type', 'text/plain')])
    return [result.encode()]

요청이 들어오면 워커 하나가 요청을 받고, 처리가 끝날 때까지 해당 워커는 점유되며 응답을 반환하고 나서야 다음 요청 처리가 가능해요. (sync worker 기준)

물론 Gunicorn도 gevent나 eventlet 같은 async worker를 사용하면 Green thread 기반으로 수백 개의 동시 연결을 처리할 수 있어요. 하지만 이건 WSGI 표준 위에서의 우회 방식이고, WebSocket 같은 양방향 통신은 여전히 구조적으로 불가능합니다.

물론 Django를 사용하더라도 멀티프로세싱이나 스케일 아웃으로 많은 워커를 구성하거나
적절한 캐싱과 인프라 구조의 최적화를 통해 개선할 수도 있겠죠...?

실제로 인스타그램은 2012년 Django + Gunicorn 스택으로 1400만 유저까지 스케일했고,
현재도 Django를 핵심 스택으로 사용하며 수십억 사용자를 처리하고 있어요. 대단하죠.. (인스타 기술 블로그)

ASGI

ASGI(Asynchronous Server Gateway Interface)는 비동기 기능을 갖춘 파이썬 웹 서버 인터페이스입니다.

(ASGI 스펙 문서에서는 WSGI의 정신적 후계자(spiritual successor)라고 소개되어 있어요)

async를 통해 비동기 처리를 지원하는 ASGI는 Django 기준 3.0부터 공식 지원한다고해요.

# WSGI
def application(environ, start_response):
    start_response('200 OK', headers)
    return [b'Hello World']

# ASGI
async def application(scope, receive, send):
    await send({
        'type': 'http.response.start',
        'status': 200,
        'headers': [(b'content-type', b'text/plain')],
    })

ASGI의 세 파라미터를 간단히 설명하자면

scope: 연결의 메타데이터 (HTTP인지 WebSocket인지, 경로, 헤더 등)
receive: 클라이언트로부터 메시지를 비동기로 수신
send: 클라이언트로 메시지를 비동기로 전송

WSGI가 요청을 받아 응답을 반환하는 단방향이었다면, ASGI는 receive/send로 언제든 양방향 통신이 가능한 구조입니다.

# asgi.py
import os
from django.core.asgi import get_asgi_application

os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myproject.settings')
application = get_asgi_application()

Django에서는 ASGI를 지원한다고 해서 모든 코드가 비동기로 동작을 지원하지는 않습니다.

대표적으로 Django ORM은 기본적으로 동기 드라이버(psycopg2 등)를 사용하기 때문에, DB 쿼리 시 해당 스레드가 블로킹됩니다.

def my_view(request):
    result = SomeModel.objects.all()  # 동기 ORM
    return HttpResponse(result)

하지만, Django 4.1 버전 이후부터는 async ORM을 점진적으로 지원하기 시작했고, ORM 뿐 아니라 Django와 Python에서 비동기를 점진적으로 지원하기 위한 노력은 지금도 꾸준히 진행되고 있는 것으로 보여요. (이전 글에서 다룬 GIL Free-threading도 그 일환이죠)

정리

Node에서는 런타임에 내장되어있었기 떄문에, 그리고 기본적으로 비동기를 지원했기 떄문에 다소 많은 차이가 느껴졌습니다.

이전 GIL 포스팅과는 다르게 마냥 부정적으로만 보이지는 않았는데요, 이는 GIL이라는 언어 자체의 레거시와는 느낌이 달랐기 떄문입니다.

GIL은 언어(CPython) 레벨의 문제이고, WSGI는 프레임워크와 웹 서버 생태계의 문제입니다. 흥미롭게도 생태계 전환이 오히려 더 빠르게 진행 중이에요. GIL 제거는 수십 년간 시도 끝에 Python 3.13에서야 실험적으로 도입된 반면, ASGI로의 전환은 FastAPI의 부상, Django 3.0+의 공식 지원 등 이미 활발히 이루어지고 있죠.

특히 Django는 ORM, Admin, Auth 등 많은 기능이 내장되어 있고, 이 모든 것들이 동기 기반으로 설계되어 있잖아요. 이걸 비동기로 전환하려면 프레임워크 전체가 바뀌어야 하는 거니까요. 그래도 Django 4.1부터 async ORM이 점진적으로 지원되고 있고, Python 생태계 전체가 비동기를 향해 나아가고 있으니 긍정적으로 보고 있어요.

그리고..... 개발자의 역량에 따라 동기적인 웹 서버로도 충분히 10M+의 트래픽이 제어 가능하고 인스타라는 선진 사례도 있기 떄문에, 이 모든게 저의 역량에 달린 일이 아닐까..(?????????) 하는 생각도 들었습니다.

다음 Python 관련 스터디는 딱히 정해지진 않았지만, 무언가 정리할 만한 주제를 찾아 돌아오도록 하겠습니다.