기획자를 위한 웹/앱 구조 ① 버튼 하나 누르면 생기는 일 — 요청과 응답

기획자가 서버를 만들 일은 없다. 하지만 회의에서는 이런 말들이 오간다.

“그건 프론트에서 처리할게요” · “API가 아직 안 나와서요” · “스테이징에 올렸으니 확인해 주세요” · “DB 마이그레이션이 필요해서 하루 걸려요” · “포트가 안 열려 있어서 접속이 안 되는 거예요”

이 문장들이 무슨 뜻인지, 어디서 일어나는 일인지 알면 — 일정 협의가 빨라지고, 요청을 엉뚱한 사람에게 하지 않게 되고, “그게 왜 오래 걸려요?” 대신 “아, 그건 백엔드 작업이군요”라고 말할 수 있게 된다. 이 시리즈의 목표는 딱 그만큼이다. 코드는 한 줄도 나오지 않는다.

큰 그림 — 요청과 응답 한 사이클

서비스의 모든 기능은 결국 아래 한 사이클의 반복이다. 사용자가 화면에서 무언가를 누르면, 요청(request) 이 서버로 가고, 서버가 응답(response) 을 돌려주고, 화면이 그 결과를 그린다.

요청·응답 한 사이클

기획 문서와의 연결: 화면 기획서에 그리는 버튼 하나하나가 곧 “요청 하나”다. “이 버튼을 누르면 어떤 데이터가 오가는가?”를 상상할 수 있으면 개발 난이도 감각이 생긴다. 화면만 바뀌는 것(탭 전환·정렬)은 싸고, 서버에 다녀와야 하는 것(조회·저장)은 상대적으로 비싸다.

요청과 응답의 생김새

요청은 항상 세 부분으로 이루어진다: 어디로(URL) + 무슨 행위(메서드) + 내용물(바디). 응답은 결과 코드(상태코드, 7편에서) + 데이터(주로 JSON)다.

메서드	행위	예시
GET	조회 — 데이터를 달라	주문 목록 보기, 상품 검색. 여러 번 눌러도 같은 결과
POST	생성 — 새로 만들어라	주문하기, 회원가입, 글쓰기. 두 번 보내면 두 개 생길 수 있음 — 중복 클릭 이슈의 뿌리
PUT / PATCH	수정 — 바꿔라	배송지 변경, 프로필 수정
DELETE	삭제 — 지워라	게시글 삭제, 장바구니 비우기

“조회는 GET, 나머지는 부수효과가 있다”만 기억해도 충분하다.

여기서 멱등성이라는 말이 나온다 — 같은 요청을 여러 번 보내도 결과가 한 번 보낸 것과 같으면 멱등하다. GET·PUT·DELETE는 멱등하고, POST는 멱등하지 않아서 “결제 버튼 두 번 눌렀더니 두 번 결제됐다”는 사고가 가능하다. 결제·주문 기획서에 중복 제출 방지가 반드시 들어가야 하는 이유다.

REST — 주소와 행위를 짓는 관례

개발자들이 “REST API”, “RESTful하게”라고 말하는 것은 API 주소를 짓는 관례다: URL은 자원(명사)을 가리키고, 행위는 메서드로 표현한다.

GET    /orders      주문 목록 조회
POST   /orders      주문 생성
GET    /orders/17   17번 주문 조회
DELETE /orders/17   17번 주문 취소

이 규칙을 따르면 API 이름만 봐도 기능을 짐작할 수 있다.

REST API = 이 관례로 설계된 API. RESTful = “그 관례를 잘 따른다”는 형용사. REST 서버 = 그런 API를 제공하는 백엔드 서버.
기획자 관점: API 목록 문서를 받으면 [메서드 + URL]만 훑어도 기능 지도가 그려진다. 요즘 API 문서는 Swagger(스웨거)라는 자동 문서 화면으로 공유되는 경우가 많다.

시리즈 전체 보기: ① 요청과 응답 · ② 정적/동적 웹 · ③ 다섯 명의 등장인물 · ④ 라이브러리와 프레임워크 · ⑤ 서버의 층위와 MSA · ⑥ 주소와 환경 · ⑦ 상태코드와 통역표 · ⑧ UML과 용어사전