GraphQL의 역할과 영향

Rajesh Narayanan 작성

검토 및 기여: OCTO 팀 외 여러 관계자.

F5 CTO실 의견

GraphQL은 기존 REST API의 한계를 뛰어넘는 현대적이고 효율적인 API 개발 방식으로 부상했습니다. REST는 웹 초창기부터 널리 사용되어 왔지만, GraphQL은 개발자에게 새로운 관점과 더 강력한 제어 기능을 제공합니다. 개발자는 GraphQL을 통해 강력한 형식의 스키마를 정의하여 클라이언트가 필요한 데이터를 정확하게 요청할 수 있도록 할 수 있습니다. GraphQL은 데이터를 과도하게 가져오거나 불충분하게 가져오는 문제를 해소함으로써 성능을 최적화하고, 복잡한 데이터 쿼리 및 데이터 모델링 요구 사항을 가진 현대적인 대화형 웹 애플리케이션을 더욱 쉽게 구축할 수 있도록 지원합니다.

하지만 GraphQL에도 여러 과제가 따른다는 점을 인정해야 합니다. 이 백서에서는 GraphQL 도입과 관련된 보안 우려와 학습 곡선에 대한 인사이트를 제공합니다. 또한 GraphQL을 성공적으로 구현한 유명 기업들이 얻은 이점을 보여주는 실제 사례를 살펴봅니다.

또한 GraphQL에 대한 자체 조사 결과를 소개하고, 그 과정에서 얻은 경험과 발견을 공유합니다. GraphQL의 기본 개념을 간략히 설명하고 REST와 비교하며, GraphQL이 해결하는 과제를 심층적으로 살펴봅니다. 조직이 충분한 정보를 바탕으로 의사 결정을 내릴 수 있도록 보안 고려 사항도 논의합니다. 이번 연구를 통해 GraphQL의 혁신적인 잠재력을 확인했습니다. 테스트 관리 제품군의 소프트웨어 아키텍처를 간소화한 사례를 소개하며, 그 결과 GraphQL을 통해 JSON 객체 내부에 숨겨져 있던 데이터의 노출량이 300% 이상 증가했습니다.

결론적으로, REST API 인프라의 확장, 최적화 또는 운영에 어려움을 겪고 있는 기업이라면 GraphQL을 실현 가능한 해결책으로 적극 검토할 것을 권장합니다. 당사의 인사이트는 GraphQL 도입을 시작하는 기업에 실질적인 지침을 제공하여, GraphQL의 이점을 활용하고 관련 과제를 효과적으로 극복할 수 있도록 지원합니다.

GraphQL 입문

왜 GRAPHQL인가?

REST API의 한계로 인해 새로운 API 기술 접근 방식에 대한 수요가 증가하고 있습니다.

REST(Representational State Transfer) 기반 접근 방식은 원래 웹 API 설계를 위한 일련의 아키텍처 원칙으로 제안되었습니다. REST는 Web 2.0의 등장과 함께 2000년대와 2010년대에 걸쳐 발전했으며, CORBA(Common Object Request Broker Architecture)와 같은 다른 기술보다 서비스 지향 아키텍처(SOA)를 구현하는 데 더 나은 수단으로 자리 잡았습니다.

모바일 기기의 보급으로 클라이언트 수가 늘어나면서 정확한 데이터에 대한 요구도 증가했습니다. 하지만 REST 기반 API에서는 데이터를 과도하게 가져오거나 필요한 만큼 가져오지 못하는 경우가 많아 비효율이 발생했습니다. Facebook과 같은 앱에서 볼 수 있듯이, 이 방식은 한 번의 업데이트에도 수많은 REST API 호출이 필요한 경우가 많았으며, 이로 인해 네트워크 트래픽이 증가하고 성능과 사용자 경험이 저하되었습니다.

GraphQL은 강력한 타입의 스키마와 더욱 효율적인 데이터 쿼리 방식을 제공함으로써 이러한 한계를 해결하도록 특별히 설계되었습니다. 따라서 네트워크 대역폭을 최적화하기 위해 특정 데이터만 필요한 사용 사례에 매우 적합합니다. 또한 GraphQL은 스키마를 자체 검사할 수 있어 더 나은 문서화와 도구 활용이 가능합니다. REST가 더욱 표준화된 방식으로 구현되었다면 어느 정도 경쟁력을 갖출 수도 있었겠지만, GraphQL의 고유한 기능과 장점은 분산형이면서 데이터 집약적인 최신 애플리케이션 아키텍처에 매력적인 선택지가 되게 합니다.

그림 1은 REST와 GraphQL의 구현 방식이 구조적으로 어떻게 다른지 보여줍니다. REST API와 GraphQL 비교에서 설명하듯이, “GraphQL과 REST API의 핵심적인 차이점은 GraphQL은 쿼리 언어인 반면, REST는 네트워크 기반 소프트웨어를 위한 아키텍처 개념이라는 것입니다.”

그림 1: REST와 GraphQL 비교. Rest API vs. GraphQL에서 발췌·수정

META가 GRAPHQL을 개발한 동기

Meta는 모바일 앱의 성능과 유연성을 개선하기 위해 2012년에 GraphQL을 개발했으며(2015년에 오픈 소스로 공개), GraphQL 이전에는 Meta의 모바일 앱이 RESTful API와 네이티브 코드를 조합하여 구축되었기 때문에 앱에서 지원해야 하는 다양한 기기, 화면 크기 및 네트워크 환경에 대응하기가 어려웠습니다. 

그들이 직면한 주요 과제 중 하나는 RESTful API가 종종 적절하지 않은 양의 데이터를 반환한다는 점이었습니다. 때로는 너무 많고, 때로는 너무 적었습니다. API가 모바일 앱에 필요하지 않은 대량의 데이터를 반환하면 로딩 시간이 길어지고 성능이 저하되었습니다. 반대로 API가 너무 적은 데이터를 반환하면 모바일 앱은 필요한 데이터를 모두 가져오기 위해 여러 엔드포인트에 여러 번 요청해야 했고, 이로 인해 처리 지연과 복잡성이 증가했습니다.

