[DB] 멋쟁이사자처럼 9기 백엔드 스터디 (3) - 서버와 배포

이번 주 벡앤드 스터디는 서버에 대해 좀 더 자세히 배우는 주제로 총 세 가지 질문이 주어졌다. 개수는 적지만 어디선가 들어본 말이 정의하기에는 더 어려운 듯이 서버라는 개념은 어디선가 들어봤지만 정확히 어떤 일을 하는지 설명하기는 어려웠다. 이번 시간을 통해서 서버에 대해 방대하진 않더라도 누군가에게는 설명할 수 있는 실력을 키우는 것이 내 목표이다.

728x90

질문 1 : 웹 서버란 무엇일까요?

'서버' 라고 하면 가장 먼저 떠오르는 것은 영화 속에서 한 방을 가득 채우고 있는 컴퓨터들 사이로 몰래 지나가서 그 사이에 있는 컴퓨터로 타타닥 몇 글자 입력해서 해킹할 때, 바로 그 방을 가득 채우고 있는 컴퓨터가 생각나는가? 아니면 학교 본관 중에 학생들의 발걸음이 잘 닿지 않는 곳에 거대한 컴퓨터들로 가득찬 방이 생각나는가?

 

물론 지금 머릿 속에 생각난 것도 서버가 맞다. 웹 서버에는 크게 두 가지가 있는데 하드웨어 웹 서버와 소프트웨어 웹 서버가 있다.

하드웨어 웹 서버

하드웨어 웹 서버란 웹 사이트의 컴포넌트 파일을 저장하는 장소로 컴포넌트 파일에는 이미지 파일, css 파일, js 파일 등 이 있고 이 파일들을 소비자에게 전달한다. 또한 웹 서버는 인터넷에 연결되어있고 사용자는 도메인을 통해 웹 서버로 접속할 수 있다.

소프트웨어 웹 서버

소프트웨어적으로는 사용자가 어떻게 호스트 파일들에게 접근하는지 관리한다. 대표적인 예로는 HTTP 서버가 있다.

 

 

그러면 소비자는 웹 서버에 어떻게 접근할까?

 

소비자는 우리가 흔히 아는 크롬, 익스플로러, 파이어 폭스 등 브라우저를 통해 접근한다. 이 브라우저에서 웹 서버에서 불려진 파일을 볼 때 브라우저는 HTTP를 통해 파일을 요청한다. 이 요청이 올바르게 웹 서버(하드웨어)에 도착하게 되면 HTTP 서버(소프트웨어)는 요청된 파일을 보내준다.

간략하게 설명하면 이렇다.

 

그런데 왜 내가 장고로 서버를 만들면 다른 사람들과 DB를 공유하지 못했을까?

 

그 이유는 내가 장고로 만든 서버는 정적 서버이기 때문이다.

 

정적 서버와 동적 서버

정적 웹 서버는 HTTP 서버가 있는 컴퓨터로 이뤄져있으며 서버에서 바로 내 브라우저로 요청된 파일이 온다.

동적 웹 서버는 정적 웹 서버에 추가적인 기능을 더한 서버로 애플리케이션 서버가 HTTP 요청을 통해 보낼 파일들을 업데이트하기 때문에 동적 웹 서버라고 불린다.

 

질문 2 : 웹 어플리케이션 서버(WAS)란 무엇일까요?

먼저 앞에서 알아본 정적 웹 서버와 동적 웹 서버의 가장 큰 차이점은 무엇일까?

 

바로 웹 애플리케이션 서버의 유무였다. 그럼 이제 웹 애플리케이션 서버의 역할을 조금이나마 느낀 분들이 있을 것이다.

웹 애플리케이션 서버는 사용자가 요청하는 HTTP 요청 방식을 통해 컴퓨터나 장치에 비즈니스 로직을 통해 구현된 동적 서버 컨텐츠를 수행한다. 대표적으로 데이터베이스를 만들어서 사용자에게 편의성을 제공한다. 그 외에도 여러 프로그램 실행 환경과 여러 개의 트랜잭션을 관리하는데 트랜잭션은 DB에 밀접한 영향을 끼친다.

 

