Shift schema drift left: policy-aware compile-time contracts for typed JVM and Spark pipelines

이 논문은 Scala 3 기반의 경량 프레임워크를 통해 컴파일 시 정책 기반의 구조적 호환성을 증명하고, 동일한 계약 타입에서 Spark 스키마를 유도하며, 쓰기 전 DataFrame 스키마를 재검증함으로써 데이터 파이프라인의 스키마 드리프트를 조기에 탐지하는 방법을 제시합니다.

핵심

🍽️ 비유: 요리실 (개발자) 과 식당 (실제 데이터)

이 문제를 이해하기 위해 다음과 같은 상황을 상상해 보세요.

1. 요리실 (코드/개발자): 셰프 (개발자) 는 메뉴판 (코드) 에 "스테이크 1 개, 감자튀김 2 개, 소스 1 개"라고 적어두었습니다.
2. 식당 (실제 데이터): 손님이 주문한 음식이 주방으로 들어옵니다.
3. 문제 (스키마 드리프트):
   • 어느 날, 셰프가 메뉴판을 고쳐서 "감자튀김 2 개"를 **"감자튀김 3 개"**로 바꿨습니다.
   • 하지만 손님이 주문한 음식 (실제 데이터) 은 여전히 "감자튀김 2 개"로 들어옵니다.
   • 이 불일치는 손님이 음식을 먹고 난 후 (데이터를 처리한 후) 에야 발견됩니다. "어? 감자가 부족하네!"라고 외치는 순간, 이미 식당은 혼란에 빠집니다.

기존의 방식은 이 불일치를 손님이 음식을 다 먹고 난 후에야 발견하거나, 아예 모든 요리를 수작업으로 하나하나 세어보는 (Typed-Dataset) 번거로운 방식을 사용했습니다.

---

🛡️ 이 논문이 제안하는 해결책: "이중 보안 시스템"

이 논문은 **"요리실 (코드)"**과 "식당 입구 (실제 데이터)" 두 곳에서 동시에 검사를 하는 새로운 시스템을 제안합니다.

1. 첫 번째 방어선: "요리실의 자동 검사기" (컴파일 타임 검증)

• 무엇인가요? 셰프가 메뉴판 (코드) 을 고칠 때, 자동으로 "이게 기존 규칙과 맞나요?"라고 확인하는 지능형 검사기입니다.
• 어떻게 작동하나요?
  • 셰프가 메뉴판에 "감자튀김 3 개"라고 적으면, 검사기는 "아니야, 원래 계약은 2 개였는데? 이건 계약 위반이야!"라고 코드가 실행되기 전에 바로 경고합니다.
  • 장점: 실수가 식당에 들어가기 전에 막아줍니다. (이걸 '컴파일 타임'이라고 합니다.)
  • 특이점: 이 검사기는 단순히 이름만 보는 게 아니라, "감자튀김이 들어있는 접시 안에 소스가 들어있나요?" 같은 중첩된 구조까지 꼼꼼히 봅니다.

2. 두 번째 방어선: "식당 입구의 최종 검사관" (런타임 검증)

• 무엇인가요? 요리실에서 완벽하게 준비된 음식이 식당 입구 (실제 데이터) 에 도착했을 때, 실제 음식이 메뉴판과 일치하는지 다시 한번 확인하는 검사관입니다.
• 왜 필요한가요? 요리실의 메뉴판은 완벽해도, 외부에서 들어오는 재료 (CSV, JSON 파일 등) 가 엉망일 수 있기 때문입니다.
• 어떻게 작동하나요?
  • "요리실에서는 3 개라고 했지만, 실제로 들어온 접시에 2 개밖에 없네? 이건 계약 위반이야!"라고 데이터를 저장하기 직전에 막습니다.
  • 핵심 기능: 기존 시스템이 놓치던 중첩된 부분의 빈칸 (예: 소스 통이 비어있는지 여부) 까지 꼼꼼히 체크합니다.

---

🎯 이 시스템의 핵심 특징 (정책)

이 시스템은 "어떤 규칙을 따를지"를 미리 정할 수 있게 해줍니다. 마치 식당의 서비스 정책처럼요.

