빅쿼리 컬럼 별칭 재사용·리전 간 테이블 복사 GA: 바뀐 점과 지금 할 일

빅쿼리 컬럼 별칭은 SELECT 절에서 만든 별칭을 같은 SELECT 목록과 WHERE 절에서 바로 다시 쓰게 해 주는 기능이고, 구글 클라우드는 2026년 10월 15일 릴리스 노트에서 이 기능과 리전 간 테이블 복사의 정식 출시(GA)를 함께 알렸다(빅쿼리 릴리스 노트). GA4 내보내기 데이터를 빅쿼리에서 쿼리하는 사람이라면 같은 계산식을 서브쿼리로 감싸던 습관을 바꿀 수 있고, 데이터셋을 다른 리전으로 옮겨야 하는 사람은 복사 방법과 제한을 다시 확인해야 한다.

무엇이 바뀌었나 컬럼 별칭 재사용(옵트인)과 리전 간 테이블 복사가 10월 15일 GA가 됐다.

누가 영향을 받나 빅쿼리로 GA4·광고 데이터를 쿼리하는 분석가, 데이터셋을 다른 리전으로 옮기는 관리자.

지금 할 일 별칭은 켜기 전에 이름 충돌부터 점검하고, 리전 간 복사는 콘솔이 아니라 bq cp로 한다.

빅쿼리 컬럼 별칭 재사용, 무엇이 바뀌었나

엑셀에서 계산한 칸을 다음 칸이 그대로 가져다 쓰듯, 이제 쿼리에서도 앞에서 이름 붙인 계산 결과를 뒤에서 이름으로 부를 수 있다. 지금까지는 같은 SELECT 목록 안에서 방금 만든 별칭을 쓸 수 없어서 계산식을 복사해 붙이거나 서브쿼리로 한 겹 감싸야 했다. 다른 데이터 웨어하우스에서 옮겨 오는 쿼리도 이 구문을 그대로 쓰는 경우가 많아, 구글은 마이그레이션 지원을 이유로 들었다.

공식 문서의 예제는 아래와 같다. gross_price를 다음 항목과 WHERE 절에서 다시 부른다(재사용 가능한 컬럼 별칭 문서).

SELECT
  net_price * 1.23 AS gross_price,
  gross_price * 0.5 AS discounted_gross_price
FROM product
WHERE discounted_gross_price < 10.0;

빅쿼리 컬럼 별칭을 정의하고 다음 항목과 WHERE 절에서 다시 쓰는 흐름 — 컬럼 별칭 재사용 흐름: 정의, 재사용, WHERE

별칭은 왼쪽에서 오른쪽 순서로만 참조된다. 정의보다 앞에서 부르면 Column not found 오류가 나고, 같은 SELECT 목록에서 별칭을 두 번 정의하면 Column name is ambiguous 오류가 난다.

컬럼 별칭 켜는 법: 기본값은 꺼짐

이 기능은 기본값이 꺼짐이라 관리자가 reusable_column_aliases_mode 옵션을 on으로 바꿔야 쓸 수 있다. 필요한 권한은 roles/bigquery.admin이거나, 프로젝트 단위는 bigquery.projects.update, 조직 단위는 bigquery.organizations.update다(활성화 방법).

범위	명령
프로젝트	ALTER PROJECT PROJECT_ID SET OPTIONS (`region-REGION.reusable_column_aliases_mode` = "on");
조직	ALTER ORGANIZATION SET OPTIONS (`region-REGION.reusable_column_aliases_mode` = "on");
끄기	값을 off로 바꾼다. NULL은 시스템 기본값(꺼짐)이다.

REGION에는 데이터가 있는 리전을, PROJECT_ID에는 프로젝트 ID를 넣는다. 켠 뒤에는 PROJECT_OPTIONS, ORGANIZATION_OPTIONS, EFFECTIVE_PROJECT_OPTIONS 뷰를 조회해 값이 on으로 적용됐는지 본다.

내 쿼리 결과가 바뀔 수 있나: 이름 충돌 점검

별칭을 켜면 이름이 겹치는 쿼리의 결과가 달라질 수 있다. 빅쿼리는 이름을 테이블 컬럼, 쿼리에서 정의한 별칭, 바깥 쿼리의 컬럼, 함수 인자, 스크립트 변수 순서로 찾는다. 그래서 DECLARE한 변수와 같은 이름의 별칭을 이미 쓰고 있다면, 켠 뒤에는 변수 대신 별칭 값이 쓰인다. 공식 문서도 활성화 전에 기존 워크로드를 평가하라고 안내한다.

사용 범위에는 제한도 있다. 그룹화 컬럼을 가리키는 별칭, 집계·윈도우 함수를 참조하는 별칭은 WHERE 절이나 다른 집계 함수의 인자로 쓸 수 없고, 파이프 구문과 GQL에서는 지원되지 않는다.

확인은 작은 실험으로 한다. 개발용 프로젝트에서만 먼저 켜고, 변수나 외부 쿼리 컬럼과 이름이 겹치는 쿼리 몇 개를 켜기 전후로 돌려 결과가 같은지 비교한다. 같으면 운영 프로젝트로 넓힌다.

빅쿼리 리전 간 테이블 복사 GA: 방법과 제한

리전 간 테이블 복사는 테이블, 테이블 스냅샷, 테이블 클론을 한 리전(또는 멀티리전)에서 다른 리전으로 옮기는 기능이다. 서울(asia-northeast3)에 있는 데이터셋을 미국 멀티리전과 같은 곳으로 합쳐야 할 때가 대표적이다. 방법은 bq cp 명령이고, 기본 형식은 아래와 같다(테이블 관리 문서).

빅쿼리 리전 간 테이블 복사를 bq cp로 서울 리전에서 다른 리전으로 옮기는 그림 — bq cp로 리전 간 테이블 복사

bq cp --sync=false mydataset_us.mytable mydataset_eu.mytable2

콘솔과 CREATE TABLE ... COPY 구문으로는 리전 간 복사를 할 수 없다. 이 밖에 같은 문서의 제한은 아래와 같다.

항목	동작
정책 태그·테이블 태그	원본에 있으면 복사할 수 없다.
IAM 정책	복사되지 않아 대상 테이블에 다시 적용해야 한다.
시간 여행 정보	대상 리전으로 복사되지 않는다.
복사 방식	여러 원본을 한 대상으로 합치기, 추가(append) 모드는 안 된다.
만료 시간	원본의 값이 대상에도 복사된다.
복제 대역폭	리전별·프로젝트별 초당 2 GiB(물리 기준).

비용도 따로 붙는다. 리전 간 복사에는 빅쿼리 가격 정책에 따른 데이터 전송 요금이 부과되고, 완료 전에 취소해도 요금이 청구된다. 스냅샷이나 클론을 새 리전으로 복사하면 전체 사본이 생겨 저장 비용도 추가된다. 복사 뒤에는 대상 리전에서 행 수를 세어 원본과 같은지, 대상 테이블 권한이 의도대로인지 확인한다.

지금 할 일과 앞으로 확인할 점

컬럼 별칭은 개발 프로젝트에서 먼저 켜고 이름 충돌 쿼리를 비교한 뒤 운영에 적용한다. 리전 간 복사는 태그와 IAM 정책을 먼저 점검하고, 비용 추정 후 bq cp로 실행한다. 같은 주에 나온 빅쿼리 소식으로 AI.AGG 함수 사용법과 SQL 편집기 Gemini 버튼 사용법도 정리해 두었다.