데이터가 없다

Part I — Zero Tokens

13조 토큰 vs 0

GPU 서버가 도착했다. L40S 48GB 2장, 총 96GB VRAM. nvidia-smi를 치면 0% 사용률로 대기 중이다.

GPT-4

~13조 토큰

인터넷, 코드, 학술 논문. 수십억 달러의 데이터 파이프라인.

Llama 3

15조 토큰

Meta의 오픈소스. Common Crawl 기반, 고품질 필터링.

우리 서버

0 토큰

96GB VRAM이 대기 중이다. 넣을 데이터가 없다.

최고급 오븐이 왔다. 하지만 냉장고가 비어 있다. 이것이 GPU 서버를 산 직후의 현실이다. 하드웨어 스펙은 충분한데, 그 안에서 돌릴 데이터가 준비되어 있지 않다. 파인튜닝에는 QLoRA 기준 최소 1,000~5,000건의 Q&A 쌍, Full fine-tune이면 1만~10만 건이 필요하다.

데이터 없는 GPU 서버는
책 없는 도서관이다.
건물은 있지만, 빌릴 책이 없다.

Part II — Data Beats Model

데이터가 모델을 이긴다

직감적으로는 큰 모델이 좋은 답변을 할 것 같다. 틀렸다. 2022년 DeepMind의 Chinchilla 논문이 이 상식을 뒤집었다.

Gopher

280B 파라미터, 300B 토큰

당시 최대 규모 모델. 파라미터 수로 승부했다.

Chinchilla

70B 파라미터, 1.4T 토큰

파라미터는 4분의 1. 대신 데이터를 4.7배 투입했다. 결과: 모든 벤치마크에서 Gopher를 이겼다.

Chinchilla Scaling Law의 결론은 명확하다. 같은 연산 예산이라면 모델을 키우는 것보다 데이터를 늘리는 것이 더 효율적이다. 이 논문 이후 Llama, Mistral, Gemma 등 거의 모든 오픈소스 모델이 학습 전략을 바꿨다. 큰 모델보다 좋은 데이터 — 이것이 2024년 이후 AI 업계의 합의다.

파인튜닝에서도 동일하다. 같은 7B 모델이라도, 정제된 5,000건의 Q&A로 학습하면 정확도 80%가 나온다. 정제 안 된 raw 데이터 5,000건이면 50%에 못 미친다. RAG에서는 이 격차가 더 극적이다. 문서의 청킹 품질, 임베딩 전처리, 메타데이터 설계에 따라 같은 질문에 대한 답변 정확도가 30%에서 85%까지 차이난다. 모델은 동일한데.

나쁜 데이터가 만드는 결과

오버피팅 — 학습 데이터를 그대로 복사하는 모델이 된다. 새 질문에 대답 못 한다
환각 증가 — 잘못된 문서를 검색하면 "자신있게 틀린 답"을 출력한다
모델 붕괴 — AI가 생성한 데이터로만 반복 학습하면 5세대 안에 품질이 붕괴한다 (Shumailov et al., 2024)

96GB VRAM에 쓰레기 데이터를 넣으면 쓰레기 모델이 나온다. 24GB GPU에 정제된 데이터를 넣으면 쓸 만한 모델이 나온다. GPU 사양이 아니라 데이터 품질이 성능을 결정한다.

Part III — RAG Comes First

RAG가 먼저다

데이터가 중요하다는 건 알겠다. 그런데 데이터가 없다. 여기서 선택지가 갈린다. 파인튜닝 데이터를 먼저 모을 것인가, RAG로 서비스부터 시작할 것인가.

RAG

Fine-tuning

구축 기간

2~4주

2~6개월

필요 데이터

문서 수백~수천 건

Q&A 쌍 1,000~100,000건

데이터 갱신

문서 교체 → 즉시 반영

재학습 필요 (수 시간~수일)

환각 제어

출처 문서 명시 가능

모델 내재화, 출처 불명

핵심 원리

모델에 문서를 붙여준다

모델의 가중치를 바꾼다

RAG를 먼저 구축하고, 서비스를 돌리고, 데이터가 쌓이면 그때 파인튜닝한다.

NVIDIA는 이것을 Data Flywheel이라 부른다. 서비스를 돌리면 사용자가 질문한다. 질문이 쌓이면 데이터가 된다. 데이터로 모델을 개선하면 더 나은 서비스가 되고, 더 많은 사용자가 온다. 바퀴는 한 번 돌기 시작하면 가속이 붙는다. 첫 회전에는 RAG면 충분하다.

01 — 시작

RAG로 서비스 오픈

기존 문서를 임베딩하고 서비스를 시작한다. 완벽하지 않아도 된다.

02 — 수집

사용자 데이터 축적

