AI 기본기 13: Data-centric AI — 모델보다 데이터셋 품질을 먼저 의심하는 법

한 줄 요약

AI 성능 문제를 만나면 보통 더 큰 모델, 더 좋은 prompt, 더 최신 framework를 먼저 떠올린다. 하지만 실제 시스템에서는 모델이 배우는 대상인 데이터셋의 정의, 품질, 분포, 평가 기준이 흔들리면 모델을 바꿔도 같은 문제가 반복된다. Data-centric AI는 모델 구조보다 데이터를 고정밀로 설계하고 개선하는 관점이다.

지난 글에서는 LoRA, quantization, distillation처럼 모델을 효율적으로 조정하는 방법을 봤다. 이번 글은 그보다 더 앞단의 질문이다.

모델을 더 세게 학습시키기 전에, 지금 학습시키는 데이터가 정말 원하는 행동을 담고 있는가?

💡

이 글은 LinkedIn에 공유된 AI 학습자료 목록을 바탕으로 이어가는 AI 기본기 시리즈다. 목록에는 Made with ML, 머신러닝 시스템 디자인, LLM·Agent 학습 자료가 함께 들어 있다. 여기서는 그 자료들을 “무엇부터 공부할 것인가”가 아니라 “AI 시스템을 만들 때 데이터 관점으로 어떤 질문을 해야 하는가”로 재구성한다.

1. Model-centric에서 Data-centric으로

전통적인 머신러닝 프로젝트 설명은 보통 이렇게 시작한다.

데이터 준비 → 모델 선택 → 학습 → 평가 → 배포

이 흐름 자체는 맞다. 문제는 성능이 부족할 때의 사고방식이다.

Model-centric 접근은 주로 이런 질문을 한다.

모델 architecture를 바꿀까?
더 큰 backbone을 쓸까?
hyperparameter를 더 튜닝할까?
최신 논문 방법을 적용할까?
더 긴 context window를 쓰면 해결될까?

반면 Data-centric 접근은 먼저 이런 질문을 한다.

라벨 정의가 일관적인가?
학습 데이터와 실제 운영 데이터의 분포가 같은가?
실패 사례가 데이터셋에 충분히 들어 있는가?
평가셋이 실제 제품 리스크를 대표하는가?
synthetic data가 실제 문제를 보강하는가, 아니면 편향을 증폭하는가?

둘 중 하나만 맞다는 뜻은 아니다. 모델도 중요하다. 하지만 실무에서는 이미 강력한 foundation model을 쓰는 경우가 많다. 이때 성능 차이는 종종 모델 이름보다 데이터를 어떻게 정의하고, 수집하고, 정제하고, 평가했는지에서 난다.

2. 데이터셋은 단순한 파일 묶음이 아니다

데이터셋을 CSV, JSONL, 이미지 폴더, 벡터 DB chunk 묶음 정도로 생각하면 너무 얕다. AI 시스템에서 데이터셋은 사실상 문제 정의를 기계가 학습할 수 있게 고정한 계약서에 가깝다.

예를 들어 고객 문의를 분류하는 모델을 만든다고 하자.

sample.json

{
  "text": "환불 요청했는데 아직 입금이 안 됐어요",
  "label": "refund_delay"
}

이 한 줄에는 여러 결정이 숨어 있다.

결정	실제 의미
입력 단위	한 문장만 볼지, 이전 대화까지 볼지
라벨 체계	`refund_delay`와 `payment_issue`를 분리할지
기준 시점	접수 당시 기준인지, 처리 완료 후 기준인지
모호한 사례 처리	여러 라벨이 가능한 경우 어떻게 정할지
운영 액션	이 라벨이 붙으면 어떤 workflow로 넘길지

데이터셋이 흔들리면 모델은 흔들린 정의를 그대로 배운다. 두 annotator가 같은 문장을 서로 다른 라벨로 붙이고 있다면 모델은 “애매하게 답하는 법”을 배운다. 제품 정책이 바뀌었는데 과거 라벨을 그대로 쓰면 모델은 과거 정책을 배운다.