우리가 사용하는 인터넷은 대부분 동적 서버이다. 근데 왜 둘을 합치지 않고 나눠서 사용할까?

 

가장 큰 이유는 기능을 분리하여 서버의 부하를 막는 것이다. 웹 애플리케이션 서버는 DB 조회, 다양한 로직 수행 등 여러 가지로 바쁜데 기본적인 정적 컨텐츠까지 맡아서 하기엔 무리가 있기 때문이다. 또한 여러 개의 WAS로 나누면 사용자가 어떤 언어를 쓰더라도 처리할 수 있는 언어의 개수가 늘어나서 사용자가 사용하기 편리할 수 있다. 결론적으로 말하면 자원을 효율적으로 사용하고 유지 보수 및 장애 극복에 있어서 둘을 분리해서 사용한다.

 

질문 3 : Django에서 제공하는 Runserver로 배포를 하면 안되는 이유는?

앞서 질문에 대한 답을 읽은 사람은 질문3에 대해 이렇게 생각할 수 도 있다. 혹시 장고는 정적 웹 서버라서 안되는 것인가?

아쉽게도(?) 장고는 웹 애플리케이션으로 runserver를 하면 동적인 페이지를 볼 수 있다. 그러면 왜 runserver로 배포를 하면 안될까??

 

장고는 HTML과 CSS, JS를 사용하긴하지만 기본적으로 Python으로 이뤄져있다. 그리고 장고는 웹 애플리케이션 서버로 웹 서버에게 도움을 주는 존재이다. 하지만 흔히 사용하는 아파치, Nginx 등 웹 서버는 장고의 말을 이해하지 못한다. 바로 파이썬 코드를 해석하지 못하는 것이다. 그래서 통역기 느낌으로 WSGI를 사용한다.

 

WSGI란?

WSGI는 Web Server Gateway Interface의 줄임말로 파이썬의 표준 게이트웨이 인터페이스이다. WSGI는 앞에서 나왔듯이 웹 서버와 애플리케이션 서버 사이에서 인터페이스 역할을 한다. 

그럼 WSGI가 일하는 방식을 살펴보자.

 

1. 사용자(클라이언트)가 요청을 보낸다.
2. 웹 서버에서 요청을 받는다. 정적인 페이지를 요청했다면 웹 서버 자신이 처리를 하고 동적인 페이지를 요청했다면 WSGI 서버(미들웨이 서버라고도 부른다)를 호출한다.
3. WSGI 서버는 WSGI를 사용하는 웹 애플리케이션인 장고를 호출한다.
4. 장고는 요청에 따라 DB를 만지면서 알맞은 처리를 수행한다.
5. 수행 결과를 WSGI 서버를 통해 내보내고 웹 서버는 전달받은 내용을 사용자(클라이언트)에게 보낸다.

복잡하게 느껴지지만 웹 어플리케이션 서버가 번역기를 달았다고 생각하면 편하다.

 

자, 그러면 왜 runserver를 배포하면 안될까?

바로 장고는 웹 애플리케이션이기 때문에 단순한 테스트용으로만 사용해야한다. 그렇지 않으면 사용자가 보낸 요청을 하나 하나 확인하고 요청에 따라 맞는 웹 어플리케이션을 호출하는 과정을 처리할 웹 서버가 없기 때문이다. 물론 장고 공식 문서에도 검증되지 않은 방식이니 배포할 때는 다른 방식을 쓰라고 나와있지만 문서를 보지 않더라도 이러한 처리과정을 알고 있으면 하면 안된다는 것을 배울 수 있다.

 

3주차를 마치며..

이번에는 서버에 대한 내용을 배웠는데 그동안 runserver를 하거나 서버 구축 이라는 말을 할 때는 가벼이 여겼지만 이제는 뭔가 구조화된 형식을 알 것 같아서 값비싼 지식이 되었던 것 같다. 게다가 백엔드 개발자를 희망하지만 서버라는 것을 명확히 알지 못했다는 것이 부끄러웠다. 점점 알아갈 수 록 알아야할 지식이 많아진다는 것을 깨닫게 되는 스터디 시간이었다.