2026년 기준 GraphQL 기업 도입률은 50%를 돌파했지만, REST 사용률은 여전히 93%로 두 방식의 공존이 지속되고 있다.
Postman의 2025 State of the API Report에 따르면 개발자의 93%가 여전히 REST를 사용하지만, 33%는 GraphQL을 병행해서 쓴다고 답했습니다. 흥미로운 건 2026년 기준 프로덕션 환경에서 GraphQL을 사용하는 기업이 50%를 넘었다는 점입니다. 2021년만 해도 10%에 그쳤던 수치죠. 그렇다면 지금 새 프로젝트를 시작하는 우리는 어떤 선택을 해야 할까요? 이 글은 두 방식의 핵심 차이를 정리하고, 제가 실제 프로젝트에서 두 가지를 모두 써본 경험을 바탕으로 어떤 상황에 무엇이 맞는지 구체적으로 안내합니다.
REST API와 GraphQL, 짧게 다시 정리하면?
REST(Representational State Transfer) API는 URL 엔드포인트를 기반으로 데이터를 요청하는 아키텍처 스타일입니다. GET /users/1처럼 리소스를 URL로 표현하고, HTTP 메서드(GET, POST, PUT, DELETE)로 작업을 구분합니다. Stripe, Twilio, GitHub 같은 회사들이 수십억 달러 규모의 비즈니스를 REST API 위에 올린 이유는 단순히 오래되었기 때문이 아니라, 캐싱과 호환성 측면에서 여전히 강력한 선택지이기 때문입니다.
GraphQL은 Meta가 2012년 사내에서 개발하고 2015년 오픈소스로 공개한 쿼리 언어입니다. 단일 엔드포인트(/graphql)에 클라이언트가 원하는 데이터의 구조를 직접 명시해서 요청합니다. 서버가 응답 구조를 결정하는 REST와 달리, GraphQL은 클라이언트가 필요한 필드만 선택적으로 요청할 수 있다는 점이 핵심 차이입니다.
처음 GraphQL을 공부할 때 저는 “그럼 REST는 곧 사라지는 건가?”라고 생각했는데, 6년이 지난 지금까지도 그런 일은 일어나지 않았습니다. 두 방식은 서로를 대체하기보다 공존하는 쪽으로 흘러왔습니다.
핵심 차이 한눈에 보기
두 방식의 가장 큰 차이는 데이터 요청 주도권이 어디에 있느냐입니다.
| 구분 | REST API | GraphQL |
|---|---|---|
| 엔드포인트 | 리소스별 다수 | 단일 (/graphql) |
| 응답 구조 결정 | 서버 | 클라이언트 |
| 오버페칭 | 발생 가능 | 없음 |
| 언더페칭 | 발생 가능 | 없음 |
| HTTP 캐싱 | 기본 지원 | 별도 구현 필요 |
| 학습 곡선 | 낮음 | 상대적으로 높음 |
| 실시간 지원 | WebSocket 등 별도 구현 | Subscription 기본 제공 |
오버페칭(Overfetching) 이란 필요한 데이터보다 더 많이 받아오는 현상입니다. 사용자 이름 하나만 필요한데 GET /users/1을 호출하면 이메일, 전화번호, 가입일까지 전부 따라옵니다. 언더페칭(Underfetching) 은 반대로 한 번의 요청으로 부족해 추가 호출이 필요한 상황입니다. 게시글 목록과 작성자 정보를 함께 보여주려면 /posts와 /users/:id를 따로 호출해야 하는 경우가 대표적이죠.
GraphQL은 이 두 문제를 쿼리 하나로 해결합니다.
graphql
query {
user(id: "1") {
name
posts {
title
createdAt
}
}
}위 쿼리 하나로 사용자 이름과 해당 사용자의 게시글 제목·작성일을 한 번에 가져올 수 있습니다. 작년에 사내 어드민 패널을 리팩토링할 때 이 방식으로 전환했는데, 대시보드 한 화면에서 호출하던 API가 4개에서 1개로 줄었습니다. 실제 측정해 본 결과 첫 화면 로딩 시간이 약 1.8초에서 0.7초로 단축됐습니다.
2026년 지금, 두 방식은 실제로 어떻게 쓰이고 있을까?
단순히 “둘 다 많이 쓴다”로 넘기기엔 너무 많은 이야기가 있습니다. 데이터를 보면 흥미로운 흐름이 보입니다.
REST는 여전히 표준이지만, 자리매김이 명확해졌습니다. Postman 2025 State of the API Report 기준 개발자 93%가 REST를 사용 중이며, 공개 API 시장에서는 압도적입니다. GitHub, Stripe, Kakao 같은 서비스가 REST를 유지하는 이유는 캐싱이 쉽고, 외부 개발자가 학습 없이 바로 호출할 수 있기 때문입니다.
GraphQL은 BFF(Backend for Frontend) 영역에서 빠르게 자리 잡았습니다. 기업 도입률은 2021년 10%에서 2026년 50% 이상으로 늘었고, Gartner는 2027년까지 60%를 넘을 것으로 예측합니다. 모바일 우선 회사의 78%가 클라이언트용 API에 GraphQL을 쓰고 있다는 통계도 있습니다.
다만 모든 GraphQL 도입이 성공한 건 아닙니다. 디버깅 난이도, 운영 복잡도, N+1 문제 때문에 GraphQL에서 다시 REST로 돌아온 기업도 적지 않습니다. JavaCodeGeeks가 2026년에 분석한 자료에 따르면, GraphQL 관련 Stack Overflow 질문의 약 40%가 답변되지 않은 상태로 남아 있다고 합니다. 이는 프로덕션에서 마주치는 복잡도가 만만치 않다는 신호입니다.
제가 두 가지를 모두 운영해 보면서 가장 크게 느낀 건 이겁니다. “GraphQL은 도입 비용이 비싸다.” 스키마 설계, DataLoader 같은 N+1 방지 도구, Apollo Client 캐싱 전략, 보안(쿼리 깊이 제한, 복잡도 분석)까지 모두 학습 비용이 따라옵니다. 도입 효과보다 운영 부담이 클 수 있다는 사실을 충분히 검토하고 결정해야 합니다.
어떤 신호가 있으면 GraphQL을, 어떤 신호가 있으면 REST를 골라야 할까?
이론보다 실제 결정에 바로 쓸 수 있는 기준을 정리했습니다.
GraphQL을 고려해야 하는 신호:
- 여러 API를 호출해 데이터를 조합하는 로직이 프론트엔드 코드에 반복적으로 등장한다
- 모바일과 웹이 같은 백엔드를 공유하면서 필요한 데이터량이 다르다 (BFF 패턴)
- 실시간 구독(Subscription) 기능이 요구된다
- 프론트엔드 팀이 백엔드 팀의 엔드포인트 추가 대기 없이 독립적으로 일하고 싶다
- 데이터 관계가 깊고 다양한 traversal(예: 사용자 → 팔로워 → 그들의 게시글 → 댓글)이 필요하다
REST API를 유지/선택해야 하는 신호:
- API 리소스가 단순하고 관계가 복잡하지 않다
- 외부 개발자에게 공개 API를 제공해야 한다
- 마이크로서비스 간 내부 통신처럼 계약이 명확한 경우
- HTTP 캐싱이 성능에 결정적이다 (CDN, 브라우저 캐시 활용)
- 팀 규모가 작거나 빠른 출시가 우선이다
- 파일 업로드처럼 멀티파트 요청이 많다
두 방식은 경쟁 관계가 아니라 상황에 따른 선택지입니다. 실제로 GitHub, Shopify, Netflix, Airbnb는 GraphQL과 REST를 함께 운영합니다. 내부 마이크로서비스 통신은 REST로, 클라이언트-서버 인터페이스는 GraphQL로 운영하는 하이브리드 구조가 일반적입니다.
API 선택과 마찬가지로 빌드 도구 선택도 팀과 프로젝트 상황에 따라 달라집니다. 비슷한 고민을 했던 Vite vs Webpack 2026, 속도 차이가 얼마나 날까?도 참고해 보세요. 그리고 API에서 받아온 데이터를 브라우저에서 효율적으로 렌더링하려면 웹 성능 최적화 입문: Lighthouse 점수 높이는 법도 함께 읽어보길 권장합니다.
GraphQL 공식 문서(graphql.org/learn)와 Apollo Client 공식 문서(apollographql.com/docs/react)는 시작점으로 가장 신뢰할 수 있는 자료입니다. MDN의 HTTP caching 가이드는 REST 캐싱을 깊이 이해하는 데 도움이 됩니다.
자주 묻는 질문 (FAQ)
Q. REST API와 GraphQL 중 어떤 것이 더 빠른가요?
상황에 따라 다릅니다. GraphQL은 필요한 데이터만 요청하므로 네트워크 전송량이 줄어들지만, 서버에서 쿼리를 파싱하고 리졸버를 실행하는 오버헤드가 추가됩니다. 한 사례 연구에서는 REST에서 GraphQL로 대시보드를 리팩토링했을 때 오버페칭 제거와 호출 통합으로 로딩 시간이 60% 감소했지만, 또 다른 사례에서는 N+1 문제로 오히려 느려진 경우도 있었습니다. 데이터 관계가 복잡할수록 GraphQL의 네트워크 효율이 빛을 발하고, 단순 CRUD일수록 REST가 더 빠른 경향이 있습니다.
Q. GraphQL을 사용하면 REST API가 필요 없어지나요?
그렇지 않습니다. 2026년 현재 GitHub, Shopify, Netflix, Airbnb 같은 회사들이 GraphQL과 REST를 동시에 운영하고 있습니다. 파일 업로드, 외부 공개 API, 단순 CRUD 서비스, 내부 마이크로서비스 통신에는 REST가 더 적합합니다. 제 경우에는 외부 클라이언트가 호출하는 공개 API는 REST로 두고, 내부 어드민 BFF 레이어만 GraphQL로 옮긴 적이 있습니다. 두 방식을 혼합하는 게 자연스러운 흐름입니다.
Q. Next.js 프로젝트에서 GraphQL을 사용하려면 어떻게 시작하면 좋을까요?
가장 많이 사용하는 조합은 Apollo Client(프론트엔드)와 Apollo Server(백엔드)입니다. Next.js App Router 환경에서는 Apollo Client의 React Server Components 지원 여부를 먼저 확인해야 합니다. 초기 학습 비용을 줄이고 싶다면 Hasura처럼 기존 데이터베이스에 GraphQL API를 자동으로 생성해 주는 BaaS 도구를 활용하는 방법도 있습니다. 처음부터 풀스택 GraphQL을 구축하지 말고, 기존 REST 위에 BFF 레이어로 GraphQL을 얹는 점진적 도입을 추천합니다.
Q. GraphQL의 N+1 문제란 무엇인가요?
GraphQL에서 N+1 문제는 중첩 쿼리를 처리할 때 발생합니다. 예를 들어 게시글 10개를 조회하면서 각 게시글의 작성자를 가져올 때, 리졸버가 10번의 별도 데이터베이스 쿼리를 실행하는 현상입니다(1번의 목록 조회 + N번의 작성자 조회). 이를 해결하기 위해 DataLoader 라이브러리를 사용해 요청을 배치로 묶어 처리합니다. 제가 GraphQL 서버를 처음 운영했을 때 가장 먼저 마주친 성능 이슈가 정확히 이 N+1이었습니다. DataLoader 적용 전후로 DB 쿼리가 100건에서 2건으로 줄었으니, 도입 전에 반드시 고려해야 할 실무 이슈입니다.
Q. GraphQL을 도입했다가 다시 REST로 돌아간 사례도 있나요?
네, 적지 않습니다. 디버깅 난이도, 운영 복잡도, 보안(쿼리 깊이 제한·복잡도 분석), 캐싱 전략 등에서 예상치 못한 부담이 발생한 경우가 보고되고 있습니다. 핵심은 “GraphQL이 해결하는 문제가 우리 팀의 실제 문제와 일치하는가?”입니다. 단순히 트렌드를 따라가는 도입은 오히려 부채가 됩니다.
결론
REST API와 GraphQL은 어느 쪽이 절대적으로 낫다고 단정 지을 수 없습니다. 2026년 현재 데이터를 보면, REST는 공개 API와 단순 CRUD에서 여전히 강력하고, GraphQL은 BFF 레이어와 복잡한 데이터 관계에서 빛을 발합니다. 두 방식을 혼합해 운영하는 회사들이 늘어나는 흐름은 결국 우리에게도 동일한 메시지를 줍니다. 트렌드가 아니라 문제에 맞게 선택할 것. 제 경험상 가장 좋은 결과는 “이 도구가 우리 팀이 풀고 있는 문제를 정말 풀어주는가?”를 솔직하게 따져봤을 때 나왔습니다.
프론트엔드 개발자로서 전체적인 기술 스택을 어떻게 쌓아가야 할지 궁금하다면 2026년 프론트엔드 개발자 로드맵을 참고해 보세요.
