GraphQL: 엔터프라이즈의 허니문은 끝났다

• GraphQL은 데이터 과다 요청 문제를 해결하려 하지만, 대부분의 엔터프라이즈 환경에서는 이미 다른 방식으로 해결된 문제임
• BFF(Backend for Frontend) 구조가 일반화된 기업 시스템에서는 GraphQL의 주요 장점이 크게 줄어듦
• 구현 복잡도, 관찰성 저하, 캐싱 문제, ID 제약, 파일 처리의 불편함 등으로 실제 운영 환경에서 비용이 커짐
• REST는 단순하고 빠르며, 오류 처리와 온보딩이 쉬워 대규모 팀 환경에서 더 효율적임
• 결론적으로 GraphQL은 특정 상황에서는 유용하지만, 대부분의 엔터프라이즈에는 과도한 선택이라는 평가

GraphQL이 해결하려는 문제

• GraphQL의 핵심 목적은 overfetching(불필요한 데이터 과다 요청) 방지
  • 클라이언트가 필요한 필드만 요청해 불필요한 데이터 전송을 줄이는 구조
  • 새로운 UI 요구사항마다 백엔드 수정이 필요 없다는 장점
• 그러나 실제 환경에서는 이 이상적인 구조가 복잡한 현실과 맞지 않음

BFF로 이미 해결된 overfetching

• 대부분의 엔터프라이즈 프런트엔드는 BFF(Backend for Frontend) 계층을 사용
  • UI에 맞게 데이터를 조합하고, 여러 다운스트림 호출을 통합하며, 백엔드 복잡성을 숨김
• REST 기반 BFF는 이미 필요한 데이터만 반환할 수 있어 GraphQL의 장점이 중복됨
• GraphQL 계층이 REST API로부터 데이터를 가져올 경우, overfetching이 단지 한 단계 아래로 이동
• 여러 페이지가 동일 엔드포인트를 공유할 때 GraphQL이 유용할 수 있으나,
  • 그 이점은 몇 킬로바이트 절약을 위해 더 많은 설정과 유지보수 부담을 감수하는 수준

구현 복잡도와 생산성 저하

• GraphQL은 REST보다 구현 시간이 훨씬 길고 복잡함
  • 스키마, 타입, 리졸버, 데이터 소스 정의 등 추가 작업 필요
  • 스키마와 클라이언트 동기화 유지 부담 존재
• GraphQL은 소비(클라이언트 편의) 를 최적화하지만, 생산(서버 개발 속도) 을 희생
• 엔터프라이즈 환경에서는 생산 속도와 단순성이 더 중요함

관찰성과 모니터링 문제

• GraphQL의 HTTP 상태 코드 체계가 비일관적
  • 200 응답에도 오류가 포함될 수 있어, 모니터링 시 성공/실패 구분이 어려움
• REST는 2XX/4XX/5XX로 명확히 구분되어 대시보드 필터링이 직관적
• Apollo 등에서 커스터마이징 가능하지만, 이는 추가 설정과 정신적 부담을 초래
• 운영 중 장애 대응 시 REST보다 문제 파악이 어렵고 복잡함

캐싱의 현실적 한계

• Apollo의 정규화 캐싱(normalized caching) 은 이론적으로 강력하지만 실제로는 취약하고 복잡
  • 필드 하나만 다른 쿼리도 별도로 취급되어 수동 연결 필요
  • 캐시 디버깅이 별도의 문제로 발전
• 반면 REST는 단순히 전체 응답을 캐싱해 안정적이고 유지보수 용이

ID 필드 제약의 문제

• Apollo는 모든 객체에 id 또는 _id 필드가 필요하다고 가정
  • 많은 엔터프라이즈 API는 고유 ID가 없거나, 전역 식별자가 아님
• 이를 맞추기 위해 BFF가 로컬 ID 생성 로직을 추가해야 함
  • 결과적으로 불필요한 필드와 로직 증가, overfetching 감소 효과 상쇄

파일 업로드 및 다운로드의 비효율

• GraphQL은 이진 데이터 처리에 부적합
  • 실제로는 다운로드 URL을 반환하고, 파일은 REST로 전송
  • PDF 등 대용량 데이터를 GraphQL 응답에 포함하면 성능 저하
• 이로 인해 “단일 API”라는 GraphQL의 이상이 깨짐

온보딩과 학습 곡선

• 대부분의 개발자는 REST 경험이 풍부하지만 GraphQL은 학습 필요
  • 스키마, 리졸버, 쿼리 구성, 캐싱 규칙, 오류 처리 등 새 개념 학습 필요
• 이로 인해 팀 온보딩 속도 저하
• REST는 “지루하지만 확장성 높은” 접근으로 대규모 팀에 적합

오류 처리의 복잡성

• GraphQL 오류 응답은 nullable 필드, partial data, errors 배열, 확장 상태 코드 등으로 복잡
  • 어떤 리졸버가 실패했는지 추적 필요
• REST는 단순히 400/500으로 구분되어 이해와 디버깅이 용이

결론: GraphQL은 틈새 기술

• GraphQL은 특정 상황에서는 유효한 도구
  • 그러나 대부분의 엔터프라이즈 환경에서는 이미 BFF와 REST로 문제 해결
  • 주요 과제는 overfetching이 아니라 관찰성, 신뢰성, 속도
• 결과적으로 GraphQL은 좁은 문제를 해결하면서 더 넓은 복잡성을 초래
• “GraphQL은 나쁘지 않지만, 대부분의 경우 필요하지 않다”는 결론