Data Engineering Agent를 사용한 기존 파이프라인 수정 및 마이그레이션
요약
본 기사는 BigQuery Studio의 Data Engineering Agent를 활용하여 기존 데이터 파이프라인을 수정하고 마이그레이션하는 실무 방법을 안내합니다. 이 에이전트는 자연어 지시만으로 복잡한 쿼리 분석, 개선 제안 및 실제 코드 수정을 지원하며, 특히 레거시 ML 함수(ML.GENERATE_TEXT)를 최신 AI.* 함수로 전환하거나 스케줄 쿼리의 의존 관계를 DAG로 정리하는 데 유용합니다.
핵심 포인트
- Data Engineering Agent는 BigQuery에서 자연어 기반의 파이프라인 분석 및 수정 기능을 제공합니다.
- 레거시 ML.GENERATE_TEXT 호출을 최신 AI.* 함수로 쉽게 마이그레이션할 수 있습니다.
- 복잡한 스케줄 쿼리의 의존 관계를 조사하고 DAG 형태로 정리하여 관리 효율성을 높일 수 있습니다.
기존 파이프라인을 수정하는 것이 어려운 이유
BigQuery에서 운영 중인 데이터 파이프라인에는 다음과 같은 문제들이 쌓이기 쉽습니다.
- 스케줄 쿼리가 너무 많아져 의존 관계를 파악하기 어렵다
- 구식의 ML.GENERATE_TEXT를 사용하고 있어 AI.* 함수로 전환하고 싶다
- 작성한 담당자가 퇴사하여 의도를 알 수 없는 SQL이 남아있다
- 파티션 설계가 오래되어 비용이 계속 증가하고 있다
이러한 수정 및 마이그레이션 작업은 영향 범위 조사부터 시작해 직접 다시 작성해야 하므로 매우 시간이 많이 걸립니다. BigQuery의 Data Engineering Agent를 사용하면 자연어로 지시하는 것만으로 기존 파이프라인의 분석, 수정, 마이그레이션을 진행할 수 있습니다.
본 기사에서는 Data Engineering Agent를 사용하여 기존 파이프라인을 수정하고 마이그레이션하는 절차를 실무에서 사용할 수 있는 프롬프트와 함께 설명합니다.
Data Engineering Agent란 무엇인가
Data Engineering Agent는 BigQuery Studio의 에이전트 기능 중 하나입니다. 단순히 파이프라인을 생성하는 것뿐만 아니라, 기존 쿼리나 스케줄 설정을 읽어 들여 변경 및 개선 사항을 제안하고 실행할 수 있는 능력을 가지고 있습니다.
이전 기사 'Data Engineering Agent로 자연어로 파이프라인 만들기'에서는 신규 생성을 다루었습니다. 본 기사에서는 수정(改修)과 마이그레이션에 초점을 맞춰 설명합니다.
사전 준비
필요한 권한
Data Engineering Agent를 이용하려면 다음 IAM 역할이 필요합니다.
roles/bigquery.dataEditor
(데이터셋에 대한 쓰기 권한)
roles/bigquery.jobUser
(쿼리 실행 권한)
roles/bigquery.connectionUser
(Vertex AI 연결 이용 권한)
연결 설정은 K-02 'BigQuery에서 AI 기능을 사용하기 위한 IAM 및 Vertex AI 연결 설정'을 참조하세요.
Agent 시작
BigQuery Studio를 열고, 화면 오른쪽 상단의 'Agent' 아이콘을 클릭합니다. 에이전트 패널이 열리면 'Data Engineering'을 선택합니다.
사용 사례 1: ML.GENERATE_TEXT에서 AI.* 함수로의 마이그레이션
2024년 이후부터 BigQuery에서는 ML.GENERATE_TEXT보다 AI.* 함수가 권장되게 되었습니다. 기존의 ML 모델 호출을 AI.* 함수로 전환하는 경우를 살펴보겠습니다.
대상 쿼리 예시
-- 마이그레이션 전 (ML.GENERATE_TEXT 사용)
SELECT
product_id,
...
Agent에 대한 지시
에이전트 패널에 다음과 같이 입력합니다.
위 쿼리를 ML.GENERATE_TEXT에서 AI.GENERATE 함수로 마이그레이션해 주세요.
모델은 gemini-2.0-flash-001, max_output_tokens는 500을 유지해 주세요.
Agent는 차이점을 제시하면서 수정된 쿼리를 출력합니다.
-- 마이그레이션 후 (AI.GENERATE 사용)
SELECT
product_id,
...
변경점은 바로 확인할 수 있습니다. Agent가 생성한 설명문도 함께 읽어보면 마이그레이션의 배경을 이해하기 쉽습니다.
사용 사례 2: 스케줄 쿼리의 의존 관계 정리
여러 개의 스케줄 쿼리가 쌓이면 어떤 쿼리가 어느 테이블에 의존하는지 파악하기 어려워집니다.
Agent에 대한 지시
데이터셋 'analytics_mart' 내의 모든 뷰와 테이블의 의존 관계를 조사하고,
실행 순서를 DAG(Directed Acyclic Graph)로 정리해 주세요.
문제가 있다면 개선안도 제시해 주세요.
Agent는 데이터셋 내의 테이블 정의 및 뷰 정의를 탐색하여, 의존 관계가 정리된 리스트를 반환합니다. 순환 참조나 데드 코드(참조되지 않은 테이블)도 감지할 수 있습니다.
출력 예시:
1. raw_events (소스 테이블)
2. stg_sessions (raw_events에 의존)
3. mart_daily_revenue (stg_sessions에 의존)
...
이 출력을 바탕으로 불필요한 테이블이나 뷰를 정리할 수 있습니다.
사용 사례 3: 파티션 설계 개선
오래된 테이블에 파티션이 설정되어 있지 않은 경우, 쿼리마다 전체 스캔(full scan)이 실행되어 비용이 증가합니다.
현황 확인 프롬프트
테이블 “project.dataset.ga4_events_flat”의 파티션 설정을 확인하고, 현재 월별 비용을 개략적으로 추산해 주세요.
개선 방안이 있다면 제시해 주세요.
Agent의 답변 예시
현재: 파티션 없음, 전체 데이터 풀 스캔(추정)
월별 쿼리 비용 개략 추산: 약 12,000엔 (월 200GB 스캔 가정)
개선 방안:
...
“예”라고 답하면 마이그레이션용 CREATE TABLE AS SELECT 문을 출력해 준다.
CREATE OR REPLACE TABLE `project.dataset.ga4_events_flat_v2`
PARTITION BY DATE(event_date)
CLUSTER BY event_name, user_pseudo_id
...
유스케이스 4: GA4 데이터 집계 로직 수정
GA4의 BigQuery 익스포트를 사용할 때, ga_session_id를 가져오는 방법이 오래된 쿼리에서는 잘못되는 경우가 있다.
흔히 발생하는 오류 패턴
-- NG: ga_session_id를 직접 참조하려는 잘못된 접근 방식
SELECT
user_pseudo_id,
...
Agent에게 지시하여 수정하기
ga_session_id를 event_params에서 UNNEST로 올바르게 가져오도록 수정해 주세요.
수정 후:
SELECT
user_pseudo_id,
(
...
Agent는 GA4의 스키마 특성을 이해하고, UNNEST를 통한 정확한 획득 방법을 제안한다.
유스케이스 5: collected_traffic_source를 사용한 트래픽 분석으로 전환
기존 쿼리에서는 event_params에서 트래픽 정보를 가져왔지만, collected_traffic_source를 사용하면 더 간단하게 작성할 수 있다.
Agent에게 지시하기
event_params에서 medium과 source를 가져오는 부분을,
collected_traffic_source를 사용하는 형태로 바꿔 주세요.
수정 전:
SELECT
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'medium') AS medium,
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'source') AS source
...
수정 후:
SELECT
collected_traffic_source.manual_medium AS medium,
collected_traffic_source.manual_source AS source
...
collected_traffic_source.manual_medium를 사용함으로써 코드가 짧아지고 가독성도 높아진다.
전환 시 주의할 점
프로덕션 환경에 반영하기 전에 검증하기
Agent가 제안하는 변경 사항은, 먼저 뷰나 별도의 테이블에서 동작을 확인한 후 프로덕션 테이블에 적용해야 한다. 특히 파티션 변경은 데이터 재삽입이 필요하므로, 원본 테이블은 삭제하지 않고 남겨두어야 한다.
스케줄 쿼리 업데이트는 수동 확인 거치기
스케줄 쿼리의 SQL 변경은 Agent가 제안하지만, 실제 업데이트는 BigQuery Studio의 스케줄 관리 화면에서 진행한다. Agent가 직접 일정을 수정하는 것이 아니므로, 제안 내용을 확인한 후 적용해야 한다.
비용 추산은 어디까지나 참고 값
Agent가 제시하는 비용 추산은 실제 쿼리 패턴과 다를 수 있다. 개선 전후로 BigQuery의 “이 쿼리를 실행하면 약 XGB의 데이터가 처리됩니다” 표시를 비교하는 것이 정확하다.
요약
Data Engineering Agent를 활용하면, 다음 수정/전환 작업을 자연어로 지시할 수 있다.
- ML.GENERATE_TEXT에서 AI.* 함수로 전환하기
- 스케줄 쿼리의 의존성 정리 및 DAG 시각화
- 파티션 설계 개선 및 마이그레이션 SQL 생성
- GA4 쿼리의 올바른 UNNEST/collected_traffic_source 활용으로 수정하기
기존 파이프라인의 기술적 부채를 해소하고 싶다면, 먼저 의존 관계 정리부터 시작하여 영향 범위를 파악한 후 개별적인 수정에 들어가는 것이 순조롭게 진행됩니다.
BigQuery 데이터 파이프라인 설계 및 AI 활용에 대한 실무 수준의 지원을 제공합니다. 상담은 여기에서 부탁드립니다.
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기