ML.GENERATE_TEXT에서 AI.* 함수로: 무엇이 바뀌고 어떻게 마이그레이션할 것인가

서론

시리즈의 네 번째 회차이자, 페이즈 1의 마지막 편입니다.

BigQuery에서 LLM을 사용하는 방법을 조사하다 보면, 두 세대의 정보가 혼재되어 있는 것을 알 수 있습니다.

• 이전 세대:
  CREATE MODEL로 원격 모델을 생성하고, ML.GENERATE_TEXT로 호출하는 방식
• 새로운 세대:
  AI.GENERATE와 같은 AI 함수를 직접 호출하는 방식

인터넷상의 기사들은 두 가지가 뒤섞여 존재하는 경우가 많아, 어느 것을 보고 있는지 의식하지 않으면 혼란스럽습니다. '기사대로 했는데 작동하지 않는다'는 원인이 사실은 세대 차이였던 경우라는 이야기는 흔합니다.

이번 글에서는 이 두 가지의 차이점을 정리하고, 기존 자산이 있을 경우의 마이그레이션(移行) 방법을 다루겠습니다.

무엇이 다른가

전통적 방식: 모델 객체 생성

ML.GENERATE_TEXT를 사용하려면, 먼저 BigQuery 상에 모델 객체를 만들 필요가 있었습니다.

-- ① 원격 모델을 생성한다
CREATE OR REPLACE MODEL `your-project.ai_lab.gemini_model`
REMOTE WITH CONNECTION `your-project.asia-northeast1.gemini-conn`
...

-- ② 해당 모델을 지정하여 호출한다
SELECT *
FROM ML.GENERATE_TEXT(
...

2단계 구조였습니다. 모델을 만든 후에, 그것을 참조했습니다.

현재 방식: 함수 직접 호출

AI 함수는 모델 객체 생성이 불필요합니다. 연결과 엔드포인트를 직접 지정합니다.

SELECT
id,
AI.GENERATE(
...

1단계가 되었습니다.

비교

스칼라 함수가 되었다는 점이 실무상 가장 큰 변화입니다. 테이블 함수였을 때는 AI 호출이 쿼리 구조를 규정했습니다. 지금은 일반 함수와 마찬가지로, SELECT 안에도, WHERE 안에도 작성할 수 있습니다.

-- 이런 작성이 가능해졌다
SELECT id, body
FROM `your-project.ai_lab.sample_reviews`
...

ML.GENERATE_TEXT의 시대에는 일단 전체 데이터를 생성한 후, 그 결과를 외부에서 필터링할 수밖에 없었습니다. 필요한 데이터만 걸러낼 수 있게 된 것은 비용 측면에서도 의미가 있습니다.

어떤 것을 사용해야 할까

새로 작성한다면 AI 함수입니다. 이유는 명확하고, 작성량이 적으며, SQL에 자연스럽게 녹아들고, 관리형 함수(AI.IF / AI.CLASSIFY / AI.SCORE)를 사용할 수 있기 때문입니다.

다만 ML.GENERATE_TEXT가 즉시 불필요해지는 것은 아닙니다. 다음과 같은 경우에는 유지하는 판단도 있습니다.

• 이미 프로덕션 환경에서 안정적으로 작동하고 있는 경우. 작동하는 것을 건드리는 리스크가 더 큽니다 -
• 모델을 객체로 일원 관리하고 싶은 경우. 어떤 모델을 사용하고 있는지 BigQuery 측에서 파악하고 싶은 케이스 -
• 세밀한 매개변수 제어가 필요한 경우. temperature 등을 명시적으로 조정하는 경우

세 번째 보충 설명이 필요합니다. AI 함수 중에서도 관리형 함수(AI.IF / AI.CLASSIFY / AI.SCORE)는 BigQuery 측에서 매개변수 조정을 담당합니다. 안정적인 결과를 얻기 쉽다는 장점이 있는 반면, 세밀한 제어는 할 수 없습니다. 제어가 필요하다면 AI.GENERATE를 사용하거나, ML.GENERATE_TEXT를 남겨두는 것이 좋습니다.

마이그레이션 절차

기존의 ML.GENERATE_TEXT 자산이 있는 경우의 진행 방법입니다.

Step 1: 사용 위치 파악하기

먼저 현재 상황을 파악합니다.

SELECT
creation_time,
job_id,
...

생성된 모델도 확인합니다.

SELECT
model_name,
model_type,
...

dbt나 Dataform으로 관리하고 있다면, 리포지토리를 검색하는 것이 빠릅니다.

grep -rn "ML.GENERATE_TEXT" models/ --include="*.sql"

Step 2: 병렬 구동으로 결과를 비교하기

갑자기 교체하지 마세요. 출력이 달라질 수 있습니다.

같은 입력에 대해 두 가지를 모두 실행하고, 결과를 대조합니다.

CREATE OR REPLACE TABLE `your-project.ai_lab.migration_compare` AS
WITH src AS (
SELECT id, body
...

비교한 후, 차이점의 경향을 살펴봅니다.

SELECT
COUNTIF(old_result IS NULL) AS old_failed,
COUNTIF(new_result IS NULL) AS new_failed,
...

Step 3: 하위 공정(Downstream)에 미치는 영향 확인하기

생성된 결과를 사용하고 있는 후속 작업을 확인합니다.

• 대시보드 표시가 깨지지 않는지
• 분류 결과로 필터링하는 부분이 없는지
• 글자 수의 전제를 두고 있지 않은지

특히 분류/판정 시스템은 영향이 큽니다. 레이블 문자열이 미묘하게 바뀌는 것만으로도, WHERE category = 'クレーム'와 같은 조건이 공백을 반환할 수 있습니다.

이 기회에, 애초에 자유 문장(free text)으로 분류시키는 것을 중단하고 AI.CLASSIFY로 대체하는 것이 더 나은 경우도 많습니다. 분류 축을 명시적으로 정의할 수 있고, 출력이 안정적입니다.

Step 4: 전환 및 정리 작업

문제가 없다면 교체합니다. 교체 후에는 잠시 지켜본 뒤에 모델 객체를 삭제합니다.

-- 충분한 기간 동안 새로운 방식으로 안정화된 후에 실행할 것
DROP MODEL IF EXISTS `your-project.ai_lab.gem

문장으로 사용 가능 - 
**새로운 것은 AI 함수입니다.** 기존의 안정적으로 작동하는 시스템은 서둘러 이전할 필요가 없습니다. 마이그레이션은 **병행 운영을 통해 비교한 후에** 진행하세요. 출력 결과가 완전히 일치할 것이라고 기대하지는 마세요. **분류 및 판정 계열은 영향이 큽니다.** 이 기회에 `AI.CLASSIFY`로 대체하는 것을 고려해 볼 가치가 있습니다.

여기에서 요청하기 → GA4×BigQuery 기반 구축 서비스

### Discussion
![](https://static.zenn.studio/images/drawing/discussion.png)