BigQuery Graph 정식 출시와 에이전트 문맥 경로 설계

1. ‘무엇이 새로 정식 출시됐나?’ 표와 관계를 같은 창고에서 다루는 선택지

Google Cloud는 2026년 9월 1일 BigQuery Graph의 정식 출시(GA, 일반적으로 운영 환경에서 사용할 수 있다고 제공자가 밝힌 상태)를 발표했다. 발표문에 따르면 BigQuery 안에서 ISO 표준 그래프 질의 언어인 GQL(Graph Query Language)을 SQL과 나란히 쓰고, 테이블을 별도 그래프 데이터베이스로 옮기는 ETL 없이 관계를 따라갈 수 있다. ETL은 데이터를 꺼내고, 모양을 바꾸고, 다른 곳에 넣는 작업이다. 이 과정이 줄면 복사본과 동기화해야 할 곳도 줄 수 있다.

하지만 ‘정식 출시’라는 말이 모든 관련 기능이 같은 상태라는 뜻은 아니다. Google의 발표문은 그래프 엔진과 GQL 사용을 GA로 소개하는 한편, 에이전트가 그래프를 만들도록 돕는 일부 기능은 앞으로 순차 제공된다고 구분한다. 따라서 지금 시스템 설계에 넣을 때는 문서에서 각 기능의 출시 상태를 따로 확인해야 한다. 정식 제품의 이름만 보고 미리보기 기능까지 운영 약속으로 계산하면 안 된다.

왜 이 변화가 중요한가? 관계형 표는 주문, 고객, 상품처럼 칸과 행을 잘 정리한다. 그런데 “이 고객의 지연 주문은 어느 공급자와 연결되고, 그 공급자는 어느 지역에 있나?”처럼 여러 번 건너야 하는 질문은 조인이 길어지고 읽기 어려워질 수 있다. 그래프는 이때 사람·주문·상품·공급자 같은 대상을 노드로, 구매·공급 같은 연결을 간선으로 놓고 길을 찾는다. 지하철 노선도에서 역은 노드, 역 사이 선은 간선이라고 생각하면 쉽다.

BigQuery Graph는 기존 BigQuery의 행·열 수준 보안도 이어받는다고 발표됐다. 이것은 권한 설계가 자동으로 완성된다는 뜻은 아니다. 그래프 경로는 여러 테이블을 지나므로, 한 경로가 보여 주는 조합 정보가 기존 정책과 맞는지 검토해야 한다. 다음 절에서 그래프의 출발점인 노드와 간선의 계약을 살펴보자.

2. ‘그래프는 SQL을 대신하나?’ 질문의 모양이 다를 때만 경로를 쓴다

그래프가 관계형 모델보다 항상 더 좋은 것은 아니다. 어제의 주문 총액은 얼마인가처럼 묶고 더하는 질문은 SQL이 자연스럽다. 반면 의심 계정과 세 단계 안에 연결된 결제 수단은 무엇인가처럼 길과 이웃을 묻는 질문은 그래프가 읽기 쉬울 수 있다. 좋은 선택은 유행어가 아니라 질문의 모양에서 시작한다.

BigQuery Graph에서 노드는 보통 기존 테이블의 한 행을 바탕으로 만들고, 간선도 관계를 담은 테이블 행에서 만든다. 그래서 가장 중요한 설계는 그래프 화면이 아니라 계약이다. Customer 노드의 키는 무엇인지, Bought 간선은 어느 고객에서 어느 상품으로 가는지, 삭제된 계정의 연결은 언제 사라지는지 정해야 한다. 이름이 비슷한 두 고객을 같은 사람으로 잘못 잇는 순간, 멋진 경로 탐색은 틀린 답을 더 빨리 만드는 도구가 된다.

[노드 테이블]                  [간선 테이블]                 [질문]
고객 C1, 상품 P7, 공급자 S4  →  C1-구매-P7, P7-공급-S4  →  C1의 공급자는 누구인가?

Google은 GA에서 비순환·무방향 탐색을 최적화했고, 공개 벤치마크 기준으로 GQL은 미리보기 때보다 2배, 무방향 탐색은 100배 빨라졌다고 밝혔다. 이 숫자는 모든 데이터와 모든 질의에서 같은 결과가 난다는 약속이 아니다. 발표문이 말한 특정 경로 유형과 공개 벤치마크의 비교 결과다. 독자 시스템에서는 데이터 크기, 연결 수, 파티션, 권한 필터가 다르므로 대표 질문을 골라 직접 비교해야 한다.