그래서 데이터셋 품질은 단순히 “오타가 적다”가 아니다. 더 정확히는 다음 네 가지다.

정의 품질: 무엇을 맞혀야 하는지 명확한가?
라벨 품질: 사람이 같은 기준으로 일관되게 붙였는가?
분포 품질: 실제 운영 입력을 대표하는가?
평가 품질: 성공과 실패를 제품 관점에서 구분하는가?

3. 라벨 품질: 정답은 발견되는 것이 아니라 설계된다

많은 팀이 라벨을 “이미 존재하는 정답”처럼 다룬다. 하지만 실제 라벨은 보통 설계물이다.

감성 분석을 예로 들어 보자.

“배송은 늦었지만 상담원이 친절해서 괜찮았어요.”

이 문장은 긍정인가, 부정인가, 중립인가? 목적에 따라 답이 달라진다.

목적	가능한 라벨
배송 품질 분석	부정
상담 품질 분석	긍정
전체 고객 만족도	중립 또는 mixed
VOC 우선순위 분류	배송 지연 이슈

즉 라벨은 자연에 숨어 있는 하나의 절대값이 아니라, 서비스가 어떤 결정을 내릴지에 맞춰 정의한 관측값이다.

라벨 품질을 높이려면 최소한 다음을 문서화해야 한다.

positive / negative example
borderline case 처리 기준
multi-label 허용 여부
annotator 간 불일치 해결 방식
라벨 변경 이력
제품 정책 변경과 라벨 정의의 연결

⚠️

라벨 가이드 없이 데이터만 늘리면 성능이 좋아지는 것이 아니라 노이즈가 더 정교하게 축적될 수 있다. 특히 LLM judge나 synthetic labeling을 쓸 때도 기준 문서가 없으면 자동화된 불일치가 대량 생산된다.

4. 분포 품질: 평균 성능보다 실패 구간을 봐야 한다

데이터셋이 실제 운영 분포를 대표하지 않으면 offline metric은 좋아도 제품에서는 실패한다. 가장 흔한 문제는 train/test split을 랜덤으로 나눴는데 실제 서비스에서는 시간, 사용자군, 도메인, 언어, 입력 길이가 계속 바뀌는 경우다.

예를 들어 RAG 기반 고객지원 봇을 만든다고 하자.

데이터 구간	흔한 실패
짧은 FAQ 질문	잘 맞음
긴 complaint	핵심 요구를 놓침
여러 의도가 섞인 질문	첫 번째 의도만 처리
최신 정책 질문	오래된 문서 검색
은어·오타·구어체	retrieval 실패
공격적 prompt	안전 정책 우회

전체 accuracy가 높아도 특정 구간에서 계속 실패하면 운영 리스크는 크다. 그래서 데이터셋을 볼 때는 평균 하나가 아니라 slice를 봐야 한다.

전체 성능
  ├─ 입력 길이별
  ├─ 사용자 유형별
  ├─ 도메인별
  ├─ 시간별
  ├─ 언어/표현별
  ├─ 난이도별
  └─ 리스크 유형별

이 관점은 LLM과 agent 시스템에서 더 중요하다. Agent는 단일 분류 모델보다 실패 모드가 많다. 잘못된 검색, 잘못된 tool 선택, 잘못된 인자 생성, 잘못된 중간 추론, 불필요한 반복 호출이 모두 실패가 된다.

5. Evaluation set은 “시험지”가 아니라 운영 계약이다

평가셋은 모델을 점수 매기기 위한 파일이 아니다. 실제로는 팀이 “이 정도는 반드시 맞혀야 한다”고 합의한 운영 계약이다.

좋은 평가셋은 최소 세 층으로 나뉜다.

평가셋	목적	예시
Dev set	빠른 반복 개선	일반 케이스, 자주 보는 실패
Regression set	과거에 고친 문제 재발 방지	버그 리포트, 고객 불만, 장애 사례
Stress set	위험 구간 검증	긴 입력, prompt injection, 최신 정책, 애매한 질문

