먼저 답하면: AI가 BigQuery 또는 Dataform 파이프라인을 만들었다는 사실만으로 운영 반영을 승인하면 안 됩니다. 소스·대상 스키마·변환·스케줄·권한·실행 증거·롤백의 7칸이 채워지고, 각 칸의 보류 조건이 해소됐을 때에만 배포를 검토하는 편이 안전합니다.
“AI가 자연어 요청을 받아 파이프라인을 만들었는데, staging에서 한 번 돌았으니 운영에 넣어도 될까요?” 이 질문의 핵심은 생성 속도가 아니라 누가 어떤 근거로 변경을 인수할 수 있느냐입니다. 이 글에서는 BigQuery/Dataform 변경을 사람이 재현 가능하게 검토하고, 배포·보류·롤백 판단을 남기는 7칸 변경 수용 카드를 정리합니다.
핵심 요약
- BigQuery의 Data Engineering Agent는 데이터 파이프라인을 구축·수정하는 맥락에서 제공되지만, 생성 결과가 곧바로 운영 적합성을 뜻하지는 않습니다.
- 운영 반영 전에는 원본 데이터 범위, 대상 스키마, 실제 변환 로직, 실행 시점, 접근 권한, staging 실행 기록, 되돌리는 방법을 각각 확인해야 합니다.
- 대표 입력만 통과한 검증은 부족합니다. 빈 입력·지연 입력·호환성이 깨지는 스키마 변경도 staging에서 확인해야 합니다.
- 보류는 실패가 아닙니다. 증거가 비어 있거나 영향 범위를 모를 때의 보류가 데이터 사고와 불필요한 복구 비용을 줄입니다.
생성 성공과 운영 수용은 왜 다른가
Google Cloud의 BigQuery Data Engineering Agent 공식 문서는 데이터 파이프라인을 만들고 수정하는 기능 맥락을 설명합니다. 다만 도구가 제안한 SQL이나 Dataform 변경이 조직의 데이터 계약, 접근 범위, 실행 주기, 하위 시스템의 기대값까지 자동으로 이해한다고 볼 수는 없습니다.
예를 들어 일별 집계 테이블의 컬럼을 nullable에서 필수값으로 바꾸면 쿼리 자체는 실행될 수 있습니다. 그러나 빈 값이 들어오는 날의 적재가 멈추거나, 그 컬럼을 쓰는 대시보드가 예상과 다르게 동작할 수 있습니다. 반대로 스케줄을 한 시간 앞당기는 작은 변경도 원본 테이블의 갱신보다 먼저 실행되면 오래된 데이터가 퍼질 수 있습니다.
FLOWIT의 실무 기준: “실행된다”는 품질 신호 하나일 뿐입니다. 비용은 재처리와 복구 시간으로, 권한은 읽을 수 있는 데이터 범위로, 신뢰성은 지연·빈 입력·재시도로, 운영은 담당자와 중단 기준으로 확인해야 합니다.
기능의 현재 제공 범위나 변경 사항은 배포 직전에 BigQuery 공식 릴리스 노트로 다시 확인해 주세요. 프로젝트·권한 구성에 따라 사용할 수 있는 기능과 동작은 달라질 수 있습니다.
운영 반영 전, 7칸 변경 수용 카드
아래 표는 회의용 체크 항목이 아니라 변경 하나당 남기는 인수 기록입니다. 각 줄에 링크나 실행 ID를 남기고, 보류 조건이 하나라도 남으면 운영 반영을 멈춥니다.
| 수용 칸 | 확인할 값 | 남길 증거 | 보류 조건 |
|---|---|---|---|
| 1. 소스 | 원본 테이블, 갱신 주기, 입력 범위, 민감 정보 여부 | 데이터 소유자 확인과 읽기 범위 기록 | 입력 범위 또는 민감 정보 처리 기준이 비어 있음 |
| 2. 대상 스키마 | 키, 파티션, nullable, 기존 소비자와의 호환성 | 변경 전후 스키마 비교 | 파괴적 변경의 승인자·영향 범위가 없음 |
| 3. 변환 | 조인, 집계, 시간대, 중복 제거, 지표 정의 | 요구사항과 SQL/Dataform diff | 자연어 요구와 계산식이 서로 맞지 않음 |
| 4. 스케줄 | 실행 시각, 의존 작업, 재시도, 지연 허용치 | staging 실행 계획과 의존성 목록 | 원본 갱신보다 먼저 실행되거나 중단 기준이 없음 |
| 5. 권한 | 서비스 계정, 읽기·쓰기 범위, 운영자 역할 | 최소 권한 검토 기록 | 과도한 권한 또는 책임 주체가 불명확함 |
| 6. 실행 증거 | 대표·빈·지연 입력 결과, row count, freshness, 오류 로그 | staging 실행 ID와 비교 결과 | 대표 입력 한 번의 성공 외에 기록이 없음 |
| 7. 롤백 | 되돌릴 버전, 담당자, 중단 임계값, 영향 대시보드 | 복구 절차와 연락 경로 | 되돌릴 지점 또는 실행 담당자가 비어 있음 |
카드를 실제로 쓰는 예시
“지난 30일 구매 전환을 일별로 집계해 달라”는 요청을 AI가 받았다고 가정해 보겠습니다. 이때 변환 칸에는 전환의 정의와 시간대 가정을 적고, 대상 스키마 칸에는 날짜·캠페인·전환 수의 키와 nullable 여부를 비교합니다. 실행 증거 칸에는 정상 기간뿐 아니라 구매가 전혀 없는 날짜와 늦게 들어온 이벤트가 포함된 기간의 결과를 함께 남깁니다. 이렇게 해야 숫자가 나왔다는 사실과 그 숫자를 운영 지표로 써도 되는가를 구분할 수 있습니다.
staging에서 먼저 넣어 볼 3가지 실패
실패 주입은 파이프라인을 일부러 망가뜨리자는 뜻이 아닙니다. 실제 운영에서 자주 만나는 입력을 staging에서 먼저 통과시켜, 보류 조건이 제대로 작동하는지 확인하는 절차입니다.
- 빈 입력: 원본 파티션에 행이 없을 때 대상 테이블이 의도한 빈 결과를 만들고, 기존 데이터를 덮어쓰지 않는지 확인합니다. row count가 0인 사실과 오류 여부를 함께 남깁니다.
- 지연 입력: 원본 데이터가 예정 시각보다 늦게 도착했을 때 재시도·대기·중단 중 무엇을 선택하는지 확인합니다. stale 결과를 정상 완료로 기록하지 않는 기준이 필요합니다.
- 호환성이 깨지는 스키마: 필요한 컬럼이 빠지거나 타입이 바뀐 입력을 넣어 봅니다. 실패해야 할 경우에는 조용히 null로 흘려보내지 말고, 담당자가 볼 수 있는 오류와 영향 범위를 남겨야 합니다.
보류가 필요한 신호: 개인정보 포함 여부를 모른 채 범위를 넓히는 경우, 다운스트림 대시보드의 소유자를 모르는 경우, 또는 롤백 담당자가 정해지지 않은 경우입니다. 이 세 가지는 파이프라인 코드가 깔끔해 보여도 운영 반영 근거가 되지 않습니다.
배포·보류·롤백은 어떻게 가를까
| 상태 | 선택 조건 | 바로 할 일 |
|---|---|---|
| 배포 검토 | 7칸이 모두 채워지고, 세 가지 staging 입력의 결과와 영향 범위가 기록됨 | 담당자가 운영 실행을 승인하고 첫 실행을 관찰합니다. |
| 보류 | 증거·권한·스키마 호환성·중단 기준 중 하나가 비어 있음 | 빈 칸의 책임자와 마감 시점을 정하고 staging에서 재검증합니다. |
| 롤백 | 운영 실행에서 합의한 중단 임계값을 넘거나 다운스트림 영향이 확인됨 | 기록된 버전으로 되돌리고, 영향받은 사용자와 지표를 확인합니다. |
여기서 핵심은 “AI가 만든 변경이라서 더 엄격하게 본다”가 아닙니다. 사람이 만든 변경에도 같은 카드가 필요합니다. 다만 생성 속도가 빨라질수록 검토의 병목은 코드 작성이 아니라 근거를 모으고 책임을 명확히 하는 과정으로 이동합니다.
배포 직전 10분 마감 체크리스트
- 원본 테이블·갱신 주기·민감 정보 범위를 확인했나요?
- 키·파티션·nullable·기존 소비자에 대한 스키마 비교를 남겼나요?
- 요구사항과 실제 SQL/Dataform의 조인·시간대·집계 정의가 맞나요?
- 대표·빈·지연 입력의 staging 실행 ID, row count, freshness, 오류 로그가 있나요?
- 서비스 계정의 읽기·쓰기 범위가 필요한 수준으로 제한됐나요?
- 되돌릴 버전, 실행 담당자, 중단 임계값, 영향받는 대시보드가 적혀 있나요?
체크가 끝나면 카드 자체를 변경 요청에 붙여 두세요. 다음 날 이상 징후가 생겼을 때 “누가 무엇을 확인했는가”를 다시 추측하지 않아도 됩니다. 데이터 에이전트에 노출할 범위를 먼저 정해야 한다면 검증된 질의 표면 계약, 결과 자체의 품질 기준이 필요하다면 데이터 품질 릴리스 게이트, 범용 변경 기록을 함께 다루려면 AI 에이전트 desired-state 변경 기록도 이어서 보시면 좋습니다.
자주 묻는 질문
AI가 만든 SQL을 사람이 전부 다시 작성해야 하나요?
그럴 필요는 없습니다. 다만 요구사항과 실제 변환의 차이를 검토하고, 입력·출력·권한·실행 결과를 재현 가능한 증거로 남겨야 합니다. 카드의 목적은 재작성보다 인수 판단을 빠뜨리지 않는 데 있습니다.
대표 기간이 정상으로 나오면 충분하지 않나요?
충분하지 않습니다. 빈 입력, 늦은 입력, 타입이나 컬럼이 달라진 입력은 운영에서 반복되는 조건입니다. 세 조건에서 멈춤·재시도·오류 기록이 어떻게 동작하는지 확인해 주세요.
스키마 변경은 항상 보류해야 하나요?
항상 그런 것은 아닙니다. 호환성, 영향을 받는 소비자, 승인자, 되돌리는 방법이 명확하면 검토할 수 있습니다. 반대로 이 정보가 없으면 작은 변경도 보류하는 편이 낫습니다.
권한은 어떤 수준까지 적어야 하나요?
실행 주체가 어떤 원본을 읽고 어디에 쓸 수 있는지, 운영 중 누가 권한을 변경할 수 있는지를 적어 두면 됩니다. 필요한 범위보다 넓은 접근은 별도 검토 대상으로 남겨 주세요.
롤백 기준은 오류가 난 뒤에 정해도 되나요?
아닙니다. 운영 반영 전에 되돌릴 버전과 담당자, 중단할 조건, 확인할 영향 범위를 정해야 합니다. 그래야 이상이 생겼을 때 원인 분석과 복구가 서로 엉키지 않습니다.
참고 자료
이 글이 마음에 드세요?
FLOWIT on YouTube
영상으로도 FLOWIT을 이어서 보세요
AI 자동화, Claude Code, n8n, 데이터 분석 흐름을 블로그와 영상으로 함께 정리하고 있습니다.
Related Notes
같이 읽으면 좋은 FLOWIT 글
AI 에이전트를 운영 중인데, 모니터링은 뭘 봐야 할까? 5계층 관측 카드프로덕션 AI 에이전트의 건강 상태를 5계층(도구 호출·토큰/비용·세션 이상·출력 품질·사용자 피드백)으로 나누고, 각 계층의 지표·임계값·알림·개입 기준을 6칸 카드로 설계하는 실무 프레임워크.
AI 코딩 에이전트, 벤치마크 1위면 도입해도 될까? 우리 저장소에서 먼저 돌릴 10개 업무 실험 카드AI 코딩 에이전트의 외부 점수와 데모만으로 결정하지 마세요. 대표 업무 10개와 5개 관측칸으로 1주 파일럿을 설계하는 방법을 정리합니다.
AI 에이전트 승인창이 많을수록 안전할까? 장기 작업의 승인 피로를 막는 5칸 개입 예산장기 실행 AI 에이전트에서 승인 알림만 반복하지 않도록, 비가역성·계획 이탈·새 권한을 기준으로 재승인 지점과 증거 묶음을 설계하는 5칸 개입 예산을 정리합니다.