ID가 망가진 것만으로 AI 순위가 전부 1위가 되어버려서, CSV 감사 도구를 OSS로 공개했다

서론

개인 개발 중인 AI 시스템을 가동하던 어느 날, 추론 결과를 확인하니 모든 행의 순위가 「1위」로 되어 있었다.

모델은 정상적으로 작동하고 있었다. 코드에 버그도 없었다. 에러도 발생하지 않았다. 그럼에도 결과는 망가져 있었다.

원인은 단순했다. 그룹 ID(Group ID) 설계가 잘못되어 있었다. 단지 그것만으로 랭킹 계산이 완전히 붕괴되었다.

이 기사는 개인 개발 AI에서 실제로 일어난 데이터 품질 사고와 그 원인, 그리고 재발 방지 과정을 기록한 것이다. 같은 실수를 반복하는 사람이 줄어든다면 그것으로 충분하다고 생각한다.

만들고 있던 시스템에 대하여

이 시스템은 하나의 이벤트에 여러 대상이 연결되는 데이터를 바탕으로, 여러 예측 모델을 조합하여 판단을 내리는 개인 개발 파이프라인이다. 즉, 데이터를 읽어오고, 가공하고, 모델에 전달하여 결과를 내는 일련의 흐름이다.

최초의 목적은 「정밀도 높은 예측 모델을 만드는 것」이었다. 하지만 개발이 진행됨에 따라, 모델보다 데이터의 품질 관리(Data Quality Management)에 더 많은 시간을 쓰게 되었다.

이하에 실제로 발생했던 대표적인 3가지 사고를 기록한다.

사고 1: 그룹 ID가 망가져서 순위가 모든 행에서 1위가 되었다

무슨 일이 일어났는가

추론 후의 순위(rank)를 확인하니, 모든 행의 값이 1이 되어 있었다.

시스템상으로는 「추론은 성공했다」는 상태였다. 코드도 작동하고 있다. 하지만 출력 결과가 이상하다. 처음에는 모델을 의심했고, 다음에는 특성량(Feature)을 의심했다. 하지만 원인은 훨씬 앞 단계에 있었다.

왜 그렇게 되었는가

이 시스템은 「1개 이벤트에 여러 대상이 연결되는」 구조이며, 랭킹은 이벤트별로 생성한다.

df["rank"] = df.groupby("event_id")["score"].rank(ascending=False)

그런데 실제 event_id(그룹을 식별하는 ID)가 「이벤트 단위」가 아니라 「대상 단위」로 되어 있었다. 즉, 각 그룹에 데이터가 1건씩밖에 없어서 모두가 자동으로 1위가 된 것이다.

# 망가진 상태 (각 그룹에 1건씩만 있음)
event_id | score | rank
event_001_A | 0.82 | 1 ← A밖에 없음
...

까다로웠던 점

에러가 발생하지 않는다. 모델은 작동하고 rank도 나온다. 단지 「전원 1위」라는 의미 없는 결과가 조용히 나열될 뿐이다.

여러 모델의 일치 여부로 판단하는 시스템에서는 이 rank가 어긋나면 판단 전체를 신뢰할 수 없게 된다.

배운 점

ID 설계는 특성량이나 모델보다 먼저 검증해야 할 기반이다. ID가 망가지면 랭킹, 집계, 테이블 조인(Join)이 근본부터 무너진다. 문제가 모델의 정밀도 문제처럼 보여도, 사실은 ID 설계의 문제인 경우가 있다.

사고 2: 모델은 있는데, 추론할 수 없었다

무슨 일이 일어났는가

일일 추론 메커니즘을 구현할 때, 「모델이 필요로 하는 특성량」과 「실제로 준비할 수 있는 특성량」을 대조했다.

결과는 다음과 같았다.

항목	수
모델이 필요로 하는 특성량(열)의 수	78
일일 입력 CSV만으로 준비 가능한 특성량	19
부족한 특성량
59

모델은 존재했다. 하지만, 작동할 수 있는 상태는 아니었다.

왜 이렇게 되는가

학습 시의 데이터에는 과거의 이력 정보가 풍부하게 포함되어 있었다. 하지만 일일 단위로 전달되는 CSV는 당일 데이터가 중심이며, 과거 이력으로부터 만드는 특성량이 포함되어 있지 않았다.

「모델을 학습할 수 있다」는 것과 「매일 추론할 수 있다」는 것은 전혀 별개의 문제다.

어떻게 해결했는가

부족한 이력 계열의 특성량을 생성하는 프로세스를 별도로 만들어 일일 파이프라인에 통합했다. 최종적으로 부족한 특성량을 59개에서 9개까지 줄일 수 있었다 (이력 대조율 97.1%).

배운 점

모델을 운영 단계에 올리기 전에, 「추론에 필요한 열이 실제로 갖춰지는가」를 확인하는 작업이 필수적이다. 이를 수행하지 않으면 모델이 있어도 사용할 수 없는 상황이 발생한다.

사고 3: 데이터가 누락되어도 처리가 멈추지 않았다

무슨 일이 일어났는가

