빅쿼리 measures 사용법: 지표를 중복 없이 집계하는 정의·쿼리 순서

빅쿼리 measures는 무엇이고 어디에 쓰나

빅쿼리 measures는 매출 합계나 주문 수 같은 계산식을 한 번만 적어 두고, 쿼리를 쓸 때마다 그 이름만 불러 쓰는 기능이다. 구글이 2026년 10월 28일 정식 출시(GA)했다. 쓰는 방법은 세 단계다. 그래프를 만들 때 계산식에 이름을 붙이고, 쿼리에서 그 그래프를 펼친 다음, 이름을 불러 집계한다. 실제로 쿼리를 돌린 화면은 아래 "따라 하는 방법"에서 보여 준다.

표를 이어 붙인 쿼리에서 합계가 갑자기 부풀어 오른 적이 있다면 이 기능이 필요한 경우다. 용돈 장부에서 부모가 준 용돈 한 건을 아이 세 명의 표와 이어 붙이면 그 한 건이 세 줄로 늘어나고, 합계를 내면 세 배가 된다. measures는 "이 값은 주문 번호 하나당 한 번만 센다"는 규칙을 계산식에 미리 적어 두기 때문에 줄이 늘어나도 합계가 그대로다. 빅쿼리도 같은 방식으로 적어 둔 규칙대로만 계산한다. 다만 빅쿼리 그래프(Property Graph)로 만든 데이터에만 해당하고, 일반 테이블 쿼리의 SUM을 바꿔 주는 기능은 아니다.

구글 클라우드는 2026년 10월 28일 블로그에서 AI 에이전트가 자신 있게 틀린 답을 내는 문제를 풀려고 빅쿼리에 measures를 도입했고 이제 정식 출시(GA)됐다고 밝혔다. 그래프 measures는 4월 22일 릴리스 노트에 프리뷰로 먼저 올라왔다. 대시보드와 AI 에이전트가 같은 지표 정의를 쓰게 되므로, 지표 계산식을 쿼리마다 따로 적어 온 데이터 담당자는 이 기능으로 모을 수 있는지 확인해 볼 만하다.

measures가 막아 주는 과다 집계

도시별 주문 상품 수를 구하는 상황을 보자. 일반 JOIN 뒤 SUM은 주문이 여러 행으로 복제되면 같은 값을 여러 번 더한다. measures는 주문 한 건을 한 번만 센다.

구글 문서에 따르면 measure는 노드 또는 엣지 테이블의 KEY를 기준으로 집계를 정의한다. 그래프를 따라 테이블을 이어 붙이면 행이 복제되는데, KEY 기준으로 집계하므로 복제된 행이 합계를 키우지 않는다. 문서가 지원하는 집계 함수는 SUM, AVG, COUNT, MIN, MAX이고, 같은 테이블의 다른 measure를 조합하는 파생 measure에는 AGG를 쓴다.

구분	일반 JOIN 뒤 SUM	measures
집계 기준	이어 붙인 결과의 모든 행	정의한 테이블의 KEY
행이 복제되면	같은 값이 여러 번 더해진다	복제와 상관없이 한 번만 센다
계산식을 두는 곳	쿼리마다 따로 작성	그래프 정의 안에 한 번

구글의 프리뷰 소개 글은 이를 "그래프 경로를 먼저 풀고 나서 지표를 계산한다"고 설명한다. 같은 글은 평면 테이블만 본 에이전트가 겨울 재킷 매출이 시애틀에서 12% 줄었다는 사실은 알려 줘도, 주문에서 물류센터, 공급업체로 이어지는 원인 경로는 모른다는 예를 든다.

따라 하는 방법: measure 정의하고 GRAPH_EXPAND로 집계하기

빅쿼리 콘솔(console.cloud.google.com/bigquery)을 열고 데이터셋을 하나 만든 뒤, 쿼리 편집기에 아래 순서로 붙여 넣어 실행한다. 이 예시로 구하는 값은 도시별 주문 상품 수 합계다. 순서는 세 단계다. 먼저 그래프를 만들 때 상품 수를 더하는 계산식에 이름을 붙인다. 이 계산식이 measure다. 그다음 GRAPH_EXPAND로 그래프를 한 장의 표처럼 펼친다. 마지막으로 붙여 둔 이름을 AGG로 감싸 도시별로 집계한다.