Meta는 모든 앱이 단일 요청으로 필요한 데이터만 요청할 수 있도록 GraphQL을 개발했습니다. 이를 통해 모바일 앱과 백엔드 서비스 간의 데이터 전송을 최적화하여 로딩 시간을 단축하고 성능을 향상할 수 있었습니다. 또한 GraphQL의 강력한 타입 시스템과 자체 문서화 기능 덕분에 개발자가 API를 더 쉽게 이해하고 사용할 수 있게 되었습니다.

GRAPHQL의 장점

GraphQL은 데이터 조회 및 조작을 위한 강력한 기능을 제공하여 기존 API 방식보다 상당한 이점을 제공합니다.

강력한 형식의 스키마

GraphQL은 강력한 형식의 스키마를 통해 API에서 쿼리할 수 있는 데이터의 구조와 형식을 명확하고 정확하게 정의합니다. 도서, 저자, 출판사 정보를 포함하는 도서관용 API가 있다고 가정해 보겠습니다.

a) GraphQL 스키마: GraphQL에서 강력한 형식의 스키마는 아래 그림 2와 같습니다:

그림 2: GraphQL 스키마 예시

GraphQL의 강력한 형식 스키마는 입력값 검증을 지원하고, 데이터의 과도한 가져오기와 불충분한 가져오기를 방지하며, 명확한 문서화 및 도구 지원을 제공하고, 버전 관리를 용이하게 하며, 권한 부여와 액세스 제어를 지원함으로써 보안상의 이점을 제공합니다. 이러한 기능은 일반적인 취약점의 위험을 줄이고 적절한 데이터 처리와 액세스 관리를 보장하여 API 보안을 강화합니다.

제시된 예시(그림 2)에서 스키마는 책, 저자, 출판사의 데이터 유형과 이들 간의 관계를 정의합니다. 이 스키마는 강력한 형식 지정이 적용되어 있어 모든 필드에 특정 데이터 유형이 지정되며, 클라이언트는 스키마를 쉽게 검사하여 사용 가능한 필드와 해당 유형을 확인할 수 있습니다.

b) REST 스키마: REST에서는 아래 그림 3과 같이 스키마가 느슨한 타입으로 정의됩니다:

그림 3: REST 스키마 예시

이러한 엔드포인트는 도서, 저자 및 출판사를 나타내는 JSON 객체를 반환하지만, 스키마 자체는 명시적으로 정의되어 있지 않아 프로그래머의 역량과 해석에 따라 달라집니다. 클라이언트는 데이터 구조를 이해하기 위해 문서에 의존해야 합니다.

REST를 넘어서

GraphQL은 REST보다 나은 대안이라는 수준을 넘어 발전해 왔으며, 더 나은 데이터 전략을 모색하는 기업이 선호할 만한 접근 방식으로 자리 잡을 잠재력이 있습니다. REST의 한계를 해결한다는 점 외에도 GraphQL이 API 설계의 새로운 접근 방식으로 발전한 데에는 여러 가지 이유가 있습니다. 표(그림 4)를 통해 REST 대비 GraphQL의 장점을 확인할 수 있지만, GraphQL은 REST 자체의 문제점을 파악한 데 따른 대응이라기보다 인터넷과 다양한 애플리케이션의 발전에 대응하여 등장한 것으로 이해하는 편이 가장 적절합니다.

그림 4: REST 대비 GraphQL의 장점

GRAPHQL의 과제

GraphQL은 기존 RESTful API에 비해 많은 장점을 제공하지만, 사용하는 데 몇 가지 어려움도 있습니다. 일반적인 과제는 다음과 같습니다:

1. 학습 곡선: 대부분의 개발자는 REST에 더 익숙하므로 GraphQL을 도입하려는 조직은 팀이 GraphQL을 효과적으로 사용하는 방법을 익힐 수 있도록 충분한 시간을 할애해야 합니다. GraphQL에서는 API를 구축하고 사용하는 방식에 대해 기존과 다르게 접근해야 하며, 이를 도입하려면 기반 애플리케이션 아키텍처를 변경해야 할 수도 있습니다. 개발자는 스키마, 리졸버, 타입과 같은 새로운 개념뿐만 아니라 새로운 도구와 라이브러리도 익혀야 할 수 있습니다. GraphQL에서는 클라이언트가 액세스할 수 있는 데이터를 더 세밀하게 제어할 수 있으므로 API 보안이 더 어려워질 수 있습니다. 입력값 검증, 인증, 권한 부여와 같은 기법도 RESTful API와는 다르게 적용해야 할 수 있습니다.
2. 캐싱: GraphQL에서는 클라이언트가 쿼리마다 서로 다른 데이터를 요청할 수 있어 응답을 캐싱하고 재사용하기가 더 어렵기 때문에 캐싱이 더 복잡할 수 있습니다.
3. 성능: GraphQL을 사용하면 클라이언트가 필요한 데이터만 요청할 수 있지만, 더 복잡하고 리소스를 많이 사용하는 쿼리가 실행될 수도 있습니다. GraphQL API는 특히 대규모 데이터 세트를 쿼리하거나 동시에 많은 요청이 발생할 때 성능 문제가 생길 수 있습니다. 개발자는 쿼리 깊이를 제한하거나 클라이언트가 필요한 특정 데이터에만 접근할 수 있도록 권한을 부여하는 등의 전략을 구현해야 합니다.
4. 오류 처리: GraphQL에서는 오류가 별도의 HTTP 상태 코드가 아닌 응답의 일부로 반환될 수 있으므로 오류 처리가 더 복잡해질 수 있습니다.
5. 테스트: GraphQL 테스트는 쿼리의 복잡성, 표준화된 테스트 방식의 부재, 스키마 변경, 런타임 중 쿼리 검증으로 인해 여러 어려움이 따릅니다. 개발자는 이러한 문제를 해결하기에 적합한 테스트 프레임워크와 도구를 찾는 데 시간을 투자해야 합니다. 또한 적절한 도구를 선택하고 스키마 변경을 고려하여 포괄적인 테스트 범위를 확보함으로써 GraphQL API를 효과적으로 테스트하고 기능과 안정성을 보장해야 합니다.
6. 모니터링: GraphQL API 모니터링은 쿼리의 복잡성, 표준화된 로깅 및 메트릭의 부재, 잠재적인 성능 문제로 인해 어려울 수 있습니다. GraphQL 쿼리의 동적인 특성 때문에 요청된 데이터의 구조와 크기를 예측하고 모니터링하기가 더욱 어렵습니다. GraphQL API에 특화된 표준 모니터링 도구가 없어 GraphQL 쿼리 성능, 오류 추적 및 API 상태에 대한 인사이트를 얻기도 어렵습니다. 개발자는 GraphQL의 고유한 특성을 처리할 수 있는 전문 모니터링 도구와 방식을 도입하여 효율적인 성능과 안정적인 운영을 보장해야 합니다.

