클라이언트와 서버

클라이언트-서버 아키텍쳐 (2-Tier Architecture)

(실제로 존재할 수는 없지만)서버와 존재하지 않는 쇼핑몰 어플리케이션이 있다고 가정해보자. 이 어플리케이션은 서버와 통신하는 것이 아닌, 상품의 가격, 상세 정보, 목록 등 모든 데이터가 어플 내에 내장되어 있다. 이런 경우라면 끊임없이 업데이트가 진행되어야 할 것이다. 새로운 상품을 업데이트 해야한다면 1.0 버전 내에는 신상품에 대한 정보가 없기 때문이다.

이는 상품 정보를 실시간으로 전달하기에 매우 어렵고, 결제 역시 은행 서버 등 다른 금융 관련한 서버와 연계가 되어야 하므로 사실상 서버가 없이는 서비스가 불가능 하다. 이처럼, 빈번한 데이터 업데이트가 필요한 경우 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시는 것이 유리하다.

이렇게 리소스가 존재하는 곳과 리소스를 사용하는 어플을 분리시킨 것을 클라이언트-서버 아키텍쳐, 또는 2티어 아키텍쳐라고 부른다. 리소스를 사용하는 어플리케이션은 ‘클라이언트(Client)’, 리소스를 제공하는 곳은 ‘서버(Server)’이다.

단어의 어원을 떠올리면 두 관계를 이해가 쉽다. 리소스가 필요한 고객(클라이언트)는 서빙하는 직원(서버)에게 원하는 리소스를 요청하고, 직원은 그 리소스를 담아 고객에게 응답한다. 클라이언트와 서버는 요청과 응답을 주고 받는 관계이고, 요청이 선행되면 응답이 오는 구조이다.

3티어 아키텍쳐 (3-Tier Architecture)

사실 일반적으로 서버는 리소스를 전달해주는 역할을 하고, 리소스는 저장하는 공간인 데이터베이스를 별도로 마련하여 서버와 통신하게 된다. 이처럼 클라이언트-서버 아키텍쳐에 데이터베이스가 추가된 형태를 3티어 아키텍처라고 부른다.

프론트엔드와 백엔드

이런 아키텍쳐 구조에 따라 개발 직군이 나뉘게 된다. 클라이언트처럼 사용자가 직접 눈으로 보고, UI를 클릭하거나 터치하는 등의 상호작용을 할 수 있는 어플을 주로 개발하면 프론트엔드 개발자, 사용자의 눈에 보이진 않지만 상품 정보를 API로 노출한다거나 로그인/로그아웃, 권한 등 사용자 인증을 주로 다룬다면 백엔드 개발자라 부른다. 백엔드는 보통 데이터베이스 등 시스템 설계까지 맡는 경우가 많다.

클라이언트와 서버의 종류

클라이언트는 보통 웹 사이트(웹 어플), 스마트폰/태블릿 용 어플, 데스크탑용 프로그램(어플) 등 플랫폼에 따라 구분된다. 서버는 파일 서버, 웹 서버, 메일 서버, 데이터베이스 서버 등 서버가 하는 역할에 따라 종류가 달라진다.

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

프로토콜

프로토콜은 통신 규약, 즉 약속이다. 이런 프로토콜은 요청할 리소스나 서버의 역할에 따라 다양한 방법이 존재하며, 보편적으로 많이 사용하게 되는 주요 프로토콜은 아래와 같다.

그리고 ‘통신 규약’이라는 측면에서 각자의 프로토콜에 따라 지켜야 할 규약이 존재한다. 제대로 된 통신을 위해서는 프로토콜에 맞는 규약을 지켜야 정상적인 통신이 가능하다.

웹 어플리케이션 프로토콜 : HTTP

웹 어플리케이션 아키텍쳐에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해 통신하게 된다. HTTP를 이용해 주고 받는 메세지는 ‘HTTP 메세지’라 일컫는다.

API (Application Programming Interface)

서버에게 리소스를 요청할 때는 서버가 요구하는 정확한 방법에 맞춰 요청해야 한다. 컴퓨터 세계는 결국 0과 1로 이루어져 있고, 정확하지 않은 요청은 컴퓨터가 이해할 수 없기 때문이다. 그리고 서버에서 사용 가능한 자원이 파악되어야 요청하는 방법을 정확히 알 수 있다. 하지만 우리는 서버가 어떻게 구성되어 있는지 알 수 있는 방법이 없다.

서버는 마치 식당에서 메뉴판을 제공하듯, 리소스를 잘 활용할 수 있는 API를 제공해야 한다.

정확한 요청을 받기 위해 서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(interface)를 제공해야 한다. 이에 대한 정답이 바로 API이다. API는 Application Programming Interface의 약자이며, Interface의 사전적 의미는 ‘의사소통이 가능하도록 만들어진 접점’이다. 이런 의미를 생각해보면, 메뉴판도 인터페이스라 볼 수 있다. 다만 API는 어플이 요청할 수 있고 프로그래밍 가능한 인터페이스라는 차이점이 있다.

서버는 API를 구축해놓아야 클라이언트가 이를 활용할 수 있다. 보통 인터넷에 있는 데이터를 요청할 때는 HTTP라는 프로토콜을 사용해 주소(URL, URI)를 통해 접근할 수 있게 된다. 이 때, ?나 &같은 기호를 사용해 파라미터를 추가하여 요청을 보낼 수도 있다.

HTTP API 디자인을 잘 하는 법

HTTP API 디자인에는 Best Practice가 존재한다. 실제로 쓰일 법한 API인 사용자 관리 API를 예제로 작성한다.

위의 예제를 보면 URL 디자인은 단순하지만 메서드라는 개념이 등장한다. HTTP 요청에는 메서드라는 것이 존재해서, 리소스를 단순히 받는 것을 넘어 리소스와 관련된 행동(CRUD; Create / Read / Update / Delete)을 지정할 수 있다. 좋은 레퍼런스 사이트

요청에 따른 메서드는 다음과 같으며, 이 메서드들을 기억해두자. 각각 조회, 추가, 갱신, 삭제와 관련되어 있다. 이때 HTTP 메서드는 리소스를 이용해 하려는 행동에 맞게 적절하게 쓰여야 한다. GET을 요청했는데 서버에서 리소스가 지워진다면 좋은 API 디자인이 아닌 것이다.

요청	적절한 메소드
조회 (Read)	GET
추가 (Create)	POST
갱신 (Update)	PUT or PATCH
삭제 (Delete)	DELETE

Uploaded by N2T

티스토리툴바

웹 어플리케이션 아키텍쳐