WSGI와 ASGI 완벽 이해: Python 웹 서버 구조부터 동작 원리까지
Python 웹 개발을 하다 보면 WSGI와 ASGI라는 단어를 자주 보게 됩니다. 하지만 이름만 보고는 ‘이게 대체 뭐지?’ 싶은 경우가 많죠. 이 글에서는 Python 웹 서버 구조를 이해하기 쉽게 풀어보고, WSGI와 ASGI가 각각 무엇이며 어떻게 다른지 실제 예시를 통해 살펴보겠습니다.
1. Python 웹 서버란 무엇인가
Python 웹 서버는 클라이언트(사용자)로부터 오는 요청(request)을 받아, Python 애플리케이션에게 전달하고, 그 결과(response)를 다시 사용자에게 돌려주는 역할을 합니다.
쉽게 말해, 웹 서버는 “사용자 ↔ Python 코드” 사이의 중계자입니다.
일반적으로 Python 웹 서버는 다음과 같은 일을 수행합니다.
- 클라이언트의 HTTP 요청을 받습니다.
- 해당 요청을 Python 웹 애플리케이션에 전달합니다.
- 애플리케이션이 생성한 응답 데이터를 클라이언트에게 반환합니다.
이때, 이 연결 통로의 규칙이 바로 WSGI나 ASGI입니다.
웹 서버의 예시로는 다음과 같은 것들이 있습니다.
- Gunicorn: Python에서 가장 많이 사용하는 WSGI 서버
- Uvicorn, Daphne: ASGI 서버로 빠른 비동기 처리가 가능합니다
2. WSGI와 ASGI가 무엇인가
2.1 WSGI (Web Server Gateway Interface)
WSGI는 2003년에 제정된 Python 웹 서버와 애플리케이션 간의 통신 표준입니다. ‘동기(synchronous)’ 방식으로 작동하며, 한 번에 한 요청씩 처리하는 구조입니다.
- WSGI는 요청이 완료될 때까지 다음 요청을 기다립니다.
- CPU나 I/O 작업이 간단한 경우엔 충분히 효율적입니다.
- Django, Flask 같은 기존 프레임워크는 기본적으로 WSGI를 사용했습니다.
대표적인 WSGI 서버 Gunicorn, uWSGI
WSGI 구조 요약
[Client] → [Web Server(Nginx)] → [WSGI Server(Gunicorn)] → [Python App(Django)]2.2 ASGI (Asynchronous Server Gateway Interface)
ASGI는 비동기(asynchronous) 처리를 지원하는 WSGI의 차세대 버전입니다. Python의 async/await 문법을 활용하여, 여러 요청을 동시에 처리할 수 있습니다.
- WSGI의 한계를 극복하기 위해 만들어졌습니다.
- Django Channels 프로젝트에서 처음 등장했습니다.
- WebSocket, HTTP/2 같은 실시간 양방향 통신도 지원합니다.
- 동기와 비동기 애플리케이션을 모두 관리할 수 있습니다.
대표적인 ASGI 서버: Uvicorn, Daphne, Hypercorn
ASGI 구조 요약
[Client] → [Web Server(Nginx)] → [ASGI Server(Uvicorn)] → [Python App(FastAPI)]3. Python 웹 서버와 어떻게 통신하는가
웹 서버 자체는 Python 코드를 직접 이해하지 못합니다. 그래서 “Gateway Interface”라는 표준이 필요합니다.
- WSGI는
def application(environ, start_response):형태의 동기 함수로 통신합니다. - ASGI는
async def app(scope, receive, send):형태의 비동기 함수로 통신합니다.
서버와 애플리케이션은 HTTP 요청 정보를 딕셔너리로 주고받으며, 응답은 함수 호출 형태로 반환합니다.
3.1 WSGI 동작 방식
- 클라이언트가 HTTP 요청을 보냅니다.
- 웹 서버(Nginx)가 요청을 WSGI 서버(Gunicorn)에 전달합니다.
- WSGI 서버는 요청 정보를
environ으로 묶어 Python 앱의application함수로 보냅니다. - 앱이 응답을 생성하면
start_response를 통해 결과를 반환합니다.
3.2 ASGI 동작 방식
ASGI에서는 요청과 응답을 비동기 이벤트 흐름으로 처리합니다.
- 웹 서버가 ASGI 서버(Uvicorn)에 요청을 전달합니다.
- ASGI 서버는 요청 정보를
scope라는 객체로 넘깁니다. - Python 애플리케이션은
receive와send코루틴을 통해 클라이언트와 통신합니다.
4. 예시 코드 및 아키텍처 설명
4.1 WSGI 예시 코드
def application(environ, start_response):
status = '200 OK'
response_body = b"Hello, WSGI World!"
headers = [(b'Content-Type', b'text/plain')]
start_response(status, headers)
return [response_body]
# 이 코드는 Gunicorn 같은 WSGI 서버를 통해 실행됩니다.
# 예: gunicorn myapp:applicationWSGI 아키텍처
Client ---> Nginx ---> Gunicorn (WSGI 서버) ---> Flask/Django 앱4.2 ASGI 예시 코드
import asyncio
async def app(scope, receive, send):
assert scope['type'] == 'http'
await send({
'type': 'http.response.start',
'status': 200,
'headers': [(b'content-type', b'text/plain')],
})
await send({
'type': 'http.response.body',
'body': b'Hello, ASGI World!',
})
# Uvicorn으로 실행 예시:
# uvicorn main:app --reloadASGI 아키텍처
Client ---> Nginx ---> Uvicorn (ASGI 서버) ---> FastAPI/Django Channels 앱5. 결론
WSGI와 ASGI는 모두 Python 웹 서버와 애플리케이션 간의 ‘소통 규칙’입니다.
| 비교 항목 | WSGI | ASGI |
|---|---|---|
| 처리 방식 | 동기(synchronous) | 비동기(asynchronous) |
| 웹 서버 예시 | Gunicorn, uWSGI | Uvicorn, Daphne |
| 프레임워크 | Django, Flask | FastAPI, Django Channels |
| 실시간 기능 (WebSocket) | ❌ 지원 안 함 | ✅ 지원함 |
| 장점 | 구조 단순, 안정적 | 고성능, 병렬 처리 가능 |
| 단점 | 느리고 실시간에 부적합 | 구조가 다소 복잡 |
요약하자면
- 기존의 간단한 API 서버나 중소규모 애플리케이션은 여전히 WSGI가 충분히 좋습니다.
- 대규모 트래픽, 실시간 통신(채팅, 스트리밍 등)이 필요한 애플리케이션은 ASGI가 훨씬 효율적입니다.
WSGI는 안정된 표준으로 단단한 기반을 제공했고, ASGI는 그 위에 현대적인 비동기 생태계를 확장시키는 역할을 하고 있습니다.
👉 한 문장 정리
WSGI는 과거와 현재를 잇는 ‘표준 게이트웨이’, ASGI는 미래의 Python 웹 서버 표준입니다.