• 엄격한 규칙 (Exact): 메뉴판에 적힌 것과 완벽하게 일치해야 합니다. (감자 2 개면 2 개, 3 개면 거절)
• 유연한 규칙 (Backward/Forward):
  • Backward: 새로운 메뉴가 추가되어도 괜찮습니다. (예: 감자튀김에 케첩이 추가되어도 OK)
  • Forward: 기존 메뉴가 빠지면 안 되지만, 새로운 메뉴가 추가된 건 괜찮습니다.
• 위치 기반: 이름이 달라도 순서만 같으면 OK.

이 논문은 이 모든 규칙을 **코드 작성 단계 (요리실)**와 실제 데이터 도착 단계 (식당 입구) 모두에서 적용할 수 있게 만들어줍니다.

---

💡 왜 이것이 중요한가요?

1. 실수를 미리 잡습니다: 데이터가 망가진 후에 발견하는 대신, 코드를 짤 때 바로 "이건 안 돼!"라고 알려줍니다.
2. 전체 시스템을 갈아엎을 필요가 없습니다: 기존에 쓰던 복잡한 데이터 처리 방식을 모두 바꾸지 않아도, **가장 중요한 문 (데이터가 들어가는 곳)**만 이 시스템으로 지키면 됩니다.
3. 빠르고 가볍습니다: 이 검사기를 거치더라도 시스템 속도가 느려지지 않습니다. (마이크로초 단위의 지연만 발생)

📝 요약

이 논문은 **"요리실 (코드)"**에서 메뉴를 고칠 때 실수가 없도록 자동 검사를 하고, **"식당 입구 (실제 데이터)"**에서 들어오는 음식이 메뉴와 일치하는지 최종 확인하는 이중 보안 시스템을 소개합니다.

이 시스템은 데이터 파이프라인의 실수를 **데이터가 망가지기 전 (컴파일 단계)**에 잡아서, 식당 (시스템) 이 붕괴되는 것을 막아줍니다. 마치 요리사가 실수하지 않도록 돕는 자동 조리대와 손님이 들어오기 전 음식을 다시 확인하는 웨이터가 함께 일하는 것과 같습니다.

---

🚛 특별 기능: "트럭의 깊은 검사" (런타임 검증의 핵심)

대부분의 검사관은 상자 (데이터) 가 들어왔는지 여부만 확인합니다. 하지만 이 시스템의 검사관은 상자 안의 깊은 부분을 확인합니다.

• 일반적인 검사: "상자에 사과가 들어있나요?"만 확인합니다.
• 이 시스템의 검사: **중첩된 리스트나 맵 (Map) 내부의 각 칸이 비어있을 수 있는지 (Nullability/Optionality)**를 정밀하게 확인합니다.
  • 예시: 계약서에 "모든 사과 칸이 채워져 있어야 한다"고 적혀 있는데, 트럭이 "가끔 빈 칸이 있는 사과 상자"를 보내면, 이 검사관이 이를 즉시 잡아냅니다.
  • 중요한 점: 일반적인 중첩 구조의 모양 (Shape) 불일치 전체를 잡는 것이 아니라, 리스트나 맵 값 내부의 '빈 칸 허용 여부' (Optionality/Nullability) 차이를 정확히 감지하는 것이 이 시스템의 핵심 기여입니다. 기존 도구들은 이런 깊은 수준의 빈칸 관련 실수를 자주 놓칩니다.

기술 요약

제시된 논문 "Shift schema drift left: policy-aware compile-time contracts for typed JVM and Spark pipelines" 은 데이터 파이프라인의 스키마 드리프트 (Schema Drift) 문제를 해결하기 위해 컴파일 타임 검증과 런타임 검사를 결합한 새로운 프레임워크를 제안합니다. 저자 Vittal Mirji 는 Scala 3 와 Spark 를 기반으로 한 이 메커니즘이 기존 접근법의 한계를 극복하고 신뢰성을 높일 수 있음을 보여줍니다.

다음은 논문의 핵심 내용을 요약한 기술적 요약입니다.

---

1. 문제 정의 (Problem)

데이터 파이프라인에서 스키마 드리프트는 종종 실제 데이터가 처리될 때 (런타임) 발견되어 심각한 장애를 유발합니다.

