* 이 포스트는 학습 과정에서 그 내용을 기록한 글이기에 부정확한 정보가 포함될 수 있습니다. 따라서 해당 글은 참고용으로만 봐주시고 틀린 부분이 있다면 알려주시면 감사하겠습니다. 또한 학습이 진행됨에 따라 언제든지 글이 수정될 수 있는 점 참고해주세요.
* 비유는 언제나 원관념이 일정 부분 희생됩니다. 이를 감안하셔서 너무 비유에 매몰되지 마시고 처음 학습하신다면 스스로 정확한 개념을 따로 더 학습하시길 바랍니다.
😄 이 글은 개발자들 간 API 통신에 대해 다루기에 기본적으로 개발자들을 위한 글이지만 개발에 입문하시는 분들이나 관심이 있으신 일반인분들도 이해하실 수 있게 풀어서 작성합니다. 중간중간 이해가 어려울 수 있는 부분들은 refer를 추가하므로 보시는데 큰 어려움은 없으실 겁니다.
안녕하세요? 블로그에 어떤걸 포스팅하는게 정확히 8개월만이네요 하하... 취업 준비하고 입사 후에 적응하느라 많이 바빴습니다...는 핑계겠죠?
아무튼 이번에 입사해서 일을 배우다보니 클라이언트 서버 API 통신에 대해 다시 정리해보는 시간을 갖게 됐고 블로그에 포스팅하기 좋을 것 같아서 이렇게 글을 작성하게 됩니다. 아무래도 제가 백엔드 개발자다 보니 백엔드 개발자의 입장에서 통신을 살펴 볼 것이기에 너무 자세하게 프론트엔드 측 지식을 다루진 않을 것이고 가볍게 읽기 좋은 포스팅이라고 생각하고 봐주세요.
글이 길어질 것 같아서 시리즈로 포스팅하겠습니다. 이 글에서 다룰 첫번째는 Client-Server 모델 구조입니다.
# 클라이언트-서버 모델
클라이언트와 서버로 흔히 알려진 Client-Server 모델(이후 C/S 모델로 줄이겠습니다)를 한 마디로 정리하면 두 개의 컴퓨터가 서로 통신하는 방식 중 하나라고 말할 수 있을 겁니다. 두 개의 컴퓨터가 서로 통신하는 방식에는 여러 가지가 있습니다. 뒤에서 자세히 다룰 것이기에 간단히 꼽아보자면 다들 익숙하실 P2P 모델이 있습니다. 더 나아가 우리가 대부분 사용할 어플리케이션의 통신에 있어서는 주로 C/S 모델을 채택한다고 생각하시면 됩니다.
가게에서 물건을 주문하는 손님처럼 네트워크로 정보를 요청하는 역할인 컴퓨터를 클라이언트라 부릅니다. 그 예로 우리가 사용하는 크롬이나 엣지 등 브라우저가 있습니다. 사용자가 웹사이트를 방문할 때 서버에게 요청을 보내 원하는 정보(웹 페이지 등)을 가져옵니다. 물건을 주문했으면 그 주문에 맞는 물건을 내주는 점원처럼 요청한 정보를 처리하는 역할을 가진 컴퓨터를 서버라 합니다. 이 서버는 워낙 평소에 추상적으로 사용되어 예시를 들기보단 뒤에서 더 자세히 설명하겠습니다.
이 클라이언트와 서버의 관계를 보통 네트워크 아키텍쳐 또는 분산 어플리케이션 구조라는 용어로 부르는데 우리는 C/S 모델을 이 중 네트워크 아키텍쳐 중 하나로 간주하겠습니다. C/S 모델은 네트워크의 탄생 이후부터 아키텍처의 주류에 항상 있어 왔지만 정확한 C/S 모델의 이해를 위해선 네트워크 아키텍처의 변천사를 짧게 알아봐야합니다.
# 클라이언트-서버 모델의 초창기
1960~70년대 당시에는 네트워크라는 개념도 희박했었기에 거의 모든 컴퓨팅 시스템은 로컬에서 구축, 사용되었습니다. 그렇기에 중앙에 위치한 메인프레임(Mainframe) 컴퓨터가 모든 컴퓨팅 자원을 제공하고, 사용자들은 이를 터미널을 통해 접근했습니다. 이 방식을 메인프레임-터미널 모델이라 부릅니다. 이 모델에서 사용되는 터미널은 정말 단순한 입출력 장치로서 작동했으며 거의 모든 처리는 중앙에 위치한 메인프레임에서 이루어졌습니다. 그 예로는 IBM 메인프레임이 존재합니다.
80년대 우리에게 익숙한 PC가 도입되었고 기존의 단순한 입출력 역할만 했던 터미널과는 다르게 중앙과 컴퓨팅 자원을 공유하고 연산이 충분히 가능했습니다. 따라서 우리에게 익숙한 C/S 모델은 이 때부터 주로 사용되었습니다. 물론 지금처럼 클라이언트인 브라우저가 할 수 있는 기능을 하기엔 이 때 PC는 성능적으로 너무 안 좋았기 때문에 현 방식과는 큰 차이가 존재하지만 C/S의 기본 개념은 동일했습니다. 이 때의 C/S 모델은 클라이언트에서 직접 DB에 접근하는 경우가 많았고 이를 2-티어(2-Tier) 아키텍처라고도 부릅니다.
이후 90년대에 들어서 중앙의 컴퓨터가 너무 많은 부하를 받고 비용이 증가하자 P2P (Peer-to-Peer) 아키텍처가 등장했습니다. P2P를 간단하게 소개하면 네트워크 상의 컴퓨터들이 서버와 클라이언트 구분 없이 모두 대등한 지위에서 데이터를 주고받는 방식인데 이 방식에선 각 컴퓨터는 다른 컴퓨터와 데이터를 직접 공유할 수 있는 권한을 가집니다. 대표적으로 우리가 아는 웹하드, 토렌트 같은 파일 공유 프로그램이 이 방식입니다.
P2P 아키텍처는 물론 각 컴퓨터들의 자원을 공유시켜 효율적인 비용 관리에서 그 강점이 존재했지만 네트워크 애플리케이션의 복잡성이 너무 증가하고 사용자들의 요청이 엄청나게 늘어난 환경에선 사용하기 매우 어려웠습니다. 그래서 등장한 것이 3-티어(3-Tier) 아키텍처입니다. 이 아키텍처는 크게 프레젠테이션 레이어(UI), 비즈니스 로직 레이어, 데이터 레이어로 나뉘는데 개발자들 입장에선 ‘어? 지금 내가 접하고 있는 모델이 이건데?’라고 생각하실겁니다. 정확합니다! 현대 웹 어플리케이션의 대부분은 C/S 모델이라 통용되지만 정확히는 이 3-티어(3-Tier) 아키텍처라고 부르는게 맞습니다.
# 3-tier의 등장 이후 클라이언트-서버 모델
이 3티어의 등장 이후 생긴 모든 네트워크 아키텍처는 어떻게 보면 이 3티어 C/S 모델의 단점을 보완하기 위해 생겼다고 해도 무방합니다. 2000년대 들어서 등장한 서비스 지향 아키텍처(SOA, Service-Oriented Architecture)는 네트워크 모델이지만 그보단 어플리케이션 통신 방식이라고 이해하는 것으로 생각하는 것이 편합니다. SOA는 서로 다른 시스템들이 독립적인 서비스로 개발되고 제공되며, 이러한 서비스들이 네트워크를 통해 서로 표준화된 인터페이스로 통신할 수 있도록 설계된 아키텍처입니다. 일반 사용자 입장에서 딱 알아들을만한 예시가 없어 부연 설명을 더 하자면 SOA는 재사용성에 초점을 맞춰 SOAP이나 REST같은 인터넷 데이터 교환 메커니즘을 API로 구현하는 등의 설계 방식이라고 보시면 됩니다.
SOA는 이후 2010년대에 대두된 마이크로서비스 아키텍처(MSA, Microservices Architecture)와 비교해서 이해하면 편한데 MSA란 하나의 어플리케이션에 존재하는 결제, 인증, 유저관리 등 각 주요 기능들을 하나의 모듈별로 묶어 각 모듈은 독립적으로도 개발, 배포, 확장이 가능하며 이 모듈들이 연결되어 하나의 어플리케이션을 이루도록 하는 설계 방식입니다. 모듈화라는 관점에서 Docker 등 컨테이너 기술과 궁합이 잘 맞아 보통은 결합되어 자주 사용됩니다. 여기서 SOA와 MSA는 각 기능을 분리한다는 공통점이 존재하여 헷갈릴 수 있지만 SOA는 서비스의 재사용성을 최우선하여 공통 기능을 분리한다는 개념으로 끝이지만 MSA는 각 기능의 모듈화를 통해 서비스 간의 결합도를 낮추어 확장에 더욱 유리하도록 설계한다는 개념입니다.
쉽게 얘기해서 만약 A라는 어플리케이션이 제공하는 기능에 채팅, 인증, 유저 관리 세 가지가 존재한다면 SOA 관점에선 주로 웹에서 공통적으로 사용되는 인증과 유저 관리 기능을 통합하여 다른 어플리케이션을 사용하더라도 이 통합된 기능을 사용할 수 있어 비용 절감에 큰 이득을 갖지만 인증과 유저 관리 기능의 서비스 결합도는 증가합니다. 이를 MSA의 관점에서 설계한다면 채팅, 인증, 유저 관리 이 세 가지 기능 모두 독립적인 모듈로 개발하여 이후 A라는 어플리케이션에서 더 이상 유저 관리라는 기능을 사용하지 않게 변경합니다. 비교적 작은 서비스라면 오히려 비용적으로 마이너스가 될 수도 있지만 서비스가 커질수록 서비스간 결합도가 낮아 지고 비용 절감에 오히려 더 유리해지므로 이 점에서 SOA와 차이가 존재합니다.
여기까지 C/S 모델의 변화 과정을 짧게 살펴봤는데 이를 한 줄로 정리하면 대부분의 어플리케이션 구조는 이 3-Tier를 기본으로 설계되며 빅테크나 스타트업 등 혁신을 추구하는 기업들은 여기서 더 나아가 SOA, MSA같은 설계 방식을 결합한다고 생각하면 됩니다. 최근 많이 들리는 클라우드, 엣지 컴퓨팅 및 서버리스 아키텍쳐 같은 용어들도 물론 중요하지만 우리가 다루는 줄기에선 설명할 필요 없을 것 같습니다.
# 클라이언트
글의 초입에 클라이언트와 서버가 무엇인지에 대해 짧게 소개했었는데 둘의 통신 방식을 이해하는데 있어 좀 더 클라이언트와 서버 각각에 대해서 소개하는 것이 좋겠습니다.
클라이언트(Client)는 개발 영역에서도 영단어의 뜻 그대로 고객, 의뢰인, 손님이라고 이해할 수 있습니다. 사실 일반인에게 가장 익숙한 클라이언트 개념은 앱 클라이언트입니다. 대부분이 스마트폰을 사용하며 스마트폰에 어플리케이션을 설치하여 사용하는데 여기서 사용하는 어플이 앱 클라이언트라고 보시면 됩니다.
하지만 개발자에게 클라이언트란 네트워크 아키텍처에서 서버(Server)에 요청을 보내고, 그 요청에 대한 응답을 받는 역할을 담당하는 컴퓨터나 프로그램입니다. 처음 설명했던 터미널도 어떻게 보면 ‘기능이 매우 제한된’ 클라이언트로도 볼 수 있겠죠. 특히나 웹 개발자들에게 클라이언트란 웹 클라이언트일 가능성이 높습니다. 이 클라이언트란 개념은 시간이 지나며 변화해왔기에 여러 사람에게 다른 의미로 받아들여집니다. 그렇기에 이에 대해 좀 더 잘 알기위해서 클라이언트의 변천사를 짧게 소개하겠습니다.
# 클라이언트의 변천사
앞서 소개했듯 60~70년대의 클라이언트는 터미널 형식으로 존재했습니다. 하지만 사실상 터미널은 클라이언트라기 보단 우리가 사용하는 키보드나 마우스 같은 입력 장치에 더 가까웠습니다. 80년대 들어 PC가 등장했고 본격적으로 클라이언트라고 부를 수 있는 분산 클라이언트(Distributed Client) 형태로 나타났습니다. 터미널처럼 단순 서버에 신호만 보내는 것이 아닌 클라이언트는 스스로 로컬에서 일부 데이터를 처리하고 계산할 수 있는 능력을 갖추게 되었습니다.
이때 등장한 것이 Fat(Thick) 클라이언트입니다. 대표적으로 MS office나 패키지 게임이 존재합니다. 이 팻 클라이언트는 PC의 등장으로 클라이언트 자체로도 충분히 많은 기능을 가지게 되었고 서버에 연산을 요청할 필요 없이 스스로도 사용자가 원하는 기능을 제공할 수 있었습니다. 이러한 팻 클라이언트는 서버에 요청할 일이 아예 없는 경우도 있었으니 네트워크 의존성은 매우 낮았다고 할 수 있겠죠. 하지만 사용자의 PC 환경이 성능을 좌우했고 네트워크가 없다면 SW 업데이트에 있어서 어려움이 있었다는 단점이 존재했습니다.
이런 단점들이 있었기에 Fat 클라이언트는 사용자 입장에서 무겁게 느껴질만 했었고 그래서 등장한 것이 Thin 클라이언트입니다. 클라이언트가 하는 역할은 터미널처럼 단순 요청은 아니나 화면 출력처럼 단순하고 대부분의 데이터 처리/비즈니스 로직 수행은 서버에서 이루어진다는 게 가장 큰 특징입니다. 현재도 사용되는 HP 씬 클라이언트나 Google Chrome OS(크롬 브라우저 아님) 등이 있습니다.
이후 00년대에 들어 이 씬 클라이언트를 보완하기 위해 나타난 것이 Rich 클라이언트입니다. 사실 리치 클라이언트의 개념은 씬 클라이언트와 비슷합니다. 하지만 PC의 보급화와 어플리케이션 기능의 진화로 클라이언트에 기대되는 기능이 단순 화면 출력 이상으로 많아졌습니다.
어찌보면 리치 클라이언트는 팻 클라이언트에 네트워크 연결이 된 것으로 이해될 수 있는데 단순히 생각하면 맞을 수도 있는 설명이지만 두 클라이언트는 그 개념이 완전히 다릅니다. 팻 클라이언트의 경우 서버는 단순히 DB처럼 데이터만 제공할 뿐 대부분의 기능은 클라이언트가 담당합니다. C/S 모델이 대중화되기 이전이므로 서버와의 연결이 아예 필요 없는 경우도 많았습니다. 대표적으로 Ms office를 떠올리시면 쉬울겁니다. 하지만 리치 클라이언트는 클라이언트도 물론 로컬에서 많은 작업들이 수행되지만 기본적으로 그 작업들은 서버에 요청할 데이터를 가공하고 서버가 응답한 데이터를 렌더링하는 작업이 주가 됩니다.
이 리치 클라이언트의 대표적인 예시가 엣지나 크롬 같은 브라우저 기반 웹 클라이언트입니다. 대표적으로 웹 브라우저가 있습니다. 이 때 지금도 많이 사용되는 ‘클라이언트가 서버로 요청 > 서버가 요청한 데이터를 처리 > 클라이언트가 응답된 데이터를 바탕으로 렌더링’ 프로세스가 대중화되었습니다.
이후 2010년대 우리 생활에 스마트폰이 너무나 익숙해질 때 같이 등장한 것이 모바일 클라이언트입니다. 따로 설명할 필요가 없을 정도로 우린 이 구조를 너무 잘 압니다만 그래도 정리하자면 스마트폰이라는 모바일 기기에 iOS, Android 같은 운영체제를 설치한 후 모바일 네트워크(3G, Wifi)를 통해 서버와 상호작용하는 구조를 갖습니다.
# 웹 클라이언트의 렌더링 방식의 진화
사실 모바일의 경우 우리가 잘 알지만 사실 모바일만큼이나 웹 환경도 크게 발달했습니다. 그 과정에서 기존의 클라이언트는 사용자 경험에 있어서 분명히 한계가 존재했고 그를 위해 등장한 것이 바로 SPA, Single Page Application입니다. 아주 정확한 것은 아니지만 이해를 할 때 SPA도 웹 클라이언트의 범주 안에 있다고 생각하는 것이 편합니다.
지금까지 클라이언트가 서버와 통신할 때마다 보통은 서버에서 페이지를 불러와서 렌더링을 하는 과정이 일반적이었습니다. 그래서 보통 우리가 어떤 버튼을 눌러 서버에 정보를 요청하거나 한 페이지 내에서 다른 메뉴로 이동하는 과정에서 대부분 페이지가 깜빡이며 기존의 페이지가 사라지고 새로운 페이지가 나타나는 경험을 했었습니다. 이렇게 서버에서 새로 그려질 페이지 전체를 새로 불러와서 클라이언트가 그려주기만 하는 것을 SSR, Server Side Rendering이라고 합니다. 하지만 SSR은 요청마다 매번 서버에 그려질 페이지 정보를 가져와야 하므로 속도가 느린 편이었고 필수적으로 html, css, js파일을 매번 로드하고 깜빡이는 과정이 필요했고 이를 앞서 사용자 경험에 한계가 있다고 표현한 것입니다.
하지만 SPA는 그런 단점을 개선하기 위해 페이지 최초 접속시에 필요한 모든 html, css, js 파일을 불러오며 같은 페이지 내부에서 다른 메뉴로 이동할 경우 서버에서 그 페이지에 대한 정보를 매번 불러오는 것이 아닌 초기 로드된 파일을 바탕으로 클라이언트 자체에서 새로운 페이지를 그리게 됩니다. 속도면에서 초기에 로드할 수 없는 정보들(예를 들어, 특정 인물의 사진처럼 유저가 선택해야지만 서버가 전달하는 정보)의 경우에만 서버에 정보를 요청하는 통신(주로 AJAX)을 보내며 이러한 렌더링 방식을 CSR, Client Side Rendering이라 부르며 일반적으로 초기엔 모든 SPA는 CSR 방식을 사용했다고 생각하시면 편합니다. 흔히 아는 React, Vue, Angular 등 웹 프레임워크들이 이에 사용됩니다. 여기서 SPA는 어플리케이션의 종류 중 하나, CSR은 그 어플리케이션의 렌더링 방식 중 하나로 이해하시면 됩니다. 즉 SPA = CSR이 아니란 겁니다.
하지만 유저 사용 경험(UX)을 크게 높일 수 있는 CSR 방식 역시 단점이 많았습니다. 초기에 많은 파일들을 로드하는 과정에서 속도가 느리며 서버 부하가 발생하고 현대 웹 서비스와 뗄 수 없는 검색 엔진 최적화(SEO, Seach Engine Optimization)가 어렵습니다. 따라서 빌드 시점에 모든 페이지가 html을 이용하여 정적으로 작성되며 이후 페이지별 js가 로드되는 SSG(Static Site Generation) 방식이나 이전에 설명했던 SSR 방식을 함께 사용하는 웹서비스가 등장합니다. 대표적으로 많이 들어 보셨을 Next.js나 Nuxt.js 같은 프레임워크가 대표적으로 이에 사용됩니다.
앞서 살펴본 것처럼 모바일과 웹 클라이언트 둘다 기술의 발전과 같이 급속도로 발전했습니다. 하지만 기업에선 일부를 제외하곤 두 클라이언트 모두 사용자에게 만족스럽게 제공하는 것은 현실적으로 많이 어려웠습니다. 따라서 2010년대 후반 PWA, Progressive Web Application가 등장하게 됩니다. 조금 다르지만 쉽게 여러분이 아시는 모바일 환경에서 사용하던 네이티브 앱과 웹 앱의 장점을 합친 하이브리드 앱을 생각하시면 쉽습니다. 예를 들어 PC에서 따로 내가 어플리케이션을 설치한 적이 없는데 실행하면 프로세스가 따로 생기는 어플들을 말합니다.
# 서버
서버(server)란 용어 자체는 정말 많은 분야에서 다양한 의미로 사용됩니다. 그렇기 때문에 앞서 살펴본 클라이언트도 있지만 특히나 서버란 일반인과 개발자가 소통할 때 가장 혼선을 주는 단어이기도 합니다. 어떤 단어든 간에 시간이 흐르며 사용하는 환경이 바뀌며 뜻이 추가됩니다. 그렇기에 서버라는 용어 자체는 시간이 흐르며 세대에 따라 받아들이는 의미가 조금씩 달라졌습니다. 클라이언트도 앞서 살펴봤듯 계속 변화해 왔지만 사실 서버는 클라이언트와 달리 일반 사용자의 입장에서 직접 다룰 수 없는 개념이기에 더욱 개변 현상이 심해진 것이라 생각합니다. 따라서 서버에 대해 더 잘 알려면 당연히 어떻게 서버가 변화해 왔는지 알 필요가 있다고 생각합니다.
# WAS
우선 추상적인 서버의 개념에 대해 설명하겠습니다. 쉽게 서버가 하는 역할에 대해 얘기할텐데, 초창기 중앙 서버는 정적인 요청을 받는 웹 서버로 충분했습니다. 클라이언트는 단순히 저장된 사진, 동영상이나 업데이트에 필요한 파일들만 요청했기 때문입니다. 하지만 웹이 발전함에 따라 서버는 클라이언트의 동적인 요청을 처리하고 다양한 작업을 수행해야만 했습니다. 그래서 등장한 것이 웹 어플리케이션 서버(WAS, Web Application Server)입니다.
이름처럼 WAS는 요청을 받으면 정해진 파일을 응답하는 웹 서버와는 다르게 어플리케이션을 사용하듯 요청에 담긴 여러 파라미터에 따라 연산을 진행하여 동적으로 응답을 생성한 뒤 전달합니다. 개발자라면 Apache Tomcat을 대표적으로 아실겁니다. 사실 요즘 배포된 많은 서비스들은 요청을 WAS에서 직접 받는 것이 아닌 중간에 웹 서버, cdn 등을 거치게 되고 이 과정에서 프록시라는 개념도 알 필요가 있는데 이를 설명하려면 너무 길어지기에 다음에 자세히 다루도록 하고 우리는 WAS라는 개념이 등장했다 정도만 기억하고 넘어가면 됩니다.
* 이 부분에 대한 더 자세한 설명은 https://fadet-coding.tistory.com/34 의 WAS 파트에 조금 더 자세히 있습니다.
이 웹 서버와 WAS 서버처럼 클라이언트의 요청을 받아서 응답을 주는 중앙 컴퓨팅 장치를 서버로 이해할 수 있습니다. 일반인이 이해하는 서버의 의미는 보통 이 개념이라고 생각하시면 됩니다. 만약 게임이나 채팅을 하는데 버벅이면 ‘아 서버 터졌나보네…’라고 할 때처럼 말입니다. 여기까지 알아두면 뒤에 소개할 infrastructure로서 서버의 변천사를 이해하는데 무리가 없을 것입니다.
# Server as InfraStructure
이제 서버의 역할이 아닌 infrastructure로서 서버에 대한 역사를 짚어보겠습니다. 초창기의 서버는 메인프레임을 의미했습니다. 이 메인프레임은 그 당시 컴퓨팅 기술의 집약체로 많은 연산이 필요한 대기업이나 정부 기관에서나 사용할 수 있었습니다. 그만큼 정말 고비용, 고성능의 장비였고 그렇기에 유연성이 낮고 유지보수 비용이 엄청났습니다.
이후 PC의 등장으로 일부의 전유물이었던 서버는 여러 기업들도 사용할 수 있게 되었습니다. 기업은 베어메탈(Bare Metal)이라고 주로 불리는 물리적인 서버를 운용합니다. 연산을 처리할 수 있고 클라이언트에게 응답하는데 특화된 고성능의 PC들을 모아서 IDC, Internet Data Center를 구축하고 구축한 IDC에 자신들의 중앙 서버를 구동시켜 클라이언트에게 요청을 받아 정보를 제공하거나 개인 SW를 업데이트해줍니다. 여기서 엔지니어들은 실제 IDC로 구축된 서버실 환경 자체를 서버라 부릅니다. 따라서 여기서 등장한 서버의 의미는 앞서 역할로서의 서버와는 개념이 상당히 다릅니다.
초기 이 IDC는 직접 하드웨어에 실제 서버를 구축하여 사용하였습니다. 실제 응답하는 서버 SW를 IDC에 구축한 PC로 직접 설치하고 관리했다고 보시면 됩니다. 조금만 생각해봐도 이 방식은 한계가 분명합니다. 정말 단적인 예로 내 PC에 인터넷 브라우저와 게임을 동시에 실행했을 때 인터넷으로 대용량 파일을 받는 것처럼 네트워크 자원 소비가 과도해지면 같이 실행 중인 게임의 핑이 튀는 현상을 겪어보셨을 겁니다. 이 문제가 PC가 아닌 서버실에서 발생한다면 어떨까요?
위와 같은 문제점을 해결하기 위해 가상화(Virtualized) 기술이 도입됩니다. 아래 그림처럼 기존에는 하나의 물리 하드웨어 위에 하나의 OS가 설치되고 그 위에 여러 WAS가 실행되었습니다. 이 과정에서 아까의 예시처럼 하나의 WAS에 과도한 자원이 몰리면 다른 WAS에 영향이 가는 것이 불가피하며 하나의 OS에서 여러 WAS가 동작하므로 호환이 되지 않는 WAS는 사용하지 못하거나 다른 OS를 설치한 또다른 하드웨어를 추가로 구축해야 했습니다.
하지만 가상화 기술을 도입하여 가상 머신이란 개념을 도입하면 아까처럼 물리 하드웨어 위에 OS가 직접 설치되는 것이 아닌 Hypervisor가 설치됩니다. 하이퍼바이저란 가상화 계층을 구현해주는 SW이며 쉽게 하드웨어와 가상 머신의 중간 관리자라고 생각하시면 됩니다. 이 하이퍼바이저 위에 아까처럼 WAS들이 직접 설치되는 것이 아닌 여러 가상 머신이 설치됩니다. 이 개별 가상 머신은 하나의 물리 하드웨어처럼 작동하며 각자의 OS를 설치하기에 호환성에 있어서 엄청난 이점을 얻게 됩니다.
가상화는 여러 이점이 있지만 기존의 단점을 대체하기엔 한계가 존재했습니다. 호환성 측면에서 각자의 OS를 가지는 것은 좋았지만 다들 아시듯 OS는 많은 자원이 필요하기에 가상 머신의 온전한 성능을 다 사용하지 못하고 초기에 가상 머신별로 실제 하드웨어 자원을 분할해줘야하므로 갑자기 서비스 중인 한 영역을 축소시키는 등의 일이 발생할 때 하나의 가상머신에 분할된 자원이 잉여가 되는 등 각 가상 머신별로 유연하게 자원을 분할하지 못합니다. 또한 논리적으로 구분해서 사용한다 하더라도 결국 하나의 물리적인 하드웨어에서 구동되는 것은 동일하므로 만약 하나의 가상 머신 오류로 하드웨어에 직접적인 영향이 생겨 다운되는 경우 나머지 가상 머신들도 꺼지는 대참사가 발생하게 됩니다.
그래서 등장한 것이 컨테이너(Containerized) 기술입니다. 아래 그림처럼 컨테이너 기술에선 하나의 물리적인 하드웨어가 아니라 외부의 인프라(대표적으로 클라우드)를 대여하고 또 여러 컴퓨팅 시스템을 사용하여 하나의 패키지처럼 구성할 수 있습니다. 그렇기 때문에 필요한 OS에 따라 컴퓨팅 시스템을 분리하여 각자가 OS를 공유함으로써 자원 활용을 효율적으로 할 수 있습니다. 또한 하나의 컨테이너는 이미지와 레이어라는 개념을 사용하기에 가상 머신처럼 OS를 깔고 프로그램을 설치하는 등 여러 설치 절차가 필요 없이 정의 파일대로 빌드하면 되므로 특정 서비스가 폐쇄되면 그냥 컨테이너를 없애고 다음에 다시 빌드하는 비용이 엄청나게 줄어들게 됩니다.
이 때 각 컨테이너들이 설치되는 클라우드 등 인프라 패키지들 자체를 서버라고도 부르곤 합니다. 개발자들이 흔히 백 서버, DB 서버 등등으로 편하게 부르는 용어들은 사실 WAS나 DBMS가 설치된 클라우드 서버를 뜻한다고 보시면 됩니다.
끝에 다룬 서버의 변천사는 사실 작성한 내용보다 훨씬 내용이 많고 자세히 다루면 웹이 발달하면서 서버에게 요구되는 스펙들이나 클라우드 컴퓨팅의 대두 등 수많은 토픽들을 다뤄야합니다만 너무 길어지기도 하고 서버를 이해하는 데 있어서는 이 정도의 지식만 있다면 충분하다 생각됩니다. 이 정도 다뤘다면 누군가 서버라는 단어를 사용했을 때 맥락에 따라 어떻게 해석할지에 도움이 되었으면 좋겠습니다.
이번 포스트에선 클라이언트-서버 모델에 대해 다뤘습니다. 이정도 서버와 클라이언트에 대한 지식을 갖췄다면 다음 포스트를 이해하시는데 큰 문제가 없을겁니다. 그렇다면 다음 글에서 뵙겠습니다.
'Learning' 카테고리의 다른 글
| L4_AWS 프리티어_프리티어 만료 후 인스턴스&계정 삭제 (0) | 2023.04.05 |
|---|---|
| L3_AWS Elastic beanstalk_개고생 체험기 (0) | 2023.02.28 |
| L2_메모리로 알아보는 JAVA와 JavaScript (0) | 2023.02.11 |
| L1_react+spring boot_api 공부_1 (0) | 2023.02.07 |