GraphQL 사용 패턴

GraphQL은 API 구축부터 모바일 앱 구동에 이르기까지 광범위한 애플리케이션에 활용할 수 있는 강력한 도구입니다. 유연성이 뛰어나고 여러 데이터 소스를 통합할 수 있어 다양한 사용 패턴에 적합합니다.

1. 효율적인 API 구축: GraphQL의 주요 용도 중 하나는 웹 및 모바일 애플리케이션에서 사용할 수 있는 API를 구축하는 것입니다. GraphQL은 데이터를 정의하고 액세스하는 유연하고 강력한 방법을 제공하므로, 다양한 클라이언트와 사용 사례를 지원해야 하는 API를 구축하는 데 매우 적합합니다.
2. 데이터 가져오기 및 조작: GraphQL은 데이터베이스, 클라우드 서비스, 기타 API 등 다양한 소스에서 데이터를 가져오고 조작하는 데 사용할 수 있습니다. GraphQL은 데이터에 접근하는 통합된 방식을 제공하여 데이터 기반 애플리케이션을 구축하고 유지 관리하는 과정을 간소화할 수 있습니다.
3. 실시간 사용 사례: GraphQL은 실시간 사용 사례에 매우 적합합니다. 클라이언트가 특정 데이터의 업데이트를 구독하고 데이터가 변경될 때 알림을 받을 수 있기 때문입니다. 이는 채팅, 라이브 스트리밍, 실시간 대시보드 등의 애플리케이션에 활용할 수 있습니다.
4. 마이크로서비스: GraphQL을 사용하면 서로 다른 마이크로서비스가 일관되고 명확하게 정의된 방식으로 통신할 수 있는 유연하고 느슨하게 결합된 아키텍처를 구축할 수 있습니다.
5. 백엔드에서 프런트엔드로: GraphQL을 사용하면 프런트엔드용 백엔드(BFF) 아키텍처를 구축할 수 있으며, 이를 통해 다양한 프런트엔드 클라이언트가 일관되고 효율적인 방식으로 데이터와 서비스에 접근할 수 있습니다.
6. 모바일 개발: GraphQL은 플랫폼이나 기기에 관계없이 일관되고 효율적인 방식으로 데이터와 서비스에 액세스할 수 있도록 하여 모바일 앱을 구동하는 데 사용할 수 있습니다.

업계의 GraphQL 도입 경험(사례 연구)

다음과 같은 업계 도입 사례에서 볼 수 있듯이, GraphQL이 필요한 이유는 분명합니다:

넷플릭스

Netflix는 자사의 GraphQL 여정을 2020년에 2부작 블로그 시리즈로 정리했으며, 이는 모든 GraphQL 실무자가 반드시 읽어야 할 글입니다. 이들이 소개한 사례 연구는 Studio Edge 시스템으로, 스튜디오 API를 GraphQL 기반으로 재설계한 내용입니다. Netflix의 Studio API는 콘텐츠 팀이 TV 프로그램과 영화의 제작, 후반 작업 및 배급을 관리하고 모니터링하는 데 사용됩니다. 이 API를 통해 작품 메타데이터, 출연진 및 제작진 정보 등을 비롯한 방대한 데이터에 접근할 수 있습니다.

초기에 Studio API는 JSON 형식으로 데이터를 반환하는 엔드포인트를 갖춘 전통적인 RESTful 아키텍처를 사용해 구축되었습니다. 하지만 API가 확장되고 이에 접근하는 클라이언트 수가 늘어나면서 더 효율적인 솔루션이 필요하다는 점이 분명해졌습니다.

Netflix는 Studio API를 위한 잠재적 솔루션으로 GraphQL을 검토하기 시작했습니다. 먼저 Studio API를 위한 선별된 그래프를 구축했습니다. 그 결과 네트워크 사용량 절감, 데이터 접근 간소화, 클라이언트가 필요한 데이터만 요청할 수 있도록 하여 성능을 개선하는 등 몇 가지 주요 이점을 확인했습니다.

Netflix는 Studio API에 GraphQL을 도입하면서 몇 가지 고유한 과제에도 직면했습니다. 특히 스키마의 복잡성을 관리하고 클라이언트가 접근 권한이 있는 데이터에만 접근할 수 있도록 보장하는 것이 주요 과제였습니다.

이러한 과제를 해결하기 위해 Netflix는 Apollo Federation 사양을 사용하여 Studio API 스키마를 더 작고 관리하기 쉬운 단위로 분할하는 "Netflix GraphQL Federation"이라는 맞춤형 솔루션을 개발했습니다. 또한 권한 및 액세스 제어 관리 시스템을 구현하여 클라이언트가 스키마의 특정 부분에 접근하지 못하도록 제한할 수 있게 했습니다.

