웹 애플리케이션 아키텍처

학습 목표

• 클라이언트-서버 아키텍처를 이해할 수 있다.
• HTTP를 이용한 클라이언트-서버 통신을 이해할 수 있다.
• API의 개념을 이해할 수 있다.

---

클라이언트-서버 아키텍처

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

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

리소스를 사용하는 앱이 바로 클라이언트, 리소스를 제공(serve)하는 곳은 서버라고 부른다.

리소스에 접근하려는 앱은 카페로 치면 손님(client)과 같다. 손님이 아메리카노를 마시기 위해 리소스를 가지고 있는 점원(server)에게 요청해야 한다. 손님의 요청에 따라 점원은 리소스를 담아 응답한다.

이처럼 클라이언트와 서버는 요청과 응답을 주고받는 관계이다. 클라이언트-서버 아키텍처에서는 요청이 선행되고 그 후에 응답이 온다.

3티어 아키텍처

일반적으로 서버는 리소스를 전달해 주는 역할만 담당한다. 리소스를 저장하는 공간을 별도로 마련해 두는데 이 공간을 데이터베이스라고 부른다. 데이터베리스는 창고와 같은 역할을 한다.

이처럼 기존 2티어 아키텍처에 데이터베이스가 추가된 형태를 3티어 아키텍처라고 부른다.

백엔드와 프론트엔드

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

클라이언트처럼 사용자가 직접 눈으로 보고, UI를 클릭 또는 터치하는 등의 상호작용을 할 수 있는 앱을 주로 개발하면 프론트엔드 개발자라고 한다.

반면 사용자는 눈에 보이지 않지만, 상품 정보를 API로 노출한다든지, 로그인/로그아웃, 권한 관리 등의 사용자 인증을 주로 다루는 개발자는 백엔드 개발자라고 부른다. 백엔드 개발자는 데이터베이스 등의 시스템 설계까지 맡아서 하는 경우가 많다.

클라이언트와 서버의 종류

클라이언트는 보통 플랫폼에 따라 구분된다. 브라우저를 통해 주로 이용하는 웹(Web) 플랫폼에서의 클라이언트는 웹사이트 또는 웹 앱이라고 부른다.

iOS나 안드로이드와 같은 스마트폰/태블릿 플랫폼, 그리고 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱 역시 클라이언트가 될 수 있다.

---

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

클라이언트와 서버가 어떤 식으로 통신하는지, 그리고 이때 등장하는 API라는 것은 무엇을 의미하는지 알아본다.

클라이언트와 서버의 통신

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

커피 전문점을 예로 들어 보자. 주문하지 않은 커피가 갑자기 나올 수도 있겠지만, 보통은 손님으로부터 주문이 들어가야 커피가 나온다.

클라이언트-서버 아키텍처에서는 서버 마음대로 클라이언트에 리소스를 전달하지 않는다.

프로토콜

• 프로토콜은 통신 규약, 즉 약속을 의미한다. 손님이 주문을 받는 사람에게 대뜸 찾아가, 외계어로 주문을 할 수 없듯 주문을 하기 위해서는 꼭 지켜야 하는 약속이 몇가지 존재한다.

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

• 웹 애플리케이션 아키텍처에서는, 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 대화를 나눈다.
• HTTP를 이용해 주고받는 메시지는 HTTP 메시지라고 부른다.

프로토콜 예제 : 커피 주문

커피 전문점에 가서 커피를 주문할 때에는 다양한 방법을 사용할 수 있다.

카운터로 찾아가거나, 앱을 이용하거나, 키오스크를 이용할 수도 있다.

이러한 방법 하나하나 전부 프로토콜이다. 같은 일을 하기 위해 “다양한 방법”이 존재하는 것이다.

→ 서버와 통신할 수 있는 다양한 방법이 존재한다.

프로토콜 예제 : 우편

규약이라는 측면에서 프로토콜을 이해해 보자.

가게에서 외계어로 상품 주문을 할 수 없든, 우편을 보낼 때에 수신자에 대한 아무런 표기가 없다면 이 전송 요청은 갈 길을 잃고 말 것이다. 그리고 수신자를 적어도 우표를 붙이지 않으면 마찬가지로 반송이 되고 말 것이다.

이는 “우편 전송”이라는 행동을 하기 위해 반드시 지켜야 하는 규약이 있음을 의미한다. 각자의 프로토콜마다 지켜야 하는 규약이 존재한다.

→ 제대로 된 통신을 위해서는 규약(약속)을 지켜야만 한다.

API

손님이 메뉴를 주문하기 위해서는 메뉴판을 보고 주문해야 한다. 컴퓨터에게 요청할 때에는, 정확한 주문 방법을 따라 요청해야 한다.

서버가 어떻게 구성되어 있는지 모른다면, 클라이언트는 어떻게 자원을 확인할 수 있을까?

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

API(Application Programming Interface) 서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공해 줘야 한다. 이것을 API라고 한다.

API 예제 : 커피 주문

API는 메뉴판과 같다. 클라이언트가 커피 전문점에서 제공하는 자원의 종류(아메리카노, 라떼 등)를 모른다고 가정할 경우, 엉뚱한 메뉴(설렁탕 등)를 시키지 않도록 도와주어야 한다.

커피 전문점이 주문할 수 있는 메뉴를 적은 메뉴판을 만들어 놓았기 때문에, 클라이언트는 이에 맞게 적절한 요청을 할 수 있는 것이다.

마찬가지로 서버는 리소스를 전달할 메뉴판, 즉 API 문서를 작성해야 클라이언트가 이를 활용할 수 있다.

보통 인터넷에 있는 데이터를 요청할 때에는 HTTP 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있다.

호스트 - http://starbucks.com

요청	URL 디자인 예제
아메리카노 한 잔 주세요	/coffee/americano
망고 프라푸치노 한 잔 주세요	/frappuccino/mango
콜드브루 두 잔 주세요	/coffee/coldbrew?quantity=2
아메리카노 두 잔 전부 헤이즐넛 시럽 넣어 주세요!	/coffee/americano?guantity=2&syrup=hazelnet

HTTP API 디자인을 잘 하는 방법

HTTP API 디자인에는 Best Practice가 존재한다.

예) 사용자 관리 API

요청	URL 디자인	사용하는 메서드
모든 사용자 조회	/users	GET
새 사용자 추가	/users	POST
1번 사용자 정보 갱신	/users/1	PUT
1번 사용자 정보 삭제	/users/1	DELETE
1번 사용자 정보 조회	/users/1	GET

HTTP 메서드는 CRUD 행동에 따라 목적에 맞게 써야 한다.

요청	적절한 메서드
조회 (Read)	GET
추가 (Create)	POST
갱신 (Update)	PUT 또는 FETCH
삭제 (Delete)	DELETE