데이터 파이프라인은 모든 검사를 통과하지만 LLM은 조용히 성능 저하된다

요약 — 스키마 유효성 검사, null 체크, 행 개수 모니터링은 AI 데이터 파이프라인의 구조적 실패는 잡아내지만, 클리닝(cleaning), 정규화(normalization), 중복 제거(dedup) 로직 변경으로 인해 발생하는 의미론적 표류(semantic drift)에는 눈이 멀다. 이로 인해 모델과 RAG 시스템은 지속적으로 성능이 저하되지만, 모든 대시보드는 녹색 상태를 유지한다. 해결책은 파이프라인 출력을 단순히 데이터 형태가 아니라 하위 작업 동작에 연결된 회귀 테스트(regression tests)를 가진 버전 관리 아티팩트(versioned artifact)로 취급하는 것이다.

현대 스택의 모든 데이터 품질 도구는 하나의 질문에 답하도록 구축되었다: 데이터의 형태가 깨졌는가? 열이 누락되었는가, null 값이 급증했는가, 행 개수가 세 표준편차를 벗어났는가. 이것들은 좋은 질문이다. 하지만 대부분 실제로 AI 시스템을 프로덕션에서 저하시키는 것들에 대해서는 잘못된 질문이기도 하다.

AI 파이프라인에 중요한 실패 모드는 구조적(structural)이지 않다. 의미론적(semantic)이다. 스키마는 동일하게 유지되고, 행 개수는 허용 범위 내에 있으며, 모든 null 체크를 통과하지만 — 모델은 여전히 성능이 나빠진다. 왜냐하면 아무도 위험하다고 플래그 지정하지 않은 클리닝 단계 아래에서 데이터의 의미가 변경되었기 때문이다.

구조는 의미가 아니다

일반적인 수집(ingestion)부터 학습(training)까지의 파이프라인이 실제로 무엇을 하는지 생각해 보자: 원시 텍스트를 가져와, HTML을 제거하고, 공백을 정규화하며, 거의 동일한 문서를 중복 제거하고, 언어별로 필터링하며, PII(개인 식별 정보)를 마스킹하고, 어쩌면 토큰 예산에 맞춰 잘라낸다. 이 모든 단계는 의미론적 변환(semantic transformation)이다. 그 어떤 것도 스키마에 의해 검사되지 않는다.

이제 누군가가 저장 공간 비용을 절감하기 위해 중복 제거 임계값(deduplication threshold)을 강화했다고 상상해 보자. 파이프라인은 여전히 동일한 유형의 문자열 열, 동일한 근사적 볼륨, 동일한 null 가능성을 가진 열을 방출한다. 하지만 단지 소수 주제에 속하는 비례적으로 큰 부분을 조용히 제거했을 뿐이다. 왜냐하면 그 문서들이 다수 클래스보다 서로 더 유사했기 때문이다. 당신의 스키마 유효성 검사기는 매우 만족할 것이다. 그러나 해당 주제에 대한 검색 품질은 절벽 아래로 떨어졌다.

혹은 PII(개인 식별 정보) 제거 모델이 업그레이드되어 이메일과 전화번호뿐만 아니라 특정 맥락에서 고유 명사처럼 보이는 모든 것을 스크러빙하게 됩니다. 아무것도 깨지지 않습니다. 파이프라인은 정상적으로 작동합니다. 하지만 여러분의 파인튜닝(fine-tuning) 데이터셋은 의미 있는 분량의 개체명(named entities)을 잃게 되고, 모델은 이름과 유사한 어떤 것에도 주저하기 시작합니다.

이것이 BI보다 AI에 더 치명적인 이유

전통적인 데이터 엔지니어링은 구조적 검사만으로도 넘어갈 수 있었습니다. 왜냐하면 소비자가 대시보드나 보고서였고, 사람이 개입하여 숫자가 이상하게 보일 때 알아챌 수 있었기 때문입니다. AI 파이프라인은 그 인간의 체크포인트를 제거합니다. 소비자는 학습 실행(training run)이나 임베딩 인덱스이며, 잘못된 클리닝 변경과 눈에 보이는 증상 사이의 피드백 루프는 몇 주가 걸릴 수 있습니다. 이는 '모델 드리프트(model drift)'로 귀속되는 평가 점수의 느린 침식인데, 실제로는 처음부터 계속 '파이프라인 드리프트(pipeline drift)'였던 것입니다.

이것은 검색 증강 생성(retrieval-augmented generation)에 특히 가혹합니다. RAG 시스템의 품질은 무엇이 인덱싱되었는지의 함수이며, 무엇이 인덱싱되었는지는 상류(upstream)의 모든 정규화 및 청킹(chunking) 결정의 함수입니다. 청킹 경계 로직을 변경하거나, 문장 분리기(sentence splitter)를 바꾸거나, 각주가 본문 텍스트에 병합되는 방식을 변경하면 — 검색 정밀도(retrieval precision)는 왜 그런지 알려주는 구조적 신호 하나 없이 움직입니다. 결국 실제 결함은 세 단계 앞선 파이프라인 스테이지, 즉 모든 테스트를 통과한 클리닝 함수에 있는데도 모델과 리트리버(retriever)를 디버깅하게 됩니다.

놓치고 있는 검사들

스키마 및 볼륨 검사는 '데이터가 올바른 형태로 모양을 갖추었는지'에 답합니다. 여러분이 필요로 하는 검사는 '데이터가 이전에 가졌던 의미를 여전히 가지고 있는지'에 답합니다. 이것은 완전히 다른 범주이며, 테이블의 데이터 품질 규칙이라기보다는 모델에 대한 회귀 테스트(regression tests)처럼 보입니다:

• 임베딩 거리 드리프트 (Embedding-distance drift): 파이프라인 변경 전후에 고정된 문서 샘플을 인코딩하고, 임베딩 분포가 특정 임계값을 초과하여 이동하는지 경고합니다.

• 검색 중복률 (Retrieval overlap): 색인 재구축(reindex) 전후에 고정된 벤치마크 쿼리 세트를 대상으로 실행하고, 상위 k개 항목의 중복률을 비교합니다. 건강한 파이프라인 변경은 이 수치를 거의 움직이지 않게 해야 합니다.

• 클래스 및 토픽 균형 (Class and topic balance): 단순히 전체 개수뿐만 아니라, 중복 제거(dedup) 및 필터링 단계를 거치면서 레이블, 언어 또는 토픽 클러스터의 분포를 추적합니다.

• 개체 생존율 (Entity survival rate): PII 마스킹 또는 익명화 단계의 경우, 이름 있는 개체(named entities), 숫자, 날짜 중 어떤 비율이 살아남는지 측정하고 급격한 하락에 대해 경고합니다.

• 골든 세트 비교 (Golden-set diffing): 알려진 '정답' 클리닝 출력이 포함된 작고 수작업으로 큐레이션된 문서 세트를 유지하고, 모든 파이프라인 변경 시 실제 출력과 이를 비교(diff)합니다.

이들 중 어느 것도 생소한 것은 아닙니다. 이는 유닛 테스트 스위트(unit test suite)에 적용하는 것과 같은 본능이며, 이 방식으로는 거의 아무도 테스트하지 않았던 스택의 일부에 적용되는 것입니다. 왜냐하면 역사적으로 데이터 엔지니어들이 스키마(schema)로 생각하고 소유해 왔기 때문이지, 태스크 메트릭(task metrics)으로 생각하는 ML 엔지니어들이 아니었기 때문입니다.

클리닝 로직을 구성이 아닌 코드로 다루기

더 깊은 문제는 기술적인 것이 아니라 조직적인 문제입니다. 클리닝 및 정규화 로직은 편리해 보이는 어떤 스크립트에 존재하는 경향이 있습니다. 한 번 설정되고 다시는 검토되지 않는 중복 제거 임계값, 몇 가지 예시를 바탕으로 엔지니어가 조정했던 보일러플레이트(boilerplate) 제거용 정규 표현식(regex) 등이 그렇습니다. 이 로직은 모델에 공급되는 코드만큼이나 모델 동작에 큰 영향을 미치지만, 모델 코드가 받는 것과 같은 검토의 엄격함을 받기 어렵습니다.

해결책은 클리닝 로직을 명시적으로 버전 관리하고, 모델 변경 시 요구하는 것과 같은 회귀 테스트 스위트 뒤에 그 변경 사항을 게이트(gate) 하는 것입니다. 만약 PR이 중복 제거 임계값(deduplication threshold)을 수정한다면, 단순히 '파이프라인이 여전히 실행된다'를 보여주는 것이 아니라, 고정된 평가 세트(frozen eval set)에서 이전/이후 효과를 보여주도록 요구되어야 합니다. 만약 PR이 PII가 어떻게 마스킹되는지 변경한다면, 단순히 성공적인 건식 실행(dry run)을 보여주는 것이 아니라 레이블링된 샘플에서 개체 생존율(entity survival rates)을 보여줘야 합니다.

이는 데이터 품질을 모니터링 문제에서 CI(Continuous Integration) 문제로 전환하는 것입니다. 모니터링은 이미 프로덕션에 들어간 후에 무언가 고장 났음을 알려줍니다. 반면, CI 게이트는 정량화된 효과를 첨부하여 의미론적 변경이 배포되기 전에 임박했음을 알려줍니다.

진짜 교훈

AI 시스템을 구동하는 파이프라인은 아웃티지(outages)가 실패하는 방식으로는 거의 고장 나지 않습니다. 그것들은 느린 누수가 발생하는 방식으로 실패합니다. 대시보드의 모든 다이얼은 정상으로 읽히지만, 실제로 망가진 것은 아무도 측정하지 않은 속성, 즉 클리닝된 데이터가 원본 데이터가 의미했던 것을 여전히 의미하는지 여부입니다. 스키마 유효성 검사(Schema validation)는 데이터 소비자(consumer of data)가 형태만 유지된다면 의미의 드리프트(drift in meaning)를 허용할 수 있었던 세계를 위해 구축되었습니다. AI 시스템은 그렇지 못합니다. 그들은 의미를 가중치(weights)와 인덱스에 직접 인코딩하며, 의미를 조용히 재구성하는 클리닝 단계는 기능적으로 당신이 요청하지 않은 사일런트 파인튜닝(silent fine-tune)과 같습니다.

만약 데이터 파이프라인이 중복 제거, 필터링, 정규화(normalization) 과정을 거치면서 실제 콘텐츠에 무슨 일이 일어나는지보다 컬럼 유형에 대한 테스트가 더 많다면, 그 불균형이야말로 다음 설명할 수 없는 모델 회귀(model regression)가 발생할 지점입니다. 구조적 검사는 결코 어려운 부분이 아니었습니다. 의미론적 검사야말로 어렵고, 아직 아무도 그것을 작성하고 있지 않습니다.