또한 해당 블로그에서는 모놀리스에서 페더레이티드 게이트웨이로 발전해 온 API 아키텍처의 변화 과정도 소개했습니다. 그림 5는 해당 블로그의 이미지를 재구성한 것입니다.

그림 5: API 아키텍처의 발전 과정(Netflix 자료를 바탕으로 재구성)

업계에서 널리 사용되고 있을 수 있지만 아직 공식적으로 정립되지 않은 또 다른 접근 방식이 빠져 있다고 생각합니다.

아래와 같이 그림 5의 게이트웨이 집계 계층과 연합 게이트웨이를 결합할 수 있습니다:

그림 6: 임시 GraphQL 게이트웨이 액터를 포함하는 F5의 진화된 API 아키텍처

각 톱니바퀴 아이콘은 기본적으로 엣지, 즉 토폴로지상 클라이언트와 가까운 위치에서 실시간으로(트랜잭션별로도 가능) 인스턴스화되어 보안 API 전송을 통해 마이크로서비스에 연결될 수 있는 일시적이고 페더레이션된 GraphQL 인스턴스(일명 게이트웨이 액터)를 나타냅니다. 이 조합은 본질적으로 게이트웨이 집계 계층 또는 페더레이션 계층을 두 기능의 장점을 결합한 분산 게이트웨이 액터로 대체합니다. 이를 분산 GraphQL 게이트웨이 액터 아키텍처라고 하며, 그림 7에 나와 있습니다.

그림 7: 분산형 GraphQL 게이트웨이 액터

그 밖의 얼리 어답터

PayPal

PayPal은 2018년 Checkout 앱에 GraphQL을 도입한 이후 계속해서 GraphQL을 활용해 왔습니다. Meta와 마찬가지로 PayPal이 REST에서 가장 우려한 점은 REST의 설계 원칙이 웹 및 모바일 앱과 그 사용자에게 최적화되어 있지 않다는 것이었습니다. 클라이언트 애플리케이션은 데이터를 가져오기 위해 클라이언트와 서버 간에 여러 차례 요청을 주고받아야 했으며, 약 700ms가 소요되었습니다. 이로 인해 렌더링 시간이 길어지고 사용자의 불만이 커졌으며 전환율도 낮아졌습니다. PayPal은 Checkout 앱의 사용자 인터페이스(UI) 개발자들이 UI를 구축하는 데 업무 시간의 3분의 1도 채 쓰지 못하고, 나머지 시간은 데이터를 가져오고 처리하는 방법을 파악하는 데 사용하고 있다는 사실을 발견했습니다.

PayPal 엔지니어링 팀이 검토한 다른 기술로는 오케스트레이션 API와 Bulk REST가 있었습니다. 오케스트레이션 API를 구축하면 데이터를 과도하게 가져오게 되고 클라이언트가 서버에 종속될 수 있었습니다. PayPal은 시간이 지남에 따라 이 접근 방식으로 인해 API가 비대하고 조잡해지며 여러 목적을 동시에 수행하게 될 수 있다고 판단했습니다. Bulk REST 실험 역시 성공적이지 못했습니다. 엔지니어링 팀이 오케스트레이션 API를 일일이 조정할 필요는 없어졌지만, 클라이언트가 API의 작동 방식을 속속들이 알아야 했기 때문입니다.

PayPal이 신제품 개발에 GraphQL을 처음 활용한 사례는 PayPal Checkout을 앱에 통합하기 위한 모바일 SDK였습니다. 엔지니어링 팀은 GraphQL을 평가한 지 일주일 만에 신제품에 이를 사용하기로 결정했습니다. API가 아직 준비되지 않았음에도 PayPal에 관한 전문 지식이 거의 필요하지 않은 상태에서 예정보다 일찍 제품을 완성할 수 있었습니다. 개발자들이 효율적이고 사용자 친화적인 앱을 빠르게 구축할 수 있었던 덕분에 엔지니어링 팀은 기술 스택에 GraphQL을 전면 도입하기로 결정했습니다.

스타벅스

스타벅스는 자사의 프로그레시브 웹 앱(PWA) 개발을 위해 외부 업체를 고용했습니다.

팀은 복잡한 비즈니스 로직을 효율적이고 효과적으로 처리할 수 있는 주문 시스템을 구축하는 임무를 맡았습니다. 고객이 주문을 개인화할 수 있기 때문에 개발팀은 시스템이 다양한 고유 비즈니스 로직을 처리하고, 적시에 적절한 데이터를 적절한 곳으로 전송할 수 있도록 해야 했습니다.

GraphQL을 통해 팀은 서버 측 캐싱과 렌더링을 지원하는 효율적인 API를 구축하여 오프라인 기능을 개선할 수 있었습니다. 또한 React를 활용해 애니메이션을 구현함으로써 역동적이고 매력적인 사용자 경험을 제공했습니다.

F5의 GraphQL

F5 CTO실의 목표는 F5 에코시스템 내에서 GraphQL을 어떻게 활용할 수 있는지 파악하는 것이었습니다. 현재 GraphQL 활용 방안을 모색하는 두 개의 프로젝트를 진행하고 있습니다.

데이터 모델 및 가시성 개선

F5에서 제공하는 테스트 관리 제품군(TMS)을 통해 고객은 자체 시스템의 엔드포인트 또는 클라이언트를 테스트하여 사람인지 봇인지 확인할 수 있습니다.

이 프로젝트는 TMS 소프트웨어의 개발 및 테스트 프로세스를 간소화하기 위한 내부용 프로젝트였습니다. 주요 목표는 기존 SQL 데이터베이스에 갇혀 있던 JSON 데이터를 추출해 그래프 데이터로 변환하고, 쿼리를 위한 GraphQL API를 구현하는 것이었습니다.

