BigQuery Graph 정식 출시
SQL 데이터웨어하우스에 GQL 그래프 분석이 들어온 이유
Google Cloud는 2026년 9월 1일 BigQuery Graph의 정식 출시(GA)를 발표했습니다. 이제 BigQuery의 관계형 테이블을 별도 그래프 데이터베이스로 복사하지 않고 속성 그래프로 정의한 뒤, 국제 표준 Graph Query Language(GQL)로 관계와 경로를 탐색할 수 있습니다.
기업 데이터의 중요한 질문은 한 행의 값만으로 답하기 어렵습니다.
- 의심 계좌와 연결된 다른 계좌는 무엇인가?
- 장애가 난 부품이 어떤 공급업체와 제품에 영향을 주는가?
- 여러 기기와 이메일이 실제로 같은 고객을 나타내는가?
- AI 에이전트가 내린 결정은 어떤 정보와 정책을 거쳤는가?
이런 질문은 데이터 사이의 연결과 경로를 이해해야 합니다. BigQuery Graph의 의미는 그래프 분석을 데이터웨어하우스 밖의 별도 사일로로 분리하지 않고, 기존 데이터·보안·분석 환경 안으로 가져왔다는 데 있습니다.
이 글은 Google Cloud의 2026년 9월 1일 공식 발표, BigQuery 기술 문서, ISO/IEC 39075:2024 GQL 표준 정보를 기준으로 작성했습니다. 발표에 포함된 대화형 분석과 에이전트 관련 기능 중 일부는 프리뷰이거나 순차 출시 중입니다.
1. 관계형 데이터와 그래프 데이터는 무엇이 다른가?
관계형 데이터베이스는 행과 열, 키와 조인으로 데이터를 표현합니다. 주문과 고객, 계좌와 거래처럼 구조가 명확한 업무에 강합니다.
그래프는 데이터를 노드(node)와 에지(edge)로 표현합니다.
| 그래프 요소 | 의미 | 예시 |
|---|---|---|
| 노드 | 분석할 개체 | 고객, 계좌, 제품, 공급업체 |
| 에지 | 개체 사이의 관계 | 소유한다, 송금한다, 구매한다, 공급한다 |
| 레이블 | 개체와 관계의 유형 | Customer, Account, Transfers |
| 속성 | 노드·에지의 세부 값 | 이름, 금액, 시간, 국가 |
예를 들어 고객과 공급업체의 관계를 찾으려면 관계형 SQL에서는 여러 테이블을 순서대로 조인해야 합니다. 그래프에서는 연결 패턴을 직접 표현합니다.
(고객)-[구매]->(제품)-[공급]->(공급업체)
관계 단계가 많고 탐색 깊이가 변하는 문제일수록 그래프 표현이 더 자연스럽습니다.
2. BigQuery Graph의 핵심: 데이터를 복사하지 않는 논리 그래프
BigQuery 문서에 따르면 property graph를 만들 때 원본 데이터가 이동하거나 복사되지 않습니다. 기존 테이블을 노드와 에지로 매핑하는 논리적 그래프 스키마가 생성됩니다.
기존 BigQuery 테이블
├─ Person
├─ Account
├─ Owns
└─ Transfers
↓
CREATE PROPERTY GRAPH
↓
FinGraph라는 논리적 속성 그래프
↓
GQL로 관계와 경로 탐색
원본 테이블의 데이터가 바뀌면 다음 그래프 질의는 최신 테이블 데이터를 기준으로 실행됩니다. 별도 그래프 저장소로 데이터를 복제하는 ETL 파이프라인과 동기화 지연을 줄일 수 있습니다.
간단한 정의는 다음과 같은 형태입니다.
CREATE OR REPLACE PROPERTY GRAPH graph_db.FinGraph
NODE TABLES (
graph_db.Person,
graph_db.Account
)
EDGE TABLES (
graph_db.PersonOwnAccount
SOURCE KEY (person_id) REFERENCES Person (id)
DESTINATION KEY (account_id) REFERENCES Account (id)
LABEL Owns,
graph_db.AccountTransferAccount
SOURCE KEY (from_id) REFERENCES Account (id)
DESTINATION KEY (to_id) REFERENCES Account (id)
LABEL Transfers
);
Person과 Account 테이블은 노드가 되고, 소유와 송금 테이블은 방향이 있는 에지가 됩니다.
3. SQL과 GQL을 왜 함께 사용하나?
ISO/IEC 39075:2024는 속성 그래프의 구조와 조작을 위한 GQL의 문법과 의미를 정의합니다. BigQuery는 이 표준 계열의 GQL을 SQL과 나란히 제공합니다.
SQL이 잘하는 일
- 대규모 집계와 통계
- 정형 보고서와 BI
- 필터, 그룹화, 윈도 함수
- 데이터 정제와 변환
GQL이 잘하는 일
- 여러 단계 관계 탐색
- 특정 연결 패턴 검색
- 두 개체 사이의 경로 추적
- 순환 구조와 네트워크 분석
- 이웃·연관 개체 확장
예를 들어 Dana가 송금한 상대를 찾는 질의는 다음처럼 관계 자체를 읽을 수 있습니다.
GRAPH graph_db.FinGraph
MATCH
(person:Person {name: "Dana"})-[:Owns]->
(account:Account)-[transfer:Transfers]->
(target:Account)<-[:Owns]-(receiver:Person)
RETURN
person.name AS sender,
transfer.amount AS amount,
receiver.name AS receiver;
BigQuery에서는 그래프 질의를 SQL 작업 흐름과 결합할 수 있습니다. 그래프로 의심 네트워크를 찾은 뒤 SQL로 금액을 집계하거나, BigQuery ML과 AI 함수를 같은 분석 과정에 연결할 수 있습니다.
핵심은 SQL을 대체하는 것이 아닙니다. 테이블 분석에는 SQL, 관계 탐색에는 GQL을 사용하고 결과를 다시 결합하는 것입니다.
4. 정식 출시에서 달라진 성능과 표현력
Google Cloud는 프리뷰 이후 경로 탐색 엔진을 개선했다고 발표했습니다.
- 공개 벤치마크 기준 GQL 실행이 프리뷰보다 2배 빨라졌습니다.
- 무방향 탐색은 프리뷰보다 최대 100배 향상됐다고 밝혔습니다.
- ACYCLIC과 TRAIL 경로 모드의 순환 감지가 더 빠르고 효율적으로 개선됐습니다.
- CALL 문과 확장된 서브쿼리를 이용해 복잡한 그래프 질의를 작은 단계로 나눌 수 있습니다.
- 반복되는 그래프 로직을 재사용 가능한 함수로 구성할 수 있습니다.
이 수치는 Google이 공개한 벤치마크 결과이므로 실제 데이터의 연결 밀도, 경로 길이, 슬롯과 예약 환경에서 자체 측정이 필요합니다. 그래프 질의는 연결이 많을수록 탐색 후보가 급격히 늘 수 있기 때문입니다.
5. 데이터웨어하우스 안에서 그래프를 실행하는 장점
기존 보안 정책을 이어서 사용
BigQuery Graph는 BigQuery의 행 수준·열 수준 보안 아래에서 실행됩니다. 별도 그래프 시스템으로 데이터를 내보내면서 접근 정책을 다시 만들고 동기화하는 부담을 줄일 수 있습니다.
ETL과 복제 감소
그래프가 원본 테이블의 논리적 뷰로 동작하므로 분석용 복제본을 계속 갱신하는 파이프라인이 필요하지 않습니다. 데이터 중복, 지연, 서로 다른 정답이 생기는 문제를 줄일 수 있습니다.
페타바이트 규모 분석과 결합
BigQuery의 분산 처리 기반에서 관계 탐색을 수행하고, 결과를 기존 SQL·ML·AI 워크로드와 연결할 수 있습니다. 전용 그래프 데이터베이스의 메모리에 전체 그래프를 올리는 방식과 다른 확장 경로입니다.
운영 도구 통합
BigQuery의 권한, 감사 로그, 비용 관리, 데이터 카탈로그를 계속 활용할 수 있습니다. 데이터 팀이 새로운 플랫폼을 별도로 운영해야 하는 범위를 줄입니다.
6. 대표 활용 사례
| 분야 | 그래프 질문 | 활용 예 |
|---|---|---|
| 금융·보안 | 의심 대상에서 몇 단계 안에 연결된 개체는? | 자금세탁 네트워크, 공격 경로 탐지 |
| 제조·물류 | 한 부품의 장애가 어디까지 전파되는가? | 공급망 디지털 트윈, 대체 경로 분석 |
| 유통·광고 | 흩어진 식별자가 같은 고객인가? | Customer 360, 아이덴티티 해석 |
| 통신·IT 운영 | 장애 서비스가 어떤 시스템에 의존하는가? | 네트워크 토폴로지, 데이터 계보 |
| 지식 관리 | 문서·사람·개념이 어떻게 연결되는가? | 지식 그래프, GraphRAG |
| AI 거버넌스 | 에이전트 결정이 어떤 도구와 정책을 거쳤는가? | 실행 추적, 감사 가능한 메모리 |
그래프가 유용한지는 데이터 크기보다 질문의 형태가 결정합니다. 행 하나를 조회하거나 단순 집계하는 문제라면 SQL이 더 간단합니다. 연결 단계가 많고 경로 자체가 의미를 가질 때 그래프의 가치가 커집니다.
7. AI 에이전트와 그래프의 결합
생성형 AI는 비정형 문서를 요약하는 데 강하지만, 기업의 정확한 관계와 제약을 스스로 보장하지 못합니다. 그래프는 에이전트에게 구조화된 연결 맥락을 제공합니다.
예를 들어 “배송이 지연된 고객의 제품을 공급한 업체와 국가를 알려 달라”는 질문은 다음 경로로 답할 수 있습니다.
고객
→ 구매한 제품
→ 제품 공급업체
→ 공급업체의 국가
모델이 관련 테이블을 매번 추측해 조인하는 대신, 미리 정의된 그래프 스키마와 관계를 따라가도록 만들 수 있습니다. 이 방식은 답의 근거 경로를 설명하기도 쉽습니다.
Google은 BigQuery의 conversational analytics가 자연어 질문을 SQL이나 GQL로 변환하고 탐색 경로를 시각화할 수 있다고 설명합니다. Gemini Enterprise와 MCP 서버를 연결하는 방식, 그래프 스키마 작성을 돕는 에이전트 스킬, 에이전트 실행 기록을 그래프로 남기는 context graph도 함께 소개했습니다.
다만 공식 발표는 이 생태계 기능 중 일부가 프리뷰 또는 순차 출시라고 명시합니다. 운영 환경에서는 기능별 제공 단계, 지역, 지원 조건을 따로 확인해야 합니다.
8. 크로스 클라우드 그래프의 가능성과 주의점
Google은 BigQuery Graph가 borderless Lakehouse를 통해 BigQuery 테이블과 다른 클라우드의 개방형 Iceberg 테이블을 하나의 가상 그래프로 연결할 수 있다고 소개했습니다. Databricks Unity Catalog, AWS Glue, Snowflake 등에 있는 데이터를 원래 위치에서 참조해 관계를 탐색하는 구조입니다.
이는 데이터를 한곳으로 복사하지 않고 멀티클라우드 지식 그래프를 구성할 가능성을 보여줍니다. 하지만 “데이터 이동 없음”이 곧 운영 부담 없음이라는 뜻은 아닙니다.
- 네트워크 지연과 외부 소스 가용성을 고려해야 합니다.
- 클라우드마다 권한과 감사 정책이 다릅니다.
- 스키마 변경이 그래프 정의를 깨뜨릴 수 있습니다.
- 데이터 위치와 처리에 관한 규제 요구를 확인해야 합니다.
- 질의 비용이 어느 시스템에서 발생하는지 추적해야 합니다.
- 캐시와 최신성 정책을 명확히 해야 합니다.
가상화는 복사를 줄이지만 분산된 시스템의 계약과 품질까지 자동으로 통일하지는 않습니다.
9. 설계할 때 놓치기 쉬운 위험
원본 스키마 변경을 BigQuery가 자동으로 막지 않는다
BigQuery 문서는 그래프가 의존하는 테이블이나 열을 삭제·변경해도 그래프 스키마의 무결성을 자동으로 보장하지 않는다고 설명합니다. 노드나 에지에 사용한 테이블을 바꾸기 전에 그래프 정의를 함께 수정해야 합니다.
키 제약은 선언돼도 강제되지 않는다
BigQuery는 primary key와 foreign key 정보를 질의 최적화에 사용할 수 있지만 이를 강제로 검사하지 않습니다. 데이터가 실제로 유일성과 참조 무결성을 만족하지 않으면 잘못된 결과가 나올 수 있습니다.
그래프 도입 전에 다음 품질 검사가 필요합니다.
- 노드 키의 중복 여부
- 에지의 출발·도착 노드 존재 여부
- 관계 방향과 의미의 일관성
- 삭제된 개체를 가리키는 고아 에지
- 시간에 따라 바뀌는 관계의 유효 기간
모든 열을 속성으로 노출하면 비용이 커질 수 있다
Google은 필요한 속성만 명시하고 PROPERTIES ALL COLUMNS 사용을 피하도록 권장합니다. 노드와 에지에 불필요한 열을 많이 넣으면 그래프 질의에서 컬럼 스캔이 증가하고 성능이 떨어질 수 있습니다.
그래프가 정답을 자동으로 만들지는 않는다
그래프는 정의한 관계를 빠르게 탐색합니다. 잘못 정의한 관계, 오래된 마스터 데이터, 부정확한 엔터티 연결은 더 빠르게 잘못된 결론을 만들 수 있습니다. 스키마 설계와 데이터 품질이 모델 선택보다 먼저입니다.
10. 도입 순서
1단계: 관계 중심 질문 하나를 선택한다
“그래프를 써 보고 싶다”보다 다단계 관계 때문에 SQL이 복잡하거나 느린 업무 질문을 고릅니다. 사기 탐지, 공급망 영향 분석, 시스템 의존성처럼 결과의 가치를 측정할 수 있어야 합니다.
2단계: 노드와 에지의 의미를 정의한다
ER 다이어그램을 그대로 그래프로 옮기지 말고 업무에서 탐색할 개체와 관계를 선정합니다. 에지의 방향, 시간 범위, 생성 근거도 문서화합니다.
3단계: 키와 데이터 품질을 검증한다
BigQuery의 키 제약이 자동 강제되지 않는다는 전제로 중복, 누락, 고아 관계를 검사하는 데이터 품질 작업을 먼저 만듭니다.
4단계: 작은 속성 집합으로 시작한다
질의에 필요한 속성만 노출하고 스캔량과 슬롯 사용량을 측정합니다. 자주 사용하는 패턴부터 재사용 가능한 함수로 정리합니다.
5단계: 기존 SQL 결과와 비교한다
동일한 업무 질문을 기존 조인 방식과 GQL 방식으로 실행해 정확도, 지연, 비용, 유지보수성을 비교합니다.
6단계: 보안과 감사 경로를 점검한다
행·열 수준 정책이 그래프 질의에서도 기대대로 적용되는지 테스트합니다. AI 에이전트를 연결한다면 자연어 질문, 생성된 GQL, 조회 결과, 최종 답변을 하나의 감사 기록으로 남깁니다.
11. 실무 체크리스트
- 관계 탐색이 실제 업무 병목인지 확인했는가?
- 노드와 에지의 업무 의미가 문서화돼 있는가?
- 노드 키의 유일성과 에지 참조 무결성을 검증하는가?
- 원본 테이블의 스키마 변경과 그래프 정의를 함께 배포하는가?
- 필요한 속성만 그래프에 노출했는가?
- 순환·가변 길이 경로의 탐색 범위에 상한이 있는가?
- GQL과 기존 SQL 결과를 표본 데이터로 비교했는가?
- 행·열 수준 보안이 기대대로 적용되는지 시험했는가?
- 슬롯 사용량, 처리 바이트, 지연을 함께 관측하는가?
- 멀티클라우드 소스의 장애와 스키마 변경에 대비했는가?
- 에이전트가 생성한 GQL을 실행 전에 검증하는가?
- 프리뷰 기능을 운영 핵심 경로에 사용할 때 대체 수단이 있는가?
결론
BigQuery Graph의 정식 출시는 그래프 분석이 별도의 전문 데이터베이스에만 머물지 않고 데이터웨어하우스의 기본 분석 방식으로 들어오고 있음을 보여줍니다.
가장 큰 장점은 기존 테이블을 복사하지 않고 논리적 속성 그래프로 정의해 SQL 집계와 GQL 관계 탐색, BigQuery ML·AI 기능, 기존 보안 정책을 한 환경에서 결합할 수 있다는 점입니다. 사기 네트워크, 공급망, 고객 식별, 시스템 계보, AI 에이전트의 근거 추적처럼 관계가 핵심인 문제에서 특히 유용합니다.
그러나 그래프 기능이 데이터 품질과 모델링 책임을 대신하지는 않습니다. 키 제약이 실제 데이터에서 지켜지는지, 관계가 올바르게 정의됐는지, 탐색 비용이 통제되는지, 원본 스키마 변경이 함께 관리되는지를 먼저 확인해야 합니다.
앞으로의 데이터 엔지니어는 SQL과 GQL 중 하나를 선택하는 사람이 아니라, 행 중심 분석과 관계 중심 분석을 같은 데이터 기반에서 연결하는 설계자가 되어야 합니다.
참고 자료
- Google Cloud Blog, BigQuery Graph is now GA (2026-09-01)
- Google Cloud Docs, BigQuery Graph query overview
- Google Cloud Docs, Create and query a graph
- Google Cloud Docs, Graph schema overview
- Google Cloud Docs, GQL schema statements
- Google Cloud Docs, GQL query statements
- ISO, ISO/IEC 39075:2024 — Database languages — GQL
서비스 제공 단계, 지원 지역, 예약 에디션과 가격은 변경될 수 있습니다. 실제 도입 전에는 Google Cloud의 최신 문서와 콘솔 표시를 함께 확인해야 합니다.