GraphQL의 종말에 대한 보고는 크게 과장되었습니다. 대신에 트렌드를 넘어서 성숙하고 신뢰할 수 있는 GraphQL이 기관을 더 나게 만드는 방법을 살펴봅시다.

[기술 이름을 여기에 입력]이 죽고 있다는 이야기를 듣게 될 때마다 한 잔 들어보세요. GraphQL은 최근 이러한 내러티브의 주요 주제가 되고 있습니다. 그 종말에 대한 주장, "무너졌다"는 생각은 개발자들 사이에서 곳곳에 퍼져 있습니다.

말할 필요도 없이, 이는 매우 안전하지 않은 음주 게임입니다.

GraphQL이 죽고 있지는 않아요. 이젠 새로운, 블리딩 엣지 기술은 아니지만, 테크 트위터 포스터 아동으로서 더 이상 대놓고 화제가 되지는 않았어요. 온라인 포럼에서의 뜨거운 논쟁과 흥미로운 주장들은 없어졌지만, GraphQL 그 자체는 견고하고, 잘 이해되는 도구로 성숙해져서 현재 실제 사용되며, 현실 세계의 문제를 해결하는 데 잘 확립되어 있어요.

GraphQL이 드디어 지루해졌어요.

지루함의 미덕

지루함은 안정적이에요. 지루함은 신뢰할 수 있어요.

GraphQL이 StackOverflow Trends를 보고 있다면 정체되었을 수도 있어요...

...하지만 저는 이것이 초기 흥분 주기의 폭풍 뒤의 침묵이며, 개발자 생태계 내에서의 역할과 목적에 대한 보다 세밀한 이해를 가능케 한다고 주장할 거예요.

제가 설명해 드릴게요.

2015년에는 GraphQL이 최고의 기술로 손 꼽히더니 2023년에는 이젠 여러분의 도구 상자 속의 또 다른 도구가 되었습니다.

여기서 오해가 나타난 것 같아요. GraphQL의 초기 흥행 주기 동안 개발자들 사이에서 REST API를 대체할 것으로 송고되어 자리를 털었습니다. 먼지가 내리고 실용적인 구현이 펼쳐지며, 점점 더 많은 조직에서 운영에 활용할 때, 우리는 하나 분명한 진실을 발견했어요 — GraphQL도 어떤 기술처럼 마법의 탄환은 아니었다는 것.

우리는 GraphQL이 어떤 부분에서 뛰어난 일을 하는지 깨달았어요 — API 조합이 필요하거나 데이터 종속성을 연합해야 하는 경우에는 확실한 선택입니다. GraphQL은 프론트엔드와 백엔드 팀 간의 조직적인 격차를 메우는 데 뛰어난 능력을 발휘했으며, 모든 사람이 합의할 수 있는 공유 계약으로서 우리를 이어주었습니다. 모바일 앱을 만들어야 하고 느린 장치와 네트워크를 고려해야 할 때는 GraphQL이 최선의 선택이 될 거예요.

GraphQL의 최적 사용 사례와 그렇지 않은 사례를 파악하고, 함정과 절충 사항을 파악했으며, 실 서비스 환경에서의 배포 방법을 알아냈습니다. 그 결과, GraphQL이 지루해진 것이죠.

괜찮아요.

8년 뒤에 GraphQL이 '지루하다'는 것은 후퇴가 아니라, 그에 대한 관심이 식은 반면 GraphQL 자체가 성공했다는 것을 의미합니다.

GraphQL은 이제 주류가 되었습니다

이제 많은 회사들이 어떤 형태로든 GraphQL을 사용하고 있습니다.

예를 들어 Shopify은 GraphQL 스키마가 제공하는 강타입 구조를 활용하여 클라이언트-서버 데이터 매핑을 원활하게 하고 있다. 이전에 Shopify의 외부 REST API에 대한 변경 사항이 발생하면 클라이언트 앱이 오동작하여 클라이언트 측 개발자들이 필드를 정적으로 유형화하고 무료로 전달되는 JSON 응답을 매번 변환해야 했기 때문에 위험이 증가했습니다. GraphQL 스키마는 강력한 형식 지원을 통해 신뢰성, 유형 안정성 및 효율적인 계약 관리를 육성하는 기반을 제공했습니다. 대부분의 기관(예: GitHub)에 대해, 프론트엔드를 위한 직관적인 쿼리 메커니즘이 GraphQL 도입에 대한 수익을 가져다주는 유일한 필수 조건입니다.

그러나 다양한 '지루한' 기술을 사용하고 있지만 지식을 격리하는 서로 다른 팀이 있는 경우는 어떨까요? 이 경우 안정적이고 신뢰할 수 있는 기술을 사용한다고 해도, 지식 격리는 여전히 증가된 조직적 위험을 감수하고 있다는 것을 의미합니다.

