Executive Summary

주요 수치

네 숫자는 서로 다른 두 벤치마크에서 왔습니다. 오탐과 F1, 놓침은 다섯 개 실데이터에 60개 과업을 붙여 1,500번의 통과·차단을 판정한 종단 벤치마크 EIDBench의 결과이고, 48/63은 코드에 숨은 제약을 하나씩 찾아내는 능력만 따로 재는 벤치마크 ICDBench 63개 사례의 결과입니다.

앞의 세 숫자는 과업 코드를 읽힌 결과이고, 마지막 숫자는 그 대가로 남은 구멍입니다.

출처: arXiv:2604.21765 표 2·3

논문은 인수합병 뒤의 흔한 장면에서 출발합니다. 큰 여행사가 예약 앱을 만든 스타트업을 사들이고, 본사 데브옵스 팀이 스타트업의 서비스들을 회사 데이터 레이크에 붙입니다. 매일 밤 ETL 파이프라인이 예약 데이터를 밀어 넣고, 그 데이터를 세 갈래가 받아 씁니다. 할인을 계산해 안내 메일을 보내는 배치 작업, 진행 중인 예약을 집계하는 일일 리포트, 예약 완료 확률을 예측하는 모델 학습입니다. 테이블에는 이름, 이메일, 지역, 고객 등급, 매출, 상태 여섯 개 칼럼이 있습니다.

주말 장애에 지친 팀은 데이터 유닛 테스트를 붙입니다. 기존 데이터의 표본을 Deequ에 주고 제약 추천 기능을 돌리면, 프로파일링과 휴리스틱을 거쳐 칼럼별 결측률과 값 범위에 대한 제약이 나옵니다. 파이프라인은 이제 새 배치마다 이 테스트를 돌려 통과 여부를 판단합니다. 그다음 사흘 밤에 일어난 일이 이 논문의 문제 제기입니다.

첫째 밤, 테스트는 배치를 통과시켰고 배치 작업이 죽었습니다. 원인은 코드 안에만 있던 조건이었습니다. 상태 칼럼이 완료로 표시된 레코드는 이메일 칼럼에 유효한 값이 있어야 하는데, 데이터 분포만 본 제약 추천은 이 조건부 의존성을 볼 수 없었습니다. 둘째 밤에는 반대 방향으로 틀렸습니다. 테스트가 지역 칼럼의 GER 값과 고객 등급 3을 낯선 값으로 보고 배치를 격리했지만, 스타트업 엔지니어에게 물어보니 GER는 레거시 예약 시스템이 이따금 만들어 내는 값이고 3은 드물지만 유효한 특별 등급이었습니다. 셋째 밤, 사람이 판단해 배치를 통과시키자 이번에는 모델 학습이 죽었습니다. 전처리 코드가 매출을 표준편차로 나눠 정규화하는데 그 배치의 표준편차가 0이어서 학습 데이터에 NaN이 들어갔습니다.

세 사건의 공통점은 데이터 쪽에 있지 않습니다. 첫째는 분기문에, 둘째는 코드가 이미 처리하고 있던 허용 값에, 셋째는 나눗셈 한 줄에 답이 있었습니다. 데이터가 깨끗한지 묻는 질문은 그 데이터로 무엇을 하는지 정하지 않으면 닫히지 않습니다. 같은 배치가 리포트 작업에는 안전하고 모델 학습에는 치명적일 수 있으니, 파이프라인 한가운데에 놓인 단일 테스트로는 애초에 답할 수 없는 질문입니다.

PrismaDV는 하나의 큰 모델에게 테스트를 써 달라고 부탁하는 방식이 아닙니다. 표본 데이터와 과업 코드를 입력으로 받아, 역할이 나뉜 모듈을 순서대로 지나며 제약을 만들어 냅니다. 프로파일링과 후처리는 일반 코드가 담당하고, 코드를 읽는 중간 단계에서만 언어 모델을 호출합니다.

• 프로파일링. 표본에서 스키마와 값 분포 같은 기본 통계를 계산합니다. 기존 도구와 출발점이 같은 단계입니다.
• 칼럼 접근 탐지. 과업 코드가 실제로 읽는 칼럼과 함께 읽는 칼럼 조합을 찾습니다. 쓰지 않는 칼럼에 대한 제약은 오탐만 만들기 때문에 검증 범위를 먼저 좁힙니다.
• 데이터 흐름 분석. 그 칼럼들이 어느 줄에서 어떻게 비교되고 계산되고 분기되는지 따라가 암묵적 가정을 추론합니다. 나눗셈에 쓰이는 칼럼, 조건문이 걸린 칼럼, 라이브러리 함수에 그대로 넘겨지는 칼럼이 각각 다른 요구를 남깁니다.
• 제약 코드 생성과 사전 검사. 추론한 가정을 PyDeequ 문법의 실행 가능한 제약으로 옮기고, 문법이 깨지거나 실행되지 않는 제약은 버립니다.

