진짜 문제는 데이터다 (AI가 아니라)
팀이 몇 주를 들여 AI 모델을 평가한다. GPT-5.2와 Claude Opus 4.6을 비교 테스트한다. 어느 쪽이 자신들의 use case에 더 맞는지 토론한다. 벤치마크를 읽고 시험을 돌린다. 최종적으로 모델을 결정하고 워크플로우를 구축한다.
진짜 문제는 데이터다 (AI가 아니라)
"AI로 만들기" 시리즈 4편
자주 반복되는 장면이 있다.
팀이 몇 주를 들여 AI 모델을 평가한다. GPT-5.2와 Claude Opus 4.6을 비교 테스트한다. 어느 쪽이 자신들의 use case에 더 맞는지 토론한다. 벤치마크를 읽고 시험을 돌린다. 최종적으로 모델을 결정하고 워크플로우를 구축한다.
그리고 실제 데이터를 넣는다 — 스프레드시트, CRM 내보내기, 고객 메모, 내부 문서들. 결과는 엉망이다. 일관성이 없고, 신뢰하기 어렵고, 가끔 쓸모 있고, 종종 틀렸다.
모델을 탓한다. 다른 모델로 바꾼다. 결과는 같다.
모델이 문제가 아니었다.
실제로 무슨 일이 일어나고 있는가
데이터 엔지니어링에는 AI보다 수십 년 먼저 생긴 원칙이 있다. 쓰레기를 넣으면 쓰레기가 나온다(Garbage in, garbage out). 나쁜 데이터를 시스템에 넣으면 시스템이 아무리 정교해도 나쁜 결과가 나온다. 1980년대 데이터베이스에서도 사실이었고, 머신러닝 모델에서도 사실이었다. 오늘날 AI에서는 특히 그렇다.
차이점은 AI가 이 문제를 숨기는 데 유난히 뛰어나다는 것이다. 언어 모델은 일관성 없고 지저분하고 불완전한 데이터를 받아 들리기에 일관되고 자신감 있는 무언가를 만들어낼 수 있다. 공백을 채우고, 모순을 매끄럽게 넘기고, 그럴듯하게 들리는 결과물을 생성한다. 그 말은 AI 결과물에 따라 행동하려 할 때 그것이 불안정한 기반 위에 세워진 것임을 깨달을 때까지 AI가 잘 작동한다고 오랫동안 생각할 수 있다는 뜻이다.
AI 도구를 평가하는 대부분의 사람들은 모델을 평가하고 있다. 데이터를 평가해야 한다.
여기서 "데이터"가 실제로 의미하는 것
AI 맥락에서 데이터를 말할 때 스프레드시트와 데이터베이스만 의미하는 게 아니다. AI가 일을 하도록 넣는 모든 정보를 의미한다. 여기에 포함되는 것들:
- 정형 데이터 — 스프레드시트, CSV 파일, 데이터베이스 내보내기, CRM 레코드
- 비정형 텍스트 — 이메일, 회의 메모, 고객 피드백, 내부 문서, PDF
- 프롬프트에 제공하는 맥락 — 배경 정보, 지침, 예시
- 외부 소스 — 모델에 전달하기 위해 가져오는 웹사이트, API, 문서
이 모두가 데이터다. 그리고 모두 AI가 할 수 있는 것에 영향을 미치는 품질 문제를 가지고 있다.
AI 프로젝트를 망치는 4가지 데이터 문제
1. 일관성 없음
가장 흔하고 가장 치명적이다. 같은 것이 다섯 가지 다른 방식으로 묘사된다: "서울", "Seoul", "서울시", "서울특별시", "SEOUL". 한 시스템에서는 "활성"인 고객 상태가 다른 시스템에서는 "active"다. 어떤 레코드에는 공백이 있고 다른 레코드에는 하이픈이 있는 제품명.
사람은 일관성 없음을 자동으로 처리한다 — 뇌가 힘들이지 않고 정규화한다. AI는 그렇지 않다. "활성"과 "active"를 잠재적으로 다른 것으로 취급한다. 패턴 변형을 알아차리고 혼란스러워하거나 하류에서 오류를 복합시키는 가정을 만든다.
테스트: 데이터의 핵심 필드 — 카테고리, 상태, 이름 — 를 골라 같은 값의 변형이 몇 개 존재하는지 세어보라. 두세 개 이상이면 일관성 문제가 있다.
2. 불완전함
빠진 필드. 빈 셀. 값이 있어야 할 곳에 "N/A". 입력하는 사람이 바빴거나 시스템이 요구하지 않아서 절반만 채워진 레코드들.
AI는 불완전한 데이터로 작업할 수 있다 — 하지만 공백을 가정으로 채울 것이다. 그 가정이 합리적인 경우도 있다. 종종 그렇지 않다. 그리고 어느 쪽인지 항상 알 수 있는 건 아니다.
불완전함이 체계적일 때 위험이 배가된다 — 같은 유형의 레코드에서 항상 같은 필드가 빠질 때. AI가 같은 잘못된 가정을 반복해서, 일관되게, 대규모로 만든다는 의미다.
테스트: 레코드의 몇 퍼센트가 모든 핵심 필드를 채웠는가? 80% 미만이면 AI가 사실보다 가정으로 더 많이 작동하게 된다.
3. 오래됨
데이터에는 유효기간이 있다. 2년 전 고객 레코드는 잘못된 주소, 예전 직함, 더 이상 작동하지 않는 전화번호가 있을 수 있다. 2022년에 작성된 제품 설명은 더 이상 존재하지 않는 기능을 묘사할 수 있다. 18개월 전 시장 분석은 다른 시장을 설명하고 있다.
오래된 데이터를 AI에 넣고 현재의 것을 요청하면 — 추천, 제안서, 고객 상황 요약 — 그 오래된 정보로 작업해 권위 있게 들리지만 현실의 구식 그림 위에 세워진 결과물을 만들어낸다.
테스트: 각 주요 데이터 소스가 마지막으로 검증되거나 업데이트된 게 언제인가? 모른다면, 그게 답이다.
4. 맥락 붕괴
가장 미묘한 문제다. 데이터가 당신에게는 완벽하게 이해된다 — 데이터가 담지 못하는 수년간의 맥락을 가지고 있기 때문이다.
"고객 보류 중"은 팀에게 특정한 의미다: 서비스 일시정지를 요청했거나, 하드웨어 배송을 기다리거나, 계약 갱신 협상 중이다. 하지만 그 문구 단독으로 AI에게 전달하면 수십 가지 의미 중 하나일 수 있다. AI는 그것을 올바르게 해석할 조직적 맥락이 없다.
내부인에게는 완벽하게 이해되지만 외부 독자에게는 — AI를 포함해 — 불투명한 약어, 내부 용어, 줄임말, 코드에서 특히 그렇다.
테스트: 레코드 샘플을 무작위로 골라 사업에 익숙하지 않은 사람에게 해석하도록 요청하라. 혼란스러워하는 모든 곳이 맥락 붕괴 위험이다.
데이터 준비도 체크리스트
데이터 위에 AI 워크플로우를 구축하기 전에 이 체크리스트를 실행하라:
일관성
- 핵심 범주형 필드가 표준화된 값을 사용함 (같은 것의 여러 변형이 아니라)
- 이름, ID, 참조가 시스템 간에 일치함
- 날짜 형식이 일관됨
- 텍스트 필드에 별도 필드에 있어야 할 정형 데이터가 없음
완전성
- 핵심 필드가 80% 이상 채워져 있음
- 누락된 값이 명시적으로 표시됨 (비어있지 않고, 일관성 없는 "N/A"나 "미상"이 아니라)
- 필수 필드가 습관적으로 비워지지 않음
신선도
- 각 데이터 소스가 마지막으로 검증된 시기를 알고 있음
- 오래된 레코드가 표시되거나 보관되어 있고 현재 것과 섞이지 않음
- 시간에 민감한 필드 (연락처, 가격, 상태)에 검토 주기가 있음
맥락
- 약어와 내부 용어가 어딘가에 문서화되어 있음
- 상태 코드와 카테고리에 정의가 있음
- 레코드가 내부 조직 맥락 없이도 이해 가능함
이 목록의 모든 것을 체크할 수 있다면 데이터가 AI 준비가 된 것이다. 절반 미만을 체크하고 있다면 어떤 모델을 쓰더라도 AI 결과물이 신뢰할 수 없을 것이다.
어떻게 해결할 것인가
좋은 소식이 있다. AI 자체가 데이터를 정리하고 준비하는 탁월한 도구다. 프로세스는 이렇다:
1단계: 먼저 감사하고, 그 다음 수정하라. 무작위로 데이터 정리를 시작하지 마라. AI를 사용해 감사하라 — 샘플을 넣고 일관성 없음, 누락된 패턴, 모호한 값을 식별하도록 요청하라. 어떻게 수정할지 결정하기 전에 문제를 표면화하도록 해라.
2단계: 영향이 큰 필드부터 먼저 표준화하라. 모든 것을 고칠 필요는 없다. AI 워크플로우가 실제로 사용할 필드에 집중하라. 고객 접근 도구를 구축한다면 고객 이름, 상태, 연락처 정보가 내부 메모보다 더 중요하다. 전체 데이터셋이 아니라 중요 경로를 수정하라.
3단계: 표준화한 것을 문서화하라. 각 필드에 허용되는 값, 각 상태의 의미, 약어가 뜻하는 것을 담은 짧은 참조 문서가 몇 시간의 정리보다 가치 있다. 문제가 재발하는 것을 방지하고 AI에게 참조할 것을 제공한다.
4단계: 신선도를 프로세스에 내장하라. 데이터 품질은 일회성 프로젝트가 아니다. 쇠퇴한다. 간단한 검토 주기를 구축하라 — 느리게 변하는 데이터는 분기별, 빠르게 변하는 것은 월별 — 같은 오래됨 문제를 반복해서 해결하지 않도록.
올바른 모델보다 올바른 데이터
올바른 AI 모델 선택은 10% 문제다. 데이터를 올바르게 하는 것은 90% 문제다.
이건 AI에 대한 비판이 아니다. 정보 집약적인 작업에서 진짜 작업이 어디에 있는지를 반영한다. 모델은 도구다. 데이터는 원재료다. 나쁜 재료로 작업할 때 도구를 탓하는 장인은 없다.
AI에서 일관되게 좋은 결과를 얻는 빌더들이 반드시 최고의 모델을 쓰는 건 아니다. 그들은 깨끗하고 일관되며 잘 문서화된 데이터를 사용하고 있다 — 그리고 그것을 유지하는 습관을 구축했다.
이게 AI 데모 세계가 절대 보여주지 않는 멋없는 진실이다. 데모는 완벽하게 사전 정리된 예시 데이터를 사용한다. 당신의 현실은 더 지저분하다. 그 지저분함을 고치는 것이 AI를 어떤 것에 추가하기 전에 할 수 있는 가장 높은 레버리지 작업이다.
더 깊이 배우고 싶다면
이 글은 데이터 기반을 다뤘다. 송재희의 AI Development Guide는 더 깊이 들어간다 — 특정 AI 사용 사례를 위해 데이터를 구조화하는 방법, AI를 사용해 가진 것을 정리하고 풍부하게 하는 방법, 데이터 품질이 AI 스택의 모든 레이어와 어떻게 연결되는지.
📱 Apple Books ▶️ Google Play Books 🌐 전 플랫폼 구매 (Books2Read)
다음 편: "기술보다 문제 정의가 성패를 가른다" — 거의 무엇이든 만들 수 있는 도구들의 시대에 왜 병목이 얼마나 정확하게 원하는 것을 표현할 수 있느냐로 완전히 이동했는지를 다룹니다.