• 기존 접근법의 한계:
  • Typed-Dataset 라이브러리 (frameless, iskra 등): 전체 코드를 타입으로 감싸야 하므로 도입 비용이 높음.
  • 테이블 레벨 스키마 강제 (Delta Lake, Iceberg 등): 작성 (Write) 시점에 저장된 스키마와 비교하므로, 이미 작업이 제출된 후의 문제임.
  • 공통된 결함: 선언된 Scala 타입과 실제 실행 시의 Spark 스키마 간의 불일치를 컴파일 타임에 증명하지 못함. 코드는 타입이 안전해 보이지만, 외부 데이터 경계 (Boundary) 에서 런타임 오류가 발생함.

2. 방법론 (Methodology)

이 논문은 Scala 3 매크로 (Macros) 와 Quote Reflection 기술을 활용하여 컴파일 타임 증명과 런타임 검사를 하나의 통합된 흐름으로 결합합니다.

A. 구조적 계약 (Structural Contracts) 모델

• 정의: 비즈니스 규칙이나 시맨틱이 아닌, 레코드 형태 (필드명, 중첩 구조, 컬렉션 모양, 옵셔널 여부, 기본값 등) 에 초점을 맞춘 계약.
• 정책 (Policy) 패밀리: 호환성 판단 기준을 명시적으로 정의합니다.
  • Exact 계열: 필드명/순서/대소문자 민감도에 따른 정밀 일치 (Exact, ExactUnorderedCI, etc.).
  • Subset 계열:
    • Backward: 프로듀서의 추가 필드 허용, 계약의 필수 필드 누락은 옵셔널/기본값일 때만 허용.
    • Forward: 프로듀서 필드가 계약에 모두 존재해야 함 (계약은 더 많은 필드 허용).
  • Full: 모든 구조 허용.

B. 컴파일 타임 증명 (Compile-time Proof)

• 메커니즘: Scala 3 매크로를 사용하여 SchemaConforms[Out, Contract, P] 타입 클래스를 유도 (Derive) 합니다.
• 작동 원리:
  1. Producer 타입 (Out) 과 Contract 타입 (R) 을 정규화된 구조적 모델 (TypeShape) 로 변환합니다.
  2. 명시된 정책 (P) 하에 두 구조를 비교합니다.
  3. 불일치가 발견되면 컴파일을 중단하고 구체적인 경로 (Path) 와 드리프트 원인 (누락된 필드, 추가 필드 등) 을 리포트합니다.
  4. 이 과정은 CI/CD 파이프라인에서 코드 제출 전에 구조적 드리프트를 차단합니다.

C. 런타임 핀 (Runtime Pin) 및 비교기

• 필요성: 컴파일 타임 증명만으로는 CSV/JSON 등 외부 데이터 소스의 실제 스키마 드리프트를 막을 수 없음.
• 작동 원리:
  1. 동일한 Contract 타입에서 Spark StructType 스키마를 유도합니다.
  2. Sink(저장소) 쓰기 직전에 실제 DataFrame 스키마와 유도된 스키마를 비교합니다.
  3. Spark 기본 비교기의 한계 극복: Spark 의 기본 비교기는 중첩 컬렉션의 옵셔널성 (Nested Collection Optionality) 을 체크하지 않는데, 이 프레임워크는 이를 명시적으로 체크합니다.
  4. Subset 정책 (Backward/Forward) 을 런타임에서 실제로 구현하여 Spark 기본 기능에 없는 기능을 제공합니다.

D. 타입드 빌더 (Typed Builder)

• addSink[R, P] 메서드를 통해 컴파일 타임 증명이 있어야만 Sink 를 추가할 수 있도록 강제합니다.
• 빌드된 파이프라인은 실행 시 Sink 쓰기 직전에 다시 한번 런타임 검사를 수행합니다.

3. 주요 기여 (Key Contributions)

