Orbital, Hasura, 그리고 Apollo는 모두 유사한 기능을 수행합니다. 하지만 에이전트가 소프트웨어의 대부분을 작성할 때, 이들 중 어떤 것을 선택할지는 여러분에게 결정됩니다. 여기에서 여러분의 에이전트가 선호하는 도구와 그 이유를 알아봅니다.
Claude Code를 사용하여, 저희는 4단계에 걸쳐 해당 도구들의 agent experience (AX)를 평가하기 위해 자체 audit method을 따랐습니다.
AX 감사(Audit)의 네 가지 단계
이 감사는 개발자가 에이전트와 함께 거치는 깔때기(funnel)를 따라 진행됩니다:
Awareness → Discoverability → Reputation → Integration
저희는 도구 없이 모델이 알고 있는 것부터 시작하여, 웹 검색 및 fetch를 통한 온라인 발견 및 추천을 테스트했고, 마지막으로 전체 도구 세트를 사용한 작동하는 통합(integration)을 시도했습니다. 원문 기사에서 인터랙티브 감사 다이어그램과 정확한 프롬프트를 확인하세요.
- Awareness: 모델이 도구 없이도 이미 제품에 대해 알고 있는가?
- Discoverability: 온라인에서 검색했을 때 제품을 찾아내는가?
- Reputation: 대안보다 해당 제품을 추천하며, 사실 관계를 정확히 전달하는가?
- Integration: 작고 작동 가능한 통합을 구축하고 검증할 수 있는가?
각 단계는 1부터 4까지의 점수를 받습니다: **GOOD (4)**은 마찰이 적다는 의미; **OK (3)**는 사소한 격차가 있다는 의미; **POOR (2)**는 상당한 격차를 가진 부분적인 결과라는 의미; **FAIL (1)**은 제품을 알 수 없거나 작업이 작동하지 않는다는 의미입니다.
**테스트 방법
**
모든 테스트는 2026년 10월 13일~14일에 Claude Code 2.1.287의 Claude Opus 5.5(claude-opus-5-5)를 사용하여 진행되었습니다. 모든 세션은 감사 컨텍스트(audit context)나 사용자 맞춤 설정이 없는 새로운 폴더에서 시작되었습니다. 각 통합 과정에서는 자체적인 새 Claude Code 프로필과 제공된 테스트 데이터가 포함된 폴더를 사용했습니다. 이 프로필들은 MCP 서버를 로드하지 않았으며, 내장 스킬 및 플러그인만 사용했고, 모든 명령어는 저희가 승인했습니다. 인식(Awareness) 질문은 도구 없이 실행되었고, 발견 가능성(discoverability) 및 평판(reputation) 질문에는 웹 검색과 웹 가져오기(web fetch) 기능만 사용되었습니다. 각 프롬프트는 한 번씩 실행했으므로, 이 결과들은 벤치마크라기보다는 한 개발자의 경험으로 간주해 주십시오.
저희는 Orbital의 역할과 대안에 대한 여섯 가지 질문을 던지고, 그 답변들에서 가장 많이 언급된 제품들을 바탕으로 Hasura와 Apollo GraphQL을 선택했습니다. 두 제품 모두 여섯 가지 답변에 등장했습니다. WunderGraph Cosmo도 등장했지만, 저희가 Apollo를 선택한 이유는 Orbital 자체 비교 페이지에서 Apollo가 같은 GraphQL 도구들과 비교되기 때문입니다. 공유된 질문들은 Orbital의 문제점(REST API, 데이터베이스, Kafka에 분산된 데이터)을 설명하므로, 다른 두 제품보다 Orbital에 더 적합합니다.
Orbital, Hasura 및 Apollo GraphQL이란 무엇인가요?
세 가지 모두 앱이나 에이전트가 여러 시스템에 걸쳐 존재하는 데이터를 하나의 API로 요청할 수 있게 해줍니다.
Orbital은 사용자의 기존 API, 데이터베이스, 메시지 스트림 앞에 위치합니다. 각 시스템의 데이터가 무엇을 의미하는지 한 번만 설명하면, 원하는 데이터를 Orbital에 요청하고, Orbital이 어떤 시스템을 호출해야 할지 파악하여 결과를 결합해 줍니다. 저희 Orbital 빠른 시작 가이드에서 작동 방식을 더 자세히 다루고 있습니다.
Hasura는 데이터베이스와 API를 하나의 GraphQL API로 변환하며, 이 회사는 현재 AI 에이전트 제품인 PromptQL도 판매하고 있습니다. Apollo GraphQL은 여러 서비스를 하나의 API로 결합하는 라우터(router)나 코딩 없이 REST API를 매핑하는 커넥터(Connectors)를 포함하여 널리 사용되는 GraphQL 도구들을 만듭니다.
한눈에 보는 결과
-
🥇 Hasura (1st) — 에이전트에 의해 알려지고 발견됨; 브라우저 로그인 후 자격 증명(credentials)을 검색하고 스크립트를 실행함.
-
🥈 Apollo GraphQL (2nd) — 에이전트에 의해 알려지고 발견됨; 우리가 로그인하고 키를 생성한 후 스크립트를 실행함.
-
🥉 Orbital (3rd) — 명명된 대결(head-to-heads)에서 승리함; 프롬프트 없이 발견된 적이 없고, 스크립트가 인증 단계에서 멈춤.
| Stage | Orbital | Hasura | Apollo GraphQL |
|---|
| Awareness | OK (3) | GOOD (4) | GOOD (4) |
| ... | | | |
| 평균값은 반올림되지 않았습니다. Hasura가 1위를 차지한 이유는 에이전트가 브라우저 로그인 후 자격 증명을 얻었기 때문이며, Apollo는 우리가 키를 생성하도록 필요했습니다. | | | |
Orbital 대 Hasura 대 Apollo GraphQL: 무엇을 선택해야 할까요?
에이전트의 추천은 사용자의 데이터에 따라 달라졌습니다: "코드 없이 Kafka를 포함한 혼합 소스를 결합하려면 Orbital을 사용하고, 주로 SQL 데이터베이스 위에 즉각적인 API가 필요하면 Hasura를 사용하며, 여러 팀이 소유한 GraphQL 서비스를 연합(federate)하려면 Apollo를 사용하세요."
에이전트들은 데이터에 Kafka 토픽이 포함되어 있고 각 시스템마다 코드를 작성하지 않고 조인(joins)을 원할 때 Orbital을 선택했으며, 이 근거로 모든 대결에서 승리했습니다. Orbital을 명시적으로 언급하고, 스크립트 인증을 직접 확인해야 할 준비를 하세요: 저희 에이전트는 Orbital을 설치했지만 제공한 키로는 데이터를 가져올 수 없었습니다.
에이전트들은 "데이터가 주로 관계형(relational)이고 그것 위에 빠르고 자동 생성된 GraphQL API를 원하는 경우" Hasura를 추천했습니다. Apollo와 비교했을 때, 에이전트는 한 순서에서는 Hasura를 선호했고 다른 순서에서는 어느 쪽도 선호하지 않았습니다. 저희 에이전트는 Hasura DDN을 사용하여 브라우저 로그인 후 토큰을 검색했으며, Hasura Cloud에 인증하고 로컬 고객 및 주문 데이터를 가져오는 스크립트를 실행했습니다. 로컬 데이터 쿼리는 토큰을 사용하지 않았습니다. 위험성에 대해 질문했을 때, 에이전트는 Hasura가 자사의 AI 제품인 PromptQL로 전환하는 것에 대해 언급했습니다.
에이전트들은 "사용자가 GraphQL를 원할 때" 또는 "소스가 주로 REST일 때" Apollo를 선호했으며, "커뮤니티가 훨씬 크고 채용하기 쉽다"고 언급했습니다. 이 도구는 추가 서비스 없이는 데이터베이스나 Kafka에 연결하지 못하며, 이것이 Orbital과의 두 번의 대결(head-to-heads) 모두에서 패배한 이유입니다. 저희가 로그인하고 개인 키를 생성한 후, 에이전트는 이를 사용하여 GraphOS 계정 정보를 쿼리했고 또한 로컬 고객 및 주문 데이터도 쿼리했습니다. 로컬 라우터는 자격 증명(credentials)을 사용하지 않았습니다.
인식 (Awareness): 모델은 Orbital에 대해 알고 있는가?
인식 테스트는 웹 검색 없이 오직 훈련 데이터만으로 모델이 무엇을 알고 있는지 확인하는 것입니다.
-
Orbital: 좋음 (OK, 3/4) — 데이터 게이트웨이(data gateway)로 알고 있음; "관리되는 컨텍스트 레이어(governed context layer)"는 모름; 프롬프트 없이 언급된 적 없음
-
Hasura: 좋음 (GOOD, 4/4) — 정확하며, 검색 없이 Orbital의 역할에 대해 언급됨
-
Apollo GraphQL: 좋음 (GOOD, 4/4) — 정확하며, 검색 없이 Orbital의 역할에 대해 언급됨
저희는 먼저 어떤 제품명도 언급하지 않고 Orbital의 역할을 설명했습니다. 앱과 AI 에이전트가 통합 코드 없이 REST API, 데이터베이스 및 Kafka 전반에 걸쳐 데이터를 쿼리할 수 있게 해주는 도구를 물었을 때, 모델은 Hasura, Apollo, WunderGraph Cosmo 등을 언급했습니다. 저희가 Orbital의 주요 기능을 가진 자체 호스팅 레이어(self-hosted layer)를 설명했을 때는 Grafbase를 선택했으며, 대안으로 Hasura DDN과 Apollo를 제시했습니다. 이 답변들 어디에도 Orbital은 등장하지 않았습니다.
그런 다음 도구 없이 새로운 세션에서 각 제품의 도메인과 함께 이름을 언급했습니다: "Orbital(orbitalhq.com)이란 무엇인가?", 그리고 Hasura(hasura.io)와 Apollo GraphQL(apollographql.com)에 대해서도 같은 질문을 했습니다. 모델은 세 가지 모두를 정확하게 설명했습니다:
| Company | Answer (excerpt) |
|---|
| Orbital | "Orbital (orbitalhq.com)은 데이터 통합 플랫폼으로, 때로는 '데이터 게이트웨이' 또는 '글루 코드(glue code) 없는 통합'으로 설명됩니다. 이는 이전에 Vyne을 구축했던 팀에서 나왔으며, Orbital은 본질적으로 Vyne의 후속작입니다." |
| ... | |
| For Orbital에 대해서는 쿼리 언어인 Taxi, API 및 데이터베이스와 Kafka 전반의 조인(joins), 그리고 자체 호스팅(self-hosted) Docker 설정에 대해 설명했지만, AI 에이전트나 MCP에 대한 언급은 없었습니다. Apollo에 대해서는 Apollo MCP Server를 언급했습니다. | |
다음으로 도메인 없이 각 회사의 웹사이트에서 슬로건을 가져와 사용해 보았습니다. Orbital에 대한 질문은 다음과 같았습니다: "'거버넌스된 컨텍스트 레이어(governed context layer)'인 Orbital에 대해 무엇을 알고 있습니까? 이것이 무엇을 하는 것이며 누구를 위한 것입니까? 모르면 명확하게 말해주세요." Hasura와 Apollo의 버전에서는 자체 이름과 슬로건을 바꿔서 사용했습니다. Orbital의 홈페이지는 "기존 API, 데이터베이스 및 스트림을 거버넌스된 컨텍스트 레이어로 변환"이라고 설명했지만, 모델은 이 구절을 Orbital과 연결하지 못했습니다:
| Company | Tagline | Answer (excerpt) |
|---|
| Orbital | "governed context layer" | "이것이 무엇인지 모르겠습니다. '거버넌스된 컨텍스트 레이어'로 설명되는 'Orbital'이라는 제품에 대한 신뢰할 수 있는 정보가 없기 때문에, 이것이 무엇을 하는지 또는 누구를 위한 것인지 말씀드릴 수 없습니다." |
| ... | | |
| For Orbital의 경우, 여러 관련 없는 'Orbital'이라는 이름의 지리 공간 분석 회사(geospatial analytics company)인 Orbital Insight를 나열했습니다. Hasura와 Apollo에 대해서는 어느 쪽이든 제품을 정확하게 설명했습니다. | | |
노트북에서 Orbital을 사용하여 두 개의 REST API를 조인하는 방법을 묻자, 모델은 올바른 설정 형태를 제시했습니다: Docker, 공유 고객 ID 유형을 가진 Taxi 프로젝트, 그리고 쿼리였습니다. 첫 번째 명령어는 해당 주소가 Orbital의 런처 스크립트를 제공함에도 불구하고 https://start.orbitalhq.com을 Docker Compose 파일로 저장했습니다. 또한, 최초 시작 시 Orbital에 필요한 로그인 절차도 언급하지 않았습니다.
선택할 때 이것이 의미하는 바는
웹 검색 없이 에이전트는 이 작업에 Hasura나 Apollo를 제안합니다. 만약 Orbital을 고려하게 하고 싶다면, 그 이름을 언급해야 합니다. 모델은 이를 데이터 게이트웨이(data gateway)로 알고 있으며, 이는 Orbital의 문서가 설명하는 방식이지만, 홈페이지에서 설명하는 '거버넌스된 컨텍스트 레이어(governed context layer)'라는 설명으로는 알지 못합니다.
발견 가능성: 에이전트가 Orbital을 찾을 수 있을까?
발견 가능성은 웹 검색 기능을 가진 에이전트가 유사한 도구를 찾으면서 특정 제품을 찾아낼 수 있는지 테스트하는 것입니다. 우리는 두 가지 인지 질문(awareness questions)을 웹 검색으로 반복했으며, 이후 광범위한 문제를 Orbital로 좁혀 들어가는 6개 문항의 퍼널(funnel) 테스트를 두 번 실행했습니다. 처음 네 개의 질문은 세 회사 모두에게 동일했습니다. 각 퍼널은 5번 질문에서 분기되었는데, 이때 해당 회사의 태그라인을 사용한 제품을 요청했고, 6번 질문에서 회사 이름을 언급하도록 했습니다.
-
Orbital: 실패 (FAIL) (4개 중 1회) — 두 퍼널 모두 이름으로만 찾았으며, 태그라인 검색 시 Cube가 발견되었습니다.
-
Hasura: 성공 (OK) (4개 중 3회) — 1번 또는 3번 질문에서 이름으로 언급되었고, 태그라인 검색 시 두 번 모두 발견되었습니다.
-
Apollo GraphQL: 성공 (OK) (4개 중 3회) — 1번 또는 3번 질문에서 이름으로 언급되었으며, 태그라인 검색 시 한 번 발견되었습니다.
웹 검색을 사용했을 때도 에이전트는 Hasura와 Apollo를 다시 언급했지만, Orbital은 그렇지 못했습니다. 하나의 질의는 Orbital의 설명과 근접했습니다: self-hosted GraphQL federation REST databases Kafka no resolvers field-level authorization 2026. 이에 대한 답변은 어떤 도구도 상위 API 변경 사항(upstream API changes)을 흡수하지 못한다고 말했습니다:
Request and response about a self-hosted data layer and upstream API changes
퍼널 A는 마이크로서비스 간의 접착 코드(glue code)에 지친 플랫폼 엔지니어를 목표로 했고, 퍼널 B는 AI 에이전트를 구축하는 팀을 따라갔으며, 이 청중은 현재 Orbital의 홈페이지가 이야기하고 있는 대상입니다. 여기는 각 답변 시작 부분과 함께 Orbital 브랜치에서의 퍼널 B 내용입니다:
Discovery funnel step 1
Discovery funnel step 2
Discovery funnel step 3
Discovery funnel step 4
Discovery funnel step 5
Discovery funnel step 6
질문 4에서 에이전트는 "context layer" OR "data gateway" for AI agents startup launch 2026 governed access internal systems라는 구문을 검색했습니다. 이 구문은 Orbital의 두 가지 설명을 모두 사용했지만, Orbital 자체는 찾지 못했습니다. 질문 5에서는 Orbital의 태그라인이 Cube로 이어졌고, Cube의 AI Context Layer 페이지에는 "Cube가 귀하의 AI 에이전트에게 통제된 컨텍스트 레이어(governed context layer)를 제공합니다"라고 명시되어 있습니다. Funnel A의 태그라인 검색 역시 같은 방식으로 진행되었으며, Cube, Starburst, Denodo, 그리고 Atlan을 나열했습니다:
