WSGI

01무엇이고, 어떤 일을 하나

• Python 웹 프레임워크와 서버 구현의 연결 규약을 정한다.
• 요청 메타데이터와 입력 스트림을 애플리케이션에 제공한다.
• 응답 상태·헤더·본문의 전달 방식을 일관되게 표현한다.

02어떤 순서로 동작하나

1. 환경 구성

   서버가 HTTP 요청을 environ의 메서드·경로·입력 스트림 등으로 표현한다.

2. 앱 호출

   application(environ, start_response) 형태로 동기 callable을 호출한다.

3. 응답 시작

   애플리케이션이 start_response를 통해 상태와 헤더를 알린다.

4. 본문 전송

   반환된 iterable에서 bytes 조각을 읽어 응답 본문으로 보내고 필요한 종료·자원 정리를 수행한다.

03먼저 알아둘 용어와 구성요소

callable

호출할 수 있는 객체이다. WSGI 애플리케이션은 서버가 environ과 start_response를 인자로 호출하고 바이트 본문의 iterable을 얻는 규약을 따른다.

start_response

서버가 environ과 start_response를 넘겨 호출하고 앱은 상태와 헤더를 start_response로 알린 뒤 바이트열들을 생산하는 iterable을 반환한다.

environ

environ은 요청 메서드·경로·서버 정보 등과 입력 스트림을 담는다.

bytes 본문

WSGI 본문 iterable의 각 항목은 bytes이다. str을 UTF-8로 인코딩하여 반환할 때 문자 수와 전송 바이트 수를 구분한다.

Content-Length

한글 문자 수와 전송 바이트 수가 같지 않을 수 있으므로 Content-Length를 len(원문문자열)로 계산하면 잘못된다.

워커

여러 프로세스·스레드 워커를 둘 수 있지만 각 워커의 메모리 상태와 DB 연결 수가 늘어난다는 비용도 함께 고려한다.

04예제로 따라가기

• 본문이 '가'이면 Python 문자 길이는 1이어도 UTF-8 본문 바이트는 3개다. Content-Length는 전송 바이트 수에 맞춘다.
• WSGI 앱이 DB 응답을 동기 대기하면 해당 워커의 요청 자리가 점유되므로 단순히 서버 프로세스가 살아 있다는 정보만으로 여유를 알 수 없다.
• 여러 워커 프로세스의 전역 Python 사전은 자동 공유 저장소가 아니므로 세션 상태를 임의 전역 변수에만 넣으면 요청마다 결과가 달라질 수 있다.

05혼동하기 쉬운 점과 확인 기준

• WSGI의 동기 호출이나 async 함수 안의 동기 DB 호출은 해당 실행 흐름을 기다리게 할 수 있다. await라는 키워드 유무보다 실제 호출이 어디서 양보하는지 봐야 한다.
• 앱은 status·헤더·본문을 만들고 서버 인터페이스가 이를 HTTP로 전달한다. 문자 개수와 바이트 길이, 이미 보낸 헤더 뒤 발생한 예외를 구별해야 응답 오류를 설명할 수 있다.
• WSGI는 HTTP를 새로 정의하는 네트워크 프로토콜이 아니라 서버와 앱 사이 인터페이스 규약이다. 비동기 이벤트 모델인 ASGI와 호출 형태를 섞지 않는다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.