예시는 구글 블로그가 쓴 공개 데이터셋 thelook_ecommerce(가상의 쇼핑몰 주문 데이터)다. 공개 데이터셋은 읽기 전용이라 그래프는 내 데이터셋에 만들고 공개 테이블을 가리키게 한다. 내프로젝트와 내데이터셋은 본인 이름으로 바꾼다.

CREATE OR REPLACE PROPERTY GRAPH `내프로젝트.내데이터셋.thelook_graph`
NODE TABLES(
  `bigquery-public-data.thelook_ecommerce.users` AS Users KEY(id) LABEL Users
    PROPERTIES(id, city, country),
  `bigquery-public-data.thelook_ecommerce.orders` AS Orders KEY(order_id) LABEL Orders
    PROPERTIES(
      order_id,
      num_of_item,
      MEASURE(AVG(num_of_item)) AS avg_items_per_order,
      MEASURE(SUM(num_of_item)) AS total_items
    )
)
EDGE TABLES(
  `bigquery-public-data.thelook_ecommerce.orders` AS OrderedBy KEY(order_id)
    SOURCE KEY(order_id) REFERENCES Orders(order_id)
    DESTINATION KEY(user_id) REFERENCES Users(id)
    LABEL OrderedBy
);

코드에서 핵심은 MEASURE(SUM(num_of_item)) AS total_items 한 줄이다. 주문마다 들어 있는 상품 수를 더하는 계산식에 total_items라는 이름을 붙인다. 이후에는 이 이름만 부르면 된다.

위 쿼리를 편집기에 붙여 실행하면 "쿼리 완료됨" 아래에 속성 그래프가 새로 만들어졌다는 문구가 나온다. 이 문구가 보이면 계산식(measure)이 그래프 안에 저장된 것이다. 이 쿼리는 직접 실행해 성공을 확인했고, 실행 중 세 가지 오류를 만났다. 테이블 별칭을 Order로 쓰면 예약어라 "Unexpected keyword ORDER" 오류가 나서 Orders로 바꿨다. measure 안에서 쓰는 num_of_item을 PROPERTIES에 적지 않으면 "Columns are not supported in graph measure property expressions" 오류가 나고, 엣지 테이블에 KEY가 없으면 "graph element table keys must be explicitly defined" 오류가 난다. 키 규칙은 구글 문서의 measures 설명에서 확인할 수 있다.

그다음 같은 편집기에서 아래 SELECT를 실행한다. FROM의 GRAPH_EXPAND는 그래프를 한 장의 표처럼 펼친다. AGG는 방금 붙인 이름(Orders_total_items)을 불러 도시별로 계산한다. 정리하면 도시별로 주문된 상품이 모두 몇 개인지 묻는 쿼리다.

SELECT
  Users_city AS city,
  ROUND(AGG(Orders_avg_items_per_order), 2) AS agg_avg_items,
  ROUND(AGG(Orders_total_items), 2) AS agg_total_items
FROM GRAPH_EXPAND("내프로젝트.내데이터셋.thelook_graph")
GROUP BY Users_city
ORDER BY agg_total_items DESC
LIMIT 10;

결과 탭에 도시 10줄이 나오면 성공이다. 이 실행에서는 Shanghai가 agg_total_items 4291.0으로 맨 위였고 Beijing 3840.0, Seoul 2623.0이 뒤를 이었다. 쉽게 말해 Shanghai에서 주문된 상품은 모두 4291개로 가장 많았다는 뜻이다. 같은 공개 데이터셋은 바뀔 수 있어 숫자는 달라질 수 있다.

펼쳐진 measure 열 이름은 "노드 별칭_measure 별칭" 형태다. 위 쿼리에서 Orders 노드의 total_items가 Orders_total_items가 되는 식이다. GQL 쿼리는 measure 속성을 직접 참조할 수 없으므로 GRAPH_EXPAND와 AGG를 거쳐야 한다. 반환 구조를 먼저 보고 싶으면 BQ.SHOW_GRAPH_EXPAND_SCHEMA를 부르면 쿼리를 돌리지 않고 출력 스키마를 확인할 수 있다.

결과가 맞는지는 두 숫자를 비교해 확인한다. 하나는 도시별 total_items를 모두 더한 값이다. 다른 하나는 orders 테이블에서 num_of_item을 직접 더한 값이다. 이때 사용자와 연결된 주문만 비교 대상으로 맞춘다. 두 값이 같으면 정의가 의도대로 동작한 것이고, 다르면 키 설정이나 연결되지 않은 행부터 점검한다.

