REST API의 단점은 무엇인가요?

REST API 단점: 오버페칭과 언더페칭 문제

REST API 단점을 정확히 파악하면 효율적인 아키텍처를 설계하는 데 큰 도움이 됩니다. 데이터 전송 효율이 떨어지거나 불필요한 네트워크 비용이 발생하는 상황을 방지하고 시스템 성능을 개선할 기초 지식이 됩니다. 올바른 설계 방향을 설정하여 기술적 한계를 극복하고 리소스 낭비를 줄여보세요.

REST API의 주요 한계와 아키텍처적 단점 개요

REST API는 현대 웹 아키텍처에서 널리 사용되지만, 아키텍처 스타일 중심의 접근 방식 특성상 설계 일관성이 부족해질 수 있고 데이터 전송 효율 문제도 자주 발생합니다. 특히 클라이언트가 필요한 것보다 더 많거나 적은 데이터를 받는 오버페칭 언더페칭 해결 문제는 네트워크 자원 낭비와 성능 저하의 주요 원인으로 지적됩니다. 또한 엔드포인트 관리와 버전 제어가 복잡해질 경우 유지보수 비용 증가로 이어질 수 있습니다.

REST(Representational State Transfer)는 엄격한 표준 규격보다는 여러 제약 조건을 기반으로 하는 아키텍처 스타일입니다. 이러한 특성은 유연성을 제공하지만, 팀마다 리소스 경로 설계 방식이나 응답 구조가 달라질 수 있어 대규모 프로젝트에서는 일관성 유지가 어려워질 수 있습니다. 따라서 REST API 설계 시 주의사항을 숙지하고 팀 내부의 명확한 규칙과 문서화를 함께 운영하는 것이 중요합니다.

오버페칭(Over-fetching)과 언더페칭(Under-fetching)의 비효율성

오버페칭은 클라이언트가 화면에 표시할 데이터는 이름뿐인데, API 응답에는 주소, 전화번호, 가입일 등 수십 개의 필드가 포함되어 내려오는 현상을 말합니다. 모바일 환경에서 이는 치명적입니다. 통계에 따르면 모바일 애플리케이션에서 REST API를 사용할 경우, 실제로 사용되지 않는 데이터가 전체 페이로드의 상당 부분을 차지하는 경우가 허다합니다.^[1] 이는 사용자의 데이터 플랜을 낭비할 뿐만 아니라 기기의 배터리 소모를 가속화합니다.

반대로 언더페칭은 하나의 화면을 구성하기 위해 여러 번의 API 호출이 필요한 상황입니다. 예를 들어 사용자의 주문 목록을 가져온 뒤, 각 주문의 상세 상품 정보를 가져오기 위해 다시 N번의 호출을 해야 하는 N+1 문제가 대표적입니다. 네트워크 레이턴시가 100ms인 환경에서 5번의 순차적인 API 호출은 사용자에게 0.5초 이상의 지연을 강제합니다. 이는 단순한 불편함을 넘어 사용자 이탈률을 높이는 직접적인 원인이 됩니다. ^[2]

공식 표준 부재와 문서화의 늪

REST는 HTTP 프로토콜을 기반으로 하지만, 리소스 명명 규칙이나 오류 처리 방식에 대한 통일된 구현 표준은 제공하지 않습니다. 이 때문에 프로젝트나 조직마다 API 설계 스타일이 달라질 수 있습니다. REST API 문제점 중 하나는 어떤 팀은 HTTP 상태 코드 중심으로 오류를 처리하고, 다른 팀은 응답 본문 내부에 별도의 오류 정보를 포함하기도 한다는 점입니다.

이러한 파편화는 문서화 부담을 기하급수적으로 늘립니다. API 명세가 조금만 바뀌어도 수동으로 문서를 업데이트해야 하며, 이 과정에서 발생하는 휴먼 에러는 프론트엔드와 백엔드 간의 불필요한 논쟁을 유발합니다. 실제로 API 개발 및 문서화 작업은 전체 백엔드 개발 일정의 상당 부분을 차지하며, 표준이 없는 REST 환경에서는 이 수치가 더 높아질 가능성이 큽니다. ^[3]

데이터 모델링과 실시간성 구현의 한계

REST API는 자원 기반의 구조를 가지기 때문에 복잡한 관계형 데이터베이스(RDBMS)의 모델을 표현하는 데 한계가 명확합니다. 자원 간의 깊은 중첩 관계를 URI로 표현하다 보면 경로가 지나치게 길어지거나, 가독성이 현저히 떨어지는 구조가 만들어지기 일쑤입니다. 또한, 실시간 데이터 전송이 필요한 환경에서는 REST의 무상태성(Stateless)과 단방향 통신 구조가 큰 걸림돌이 됩니다.

RDBMS와 객체 간 불일치 문제

데이터베이스에는 수많은 테이블이 복잡하게 얽혀 있지만, REST API는 이를 평면적인 JSON 리소스로 변환하여 전달해야 합니다. 다대다(N:M) 관계나 복잡한 조인(Join) 결과물을 RESTful하게 설계하는 것은 매우 고통스러운 작업입니다. 무리하게 REST 스타일을 고집하다 보면 결국 API 엔드포인트가 수백 개로 늘어나는 엔드포인트 폭발 현상을 겪게 됩니다. REST API 단점을 고려하지 않고 모든 관계를 엔드포인트로 만들려다 관리 불능 상태에 빠지는 경우도 빈번합니다.

실시간 데이터 처리의 비효율성

REST API는 클라이언트 요청에 대해 서버가 응답하는 풀(Pull) 방식 기반으로 동작합니다. 따라서 실시간 채팅이나 주식 시세처럼 지속적인 데이터 갱신이 필요한 서비스에서는 클라이언트가 일정 간격으로 반복 요청을 보내는 폴링(Polling) 방식을 사용해야 하는 경우가 많습니다. REST API GraphQL 차이점을 이해한다면, 실시간성이 중요한 환경에서는 WebSocket과 같은 양방향 통신 기술이나 대안적인 쿼리 언어가 더 적합할 수 있음을 알게 됩니다.

엔드포인트 관리와 버전 제어의 복잡성

도입부에서 언급했던 운영 비용 상승의 핵심 원인이 바로 여기 있습니다. REST API는 리소스가 변경될 때마다 하위 호환성을 위해 버전을 관리해야 합니다. 보통 URI에 v1, v2를 붙이는 REST API 버전 관리 방법을 쓰는데, 서비스가 커질수록 관리해야 할 엔드포인트가 기하급수적으로 늘어납니다. 이전 버전을 사용하는 클라이언트가 남아있으면 서버는 해당 코드를 계속 유지해야 합니다.

실제로 대형 서비스의 경우 관리되는 API 버전이 5개 이상 넘어가면 보안 취약점 패치나 라이브러리 업데이트 시 작업량이 3배 이상 늘어납니다. 하위 호환성을 깨지 않으면서 기능을 추가하려다 보니 코드는 점점 '스파게티'가 되어가고, 테스트 케이스는 감당할 수 없을 정도로 불어납니다. 버전 관리는 선택이 아닌 생존의 문제이지만, REST 구조에서는 이 과정이 유독 투박하고 번거롭습니다.

REST API와 대안 기술(GraphQL, gRPC) 비교

REST API

• 낮음 (아키텍처 스타일일 뿐 규약이 없음)

• 낮음 (HTTP 기본 지식만으로 시작 가능)

• 매우 높음 (HTTP 표준 캐싱 메커니즘 활용 가능)

• 낮음 (오버페칭 및 언더페칭 발생 빈도 높음)

GraphQL

• 높음 (강력한 타입 시스템과 스키마 존재)

• 보통 (쿼리 언어와 스키마 정의 학습 필요)

• 낮음 (엔드포인트가 하나라 HTTP 캐싱 적용이 어려움)

• 매우 높음 (클라이언트가 필요한 필드만 정확히 요청)

gRPC (추천: 마이크로서비스 간 통신)

• 매우 높음 (엄격한 계약 기반 인터페이스 정의)

• 높음 (HTTP/2 및 이진 직렬화 이해 필요)

• 낮음 (이진 프로토콜 특성상 전통적 캐싱 불가)

• 최상 (Protocol Buffers 기반 이진 포맷 사용)

스타트업 A사의 데이터 다이어트 성공기

서울 소재의 여행 플랫폼 스타트업 A사는 사용자 2만 명을 넘어서면서 서버 비용 문제에 직면했습니다. REST API를 통해 호텔 상세 정보를 불러올 때마다 150개가 넘는 필드를 포함한 20KB 크기의 JSON을 전송하고 있었죠. 정작 앱 메인 화면에서 사용하는 데이터는 단 5개뿐이었습니다.

처음에는 API 응답을 줄이기 위해 별도의 '요약용 엔드포인트'를 수십 개 만들었습니다. 하지만 이는 관리해야 할 코드만 늘렸고, 프론트엔드 팀은 어떤 API를 써야 할지 몰라 혼란에 빠졌습니다. 결과적으로 개발 속도가 30% 이상 느려지는 역효과만 났습니다.

팀은 무분별한 엔드포인트 생성을 멈추고, 꼭 필요한 데이터만 필터링해서 보내는 BFF(Backend for Frontend) 계층을 도입했습니다. 데이터 구조를 전면 재검토하는 데 3주가 걸렸지만, 그 과정에서 불필요한 레거시 필드들을 과감히 쳐낼 수 있었습니다.

그 결과 API 페이로드 크기는 평균 85% 감소했고, 사용자들의 첫 페이지 로딩 시간은 1.2초에서 0.3초로 단축되었습니다. 서버 대역폭 비용도 월 1,500달러 이상 절감하며 운영 효율성을 극대화했습니다.