메타의 웹 API 시스템인 그래프QL(GraphQL)은 다른 종류의 API다. 그래프QL에서 개발자는 요청과 응답 모두를 엄격한 유형의 쿼리 언어로 정의함으로써 애플리케이션이 API로부터 정확히 어떤 데이터를 얻고자 하는지 지정할 수 있다. 그래프QL은 보다 효율적이고 구조적이며, 체계적인 REST 대안으로 평가받는다.
여기서는 그래프QL과 REST의 차이점, 이 차이점이 API 설계에 미치는 영향, 그리고 서버에서 데이터를 불러오는 용도로 많은 경우 그래프QL이 REST보다 더 나은 선택인 이유를 알아본다.
그래프QL vs. REST
REST에서는 일반적으로 특별히 만들어진 URL을 통해 요청을 제출하며 각 요청은 서로 다른 엔드포인트로 전송된다(예를 들어 /movie/2120, /director/5130). 그래프QL에서는 JSON과 비슷한 쿼리로 찾는 데이터에 대한 선언적 요청을 제출하며, 모든 요청이 동일한 엔드포인트로 전송된다. 돌려받는 데이터는 요청에 사용되는 스키마에 따라 결정된다. 필요한 특정 데이터만 요청하기 위한 표준화된 자체 설명적 방법이다. 다양한 요청 유형에 대해 서로 다른 엔드포인트 URL 형식이 아니라 서로 다른 스키마를 사용하는 방식으로, 쿼리 메커니즘이 훨씬 더 유연해진다.
많은 REST API 역시 공통 사양인 스웨거(Swagger)를 준수하지만, REST API가 스웨거에 의해 생성돼야 한다는 규칙은 없다. 그래프QL은 기본적으로 API에 대한 공식 정의를 제공한다. 이런 측면에서 그래프QL은 SQL과 비슷한 면이 있다. SQL 기반 데이터 소스에서는 모든 데이터 요청에 대해 하나의 공통 엔드포인트에 연결하며, 요청의 형식에 따라 돌려받는 레코드가 결정된다. 또한 SQL에는 많은 구현이 있지만 SQL 쿼리 구문은 이런 구현 전반에서 상당히 일관적이다.
그래프QL 쿼리
앞서 언급했듯이 그래프QL은 불러올 데이터가 쿼리와 응답에서 어떻게 구성되는지를 스키마 또는 데이터 정의를 사용해서 설명한다. 객체 관계 매퍼(object-relational mapper, ORM)을 다뤄본 사람이라면 누구나 그래프QL의 데이터 스키마 정의가 익숙하게 느껴질 것이다. 다음 예제를 보자. type Movie {
id: ID
title: String
released: Date
director: Director
}
type Director {
id: ID
name: String
movies: [Movie]
}
스키마의 각 요소에는 유형 정의가 있다. 그래프QL에는 쿼리를 위한 자체 유형 시스템이 있으며, 이 시스템은 수신되는 스키마의 유효성을 검사하고 정의와 일치하는 형식으로 데이터를 반환하는 데 사용된다.
그래프QL에 제출되는 쿼리는 스키마에 의해 비슷하게 정의된다.
type Query {
movie_title(title: String!): Movie
director(id: ID): Director
}
이 쿼리는 최대 2개의 매개변수 movie_title, director를 받는다(각각 title과 ID를 통해 받음).
유형 옆의 !는 쿼리의 필수 요소임을 나타낸다. 즉, title로 영화를 쿼리해야 하며 director는 선택 사항(쿼리 범위를 좁히는 용도)이다.
필수 요소는 데이터 스키마에서도 사용될 수 있다. 다음과 같이 ID만으로 영화를 검색하는 쿼리도 가능하다.
query GetMovieByID ($id: ID!) {
movie(id: $id) {
name
}
}
이 쿼리는 따로 정의된 변수($id)를 사용해서 ID 번호로 영화를 조회해서 이름을 반환한다. 그래프QL 쿼리는 개별 필드뿐만 아니라, 필드 안에 항목이 배열을 중첩하는 방식으로 관련 객체와 해당 필드도 반환할 수 있다.
쿼리를 위한 변수는 다음과 같은 형식을 사용해 쿼리의 별도 섹션에서 전달된다.
{
"id": 23
}
그래프QL 유형
그래프QL의 쿼리 유형 시스템은 문자열, 정수와 같은 많은 일반적인 스칼라 유형을 지정한다. 대부분의 쿼리는 이런 유형을 중심으로 구성된다. 그러나 유형 시스템에는 더 정교한 쿼리를 위한 다음과 같은 여러 가지 고급 유형도 포함된다. - interface 유형은 다른 유형에서 구현 및 재사용할 수 있는 사전 정의된 필드 집합이 있는 추상 유형을 만드는 데 사용할 수 있다.
- union 유형은 한 종류의 쿼리에서 여러 유형에 걸쳐 다양한 종류의 결과를 반환할 수 있게 해준다.
- input 유형은 위와 같은 종류의 객체 전체를 매개변수로 전달하는 데 사용할 수 있다(이러한 객체가 유효성 검사가 가능한 일반적인 스칼라 유형에서 생성된 경우).
인터페이스 또는 유니언 객체를 다루는 경우 인라인 조각 및 지시문을 사용해서 해당 객체 유형이 지정할 수 있는 조건을 기반으로 데이터를 반환해야 한다.
쿼리에서 반환 가능한 또 다른 유형은 선택적인 edges 필드에 반환되는 edge 유형이다. 에지에는 nodes(데이터 레코드), 그리고 해당 객체에서의 앞뒤 페이지 매김 방법에 대한 컨텍스트 정보를 제공하는 인코딩된 문자열인 cursors가 포함된다.
{
movie {
name
actors (first:5) {
edges {
cursor
node {
name
}
}
}
}
}
이 예제에서 movie 노드는 영화와 배우의 이름을 반환한다. 영화의 각 배우에 대해 배우 이름이 포함된 노드와 배우의 "이웃"을 탐색할 수 있게 해주는 커서를 받게 된다.
그래프QL을 사용한 페이지 매김
데이터 소스를 다룰 때 일반적인 시나리오는 커서를 통해 페이지 단위로 데이터를 요청하는 것이다. 그래프QL은 여러 가지 페이지 매김 방법을 제공한다. 레코드를 요청할 때 요청할 레코드의 수와 시작 오프셋뿐 아니라 연속된 페이지를 요청하는 방법도 지정할 수 있다. 위 섹션의 예제 코드는 괄호 안의 first:5 매개변수에 지정된 대로 특정 영화와 관련된 처음 5명의 배우만 반환한다.
actors 뒤의 first: 절 뒤에 이어지는 항목을 불러올 방법을 설명하는 다른 키워드를 붙일 수 있다. offset:은 간단한 오프셋에 사용할 수 있지만 오프셋은 데이터가 추가 또는 삭제될 때 폐기될 수 있다.
가장 견고한 페이지 매김을 위해서는 위에서 설명한 edge 유형을 사용해서 현재 요청 중인 객체와 함께 제공할 수 있는 커서를 사용하는 것이 좋다. 이렇게 하면 페이지 매김 사이에 데이터가 삽입 또는 삭제될 때(예를 들어 객체의 고유 ID 또는 고유한 다른 속성을 다른 계산의 시작 키 인덱스로 사용하는 경우) 끊기지 않는 페이지 매김 메커니즘을 만들 수 있다.
그래프QL 뮤테이션을 사용한 데이터 변경
REST API에서는 POST, PATCH 및 기타 HTTP 동사를 사용하는 요청을 제출해서 서버 측 데이터를 변경한다. 그래프QL에서는 변경을 위한 특정 쿼리 스키마인 뮤테이션 쿼리를 사용한다. 이 부분도 SQL이 UPDATE 또는 DELETE 쿼리를 사용하는 것과 거의 같은 방식이다. 데이터를 변경하려면 뮤테이션 스키마라는 스키마를 사용해서 그래프QL 쿼리를 제출한다.
mutation CreateMovie ($title: String!, $released: Date!) {
createMovie (title: $title, released: $released){
id
title
released
}
}
[submitted data]
{
"title": "Seven Samurai"
"released": "1950"
}
뮤테이션 쿼리를 포함한 모든 쿼리는 데이터를 반환할 수 있다. 여기서 createMovie 뒤의 중괄호 안에 있는 필드 목록은 이 요청으로 새 레코드가 생성된 후 서버에서 무엇을 반환해야 하는지를 지정한다. 여기서 id 필드의 값은 데이터베이스에 의해 생성되고 다른 필드의 값은 쿼리에서 제출된다.
또 한가지 유의해야 할 점은 데이터를 반환하는 데 사용되는 쿼리와 데이터 유형은 데이터를 요청하는 데 사용된 것과 설계상 다르다는 것이다. 뮤테이션 쿼리는 수신되는 데이터를 검증해야 하며 따라서 이러한 쿼리에 사용되는 유형은 이 기능을 위한 유형이다. 마찬가지로, 반환된 쿼리 객체에 사용되는 필드는 검증이 아닌 표시용이다. 쿼리에서 반환되는 그래프QL 객체에는 순환 참조 또는 기타 문제가 있는 필드가 포함될 수 있고 이 경우 쿼리 매개변수로 사용할 수 없게 된다.
왜 그래프QL인가?
REST가 아닌 그래프QL을 선택하는 주된 이유는 그래프QL 쿼리의 명시적, 선언적 특성에 있다. 쿼리와 반환되는 데이터의 형태에 대한 공식적인 정의가 있으면 여러 API와 구현에 걸친 일관성 외에도 다른 여러 이점을 얻을 수 있다. API 에반젤리스트 필 스터전이 그래프QL과 REST를 비교한 글에서 언급했듯이, 그래프QL의 필드 구조는 전체 API를 버저닝하는 방식과 달리 시간 경과에 따라 특정 필드를 폐기하거나 가져올 수 있으므로 쿼리에 더 세분화된 버저닝을 더 쉽게 적용할 수 있다. 그래프QL에서도 여전히 일괄적인 버저닝 접근 방식을 사용할 수 있다. 핵심은 변경 사항을 적용할 때 반드시 그렇게 할 필요는 없다는 것이다.
그래프QL API를 위한 오픈소스 툴 개발업체인 아폴로 그래프QL(Apollo GraphQL)의 엔지니어링 관리자 샤코 스투바일로는 그래프QL 접근 방식의 또 다른 장점인 자체 문서화를 강조한다. 스투바일로는 "가능한 모든 쿼리, 객체, 필드에는 서버에서 표준 방식으로 쿼리할 수 있는 이름, 설명, 유형 정보가 함께 제공된다"라고 말했다.
그래프QL의 자체 문서화는 일종의 성찰 기능도 제공한다. 즉, 쿼리를 사용하여 쿼리 자체에 대한 정보를 반환할 수 있다. 따라서 그래프QL 쿼리를 사용하는 소프트웨어는 특정 필드 집합을 다루기 위해 하드 와이어링을 할 필요 없이 자동으로 필드를 추론할 수 있다.
그래프QL이 더 나중에 나온 기술이고 REST/스웨거가 더 오래되었다는 것만으로 그래프QL을 선호하는 것은 바람직하지 않다. 일상적인 API 설계(The Design of Everyday API)의 저자 아르노 로레는 "그래프QL API도 REST API와 마찬가지로 명확한 목적에 따라 만들어져야 하며, 내부적 관점이 아닌 외부적 관점에서 설계되어야 한다"라고 말했다.
editor@itworld.co.kr
함께 보면 좋은 콘텐츠
Sponsored
Seagate
'반박 불가' 하드 드라이브와 SSD에 관한 3가지 진실
ⓒ Getty Images Bank 하드 드라이브가 멸종할 것이라는 논쟁이 10년 넘게 계속되고 있다. 빠른 속도와 뛰어난 성능이 필요한 애플리케이션에 적합한 플래시 스토리지의 연매출이 증가하고 있는 것은 자명한 사실이다. 하지만, 클라우드의 보편화 및 AI 사용 사례의 등장으로 인해 방대한 데이터 세트의 가치가 높아지는 시대에 하드 드라이브는 플래시 스토리지로 대체할 수 없는 가치를 가지고 있다. 전 세계 엑사바이트(EB) 규모 데이터의 대부분을 저장하는 하드 드라이브는 데이터센터에서 그 어느 때보다 필수적이다. 전 세계 데이터 세트의 대부분이 저장된 엔터프라이즈 및 대규모 클라우드 데이터센터는 데이터 성장에서 핵심이 될 것이다. 하드 드라이브와 SSD를 비교하자면, 하드 드라이브 스토리지는 2022년에서 2027년 사이 6,996EB 증가할 것으로 예상되는 반면, SSD는 1,363EB 증가할 것으로 보인다. ⓒ Seagate 생성형 AI 시대에는 콘텐츠를 경제적으로 저장해야 하기 때문에 플래시 기술과 밀접하게 결합된 컴퓨팅 클러스터는 더 큰 하드 드라이브 EB의 다운스트림 수요를 직간접적으로 촉진할 것이다. 하드 드라이브가 왜 데이터 스토리지 아키텍처의 중심이 될 수밖에 없는지는 시장 데이터를 근거로 설명 가능하다. 가격 책정 근거 없는 믿음 : SSD 가격이 곧 하드 드라이브 가격과 같아질 것이다. 사실 : SSD와 하드 드라이브 가격은 향후 10년간 어느 시점에도 수렴하지 않을 것이다. 데이터가 이를 명확하게 뒷받침한다. 하드 드라이브는 SSD에 비해 테라바이트당 비용 면에서 확고한 우위를 점하고 있으며, 이로 인해 하드 드라이브는 데이터센터 스토리지 인프라의 확고한 주춧돌 역할을 하고 있다. IDC 및 포워드 인사이트(Forward Insights)의 연구에 따르면, 하드 드라이브는 대부분의 기업 업무에 가장 비용 효율적인 옵션으로 유지될 것으로 전망된다. 엔터프라이즈 SSD와 엔터프라이즈 하드 드라이브의 TB당 가격 차이는 적어도 2027년까지 6대 1 이상의 프리미엄이 유지될 것으로 예상된다. ⓒ Seagate 이러한 TB당 가격 차이는 장치 구입 비용이 총소유비용(TCO)에서 가장 큰 비중을 차지하는 데이터센터에서 특히 두드러지게 드러난다. 장치 구입, 전력, 네트워킹, 컴퓨팅 비용을 포함한 모든 스토리지 시스템 비용을 고려하면 TB당 TCO는 하드 드라이브 기반 시스템이 훨씬 더 우수하게 나타난다. ⓒ Seagate 따라서, 플래시는 특정 고성능 작업의 수행에 탁월한 스토리지이지만, 하드 드라이브는 당분간 안정적이고 비용 효율적이며 널리 채택된 솔루션을 제공하는 데이터센터에서 계속해서 주류로 사용될 것이다. 공급과 확장의 관계 근거 없는 믿음 : NAND 공급이 모든 하드 드라이브 용량을 대체할 정도로 증가할 수 있다. 사실 : 하드 드라이브를 NAND로 완전히 교체하려면 감당할 수 없는 설비투자(CapEx)가 필요하다. NAND 산업이 모든 하드 드라이브 용량을 대체하기 위해 공급을 빠르게 늘릴 수 있다는 주장은 재정적, 물류적으로 엄청난 비용이 발생한다는 점을 간과한 낙관적인 생각이다. 산업 분석기관 욜 인텔리전스(Yole Intelligence)의 2023년 4분기 NAND 시장 모니터 리포트에 따르면, 전체 NAND 산업은 2015년~2023년 사이 3.1제타바이트(ZB)를 출하하면서 총 매출의 약 47%에 해당하는 2,080억 달러의 막대한 자본 지출을 투자해야 했다. 반면, 하드 드라이브 산업은 데이터센터 스토리지 수요의 거의 대부분을 매우 자본 효율적인 방식으로 해결하고 있다. 씨게이트가 2015년~2023년 사이 3.5ZB의 스토리지를 출하하며 투자한 자본은 총 43억 달러로, 전체 하드 드라이브 매출의 약 5%에 불과하다. 그러나 NAND 산업의 경우 ZB당 약 670억 달러에 해당하는 금액을 투자한 것으로 나타나 하드 드라이브가 데이터센터에 ZB를 공급하는 것이 훨씬 더 효율적임을 알 수 있다. ⓒ Seagate 작업 부하 근거 없는 믿음 : 올 플래시 어레이(AFA)만이 최신 엔터프라이즈 작업 부하의 성능 요구를 충족할 수 있다. 사실 : 엔터프라이즈 스토리지 아키텍처는 일반적으로 디스크 또는 하이브리드 어레이, 플래시, 테이프를 사용하여 특정 작업 부하의 비용, 용량, 성능 요구 사항에 최적화할 수 있도록 미디어 유형을 혼합한다. 기업이 플래시 없이는 최신 작업 부하의 성능 수요를 따라잡지 못할 위험이 있다는 주장은 다음과 같은 3가지 이유로 반박 가능하다. 첫째, 대부분의 최신 작업 부하에는 플래시가 제공하는 성능상의 이점이 필요하지 않다. 전 세계 데이터의 대부분은 클라우드와 대규모 데이터센터에 저장되어 있으며, 이러한 환경에서는 작업 부하 중 극히 일부에만 상당한 성능이 필요하다는 파레토 법칙을 따르고 있다. 둘째, 예산 제약이 있고 데이터 세트가 빠르게 증가하는 기업들은 성능뿐만 아니라 용량과 비용의 균형을 맞춰야 한다. 플래시 스토리지는 읽기 집약적인 시나리오에서는 탁월한 성능을 발휘하지만 쓰기 작업이 증가하면 내구성이 떨어져 오류 수정과 오버프로비저닝에 추가 비용이 발생한다. 또한, 대규모 데이터 세트나 장기 보존의 경우 영역 밀도가 증가하는 디스크 드라이브가 더 비용 효율적인 솔루션일 뿐만 아니라 수천 개의 하드 드라이브를 병렬로 활용하면 플래시를 보완하는 성능을 달성할 수 있다. 셋째, 수많은 하이브리드 스토리지 시스템은 다양한 미디어 유형의 강점을 단일 유닛에 원활하게 통합하고 최대한으로 활용할 수 있도록 세밀하게 조정된 소프트웨어 정의 아키텍처를 사용한다. 이러한 스토리지는 유연성을 제공하므로 기업은 지속적으로 변화하는 요구 사항에 따라 스토리지 구성을 조정할 수 있다. AFA와 SSD는 고성능의 읽기 집약적인 작업에 매우 적합하다. 하지만 하드 드라이브가 이미 훨씬 낮은 TCO로 제공하는 기능을 AFA로 불필요하게 비싼 방법으로 제공하는 것은 비용 효율적이지 않을 뿐만 아니라, AFA가 하드 드라이브를 대체할 수 있다고 주장하는 근거가 될 수 없다.
Seagate
“작지만 큰 영향력” 하드 드라이브의 나노 스케일 혁신
ⓒ Seagate 플래터당 3TB라는 전례 없는 드라이브 집적도를 자랑하는 새로운 하드 드라이브 플랫폼이 등장하며 디지털 시대의 새로운 이정표를 세웠다. 플래터당 3TB를 저장할 수 있다는 것은 동일한 면적에서 스토리지 용량을 기존 드라이브 대비 거의 두 배로 늘릴 수 있다는 것을 의미한다. 이러한 혁신은 데이터 스토리지의 미래와 데이터센터의 디지털 인프라에 괄목할 만한 영향을 미친다. AI의 발전과 함께 데이터의 가치가 그 어느 때보다 높아졌다. IDC에 따르면 2027년에는 전 세계에서 총 291ZB의 데이터가 생성될 것으로 예측되며, 이는 스토리지 제조 용량의 15배 이상일 것으로 보인다. 대부분의 데이터를 호스팅하는 대형 데이터 센터에 저장된 데이터 중 90%가 하드 드라이브에 저장된다. 즉, AI 애플리케이션의 주도로 데이터가 급증함에 따라 물리적 공간을 늘리지 않으면서도 데이터를 저장할 수 있는 스토리지 기술 혁신이 필요하다. 데이터 스토리지 인프라를 업그레이드하는 것은 단순히 기술적인 문제가 아니라 지금 시대가 직면한 규모, 총소유비용(TCO), 지속가능성이라는 과제에 대한 논리적 해답인 셈이다. 열 보조 자기 기록(HAMR) 기술은 선구적인 하드 드라이브 기술로 드라이브 집적도 향상을 위해 지난 20년 동안 수많은 연구를 거쳐 완성되어 왔다. 씨게이트 모자이크 3+ 플랫폼은 이러한 HAMR 기술을 씨게이트만의 방식으로 독특하게 구현한 것으로, 미디어(매체)부터 쓰기, 읽기 및 컨트롤러에 이르는 복잡한 나노 스케일 기록 기술과 혁신적인 재료 과학 역량을 집약한 결정체다. 이 플랫폼은 데이터 비트를 변환하고 자기 및 열 안정성을 유지하면서 더욱 촘촘하게 패킹해서 각 플래터에 훨씬 더 많은 데이터를 안정적이고 효율적으로 저장할 수 있다. 예를 들어, 기존 데이터센터에 있는 16TB 드라이브를 30TB 드라이브로 업그레이드하면 동일한 면적에서 스토리지 용량을 두 배로 늘릴 수 있다. 더 낮은 용량에서 업그레이드한다면 상승 폭은 더욱 커진다. 이 경우, 테라바이트당 전력 소비량이 40% 감소하는 등 스토리지 총소유비용(TCO)이 크게 개선된다. 또한 효율적인 자원 할당과 재활용 재료 사용으로 운영 비용을 절감하고 테라바이트당 탄소 배출량을 55% 감소시켜 데이터센터가 지속 가능성 목표를 달성할 수 있다. 드라이브 집적도 향상은 하이퍼스케일과 프라이빗 데이터센터의 판도를 바꿀 수 있다. 데이터센터가 급증하며 전력사용량과 탄소배출량 역시 늘어나 데이터센터의 지속가능성이 화두가 되고 있는 가운데, 과학기술정보통신부는 ‘탄소중립 기술혁신 추진전략-10대 핵심기술 개발방향’에서 2030년까지 데이터센터 전력소모량을 20% 절감하겠다고 밝힌 바 있다. 이러한 목표에 발맞춰, 집적도를 획기적으로 개선한 대용량 데이터 스토리지를 활용하는 것은 원활하고 지속적인 AI 모델 학습, 혁신 촉진 및 비즈니스 성공을 위해 필수적이다. 엔터프라이즈 데이터센터의 경우 제한된 공간, 전력, 예산에 맞춰 확장할 수 있는 지속 가능한 방법을 찾아야 한다. 하드 드라이브의 집적도 혁신은 점점 더 커져가는 클라우드 생태계와 AI 시대에 대응하는 해답이자, 동일한 공간에 더 많은 엑사바이트를 저장하면서도 자원 사용은 줄이도록 인프라를 확장할 수 있는 방법이다. 이는 글로벌 데이터 영역에서 경쟁력을 유지하고 글로벌 디지털 경제의 선두주자로서 입지를 강화하는 데 매우 중요하다.