빅쿼리 measures 쓸 때 제한과 요금제 확인

GRAPH_EXPAND에는 몇 가지 제약이 있다. 루트 노드 테이블이 여러 개인 그래프는 start_node를 지정해야 하고, 그 루트에서 닿지 않는 데이터는 결과에서 빠진다. 다대다 관계가 모호한 연결 테이블은 엣지로 인식되지 않고 무시되며, 모든 엣지가 무시되면 호출이 오류로 끝난다. 이때는 연결 테이블을 노드 테이블로 올려 모델링하라고 문서가 안내한다. 그래프를 바꿔도 캐시된 결과는 무효화되지 않으므로 GRAPH_EXPAND를 호출할 때는 캐시 조회를 끄는 편이 안전하다.

에디션 조건은 둘로 나뉜다. 문서에 따르면 GQL 쿼리를 돌리려면 Enterprise나 Enterprise Plus 예약이 필요하고, 온디맨드 요금제는 GRAPH_EXPAND로 SQL 쿼리를 실행할 수 있다. 8월 27일 릴리스 노트는 measures가 Enterprise, Enterprise Plus, 온디맨드에서 계속 제공되고 Standard 에디션에서는 제공되지 않는다고 적었다. 같은 노트의 8월 20일 항목은 그래프 처리 기능에 대한 Standard 에디션·온디맨드 지원을 2027년 4월 26일부터 단계적으로 없앤다고 예고했다. 지금 Standard를 쓰는 팀이라면 도입 전에 에디션부터 확인해야 한다.

대시보드와 AI 에이전트에서 같은 지표 쓰기

구글은 GA 발표에서 Looker 대시보드, 대화형 에이전트, 데이터 팀 쿼리가 빅쿼리에 정의한 measures를 함께 쓰는 구조를 내세웠다. 프리뷰 소개 글에 따르면 Looker는 LookML의 dimension과 measure를 기존 빅쿼리 그래프의 속성에 연결할 수 있고, 대화형 분석 에이전트는 그래프 설명과 measures를 바탕으로 쿼리를 만든다.

다만 이는 지표 정의를 일관되게 만드는 방법이지 모든 AI 답변이 맞다는 보증은 아니다. 지표가 틀리면 대시보드와 에이전트가 같이 틀리므로, 도입은 구글 글의 제안을 따라 작게 시작하는 편이 안전하다. 이미 BI 시맨틱 레이어가 있으면 관리 중인 지표 하나를 그것이 설명하는 엔티티에 직접 정의하고, 지식 그래프가 기반이면 가장 자주 쓰는 탐색 경로에 통합 지표를 붙인다. 정의한 뒤에는 이미 믿고 쓰는 기존 보고서 숫자와 맞는지 대조한 다음 대시보드나 에이전트에 연결한다.

빅쿼리 안에서 이미지나 PDF 같은 비정형 파일을 SQL로 다루는 방법은 빅쿼리 ObjectRef 사용법에서 순서대로 정리했다. 최근 바뀐 빅쿼리 기능은 이번 주 마케팅·AI 변화에서 함께 볼 수 있다.

자주 묻는 질문

빅쿼리 measures는 일반 테이블 쿼리에도 쓸 수 있나요?

문서가 설명하는 정의 위치는 그래프 노드·엣지 테이블의 PROPERTIES이다. 일반 테이블을 쓰려면 먼저 그 테이블을 그래프로 모델링해야 한다.

GA4 내보내기 데이터에도 적용할 수 있나요?

GA4 내보내기 테이블을 다루는 쿼리 방식은 GA4 내부 트래픽을 빅쿼리에서 거르는 방법에서 볼 수 있다. 그래프로 모델링할 수 있는 테이블이라면 시도할 수 있다. 키가 되는 열(예: 주문 ID)이 분명한 테이블부터 시험하는 것이 안전하다.

measures 때문에 요금이 따로 붙나요?

measures 쿼리도 일반 쿼리와 같이 빅쿼리 요금의 온디맨드(처리한 데이터량) 또는 용량(슬롯 사용량) 기준으로 청구된다.

먼저 지금 쓰는 지표 중 JOIN 때문에 합계가 달라진 적 있는 것 하나를 골라 그래프 노드에 MEASURE로 정의하고, 기존 값과 대조하는 것부터 시작하면 된다.