이는 현재 데이터베이스가 메타데이터를 테이블형 데이터베이스에 JSON 객체로 저장함으로써 발생하는 "JSON 블롭 문제"를 비롯한 여러 과제를 안고 있기 때문에 필요했습니다. 이러한 객체를 파싱하고 처리하는 작업은 본질적으로 비용이 많이 들고 비효율적입니다. 또한 JSON 블롭은 그래프 구조의 특성상 F5의 제품과 보안을 한층 더 개선할 수 있는 가치 있는 데이터를 포함하고 있습니다. 방향성 그래프 데이터베이스로 전환하면 JSON 블롭을 효율적으로 파싱하고 방향성 관계를 기반으로 관리하여 데이터 전송과 활용을 최적화할 수 있습니다.

그림 8: F5 TMS GraphQL 프로젝트 범위

결과는 고무적입니다. TMS 관계형 데이터베이스에서 어떤 테이블에 JSON 블롭이 있는지 파악한 결과, GraphDB로 전환하고 GraphQL을 사용하면 시스템에 대한 가시성을 몇 배나 높일 수 있다는 결론을 내렸습니다.

그림 9: 구현 방식 선택

그림 9는 이 프로젝트에서 가능한 발전 방향 또는 구현 방식을 보여줍니다. 각 선택지에는 저마다 고려해야 할 사항이 있습니다.

옵션 1은 클라이언트를 변경할 필요가 없으므로 UI에 미치는 영향이 가장 적습니다. 옵션 1이나 2와 같은 하이브리드 모드는 상황에 따라 효과적일 수 있으며, 특히 JSON 객체가 포함된 열의 수가 적은 경우에 적합합니다. 또한 각 JSON에서 파생되는 스키마도 작습니다.

하지만 이를 계획하는 과정에서 JSON 객체에 필요한 컨텍스트가 SQL 데이터베이스의 다른 열에 저장되어 있다는 사실을 알게 되었습니다. 또한 각 JSON 객체에 저장된 스키마의 크기도 상당히 컸습니다. 이로 인해 코드베이스를 유지 관리하는 데 더 많은 작업이 필요했을 것입니다. 따라서 신중하게 검토한 끝에 옵션 3과 같이 GraphQL과 Neo4J를 지원하도록 애플리케이션 아키텍처를 재설계하기로 결정했습니다.

CLOUDGRAPH 통합

CloudGraph는 AWS, Azure, GCP 및 Kubernetes(K8s)를 위한 무료 오픈 소스 범용 GraphQL API이자 클라우드 보안 태세 관리(CSPM) 도구입니다. 이 프로젝트의 목표는 CloudGraph를 사용하여 F5 Distributed Cloud(F5XC) 데이터가 표시되는 ‘CloudGraph 플러그인’(그림 10)을 구축함으로써 F5 Distributed Cloud를 통해 연결된 클라우드 리소스에 대한 가시성을 높이는 것입니다.

당사의 목표는 CloudGraph와 통합하여 해당 기술을 심층적으로 이해하고, 향후 F5XC 데이터를 위한 CloudGraph 통합 기능, 인사이트 및 GraphQL API를 구축하는 것입니다.

그림 10: CloudGraph와 F5 Distributed Cloud의 통합

사용자 지정 F5XC 공급자를 CloudGraph 플랫폼에 통합하고 플랫폼의 관계 생성 기능을 활용하면 F5XC를 통해 연결된 클라우드 리소스와 다른 클라우드 전반에서의 관계를 더욱 명확하게 파악할 수 있습니다. 그런 다음 동일한 테넌트에 대해 여러 클라우드의 리소스를 대상으로 복잡한 쿼리를 생성할 수 있습니다. 이를 통해 이해관계자에게 F5XC에 대한 포괄적인 개요를 제공하고, F5 및 고객과 관련된 클라우드 운영을 위한 추가 GraphQL 플러그인과 사용자 지정 인사이트를 지원하도록 CloudGraph와의 더욱 심층적인 통합을 모색할 수 있습니다.

위의 이니셔티브를 바탕으로 진행한 초기 검토 결과는 앞서 소개한 사례 연구에서 설명한 경험과 일치했습니다.

GraphQL 보안 우려 사항

보안 측면에서 GraphQL이 REST보다 우수하다는 초기 인식은 사실이 아닌 것으로 밝혀졌습니다. 다른 모든 기술과 마찬가지로 GraphQL도 올바르게 구현하지 않으면 고유한 위험이 따르기 때문입니다. GraphQL이 본질적으로 다른 기술보다 더 안전한 것은 아니라는 점을 인식하는 것이 중요합니다. GraphQL API의 보안을 보장하려면 올바르게 구현하고 모범 사례를 준수해야 합니다. 이러한 오해를 바로잡으면 GraphQL의 보안 고려 사항을 현실적으로 이해하고 잠재적 위험을 완화하기 위한 적절한 조치를 취할 수 있습니다.

인트로스펙션 공격

GraphQL은 개발자에게 인트로스펙션이라는 강력한 도구를 제공합니다. 이 도구를 사용하면 GraphQL 서비스에서 사용하는 스키마에 관한 정보를 요청할 수 있어, 개발자가 서비스와 그 구조를 파악할 수 있습니다. 하지만 인트로스펙션에는 위험이 따릅니다. 운영 환경의 GraphQL 서비스에서 인트로스펙션을 활성화하면 스키마에 포함된 민감한 정보에도 접근할 수 있게 됩니다. 악의적인 사용자가 인트로스펙션을 악용해 민감한 데이터를 탈취하고 잠재적으로 피해를 일으킬 수 있으므로 이는 심각한 위험을 초래합니다. 또한 이러한 사용자는 전체 스키마를 살펴보고 실행할 쿼리를 결정할 수 있기 때문에 잠재적으로 유해한 작업을 쉽게 식별할 수 있습니다. 이러한 정보 유출은 스키마의 특성과 스키마에 포함된 데이터에 따라 치명적인 결과를 초래할 수 있습니다.

