[Network] 웹 애플리케이션 아키텍처 (클라이언트, 서버, HTTP, API)

* HTTP에서 사용하는 클라이언트 - 서버 아키텍처
* 브라우저의 작동원리를 이해하기 위한 네트워크 기초 지식
* 클라이언트와 서버가 통신하는 방법인 API

 

 

 '내가 꿈꾸는 세상은 전 세계가 네트워크로 연결된 상태에서 서로의 자료를 공개하고
이렇게 공개된 자료를 하이퍼텍스트를 이용해 공유할 수 있는 세상이다.' 

 

 

www, URL, HTTP 등을 고안하여 웹 을 탄생시킨 웹의 아버지

 

Sir Timothy John Berners-Lee : WWW의 아버지 

- 하이퍼텍스트 문서를 작성할 수 있는 마크업 언어 HTML
- 하이퍼텍스트를 전송하는 프로토콜 HTTP
- 웹 상의 자원을 모두가 접근할 수 있도록 만든 식별자 URL

 

https://www.lgcns.com/blog/it-trend/17563/

웹의 발명 - 팀 버너스 리(Tim Berners-Lee) - LG CNS

 

 

---

 

클라이언트 - 서버 아키텍처 (2티어 아키텍처)

 

스마트폰에서 쇼핑몰 앱을 사용할 때

• 인터넷 연결이 없다면 쇼핑몰 앱은 정상적으로 동작할 수 없다.
• 그 이유는 상품 정보를 인터넷 어딘가에 존재하는 서버로부터 받아오기 때문이다.
• 보통 어딘가에 접속하려고 하는 데 사용이 불가능한 경우 "서버가 죽었다"라고 표현한다.
• 서버(server)는 영어 단어 그대로 제공(serve)하는 주체이다.

- 판매하려는 상품 정보가 전부 앱 안에 담긴 경우 (가정)

• 만약 앱과 연결된 서버가 존재하지 않는다면 끊임없이 앱을 업데이트해야 한다.
• 쇼핑몰 앱 1.0 버전을 잘 사용하더라도, 새로운 상품을 업데이트하면 1.0 버전 내에는 신상품에 대한 정보가 없어서 앱 자체를 전부 업데이트해야 한다.
• 앱을 사용하는 사람들에게 상품 정보를 실시간으로 전달하기가 매우 어렵다.
• 이 외에도 서버가 없다면 "결제"라는 행동을 할 수 없다.
  -> "결제"도 결국 금전 정보를 주고받는 은행 서버와의 연결이 필요하기 때문

빈번한 데이터 업데이트가 필요한 경우, 리소스를 존재하는 곳과 사용하는 앱을 분리시키는 것이 유리

 

이렇게 상품 정보 같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키텍처, 또는 클라이언트-서버 아키텍처라고 부른다.

*  리소스를 사용하는 앱이 바로 "클라이언트"
*  리소스를 제공(serve)하는 곳은 "서버" 

 

 

클라이언트(client, 손님)와 서버(server, 서빙하는 사람) 비유

• 리소스에 접근하려는 앱은 카페로 치면 손님과 같다.
• 손님은 아메리카노를 마시기 위해 리소스를 가지고 있는 점원에게 요청해야 한다.
• 손님의 요청에 따라 점원은 리소스를 담아 응답한다.
• 이처럼 클라이언트와 서버는 요청과 응답을 주고받는 관계이다.
• 클라이언트-서버 아키텍처에서는 요청이 선행되고 그 후에 응답이 온다.
• 일반적으로 서버는 리소스를 전달해 주는 역할만 담당한다.
• 리소스를 저장하는 공간을 별도로 마련해 두고 "데이터베이스"라고 부른다. (창고와 같은 역할)

 

이처럼 기존 2티어(클라이언트-서버) 아키텍처에 데이터베이스가 추가된 형태를 3티어 아키텍처라고 부른다.

 

 

프론트엔드와 백엔드

프론트엔드 혹은 백엔드는 아키텍처에서 어떤 분야를 다루는지에 따라 구분된다.

 

 

• 프론트엔드 :
  • 클라이언트처럼 사용자가 직접 눈으로 보고, UI를 클릭 또는 터치하는 등의 상호작용을 할 수 있는 앱을 주로 개발한다. 
• 벡엔드 :
  • 사용자 눈에 보이지 않지만, 상품 정보를 API로 노출한다든지, 로그인/로그아웃, 권한 관리 등의 사용자 인증을 주로 다룬다.
  • 백엔드 개발자는 데이터베이스 등의 시스템 설계까지 맡아서 하는 경우가 많다.

 

 

 

클라이언트와 서버의 종류

 

•  클라이언트는 보통 플랫폼에 따라 구분된다.
  • 브라우저를 통해 주로 이용하는 웹(Web) 플랫폼에서의 클라이언트는 웹사이트 또는 웹 앱이라고 부른다.
  • iOS나 안드로이드와 같은 스마트폰/태블릿 플랫폼, 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱 역시 클라이언트이다.
• 서버는 무엇을 하느냐에 따라 종류가 달라진다.
  • 파일 서버는 파일을 제공하는 앱이다.
  • 웹 서버는 웹사이트에서 필요로 하는 정보들을 제공하는 앱이다.
  • 메일 서버는 메일을 주고받을 수 있도록 도와주는 앱이다.
  • 데이터베이스도 데이터 제공자로서 일하므로 일종의 서버라고 볼 수 있다.

 

 

 

클라이언트-서버 통신과 API

 

클라이언트(client, 손님)와 서버(server, 서빙하는 사람) 비유

커피 전문점에서의 상품 제공자와 손님의 관점으로 예를 들어 보겠다.

