AI 지원 SQL 마이그레이션 파이프라인을 어떻게 구축할까요? 이를 버전 관리 워크플로우(version-controlled workflow)로 연결된 4단계 구조로 설계하세요. 소스 시스템에서 객체 정의를 가져오는 인벤토리(inventory) 단계, LLM이 방언 규칙 세트(dialect ruleset)에 따라 대상 플랫폼용 SQL 초안을 작성하는 변환(conversion) 단계, 소스와 대상의 출력값을 행 단위로 대조하는 검증(validation) 단계, 그리고 검증된 객체만을 CI/CD를 통해 Fabric 또는 Databricks로 배포하는 배포(deployment) 단계입니다.

대부분의 팀이 거꾸로 구축하는 파이프라인

AI 지원 SQL 마이그레이션을 실험하기 시작하는 대부분의 팀은 초기에 동일한 결정을 내립니다. 채팅창을 열고, 저장 프로시저(stored procedure)를 붙여넣은 뒤, Databricks 또는 Fabric용으로 변환해 달라고 요청하는 것입니다. 한 번은 작동합니다. 두 번도 작동하죠. 하지만 누군가 금요일 마감 기한 전에 이 변환 작업을 400개나 실행하려고 시도하는 순간, 데모 뒤에는 파이프라인이 없으며 단지 브라우저 탭에 복사하여 붙여넣는 사람이 있을 뿐이라는 사실을 깨닫게 됩니다.

"AI가 SQL을 변환할 수 있다"와 "우리는 감사 추적(audit trail)이 가능하며, 대규모로, 신뢰할 수 있게 SQL을 변환하는 파이프라인을 보유하고 있다" 사이의 격차가 바로 대부분의 마이그레이션 작업이 정체되는 지점입니다. 이 글에서는 파이프라인 자체를 살펴봅니다. 단계들이 어떻게 연결되는지, 어디에서 무엇이 실행되는지, 그리고 개념 증명(proof of concept) 단계에서는 건너뛰기 쉽지만 운영 환경(production)에서는 건너뛰기에는 비용이 많이 드는 워크플로우의 부분들은 무엇인지 알아봅니다.

파이프라인이 실제로 수행해야 하는 작업

코드를 작성하기 전에, 파이프라인을 진정으로 서로 다른 작업을 수행하는 단계로 분리하는 것이 도움이 됩니다. 이들을 하나의 "AI 마이그레이션" 덩어리로 취급하는 것이 보통 문제가 발생하는 지점입니다.

인벤토리(Inventory): 2년 전에 누군가 관리했던 스프레드시트가 아니라, 소스 시스템에서 모든 객체 정의, 종속성(dependencies) 및 메타데이터(metadata)를 직접 가져옵니다.

변환 (Conversion): 각 객체를 방언별 컨텍스트 (dialect-specific context)와 함께 언어 모델 (language model)로 전송하여, 대상 플랫폼의 SQL 방언 (SQL dialect)으로 된 1차 번역 결과물을 얻습니다.

검증 (Validation): 변환된 객체를 대표 데이터 (representative data)에 대해 실행하고 출력값을 소스 (source)와 비교하여, 구문 오류 (syntax errors)뿐만 아니라 미세한 의미론적 드리프트 (semantic drift)까지 잡아냅니다.

승격 (Promotion): 검증된 객체를 소스 제어 (source control) 및 CI/CD를 통해 대상 환경으로 이동시키며, 무엇이 왜 변경되었는지에 대한 명확한 기록을 남깁니다.

이러한 각 단계는 독립적으로 구축될 수 있으며, 솔직히 말해 그렇게 구축해야 합니다. 이들을 긴밀하게 결합하는 것은 흔히 발생하는 초기 실수로, 배치 실행 (batch run)이 부분적으로 실패했을 때 전체 시스템의 디버깅을 더 어렵게 만듭니다.

1단계: 소스에서 직접 추출한 인벤토리 (Inventory)

누군가의 기억이나 오래된 위키 (wiki) 페이지에 의존하는 것은 건너뛰십시오. 시스템 카탈로그 (system catalog)에서 객체 정의 (object definitions)와 메타데이터 (metadata)를 직접 가져옵니다.

