"6년 썼는데 이제 손절합니다" 현직 개발자가 GraphQL 추천 안 하는 이유

요약 2018년부터 실무 프로덕션에서 GraphQL을 적극적으로 도입하고 찬양해 왔던 한 개발자가 6년간의 운영 끝에 "이제는 대부분의 사람들에게 GraphQL을 추천하지 않는다"고 선언하며 그 이유를 상세히 털어놓았습니다. 작성자는 처음에 비타입 JSON REST API 기반으로 리액트 SPA를 개발할 당시, GraphQL이 가져다준 유연함과 편리함에 크게 매료되어 열렬한 지지자(하입 트레인 탑승자)가 되었다고 회고했습니다. 하지만 보안, 성능, 유지보수성 같은 비기능적 요구사항이 중요한 환경에 시스템을 배포하고 운영하면서 관점이 완전히 바뀌게 되었습니다. 가장 큰 문제로 꼽힌 것은 넓어진 공격 표면(Attack Surface)과 보안 관리의 난이도였습니다. 첫째로 '인가(Authorisation)' 문제입니다. REST API는 특정 엔드포인트 단위로 접근 권한을 검사하면 되지만, GraphQL은 클라이언트가 쿼리를 조합하기 때문에 모든 객체와 필드 단위로 현재 사용자의 권한과 맥락(예: 특정 사용자의 차단 여부, 공개 프로필과 개인정보 구분 등)을 일일이 확인해야 합니다. 이로 인해 인가 로직의 복잡도가 극도로 치솟습니다. 둘째는 '속도 제한(Rate Limiting)'과 서비스 거부 공격 방어의 어려움입니다. REST는 분당 요청 수 기반으로 비교적 간단하게 제한할 수 있지만, GraphQL은 빈 스키마에서도 순환 참조를 이용해 불과 128바이트짜리 쿼리로 서버의 CPU를 수십 초간 점유하거나 메모리를 고갈시키는 것이 가능합니다. 이를 방지하기 위해 필드별 복잡도를 계산해 차단하는 방식을 쓰더라도, 목록의 길이를 사전에 알기 어렵거나 그래프 내부 순환 참조가 겹치면 복잡도가 기하급수적으로 폭증해 정상 요청이 차단되거나 악성 요청이 통과되는 딜레마에 빠지게 됩니다. 마지막으로 쿼리 실행 전 파싱 단계에서도 수많은 지시자(directive)를 중첩하는 등 비정상적인 쿼리 문자열을 보내 서버 메모리 부족(OOM)을 유발하는 취약점이 발생하는 등, 클라이언트에 자율성을 주는 대가로 백엔드가 짊어져야 할 부담이 지나치게 커졌다고 지적했습니다.