LLM 시스템이라면 여기에 human eval과 LLM-as-judge를 섞을 수 있다. 다만 LLM judge를 쓴다고 해서 평가 문제가 사라지는 것은 아니다. Judge prompt, rubric, reference answer, pass/fail 기준이 또 하나의 데이터셋이 된다.

예를 들어 답변 품질을 평가할 때 rubric은 이렇게 나눌 수 있다.

정확성: 문서 근거와 일치하는가?
완전성: 사용자의 핵심 질문을 모두 다뤘는가?
근거성: 출처나 검색 결과를 과장하지 않았는가?
형식성: 요구한 JSON schema 또는 톤을 지켰는가?
안전성: 금지된 조언이나 개인정보 노출이 없는가?
행동성: 다음 액션으로 이어질 만큼 구체적인가?

이 rubric이 없으면 “좋은 답변”은 사람마다 달라진다. 그러면 모델 평가도, prompt 개선도, fine-tuning 데이터 생성도 모두 흔들린다.

6. Synthetic data는 부족한 구간을 채우는 도구다

요즘은 LLM으로 학습 데이터와 평가 데이터를 합성하는 경우가 많다. Synthetic data는 강력하지만, 만능은 아니다.

좋은 사용법은 부족한 실패 구간을 의도적으로 보강하는 것이다.

예를 들어 실제 데이터에서 prompt injection 사례가 부족하다면 다음처럼 생성할 수 있다.

목표: 고객지원 RAG 봇의 prompt injection 방어 평가셋 생성
조건:
- 실제 고객 문의처럼 자연스러워야 함
- 문서 무시, 시스템 지시 변경, 비밀 정보 요청 패턴 포함
- 정상 문의와 공격 문구가 섞인 mixed intent 포함
- expected behavior는 “정책 위반 지시를 무시하고 정상 문의만 처리”

반대로 나쁜 사용법은 “데이터가 부족하니 LLM으로 10만 개 만들자”에 가깝다. 이 경우 synthetic data가 모델의 말투와 편향을 복사하고, 실제 운영 분포와 멀어질 수 있다.

Synthetic data를 쓸 때는 세 가지를 확인해야 한다.

Targeted: 어떤 부족 구간을 채우는가?
Diverse: 표현, 난이도, 길이, 도메인이 충분히 다양한가?
Validated: 사람이 샘플링 검수하거나 실제 실패 로그와 비교했는가?

✅

Synthetic data는 “데이터를 싸게 많이 만드는 도구”라기보다 “희귀하지만 중요한 실패 구간을 설계해 넣는 도구”로 보는 편이 안전하다.

7. 데이터 버전 관리는 모델 버전 관리만큼 중요하다

모델 성능이 바뀌었을 때 원인을 추적하려면 데이터도 버전이 있어야 한다.

model_v7
  ├─ train_data: customer_support_2026_07_15_v3
  ├─ eval_data: support_regression_2026_07_v2
  ├─ prompt: support_agent_prompt_v12
  ├─ retriever_index: docs_index_2026_07_20
  └─ policy: refund_policy_2026_q3

LLM 애플리케이션에서는 특히 retriever index와 문서 버전이 중요하다. 모델은 그대로인데 문서 chunking이 바뀌거나, embedding model이 바뀌거나, 최신 정책 문서가 누락되면 답변이 달라진다.

따라서 재현 가능한 AI 시스템은 최소한 다음을 기록해야 한다.

항목	왜 필요한가
원천 데이터 snapshot	나중에 같은 학습을 재현하기 위해
라벨 가이드 버전	기준 변경을 추적하기 위해
전처리 코드 버전	filtering, chunking, dedup 기준이 성능에 영향
synthetic data prompt	합성 데이터 생성 기준 재현
평가셋 버전	metric 변화가 진짜 개선인지 확인
배포 시점 운영 로그	offline 성능과 online 실패 연결

이 기록이 없으면 “이번 모델이 왜 좋아졌는지”보다 “왜 갑자기 나빠졌는지”를 설명하기 어렵다.

