데이터가 8할이라면, 그 8할을 어떻게 다루나
"데이터가 8할"은 누구나 말한다. 정작 그 8할이 무엇으로 이루어졌는지는 잘 말하지 않는다. 한국어 식문화 도메인에서 우리가 매일 굴리는 정제·태깅·검증·평가·grounding이라는 데이터 공정의 해부도, 그리고 이를 한 편씩 펼칠 시리즈의 출발점.
“데이터가 8할”은 슬로건이 아니다
지난 글(한국어 도메인에 LLM을 맞춘다는 것)에서 우리는 한 줄로 끝맺었다 — 도메인에 LLM을 맞추는 일의 8할은 모델이 아니라 데이터다. 그 글은 우리가 어떻게 거기에 도달했는지의 기록이었다.
그런데 “데이터가 8할”은 사실 누구나 말한다. 컨퍼런스 슬라이드의 단골 문구이고, 틀린 말도 아니다. 문제는 그다음이다. 정작 그 8할이 무엇으로 이루어졌는지는 잘 말하지 않는다. 8할이라는 강조가 구호로 남으면, 데이터 작업은 “일단 많이 모아 정리한다”는 막연한 노가다로 뭉뚱그려진다.
우리 경험은 반대였다. 그 8할은 한 덩어리가 아니라 공정이었다. 정제·태깅·검증·평가·grounding이라는, 각자 다른 질문에 답하고 각자 다른 함정을 가진 단계들로 쪼개졌다. 이 글은 그 해부도를 펼친다. 모델 고르기를 폄하하려는 게 아니다 — 모델 선택은 여전히 출발점이다. 다만 출발점일 뿐이고, 결과를 가른 건 그 뒤에 세운 공정이었다.
8할의 해부 — 다섯 단계가 답하는 질문
각 단계는 한 문장으로 요약되는 고유한 질문을 책임진다. 깊이는 다음 글들의 몫이고, 여기서는 지도만 그린다.
- 정제(normalization) — “같은 것을 같다고 부르게 만든다.” 한국어 레시피는 표기·단위·조리 표현이 제각각이다. 같은 재료가 다른 이름으로, 같은 동작이 다른 표현으로 흩어진 것을 일관된 형태로 모은다.
- 태깅(tagging) — “무엇으로 분류할지가 곧 도메인 지식이다.” 계절·제철, 조리 난이도, 한·양·일·중 같은 구성. 어떤 축을 세우느냐가 그 도메인을 얼마나 아는지를 드러낸다.
- 검증(verification) — “들일지 말지를 판정한다.” 정제·태깅을 통과한 데이터가 실제로 일관적인지, 코퍼스에 승격할 자격이 있는지를 가르는 관문이다.
- 평가(evaluation) — “‘좋아졌다’를 측정한다.” 게이트를 손볼 때마다 품질이 정말 올라갔는지, 어디선가 회귀가 생기지 않았는지를 정량·정성으로 잡는 체계다.
- grounding — “판단을 도메인 사실에 묶는다.” 검증 가능한 도메인 상식 위에서만 판단을 받아들인다. 사실에 근거를 댈 수 없는 그럴듯함은 통과시키지 않는다.
┌─ 평가 ─────────────────────────────┐ ← 좋아졌나를 측정
│ │
원천 → 정제 → 태깅 → 검증 → 코퍼스 승격
│ │
└─ grounding ────────────────────────┘ ← 판단을 사실에 묶음정제·태깅·검증이 데이터가 흘러가는 축이라면, 평가와 grounding은 그 축 전체를 감싸는 틀이다. 측정이 없으면 게이트를 손볼 근거가 없고, grounding이 없으면 검증이 그럴듯한 허구를 통과시킨다.
왜 한 편으로는 부족한가
다섯 단계를 한 단락씩 스치는 일은 지난 글에서 이미 했다. 그게 개요였다. 한 편으로 부족한 이유는, 각 단계가 고유한 함정을 가지기 때문이다.
정제는 한국어의 지저분함과 싸운다 — 표기가 흔들리는 만큼 “같다/다르다”의 경계가 무너진다. 태깅은 일관성이 적이다 — 같은 레시피에 매번 같은 축이 붙지 않으면 분류 자체가 신뢰를 잃는다. 검증은 그럴듯한 허구를 막는 일이다 — LLM은 틀려도 매끄럽게 틀리기에, 통과시킬지 말지의 기준이 까다롭다. 평가는 “좋아진 것 같다”는 착각과 싸운다 — 측정이 없으면 개선도 회귀도 그저 느낌이다. grounding은 유창함이 곧 정확함은 아니라는 문제와 마주한다. 각각이 한 편을 받을 자격이 있는 건, 답이 단락 하나에 담기지 않아서다.
한 가지는 분명히 해둔다. 이 글에서 말하는 LLM은 코퍼스를 짓고 검증·평가하는 데이터 파이프라인의 판단자다. 사용자에게 나가는 주 단위 식단을 짜는 코어 엔진은 LLM 없이 도는 결정론 알고리즘으로, 이와 별개다. 데이터 공정에서는 회색지대를 판단하는 LLM이 일하고, 식단을 짜는 자리에서는 재현 가능한 결정론이 일한다. 둘을 섞지 않는 것이 우리 설계의 전제다.
이게 시리즈가 되는 이유
그래서 다음 글부터, 다섯 단계를 한 편씩 펼친다. 정제는 “한국어는 지저분하다”는 현실에서, 태깅은 “무엇으로 분류할지가 도메인 지식이다”라는 명제에서 출발한다. 검증은 LLM을 판단자로 세우는 게이트를, 평가는 “좋아졌다”를 측정하는 법을, grounding은 판단을 도메인 사실에 묶는 일을 다룬다.
이 분해에서 우리가 얻은 종합은 이렇다. 8할을 다루는 일은 공정이고, 공정은 한 번 세우면 굴러가는 운영 역량이며, 운영 역량은 도메인이 바뀌어도 옮겨갈 수 있다. 우리가 한국어 식문화에서 세운 게이트의 구조는 식재료에 묶여 있지 않다. 묶여 있는 건 “정제할지, 태깅할지, 들일지, 좋아졌는지, 사실에 맞는지”라는 질문의 순서다.
모델을 고르기 전에
자기 도메인에 AI를 붙이려는 팀이라면, 모델을 고르기 전에 이 질문을 먼저 던지는 편이 낫다 — 우리 데이터에도 같은 게이트가 필요하지 않은가. 데이터 품질과 평가 공정을 운영하는 역량은 도메인 불문 이식 가능한 자산이다. 우리는 한국어 식문화라는, 충분히 지저분한 실제 도메인에서 이 게이트를 매일 굴리며 검증했다.