RESTful API에서의 오버페칭(Over-Fetching)과 언더페칭(Under-Fetching)

현대 웹 애플리케이션과 데이터 중심 서비스에서는 클라이언트와 서버 간의 효율적인 데이터 통신이 매우 중요하다. 특히 데이터 분석 시스템이나 대시보드처럼 실시간, 대용량 데이터를 다루는 환경에서는 API 설계 방식이 전체 시스템 성능과 사용 경험에 중대한 영향을 미친다.

이 글에서는 RESTful API 환경에서 자주 발생하는 두 가지 문제, 오버페칭(Over-Fetching)과 언더페칭(Under-Fetching)에 대해 설명하고, 이를 최소화하기 위한 고려사항을 알아보자

1. 오버페칭(Over-Fetching)이란?

오버페칭은 클라이언트가 실제로 필요하지 않은 데이터를 서버로부터 받아오는 현상을 의미한다. 이는 데이터 전송량 증가, 페이지 렌더링 속도 저하, 불필요한 메모리 점유로 이어질 수 있다.

1.1 오버페칭 예시

GET /users

응답 데이터:
{
  "id": 1,
  "name": "ruby",
  "age": 18,
  "color": "red"
}

위의 예시에서 클라이언트는 name만 필요하지만, 불필요하게 id, age, color도 함께 전달된다.

1.2 오버페칭의 문제점

• 네트워크 대역폭 낭비
• 클라이언트 메모리 및 처리 시간 증가
• 불필요한 데이터 전송에 따른 보안 리스크

1.3 해결 방법

• REST API 필터링 기능 활용

  GET /users?fields=name,email

• 동적 쿼리가 가능한 API 설계 적용

  GraphQL 같은 방식은 클라이언트가 필요한 필드만 명시해 요청할 수 있어 오버페칭을 최소화할 수 있다.

  query {
    user {
      name
      email
    }
  }

2. 언더페칭(Under-Fetching)이란?

언더페칭은 클라이언트가 필요한 데이터를 한 번의 요청으로 받아오지 못해, 여러 API 요청을 반복해야 하는 상황을 말한다. 이는 전체 응답 시간을 늘리고, 클라이언트 로직을 복잡하게 만든다.

2.1 언더페칭의 예시

게시판 목록에서 각 게시글과 작성자 정보를 동시에 보여주고자 할 때:

• /posts 요청 → 게시글 정보만 반환
• 각 게시글마다 /users/{id} 요청 → 작성자 정보 따로 요청

게시글이 n개라면, n+1번의 API 요청이 필요하다.

2.2 언더페칭의 문제점

• 네트워크 요청 수 증가
• 사용자 응답 지연
• 프론트엔드 병합 로직 복잡화

2.3 해결 방법

• REST API 설계 개선

  작성자 정보를 포함해 반환하는 API를 설계한다.

  GET /posts?include=author

• 복합 데이터 응답을 허용하는 API 도입

  예를 들어, GraphQL에서는 다음과 같이 단일 요청으로 구조화된 데이터를 받아올 수 있다.

  query {
    posts {
      id
      title
      author {
        name
        email
      }
    }
  }

3. 결론

• 실시간 대시보드나 메트릭 수집 시스템에서 오버페칭은 성능 저하의 주요 원인이 된다.
• 언더페칭은 데이터 병합 로직 증가로 인해, 클라이언트-서버 간의 병목 또는 오류 발생 가능성을 높인다.
• ETL 파이프라인을 설계할 때도 필요한 데이터가 한 번에 수집되지 않는 언더페칭 구조는 API 병렬 처리, 스케줄 최적화 등의 추가 로직을 요구한다.