여기서 홉은 연결선 하나를 건너는 횟수다. 친구의 친구를 찾는 것은 두 홉이다. 어린아이에게 “세 다리 건너 친구”라고 말하듯, 홉 수를 제한하면 질문의 범위를 작게 만들 수 있다. 제한이 없으면 아주 촘촘한 그래프에서 답이 너무 많아지거나 비용과 지연이 커질 수 있다. 다음 이미지는 이 계약이 실제 경로를 어떻게 만들고, 잘못된 간선을 어디에서 막아야 하는지 보여 준다.

3. ‘에이전트가 그래프를 읽게 해도 될까?’ 답보다 근거 경로를 먼저 남긴다

▲ 그래프는 많은 연결을 보여 주지만, 신뢰는 연결을 많이 그리는 데서 나오지 않는다. 어떤 연결이 허용되고 어떤 연결이 막히는지 분명히 할 때 나온다.

BigQuery Graph의 발표는 그래프를 에이전트의 문맥, 즉 답을 만들 때 참고하는 연결 정보로 쓰는 방향도 제시한다. 자연어로 묻고 그래프를 탐색하는 기능, MCP 서버를 통한 연결, 행동 기록을 문맥 그래프로 남기는 방향이 함께 언급된다. 다만 앞서 말했듯 기능마다 GA·미리보기·순차 제공 상태가 다를 수 있다. 운영에 넣기 전에는 현재 문서의 상태와 지원 범위를 다시 확인해야 한다.

에이전트가 “지연 주문의 공급자는 어디인가?”에 답하는 장면을 생각해 보자. 좋은 답은 공급자 이름만 보여 주지 않는다. 고객→주문→상품→공급자로 이어진 경로와, 각 연결이 어느 시점의 어떤 테이블에서 왔는지 다시 확인할 수 있어야 한다. 그래야 사람이 답을 검토하거나, 연결이 틀렸을 때 고칠 곳을 찾을 수 있다. 이를 근거 경로라고 부르자. 말 그대로 답까지 걸어간 발자국이다.

그래프를 만드는 에이전트에도 같은 원칙이 필요하다. 발표문은 데이터셋과 문서를 바탕으로 노드·간선을 제안하고, 관계별 일치율을 보여 주는 기능을 순차 제공한다고 설명한다. 제안은 출발점일 뿐이다. 예를 들어 일치율이 높아도 키가 공유 사서함처럼 애매하다면 사람의 검토가 필요하다. 숫자는 “관계가 진짜다”라는 도장이 아니라, 어디를 먼저 확인할지 알려 주는 표지판이다.

4. ‘별도 그래프 DB를 바로 없애도 될까?’ 데이터 이동이 줄어도 운영 질문은 남는다

BigQuery Graph가 ‘데이터를 옮기지 않고’ 탐색할 수 있다고 말하는 장점은 분명하다. 복사 파이프라인을 줄이면 지연된 복사본, 별도 권한, 동기화 실패를 줄일 기회가 생긴다. 그러나 모든 그래프 워크로드가 같은 방식으로 맞는다는 뜻은 아니다. 실시간 트랜잭션에서 아주 낮은 지연으로 그래프를 갱신하고 탐색해야 하는지, 분석용 대규모 탐색이 중심인지에 따라 선택은 달라진다.

Google도 BigQuery Graph와 Spanner Graph를 함께 언급한다. 이를 단순히 ‘더 좋은 제품’의 관계로 보면 안 된다. 저장 위치, 갱신 방식, 지연 목표, 사용자가 묻는 질문이 다르기 때문이다. 팀은 기존 그래프 시스템을 급하게 지우기보다, 가장 많이 쓰는 경로 질문 하나를 두 환경에서 비교하고 이전 비용을 계산하는 편이 낫다.

5. ‘이번 주에 무엇을 시험할까?’ 한 경로·한 권한·한 근거부터 시작하기

BigQuery Graph의 GA는 데이터 웨어하우스가 표를 계산하는 곳에서, 관계의 길을 묻는 곳까지 넓어지고 있음을 보여 준다. 그렇다고 모든 표를 노드와 간선으로 바꿀 필요는 없다. 이 기술이 가장 빛나는 곳은 이미 가진 데이터에서 ‘누가 누구와 어떤 경로로 이어지는가’를 믿을 만하게 답해야 하는 질문이다.

먼저 한 개의 경로를 고르자. 그리고 노드 이름, 간선 방향, 권한, 갱신 시각, 근거 경로를 종이에 적어 보자. 그래프의 가치는 연결을 많이 만드는 데 있지 않다. 필요한 연결만 정확하게 남기고, 틀린 연결은 멈추게 하는 데 있다.

에이전트가 더 많은 데이터를 읽게 하는 것보다 중요한 일은, 어떤 관계를 믿고 어떤 관계를 멈출지 먼저 정하는 것이다.

공식 참고 자료

• Google Cloud Blog: BigQuery Graph is now GA