발명은 필요에서부터 시작된다. 

 

페이스북이 그래프QL을 만들기로 한 이유는 모바일 애플리케이션 개발 시 발생하는 여러 기술적 문제를 해결하기 위해서였다. 하지만 현재 그래프QL이 인기를 얻고 있는 이유는 기술적 문제보다는 커뮤니케이션 문제를 해결하기 때문이다.

 

커뮤니케이션은 아주 어려운 기술이다. 

 

커뮤니케이션 능력을 키우면 다양한 방면에서 삶이 더 윤택해진다. 마찬가지로 소프트웨어의 각기 다른 부품 간에 발생하는 커뮤니케이션의 품질을 향상시키면 해당 소프트웨어를 이해하기 쉬워질 뿐만 아니라 개발, 유지관리, 확장도 쉬워진다.

 

그래프QL이 판도를 바꿀 수 있다고 생각하는 것도 이 때문이다. 

 

서로 다른 소프트웨어(프런트엔드와 백엔드)가 커뮤니케이션하는 방법을 바꿔버리는 게임체인저인 것이다. 

 

그래프QL은 프런트엔드와 백엔드에 동등한 힘을 실어주면서, 서로 독립할 수 있게 해준다. 

 

또한, 둘 사이의 커뮤니케이션 프로세스를 기술적 전송 채널에서 분리해주며, 말로는 한정된 단어밖에 사용할 수 없는 일반 커뮤니케이션 언어를 대체하도록 표현력이 풍부한 언어를 제공한다.

 

지금 그래프QL은?

그래프QL은 페이스북의 다양한 애플리케이션에서 그 진가를 발휘하고 있다. 페이스북의 메인 웹 애플리케이션뿐만 아니라 페이스북 모바일 애플리케이션, 인스타그램 등도 포함된다. 

 

많은 개발자들이 그래프QL에 관심을 가지고 있으며, 실제로 사용하는 개발자도 빠르게 늘고 있다. 

 

 

 

페이스북 외에도 깃허브, 에어비앤비, 옐프, 핀터레스트, 트위터, 뉴욕 타임즈, 코세라, 쇼피파이 등 유명 웹/모바일 애플리케이션도 그래프QL을 사용한다. 최근에 나온 기술이지만 벌써 이렇게 많은 서비스가 그래프QL을 사용하고 있다는 사실이 놀랍다.

 

그래프QL이란?

그래프QL의 '그래프(Graph)'는 현실 세계의 데이터를 표현하는 가장 적합한 방법이 그래프라는 사실에서 착안했다. 

 

크든 작든 데이터 모델을 분석하게 되면 객체 간의 관계를 그래프로 표현한 것을 보게 된다. 그래프QL을 처음 접하고 감탄하는 부분이 이 지점이다. 그래프로 생각하면 더 쉬운 것을 왜 굳이 (URL에 포함된) 리소스나 테이블로 생각하는 것일까? 

 

그렇다고 그래프QL을 ‘그래프 데이터베이스’에서만 사용할 수 있는 것은 아니다. 문서형 데이터베이스(몽고DB)나 관계형 데이터베이스(PostgreSQL)는 물론이고 API 데이터를 그래프 형태로 표현할 때도 사용할 수 있다.

 

그래프QL의 'QL'은 쿼리 언어(Query Language)를 의미해 오해를 불러일으킬 수도 있다. API를 사용하는 프런트엔드 입장에서만 보면 그래프QL은 데이터 API용 쿼리 언어가 맞지만, 한편으로는 백엔드에서 구현돼야 하는 런타임 계층의 역할도 한다. 프런트엔드는 이 런타임 계층이 제공하는 새로운 언어를 사용해서 데이터를 받는다.

 

그래프QL 언어는 선언적이며 유연하고 효율적으로 설계됐다. 데이터 API를 사용하는 클라이언트(모바일이나 웹 애플리케이션) 개발자는 서버에 저장된 데이터 구조나 데이터 관계를 이해할 필요가 없다. 머리 속에 떠오른 그대로 유사한 언어를 사용해서 원하는 데이터를 요청하면 된다.

 

백엔드에는 그래프QL 기반의 런타임이 필요하다. 이 런타임은 API를 통해 제공될 데이터의 구조를 관리한다. 이 구조를 그래프QL에서는 스키마(schema)라고 부른다. API 사용자는 그래프QL 언어를 사용해서 필요한 데이터를 정확하게 요구하기 위한 텍스트를 구성하고 클라이언트는 이 텍스트 요청을 전송 채널(예: HTTPS)을 통해 API 서비스에 전달한다. 

 

그러면 그래프QL의 런타임 계층이 이 텍스트 요청을 받아서 백엔드에 있는 다른 서비스들과 커뮤니케이션 하고 그 결과들을 모아서 적합한 데이터를 만든다. 그렇게 만들어진 데이터를 JSON 같은 형식으로 API 사용자에게 반환하는 것이다. 

 

 

 

[그래프QL은 언어이자 런타임이다.]

 

데이터 API

일반적으로 API란 애플리케이션 상에 있는 다수의 컴포넌트 간의 커뮤니케이션을 원활하게 만드는 인터페이스를 의미한다. 

 

예를 들어, 어떤 API는 웹 클라이언트와 데이터베이스 서버 간 커뮤니케이션을 가능하게 해준다. 클라이언트는 필요한 데이터를 서버에 요청하고 서버는 클라이언트가 요구한 데이터를 객체로 반환한다.

 

 

 

[데이터 API 구성]

 

API에는 여러 종류가 있으며 규모가 큰 애플리케이션은 모두 API를 가지고 있다. 그래프QL에서 말하는 API는 데이터를 읽고 수정하기 위한 API로 이것을 데이터 API라고 한다.

 

그래프QL은 프로그래밍 가능한 많은 인터페이스 중 하나로 애플리케이션이 필요로 하는 데이터를 읽고 수정할 수 있게 해준다. 그래프QL 외에도 REST, SOAP, XML 등의 인터페이스가 있으며 SQL도 여기에 포함된다.

 

SQL은 QL이라는 이름 때문에 그래프QL과 직접 비교 대상이 되기도 한다. SQL과 그래프QL 모두 데이터 스키마를 요청할 수 있는 언어이며, 양쪽 모두 데이터를 읽고 수정할 수 있다. 

 

간단히 말하자면 그래프QL은 클라이언트와 서버 간 데이터 교환을 최적화하기 위한 툴이다. 

 

구체적으로 살펴보면 클라이언트는 필요한 데이터를 서버에 요청하기 위한 커뮤니케이션을 수행하고, 서버는 이 요청에 응답하기 위한 데이터를 준비해서 클라이언트에게 반환한다. 

 

그래프QL은 클라이언트가 필요한 데이터를 정확하게 요청할 수 있게 도와주며, 서버가 다수의 데이터 저장소로부터 필요한 데이터를 쉽게 추출할 수 있게 해준다.

 

그래프QL의 핵심은 데이터를 정의하고 API를 관리할 때 사용하는 강력한 타입(type) 시스템이다. 이 타입 시스템은 여러 면에서 서버와 클라이언트 양쪽에 유용하게 활용된다. 

 

클라이언트는 요청할 수 있는 데이터 타입을 명확하게 제시하고 잘못된 경우에는 자세하고 유용한 오류 메시지를 제공한다. 또한, 클라이언트는 타입을 사용해서 데이터 요소를 전달하기 위한 수작업을 최소화한다. 

 

그래프QL의 타입 시스템은 내향성(introspective) API 같은 고급 기능이나 클라이언트와 서버용 툴을 구축할 수 있게 해준다. 대표적인 툴 중 하나가 바로 그래피컬(GraphiQL)로 그래프QL 요청을 확인하거나 테스트하는 브라우저 기반의 편집기이다. 

 

 

 

그래프QL은 언어다

그래프QL의 이름에는 질의(query)를 뜻하는 Query의 Q가 있지만 질의란 읽는 행위에만 국한된 단어다. 

 

그래프QL은 데이터 읽기뿐만 아니라 수정도 할 수 있다. 그래프QL을 사용해서 데이터를 읽을 때는 쿼리를 사용하고 수정할 때는 변경(mutation, 뮤테이션)을 사용한다. 쿼리와 변경은 모두 그래프QL 언어의 일부이다.

 

그래프QL은 SQL과 비슷하다. SQL에서 데이터를 읽을 때는 SELECT문을 사용하고 수정할 때는 INSERT, UPDATE, DELETE문을 사용한다. 

 

SQL에는 정해진 규칙이 있다. SELECT문을 사용할 때는 FROM을 지정해야 하며 옵션으로 WHERE를 지정할 수도 있다. 

 

