개발자

“강력하지만 오용하기 쉽다” 그래프QL의 장단점 5가지

Peter Wayner | InfoWorld 2023.01.12
그래프QL(GraphQL)을 좋아하는 개발자도 있고, 싫어하는 개발자도 있을 것이다. 이 REST API 대체제의 좋은 점, 나쁜 점, 이상한 점을 살펴본다. 

페이스북(현 메타플랫폼)은 거대한 소셜 그래프에서 데이터 구조를 검색할 간결하고 강력한 방법이 필요했고, 2012년 ‘그래프QL(GraphQL)’을 처음 만들었다. 이 회사는 2015년부터 그래프QL을 공개적으로 공유하기 시작했고, 2019년에는 비영리 단체 ‘그래프QL 재단(GraphQL Foundation)’에 소유권을 기부했다. 

그리하여 오늘날 많은 기업이 그래프QL을 사용해 데이터 검색 서비스를 구축하고 있다. 이 쿼리 언어는 계속 발전하고 있으며, 그래프QL 재단은 개선 사항을 꾸준하게 발표하고 있다.
 
ⓒ Getty Images Bank
 

좋아하는 이유 1. 그래프QL은 간결하다

데이터를 검색해야 하는 개발자는 그래프QL가 간결하다는 점에서 이를 좋아하는데, 특히 사용자 인터페이스를 개선하기 위해 새 기능과 데이터를 계속 추가하는 프론트엔드 개발자가 그러하다. 구문(syntax)은 복잡하고 [때로는] 중첩된 데이터 구조에서 응답을 요청하는 가장 간단한 방법이다. 이렇게 하면 코드를 다시 작성하지 않고도 더 많은 데이터를 쉽게 요청할 수 있다.

또 그래프QL의 쿼리 메커니즘은 기존 쿼리의 복잡성을 많이 완화하도록 설계됐다. 데이터베이스 쿼리에서 내부 및 외부 조인으로 어려움을 겪는 개발자가 있을 것이다. 전 세계 서너 개의 서로 다른 데이터베이스에서 데이터를 찾기 위해 3~4개의 요청을 보내는 데 지친 개발자도 있을 것이다. 그래프QL은 이러한 모든 복잡성을 눈에 띄지 않게 처리하기 때문에 이를 고려할 필요가 없다. 
 

싫어하는 이유 1. 쿼리를 위험할 정도로 쉽게 만든다

개발자는 백엔드가 모든 복잡성을 처리한다는 점에서 그래프QL 요청에 더 많은 필드를 쉽게 추가할 수 있어 [그래프QL을] 좋아한다. 그리고서 결과가 5배, 10배 또는 100배씩 느려지면 놀란다. 이러한 모든 새 쿼리는 프로세스에 조인을 추가하고, 겉보기에 멀리 갔다가 돌아오는 것처럼 백엔드를 빠르게 보낸다. 데이터베이스 관리자는 서버 부하가 급증해 화를 내겠지만 개발자가 이를 어떻게 알겠는가? 그래프QL이 모두 숨겼으니 알 턱이 없다.

여기서 클라우드가 워크로드에 따라 [비용이] 청구되기 때문에 상황이 더 악화된다. 조금 더 많은 것을 요구하는 쿼리는 월말에 고액의 클라우드 청구서로 바뀔 수 있다. 쿠버네티스 클러스터가 요청을 처리하기 위해 자동으로(그리고 조용히) 더 많은 인스턴스를 가동하기 때문에 얼마나 지불해야 하는지 거의 알지 못한다.
 

좋아하는 이유 2. 계속 발전하는 그래프QL

그래프QL은 여전히 꽤 새롭고 지속적으로 연구되고 있다. 이는 새로운 기능이 자주 추가되고 있다는 의미다. 지난 2021년 10월 그래프QL 릴리스 로그에는 100개 이상의 변경 사항과 개선 사항이 포함됐다. 그래프QL을 개선하기 위한 작업은 계속 진행 중이다.
 

싫어하는 이유 2. 혼란스러운 API 버전 관리

많은 팀이 그래프QL API를 지속적으로 개선할 수 있지만 모든 팀이 이를 제대로 관리하지는 못한다. 사라진 필드에 ‘null’ 응답을 몰래 입력하라고 말하는 사람도 있을 정도다. 명시적인 버전 태그를 경로(예: ‘/v3/data’)로 밀어 넣고 다른 브랜치에 다른 버전의 단일 트리를 만들기도 한다. API를 실행하는 개발자는 여전히 어딘가에서 누군가가 정보를 요청한다는 이유만으로 필드 요청을 지원하고 정보를 추가하지만 결코 빼지는 않는 자신을 발견할 수 있다.
 

좋아하는 이유 3. 그래프QL의 힘은 내부에 있다