여러 예측 모델을 조합하는 파이프라인을 만들었을 때, 개별 파트는 완성되었지만, 일부 출력이 누락된 채로 후속 처리가 돌아가는 상태였다.

여러 모델의 일치를 전제로 판단을 내리는 시스템에서 일부 출력이 누락되면 근거 없는 결과가 나온다. 하지만 에러는 발생하지 않는다. 신뢰할 수 없는 결과가 사이런트(Silent)하게 계속 흐른다.

해결책: 누락되었다면 멈춘다

「부족한 것이 있다면 명확한 이유를 내보내며 멈춘다」는 설계로 전환했다.

다음은 안전 정지(Safe Stop)의 사고방식을 보여주는 예시다 (현재 OSS의 구현이 아니라, 이 프로젝트에서 채택한 패턴이다).

에러 메시지로 "무엇이 부족한지"를 명시하는 것만으로도, 원인을 특정하는 데 걸리는 시간이 상당히 단축되었다.

배운 점

"결여되어 있다면 멈춘다"는 제약이 아니라, 운영 시스템의 중요한 기능이다. 불완전한 데이터로 처리를 계속하는 것보다, 이유를 밝히고 멈추는 것이 훨씬 더 가치가 있다.

수동 확인의 한계를 느꼈다

세 가지 사고 외에도 유사한 문제가 반복해서 발생했다.

• CSV의 인코딩 (Encoding)이 날마다 바뀐다
• 열 이름 (Column name)에 전각 공백이나 오타 (Typo)가 혼입된다
• 수치 열에 변환할 수 없는 문자열이 들어있다
• 결측치가 많은 열이 어느 날 갑자기 늘어난다

수동으로 체크하는 것은 애초에 한계가 있다. 매일 자동으로 실행되는 파이프라인에서는 특히, 다음 날 아침 확인하고 나서야 "어제부터 망가져 있었다"는 것을 깨닫는 상황이 발생하기 쉽다.

개인 개발 환경에서는 "매일 같은 CSV가 온다는 보장"이 없다. 수동으로 다운로드하거나 스크레이핑 (Scraping)으로 취득하는 CSV는, 어느 날 갑자기 열이 늘어나거나 타입 (Type)이 변하기도 한다.

재발 방지를 위해, 작은 도구를 OSS로 공개했다

같은 종류의 확인 작업을 몇 번이고 수작업으로 반복하면서, "이것은 범용 도구로 만들 수 있겠다"라고 생각했다.

이 프로젝트에서 직면한 문제는 도메인 특화적인 이야기가 아니라, CSV를 다루는 데이터 분석이나 ML (Machine Learning) 개발자라면 누구나 겪을 수 있는 문제였다.

• ID 설계가 망가진다
• 필요한 열이 부족하다
• 타입이나 열 이름이 어느샌가 어긋난다
• 학습 데이터에 섞여서는 안 될 열이 있다

그래서 이러한 감사 (Audit) 기능들을 모아 Data Guardrail Kit로서 OSS로 공개했다.

Data Guardrail Kit로 할 수 있는 것

현재 구현된 주요 기능은 다음과 같다.

• CSV 읽기 (인코딩 및 구분자를 자동 판정)
• 필수 열 존재 체크 · 타입 체크 · 결측률 체크
• 중복 ID 검출
• 결과 데이터 계열의 열 이름 패턴 검출 (학습 시의 데이터 리크 (Data Leak) 후보)
• Markdown 리포트 자동 생성

체크 내용은 YAML 스타일의 심플한 파일로 정의하며, 커맨드 라인 (Command Line)에서 실행할 수 있다.

python -m data_guardrail_kit audit \
--input examples/sample_input.csv \
--schema examples/simple_schema.yaml \
...

실행하면 Markdown 리포트가 생성되어, 어떤 열이 문제인지 목록으로 확인할 수 있다.

GitHub Actions로 자동 감사하기

CSV가 업데이트될 때마다 자동으로 체크하고 싶다면, GitHub Actions에 통합할 수 있다.

name: Data Quality Check
on:
  push:
...

CSV가 바뀔 때마다 리포트가 생성되어 아티팩트 (Artifact)에 남는다. "알아채지 못했다"는 상황이 줄어든다.

요약

이 프로젝트를 통해 가장 크게 바뀐 인식은, "모델의 정확도보다 데이터 품질과 운영 설계가 우선이다"라는 점이었다.

돌이켜보면 가장 시간이 많이 걸렸던 문제는 다음 세 가지였으며, 모두 "모델의 이야기"가 아닌 "데이터의 이야기"였다.

• ID 설계 미스 —— 모든 행이 1위인 것은 ID가 망가져 있었던 결과였다
• 특징량 (Feature) 부족 —— 모델이 있어도 필요한 열이 갖춰지지 않으면 사용할 수 없다
• 안전 정지의 결여 —— 불완전한 데이터로 처리가 계속되는 시스템은 조용히 계속 망가져 간다

비슷한 상황에서 어려움을 겪고 있는 사람이 있다면, Data Guardrail Kit가 참고가 될지도 모른다.

Issue나 피드백도 환영한다.

Discussion