REST API (진행 중)
Source: Dev.to
지난 에피소드에서는 TCP와 같은 신뢰성을 위한 프로토콜, 요청을 위한 HTTP/HTTPS, 실시간 채팅을 위한 WebSockets 등 웹을 가로질러 데이터가 흐르게 하는 네트워킹 프로토콜을 살펴보았습니다. 이를 바탕으로 Episode 3에서는 애플리케이션이 보다 구조화된 방식으로 어떻게 통신하는지, 즉 API부터 시작하는 방법을 다룹니다. 먼저 REST API를 일상적인 비유를 통해 쉽게 설명할 것이며, 이는 이후 시리즈에서 다룰 gRPC, GraphQL, 그리고 다양한 커뮤니케이션 패턴을 위한 기반이 됩니다.
이제 앱 아키텍처의 기본 개념과 REST가 어떻게 들어맞는지 알아보겠습니다.
Source: …
티어의 진화 (레스토랑 비유)
앱이 어떻게 구축되는지를 설명하려면 레스토랑을 운영하는 것에 비유해 보세요. 이 디지털 주방 아이디어를 사용해 세 가지 주요 아키텍처를 나눠 설명합니다.
1‑Tier 아키텍처: 푸드 트럭
모든 것이 한 곳에서 일어납니다. 주문을 받는 사람이 동시에 요리를 하고 냉장고에서 재료를 꺼냅니다.
소프트웨어에서는 사용자 인터페이스, 비즈니스 로직, 데이터 저장소가 모두 같은 머신에 존재한다는 뜻이며, 옛날 데스크톱 앱과 같습니다.
문제: 갑자기 손님이 몰리면 전체 시스템이 느려지거나 다운됩니다. 처음부터 다시 시작하지 않고는 쉽게 도움을 추가할 수 없습니다.
2‑Tier 아키텍처: 작은 식당
운영이 두 개의 구분된 공간으로 나뉩니다:
- 프론트 카운터 – 고객이 주문하고 직원과 상호작용합니다.
- 백 주방 – 실제 작업이 이루어지는 곳입니다.
캐셔는 고객과 대화하고 주문을 받으며, “이 주문이 유효한가?” 같은 간단한 검증을 담당하고, 주방은 요리, 가격 규칙 적용, 재료 확인, 냉장고에서 아이템을 꺼내는 일을 담당합니다.
소프트웨어 용어로는:
- 클라이언트 – 사용자 인터페이스와 기본 검증을 담당합니다.
- 서버 – 비즈니스 로직과 데이터베이스를 모두 포함합니다.
장점: 여러 클라이언트가 동시에 같은 주방에 연결할 수 있어 푸드 트럭보다 훨씬 많은 고객을 처리할 수 있습니다. 주방(서버)을 변경해도 카운터(클라이언트)를 다시 만들 필요가 없습니다.
단점: 주방이 주문을 받는 일을 넘어 모든 것을 담당하게 됩니다. 메뉴가 늘어나고 고객이 맞춤 옵션을 원하게 되면, 그 모든 특수 규칙이 주방에 쌓여 관리가 어려워지고 응답 속도가 느려집니다. 저장소나 로직을 확장하려면 로직과 데이터가 함께 있기 때문에 주방 전체를 재설계해야 합니다.
3‑Tier 아키텍처: 고급 레스토랑
이제 레스토랑은 완전히 전문화되고 확장성을 갖추었습니다.
- 프레젠테이션 레이어 (프런트‑오브‑하우스 직원) – 손님 경험에만 집중하고, 메뉴 안내와 주문 접수를 담당하지만 음식이 어떻게 만들어지는지는 모릅니다.
- 애플리케이션 레이어 (주방 셰프) – 요리와 비즈니스 규칙 적용에만 전념하며, 주문이 어떻게 들어왔는지는 신경 쓰지 않습니다.
- 데이터 레이어 (보관 구역) – 재료, 레시피, 재고를 자체적으로 관리하며, 다이닝룸이나 주방과 격리되어 있습니다.
소프트웨어에서는 이러한 분리를 통해 각 티어가 단일 책임을 갖게 되므로, 더 많은 웨이터, 셰프, 혹은 더 큰 창고를 추가해도 전체 시스템을 재설계할 필요가 없습니다. 성장 관리, 메뉴 변경, 대규모 트래픽 급증 대응이 훨씬 쉬워집니다.
Source: …
API란 무엇이며 REST란 무엇인가?
REST에 대해 이야기하기 전에 API(Application Programming Interface)를 정의해 보겠습니다. 레스토랑에서는 웨이터가 요리사에게 건네는 주문서와 같습니다. 프론트엔드(웨이터)는 필요한 내용을 적어 백엔드(요리사)에게 전달합니다. 웨이터는 오븐이 어떻게 작동하는지 알 필요가 없으며, 단지 형식만 따르면 됩니다. 이것은 시스템 간에 서로의 내부 구조를 알 필요 없이 대화할 수 있게 해 주는 간단한 계약입니다.
REST(Representational State Transfer)는 API를 구축하기 위한 스타일입니다. API가 주문서라면, REST는 그 주문서를 작성하는 표준 방식이며, 모두가 같은 언어를 사용하도록 합니다.
무작위 메모 대신, REST는 HTTP를 통해 일관된 명사와 동사를 사용합니다 (Episode 2 참고).
- 명사 (리소스):
/orders,/menu-items,/customers와 같이 데이터를 나타내는 경로들입니다.
동사 (메서드)
- GET – 데이터를 가져옴
- POST – 새 데이터를 생성
- PUT – 데이터를 업데이트
- DELETE – 데이터를 삭제
이렇게 하면 3계층 구조가 인터넷 상에서 원활히 동작하여 프론트엔드가 백엔드와 쉽게 통신할 수 있습니다. 예를 들어 prasunchakra.com에 백엔드 API가 있다면, GET /posts 를 호출해 블로그 데이터를 가져올 수 있습니다.