그동안은 REST API를 주로 사용했지만, 회사에서는 GraphQL을 사용하고 있었.
처음에는 단순히 “필요한 데이터만 가져올 수 있는 쿼리 언어” 정도로 생각했지만, 실제로 사용해보니 REST와는 확실히 달랐다.
이 글에서는 프론트엔드 관점에서 GraphQL을 사용하면서 느낀 차이점과 장점을 정리했다.
1. 필요한 데이터만 가져올 수 있다
REST API를 사용할 때 가장 불편했던 점은 오버패칭(Over-fetching) 과 언더패칭(Under-fetching) 문제였다.
원하는 데이터를 얻기 위해 불필요한 필드까지 받아야 하거나,
반대로 여러 API를 조합해야만 필요한 정보를 완성할 수 있었다.
GraphQL을 사용하자 이 문제가 깔끔하게 해결되었다.
필요한 필드만 쿼리로 지정하면 그에 맞는 데이터만 반환되기 때문에,
요청 횟수와 응답 데이터의 불필요한 낭비를 크게 줄일 수 있었다.
특히 모바일 환경처럼 네트워크 비용이 민감한 상황에서 이 장점이 크게 느껴졌다.
2. 데이터 구조를 예측하기 쉬운 개발 경험
GraphQL의 스키마는 프론트엔드 개발자에게 하나의 계약서 같은 역할을 한다.
서버에서 어떤 데이터 타입이 제공되는지, 어떤 필드를 쿼리할 수 있는지가 명확하게 정의되어 있다.
덕분에 API 명세를 따로 찾아볼 필요가 거의 없었고,
IDE 자동완성 기능을 통해 어떤 데이터를 요청할 수 있는지도 즉시 확인할 수 있었다.
이는 개발 속도를 빠르게 해주었고, 타입 에러를 줄여주는 효과도 있었다.
3. 캐싱 전략의 변화
REST에서는 URL 단위로 요청이 구분되기 때문에, 캐싱이 비교적 단순했다.
하지만 GraphQL은 단일 엔드포인트를 통해 다양한 쿼리가 전달되므로,
기존의 단순한 HTTP 캐싱 방식이 통하지 않는다는 점을 처음에 체감했다.
이를 해결하기 위해 Apollo Client 같은 라이브러리의 Normalized Cache 구조를 활용했다.
처음에는 설정이 복잡하게 느껴졌지만, 한 번 익숙해지고 나니 데이터 동기화 관리가 REST보다 훨씬 정교해졌다.
특히 여러 컴포넌트가 동일한 데이터를 참조할 때, 캐시 갱신 로직을 최소화할 수 있었다.
4. 에러 핸들링과 응답 구조의 일관성
REST에서는 API마다 응답 포맷이 조금씩 달라지는 경우가 많았다.
어떤 API는 data 안에 결과를 주고, 또 어떤 API는 result라는 키를 사용하기도 했다.
GraphQL은 항상 동일한 응답 구조를 유지한다.
모든 응답은 data와 errors 필드로 구성되며,
이 덕분에 에러 처리 로직이 단순해지고 일관된 패턴으로 관리할 수 있었다.
실제로 글로벌 에러 핸들러를 구성하기 훨씬 수월했다.
5. 초기 설정과 학습 곡선의 존재
물론 GraphQL이 모든 면에서 REST보다 낫다고 말할 수는 없다.
처음 도입할 때는 스키마 정의, 리졸버 설계, 캐시 관리 등 학습해야 할 부분이 많았다.
또한 단순한 CRUD 수준의 API라면 REST가 더 빠르고 단순하게 개발할 수 있다.
즉, 프로젝트의 복잡도와 요구사항에 따라 선택이 달라져야 한다고 느꼈다.
하지만 데이터 종속성이 높고, 다양한 클라이언트에서 공통 API를 사용하는 환경이라면 GraphQL이 훨씬 유리하다.
마무리하며
프론트엔드 입장에서 GraphQL은 단순한 API 대체 기술이 아니라,
데이터를 다루는 개념이 다른 것 같다.
REST가 단방향 통신 중심의 구조였다면, GraphQL은 클라이언트가 스스로 필요한 데이터를 선언적으로 정의하는 구조다.
덕분에 데이터 의존성을 줄이고, 개발 주기를 짧게 가져갈 수 있었다.
초반 학습 비용은 존재하지만, 한 번 구조를 잡아놓으면 장기적으로 유지보수성과 확장성이 크게 향상된다는 큰 장점이 있다.