REST API란 무엇인가: 인터넷을 구동하는 네 단어

발행: 6시간 전 (2026년 5월 6일 PM 12:55 GMT+9)

10 분 소요

원문: Dev.to

Source: Dev.to

당신이 결코 의문을 제기하지 않은 메뉴

당신은 아마도 수백 번이나 식당에 들어갔지만, 실제로 그 식당이 어떻게 운영되는지 생각해 본 적은 없을 것입니다.

자리에 앉고, 웨이터가 나타납니다. 메뉴에서 무언가를 가리키면, 음식이 나옵니다.

간단합니다. 편안합니다. 익숙합니다.

하지만 이와 정확히 같은 시스템—당신, 웨이터, 그리고 주방 사이의 조용하고 조직적인 춤—이 바로 여러분의 휴대폰에 있는 거의 모든 앱이 뒤에서 소통하는 방식이라고 말한다면 어떨까요?

REST API의 세계에 오신 것을 환영합니다.

Source:

규칙이 없는 문제

메뉴가 없는 세상을 상상해 보세요.

모든 고객이 주방으로 바로 들어가서, 자신이 원하는 언어로 주문을 외치고, 셰프가 이해하기를 기대합니다. 어떤 사람은 햄버거 그림을 그립니다. 또 다른 사람은 파스타에 대한 설명을 흥얼거립니다. 또 다른 사람은 그냥 난폭하게 스토브를 가리킵니다.

혼돈.

이것이 표준이 도입되기 전 소프트웨어 커뮤니케이션의 모습이었습니다. 각 시스템마다 자체적인 커뮤니케이션 방식이 있었고, 두 시스템이 함께 작동하도록 하려면 매번 새로운 언어를 배워야 했습니다.

지치게 했고, 확장성도 없었습니다. 무언가가 바뀌어야 했습니다.

그래서 업계는 수세기 전 모든 좋은 레스토랑이 깨달은 대로—메뉴를 만들었습니다.

그 메뉴가 바로 REST입니다.

규칙을 아는 웨이터

REST — Representational State Transfer(표현 상태 전이)의 약어 — 는 단순히 시스템들이 인터넷을 통해 서로 통신하는 방법에 대한 합의된 규칙 집합일 뿐입니다.

그리고 좋은 레스토랑과 마찬가지로, 모두가 자신의 역할을 수행하기 때문에 잘 작동합니다.

Client – 프론트엔드, 휴대폰 앱, 브라우저의 웹사이트. 원하는 것이 무엇인지 알고 있지만 직접 주방에 뛰어들어 직접 가져오지는 않습니다.
Backend – 주방, 실제 작업이 이루어지고 데이터가 존재하며 요청이 처리되는 곳. 이를 볼 필요도, 이해할 필요도 없습니다. 주문만 받아 주면 됩니다.
API (the waiter) – 요청을 한 방향으로, 답변을 반대 방향으로 매끄럽게, 혼란 없이 매번 전달해 주는 웨이터 역할을 합니다.

하지만 REST API를 특별하게 만드는 점은 — 웨이터가 어떤 형식이든 아무 주문이나 받아들이는 것이 아니라는 것입니다. 구조가 있고, 언어가 있으며, 메뉴가 있습니다.

메뉴 배우기

레스토랑에서, 메뉴는 무엇을 이용할 수 있는지와 어떻게 주문할지를 알려줍니다. REST API에서는 그 메뉴가 네 가지 간단한 동작으로 구성됩니다 — 거의 모든 데이터 작업을 커버하는 네 단어.

GET — “뭔가 가져와 주세요.”

프로필, 제품 목록, 오늘의 뉴스 피드를 보고 싶을 때. GET이 가서 가져다 줍니다.

POST — “새로운 것을 추가하세요.”

계정을 만들고, 양식을 제출하고, 사진을 올릴 때 — POST는 준비한 것을 주방에 전달해 만들어 달라고 합니다.

PUT / PATCH — “이미 있는 것을 바꾸세요.”

사용자 이름을 업데이트하거나, 예약을 수정하거나, 기존 리소스를 변경할 때. PUT과 PATCH는 주방으로 돌아가 셰프에게 요리를 조정해 달라고 요청합니다.

DELETE — “제거하세요.”

게시물을 삭제하거나, 계정을 취소하거나, 오래된 데이터를 정리할 때. DELETE는 접시를 다시 가져가서 다시 돌아오지 않도록 합니다.

네 가지 동작. 거의 무한한 가능성.

모든 요청의 주소

무엇을 요청해야 할지 아는 것은 이야기의 절반에 불과합니다. 또한 어디에 요청해야 하는지도 알아야 합니다.

REST API에서는 모든 리소스—모든 데이터 조각—가 엔드포인트라고 불리는 고유한 주소를 가집니다. 이를 테이블 번호나 메뉴의 특정 항목에 비유해 보세요.

모든 사용자를 조회: GET /users
새 사용자를 추가: POST /users
특정 사용자를 조회: GET /users/1

GET /users
POST /users
GET /users/1

깨끗하고 예측 가능합니다. 패턴을 익히면 전 세계 어느 REST API에든 들어가도 바로 익숙해질 수 있습니다—메뉴가 항상 동일하게 보이기 때문이죠.

당신의 휴대폰에서의 아침

당신은 일어나서 가장 좋아하는 앱을 엽니다. 화면 구석에 있는 프로필 사진을 탭합니다. 당신은 눈치채지 못했지만, 휴대폰은 조용히 서버에 GET /profile 요청을 보냅니다. API가 이를 받아 백엔드에 전달하고, 백엔드가 당신의 데이터를 조회한 뒤 1초 이내에 이름, 사진, 상세 정보가 화면에 표시됩니다.

당신은 코드를 작성하지 않았습니다. 설정도 하지 않았습니다. 단지 탭했을 뿐입니다.

하지만 그 탭 아래에서 REST는 제 역할을 했습니다 — 조직적이고, 빠르며, 완전히 눈에 보이지 않게.

왜 전 세계가 이것에 동의했는가

Simple — 개념은 이해하기 쉽고, 구조는 따라가기 쉽다.
Standardized — 스리랑카의 개발자와 샌프란시스코의 개발자가 같은 REST API를 보고 즉시 그 기능을 이해할 수 있다.
Scalable — 작은 스타트업을 구동하는 동일한 구조가 동시에 수백만 명의 사용자를 처리할 수 있다.
Flexible — 프론트엔드와 백엔드가 서로의 비밀을 알 필요는 없으며, 단지 메뉴에 대해 합의하면 된다.

분리. 명확성. 질서.

이 문이 여는 문

REST를 이해하면 디지털 세계를 보는 시각이 조용히 바뀝니다.

피드를 불러오는 모든 앱, 주문을 받는 모든 웹사이트, 선호도를 기억하는 모든 플랫폼 — 이들은 모두 메뉴를 들고 당신과 보이지 않는 주방 사이를 오가는 웨이터에 불과합니다.

그 개념에 익숙해지면 다음과 같은 문들이 나타납니다:

GraphQL — 정확히 당신이 접시에 올리고 싶은 것을 선택할 수 있는 다른 종류의 메뉴.
WebSockets — 웨이터가 당신이 요청하기를 기다리지 않고, 준비되는 즉시 업데이트를 가져다줍니다.
Distributed systems — 하나의 주방 대신 전 세계에 수백 개의 주방이 있는 경우.

하지만 모든 것은 여기서 시작됩니다.

메뉴와 웨이터, 그리고 정확히 주문을 어떻게 해야 할지 아는 조용한 자신감과 함께.