“REST API는 익숙한데, 왜 GraphQL을 쓰는 프로젝트가 늘고 있을까?”
REST는 여전히 강력한 API 설계 방식이지만, 프론트엔드 입장에서 보면 불필요한 데이터 요청이나 중복 호출로 인한 비효율이 존재한다.
이 글에서 REST의 구조와 한계를 살펴보고, GraphQL이 어떻게 프론트엔드 개발자에게 더 편리한 API 경험을 제공하는지 정리해보자.
🔧 REST API의 기본 구조
REST는 리소스 중심의 HTTP API 설계 방식이다.
특징
- URL로 자원 지정 (
/users,/posts/1) - HTTP 메서드로 동작 구분 (
GET,POST,PUT,DELETE) - 통상 JSON으로 주고받음
- 브라우저와의 연동이 쉬워 웹에서 널리 쓰임
예시
GET /users/1
→ { "id": 1, "name": "Alice", "posts": [ ... ] }❗ REST의 한계 – 오버페칭 & 언더페칭
| 문제 | 설명 |
|---|---|
| 오버페칭 (Over-fetching) | 내가 필요하지 않은 데이터까지 같이 옴 |
| 언더페칭 (Under-fetching) | 한 번에 필요한 데이터를 다 못 받아서 여러 번 요청해야 함 |
예시 – 사용자 프로필 + 최근 게시글 필요
REST 구조에서는 보통 이렇게 호출:
GET /users/1
GET /users/1/posts?limit=3→ 두 번 호출해야 원하는 화면을 그릴 수 있음
→ 클라이언트 단에서 비효율 증가
⚙️ GraphQL이란?
클라이언트가 필요한 데이터만 명확하게 요청할 수 있도록 설계된 API 쿼리 언어이다.
- 하나의 엔드포인트 (
/graphql)만 사용 - 어떤 필드를 받고 싶은지 명시적으로 선언
- 오버페칭/언더페칭 문제 해결
예시 – 위의 문제를 GraphQL로 해결
query {
user(id: 1) {
name
posts(limit: 3) {
title
}
}
}→ 서버는 정확히 그 구조로만 응답함
→ 프론트엔드가 원하는 데이터만 받아올 수 있음!
🧠 GraphQL의 핵심 개념
| 개념 | 설명 |
|---|---|
| Schema | 요청 가능한 데이터 구조 정의 |
| Query | 데이터를 조회하는 요청 |
| Mutation | 데이터를 수정하는 요청 (POST/PUT/DELETE 대체) |
| Resolver | 실제 데이터를 가져오는 서버단 함수 |
🤝 REST와 GraphQL의 비교
| 항목 | REST | GraphQL |
|---|---|---|
| 구조 | 여러 엔드포인트 | 단일 엔드포인트 |
| 요청 단위 | URL + 메서드 | Query 언어 |
| 응답 데이터 | 고정된 구조 | 요청한 구조대로 응답 |
| 요청 수 | 자주 여러 번 | 대부분 1번에 해결 가능 |
| 학습 난이도 | 낮음 | 초반 학습 필요 |
| 캐싱 | 브라우저 친화적 (HTTP 기반) | 캐싱 전략은 클라이언트 라이브러리 필요 (Apollo 등) |
🧩 REST와 GraphQL, 공존할 수 있을까?
충분히 가능! 실제로 많은 프로젝트가 둘을 함께 사용한다.
| 전략 | 설명 |
|---|---|
| REST는 인증, 파일 업로드 등 단순/정형화된 API에 사용 | |
| GraphQL은 복잡한 UI, 유연한 데이터가 필요한 화면에 사용 | |
| 내부 통신은 REST, 외부 노출은 GraphQL로 구성하는 하이브리드 구조도 많음 |
✅ 프론트엔드 개발자를 위한 실전 팁
- GraphQL은 화면 중심 설계에 강력함 → “화면 = 데이터 구조” 느낌
- Apollo Client, Relay 같은 GraphQL 클라이언트 라이브러리를 활용하면 캐싱·에러 처리도 쉽게 가능
- GraphQL에서는 항상 스키마 중심으로 개발이 이뤄지므로 타입 안정성에 유리
- 코드 자동 생성 도구 (
graphql-codegen) 활용 시 TypeScript와 찰떡
✍️ 마무리 요약
GraphQL은 REST의 고정된 구조를 벗어나, 프론트엔드가 필요한 데이터만 명확히 정의해서 받아올 수 있는 유연한 방식이다.
프로젝트의 복잡도와 목적에 따라 REST와 함께 사용하는 전략이 현실적이다.
okorion's Tech Study Blog.