1. Scala 3 매크로 기반 구조적 증명: 명시적 정책 하에 Producer 와 Contract 타입의 호환성을 컴파일 타임에 증명하고, 실패 시 상세한 드리프트 진단 리포트를 제공합니다.
2. 정책 인식 런타임 비교기: 컴파일 타임 증명을 런타임 경계와 연결하며, Spark 가 누락한 중첩 컬렉션 옵셔널성 체크와 Subset 의미론 (Backward/Forward) 을 구현했습니다.
3. 재현 가능한 아티팩트:
   • 컴파일 오버헤드가 낮음 (10~50 개의 스키마 쌍 기준 최대 1.88 초 증가).
   • 런타임 비교 오버헤드가 미미함 (스키마 비교당 수 마이크로초~수천 나노초).
   • Spark 기본 비교기보다 느리지만 (약 17~25 배), Sink 쓰기당 한 번만 실행되므로 실용적입니다.

4. 평가 및 결과 (Evaluation & Results)

• 컴파일 타임: 의도된 구조적 경우 (정확 일치, 역/정방향 호환성) 는 통과하고, 필드 재배열, 필수 필드 누락, 중첩 옵셔널성 드리프트 등은 컴파일 실패로 차단함을 확인했습니다.
• 런타임: Spark 가 기본적으로 무시하는 중첩 컬렉션의 옵셔널성 드리프트를 성공적으로 탐지하고, Subset 정책이 런타임에서도 올바르게 동작함을 검증했습니다.
• 성능:
  • 컴파일 타임 오버헤드는 환경에 따라 10~16% 증가했으나, 이는 일회성 비용입니다.
  • 런타임 비교는 매우 빠르며, 전체 파이프라인 성능에 치명적인 영향을 미치지 않습니다.
  • 절대적인 비용은 마이크로초 (μs) 범위로 유지됩니다 (예: 로컬 환경에서 순서 무관 정밀 일치 시 ~4.7μs, Ubuntu 환경에서 ~8.1μs). 이는 행 단위 (per row) 가 아닌 Sink 쓰기당 한 번 실행되기 때문입니다.

5. 의의 및 한계 (Significance & Limitations)

• 의의:
  • Shift Left: 스키마 드리프트 검사를 런타임 실패에서 컴파일 타임/CI 단계로 앞당겼습니다.
  • 실용성: 전체 코드를 타입으로 감싸는 고비용의 Typed-Dataset 방식과 달리, Sink 경계 (Boundary) 에서만 타입 안전성을 강제하여 도입 장벽을 낮췄습니다.
  • 완결성: 컴파일 타임 증명과 런타임 검사를 상호 보완적으로 결합하여 데이터 파이프라인의 신뢰성을 높이는 새로운 패턴을 제시했습니다.
  • 적용 범위: 이 작업은 타입 기반 Dataset 레이어와 테이블 레벨 스키마 강제 사이에서 열려 있는 특정 '이음새 (seam)'를 해결한다는 점에서 의미가 있습니다.
  • 잠재적 도입 비용 절감: 계약 강제를 선언된 Scala Producer 타입과 Contract 타입이 만나는 Sink 경계에 집중함으로써, 전체 Typed-Dataset 재작성에 비해 도입 비용을 낮출 수 있다고 주장합니다. 이는 설계적 주장이며, 논문에서 도입 비용을 경험적으로 측정하지는 않았습니다.
• 한계:
  • 범위: 비즈니스 규칙, 시맨틱, 시간적 속성 (Temporal properties) 등은 검증하지 않으며, 순수한 구조적 (Structural) 호환성만 다룹니다.
  • 지원 형태: Case class 기반의 중첩 구조에 집중되어 있으며, 모든 Spark/Scala 데이터 표현을 지원하지는 않습니다.
  • 생태계: 외부 스키마 레지스트리 통합이나 대규모 산업 현장의 생산성 지표는 아직 포함되지 않았습니다.

결론

이 논문은 타입이 지정된 JVM 및 Spark 파이프라인에서 구조적 스키마 드리프트를 방지하기 위한 작고 정직한 메커니즘을 제시합니다. 이는 선언된 타입과 실제 데이터 경계 사이의 간극을 메우기 위해 컴파일 타임의 강력한 증명과 런타임의 안전장치를 결합한 혁신적인 접근법으로, 데이터 파이프라인의 신뢰성을 높이는 데 중요한 기여를 합니다.