완화 방법: 인트로스펙션의 위험을 완화하는 한 가지 방법은 다양한 프레임워크를 사용하여 프로덕션 API에서 인트로스펙션을 비활성화하는 것입니다. 인트로스펙션을 비활성화하면 개발자는 인트로스펙션이 제공하는 편리한 기능 중 일부를 사용할 수 없게 됩니다. 하지만 이러한 편의성을 되찾기 위해 개발자는 GraphOS와 같은 도구에 프로덕션 API의 GraphQL 스키마를 등록할 수 있습니다. 이를 통해 스키마와 그 정보에 대한 접근을 통제된 방식으로 유지할 수 있습니다.

SQL 인젝션

SQL 인젝션은 널리 알려진 흔한 공격으로, 데이터 조작부터 데이터베이스 전체 삭제에 이르기까지 다양한 위험을 초래합니다. 이 단순한 공격은 문자열 연결의 허점을 악용하여 공격자가 입력값에 실행 가능한 코드를 삽입함으로써 데이터베이스에 무단으로 접근하고 악의적인 변경을 수행할 수 있게 합니다. 흥미롭게도 이 공격 벡터는 SQL 데이터베이스에만 국한되지 않으며 Neo4j와 같은 그래프 데이터베이스에도 영향을 미칠 수 있습니다. Neo4j는 SQL과 유사하고 그 취약점도 그대로 지닌 Cypher 쿼리 언어를 사용합니다. Cypher 인젝션으로 알려진 이 공격 유형은 이러한 유사성을 악용하지만, 새로운 해결책을 고안할 필요 없이 기존 해결책을 활용할 수 있다는 이점도 있습니다.

완화 조치: 대응책으로는 악용을 탐지하고 방지하기 위해 사용자 입력을 정제하고, 매개변수화를 사용하여 사용자 입력이 쿼리 생성에 직접 사용되지 않도록 추상화하는 방법이 있습니다. 이러한 조치는 인젝션 공격의 위험을 효과적으로 완화합니다. GraphQL 구현에서 이 보안 문제를 해결하는 것은 매우 중요하지만, 다행히도 잘 알려져 있고 쉽게 구현할 수 있는 해결책이 마련되어 있습니다.

REST 프록시 API 공격

REST API 위에 GraphQL API를 계층화하면 서버 측 요청 위조(SSRF) 취약점이 발생할 수 있습니다. 공격자는 GraphQL 프록시를 통해 REST API로 전송되는 매개변수를 수정하여 이를 악용할 수 있습니다. 두 API 모두 특정 호출의 매개변수를 검증하지 않으면 공격자가 백엔드 시스템을 제어할 수 있게 됩니다. 예를 들어 GraphQL 쿼리의 사용자 ID에 "/delete"를 추가하면 해당 값이 REST API로 전달될 때 의도치 않게 데이터가 삭제될 수 있습니다.

완화 조치: 이 취약성은 충분히 우려할 만하지만, GraphQL 스키마에 타입을 정의하고 외부 API나 서비스로 매개변수를 보내기 전에 철저히 검증하면 효과적으로 해결할 수 있습니다. 이 취약성을 비롯해 GraphQL과 관련된 여러 취약성은 GraphQL 자체의 본질적인 문제가 아니라 구현상의 문제에서 비롯된다는 점에 유의해야 합니다. 이러한 문제는 이 기술이 큰 잠재력을 지니고 있음에도 단기적인 관점에서 GraphQL을 잘못 사용할 때 발생합니다.

배칭 공격

인증 취약점은 GraphQL을 비롯한 다양한 시스템에서 흔히 악용되는 공격 경로입니다. GraphQL은 단일 요청으로 여러 쿼리나 뮤테이션을 전송할 수 있기 때문에 무차별 대입 방식을 사용하는 배칭 공격에 노출될 수 있습니다.

첫 번째 유형의 공격은 로그인 비밀번호를 무차별 대입하는 방식입니다. 공격자는 로그인 자격 증명 쌍이 포함된 수많은 뮤테이션을 하나의 요청으로 전송합니다. GraphQL에서는 한 번의 요청에 여러 뮤테이션을 포함할 수 있으므로, 이 공격은 요청 속도 제한 검사를 우회하고 비밀번호 무차별 대입을 통해 세션을 생성할 수 있게 합니다.

두 번째 유형의 공격도 비슷한 방식으로 작동하지만, 일회용 비밀번호(OTP)라고 하는 널리 사용되는 이중 인증(2FA) 방식을 표적으로 삼습니다. 하나의 요청에 여러 개의 뮤테이션을 담아 전송하며, 각 뮤테이션에는 유효한 로그인 자격 증명과 서로 다른 OTP 값이 포함됩니다. 뮤테이션 중 하나라도 올바른 OTP를 포함하면 요청이 인증되고 세션이 생성됩니다.

완화 조치: 이러한 취약점을 해결하려면 완벽한 해결책이 없는 만큼 종합적인 접근 방식이 필요합니다. 개발자는 안전한 코딩 관행을 채택하고 비즈니스 로직 관점을 중시함으로써 중요한 역할을 수행합니다. 웹 서버 측에서는 로그인 시도 횟수 제한 및 사용자 입력 검증과 같은 조치를 구현해야 합니다. 또한 정상적인 로그인 시도에는 일반적으로 둘 이상의 뮤테이션이 포함되지 않으므로, 요청에 여러 뮤테이션이 포함되어 있는지 검사하는 데 각별히 주의를 기울여야 합니다.

서비스 거부 공격

이러한 공격은 GraphQL 서비스에 과도한 트래픽을 유발하여 정상 사용자의 요청을 처리할 수 없게 만들고, 서버 충돌까지 일으킬 수 있습니다. DoS 공격은 재귀적인 GraphQL 쿼리를 실행하거나 대규모 쿼리 요청을 전송하는 방식으로 수행될 수 있습니다.

