과거의 내가 미래의 나에게
HTTP의 진화에 대한 개인적인 정리 본문
axios를 사용하다가 문득 axios는 어쩌다 나온 라이브러리인지 궁금하게 되었고 이에 대해 거슬러 오르다가 HTTP의 발전과정에 대해서 전반적으로 살펴보게 되었다. 늘 그렇듯 하나의 궁금증이 산을 넘고 넘어 요상한 방향으로 결론나게 되었는데..이 글도 비스무리하게 HTTP 요청 라이브러리에 대해 알아보려다가 HTTP의 성장 과정에 대해서 알아보는 글이 된 것 같다.
이제부터 HTTP가 어떤식으로 성장하고 발전해나갔는지를 알아볼 것인데 HTTP가 등장하게 된 모체인 웹의 역사와 결부되어서 이야기해나가야 할 것이다.
웹의 시작 그리고 HTTP의 탄생
웹의 시작에 대해서는 다른 글에서 썼으니 간단하게 짚고 넘어가도록하자. WWW, 그러니깐 웹이 탄생한 이유는 연구문서나 대학문서들을 저장해서 그것들을 언제 어디서나 그리고 누구나 쉽게 볼 수 있도록 하기 위함이었다. 하이퍼텍스트를 통해 문서 간의 연결을 강화했고 또 인터넷의 발전은 누구나 쉽게 이 저장된 문서들을 볼 수 있도록 하였다.
위와 같은 목적을 달성하기 위해 웹은 서버와 클라이언트의 구조로 이루어지게 된다. 문서들을 저장해놓은 서버와 저장해놓은 문서를 가져와 보여주기 위한 클라이언트(브라우저)로 구성했으며, 이 때 서버에서 데이터를 가져오는 방법을 모아놓은 것이 바로 HTTP인 것이다.
브라우저를 실행시켜서 HTTP 요청으로 서버에 원하는 정보를 요청하면 서버는 해당 데이터를 브라우저로 전달하여 브라우저에 정보를 띄우게 된다. 이것이 웹의 동작 원리인 것이다.
그렇다. 최초의 HTTP는 별 거 없었다. 단지 서버에서 문서를 가져오면 됐으므로 GET 메서드만 존재하였고 응답 또한 그저 HTML 문서를 전달할 뿐이었다.
웹의 발전 그리고 HTTP의 진화
시간이 지나면서 웹은 엄청난 발전을 이룩했다. 인터넷이 발전하여 몇몇 연구원만 브라우저를 사용하는 것이 아닌 많은 사람들이 문서에 접근가능했고, 그러한 사람들이 정보를 올리기도 하면서 포털사이트가 탄생하기까지 이르렀다. 사람들이 밀집된 공간에서는 수많은 아이디어가 탄생하기 마련이고 급기야 웹을 통해 전자상거래까지 이루어지면서 웹은 더이상 단순히 문서보기용 프로그램이 아닌 그야말로 전 세계적으로 펼쳐나가는 웹(World Wide Web)이 되어버린 것이다.
이렇게 웹이 발전하면서 필연적으로 같이 진화한 것이 바로 HTTP이다.
단순히 문서 교환 역할로써는 많은 기능이 더 필요하지 않았지만 다양한 기능이 웹에 요구되면서 사람들은 목적을 이루기위해 각자 HTTP에 여러가지 기능을 추가하였다. 모두가 다른 양식을 사용하여 혼란이 도래하자, HTTP 기본적인 구조를 그대로 유지하면서 다양한 요구사항을 충족시키고 표준화시키기 위해 HTTP를 관리하는 조직이 탄생하였고 여러가지 사양을 정리하여 발표하였는데 이것이 바로 HTTP/1.1인 것이다.
이렇게 웹의 근간을 이루고 있는 HTTP가 정리되기 시작하였고, 그 이후로도 더 다양한 방면으로 다듬어지고 업그레이드되며 풍부해지기 시작한다.
여러 방면으로 업그레이드 되는 HTTP
웹의 진화는 HTTP도 같이 발전하게 만들었다. 여기서 발전이라 함은 단순히 HTTP 자체가 더 강화되는 것 뿐만 아니라 HTTP를 통해서 더 좋은 웹 개발 환경을 만드는 것도 포함되는 것이다.
아래 예시들은 내가 생각하는 HTTP와 연관되어 나오는 개념들로 웹의 발전에 따라 업그레이드된 HTTP와 관련된 기능을 간단히 나열한 것이다.
1. HTTPS
사용자에게 더 뛰어난 사용성을 위해 HTML을 전부 받는 것이 아닌 인터넷을 통해 더 많은 데이터가 오가기 시작했고 이 데이터들 중에는 개인적이고 중요한 데이터도 포함되기 시작한다. 이에 따라 데이터 교환에서 보안적인 요소가 필요하게 되었고 이는 HTTPS 탄생으로 이루어진다.
HTTP는 암호화 되지 않은 텍스트로 통신하기에 타인이 통신 내용을 가로채기에 용이했다. 이러한 문제로 새로 등장한 HTTPS는 통신함에 있어, 통신 주체들이 자신이 신뢰할 수 있음을 증명하는 증명서를 사용하게 하고 또 SSL 또는 TLS라는 프로토콜로 암호화하여 통신의 보안의 질을 향상시켰다.
2. REST
서버와 클라이언트가 데이터를 요청-응답하는 일 이외에도 서버끼리도 서로 데이터를 주고 받는 일이 많아졌다. 웹의 발전은 다양한 서비스가 나오게 만들었고 이에 따라 데이터들끼리도 교환할 일이 잦아진 것이다. 따라서 소프트웨어와 소프트웨어끼리 상호작용할 수 있도록 사전에 정의된 인터페이스인 API가 활발하게 사용되기 시작하였으며, API의 형식이 모든 소프트웨어마다 다르면 곤란하니 이에 대한 구조를 고민하기 시작했는데 여기서 나온 것 중 하나가 REST이다.
< 참조 >
API 구조에 대한 방법론은 REST말고도 다양하다. SOAP, GraphQL 등이 존재하지만 자주 보이는 것은 REST와 GraphQL 정도이다. 방법론에 따라 장단점이 존재하지만 여기서는 특별히 알아보진 않겠다.REST는 기존 HTTP 프로토콜을 그대로 활용하기도 하고 무엇보다 쉽고 간편해서 현재 가장 많이 쓰이는 방법론 중 하나이다.
3. AJAX
서버와 클라이언트가 교환하는 데이터는 HTML 문서 그 자체였다. HTML 문서가 통으로 왔다갔다 하니 불필요한 데이터가 포함되기도 하고 또 페이지를 넘어갈 때마다 화면이 깜빡거리는 등 사용자 경험의 질도 저하되기 마련이었다.
이러한 문제점을 해결하기 위해 등장한 것이 AJAX이다. HTML을 통으로 왔다갔다 하는것이 아닌 브라우저가 서버에 비동기 방식으로 데이터를 요청하고 서버는 데이터를 수신하여 화면을 동적으로 갱신할 수 있게하는 방식이다. 이를 통해 브라우저는 웹페이지의 변경에 필요한 데이터만 전송받아 브라우저에서 일부만 렌더링하는 것이 가능해진다.
AJAX는 복잡한 구문으로 인해 현대에 와서는 ES6에서 지원하는 Fetch를 사용하기도 하고, 혹은 라이브러인 Axios를 사용하기도 한다. Axios 말고도 HTTP 요청 라이브러리는 다양하니 이것저것 보고 싶다면 주소1 혹은 주소2에 들어가서 한 번 비교해보자
4. WebSocket
HTTP는 클라이언트가 요청하고 서버는 응답한다. 이것이 골자이다. 그러나 현대 사회에 와서 클라이언트가 요청하지 않아도 서버에서 데이터를 응답 받는 상황도 필요해지기 시작한다.
이에 따라 등장한 것이 웹소켓으로, 브라우저와 서버 사이의 동적인 양방향 연결 채널을 구성한다. 이를 통해 요청없이 응답을 받아오는 것이 가능해졌다.
마무리
웹 개발자로써 프론트를 담당하던 백을 담당하던 HTTP를 이용하는 것은 당연하다. 현대에 이르러서 많은 개발자들이 더 나은 환경을 마련하기 위해 수많은 기술을 연구했고 또 우리는 지금 그 걸작들을 아무렇지도 않게 사용하고 있다.
이번 글을 쓰게 된 이유는 Axios든 REST든 뭔가 들은 것은 많고 사용해본 것은 많은데 이들이 어떻게 연결되어있는지 감이 안잡혀서 쓰기 시작했었다. 쓰고나니 이들이 1:1로 대응되어 연결되어 있는 것이 아닌 웹의 진화에 따라 산발적으로 진화된 과정이기에 글의 흐름이 다소 어색하게 느껴졌지만 그래도 얼추 이들이 어떠한 과정을 거쳐 나오게 된지 알게된 계기가 되었다.
당장 개발의 결과물을 내야하기에 일단은 이런 기술들을 다짜고짜 쓰고있지만 시간이 나는대로 이 기술들이 어떤 환경에서 나오게 되었고 왜 사용되게 되었는지 알아보는 시간이 필요할 것 같다.
참고 문서
- Ajax 의 개념 - https://velog.io/@olzlel2000/Ajax-%EC%9D%98-%EA%B0%9C%EB%85%90
- HTTP의 진화 - https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
- 웹 개발자라면 알고 있어야 할 HTTP의 진화 과정 - https://yozm.wishket.com/magazine/detail/1686/
- [WEB] 🌐 웹 소켓 (Socket) 정리 (역사부터 차근차근) - https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-%EC%9B%B9-%EC%86%8C%EC%BC%93-Socket-%EC%97%AD%EC%82%AC%EB%B6%80%ED%84%B0-%EC%A0%95%EB%A6%AC