8. 실무 체크리스트: 모델 바꾸기 전에 볼 것

성능이 낮다고 바로 모델을 바꾸기 전에 아래 순서로 보는 것이 좋다.

8.1 문제 정의

모델 출력이 실제로 어떤 의사결정에 쓰이는가?
성공과 실패를 사람이 같은 기준으로 구분할 수 있는가?
top-level metric 하나로 충분한가, slice metric이 필요한가?

8.2 데이터 품질

중복, 누락, 깨진 포맷, 오래된 정책 데이터가 있는가?
라벨이 모호한 케이스는 별도 class나 ignore 처리되는가?
실제 운영 입력의 길이, 언어, 톤, 노이즈를 반영하는가?

8.3 평가 품질

평가셋이 너무 쉬운 예제로만 구성되어 있지 않은가?
과거 장애와 고객 불만이 regression set에 들어갔는가?
LLM judge를 쓴다면 rubric과 judge prompt가 버전 관리되는가?

8.4 운영 피드백

실패 로그가 학습·평가 데이터로 되돌아오는 루프가 있는가?
최신 문서와 policy 변경이 RAG index에 반영되는가?
배포 후 drift를 감지할 slice dashboard가 있는가?

이 체크리스트를 통과한 뒤에도 한계가 분명하면 그때 fine-tuning, RAG 개선, 모델 교체, agent 구조 변경을 논의하는 것이 더 낫다.

9. AI 기본기 로드맵에서 Data-centric AI의 위치

AI를 공부할 때 데이터는 초반에 “전처리”라는 이름으로 지나가기 쉽다. 하지만 실제로는 모든 단계에 걸쳐 있다.

Objective
  ↓ 무엇을 최적화할지 정한다
Representation
  ↓ 데이터를 어떤 벡터 공간으로 바꿀지 정한다
Transformer / LLM
  ↓ 패턴을 학습한다
RAG / Agent
  ↓ 외부 지식과 도구를 쓴다
Evaluation / Guardrails
  ↓ 시스템 행동을 검증한다
LLMOps
  ↓ 배포 후 상태를 추적한다
Post-training / PEFT
  ↓ 원하는 행동을 더 싸게 조정한다
Data-centric AI
  ↓ 위 모든 단계의 입력과 기준을 다시 설계한다

Data-centric AI를 배우면 “모델 성능이 낮다”는 말을 더 정확히 쪼갤 수 있다.

모델이 모르는가?
데이터가 빠졌는가?
라벨 기준이 틀렸는가?
검색된 문서가 틀렸는가?
평가셋이 현실을 못 담는가?
운영 입력이 학습 분포 밖인가?
synthetic data가 오히려 편향을 키웠는가?

이 질문을 할 수 있어야 AI 시스템을 단순 demo에서 운영 가능한 제품으로 옮길 수 있다.

10. 다음에 공부할 것

다음 단계에서는 data-centric 관점에서 자연스럽게 이어지는 주제를 볼 수 있다.

데이터 파이프라인: 수집, 정제, dedup, filtering, schema validation
Evaluation dataset 설계: golden set, regression set, adversarial set
Synthetic data generation: instruction data, preference data, edge case 생성
Dataset governance: 개인정보, 라이선스, 데이터 계보, 삭제 요청 대응
Continuous learning loop: 운영 실패 로그를 다시 학습·평가로 연결

AI 기본기를 구체적으로 학습하려면 “모델을 어떻게 학습시키는가”만큼 “모델에게 무엇을 보여 주고, 무엇으로 시험 볼 것인가”를 같이 공부해야 한다. 데이터셋은 부속품이 아니라 AI 시스템의 행동을 결정하는 첫 번째 설계물이다.

참고 자료

LinkedIn 원문: AI를 체계적으로 배우기 위한 핵심 학습 자료 모음
Made with ML: Machine Learning Systems
Chip Huyen: Machine Learning Systems Design
Google: Rules of Machine Learning
Hugging Face: LLM Course