마찬가지로 그래프QL 언어에도 지켜야 할 규칙이 있다. 예를 들면 그래프QL 쿼리는 반드시 이름을 지정해야 하며, 이름이 없으면 요청을 보낼 때 해당 쿼리가 유일한 쿼리여야 한다. 

 

그래프QL(또는 SQL) 같은 쿼리 언어는 자바스크립트나 파이썬 같은 프로그래밍 언어와는 다르다. 그래프QL 언어를 사용해서 UI를 만들거나 복잡한 계산을 할 수는 없다. 

 

쿼리 언어는 정해진 사용 용도가 있으며, 이를 위해 종종 프로그래밍 언어를 함께 사용해야 하는 경우도 있다. 

 

쿼리 언어를 프로그래밍 언어나 한국어 같은 일반 언어와 비교해 보면, (좁은 범위의 비교이긴 하지만) 그래프QL의 장점이 무엇인지 이해할 수 있다.

 

일반적으로 프로그래밍 언어는 진화를 거듭할수록 사람의 언어에 가까워진다. 과거에는 컴퓨터가 명령한 것만 이해할 수 있었으므로 명령형 패러다임(imperative paradigm)을 사용해서 프로그램을 만들었다. 

 

하지만 현재 컴퓨터는 선언적 패러다임(declarative paradigm)을 이해하기 시작했으며, 우리가 원하는 것을 이해하는 프로그램을 만들 수 있게 됐다. 

 

선언적 프로그래밍은 여러 장단점을 가지고 있지만, 무엇보다 의미가 있는 것은 사람이 어떤 문제의 원인을 생각할 때 선언적으로 접근한다는 것이다. 사람은 선언적으로 사고하는 데에 익숙하다.

 

그래프QL은 서비스다

클라이언트 애플리케이션에게 그래프QL 언어를 가르칠 수 있다면, 그래프QL 언어를 이해하는 백엔드 서비스와 데이터 요건에 관한 대화를 나눌 수 있을 것이다. 

 

데이터 서비스가 그래프QL 언어를 이해하게 하려면 런타임 계층을 만들어서 클라이언트를 향해 노출하면 된다. 서버에 있는 이 계층을 그래프QL 언어의 통역기 또는 그래프QL 언어를 이해하는 데이터 서비스의 중개인이라고 생각하면 이해하기 쉽다. 

 

그래프QL은 저장 엔진이 아니므로 그 자체를 DB같은 서버로 사용할 수 없다. 따라서 런타임 계층으로 별도의 층을 만들어서 언어를 변환하는 것이다.

 

그래프QL 서비스는 원하는 프로그래밍 언어를 사용해서 구현할 수 있다. 

 

그래프QL을 다른 라이브러리와 함께 사용하기

그래프QL은 백엔드나 프런트엔드 프레임워크, 기술 스택, 데이터베이스 등 어떤 것에도 종속되지 않는다. 즉, 아무 프런트엔드, 백엔드 환경에서든 어떤 데이터베이스를 사용해도 된다는 의미이다. 전송 채널이나 데이터 형식에도 제한이 없다.

 

프런트엔드 웹 또는 모바일 애플리케이션에선 Ajax 호출을 직접 그래프QL 서버에 던지거나 아폴로(Apollo)나 릴레이(Relay) 등의 클라이언트를 사용할 수도 있다. 

 

또한, 리액트(React) 또는 리액트 네이티브(React Native) 등의 라이브러리를 사용해서 뷰(view)에서 그래프QL 서비스가 반환한 데이터를 사용하는 방법을 관리할 수 있다. 

 

물론 UI 환경(DOM API나 네이티브 iOS 컴퍼넌트)의 네이티브 API에서 사용할 수도 있다.

 

그래프QL을 사용하기 위해 리액트나 아폴로, 릴레이가 필요한 것은 아니지만, 이런 라이브러리들을 함께 사용하면 복잡한 데이터 관리 작업을 알아서 해주므로 그래프QL의 활용도를 높여준다.

 

 

---

 

이 글은 <그래프QL 인 액션> 도서 내용 일부를 편집하여 작성되었습니다. 그래프QL 활용에 대한 보다 자세한 내용은 하기 도서에서 확인할 수 있습니다. 

 

 

『그래프QL 인 액션』