많은 개발자, 특히 API에서 데이터를 가져오려는 개발자는 그래프QL의 쿼리 성능에 감탄한다. 몇 번의 키 입력만으로도 쿼리를 변경하고 API에 완전히 다른 것을 제공하도록 명령할 수 있다.

하지만 그래프QL의 진정한 힘은 내부에 있다. 스마트 백엔드는 그래프QL을 사용하여 정보를 수집하는 가장 좋은 방법에 대해 적절한 결정을 내릴 수 있다. 최적화 루틴은 요청에 관한 정적 분석을 실행하고, 백엔드가 가장 빠른 경로를 선택하는 데 활용 가능한 비교적 정확한 예측을 할 수 있다. 또 그래프QL은 고정 쿼리를 조합하고 캐시된 개체의 목록을 유지하여 속도를 높일 수 있다.
 

싫어하는 이유 3. 너무 뛰어난 성능은 위험할 수 있다

많은 사람은 강력한 성능을 좋아한다. 그래프QL는 너무 많은 대역폭, 컴퓨팅 리소스 또는 2가지 모두를 과도하게 실행하는 쿼리처럼 보인다. 비공개로 유지해야 하는 정보를 공개하는 등의 위험도 있다. 또는 변경되면 안 되는 데이터가 업데이트되도록 만들어버릴 수도 있다.
 

좋아하는 이유 4. 사람들을 위한 데이터

데이터는 사용될 때 가치가 있으며, 이는 필요한 사람에게 데이터를 제공하는 것을 의미한다. 프론트엔드 개발자가 일반 사용자를 위한 멋진 인터페이스를 만드는 데 초점을 맞추는 이유다. 그래프QL이 개발자의 작업을 더 쉽게 만들어줄 때, 이는 차례로 다른 모든 사람의 삶을 더 쉽게 만들 수 있다. 또한 개방적이고 쉽게 접근할 수 있는 데이터 검색 메커니즘을 구축하면 전사적인 데이터 사용을 활성화할 수도 있다.
 

싫어하는 이유 4. 스키마 없음

개발자가 [그래프QL에] 공통적으로 제기하는 불만 중 하나는 데이터 트리를 안내하는 명확한 맵이나 스키마가 없다는 점이다. 올바른 문자열이 있을 수 있지만 어느 브랜치에 있는지 알 수 없다. 적어도 관계형 데이터베이스는 잘 정의되고 상당히 일관된 열이 있는 멋진 직사각형 테이블에 모든 것을 정렬한다. 이는 언어 자체보다 복잡한 그래프 데이터 구조의 문제일 수 있지만 이 부분에서만큼은 개발자의 삶을 더 편하게 만들어주진 않는다. 
 

좋아하는 이유 5. 백엔드 연결을 위한 슈퍼그래프

그래프QL 애호가는 기업의 모든 데이터를 하나의 거대한 슈퍼그래프에 결합할 수 있다는 점을 자주 언급한다. 몇 가지 구형 시스템을 활용하고 몇 가지 새로운 필드를 혼합하여 모든 일반적인 지혜와 단일 진실 소스에 관한 포괄적인 문서를 만들 것이다. 즉, 모든 데이터 웨어하우징 팀은 모든 소중한 데이터를 보관할 대규모 포털을 만들 수 있다.
 

싫어하는 이유 5. 슈퍼 그래프는 보기에만 쉽다

모든 데이터를 하나의 거대한 인터페이스로 결합하는, 슈퍼그래프를 만드는 일은 말처럼 간단하지 않다. 물리학자들이 수십 년 동안 대통합 이론(Grand Unified Theory; GUT)을 연구해 온 것처럼, 데이터 팀 역시 이러한 통합의 세부 사항을 정하는 데 많은 시간을 들여야 한다. 예를 들면 개발자는 서로 다른 브랜치의 형식 시스템이 맞지 않는다고 불평할 수 있다. 한 브랜치는 날짜를 텍스트 형식으로 저장하고, 다른 브랜치는 숫자 표준을 사용할 수 있다. 슈퍼그래프가 다른 국가에 저장된 데이터를 통합한다면 서로 다른 언어로 브랜치를 관리해야 할 가능성도 높다. 다양한 데이터 소스를 단일 인터페이스처럼 보이도록 결합하는 건 쉽지만 실제로 데이터를 통합하는 일은 훨씬 더 복잡하다.
 

결론

그래프QL은 간결하고 강력하지만 그 힘을 오용하기가 너무 쉽다는 게 결론이다. 따라서 그래프QL을 고려하는 개발자와 팀이 있다면 시간을 들여 그래프QL를 자세하게 검토할 필요가 있다. 그래프QL을 마냥 쉽고 단순한 솔루션이라고 간주한다면 클라우드 청구서와 보안 문제를 직면할 수 있다.
ciokr@idg.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.