여기서 연합 GraphQL이 도움이 될 수 있습니다. 페더레이션은 여러분이 떨어져 있는 API (gRPC, REST, SOAP, 그리고 심지어 GraphQL도 포함하여) 및 기타 데이터 의존성을 통합 인터페이스로 결합할 수 있는 능력을 제공합니다. 즉, 조직 내 모든 팀을 위한 단일 GraphQL 엔드포인트를 제공하고, 아마도 기업에서 GraphQL 채택을 촉진하는 사용 사례입니다. 단일 GraphQL 엔드포인트를 통해 여러분은 고유한 도전 과제를 직면하게 될 수 있는데, 이는 대부분의 개발자들이 절대로 경험할 수 없는 것들입니다: 확장성을 희생하지 않으면서 구성, 중앙 통제, 팀 독립성, 또는 변화하는 요구 사항에 대한 적응력 등이 있습니다.

연합 GraphQL 아키텍처를 사용하면 조직 데이터 "풀"에 추가된 모든 데이터가 즉시 모든 팀에서 사용할 수 있게 됩니다. Walmart, Zillow, Netflix와 같은 모든 기업들은 새로운 데이터 소스를 조직의 중앙 그래프에 포함시키기만 하면(물론, 이것은 다른 연합 GraphQL API일 수도 있습니다) 즉시 모든 팀이 쿼리하고 새롭고 흥미로운 비즈니스 사용 사례를 만들어내기 시작할 수 있습니다. 이 연합 아키텍처는 고유한 데이터 접근 정책, 유효성 검사, 인증 메커니즘 및 프로토콜, 그리고 감시 통제를 확립하고 시행하는 것을 가능하게 하며, 잠재적인 병목 현상을 파악하고 GDPR, HIPAA 등과 같은 산업 규제 준수를 보장하는 데 도움이 되는 것이죠.

GraphQL은 REST API의 대체재가 될만한 것이 아닌 고유한 공간을 조각내어 서비스합니다. 웹 개발이 발전하는 속도를 고려할 때, 몇 년 뒤에 여러분이 GraphQL의 고유한 강점과 완벽하게 일치하는 독특한 문제에 직면할 수도 있습니다. 심지어 프론트엔드 팀이 GraphQL 스키마를 사용하여 커스텀 디렉티브를 통해 회사의 기술 부채를 추적하는 예도 본 적이 있습니다. 즉, 이를 통해 백엔드 팀이 프론트엔드 코드베이스에 들어가지 않고도 리팩토링을 계획할 수 있었던 것이죠. 상당히 독특한 조직적인 사용 사례입니다.

죽어가는 기술로 소문난 기술로서 이것이 나쁘다고 할 수 있을까요?

미래를 내다보며

저기요, 이 글에서 중요한 건 GraphQL이 죽지 않았다는 것이라면서도 현재로서는 이러한 잠재적인 사용 사례가 정말 설득력이 없다는 걸 느끼신다면... 직감을 믿으세요.

만약 진정으로 원한다면 토크 렌치로 못을 박을 수도 있지만, 여러분이 향상된 인프라 투자나 이제부터 감수해야 할 운영 상의 어려움을 감수할 가치가 있을지는 의문입니다.

마찬가지로, CRUD 앱을 운영하는 소규모 팀이라면 REST API가 필요한 경우 GraphQL을 끼워 맞추지 않는 게 좋습니다 — 그리고 그 경우에는 OpenAPI REST가 당장 채택해야 할 "지루한" 기술입니다.

그러나 조직 또는 애플리케이션이 성장할 것으로 예상되면 다중 데이터 종속성이나 연합된 아키텍처를 예측할 수 있습니다. GraphQL을 채택하는 것이 전략적인 결정일 수 있습니다. 그리고 WunderGraph와 같은 도구가 이를 실현하는 데 도움이 될 수 있습니다.

WunderGraph는 하나가 아닌 두 제품이며, 어떤 제품을 선택할지는 현재 가장 긴급한 필요에 달려 있습니다.

WunderGraph Gateway

여러 다른 API를 관리해야 하는 경우, 각각의 스타일, 인증 프로토콜, 아키텍처를 갖는 다양한 API를 효과적으로 관리하고 싶다면 WunderGraph Gateway가 필요할 것입니다. WunderGraph Gateway는 여러분이 원하는 것입니다. 이것은 SQL/NoSQL DB(플래닛스케일과 같은 DBaaS도 포함됨), Prisma와 같은 ORM, SOAP, OpenAPI REST 또는 GraphQL API, Apollo 연합, OpenAuth, Auth0 등 OIDC/non-OIDC 호환 인증 공급자까지 여러분의 모든 다양한 데이터 원본을 통합할 수 있는 무료이며 오픈 소스 (Apache 2.0 라이센스) Backend-for-Frontend 프레임워크입니다. 이를 통해 이러한 데이터 소스를 모두 간단한 종속성 배열로 추가할 수 있고, 이를 기반으로 전체적으로 안전한 클라이언트를 생성할 수 있습니다.

