Post

LLM이 만든 변환 코드를 dbt처럼 안전하게 실행해보자

LLM이 생성한 변환 코드를 schema 계약과 대조해 검증을 통과해야만 결과를 반환하는 샌드박스를 만들었다

LLM이 만든 변환 코드를 dbt처럼 안전하게 실행해보자

LLM이 만든 변환 코드를 dbt처럼 안전하게 실행해보자

LLM이 만든 변환 코드를 그대로 실행했더니 출력 스키마가 달라지거나 컬럼이 사라졌다. dbt처럼 계약을 먼저 정의하고 검증을 통과해야만 결과가 반환되는 구조를 만들었다.

1. 서론 (Introduction)

  • 문제/상황 (Problem): LLM이 만든 데이터 변환 코드를 직접 실행하면 출력 스키마가 예상과 달라지는 경우가 있었다. 실행 전에 기계적으로 검증하지 않으면 데이터가 조용히 깨진다.
  • 목적 (Purpose): schema로 출력 계약을 정의하고, LLM 생성 변환 코드를 실행한 뒤 결과를 계약과 대조해 검증하는 샌드박스를 만든다.
  • 대상 (Target Audience): LLM 생성 데이터 변환 코드를 안전하게 프로덕션에 적용하고 싶은 데이터 엔지니어.

2. 방법 및 과정 (Methods & Process)

  • 배경 조사 및 데이터 (Data Collection): 변환 결과의 스키마를 딕셔너리로 미리 정의해두는 dbt의 schema.yml 관례를 참고했다. 컬럼 이름·데이터 타입·not-null 제약을 명시하고, LLM 코드가 만든 결과물을 이 계약과 대조하는 방식이다. 예를 들어 monthly_sales 모델은 month(date, not_null), revenue(float, not_null) 두 컬럼을 계약으로 갖는다.
  • 접근 방법 (Approach Methods):
    • [방법 1]: 실행 전 계약 정의. 컬럼 이름·타입·not-null 여부를 딕셔너리로 미리 선언해둔다.
    • [방법 2]: 실행 후 계약 검증. LLM이 생성한 변환 함수를 실행한 뒤 결과 DataFrame의 컬럼명·타입·not-null 위반을 계약과 대조한다. 위반이 있으면 결과를 반환하지 않고 즉시 예외를 던진다.
  • 분석 및 해결 프로세스 (Analysis Flow):
    • 도구/기술: pandas, 딕셔너리 기반 schema 계약.
    • 주요 단계: LLM 변환 함수 생성 $\rightarrow$ pandas로 실행 $\rightarrow$ 결과 DataFrame을 schema와 대조 $\rightarrow$ (위반) 예외 반환·결과 미반환 / (통과) 결과 반환.
    • 결과 도출 및 검증: 컬럼명을 잘못 지은 변환(revenue 대신 sales)을 계약 검증 단계에 통과시켜보니 “컬럼 누락” 예외로 즉시 차단됐다. 계약을 지키는 변환은 검증을 통과해 정상적으로 결과가 반환됐다.

3. 결과 (Results)

  • 분석 결과 요약: 스키마 위반 변환이 검증 단계에서 차단돼 잘못된 스키마가 이후 단계로 넘어가지 않았다. 계약이 문서화 역할도 해서 변환의 기대 출력을 코드가 아닌 계약 딕셔너리로 확인할 수 있었다.

4. 인사이트 및 액션 (Insights & Action)

  • 인사이트 (Insight): LLM이 만든 코드는 “계약 먼저” 없이는 프로덕션에 쓸 수 없다. 계약이 있어야 오류가 조용히 넘어가지 않고 즉시 표면화된다.
  • 실행 방안 (Action Plan): schema 계약을 LLM 코드 생성 프롬프트에 포함시키면 LLM이 계약을 지키는 코드를 처음부터 만든다. 사후 검증이 아닌 사전 가이드로 쓴다.
  • 한 줄 결론 (Key Takeaway): 계약 검증이 있는 샌드박스에서만 LLM 생성 변환 코드가 안전하다. 샘플 코드
  • 다음 스텝 (Next Step): 지금은 타입·not-null 정도만 검증하는데, dbt의 증분 빌드(incremental)나 ref() 같은 의존성 추적까지 붙이면 매번 전체를 재실행하지 않고도 안전한 파이프라인을 만들 수 있을 것 같다.
This post is licensed under CC BY 4.0 by the author.