ai technology
LLM은 무엇을 먹고 자라는가 — 데이터셋의 구축과 확보
Junyoung Park · 2026-08-03 · 8 min
LLM 이야기를 하다 보면 모델 크기나 GPU 개수, 새로운 Attention 구조가 먼저 눈에 들어온다. 논문에서도 숫자로 비교하기 쉽고, 서비스 소개 자료에도 쓰기 좋기 때문이다. 그런데 막상 모델을 직접 학습하거나 특정 도메인에 맞춰보면 성능을 결정하는 일의 상당 부분은 데이터에서 일어난다. 어떤 문서를 넣었는지, 비슷한 문장을 몇 번 반복했는지, 정답이라고 부른 응답이 실제로 좋은지, 평가 데이터가 학습 데이터에 섞이지 않았는지에 따라 같은 아키텍처도 전혀 다른 모델이 된다.
그래서 데이터셋 구축을 단순히 텍스트를 많이 모으는 일로 보면 곤란하다. 수집할 권리가 있는 데이터를 확보하고, 모델이 배워야 할 분포를 설계하고, 그 설계가 실제 학습과 평가까지 유지되도록 추적하는 일에 가깝다. 데이터의 양은 여전히 중요하지만, 최근의 공개 연구들이 반복해서 보여준 것은 양과 품질을 따로 떼어 생각할 수 없다는 점이다. RefinedWeb, FineWeb, DataComp-LM은 필터링, 중복 제거, 데이터 혼합 방식만으로도 같은 원천 데이터의 가치가 크게 달라진다는 사실을 비교적 투명하게 보여준다.
하나의 데이터셋이 아니라, 학습 단계별 데이터가 있다
LLM 데이터라고 하면 거대한 말뭉치 하나를 떠올리기 쉽지만 실제 학습에서는 목적이 다른 데이터 묶음이 차례로 사용된다. Pre-training 데이터는 언어와 지식의 넓은 분포를 익히게 하고, Continued Pre-training 데이터는 법률·의료·금융 또는 한국어처럼 특정 영역의 비중을 조정한다. SFT 데이터는 질문을 받고 유용한 답을 만드는 형식을 가르치며, Preference 데이터는 여러 답 중 어느 쪽이 더 나은지를 알려준다. 강화학습 단계에는 모델이 직접 생성한 응답과 그 응답을 평가할 보상 신호가 필요하고, 마지막 평가 데이터는 이 모든 학습 데이터로부터 오염되지 않은 채 남아 있어야 한다.
| 구분 | 모델이 배우는 것 | 데이터 형태 | 가장 흔한 실패 |
|---|---|---|---|
| Pre-training | 언어, 지식, 추론의 기반 분포 | 웹·문서·코드·책 등의 연속 토큰 | 중복, 저품질, 편향된 언어 비율 |
| Continued Pre-training | 도메인과 언어의 재조정 | 전문 문서, 최신 문서, 장문 데이터 | 일반 성능의 망각, 과도한 도메인 편향 |
| SFT | 지시를 따르는 형식과 행동 | 입력-응답 쌍, 대화, 도구 호출 | 그럴듯하지만 틀린 모범답안 |
| Preference | 좋은 답의 상대적 기준 | 질문과 chosen/rejected 응답 | 평가자 편향, 길이에 대한 편향 |
| RL / RLVR | 보상에 맞춰 탐색하는 방법 | rollout, reward, 검증 가능한 정답 | reward hacking, 분포 붕괴 |
| Evaluation | 실제 일반화 여부 | 학습과 분리된 문제·사람 평가 | 데이터 누출, 벤치마크 과적합 |
이 구분이 중요한 이유는 각 단계에서 말하는 품질의 의미가 다르기 때문이다. Pre-training에서는 넓은 커버리지와 자연스러운 문맥이 중요하지만, SFT에서는 한 개의 잘못된 정답이 모델의 행동을 직접 가르칠 수 있다. Preference 데이터는 사실 정답을 요구하지 않을 때도 많지만 비교 기준이 일관되어야 한다. 결국 모든 데이터를 같은 필터와 같은 점수로 줄 세우는 방식은 간단해 보여도 좋은 설계가 되기 어렵다.
데이터는 어디에서 확보하는가
가장 넓은 원천은 여전히 웹이다. 웹 데이터는 규모가 크고 주제가 다양하며 계속 갱신된다는 장점이 있지만, 사용 권리와 개인정보, 스팸, 자동 생성 콘텐츠, 언어 판별 오류를 함께 가져온다. 공개 데이터셋과 공공 플랫폼은 출처와 형식이 상대적으로 분명하다. 국내에서는 AI Hub가 음성·이미지·텍스트를 포함한 여러 구축 데이터를 제공하지만, 공개되어 있다는 사실과 아무 조건 없이 재배포할 수 있다는 말은 같지 않다. 실제 사용 전에는 데이터별 이용정책과 권리 조건을 확인해야 한다.
라이선스 구매나 콘텐츠 사업자와의 계약은 비용이 들지만 권리 범위와 갱신 주기를 합의할 수 있다는 장점이 있다. 기업 내부 문서, 상담 기록, 검색 로그, 사용자가 수정한 결과처럼 서비스 운영에서 생기는 데이터는 도메인 적합도가 매우 높다. 반면 개인정보와 영업비밀이 포함되기 쉽고, 원래 수집 목적과 모델 학습 목적이 다를 수 있어 동의·보관·삭제 정책까지 함께 설계해야 한다. 사람이 직접 작성하거나 검수한 데이터는 특히 SFT와 Preference 학습에서 유용하지만 비싸고, 작업 지침이 불명확하면 평가자마다 서로 다른 모델을 머릿속에 그리게 된다.
마지막으로 합성 데이터가 있다. 강한 Teacher 모델로 문제와 답, 비판, 수정 과정을 만들 수 있어 희소한 언어나 도메인을 빠르게 보강할 수 있다. 다만 합성 데이터는 없는 지식을 공짜로 만드는 장치가 아니다. Teacher의 오류와 문체, 안전 정책까지 복제될 수 있고, 생성된 데이터가 서로 지나치게 비슷하면 겉보기 개수에 비해 정보량이 작다. 따라서 합성 데이터는 생성 → 규칙 또는 실행 기반 검증 → 중복 제거 → 일부 사람 검수까지를 하나의 파이프라인으로 보는 편이 안전하다.
수집한 뒤에 더 많은 일이 남는다
원천 데이터를 가져오면 먼저 문서 구조를 복원해야 한다. HTML의 메뉴와 광고, PDF의 머리말과 꼬리말, OCR 오류, 코드 블록과 표를 본문과 구분하지 않으면 모델은 사람이 읽는 문장보다 사이트의 잔해를 더 자주 보게 된다. 그다음 언어와 도메인을 분류하고, 문서 단위의 품질 필터를 적용한다. 너무 짧은 문서, 문자 비율이 비정상적인 문서, 키워드만 반복하는 SEO 스팸은 규칙으로 많이 제거할 수 있지만, 규칙을 강하게 만들수록 구어체·방언·짧은 창작물처럼 정상적인 데이터도 함께 사라진다. 최근에는 고품질 문서를 구분하는 작은 분류 모델을 사용하되, 특정 문체만 남지 않도록 규칙 기반 필터와 함께 쓰는 경우가 많다.
중복 제거는 메모리 절약 이상의 문제다. 완전히 같은 문서뿐 아니라 일부 문단만 복사된 문서, 템플릿만 다른 기사, 번역되어 반복된 콘텐츠를 그대로 두면 모델은 자주 나온 사실을 중요한 사실로 오해하고 특정 문장을 암기하기 쉬워진다. Exact hash는 동일 문서를 빠르게 찾고, MinHash나 locality-sensitive hashing은 거의 같은 문서를 찾는 데 쓰인다. 코드나 수학 데이터처럼 반복되는 형식 자체에 의미가 있는 영역에서는 중복 제거 강도를 별도로 정해야 한다.
PII와 유해 콘텐츠를 제거하는 단계도 필요하다. 이메일·전화번호 같은 패턴은 규칙으로 찾을 수 있지만, 문맥 속 개인 정보나 간접 식별 정보는 훨씬 어렵다. 필터가 모든 위험을 해결해 준다고 가정하기보다 원천별 보존 정책과 접근 권한, 삭제 요청에 대응할 데이터 lineage를 남겨야 한다. 저작권 역시 “인터넷에서 볼 수 있었다”는 이유만으로 학습과 재배포가 자동으로 허용되는 것은 아니다. 한국저작권위원회의 생성형 AI 학습을 위한 저작물의 공정이용 안내서는 공정이용 판단이 구체적인 이용 방식과 시장 영향 등에 따라 달라진다는 점을 설명한다. 데이터셋을 설계할 때는 법률 자문을 대체하는 단일 체크박스보다 출처, 라이선스, 동의 범위, 변환 이력을 계속 추적할 수 있는 구조가 중요하다.
데이터 혼합은 모델의 교육과정을 만드는 일이다
정제가 끝난 데이터도 그대로 섞으면 되는 것은 아니다. 웹 문서가 90%이고 코드가 2%인 원천 분포를 그대로 따를지, 코드와 수학의 비율을 의도적으로 높일지에 따라 모델이 잘하는 일이 달라진다. 데이터가 풍부한 영어를 지나치게 많이 넣으면 전체 벤치마크는 좋아질 수 있지만 한국어 표현력과 문화적 맥락이 약해질 수 있고, 반대로 한국어만 반복해서 넣으면 지식 범위와 다국어 전이가 줄어들 수 있다. 한국어는 조사와 어미 변화가 많기 때문에 Tokenizer의 vocabulary와 fertility도 함께 봐야 한다. 같은 문장을 지나치게 많은 토큰으로 쪼개면 학습과 추론 비용이 늘고 긴 문맥 안에 담을 수 있는 정보가 줄어든다.
초반에는 넓고 다양한 데이터를 사용하고 후반에는 고품질·도메인 데이터를 높이는 curriculum도 많이 사용된다. OLMo 2는 데이터 혼합과 학습 후반부의 curriculum, 체크포인트까지 공개해 이 단계가 부가적인 정리가 아니라 학습 recipe의 일부임을 잘 보여준다. 중요한 것은 “고품질 데이터 비율을 높였다”는 문장보다 어떤 점수로 품질을 정의했고, 그 변화가 일반 능력과 전문 능력에 각각 어떤 영향을 주었는지 ablation으로 확인하는 것이다.
평가셋 오염 검사는 혼합 전에 끝내야 한다. 벤치마크의 질문과 답을 그대로 찾는 것뿐 아니라 paraphrase, 해설, 번역본까지 학습 데이터에 들어갈 수 있다. 최근 모델의 벤치마크 점수가 실제 사용감과 어긋나는 이유 중 하나도 이 경계가 흐려졌기 때문이다. 공개 벤치마크와 별도로 배포 직전까지 비공개로 유지하는 holdout, 시간 기준으로 나눈 최신 데이터, 실제 업무에서 수집한 실패 사례를 함께 평가해야 모델이 무엇을 외웠고 무엇을 일반화했는지 조금 더 분명해진다.
SFT와 Preference 데이터는 정답보다 기준을 만든다
SFT 데이터의 핵심은 질문 수보다 응답의 기준이다. 정확성, 관련성, 간결성, 근거 제시, 거절 방식, 도구 사용 규칙이 하나의 답 안에서 충돌할 수 있기 때문에 annotation guideline에 우선순위가 필요하다. 예를 들어 “모르면 모른다고 답한다”와 “항상 도움을 준다”를 동시에 강조해 놓으면 평가자는 서로 다른 답을 선택한다. 좋은 SFT 세트는 성공 사례만 모으기보다 흔한 실패를 어떻게 수정했는지 보여주고, 긴 답이 항상 좋은 답으로 선택되지 않도록 길이와 형식을 다양하게 만든다.
Preference 데이터도 마찬가지다. 두 답 중 하나를 고르는 pairwise 비교는 절대 점수보다 안정적이지만, 질문이 모호하거나 두 답의 차이가 작으면 label noise가 커진다. 여러 평가자의 일치율을 보고, 근거를 함께 기록하고, 쉬운 비교와 어려운 비교를 구분하는 편이 좋다. 운영 중에는 사용자의 재질문, 답변 복사, 수정, 명시적 피드백을 학습 신호로 사용할 수 있지만 클릭 한 번을 곧바로 품질로 해석해서는 안 된다. 사용자 행동은 UI와 업무 상황의 영향을 받으므로 동의와 익명화뿐 아니라 신호의 의미를 검증하는 작업이 필요하다.
현실적인 데이터 확보 전략
처음부터 거대한 범용 말뭉치를 새로 만드는 것은 대부분의 팀에 비효율적이다. 먼저 목표 능력을 몇 가지로 좁히고, 그 능력을 측정할 평가셋을 만든 뒤 공개·라이선스·내부 데이터가 각각 어느 영역을 덮는지 inventory를 작성하는 편이 낫다. 빈 영역은 사람 작성이나 합성 데이터로 채우고, 작은 실험으로 데이터 source별 효율을 비교한다. 이때 모델 크기를 고정하고 데이터만 바꾸는 ablation이 없으면, 좋아진 성능이 데이터 때문인지 학습률이나 토큰 수 때문인지 알기 어렵다.
서비스가 시작된 이후에는 실패 사례가 가장 가치 있는 데이터가 된다. 모델이 틀린 질문을 수집하고, 원인을 지식 부족·지시 불이행·검색 실패·도구 오류·안전 정책 오류로 나눈 뒤 필요한 학습 단계에 되돌려야 한다. 모든 실패를 SFT에 추가하면 증상은 가릴 수 있어도 원인을 해결하지 못한다. 최신 지식 문제는 RAG가 적합할 수 있고, 출력 형식 문제는 SFT가, 선택 기준 문제는 Preference 학습이, 탐색이 필요한 수학·코드 문제는 검증 가능한 보상을 이용한 RL이 더 적합할 수 있다.
결국 좋은 데이터셋은 파일의 집합이 아니라 권리, 분포, 품질, 평가가 연결된 운영 체계다. 얼마를 모았는지보다 왜 이 데이터를 넣었고 무엇을 제거했으며, 그 결정이 어떤 능력을 만들었는지 설명할 수 있어야 한다. 데이터가 모델의 교과서라면 데이터 lineage와 평가셋은 그 교과서의 출처와 시험 범위를 기록하는 장부에 가깝다. 이 장부가 있어야 다음 글에서 다룰 Pre-training, Distillation, 강화학습도 무엇을 실제로 개선했는지 판단할 수 있다.