WunderGraph은 개발 환경에서 GraphQL을 사용하여 모든 데이터 소스를 탐색하고 이를 단일 가상 그래프로 통합하여 원하는 데이터를 얻기 위해 GraphQL 연산을 정의합니다. 그리고 클라이언트로는 어떠한 GraphQL도 전달되지 않고 GraphQL 엔드포인트도 공개되지 않습니다. 대신 WunderGraph는 지속적인 쿼리를 사용합니다. 가상 그래프에 대한 작성한 임의의 GraphQL 연산은 해싱되고 서버에 저장됩니다. 클라이언트는 해당 해싱 이름을 호출하여 액세스할 수 있으며, WunderGraph BFF 서버에는 알려진 해시 목록이 있습니다. 사용자가 정의한 지속적인 쿼리 수만큼만 알려진 해시가 있으며, 클라이언트 요청에 대해 유효한 해시에만 응답하며 각 작업에 대해 고유한 엔드포인트로 제공합니다.

GraphQL의 채택 이점을 모두 누리면서 단점은 없앴습니다. 빠르고 효율적인 캐싱 전략과 공개 GraphQL API를 역공학하여 데이터베이스를 잠재적으로 유출하는 사용자를 방지할 수 있습니다.

WunderGraph Cosmo

만약 당신이 무엇을 하고 있는지 알고 있고, Federation V1/V2 아키텍처가 정말 원하는 것이라면 WunderGraph Cosmo가 딱입니다. 이것은 벤더 잠금이 없는 GraphQL Federation을 위한 오픈 소스 (Apache 2.0 라이선스) 플랫폼입니다. 모든 데이터의 제어권을 유지할 수 있는 완전 자체 호스팅 솔루션으로서, Apollo GraphOS의 대안인 오픈 표준을 기반으로 구축되어 있습니다. 대규모로 통합된 그래프를 구축, 관리 및 협업하려는 경우 필요한 모든 기능을 포함하고 있습니다. 스키마 레지스트리가 있어서 변경사항과 구성 오류를 확인할 수 있으며, 빠르고 효율적인 Federation V1/V2 호환 라우터, 그래프 시각화 및 피더레이션 GraphQL을 위한 분석/분산 추적 플랫폼이 포함되어 있습니다.

기업용 사례에서는 라이선싱 및 데이터 거버넌스(순응을 보장하기 위함)가 중요합니다. Cosmo가 OSI 승인 라이선스인 Apache 2.0에 따라 제공되며 완전히 자체 호스팅이 가능하기 때문에 엔터프라이즈에서 페더레이티드 GraphQL 채택을 위한 최적의 선택입니다. 더 좋은 점은 이미 Apollo Studio/GraphOS를 사용하고 있다면 페더레이티드 그래프를 관리하는 데 한 번의 클릭만으로 마이그레이션할 수 있습니다.

요약하자면...

GraphQL의 소멸에 관한 보고는 크게 과장되었습니다.

GraphQL이 안정적인 무역말을 하도록 변하는 것은 전혀 놀라운 일이 아닙니다. 이것이 성공이라는 것이죠. 새로운 기술이 지나치게 과대평가되던 시기를 겪은 뒤에 이를 극복하고, 생존하며 개발자의 무기함에 신뢰할 수 있는 도구로 자리 잡고, 특정한 실제 문제들을 해결하기 위해 노력합니다. GraphQL이 추세에서 평정기에 접어 들었다는 것을 인정하는 것은 그 하락의 선언이 아니라 그 성숙함에 대한 증거입니다.

사실 GraphQL은 다양한 API 스타일이 점점 더 보편화되면서 더욱 중요해지고 있습니다. GraphQL Federation의 능력은 다양한 API, 마이크로서비스, 데이터 소스를 통합하여 일관된 연합 구조로 만드는 데 거대한 잠재력을 갖고 있습니다. 규모 확장 시, Federation은 각 팀이나 서비스의 독립성을 희생하지 않고 공유 데이터 풀에 효율적으로 액세스할 수 있는 연결된 시스템을 구축하는 데 우리가 가진 최고의 도구입니다.

WunderGraph (Cosmo, 또는 Gateway와 같은)와 같은 OSI(Open Source Initiative)가 승인한 오픈 소스 도구는 기업들이 라이선스 장벽 없이 GraphQL을 채택할 수 있을 뿐만 아니라 데이터 거버넌스 및 분산 자율성을 유지하면서 다양하고 분리된 진화하는 기술과 함께 작업하기를 더 쉽게 만들어 줍니다.