재귀 쿼리 시나리오에서 공격자는 GraphQL 스키마 정의의 순환적 특성을 악용합니다. 예를 들어 스키마에 저자와 도서 유형이 포함되어 있다면, 공격자는 저자와 도서를 반복적으로 순환 쿼리하여 서버에 재귀 호출을 폭주시킴으로써 서버 운영을 방해할 수 있습니다.

또는 공격자는 데이터베이스에서 방대한 양의 데이터를 요청하는 쿼리를 실행할 수 있습니다. 예를 들어, 하나의 쿼리로 수많은 저자와 이들에게 연결된 모든 도서를 가져올 수 있습니다. 이처럼 대규모로 데이터를 요청하면 시스템이 현저히 느려지거나 중단될 수 있습니다.

완화: 이 문제를 완화하는 방법에는 여러 가지가 있습니다. 첫 번째 방법은 쿼리에 시간 제한을 설정하여 사용자가 지정된 시간을 초과하는 요청을 하지 못하도록 하는 것입니다. 하지만 허용된 시간 내에도 피해가 발생할 수 있으므로 이 방법만으로는 문제를 완전히 해결하지 못할 수 있습니다. 또 다른 방법은 쿼리의 깊이와 복잡도를 제한하는 것입니다. 지정된 깊이나 복잡도를 초과하여 스키마 정의에서 벗어나는 쿼리는 거부할 수 있습니다. 마지막으로 사용자 요청을 제한하는 방식도 효과적일 수 있습니다. 사용자가 대량의 요청을 보내거나 연속해서 요청을 보내는 경우, 서버가 추가 요청을 처리할 준비가 될 때까지 해당 사용자의 서버 접근을 일시적으로 차단할 수 있습니다.

GraphQL 배포 패턴

다음과 같이 GraphQL에는 여러 가지 배포 패턴이 있으며, 각 패턴마다 고유한 장단점과 고려 사항이 있습니다. 가장 일반적인 패턴은 다음과 같습니다:

모놀리식 배포

이는 GraphQL API를 배포하는 가장 간단하고 일반적인 패턴입니다. 모놀리식 배포에서는 GraphQL 서버, 데이터베이스 및 기타 필요한 서비스를 모두 하나의 단위로 함께 배포합니다. 따라서 GraphQL을 쉽게 시작할 수 있지만, 애플리케이션이 성장함에 따라 확장하고 유지 관리하기가 어려워질 수 있습니다.

그림 11: 단순 모놀리스

조합형 모놀리스

컴포즈드 모놀리스는 GraphQL을 API 계층으로 사용하고 모놀리스와 마이크로서비스를 조합하여 모놀리식 애플리케이션을 구축하는 아키텍처를 의미합니다(그림 12). 이 패턴에서는 전체 시스템을 개별 마이크로서비스로 분할하는 대신, 모든 비즈니스 로직과 데이터 액세스 계층을 캡슐화한 여러 개의 독립된 모놀리스로 애플리케이션을 먼저 개발합니다.

그림 12: 컴포즈드 모놀리스

이 모놀리식 구조에서는 GraphQL이 API 계층으로 구현되어 클라이언트가 기반이 되는 여러 마이크로서비스의 데이터를 요청하고 가져올 수 있습니다. 즉, 애플리케이션은 배포 관점에서는 모놀리식 구조를 유지하지만, GraphQL을 활용해 다양한 서비스의 데이터를 조합하고 이를 유연하고 효율적인 방식으로 클라이언트에 제공합니다.

이 패턴은 개발 및 배포를 간소화하고 GraphQL의 강력한 쿼리 및 데이터 가져오기 기능을 활용할 수 있다는 이점을 제공합니다. 개발자는 GraphQL이 제공하는 유연성과 사용 편의성을 누리면서 마이크로서비스 아키텍처를 점진적으로 도입할 수 있습니다.

페더레이션된 서브그래프

GraphQL 배포 패턴에서 페더레이션 그래프는 서브그래프라고 하는 여러 GraphQL 서비스를 하나의 통합된 GraphQL 스키마로 결합합니다. 각 서브그래프는 자체 데이터와 기능을 갖춘 별도의 도메인 또는 마이크로서비스를 나타냅니다. 이 아키텍처는 요청된 필드를 기준으로 클라이언트 쿼리를 적절한 서브그래프로 라우팅하는 중앙 게이트웨이를 사용합니다. 개발자는 이러한 서브그래프를 페더레이션하여 클라이언트가 서로 다른 서비스를 원활하게 쿼리하고 탐색할 수 있는 일관된 그래프를 만들 수 있습니다.

그림 13: 페더레이션된 서브그래프

이 접근 방식은 서비스의 모듈성, 확장성 및 독립적인 개발을 촉진하여 GraphQL API를 구축할 때 성능과 유연성을 향상합니다. 페더레이션된 서브그래프(그림 13)는 다양한 서비스의 데이터를 조합하고 분산형 확장 가능 아키텍처를 구축할 수 있는 강력한 방법을 제공합니다.

하이브리드 그래프

GraphQL 배포 패턴의 하이브리드 그래프(그림 14)는 스티칭 기법을 통해 페더레이션된 서브그래프와 페더레이션되지 않은 스키마를 결합합니다. 이 접근 방식을 사용하면 조직은 기존 GraphQL API 또는 레거시 시스템을 페더레이션된 마이크로서비스와 통합하여 두 접근 방식의 이점을 모두 활용하는 통합 GraphQL API를 구축할 수 있습니다. 하이브리드 그래프 아키텍처는 스키마를 병합하고 타입과 필드 간의 관계를 해석함으로써 유연성, 모듈성 및 확장성을 제공합니다.

그림 14: 하이브리드 그래프