질문 로그, 피드백, 검색 실패 패턴이 자동으로 쌓인다.

03 — 전환

파인튜닝 시작

축적된 데이터로 QLoRA. 이때 GPU가 진짜 일을 시작한다.

Part IV — Start With What You Have

있는 데이터부터 쓴다

파인튜닝에 쓸 데이터는 없다. 하지만 RAG에 쓸 데이터는 이미 있다. 정리되어 있지 않을 뿐이다.

Source 01

서비스 운영 로그

실시간 수집 / 도메인 특화

운영 중인 서비스가 있다면, 사용자 질문과 시스템 응답 로그가 가장 귀한 데이터다. RAG 질의 패턴 분석에 즉시 사용 가능하고, 누적되면 파인튜닝 데이터셋의 원석이 된다. 피드백 UI("답변이 도움이 되었나요?")를 붙이면 품질 라벨링이 자동으로 시작된다.

Source 02

납품처 업무 문서

RAG 임베딩 / 즉시 수집

고객사에 납품한 시스템이 있다면, 그 고객의 업무 문서가 RAG의 지식 기반이 된다. 학칙, 규정, 매뉴얼, 공문, 양식. 문서 한 건을 추가할 때마다 AI의 답변 범위가 즉시 확장된다. 모델 재학습 없이.

Source 03

공개 데이터셋 + 합성 데이터

베이스라인 / 무료

AI Hub 한국어 데이터셋(KoAlpaca ~2만 건, kullm-v2 ~15만 건)은 HuggingFace에서 바로 다운로드 가능하다. Claude/GPT API로 도메인 특화 Q&A를 합성하면 데이터를 빠르게 확장할 수 있다. NIA 가이드라인 v3.5는 합성 데이터를 공식 인정하면서 실제 데이터와의 혼합 비율 기준까지 제시했다.

데이터 수집의 첫 번째 난관은 HWP다. 한국 공공기관 문서의 대다수가 한글(.hwp, .hwpx) 포맷인데, PDF나 Word와 달리 바이너리 독자 포맷이라 파싱이 까다롭다. 단순히 텍스트로 덤프하면 표의 행열이 뒤섞이고, 머리글이 본문에 섞인다.

Option A

HWPX 경유 파싱

HWP를 HWPX(Open XML)로 변환 후 XML 파싱. python-hwp, pyhwpx가 표·텍스트를 분리한다. 무료, 자체 구축 가능. 복잡한 서식은 깨진다.

Option B

VLM 기반 문서 파서

Vision-Language Model로 문서를 이미지 렌더링 후 구조 분석. 한국딥러닝 DEEP Parser 기준 정확도 97.3%. 정확하지만 비용과 처리 시간이 든다.

A로 시작하고, 정확도 부족한 문서만 B로 보완한다. 파싱 후에는 청킹(한국어 기준 600자 청크, 100자 오버랩)과 개인정보 비식별화(Microsoft Presidio)를 거쳐 임베딩한다.

Part V — The 90-Day Roadmap

90일 로드맵

서버 도착일로부터 90일. 이 안에 첫 번째 RAG 파이프라인이 돌아가야 한다.

기간	목표	작업 내용
Week 1~2	데이터 인벤토리	보유 데이터 목록화. 형식(HWP/PDF/Excel/DB), 건수, 품질 등급, 개인정보 포함 여부 기록
Week 3~4	파싱 파이프라인	HWP/PDF 파싱 → 텍스트/표 추출 → 개인정보 마스킹 → 청킹. 이 파이프라인은 다른 고객에게도 재사용 가능
Month 2	데이터 확장	공개 데이터셋 + 합성 Q&A 생성. 도메인 특화 Q&A 최소 1,000건 확보
Month 3	피드백 루프	서비스에 피드백 UI 추가. 낮은 점수 응답을 인간이 교정하면 파인튜닝 데이터가 된다

90일이 끝나면 손에 쥐는 것은 세 가지다.

RAG 지식 기반

수백~수천 건의 문서가 벡터 DB에 임베딩된 상태. 질문하면 관련 문서를 찾아 답변을 생성한다.

데이터 파이프라인

HWP/PDF → 텍스트 → 비식별화 → 청킹 → 임베딩의 자동화. 새 고객이 오면 문서를 넣기만 하면 된다.

피드백 루프

피드백이 자동 수집되는 구조. 파인튜닝에 쓸 고품질 데이터가 시간과 함께 축적된다.

파인튜닝은 이 다음이다. 피드백 라벨이 붙은 데이터가 1,000건을 넘으면, 그때 QLoRA로 첫 시도를 한다. 96GB VRAM이면 70B 모델도 파인튜닝이 가능하다. 부족한 것은 하드웨어가 아니라 데이터다.