• 클라이언트와 서버 간의 통신은 요청과 응답으로 구성된다.
• 요청이 있어야만 응답이 온다.  

 

* 클라이언트와 서버 간의 통신을 알아보려면, 먼저 프로토콜이라는 개념을 알아야 한다.

•  프로토콜은 통신 규약, 즉 약속이다. 
• 손님은 주문을 받는 사람에게 대뜸 찾아가 아래 그림처럼 외계어로 주문을 할 수 없다

• 주문을 하기 위해서는 꼭 지켜야 하는 약속이 몇 가지 존재한다. 
• 이처럼 웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 상호작용을 한다.

 

• HTTP를 이용해 주고받는 메시지는 "HTTP 메시지"라고 부른다.
•  커피 전문점에 가서 커피를 주문할 때에는 다양한 방법을 사용할 수 있다.
  -> 카운터로 찾아가거나, 앱을 이용하거나, 키오스크를 이용 등
  -> 이러한 방법 하나하나 전부 프로토콜이다. 같은 일을 하기 위해 "다양한 방법"이 존재할 수 있다. 

 

우편 보내는 것에 비유

• 앞서 언급했듯, 가게에서 외계어로 상품 주문을 할 수는 없다.
• 프로토콜은 "규약"이다.  
• 우편을 보낼 때도 수신자에 대한 아무런 표기가 없다면 이 전송 요청은 갈 길을 잃는다.
• 수신자를 적어도 우표를 안 붙이면 마찬가지로 반송이 된다.
  -> 이는 "우편 전송"이라는 행동을 하기 위해 반드시 지켜야 하는 규약이 있음을 의미한다.
• 각자의 프로토콜마다 지켜야 하는 규약이 존재한다. 

 

 

주요 프로토콜

• OSI 7 Layers는 컴퓨터공학과 네트워크에서 자주 등장하는 개념이다.  
• 해당 프로토콜이 어떤 계층(layer)에 속해있는지를 표시하고 있다.
• 이러한 네트워크 기초 지식은 면접에서 요구하는 경우가 종종 있다.

 

API

 

•  손님이 메뉴를 주문하려면 메뉴판을 보고 주문해야 한다.
• 컴퓨터 세계에서는 "알아서 맛있게 타와"라는 요청은 허용되지 않는다.
• 0과 1로 변환될 수 있는 요청을 원할 뿐이다.
• 정확한 주문 방법에 따라 요청해야 한다.

 

 

• 하지만 우리는 서버가 어떻게 구성되어 있는지 알 방법이 없다.
• 우리가 서버 코드를 직접 짠 사람도 아닌데, 어떻게 사용 가능한 자원을 파악할 수 있을까?

 

 

API(Application Programming Interface)

• 이에 대한 정답이 바로 API(Application Programming Interface)이다.
• 서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(interface)를 제공해 줘야 한다. 이것을 API라고 한다. 
• Interface의 사전적 의미는 "의사소통이 가능"하도록 만들어진 "접점"을 의미다.
• (이 의미에 따르면, 메뉴판도 인터페이스라고 볼 수 있다.)
• 다만 API는 앱이 요청할 수 있고 프로그래밍 가능한 인터페이스라는 점이 다르다. 

스타벅스 예시

 

• 쉽게 스타벅스를 예를 들어 생각해 보면, 메뉴판과 같은 역할을 한다고 볼 수 있다.
• 클라이언트가 스타벅스가 제공하는 자원의 종류(아메리카노, 콜드브루, 프라푸치노 등)를 모른다고 가정할 경우, 엉뚱한 메뉴(예를 들어 지금 땡기는 김치전)를 시키지 않도록 도와주어야 한다.
• 스타벅스가 "고객님은 콜드브루, 아메리카노와 같은 메뉴를 주문할 수 있습니다" 라고 메뉴판을 만들어 놓았기 때문에, 우리는 이에 맞게 적절한 요청("아메리카노 주세요!")을 할 수가 있다.
• 마찬가지로 서버가 리소스 전달을 위한 메뉴판, 즉 API를 구축해놓아야 클라이언트가 이를 활용할 수 있다.
• 보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있게 된다.
• 아래는 스타벅스 API 서버가 제공하는 적절한 URL 디자인 예제이다.
  (파라미터를 사용하기 위해 물음표(?)와 & 기호를 사용하는 것을 참고)

 

 

HTTP API 디자인을 잘 하는 방법

• HTTP API 디자인에는 Best Practice가 존재한다.
• 아래는 실제로 쓰일법한 사용자 관리 API이다.

• URL 디자인은 비교적 단순하나 "메서드"라는 개념이 등장한다.
• HTTP 요청에는 메서드라는 것이 존재한다.
• 앞서 스타벅스에서는 리소스를 그저 달라고(GET) 요청했다.
• 사용자 관리 API에서는 사용자를 추가해 달라고(CREATE) 요청하거나, 지워달라고(DELETE) 요청할 수도 있다. CRUD 각각의 행동과 일치하는 HTTP 메서드의 종류가 존재한다.

 

중요한 다섯 가지 메서드는 다음과 같다. (메서드 설명은 MDN "HTTP 요청 메서드"를 참고)

• GET, POST, PUT(또는 PATCH), DELETE 각각 조회, 추가, 갱신, 삭제와 관련이 있다.
• HTTP 메서드는 리소스를 이용하여, 하려는 행동(CRUD)에 맞게 적절하게 써야 한다.
  -> 만일 GET 요청을 했는데 갑자기 서버에서 리소스가 지워진다면 좋은 API 디자인이라고 볼 수 없다.