기존 도구의 파이프라인은 사실상 첫 단계에서 끝납니다. 표본을 프로파일링하고 휴리스틱으로 제약을 추천하면 그것이 결과물입니다. PrismaDV가 뒤에 붙이는 두 단계가 갈라지는 지점입니다. 과업 코드에서 어떤 칼럼이 읽히는지 확인해 검증 범위를 먼저 좁히고, 그 칼럼이 코드 안에서 어떻게 쓰이는지 따라가 제약의 내용을 정합니다. 같은 표본을 넣어도 코드가 입력에 함께 들어오면 나오는 제약이 달라집니다.

앞의 예약 데이터로 돌아가면 각 단계가 하는 일이 분명해집니다. 배치 작업 코드에서 상태 칼럼과 이메일 칼럼이 함께 읽히는 것을 찾아내면 두 칼럼을 묶은 조건부 제약이 후보로 올라오고, 매출 칼럼이 표준편차로 나뉘는 줄을 찾아내면 그 배치의 표준편차가 0이 아니어야 한다는 요구가 생깁니다. 반대로 지역 칼럼의 허용 값이 코드에 화이트리스트로 적혀 있으면 GER는 이상값이 아니라 정상값으로 처리됩니다.

제약을 많이 만드는 것이 목표가 아니라는 점도 수치에 남아 있습니다. 제약 발견 벤치마크에서 Deequ가 사례당 평균 1.9개, PrismaDV가 2.6개를 만든 반면 코드를 함께 주고 그냥 물어본 방식은 3.1개에서 3.5개까지 만들어 냅니다. 더 많이 만든 쪽이 오탐도 훨씬 많았고, 문법이 깨져 실행조차 안 되는 제약도 섞여 있었습니다. PrismaDV는 사전 검사 단계를 거쳐 테스트 시점의 제약이 전부 실행 가능한 상태로 남습니다.

시스템 안쪽에는 데이터·코드 가정 그래프가 남습니다. 칼럼과 코드에서 추론된 가정을 잇는 구조여서, 생성된 제약 하나를 집으면 그 근거가 된 코드 위치와 자연어로 적힌 가정까지 거슬러 갈 수 있습니다. 매출이 0이 아니어야 한다는 제약이 왜 붙었는지 물으면 정규화하는 줄을 가리키는 식입니다.

그래프의 한쪽에는 과업이 실제로 읽는 입력 칼럼이 놓이고 다른 한쪽에는 과업 코드에서 추론된 암묵적 가정이 놓입니다. 두 종류의 노드만 있고 같은 종류끼리는 이어지지 않는 이분 구조입니다. 칼럼에서 출발하면 그 칼럼에 걸린 가정이 전부 나오고, 가정에서 출발하면 그 가정을 만들어 낸 코드 위치와 그로부터 합성된 제약이 나옵니다.

이 구조가 실무에서 중요한 이유는 검증 규칙이 결국 사람의 손을 거치기 때문입니다. 자동 생성된 제약을 팀이 신뢰하려면 틀렸을 때 어디를 고쳐야 하는지 알 수 있어야 합니다. 근거를 못 대는 제약은 한 번 오탐을 내면 그대로 꺼지고, 꺼진 규칙은 다시 켜지지 않습니다. 자연어 가정을 중간 표현으로 둔 설계 덕분에, 논문은 같은 가정을 Great Expectations나 파이썬 assert 문 같은 다른 문법으로 옮길 여지도 열어 둡니다.

CIKM 2026 데모는 이 그래프를 웹 화면에서 직접 다루게 만든 버전입니다. 참석자는 다섯 개 실데이터와 60개 과업에 시스템을 돌려 가정과 제약을 만들고, 그래프를 따라가며 가정을 고치고, 오류가 섞인 배치에서 과업을 아는 테스트와 모르는 테스트를 나란히 돌려 비교합니다. 데이터 팀이 규칙을 검토하는 작업이 목록 확인이 아니라 근거 확인이 되는 그림입니다.

논문 두 편을 구분해 두면 찾아 읽기 편합니다. 데모를 소개한 쪽은 제목이 질문 그대로인 "Will This Data Break My Task?" - Interactive Synthesis of Task-Aware Data Unit Tests(arXiv:2608.09376, 2026년 8월 10일 등재)이고, 방법과 벤치마크를 상세히 다룬 본 논문은 넉 달 앞선 PrismaDV: Automated Task-Aware Data Unit Test Generation(arXiv:2604.21765)입니다. 이 글의 수치는 모두 뒤쪽에서 왔습니다. 구현은 deem-data/PrismaDV 저장소에 공개돼 있어, 네 단계가 실제로 어떤 프롬프트와 후처리로 돌아가는지 직접 확인할 수 있습니다.