하이브리드 그래프 패턴을 사용하면 조직은 기존 리소스를 활용하면서 페더레이션을 점진적으로 도입할 수 있습니다. 페더레이션된 서브그래프와 페더레이션되지 않은 스키마를 원활하게 통합하여 다양한 요구 사항을 충족하고 상호 운용성을 높일 수 있습니다. 이 접근 방식을 통해 조직은 변화하는 요구 사항에 맞춰 확장하고 조정할 수 있는 포괄적인 GraphQL API를 구축할 수 있습니다. 하이브리드 그래프는 페더레이션된 서비스와 페더레이션되지 않은 서비스의 장점을 결합하여 GraphQL 배포 환경을 구축하기 위한 유연하고 강력한 솔루션을 제공합니다.

GraphQL 배포에서 하이브리드 그래프를 사용할 때는 병합된 스키마의 복잡성 관리, 잠재적인 성능 오버헤드 해결, 데이터 일관성과 무결성 보장, 시스템 발전 및 버전 관리, 분산 아키텍처에서의 모니터링 및 디버깅 복잡성 대응과 같은 과제가 발생합니다. 이러한 과제를 극복하고 하이브리드 그래프 배포를 원활하게 운영하려면 신중한 계획과 최적화, 견고한 개발 관행이 필요합니다.

서버리스 라우팅

이 패턴은 GraphQL API를 AWS Lambda 또는 Google Cloud Functions와 같은 서버리스 함수 집합으로 배포하는 방식입니다. GraphQL API를 비용 효율적이고 확장성 있게 배포할 수 있지만, 지연 시간이 늘어나고 아키텍처가 더 복잡해질 수도 있습니다.

서버리스 라우팅에는 많은 과제가 따릅니다. 그중 하나는 애플리케이션이 확장됨에 따라 분산된 서브그래프를 원활하게 연결하는 것입니다. 여러 팀과 배포를 조율하는 과정이 복잡해질 수 있어 서브그래프를 효과적으로 관리하고 확장하기가 어려워집니다. 이러한 서브그래프 간의 데이터 일관성과 동기화를 보장하는 것도 또 다른 과제입니다. 분산 서버리스 환경에서는 모니터링과 디버깅이 더 어려울 수 있으므로 적절한 로깅 및 오류 처리 메커니즘이 필요합니다. 또한 여러 서버리스 함수와 서브그래프 전반에서 액세스 제어와 권한 부여를 관리하는 데에도 어려움이 따릅니다. 서버리스 기반 GraphQL 배포의 원활한 운영과 확장성을 보장하려면 이러한 과제를 해결하는 것이 필수적입니다.

엣지 배포

GraphQL API의 엣지 배포 패턴에서는 CDN 서비스를 사용해 API를 클라이언트와 더 가까운 위치에 배치합니다. 이를 통해 지연 시간이 단축되어 응답 속도가 빨라지고, 오리진 서버의 부하가 줄어들며, DDoS 공격으로부터 보호받을 수 있습니다.

API 인프라를 전 세계의 엣지 서버에 분산하면 트래픽을 더욱 효율적으로 처리하고 전 세계 사용자에게 더 나은 경험을 제공할 수 있습니다. CDN의 캐싱 및 필터링 기능은 확장성을 높이고, 트래픽이 폭증하거나 악의적인 공격이 발생하더라도 API의 가용성을 보장하는 데 도움이 됩니다. 엣지 배포는 CDN의 서버 네트워크를 활용하여 API의 성능과 안정성을 최적화할 수 있습니다.

결론

GraphQL 기술은 전통적인 기업에서도 도입할 수 있을 만큼 충분히 성숙했습니다. 비록 Gartner의 2022년 API 하이프 사이클에 따르면 널리 도입되기까지는 아직 몇 년이 더 걸릴 것으로 보이지만, 이제 필요한 도구가 이미 갖춰진 중요한 전환점에 도달했습니다. GraphQL은 여전히 비교적 새로운 기술이지만, 기존 대규모 기업의 요구 사항을 충족할 수 있는 수준으로 발전했습니다.

GraphAPI 기술의 성숙은 GraphQL 및 기타 그래프 데이터베이스 기술을 도입하는 기업이 늘어나는 데 기반을 두고 있습니다. 이러한 기술을 도입하는 기업이 증가함에 따라 이를 지원하는 데 필요한 도구와 리소스도 점점 더 많이 제공되어 다른 기업들도 더욱 쉽게 뒤따를 수 있게 되었습니다. 또한 향상된 데이터 쿼리와 복잡성 감소 등 GraphAPI 기술의 이점이 더욱 널리 인정받으면서 기업의 도입이 한층 더 가속화되고 있습니다.

업계는 GraphQL과 같은 GraphAPI 기술의 중요성과 REST의 한계를 극복할 수 있는 잠재력을 인식해야 합니다. 기업은 특히 데이터 모델링, 다양성, 불투명성 측면에서 GraphQL에 투자하고 이를 이해해야 할 시급한 필요성을 간과해서는 안 됩니다. GraphQL의 기능과 잠재력에 매료되기 쉽지만, 부풀려진 기대가 정점에 이른 뒤 환멸의 골에 빠질 가능성도 인정해야 합니다. 공급업체는 GraphQL을 완벽하게 지원할 수 있도록 제품 개선을 최우선 과제로 삼아야 하며, 공급업체를 포함한 기업 IT 부문은 생산성 향상을 위해 GraphQL을 통해 제공할 때 이점을 얻을 수 있는 데이터가 무엇인지 파악해야 합니다.

고객은 자사의 데이터를 이해하는 일을 최우선으로 삼고, 일반적인 기업은 GraphQL을 처음 도입한 하이퍼스케일러와는 운영 방식이 다르다는 점을 인식해야 합니다. GraphQL을 효과적인 소프트웨어 아키텍처 패턴으로 받아들이고, 생산성과 혁신을 향상하는 방향으로 업계를 발전시키기 위해 함께 노력합시다.