웹 서비스가 복잡해지면서 백엔드 개발자들이 흔히 마주하는 요구사항이 있습니다.
"새로운 프로필 페이지가 생겼는데, 여기에 딱 맞는 데이터만 모아서 내려주는 API 하나 만들어주세요."
빠른 피드백과 당장의 프론트엔드 개발 편의성을 위해 이런 요청을 수락하고 특정 페이지나 액션을 위한 API를 만들기 쉽습니다.
하지만 시간이 지날수록 이는 백엔드 시스템에 큰 부메랑으로 돌아옵니다.
오늘은 왜 특정 페이지를 위한 API 구성을 피해야 하는지, 그리고 백엔드의 책임을 줄이는 올바른 API 설계 방향에 대해 이야기해보려 합니다.
특정 페이지에 국한된 API의 함정
화면(UI) 요구사항에 맞춰 데이터를 반환하거나 특정 액션만을 위해 구성된 API(이하 UI 종속적 API)는 다음과 같은 치명적인 단점을 가집니다.
재사용성의 실종과 API의 파편화
A 페이지를 위해 만든 GET /api/page-a-data API가 있다고 가정해 보겠습니다.
얼마 뒤 비슷한 데이터를 보여주는 B 페이지가 생겼을 때, 이 API를 재사용할 수 있을까요? 대부분의 경우 불가능합니다.
B 페이지는 A 페이지와 UI 구성이 조금 다르거나, 필요한 데이터의 깊이가 다르기 때문입니다. 결국 백엔드는 GET /api/page-b-data라는 또 다른 불필요한 API를 추가로 구현해야 합니다.
UI 변경이 백엔드 배포로 이어지는 강한 결합도
프론트엔드에서 화면의 레이아웃을 바꾸거나 버튼 하나를 추가할 때마다 백엔드 API도 수정되어야 합니다.
이는 프론트엔드와 백엔드의 강한 결합을 의미하며, 독립적인 배포와 유지보수를 어렵게 만듭니다.
해결책
이러한 악순환을 끊어내기 위해서는 API 설계의 패러다임을 바꿔야 합니다.
API는 프론트엔드의 '화면'을 그리기 위해 존재하는 것이 아니라, 백엔드가 관리하는 '도메인 모델(리소스)' 그 자체를 반환해야 합니다.
UI 구성의 책임은 클라이언트에게
백엔드는 데이터의 무결성을 검증하고, 비즈니스 로직을 처리하며, 시스템이 관리하는 리소스의 상태를 제공하는 데 집중해야 합니다. 회원(User), 주문(Order), 상품(Product) 등 도메인 관점에서의 RESTful한 API를 제공하고, 이 데이터들을 조합하고 가공하여 화면에 그리는 책임은 프론트엔드(클라이언트)로 위임해야 합니다.
유연성과 재사용성의 확보
도메인 중심의 범용적인 API를 설계하면, 새로운 페이지나 기능이 추가되더라도 기존 API를 조합하여 충분히 대응할 수 있습니다. 백엔드는 불필요한 API 엔드포인트를 늘릴 필요가 없고, 프론트엔드는 백엔드의 배포를 기다리지 않고도 유연하게 화면을 구성할 수 있게 됩니다.
댓글 0
댓글은 회원만 작성할 수 있습니다.
로그인하고 댓글 달기