헛경보가 몇 건이고 놓친 오류가 몇 건인지는 저자들이 새로 만든 두 벤치마크에서 나옵니다. 성격이 서로 다른데, 하나는 코드에 숨은 가정을 하나씩 찾아내는 능력만 재는 쪽입니다. 63개 사례마다 데이터 표본과 이를 처리하는 코드, 숨은 가정의 자연어 서술, 정답 제약이 붙어 있고, 통과해야 할 데이터와 거절해야 할 데이터가 따로 준비돼 있습니다. 결제 처리, 크리켓 경기 규칙, 게임 내 경매처럼 도메인이 다양하고, 명시적 assert처럼 쉬운 사례부터 제어 흐름에 흩어진 칼럼 의존성과 머신러닝 라이브러리의 동작 지식이 필요한 사례까지 섞여 있습니다.

이 벤치마크에서는 결과가 한 방향으로 갈립니다. PrismaDV는 통과해야 할 데이터 63건 중 61건을 통과시키고 거절해야 할 데이터 63건 중 48건을 막았습니다. Deequ는 각각 44건과 27건, TensorFlow Data Validation은 32건과 32건이었습니다. 이상치 탐지 계열은 거의 모든 데이터를 막거나 전부 통과시켜 사실상 판정을 못 했습니다.

다른 하나는 종단 벤치마크입니다. 다섯 개 데이터셋에 60개 과업이 딸려 있고, 데이터셋마다 오류를 주입한 배치 25개가 준비됩니다. 한 배치가 모든 과업에 해로운 것은 아니라서 1,500번의 판정 가운데 827건은 통과가 정답이고 673건은 차단이 정답입니다. 과업 코드에서 정답 판정에 쓰인 assert 블록을 떼어 낸 뒤 각 방법에 테스트를 만들게 하고, 그 테스트의 통과·차단 결정을 정답과 맞춰 봅니다.

표에서 오탐 열과 차단 열을 함께 보면 기존 도구가 실제로 무엇을 하고 있었는지 드러납니다. Deequ는 해로운 배치 673건 중 560건을 막아 냈습니다. 차단 실적만 보면 PrismaDV의 368건보다 좋습니다. 다만 같은 테스트가 안전한 배치 827건 중 693건도 함께 막았습니다. 여덟 번 중 여섯 번 넘게 헛경보를 울리는 테스트는 며칠 안에 꺼지거나 무시되고, 그렇게 꺼진 테스트의 차단율은 종이 위 숫자로만 남습니다.

PrismaDV 쪽 수치도 자랑만 담고 있지 않습니다. GPT-5를 백본으로 쓴 구성은 오탐을 112건까지 줄이는 대신 해로운 배치 305건을 통과시켰습니다. Gemini 2.5 Pro로 바꾸면 놓침이 195건으로 줄고 오탐이 230건으로 늡니다. 저자들도 이 지점을 백본에 따라 달라지는 선호로 설명하며, 헛경보와 놓침 중 무엇을 덜 견딜 수 있는지에 따라 모델을 고르라고 적었습니다. 어느 구성도 두 오차를 동시에 0으로 만들지는 못합니다.

시간이 지나며 테스트를 다듬는 장치도 함께 제안됐습니다. SIFTA는 테스트와 과업을 실제로 돌려 얻은 드문 성공·실패 신호에서 정보량이 큰 사례를 골라 모듈의 프롬프트를 갱신하는 최적화 방식입니다. 새 데이터에 적응하는 시나리오에서 다섯 데이터셋 평균 F1이 72.8%로, 사람이 손으로 쓴 프롬프트의 67.7%와 범용 프롬프트 최적화의 65% 안팎을 앞섰습니다. 다만 새 과업 시나리오에서는 69.8%와 67.3%로 격차가 줄고, 데이터셋별로 보면 손으로 쓴 프롬프트에 지는 칸도 있습니다.

무엇을 정보량이 큰 사례로 볼지가 이 방식의 이름에 들어 있습니다. Selective Informative Feedback for Task Adaptation의 줄임말인 SIFTA는 칼럼별 실패 정밀도, 곧 그 칼럼의 제약이 실패했을 때 과업도 실제로 실패한 비율을 계산합니다. 이 값이 낮은 과업·칼럼 쌍이 헛경보의 발원지이므로, 최적화를 그 자리에 몰아줍니다. 규칙을 더 촘촘하게 만드는 방향이 아니라 이미 울리고 있는 경보의 근거를 다시 재는 방향입니다.

