자체 sLLM을 만들겠다고 결심한 팀이 가장 먼저 하는 일은 대개 '크롤링'입니다. 수백만 페이지를 긁고, 텍스트 용량을 자랑하고, "코퍼스 확보 완료"라고 선언합니다. 그리고 그 코퍼스를 모델에 태운 순간, 모델이 이상한 걸 말하기 시작합니다. "구독하기", "쿠키를 허용하시겠습니까", "관련 상품 더보기".
모델은 먹인 대로 배웁니다. 광고 문구를 먹이면 광고 문구를 배웁니다.
코퍼스는 채굴이 아니라 제련이다. 많이 캐는 게 아니라 잘 걷어내는 것이다.
파인튜닝의 승패는 GPU에서 갈리지 않습니다. 데이터를 태우기 전, '무엇을 태우지 않을 것인가'를 결정하는 정제 테이블에서 갈립니다.
TL;DR
파인튜닝 코퍼스는 '수집'이 본론이 아니라 '정제'가 본론이다. 웹 텍스트 더미와 학습용 원천 텍스트는 다른 물건이다.
잡음(광고·메뉴·중복)을 그대로 태우면 모델이 보일러플레이트를 학습하고 과대표집 편향에 걸린다. 학습 예산을 광고 문구에 쓰는 셈이다.
라이선스·개인정보 검토는 학습 '전'에 끝내야 한다. 태우고 나서 빼는 건 사실상 불가능하다.
목차
왜 '긁은 텍스트'는 코퍼스가 아닌가
제련 파이프라인 9단계
확보 방식 3가지 비교
자가진단 5문
FAQ
결론
지금 바로 시작하기
왜 '긁은 텍스트'는 코퍼스가 아닌가
정의부터 맞추겠습니다.
학습 코퍼스란, 웹에서 긁은 텍스트에서 보일러플레이트를 걷어내고 중복을 지우고 라이선스와 개인정보를 검토해 남긴 '정제된 원천 텍스트'다. 원석이 아니라 제련된 금속입니다.
보일러플레이트란, 본문이 아닌 반복 요소 전부다. 헤더, 사이드바, 푸터, 쿠키 배너, '관련 글', '구독하기' 버튼 텍스트. 사람 눈엔 안 보이지만 크롤러 눈엔 전부 텍스트입니다.
문제는 이겁니다. 웹페이지 하나에서 실제 본문이 차지하는 비중은 생각보다 작습니다. 나머지는 전부 반복되는 껍데기입니다. 이 껍데기를 그대로 태우면 무슨 일이 벌어질까요.
모델은 데이터에서 가장 자주 본 패턴을 가장 자신 있게 재생산합니다. 그런데 '구독하기'는 사이트마다, 페이지마다 반복됩니다. 정작 배워야 할 도메인 지식은 페이지당 한 번인데, 껍데기는 만 번입니다. 결과적으로 모델은 도메인 전문가가 아니라 '푸터 낭독기'가 됩니다.
모델은 먹인 대로 배운다. '구독하기' 버튼까지 학습한다.
제련 파이프라인 9단계
수집은 1단계일 뿐입니다. 나머지 8단계가 코퍼스의 품질을 결정합니다.
수집 — 대상 도메인·URL을 정하고 원천 HTML을 확보한다. 여기까지는 시작일 뿐이다.
보일러플레이트 제거 — 메뉴·광고·쿠키 배너·반복 UI 텍스트를 걷어내고 본문만 남긴다. 제련의 첫 불질.
근접중복 제거 — 완전 동일 문서뿐 아니라 '거의 같은' 문서까지 제거한다. 같은 기사를 복붙한 미러 사이트, 템플릿만 다른 상품 설명이 여기서 걸린다.
포맷 정규화(JSONL) — 뒤죽박죽 텍스트를 학습 파이프라인이 바로 읽는 한 줄 한 문서(JSONL) 구조로 통일한다.
라이선스/저작권 검토 — 학습에 태워도 되는 출처인지 확인한다. 이건 뒤가 아니라 여기서 해야 한다.
개인정보 스크러빙(PII 제거) — 이름·연락처·주민번호 등 개인 식별 정보를 걷어낸다. 한 번 태우면 되돌릴 수 없다.
독성/품질 필터링 — 유해 표현, 깨진 인코딩, 의미 없는 텍스트를 걸러낸다.
도메인 밸런싱 — 특정 출처·주제가 과대표집되지 않도록 비중을 조정한다. 한 사이트가 코퍼스의 절반이면 모델은 그 사이트를 흉내 낸다.
토큰 규모 산정 — 여기서 처음으로 규모를 잰다. 반드시 '정제 이후' 기준으로.
여기서 가장 많이 틀리는 게 9번입니다. 정제 전에 토큰을 세면 껍데기까지 포함된 허수입니다. 100억 토큰이라 자랑했는데 껍데기를 걷어내니 30억이더라, 하는 일이 실제로 벌어집니다.
토큰은 정제가 끝난 뒤에 세라. 그 전 숫자는 껍데기까지 센 허수다.
그리고 5번·6번의 순서를 절대 뒤로 미루지 마십시오. 라이선스와 개인정보는 학습 '전'에 처리해야 합니다. 모델 가중치에 한 번 녹아든 정보는 특정 문장만 골라 빼낼 수 없습니다. 사후 제거가 어려운 게 아니라, 사실상 재학습 말고는 답이 없습니다.
라이선스와 개인정보는 학습 전에 끝내라. 태운 뒤엔 빼낼 수 없다.
확보 방식 3가지 비교
코퍼스를 어떻게 손에 넣느냐는 세 갈래입니다. 각각 정직하게 강점과 약점이 있습니다.
축오픈 데이터셋직접 수집·정제관리형 코퍼스 납품규모크다(공개 대용량)팀 역량에 좌우요구 규모에 맞춤도메인 맞춤낮음(범용)높음높음라이선스 검토데이터셋별 상이직접 부담검토까지 완료 후 납품중복/PII 정제데이터셋별 상이직접 부담(파이프라인 구축)정제까지 완료유지 부담낮음높음(운영·갱신 전부)낮음(위탁)
오픈 데이터셋은 시작점으로 훌륭합니다. 공개돼 있고 규모가 크죠. 다만 우리 도메인에 딱 맞진 않고, 라이선스와 정제 수준이 데이터셋마다 제각각이라 '검증'이라는 숙제가 남습니다.
직접 수집·정제는 도메인 맞춤이 가장 강력합니다. 우리가 원하는 사이트를, 원하는 깊이로 긁을 수 있으니까요. 대신 위 9단계 파이프라인을 직접 짓고 굴려야 합니다. 여기서 대부분의 팀이 2번·3번·6번에서 무너집니다.
관리형 코퍼스 납품은 수집부터 라이선스 검토까지 마친 정제 코퍼스를 받는 방식입니다. 도메인 맞춤과 낮은 유지 부담을 동시에 가져가되, 그만큼 위탁 비용이 듭니다. 국내 데이터 수집 서비스 지형은 방식마다 결이 다른데, 이 지도를 더 넓게 보고 싶다면 국내 데이터 수집 서비스 비교 — 2026년의 진짜 지도 글을 참고하십시오.
해시스크래퍼는 세 번째 방식에 해당합니다. 국내 5,000개 이상 사이트 수집 경험과 195개국 프록시 인프라 위에서, 99.7% 정확도로 원천 텍스트를 확보하고 위 9단계 정제까지 마쳐 납품합니다. 500개 이상 기업과 일하며 법적 문제 0건을 유지해 온 이유는, 라이선스 검토를 '나중'이 아니라 파이프라인 안에 넣어두기 때문입니다.
자가진단 5문
지금 준비 중인 코퍼스에 아래를 대보십시오.
우리 코퍼스에서 광고·메뉴·쿠키 배너 텍스트를 실제로 걷어냈는가
'거의 같은' 문서(미러·복붙·템플릿)까지 중복 제거했는가
라이선스·저작권 검토를 학습 '전'에 끝냈는가
개인 식별 정보를 스크러빙했고, 못 지운 게 남아 있지 않은가
토큰 규모를 '정제 이후' 기준으로 다시 셌는가
3개 이하에 체크가 안 되면, 지금 태우려는 건 코퍼스가 아니라 껍데기 더미입니다.
FAQ
Q. LLM 파인튜닝 학습 데이터셋을 웹에서 어떻게 수집하고 정제하나요? A. 수집은 시작일 뿐이고 본론은 정제입니다. 원천 HTML을 확보한 뒤 보일러플레이트 제거 → 근접중복 제거 → JSONL 포맷 정규화 → 라이선스 검토 → 개인정보 스크러빙 → 독성/품질 필터링 → 도메인 밸런싱 → 토큰 규모 산정 순으로 처리해야 학습에 쓸 '정제된 원천 텍스트'가 됩니다. 이 중 라이선스와 개인정보 검토는 반드시 학습 전에 끝내야 합니다.
Q. 그냥 많이 긁으면 좋은 코퍼스 아닌가요? A. 아닙니다. 양이 아니라 정제 수준이 품질을 결정합니다. 잡음을 그대로 태우면 모델이 광고 문구를 반복 학습하고 특정 출처를 과대표집하는 편향에 걸립니다. 규모는 정제가 끝난 뒤에 세는 게 맞습니다.
Q. 라이선스나 개인정보는 나중에 빼면 안 되나요? A. 사실상 불가능합니다. 모델 가중치에 한 번 녹아든 정보는 특정 문장만 골라 제거할 수 없어, 재학습 외에는 답이 없습니다. 그래서 두 검토는 파이프라인 앞단에 두어야 합니다.
Q. 정제한 코퍼스는 만든 뒤에 어떻게 관리하고 활용하나요? A. 코퍼스를 만든 뒤 이를 사내 업무에 실제로 태우고 갱신하는 문제는 결이 다른 주제입니다. 사내 지식 활용을 다룬 별도 글에서 따로 다룹니다.
결론
파인튜닝 프로젝트가 실패하는 지점은 보통 GPU 앞이 아닙니다. 그 전, 껍데기까지 통째로 모델에 밀어 넣은 순간입니다. 코퍼스는 채굴량이 아니라 제련 품질로 판가름 납니다. 많이 긁은 팀이 아니라 잘 걷어낸 팀이 이깁니다.
핵심은 세 가지입니다. 정제가 본론이라는 것, 잡음을 태우면 모델이 잡음을 배운다는 것, 라이선스와 개인정보는 학습 전에 끝내야 한다는 것. 이 셋만 지켜도 학습 예산을 광고 문구에 낭비하지 않습니다.
학습 예산을 광고 문구에 쓰지 마라. 그 예산은 도메인 지식에 써야 한다.
지금 바로 시작하기
우리 도메인에 맞는 사이트를 정하고, 위 9단계로 정제된 코퍼스를 받는 데까지 함께하겠습니다. 국내 5,000개 이상 사이트 수집 경험, 195개국 프록시, 99.7% 정확도, 법적 문제 0건. 라이선스 검토를 파이프라인 안에 넣어 납품합니다. 신규 가입 시 5만 크레딧을 드립니다.
수집한 데이터를 알림·대응 루프로 확장하는 흐름은 모니터링은 수집이 아니라 알림이다 — 가격·평판 데이터로 대응 루프 만들기 글에서 이어집니다.
