데이터 정리 스크립트는 결측치·형식 통일·중복 제거 같은 규칙형 오류에서는 90% 안팎의 정확도를 보였지만, 맥락 판단이 필요한 값 해석에서는 사람이 정리한 쪽이 더 정확했다[1]. 이번 실험은 "어디까지 스크립트에 맡기고 어디서 사람 검토로 넘길지"의 경계선을 실제 조건으로 확인하는 데 초점을 맞췄다. 결론부터 말하면, 자동화 여부를 가르는 기준은 데이터 크기나 양이 아니라 "판단이 필요한가"였다.
데이터 정리 스크립트, 어디까지 자동으로 넘겨도 될까?
규칙으로 서술 가능한 오류(형식 불일치, 결측 패턴, 중복 레코드)는 스크립트가 처리하고, 값의 의미를 해석해야 하는 오류는 사람 검토로 남기는 편이 재현 가능했다. 2026년 비교 연구에서는 50,000명 규모 직원 데이터에 결측 30%, 잘못된 값 25%, 형식 불일치 45%를 섞은 조건에서 자동 정리가 형식 통일 92%, 통계 정확도 88%를 기록했지만, 맥락 의존적인 복합 사례에서는 사람이 정리한 쪽이 95% 정확도로 더 나았다[1]. 즉 "자동화가 이긴다"거나 "사람이 이긴다"가 아니라 오류 종류에 따라 승자가 갈렸다는 점이 이번 판단의 출발점이었다.
- 형식·결측·중복 같은 규칙형 오류는 자동 스크립트가 속도·비용에서 유리하다[1]
- 맥락 해석이 필요한 값은 사람 검토가 정확도 우위를 유지한다[1]
- 자동화 여부를 가르는 기준은 "판단이 필요한가"이지 데이터 규모가 아니다
- 벤치마크 결과는 모델·버전에 따라 갈리므로 도구 이름만으로 일반화하면 위험하다[11]
이번 실험에서는 사내 CSV 정리 파이프라인 하나를 대상으로, 규칙 기반 정리 구간과 판단 필요 구간을 코드 레벨에서 분리했을 때 처리 시간과 재작업 빈도가 어떻게 달라지는지 확인했다. 스크립트 자체보다 "어디서 스크립트를 멈추고 사람에게 넘길지"를 정하는 규칙이 실제 작업량의 대부분을 차지했다.
규칙 구간과 판단 구간을 스크립트에서 어떻게 나눴나?
컬럼별로 "규칙만으로 정답이 정해지는가"를 먼저 분류하고, 아니라고 판단되면 자동 수정 대신 플래그를 남기는 방식으로 설계했다. 날짜 형식 통일이나 공백 제거, 대소문자 정규화처럼 정답이 하나로 수렴하는 작업은 함수로 고정했고, "이 주소가 오탈자인지 실제 지명 변형인지" 같은 항목은 자동 수정하지 않고 별도 컬럼에 표시만 남겼다. 이 접근은 CHI 2026에서 제안된 AstraClean-RAG의 구조와 방향이 비슷하다. 이 연구는 도메인 규칙과 과거 사람 검증 로그를 함께 불러오되, 둘이 충돌하면 자동으로 결론을 내지 않고 충돌 지점을 요약해 사람 검토로 넘기도록 설계했다[6].
이 설계에서 얻은 감각은 "판단 구간을 줄이려 하지 말고, 판단 구간을 명확히 드러내는 데 시간을 쓰라"는 것이었다. 처음에는 판단이 필요한 컬럼도 규칙을 더 세밀하게 쪼개면 자동화될 것이라 기대했지만, 규칙을 늘릴수록 예외 규칙이 함께 늘어나는 패턴이 반복됐다. 결국 판단 구간은 줄이는 대상이 아니라 "잘 드러내는" 대상으로 다루는 편이 유지보수 비용을 낮췄다.
실제로 스크립트를 짜면서 어디서 막혔나?
가장 많이 걸린 지점은 규칙 자체가 아니라 규칙을 적용하기 전 단계, 즉 원시 데이터의 비표준화였다. 보험 업무 자동화 사례에서는 8,200건의 고객 레코드를 자동화 대상으로 삼기 전에 비표준 주소 5%, 이메일 오류 3.3%, 중복 1.1%를 먼저 정리했고, 구조화된 입력·API 지원·검토 불필요라는 세 조건을 만족할 때만 직행 처리로 분류해 일일 업무의 78%를 자동화 가능으로 판단했다[2]. 이번 실험에서도 순서가 같았다. 정규화·중복 제거 같은 전처리를 먼저 끝내지 않으면, 뒤에 붙는 판단 로직이 무엇을 검토해야 하는지조차 정의할 수 없었다.
두 번째로 걸린 지점은 "형식이 맞는데 값이 틀린" 경우였다. 형식 검증만으로는 통과되지만 실제로는 오기입인 값들이 존재했고, 이 값들은 규칙으로 잡히지 않아 자동 정리 결과에 조용히 섞여 들어갔다. 이 문제는 스크립트를 더 정교하게 짜서 해결하기보다, 애초에 "형식 통과 = 값이 맞다"는 가정을 버리고 별도 검증 단계를 추가하는 쪽으로 수정했다.
규칙 기반 자동 처리와 사람 검토, 정확도 차이는 실제로 얼마나 났나?
작업 목적에 맞춰 워크플로를 자동 생성하는 방식은 목적을 명확히 줄 때만 성과가 안정적이었다. AutoDCWorkflow 벤치마크는 원시 표와 분석 목적을 입력받아 OpenRefine 작업 흐름을 생성하는 방식으로, 142개 목적과 96개 표로 구성된 벤치마크에서 평가됐다[11]. 이 벤치마크는 평가 축을 Purpose Answer(정답 여부), Column(Value), Workflow(Operations)로 나눠 "정답을 맞혔는가"와 "사람이 짠 순서와 비슷한가"를 분리해서 봤다는 점이 실무에 유용했다[11]. 모델별로는 Llama 3.1, Mistral, Gemma 2가 기준선보다 나았고, 그중 Gemma 2-27B는 답변·테이블 품질이 좋았던 반면 Gemma 2-9B는 사람이 짠 워크플로와 유사한 순서를 만드는 데 강했다[11]. "최신 모델이면 다 된다"는 식으로 뭉뚱그리기 어렵다는 뜻이다.
정제 자체가 잘 된다고 최종 품질이 항상 올라가는 것도 아니었다. PrefCleanBench(NeurIPS 2025)는 13개 정제 방법을 다중 데이터셋·모델·최적화 조합에서 비교하도록 표준화한 선호 데이터 정제 벤치마크인데, 정제 전략의 일반화 가능성과 이후 모델 정렬 성능을 함께 평가해 "오류를 줄이는 것"과 "최종 품질이 오르는 것"이 항상 같은 방향이 아님을 보여줬다[12].
이 실험이 안 통하는 지점은 어디인가?
이번 실험은 사내 CSV 파이프라인 하나를 대상으로 한 소규모 관찰이라, 다른 도메인이나 더 복잡한 스키마에 그대로 옮기면 판단 구간의 비율 자체가 달라질 수 있다. 벤치마크 수치도 조건에 따라 갈렸다. Gemma 2-27B와 9B가 서로 다른 지표에서 강점을 보인 것처럼[11], 어떤 모델·버전을 쓰느냐에 따라 결과가 달라지므로 "이 방식이면 항상 이 정확도가 나온다"고 옮기기는 어렵다. 실제 운영에서는 판단 구간을 "표시만 하고 넘기는" 로직 자체를 설계·유지하는 비용도 무시할 수 없었다. 이 로직이 허술하면 규칙형 오류인지 판단형 오류인지 애초에 잘못 분류되고, 그 오분류는 자동 정리 결과에 그대로 섞여 들어간다. 결국 "사람 검토 구간을 남긴다"는 설계 자체가 저절로 안전을 보장하지 않는다는 점이 이번 한계였다.
다음 실험에서는 무엇을 바꿀 것인가?
다음 라운드에서는 판단 구간으로 넘어간 항목이 실제로 사람에게 검토됐는지, 그 검토 결과가 다시 규칙으로 편입될 수 있는지를 로그로 추적할 계획이다. AstraClean-RAG가 과거 사람 검증 로그를 다시 불러와 규칙 충돌 판단에 활용하는 구조를 제안한 것처럼[6], 검토 이력을 버리지 않고 다음 정리 라운드의 입력으로 되먹이는 구조를 시험해볼 예정이다. 또한 Xavier 같은 탭형 데이터 랭글링 스크립트 작성 지원 도구가 16명의 데이터 분석가를 대상으로 사용성 연구를 거친 것처럼[14], 스크립트를 짜는 사람 입장에서 "판단 구간을 어떻게 더 빠르게 확인하는가"도 다음 실험 축으로 다룰 필요가 있다고 보고 있다.
핵심 정리
- 데이터 정리 자동화의 승패는 데이터 규모가 아니라 오류 종류로 갈렸다: 형식·결측·중복은 자동 처리가 92%대, 맥락 의존 사례는 사람 정리가 95%로 더 나았다[1]
- 자동화 전 전처리(정규화·중복 제거)를 먼저 끝내지 않으면 판단 로직 자체를 정의할 수 없었다[2]
- 워크플로 자동 생성은 목적을 명확히 줄 때 성과가 나오며, 모델별로 강점 지표가 달랐다(Gemma 2-27B vs 2-9B)[11]
- 정제 성능이 오른다고 최종 품질이 항상 오르는 것은 아니다[12]
- 판단 구간을 "표시만 하고 넘기는" 구조 자체의 유지비용도 설계에 포함해야 한다