클라이언트-서버 아키텍처
클라이언트-서버 아키텍처, 혹은 2티어 아키텍처는 리소스 사용자인 클라이언트와 리소스의 제공자인 서버를 분리한 구조이다. 이러한 기준을 바탕으로 개발자의 영역도 클라이언트 영역을 다루는 프론트엔드, 서버 영역을 다루는 백엔드로 나누어진다.
클라이언트와 서버를 분리하여 얻는 이점은 무엇일까?
게시글을 올릴 수 있는 커뮤니티 앱이 있다고 생각해 보자. 만약 서버가 없어서 새로운 글이 올라올때 마다 앱을 업데이트(클라이언트 수정)를 해야 한다면 너무나 불편할 것이다. 그러나 클라이언트-서버로 나누어진 구조에선 서버에 글을 추가하면 서버에서 변경이 일어나고, 클라이언트는 서버의 변경사항을 자동적으로 반영한다. 이러한 장점 때문에 클라이언트-서버 아키텍처는 현재 보편적인 네트워크 모델이 되었다.
그러나 이러한 방식에도 단점은 존재하는데, 바로 서버에 과부하가 일어난다는 점이다. 이러한 단점은 하드웨어 업그레이드나 서버의 증설을 통해 해결한다.
HTTP와 API
그렇다면 클라이언트와 서버는 어떻게 대화를 주고받을까? 이에 필요한 약속이 바로 HTTP이다.
HTTP
웹 어플리케이션 아키텍처에서 클라이언트와 서버는 HTTP라는 '프로토콜(규약)'을 이용해 개별적인 메시지 교환 방식으로 통신한다. HTTP는 HyperText Transfer Protocol의 줄임말로, HTML과 같은 문서를 전송하기 위한 Application Layer 프로토콜이다. HTTP에서 클라이언트(브라우저)에 의해 전송되는 메시지는 요청(requests)이라고 하며, 서버에서 응답으로 전송되는 메시지는 응답(responses)이라고 부른다.
HTTP가 가지는 주요한 특징은 다음과 같다.
- 비연결성(Connectionless): 클라이언트의 요청에 대한 서버의 응답이 완료되면 연결을 끊어버리는 성질로, 다수의 클라이언트를 상대해야 하는 서버를 배려한 특성이다. (HTTP 1.1 버전 기준 / 현재는 큰 의미 없음)
- 무상태(Stateless): 비연결성으로 인해 클라이언트가 이전에 보낸 요청을 서버가 기억하지 못하는 것을 '무상태'라고 표현한다. 이러한 방식 역시 서버가 상태를 저장해야 하는 부담을 줄이기 위한 특성이다.
그러나 로그인과 같은 상황에서는 인증상태를 특정 기간동안 유지해야 할 필요가 있다. 이러한 문제는 '쿠키'와 '세션'을 통해 해결할 수 있다.
- 쿠키: 필요한 정보를 전달받아 웹 브라우저에 저장하는 방식으로 상태를 유지할 수 있다. 네트워크로 전달되는 쿠키는 중간에 탈취될 위험이 있다.
- 세션: 쿠키와 달리 서버에 별도의 세션을 확보하고, 세션ID를 주고받으며 상태를 유지한다. 이러한 세션 ID가 웹 브라우저에 저장될 때 쿠키를 사용한다.
API
API(Application Programming Interface)는 클라이언트가 서버의 리소스를 제대로 활용하도록 지원하는 '인터페이스'로, 쉽게말하면 서버에 대한(직원) 클라이언트(고객)의 주문을 돕는 '메뉴판'이라고 할 수 있다.
정리
클라이언트와 서버의 관계를 그림으로 보면 다음과 같다.
클라이언트와 서버는 HTTP라는 '규약'을 기반으로 소통한다. 클라이언트가 특정 요청을 전송하면 이를 받은 서버는 데이터베이스와 공유하여 요청에 대한 응답을 전송한다. 이 때 클라이언트는 요청을 위해 API라는 '인터페이스'를 이용한다.
더 알아볼 내용
- API
- P2P 모델
- HTTP 버전별 특성
참고
P2P vs 클라이언트-서버 모델, 각각의 장단점은?
MDN - HTTP 개요
HTTP 는 Stateless 한데 로그인은 어떻게 구현할 수 있을까?
