django도 결국 제 위치에서 제 역할을 하는 백엔드의 일부분일 뿐이라 했습니다.
우선 django의 위치와 django에게 도달하기 전을 전체적으로 알고 django에 대해 얘기하는 것이 순서라 생각합니다.
1. 클라이언트 : (요청)안녕?
우선 django가 뭔가를 받기위해 준비한다는 것은, 이 컴퓨터는 '서버'라는 뜻입니다.
서버 : 서비스를 제공하는 컴퓨터
클라이언트 : 서비스를 사용하는 컴퓨터
그렇다면 클라이언트가 우선 django가 있는 컴퓨터를 향해 '안녕?' 이라고 보낼 것입니다.
django가 아니라 django가 있는 컴퓨터에게 보내는 겁니다!
- 이렇게 보내는 것을 'HTTP 통신'을 한다고 하는데 자세한 것은 네트워크 카테고리에 작성하겠습니다.
2. 클라이언트 : ㅇㅏㄴㄴㅕㅇ?
클라이언트가 보내는 것을 이제 전선을 통해 보내려고 합니다. 하지만 그 크기가 너무 커서 잘게 쪼개서 보내게 됩니다. 이 과정을 아는 것도 중요하지만 너무 길어서 네트워크 카테고리에 정리하겠습니다.
그렇게 쪼개져서 보내진 데이터가
Django가 있는 컴퓨터에 도착하여 다시 재조립이 됩니다.
중요한건 Django가 아니라 Django에 있는 컴퓨터에 도착한 것이지 아직 Django에 도착한 것이 아닙니다.
그리고 보냈다고해서 도착한걸 다 받아줘야 할까요?
'?? 갑자기 나한테 왜 인사함?'
이라 해버릴 수도 있잖아요...
3. 서버 : '안녕?' 이라고 보냈네?
그래서 Django가 받기 전에 먼저 컴퓨터 자체에서 받을지 말지를 결정하는 웹 서버 프로그램이 있습니다.
Django를 배우는 우리에게 있어선 Nginx가 되겠군요.
(사실 도착하는건 MAC주소 어쩌구 받을지 말지는 TCP/IP 저쩌구... 좀 더 명확하게 말하자면 nginx는 안받는다는 응답까지 해주는 역할을 합니다.)
Nginx자체로도 많은 내용이 있지만 우선 Nginx가 받는다하고 넘어가겠습니다.
네! 사실 요청은 Django가 받는게 아니라 Nginx에서 제일 먼저 받고 전달을 합니다. 이제 누가 어디서 뭐를 우리에게 보냈는지 알게 되었습니다.
4. 서버(nginx) : '안녕?' 받아라~
자 이제 nginx가 받은걸 django에게 전달하려 합니다.
그런데!!!
사실 받은걸 그대로 전달하기엔 문제가 있습니다. 잠깐 상황을 정리해보겠습니다.
nginx는 날아온 요청을 보고 django에게 전달을 해줍니다. 그런데 django가 보고 일단 매우 화가 날겁니다.
나한테 왔대서 받았더니 자기에게 쓸데없는 말이 너무 많습니다. 어차피 nginx가 어디서왔고 누구에게 왔는지 다 봤으면 그런건 그냥 빼고주지 왜 굳이 그대로 주냐고 얘기합니다.
심지어 난 한국인인데 내용은 영어로 써져 있는 상황입니다. (HTTP 요청이 python으로 작성되어있진 않으니까..)
nginx도 할 말이 있습니다. 오는 요청 확인하고 전달하는게 내 역할인데 왜 뭐라하냐고 합니다.
5. 미들웨어(gunicorn, uwsgi)
그래서 우리 컴퓨터에 일꾼을 하나 더 고용합니다. Nginx와 django 사이의 문제를 해결해 줄 미들웨어입니다!
spring에겐 Tomcat, 우리의 django에겐 gunicorn, uWSGI가 있습니다. (gunicorn 쓰세요.. 자세한건 나중에..)
이렇게 해서 nginx가 gunicorn에게 전달하고, gunicorn이 드디어 django에게 요청을 전달하게 됩니다!
6. 서버 : (응답) 나도 안녕!
그래서 django에서 받은 다음, 앞으로 우리가 구현할 로직에 따라 알맞는 응답을 같은 길을 통해 돌려줄 것입니다.
마찬가지로 gunicorn - nginx - (엄청난 생략) - 클라이언트에게 전달을 하게 됩니다.
정리
이렇게 django는 '백엔드'가 아니라 백엔드 안에서 역할을 맡은 일부분에 불과합니다.
정리라 했지만 끝난건 아니고 다음 글에 각 역할들에 대해 간단한 추가 설명을 할 예정입니다.