Fabric 마이그레이션을 위한 SQL Server 소스의 경우:
SELECT 

...

출력값을 객체당 하나의 레코드로 저장합니다: 이름, 유형, 전체 정의 텍스트, 종속성 참조 (dependency references), 그리고 대략적인 크기 지표 (1차 단계로는 라인 수(line count)로도 충분합니다).
이것이 다운스트림 (downstream)의 모든 작업을 위한 작업 큐 (work queue)가 되므로, 다음으로 넘어가기 전에 스키마 (schema)를 정확하게 설정하십시오.

2단계: 프롬프트에 방언 컨텍스트를 내장한 변환 (Conversion)

변환 품질을 결정하는 가장 큰 레버 (lever)는 모델이 아니라, 모델에 제공하는 컨텍스트 (context)입니다. 단순히 "이것을 Databricks SQL로 변환해줘"라고 말하는 프롬프트는 평범한 결과를 생성합니다. 객체와 관련된 특정 방언 차이 (dialect differences)를 포함하는 프롬프트는 실제 운영 환경에 바로 적용 가능한 (production-ready) 수준에 훨씬 가까운 결과를 만들어냅니다.

_T-SQL을 Databricks SQL로 번역하기 위한 단순화된 변환 요청 예시:

def build_conversion_prompt(
    object_definition: str,
    source_dialect: str = "tsql",
...

여기서 놓치기 쉬운 두 가지 중요한 사항이 있습니다. 첫째, 모델이 추측하는 대신 모호한 부분을 표시(flag)하도록 명시적으로 지시하면, 나중에 발견될 수도 있는(혹은 아예 발견되지 못할 수도 있는) 조용히 잘못된 변환(silently wrong conversions)의 수를 줄일 수 있습니다. 둘째, 방언(dialect) 관련 노트는 파이프라인 코드와 함께 버전 관리 시스템(version control)에 보관하십시오. 모든 마이그레이션은 새로운 엣지 케이스(edge cases)를 드러내며, 해당 파일은 누군가의 머릿속에 머무는 것이 아니라 프로그램과 함께 성장해야 합니다.

3단계: Fabric 및 Databricks에서의 배치 오케스트레이션 (Batch Orchestration)

변환 로직이 단일 객체에서 정상적으로 작동하면, 다음 문제는 프로세스를 일일이 감시하지 않고도 수천 개의 객체에 걸쳐 이를 실행하는 것입니다. Databricks에서는 매개변수화된 노트북(parameterized notebook)을 사용하는 워크플로 작업(Workflow job)이 이를 깔끔하게 처리합니다:

# Databricks 노트북
# AI 지원 변환을 위해 대기 중인 SQL 객체 배치를 처리합니다

...

Microsoft Fabric의 경우, 동일한 패턴은 인벤토리 테이블을 반복(iterate)하는 ForEach 활동(activity)을 포함하는 데이터 팩토리(Data Factory) 파이프라인으로 실행됩니다. 각 객체에 대해 Fabric 노트북 또는 Azure Function을 호출하고 결과를 레이크하우스(Lakehouse) 테이블에 기록합니다. 오케스트레이션 도구는 다르지만, 그 형태는 동일합니다. 관리 가능한 단위(실제로는 실행당 50~200개의 객체가 적당함)로 배치 처리하고, 실패 시 처음부터 다시 시작하지 않도록 진행 상황을 체크포인트(checkpoint)로 기록하며, 검증 실패 시 아무것도 다시 변환할 필요가 없도록 변환과 검증을 별도의 작업 단계로 유지하십시오.

4단계: 구문 오류(Syntax Errors) 이상을 잡아내는 검증

오류 없이 실행되는 변환된 객체가 올바른 출력을 생성하는 객체와 동일한 것은 아닙니다. 검증은 이 두 가지를 모두 확인해야 합니다.

from pyspark.sql import functions as F

# 소스 및 마이그레이션된 테이블 로드
...

샘플이 아닌, 변환된 모든 객체에 대해 세 가지 검증(행 수(row count), 집계 일치성(aggregate parity), 행 단위 해시(row-level hash))을 모두 실행하십시오. 어떤 검증이라도 통과하지 못한 객체는 조용히 승격되는 대신 수동 검토 대상으로 플래그(flag)가 지정됩니다. 이는 팀들이 마감 압박 속에서 건너뛰는 단계이며, 마이그레이션 3주 후에 분석가가 대시보드 숫자가 잘못된 것을 발견하는 상황처럼 나중에 가장 많은 시간을 소모하게 만드는 단계입니다.

Git 워크플로(Workflow) 및 CI/CD: 변환된 SQL을 다른 코드 변경과 동일하게 취급하십시오

변환된 객체는 "AI가 작성했다"는 이유로 특별 면제를 받는 것이 아니라, 직접 작성한 코드와 동일한 검토 규율을 거쳐야 합니다.

실용적인 브랜치(branching) 패턴은 다음과 같습니다. 마이그레이션 웨이브(wave)당 하나의 브랜치를 생성하고, 변환된 객체가 검증을 통과할 때마다 커밋(commit)합니다. Pull Request(PR) 시 GitHub Actions 또는 Azure DevOps 파이프라인이 실행됩니다:

name: SQL Migration Validation Pipeline

on:
...

Databricks로의 배포에는 Databricks Asset Bundles를 사용하여 검증된 노트북(notebook)과 작업(job)을 스테이징(staging) 워크스페이스에서 프로덕션(production)으로 승격할 수 있습니다. Fabric의 경우, 배포 파이프라인(deployment pipelines)을 통해 검증된 항목(노트북, Lakehouse, warehouse 객체)을 Dev, Test, Production 워크스페이스 간에 이동합니다. 어떤 방식이든, 다른 모든 코드 변경 사항과 동일한 게이트(gate)를 통과하지 않고서는 프로덕션에 도달할 수 없습니다.

조기에 채택할 가치가 있는 모범 사례(Best Practices)

방언(dialect) 매핑 규칙을 파이프라인 코드와 별도로 버전 관리(version-control)하십시오. 이 규칙들은 더 자주 변경되며 여러 프로젝트에서 재사용됩니다.

알파벳 순서나 티켓 순서가 아닌, 복잡도 계층(complexity tier)별로 배치(batch) 처리하십시오. 복잡도가 낮은 객체가 정체된 고복잡도 객체 뒤에서 대기해서는 안 됩니다.

실패 및 플래그가 지정된 모호한 사례를 포함하여 모든 변환 시도를 로그(log)로 남기십시오. 이는 누군가 "왜 이것이 소스(source)와 다르게 보이는가"라고 물을 때 감사 추적(audit trail) 역할을 하게 됩니다.

수동 검토 큐(queue)를 자동화된 파이프라인과 명확히 분리하여 유지하십시오. 수동 검토 단계를 자동화 스크립트 내부에 묻어두어 쉽게 건너뛰게 만들지 마십시오.

초기 AI 변환(conversion) 직후뿐만 아니라, 변환된 객체를 수동으로 편집한 후에도 반드시 검증(validation)을 다시 실행하십시오.

피해야 할 일반적인 실수

인벤토리(inventory) 단계를 건너뛰고 티켓(ticket) 기반으로 변환을 진행하는 것. 완전한 인벤토리 없이는 객체 수나 의존성 그래프(dependency graph)를 실제로 파악할 수 없으며, 이는 웨이브 계획(wave planning)을 추측에 의존하게 만듭니다.

성공적인 실행을 정확성의 증거로 신뢰하는 것. 오류 없이 실행되는 저장 프로시저(stored procedure)라 할지라도, 여전히 조용히 행(row)을 누락시키거나 집계(aggregate)를 잘못 계산할 수 있습니다. 검증(validation)이 존재하는 이유는 구문(syntax)의 성공과 의미론적(semantic) 정확성이 서로 다른 것이기 때문입니다.

분리 가능한 단계 대신 하나의 거대한 스크립트를 구축하는 것. 인벤토리, 변환, 검증 및 배포가 서로 뒤엉켜 있으면, 검증 로직의 버그 하나로 인해 이미 문제가 없는 객체들까지 다시 변환해야 하는 상황이 발생합니다.

운영 장애(production incident)가 발생할 때까지 성능을 무시하는 것. 배치 크기(batch size), 클러스터 크기 산정(cluster sizing), 그리고 변환 서비스의 속도 제한(rate limits)은 객체 수가 1,000개에 도달하기 훨씬 전부터 중요하게 고려되어야 합니다.

확장을 위한 성능 고려 사항

LLM API에 대한 변환 호출은 수천 개의 객체를 실행할 때 문제가 되는 지연 시간(latency)과 속도 제한(rate limits)을 가집니다. 촘촘한 순차 루프(sequential loop) 대신 제한된 워커 풀(worker pool)을 사용하여 변환 호출을 병렬화(parallelize)하십시오. 또한, 소스 객체 정의의 해시(hash)를 통해 변환 결과(conversion results)를 캐싱(cache)함으로써, 배치를 다시 실행할 때 변경되지 않은 객체를 다시 변환하지 않도록 하십시오. Databricks 측면에서는, 두 작업을 모두 크기가 작은 동일한 클러스터에서 실행하기보다, 실제 데이터 처리(real data processing)를 수행하는 검증(validation) 워크로드와 주로 API 호출 및 가벼운 변환(light transformation)을 수행하는 변환(conversion) 워크로드의 클러스터 크기를 별도로 산정하십시오.

이 파이프라인의 그 어떤 것도 엔지니어링적 판단(engineering judgment)을 대체하지 않습니다. 이는 단지 방언 매핑 규칙(dialect mapping rule)으로 처리할 수 있었던 SQL을 다시 타이핑하는 데 판단력을 소모하는 대신, 아키텍처 결정, 모호한 비즈니스 로직, 그리고 예외 케이스(edge cases)와 같이 실제로 중요한 곳으로 그 판단력을 옮겨주는 것뿐입니다. 이 네 가지 단계를 분리 가능한 구성 요소로 구축하고, 일반적인 프로덕션 데이터 파이프라인(production data pipeline)에 적용하는 것과 동일한 엄격함으로 이들을 연결하십시오. 그러면 "AI 지원(AI-assisted)" 부분은 전체 시스템이 아닌 2단계의 세부 사항이 될 것입니다.

핵심 요약 (Key Takeaways)

• 마이그레이션 파이프라인을 인벤토리(inventory), 변환(conversion), 검증(validation), 프로모션(promotion)으로 분리하십시오. 이를 하나의 프로세스로 취급하면 배치 실패(batch failures)에 대한 디버깅이 훨씬 더 어려워집니다.
• 출력 품질에 있어서는 모델의 선택보다 변환 프롬프트(conversion prompt) 내의 방언별 컨텍스트(dialect-specific context)가 더 중요합니다.
• 변환된 모든 객체를 샘플링이 아닌 행 수(row count), 집계(aggregate), 그리고 행 해시(row-hash) 체크를 통해 검증하십시오.
• 변환된 SQL을 다른 코드 변경 사항과 마찬가지로 동일한 Git 및 CI/CD 규율을 통해 전달하십시오.
• 수십 개가 아닌 수천 개의 객체를 변환하게 되면 배치 크기(batch size), 캐싱(caching), 클러스터 크기 조정(cluster sizing)이 실제 제약 사항이 됩니다.

대규모 SQL 현대화 프로젝트를 계획 중이라면, 변환 엔진은 퍼즐의 한 조각일 뿐입니다. 일관된 검증, 방언을 인식하는 번역(dialect-aware translation), 그리고 구조화된 오케스트레이션(orchestration)이 AI 지원 마이그레이션을 반복 가능한 엔지니어링 프로세스로 바꾸는 핵심입니다. 이 접근 방식이 실제로 어떻게 작동하는지 확인하고 싶다면, 우리의 Code Conversion Accelerator를 탐색하여 자동화된 SQL 변환이 엔터프라이즈급 검증 및 검토와 어떻게 결합되는지 이해해 보시기 바랍니다.