이 포스트는 널널한 개발자님 강의를 참조하여 작성한 포스트입니다.
그림 한 장으로 외워서 끝내는 웹 서비스 구조 기본이론
웹 서비스 기본 구조
네트워크같은 인프라구조를 공부할 때 가장 중요한 것이 뭐냐면 전체적인 구조를 이해하는 것이다. 웹서비스에서 쓰이는 기본 프로토콜이 HTTP이다. 근데 HTTP라는 것은 TCP/IP연결 다음에 존재한다. 그러니까 HTTP 트래픽이다 하는 것은 소켓 수준에서 만들어진 것이고 따라서 스트림 즉, 끝을 알기 어려운 데이터가 쭉 나열진 형태에서 파생된 것이다. 문제는 네트워크(TCP/IP와 같은 인터넷 네트워크)로 무언가를 보낼 때는 IP 최대크기 단위 MTU가 1500 밖에 안되니까 이 스트림을 TCP 스택 수준에서 짜른다. 이 짤려진 조각 1개를 세그먼트라고 한다면 이 세그먼트를 패킷으로 Encapsulation 해서 전송한다. 이렇게 스트림 데이터는 분해가 일어난다. 그래서 HTTP 트래픽은 가로형태로 데이터를 이어서 이걸 조각내서 패킷으로 만들어서 IP 스택쪽에서 전송을 한다.
그런데 웹 이야기를 할 때는 이런 세그먼트니 패킷이니 이런 이야기는 하지 않는다. 그리고 송수신 프로토콜 HTTP는 문자열로 되어 있고 기본구조는 굉장히 간단하다. 즉, 클라이언트에서 문서를 달라 요청하고 서버측에서 문서를 보내는 구조며 이런 과정들이 하나의 쌍으로 이루어진다. 그러면 이 웹서비스 기술들을 종합해서 이야기 해보자.
앞서 우리가 HTTP를 비롯해서 웹 이야기를 이야기하면서 언급하신 분이 팀 버너스리에 대해 이야기를 하였다. 웹을 이루는 근간의 기술이라는 것은 하나의 HTML인것이고 그것을 실어나르는 HTTP가 가장 기본이 되는 것이다. 초창기엔 PC를포함해서 위의 그림처럼 PC 1대가 인터넷과 연결되어 있다하고 어떤 서버가 있다 해보자. 그 때 이 서버를 웹서버라 해보자. 근데 사실 이 웹서버와 인터넷 사이에는 장치 3개가 존재하고 이것이 연결되어 있는데 이 장치에 대해서는 나중에 언급하도록 하자. 일단 먼저 PC수준에서 이야기 해보자.
이 PC는 웹 클라이언트인데 기본적으로 브라우저일 것이다. 중요한 것은 웹기술이라는게 HTML과 HTTP로 구현된다고는 하지만 대전제가 무엇이냐면 클라이언트와 서버간에 TCP연결을 전제하고 있다. 그니까 TCP/IP기반에서 연결을 기반으로 HTTP 통신이 이루어지는 것이다. 그런데 연결이라는 애기하면서 상태 이야기를 했었는데 여기서 모순되는게 HTTP의 특징중 하나가 무상태(stateless)를 나타낸다는 것이다. 이 모순점은 있다가 이야기를 이어가도록 하자.
이런 상태에서 팀 버너스리가 초기에 웹을 만드셨을 때 기본적으로 HTML이라는 것은 문서였다. 즉, 초창기 웹 클라이언트에 해당되는 브라우저의 본질은 문서뷰어였다. 그런데 기존의 문서뷰어랑 결정적으로 다른 점은 당대 신기술이였던 인터넷이라는 기술을 적용해서 서버에 있는 리소스를 브라우저에 전달하는건데 즉, 브라우저 주소창에 url을 입력하고 엔터를 치면 해당 도메인을 DNS서버를 통해 IP주소를 획득하고 IP주소를 통해 접속을 하고 TCP연결을 실시하고 그것을 기반으로 HTTP 통신이 이루어진다. 근데 HTTP통신이 이루어지는 시점에서 클라이언트에서 서버쪽으로 request가 나가면 이 때 이 request는 보통 http.request.method==GET 문서를 호출하는 것이다. 그러면 서버는 이러한 request를 받고 해당되는 response 문서를 보내준다. 그러면 클라이언트 입장에서는 요청 url에 대한 화면으로 전환이 된다. 이것이 초창기 웹의 형태였다. 그리고 이 문서 안에는 link가 있으니가 이 링크를 클릭하여 마치 우리가 주소창에 url을 입력한 것처럼 그 과정이 되풀이 되는 거였고 이것이 팀 버너스리가 추구한 초창기 웹의 형태였다.
💡 참고
개발자들은 알만한 이야기인데 소프트웨어를 개발할 때 개발 시, 설계원칙이라는 것이 매우 중요하다. 이 설계원칙을 보면 결국 항상 3가지를 나눠라 되어 있는데 다음과 같다.
1. UI
2. Data
3. 제어체계
이런 설계원칙의 핵심이 최근 들어서 보면 무엇에 가깝냐면 유지보수 문제와 가깝다. 그래서 이 3가지를 섞어서 개발하면 나중에 이 3가지중에 어느 한가지를 수정하면 다른 부분도 수정을 해야하는 사태가 발생한다. 그래서 가급적 유지보수성을 높이기 위해 이 3가지를 나눈다.
이런것을 고려해 웹이 어떻게 발전하냐면 처음에는 HTML문서가 잘 전달되니 좋았는데 조금 생각을 해버니 문서를 예쁘게 꾸미고 싶다는 생각이 든 것이다. 그래서 이 문서를 예쁘게 꾸미기 위한 문법들이 개발되고 위의 원칙을 근간해 만들어진게 CSS이다. 즉 이제 요청을 할 때 HTML문서뿐만 아니라 CSS도 요청을 하게 되었다.
이렇게 웹이 발전하다보니 1990년대 중반을 지나면서 새로운 브라우저도 탄생을 하게 되었는데 그것이 책에서 볼법한 브라우저인 NetScape이다.
문서라고 하는게 정적인 문서 즉, 신문이나 책같은 문서였는데 이것을 동적인 요소 + 움직임을 넣어 발전된 문서를 만들려고 시도하였다. 그래서 그렇게 동적인 요소를 넣으려다보니 이 동적인 요소에는 일정의 규칙이 따르기 마련이고 이 규칙이란 것을 script형태로 만들게 되었다. 그렇게 탄생한것이 Mocha Script였고 이것이 몇 달 뒤에 Live Script가 되고 또 몇 달뒤에 우리가 아는 Javascript가 되었다. 이렇게 이러한 노력이 더해지면서 웹은 발전되어왔다. HTML문서만 날라오면 이 문서의 내용을 화면에 렌더링하는데 그 전에 구문분석 과정도 추가가 되었다. 즉, text와 tag부분을 나눠서 이 tag를 해석해서 tag에 맞게 렌더링 과정이 필요했다. 그래서 이런 것들을 해주는 엔진이 나왔는데 바로 parser rendering engine이 포함되었으며 추가적으로 javascript의 등장으로 JS Engine까지 기본 구성요소로 포함되었다. 이제 응답을 보낼때 서버는 HTML,CSS,이미지뿐만 아니라 JS도 같이 보낸다. 즉, 정적인 문서에서 동적인 문서형태로 발전되어 왔다.
초창기 웹의 HTTP 메서드로는 GET요청밖에 없었다. 즉, 클라이언트가 HTML문서자료를 요청하면 서버는 그에 맞는 HTML문서를 응답해주는 단방향 상호작용이였다. 즉, 적극적으로 사용자가 개입할 수 있는 형태로 발전되지 못했었다. 이런 부분을 해결하고자 많은 고민을 하게 되고 방법론이 등장하게 되었는데 그게 POST이다. 예를 들어 로그인이라는 시나리오를 생각해보자, ID를 입력하는 창이 있을 것이고 PW를 입력하는 창도 있을 것이고 로그인 버튼도 존재할 것이다. 이 버튼을 클릭하여 POST 메서드를 날려서 양방향 상호작용을 하게 된다.
이 모든 방향성이 양방향 상호작용이 들어가게 되면 필연적으로 따르게 되는게 있는데 그것이 바로 상태전이다. 그런데 HTTP는 stateless이니 이 상태전이를 어딘가 기억을 시켜야 한다. 근데 이 기억을 클라이언트, 서버 둘다 해야함으로 이 기억을 클라이언트, 서버 둘다 구현이 되어야 할 것이다. 클라이언트측에서는 Cookie형태로 기억한다. 이 Cookie는 쉽게 생각해서 상호작용을 위한 기억의 부산물로 암기하자. 서버는 여러 클라이언트에 대한 기억을 저장해야하고 양도 방대하다 보니 서버쪽에서 직접 구현을 하지 않고 DB서버를 만들어 저장을 하게 된다. 그래서 웹 서버 외에 DB서버가 생겨난 것이다. 그리고 이 서버에서 클라이언트의 무언가를 기억하게 된다. 그럼 다시 예시로 와서 로그인을 하는데 ID: tester, PW: 1234라고 가정하고 POST를 보내면 ID=tester&PW=1234형태로 넘어가게 된다. 그럼 여기서 관점상 중요한게 뭐냐면 tester, 1234 이런것들이 서버관점에서 원격지 사용자 입력으로 봐야한다. 이 원격지 사용자 입력이라느 것을 서버관점에서는 절대 신뢰해서는 안된다. 이것은 반드시 검증이라는 것을 필요로 한다. 그래서 이 검증을 하는 방법으로 넘어온 ID와 PW값을 통해 DB서버에 SQL문 형태로 질의를 하게 된다. 그런데 문제는 웹서버가 DB서버를 직접 두지 않고 WAS라는 중간서버를 두어서 역할을 담당하게 된다. 이 서버를 통해 DB와 연동을 하게 된다. 그래서 역할을 살펴보면 웹 서버는 정적 리소스를 송수신하는 담당을 하고 DB서버는 자료를 담당하며 WAS는 연산을 처리하는 역할을 한다. 또한 WAS가 DB서버와 연결할때 ODBC, JDBC같은 인터페이스를 통해 연결이 되어 있고 웹서버에 넘겨온 검증 값들을 DB서버에 넘겨 SQL문형태로 질의를 하고 질의 결과가 있다면 해당되는 동적 HTML문서를 클라이언트에 넘겨주고 아니면 NOT FOUND에 해당되는 에러 HTML문서를 보여주게 된다.
WAS 서버를 보면 왼편에는 View부분을 담당하는 웹서버가 오른편에는 Model를 담당하는 DB서버 그리고 WAS 자체의 Control기능이 있다해서 이것을 MVC 구조라고 한다.