구성 요소를 하나씩 떼어 보는 실험 결과는 오히려 조심스럽게 읽어야 합니다. 다중 칼럼 제약을 빼면 F1이 0.92%p, 데이터 흐름 분석을 빼면 0.48%p, 가정 추론을 빼면 0.17%p 떨어집니다. 각 모듈이 기여하지만 격차의 대부분은 개별 모듈이 아니라 과업 코드를 입력에 넣었다는 사실에서 나온다는 뜻입니다.

저자들이 밝힌 한계도 짧지 않습니다. 시제품은 파일 하나와 테이블 하나를 쓰는 과업에 맞춰져 있어서, 여러 스크립트에 걸친 데이터 흐름과 조인으로 만들어지는 파생 테이블은 아직 다루지 못합니다. SIFTA는 오류가 관측된 학습 배치가 있어야 작동하는데 실제 운영에서 그런 배치를 모아 두기가 쉽지 않고, 저자들은 오류 주입을 자동화해 콜드스타트를 넘는 방향을 다음 과제로 적었습니다. 종단 벤치마크의 과업 코드 자체가 사람이 검수한 언어 모델 생성물이라는 점도 남습니다. 산업 현장의 실제 코드베이스로 벤치마크를 확장하는 일이 향후 과제 목록의 앞자리에 있습니다.

여기서부터는 논문의 주장이 아니라 데이터 품질을 다뤄 온 쪽에서 얹는 해석입니다. 이 시스템이 바꾸는 것은 검증 기술만이 아닙니다. 품질 점수가 무엇에 붙는지도 함께 바뀝니다. 결측률과 유일성, 값 범위로 데이터셋에 점수를 매기면 그 점수는 데이터셋의 속성입니다. 반면 이 배치가 이 과업을 깨뜨리는지 묻기 시작하면 점수는 데이터와 과업의 쌍에 붙습니다. 같은 테이블이 리포트에는 준비된 상태이고 모델 학습에는 준비되지 않은 상태일 수 있습니다.

판정의 주체도 그만큼 옮겨 갑니다. 품질의 기준은 데이터 팀이 정한 규칙 목록이었습니다. 이제는 사용처의 코드가 요구 조건을 적습니다. AI-Ready라는 말이 데이터셋에 붙는 등급이 아니라 어떤 과업에 대해 준비되었는지를 묻는 관계로 읽히기 시작하는 지점입니다. 페블러스가 모델이 아니라 데이터가 먼저다에서 다룬 준비도 논의, 그리고 Great Expectations 완전 해부에서 짚은 규칙 작성 부담이 같은 축에서 만납니다. 앞 글이 사람이 규칙을 손으로 써야 한다는 문제를 다뤘다면, 이 논문은 그 규칙을 어디서 읽어 올지에 답을 내놓습니다.

시제품이 파일 하나와 테이블 하나에 머물러 있으니 이 시스템을 오늘 파이프라인에 붙일 수는 없습니다. 그런데 판정의 기준을 옮기는 일은 도구를 바꾸지 않아도 시작됩니다. 지금 돌아가는 규칙들을 과업 쪽에서 한 번 읽어 보는 것으로 충분합니다. 실무에서 먼저 확인해 볼 것은 세 가지입니다.

• 지금 돌아가는 데이터 검증 규칙 가운데 몇 개가 실제로 쓰이는 칼럼을 겨냥하고 있습니까. 아무도 읽지 않는 칼럼의 결측률 경보는 오탐 예산만 씁니다.
• 규칙이 왜 생겼는지 답할 수 있습니까. 근거를 못 대는 규칙은 첫 헛경보에 꺼지고, 꺼졌다는 사실이 어디에도 기록되지 않습니다.
• 같은 테이블을 쓰는 과업마다 요구 조건이 다르다는 사실이 파이프라인에 반영돼 있습니까. 단일 관문 하나로 여러 과업을 지키려는 설계가 놓침과 오탐을 동시에 만들어 냅니다.

• 1.Chen, H., Phani, A., Schelter, S. (2026). "Will This Data Break My Task?" — Interactive Synthesis of Task-Aware Data Unit Tests. CIKM 2026 (Demo Track).
• 2.Chen, H., Phani, A., Schelter, S. (2026). "PrismaDV: Automated Task-Aware Data Unit Test Generation." arXiv preprint.
• 3.DEEM Group. "deem-data/PrismaDV" GitHub 저장소 (레퍼런스 구현).