Python WSGI의 역사
wsgi는 2000년대 초반 Phillip J. Eby 라는 사람이 만들었는데, wsgi가 존재하기 전, 기존에 존재하던 Apache 모듈의 일종인 mod_python이 공식적인 명세도 없을 뿐더러 불안정했기 때문에 개발자들은 다른 해결책을 찾아나서기 시작했다.
wsgi는 CGI(Common Gateway Interface)의 일종으로, web이 이제 막 걸음마 단계를 시작했을 적에 CGI는 수많은 언어에서 문제 없이 작동한다는 이유로(애초에 CGI 외에 다른 선택권이 없기도 했다) 기하급수적으로 사용량이 증가했다. 하지만 CGI는 너무 느리고 제한사항도 많았을 뿐더러, pyton app에서 CGI, mod_python, Fast CGI 등등 만ㅇ르 사용했다. wsgi는 이와중에 프레임워크의 웹서버로, route web에서는 표준 인터페이스로 개발되었다.
Server 와 Web app
WSGI는 두 가지 부류가 있다.
1) Nginx나 Apache 같은 server-often high-profile 웹 서버
2) python script로 짜여진 web app
server는 web app과 그에 연관되어있는 정보, callback 함수등을 실행한다. request는 app 단에서 실행되며, reponse는 callback 함수를 이용해서 server로 되보내진다.
가끔씩 server와 web app 사이에 한개 이상의 wsgi middleware가 존재할 때가 있는데, middleware는 app objects에 직접적으로 request를 보내거나, load balancing 등등 수많은 역할을 위해 이용된다.
python framework 인 django, cherrypy, flask, web2py 들에서 WSGI를 지원하는 것이 그 예라고 할 수 있다.
왜 wsgi가 필요하지?
그래 넌 아마 "아니 그건 됬고, 왜 wsgi가 필요한 거야?" 라고 다시 물어볼 수 있다.
- wsgi server는 많은 request들을 다룰 수 있도록 설계되었다. framework 들은 스스로 수천개의 request들을 실행하고 최고의 방법으로 처리할 수 있도록 설계되어 있지 않다. (django 의 경우 manage.py runserver로 배포하면 안된다는 소리다.)
- wsgi는 python web 개발 속도를 올려준다. 그 이유인 즉슨 wsgi의 기초적인 것들만 알아도 사용하는데에 아무런 문제가 없기 때문이다. 만약에 당신이 TurboGears, Django, cherryPy를 사용한다면, 당신의 framework가 wsgi 표준을 어떻게 사용하는지 굳이 알 필요는 없다. 하지만 확실히 wsgi에 대해 안다면 도움이 된다.
- wsgi는 당신이 stack components를 유연하게 바꿀 수 있도록 도와준다.