대규모 언어 모델(LLM)의 성능은 전적으로 훈련 데이터의 품질과 구성에 달려 있다. 현대적인 LLM 사전 훈련 데이터셋을 구성하는 요소에 대해 상위 수준의 원칙부터 시작하여, 대표적인 데이터셋의 상세 분석을 진행하겠다.
LLM 훈련 데이터셋의 역사는 원시적인 대규모 데이터 수집에서 정교하게 선별된 지식의 집합체로 발전해 온 과정이다. 초기 LLM들은 주로 Common Crawl과 같은 방대하지만 노이즈가 많은 웹 스크래핑 데이터에 의존했다. 이 시기는 더 많은 데이터가 더 나은 성능을 가져온다는 양적 접근에 가까웠다. 그러나 이 접근법은 모델이 웹에 만연한 편향, 저품질 콘텐츠, 반복적인 텍스트를 학습하는 부작용을 낳았다.
이러한 패러다임에 전환을 가져온 것은 친칠라 스케일링 법칙의 등장이었다. 이 연구는 모델의 크기만큼이나 데이터의 양이 모델 성능에 결정적인 영향을 미친다는 것을 입증하며, 업계의 초점은 더 큰 모델을 만드는 것에서 수조 개의 토큰에 달하는 고품질 데이터를 확보하고 처리하는 방향으로 전환시켰다. 이로 인해 데이터 큐레이션은 LLM 개발의 핵심적인 공학 분야가 되었다.
결과적으로, LLM 데이터셋의 개발은 양이 많을수록 좋다는 단순한 철학에서 더 나은 데이터가 더 나은 모델을 만든다는 정교한 철학으로 진화했다. 여기서 더 나은 데이터란 단순한 깨끗한 텍스트를 넘어 품질, 다양성, 그리고 전략적인 구성까지 포괄하는 개념이다. 이러한 진화는 데이터셋을 단순한 입력값에서 벗어나, 그 자체로 설계 철학과 생명 주기를 가진 공학적 산물로 인식하게 만들었다. 초기 LLM들이 사용 가능한 대규모 텍스트, 주로 웹 크롤링 데이터에 의존했다면, C4나 RefinedWeb과 같은 프로젝트들은 데이터 소스만큼이나 필터링 과정이 중요함을 보여주며 데이터에 제조와 유사한 접근법을 도입했다.
The Pile은 의도적인 구성과 가중치 부여라는 개념을 도입하여, 레시피를 만드는 것과 같은 데이터셋 설계를 선보였다. 최종적으로 Dolma는 데이터뿐만 아니라 툴킷을 오픈소스로 공개함으로써, 재현성과 지속적인 개선을 강조하며 이러한 진화를 완성했다. 이 과정은 스크립트에서 시작하여 DevOps, MLOps로 발전한 소프트웨어 개발의 역사와 유사하며, LLM 데이터 큐레이션이 이제 전문화된 공학 분야임을 시사한다.
현대적 LLM의 지식 기반은 다양한 출처에서 수집된 방대한 텍스트 데이터로 구성된다. 각 데이터 소스는 모델에 고유한 언어적 특성과 지식을 주입하는 역할을 한다.
Common Crawl은 페타바이트 규모의 공개 웹 아카이브로, AWS S3에 저장되어 누구나 접근할 수 있다. 이는 LLM 훈련 데이터의 가장 큰 단일 소스이다. 데이터는 세 가지 주요 형식(WARC(원시 HTML 응답), WET(추출된 텍스트), 메타데이터 파일)으로 제공된다. WARC 파일은 웹페이지의 원본을 담고 있으며, WET 파일은 여기서 텍스트를 추출한 것이다. 그러나 Common Crawl의 원시 데이터는 상용구, 스팸, 저품질 콘텐츠, 포맷팅 오류 등 상당한 노이즈를 포함하고 있어, 그대로 사용하기에는 부적절하다. 따라서 정제 파이프라인의 주요 대상이 된다.
서적 데이터는 LLM이 장문의 일관성과 서사 구조를 학습하는 데 중요하다. 주요 데이터셋으로는 BookCorpusOpen, Project Gutenberg에서 파생된 PG-19, 그리고 논란의 여지가 있는 Books3가 있다. 특히 The Pile 데이터셋의 일부인 Books3는 Sci-Hub, Z-Library와 같은 그림자 도서관에서 수집된 저작권 자료를 포함하고 있어, 데이터의 품질과 법적/윤리적 문제 사이의 갈등을 보여주는 대표적인 사례이다.
연구자들은 서적과 같은 고품질의 다양한 소스가 모델 성능에 중요하다고 인식했지만, 가장 큰 디지털 서적 모음은 저작권 침해 소지가 있는 웹 사이트에서 비롯되어 법적 위험을 초래한다. 이로 인해 접근 방식이 양분되었다.
The Pile과 같은 일부는 성능을 위해 이런 데이터를 포함했다가 법적 문제에 직면했고, RefinedWeb과 같은 다른 일부는 이러한 문제를 피하기 위해 의도적으로 웹 데이터로만 제한하면서도 높은 성능을 달성할 수 있음을 증명했다. 이는 향후 데이터셋 개발이 법적 고려 사항에 의해 크게 제약을 받을 것이며, 허용 가능한 소스에서 서적과 같은 품질을 추출하기 위한 더 정교한 방법이나 라이선스가 부여된 훈련 데이터 시장의 성장을 촉발할 수 있음을 시사한다.
arXiv, PubMed Central과 같은 학술 아카이브는 모델에 형식적인 언어, 추론 능력, 그리고 과학, 수학, 의료와 같은 특정 분야의 전문 지식을 주입하는 데 필수적이다. 이런 데이터는 모델이 복잡하고 구조화된 정보를 이해하고 생성하는 능력을 향상시킨다.
The Pile과 Dolma에 포함된 대규모 코드 코퍼스는 LLM의 추론 및 구조적 사고 능력을 개발하는 데 중요한 역할을 한다. 코드는 논리적 흐름과 엄격한 구문을 가지고 있어, 모델이 문제 해결 능력을 학습하는 데 도움을 준다.
Stack Exchange, Reddit 과 같은 플랫폼에서 수집된 데이터는 대화의 맥락, 질의응답 형식, 그리고 실생활에서 사용되는 다양한 언어 표현을 제공한다. 이는 모델이 보다 자연스럽고 상호작용적인 언어를 구사하는 데 기여한다.
The Pile은 다양성을 핵심 가치로 내세운 데이터셋이다. 학술 논문부터 인터넷 로그에 이르기까지, 광범위한 주제와 스타일을 포괄하기 위해 의도적으로 선택된 22개의 개별 하위 데이터셋으로 구성되어 있다. The Pile의 중요한 특징 중 하나는 훈련 에포크(Epoch) 동안 PubMed나 arXiv와 같은 고품질 소스의 데이터에 더 높은 가중치를 부여하여, 모델이 양질의 정보를 더 많이 학습하도록 유도했다. 그러나 저작권이 있는 자료를 포함한 점은 데이터 다양성 극대화와 법규 준수 사이의 갈등을 보여주는 사례가 되었다.
C4는 다양한 소스를 조합하는 대신, 단일 소스인 Common Crawl을 필터링하는 방법론에 초점을 맞춘 데이터셋이다. C4의 정제 과정은 다음과 같은 엄격한 규칙 기반 필터링을 한다.
이는 휴리스틱 기반 데이터 정제의 기초적인 접근법을 제시했다.
RefinedWeb은 The Pile의 다중 소스 접근법과 정반대의 철학을 제시한다. 이 데이터셋은 세심하게 필터링되고 중복 제거된 웹 데이터만으로도 고성능 모델을 만들 수 있다고 주장하며, 선별된 비 웹 코퍼스가 필수적이라는 기존 이론에 상반된다. RefinedWeb의 방법론은 URL 기반 필터링, trafilatura 와 같은 고급 텍스트 추출 도구 사용, 그리고 다단계 중복 제거 프로세스를 포함한다.
Dolma는 재현성과 규모에 초점을 맞춘 개방형 데이터셋이다. 이 프로젝트의 핵심은 데이터와 함께 제공되는 오픈소스 Dolma Toolkit이다. 이 툴킷을 통해 다른 연구자들이 데이터 큐레이션 과정을 그대로 재현하거나 확장할 수 있게 함으로써, 사전 훈련 데이터 준비 과정을 표준화하는 진전을 이루었다.
아래 표는 주요 LLM 사전 훈련 코퍼스의 특징을 요약하여 비교한다.
| 데이터셋 이름 | 크기(토큰) | 핵심 구성 | 주요 정제 / 필터링 철학 | 라이선스 / 주요 이슈 |
|---|---|---|---|---|
| C4 | 약 1,560억 | Common Crawl | 엄격한 휴리스틱 기반 필터링 (품질, 길이, 유해성) | ODC-BY, Common Crawl 이용 약관 |
| The Pile | 약 8,860억 | 22개의 다양한 소스 (웹, 서적, 코드, 학술) | 다양성 극대화, 고품질 소스 가중치 부여 | 혼합 라이선스, Books3 구성 요소의 저작권 문제 |
| RefinedWeb | 5조 | Common Crawl | 웹 데이터만 사용, 엄격한 필터링 및 대규모 중복 제거 | ODC-BY-1.0 |
| Dolma | 3조 | 다양한 소스 (웹, 학술, 코드, 서적 등) | 재현 가능성에 초점, 오픈소스 툴킷 제공 | ODC-BY |
최적의 데이터 혼합 비율을 찾는 것은 LLM 성능에 큰 영향을 미치지만 계산 비용이 매우 높은 문제이다. 초기에는 데이터셋을 구성할 때 휴리스틱과 수동 튜닝에 의존했다. 예를 들어 The Pile은 고품질로 인식되는 소스의 가중치를 경험적으로 높였다.
최근 연구는 이 과정을 자동화하는 방향으로 발전하고 있다. RegMix는 데이터 혼합 비율 선택 문제를 회귀 문제로 재구성한다. 이 방법은 다양한 혼합 비율로 소형 모델을 훈련한 결과를 바탕으로 대형 모델의 성능을 예측하는 회귀 모델을 학습한다. 이를 통해 대형 모델을 여러 번 훈련하지 않고도 최적의 혼합 비율을 효율적으로 찾을 수 있다.
또한 Mixture of Data Experts(MDE)와 Model Estimated Data Utility(MEDU)와 같은 방법도 제안되고 있다. MDE는 각 데이터 소스별 전문가 모델을 훈련한 뒤 이들의 예측을 가중 평균하여 성능을 근사한다. MEDU는 LLM이 소규모 데이터 샘플을 평가하여 데이터의 유용성을 추정한다. 이러한 접근법은 데이터 큐레이션을 경험적 예술에서 데이터 기반 과학으로 이동시키고 있다.
대규모 웹 크롤링을 위해서는 목적과 환경에 맞는 적절한 프레임워크를 선택하는 것이 중요하다.
Scrapy는 빠르고 강력하며 고도로 사용자 정의 가능한 오픈소스 프레임워크이다. 맞춤형 스파이더를 구축하는 데 이상적이며, 비동기식 아키텍처를 채택하여 대규모 데이터 수집에 효율적이다. 방대한 커뮤니티와 문서를 통해 높은 유연성을 제공한다.
Nutch는 배치 처리와 분산 크롤링을 위해 설계된 성숙하고 확장성 높은 프레임워크이다. Hadoop MapReduce와 통합되어 사용되며, 기업 수준의 지속적인 대규모 크롤링 작업에 적합하다. 모듈식 플러그인 시스템을 통해 HTML, PDF, XML 등 다양한 콘텐츠 유형을 처리할 수 있다.
Crawlee는 JavaScript 기반 동적 페이지를 처리하는 데 탁월한 현대적인 라이브러리이다. 프록시 순환, 인간과 유사한 헤더 자동 생성과 같은 차단 방지 기능이 내장되어 있어 복잡한 웹사이트 크롤링에 유리하다.
이 외에도 고성능 분산 크롤러인 BUbiNG이나 웹 아카이빙에 특화된 Heritrix와 같은 도구도 특정 목적에 따라 고려될 수 있다.
아래 표는 주요 웹 크롤링 프레임워크의 특징을 비교하여 프로젝트 요구사항, 기존 기술 스택, 대상 웹사이트의 특성에 따라 최적의 도구를 선택하기 위한 의사결정 프레임워크를 제공한다. 엔지니어는 크롤링 프로젝트를 시작할 때 여러 성숙한 프레임워크 중 하나를 선택해야 하며, 최고의 선택은 상황에 따라 달라진다.
이 표는 프로그래밍 언어, 확장성 모델, 주요 기능과 같은 핵심 엔지니어링 축을 기준으로 결정을 구조화한다. 예를 들어 Python 전문 지식을 가진 팀이 정적 및 동적 사이트를 혼합하여 타겟팅하는 경우 Scrapy를 선택하고 Playwright와 통합할 가능성이 높다. Java/Hadoop 생태계를 갖춘 대기업이 장기적인 웹 아카이브를 구축하는 경우 Nutch를 선호할 것이다. 현대적인 SPA 스크래핑에 집중하는 스타트업은 내장된 차단 방지 기능 때문에 Crawlee를 선호할 수 있다.
아래 표는 이러한 트레이드오프를 명시적으로 보여주어 프로젝트의 확장성이나 효율성을 저해할 수 있는 차선의 기술 선택을 방지한다.
| 프레임워크 | 언어 | 핵심 아키텍처 | 주요 강점 | 최적 사용 사례 |
|---|---|---|---|---|
| Scrapy | Python | 비동기(Twisted 기반) | 높은 유연성, 빠른 속도, 강력한 커뮤니티 | 맞춤형, 복잡한 스크레이핑 로직이 필요한 대규모 프로젝트 |
| Apache Nutch | Java | MapReduce 기반 배치 처리 | 뛰어난 확장성, Hadoop 생태계 통합, 모듈성 | 전체 웹 아카이빙, 기업 수준의 지속적인 크롤링 |
| Crawlee | Node.js | 비동기(HTTP 및 브라우저 기반) | JavaScript 렌더링, 내장된 차단 방지 기능 | 동적 웹사이트, 단일 페이지 애플리케이션(SPA) 크롤링 |
웹 크롤링은 단순한 기술적 과제일 뿐만 아니라, 웹 생태계의 책임 있는 구성원으로서 지켜야 할 윤리적 규범을 동반한다.
Robots.txt는 크롤러가 접근해서는 안 되는 경로와 요청 간 최소 지연 시간을 명시한다. 이를 무시하는 것은 웹사이트 운영자에게 피해를 줄 뿐만 아니라 법적 문제나 IP 차단으로 이어질 수 있다.
과도한 요청을 피하기 위해 크롤러는 요청 속도를 조절해야 한다. 일반적으로 초당 1~2개의 요청이 권장되며, 서버로부터 429나 503 오류를 받으면 지수 백오프 전략에 따라 재시도 간격을 늘려야 한다. 또한 트래픽이 몰리는 피크 시간대를 피해 크롤링하는 것이 바람직하다.
크롤러는 User-Agent 헤더를 통해 자신의 신원을 명확히 밝혀야 한다. 여기에는 봇의 이름, 목적, 그리고 연락 가능한 정보가 포함되는 것이 좋다. 이는 투명성을 높이고 문제가 발생했을 때 원활한 소통을 가능하게 한다.
현대의 많은 웹사이트는 JavaScript로 동적 콘텐츠를 로드하므로, 초기 HTML만 보는 전통적 크롤러는 이러한 콘텐츠를 수집하지 못한다는 문제가 있다.
Playwright, Puppeteer, Selenium 같은 브라우저 자동화 프레임워크는 UI 없이 실제 브라우저를 실행하여 JavaScript를 완전 렌더링하고 최종 DOM에 접근하게 한다. 이 방법은 충실도가 가장 높지만, 리소스 소모가 크고 속도가 느리다.
브라우저 개발자 도구로 네트워크를 관찰해 동적 데이터를 반환하는 백엔드 API를 식별한 뒤, 스크레이퍼에서 해당 API를 직접 호출하여 브라우저 렌더링을 생략한다. 이 방식은 효율적이지만, 사이트 구조 변경에 매우 취약하며 API로 제공되지 않는 콘텐츠는 놓칠 위험이 있다.
LLM을 활용한 최신 도구들은 CSS 선택자 없이도 필요한 데이터를 이해하고, 로드 대기나 무한 스크롤 같은 동적 요소를 지능적으로 처리한다. 구현 편의성과 적응력이 장점이나, 복잡도, 비용, 정밀도 측면에서 한계가 존재한다.
이런 접근법은 정확도(fidelity)와 효율성(efficiency) 간의 근본적 트레이드오프를 드러낸다. API 재현은 가장 효율적이지만 충실도가 낮고 취약성이 크며, 헤드리스 브라우저는 충실도가 높지만 대규모에선 비용과 속도 문제를 초래한다. 따라서 하이브리드 계층적 접근법이 현실적이다. 일반 정적 사이트는 빠른 HTTP 요청으로 처리하고, 초기 분석으로 식별된 고부가가치 동적 사이트에만 헤드리스 브라우저나 AI 기반 기법을 적용하면 비용과 충실도의 균형을 최적화할 수 있다.
수십억 페이지를 크롤링하기 위해서는 단일 시스템의 한계를 넘어서는 분산 아키텍처가 필수적이다.
분산 아키텍처는 여러 대의 기계가 병렬로 크롤링 작업을 수행하는 구조이다. 핵심 구성 요소는 공유 URL 프런티어, 상태 비저장 워커 노드, 차단 회피, 방문한 URL 관리이다.
차단 회피는 IP 순환과 핑거프린팅 대응을 통해 이루어진다. 단일 IP 주소에서 발생하는 대량의 요청은 웹사이트의 방화벽에 의해 쉽게 탐지되고 차단되므로, 데이터센터, 주거용, 모바일 등 수천 개의 IP로 구성된 프록시 풀을 사용하여 요청을 분산시키는 IP 순환 기법이 필수적이다. 또한 User-Agent 문자열이나 다른 HTTP 헤더를 주기적으로 변경하여 크롤러가 특정 패턴으로 식별되는 것을 방지해야 한다. 크롤러와 웹사이트 간의 관계는 본질적으로 적대적이다. 웹사이트가 JavaScript 챌린지나 핑거프린팅과 같은 정교한 방지 조치를 배포함에 따라 크롤링 도구는 단순한 HTTP 요청 라이브러리에서 인간의 행동과 인프라를 모방하는 복잡한 시스템으로 진화하고 있다.
방문한 URL 관리는 대규모 크롤링에서 중요한 과제이다. 이미 방문한 URL인지 확인하는 과정이 병목이 될 수 있기 때문이다. 수십억 개의 URL을 데이터베이스에 저장하고 조회하는 것은 비효율적이다. 이때 블룸 필터와 같은 공간 효율적인 확률적 데이터 구조를 사용하면 약간의 오탐을 감수하는 대신 최소한의 메모리로 매우 빠르게 중복 방문 여부를 확인할 수 있다.
데이터 정제 파이프라인은 가장 기본적인 텍스트 처리에서 시작된다.
가장 첫 단계는 텍스트 인코딩을 일관되게 UTF-8로 맞추고 디코딩 오류를 수정하는 것이다. 그 다음, 문서 수준에서 신뢰도 높은 언어 식별을 수행한다. 대상 언어와 일치하지 않거나 신뢰도 점수가 낮은 문서는 폐기된다. 예를 들어 RefinedWeb의 경우 0.65 미만, C4의 경우 0.99 미만인 문서는 제외된다.
웹페이지에서 헤더, 푸터, 내비게이션 바, 광고 등 실제 본문과 관련 없는 상용구 요소를 제거하고 핵심 콘텐츠만 추출하는 것이 목표이다.
도구: trafilatura나 Boilerpipe와 같은 라이브러리가 이 작업에 널리 사용된다. 이들은 텍스트 밀도, 링크 밀도와 같은 얕은 텍스트 특징과 HTML 구조적 특징을 조합하여 텍스트 블록이 본문인지 상용구인지를 분류한다.
WET 파일의 한계: Common Crawl은 미리 텍스트가 추출된 WET 파일을 제공하지만, RefinedWeb과 같은 고품질 파이프라인은 원시 HTML(WARC 파일)에서 직접 텍스트를 재추출한다. 이는 WET 파일에 상당한 양의 상용구가 포함되어 있기 때문이다.
이 단계에서는 계산 비용이 저렴하면서도 효과적으로 저품질 문서를 제거할 수 있는 규칙 기반 필터를 적용하여 데이터셋을 대규모로 정리하는 것이 목표이다.
문서 수준 필터는 다양한 기준으로 적용된다.
라인 수준 필터도 중요하다. 불완전한 텍스트 추출 과정에서 남은 “Home”, “About Us”와 같은 내비게이션 요소나 “[3 comments]”와 같은 소셜 미디어 카운터는 불필요하므로 제거하는 것이 필요하다. 또한 문장 부호로 끝나지 않거나 단어 수가 너무 적어 구문적 기준을 충족하지 못하는 라인 역시 필터링 대상이다.
중복 데이터 제거는 훈련 효율성을 높이고 모델이 특정 텍스트에 과적합되는 것을 방지하며 개인정보 공격의 위험을 줄이는 데 매우 중요하다.
각 문서의 내용을 해시(SHA-256 등)로 계산하여 해시값이 동일한 문서는 정확히 일치하는 중복으로 간주한다. 이 경우 하나만 남기고 모두 제거한다. 이 방법은 계산적으로 매우 효율적이며 중복 제거의 첫 번째 방어선 역할을 한다.
정확한 해싱은 타임스탬프나 광고와 같은 사소한 차이가 있는 문서를 잡아내지 못하므로 근사 중복 탐지가 필요하다. 이를 위해 싱글링, MinHash, LSH 기법이 사용된다.
싱글링은 문서를 겹치는 n-그램의 집합으로 표현하는 방법이다.
MinHash는 각 문서의 싱글 집합에 여러 해시 함수를 적용해 가장 작은 해시값을 선택하여 문서를 간결한 시그니처 벡터로 변환한다. 두 문서의 시그니처 유사도는 원본 집합의 자카드 유사도를 근사한다.
LSH는 모든 문서 쌍을 비교하지 않고, MinHash 시그니처를 밴드 단위로 나누어 해싱하여 버킷에 넣는다. 유사한 문서는 같은 버킷에 충돌할 확률이 높기 때문에, 동일 버킷 내 문서 쌍만 비교하면 계산량을 크게 줄일 수 있다.
대규모 데이터에서는 Apache Spark와 같은 분산 프레임워크를 사용하여 이 알고리즘을 구현할 수 있으며, Spark의 MinHashLSH 클래스는 대규모 데이터 처리에 유용하다.
MinHash와 LSH는 구문적 유사성은 잘 포착하지만 의역되거나 개념적으로 동일한 내용은 놓친다.
이를 해결하기 위해 사전 훈련된 문장 임베딩 모델을 사용하여 문서를 고밀도 벡터로 변환한 후, k-평균 클러스터링이나 근사 최근접 이웃 탐색을 적용한다. 이 방법은 의미적으로 유사한 문서를 그룹화하며 각 클러스터에서 대표 문서만 남긴다. 계산 비용이 가장 크지만 가장 강력한 중복 제거 기법이다.
데이터 정제 파이프라인은 점진적인 정제 과정으로 볼 수 있으며, 계산 비용과 의미론적 정교함이 점차 증가하는 깔때기 구조를 가진다.
각 단계는 가장 쉬운 문제들을 먼저 제거하여 더 비용이 많이 드는 후속 단계가 더 작고 깨끗한 데이터셋에 대해 작동하도록 한다. 파이프라인은 저렴하고 규칙 기반인 휴리스틱(길이, 반복)으로 시작하여 페타바이트 규모의 원시 데이터에 적용할 수 있으며, 이는 노이즈 감소 측면에서 가장 큰 효율을 제공한다.
그다음으로 더 복잡하지만 여전히 구문 중심적이며 Spark에서 확장 가능한 근사 중복 탐지(MinHash/LSH)가 이미 필터링된 데이터에 적용된다.
마지막으로 의미론적 중복 제거 및 모델 기반 품질 채점과 같은 가장 비용이 많이 드는 단계는 이미 저렴한 품질 관문을 통과한 훨씬 작고 고품질의 데이터셋에 적용된다. 이러한 계단식 설계는 고전적인 엔지니어링 최적화 방식으로, 가장 비싼 계산 자원(예: 대형 임베딩 모델을 사용한 추론)이 이미 품질 검사를 통과한 데이터에만 사용되도록 보장한다.
퍼플렉서티(Perplexity) 필터링은 언어 모델이 특정 텍스트 시퀀스를 보고 얼마나 놀라는지를 측정하는 지표이다.
낮은 퍼플렉서티는 유창하고 예측 가능한 텍스트를, 높은 퍼플렉서티는 노이즈, 비문법적 문장, 또는 코드를 나타낼 수 있다. 비교적 작은 범용 언어 모델을 훈련시킨 후 이를 사용하여 사전 훈련 코퍼스의 모든 문서에 대한 점수를 매기며, 특정 퍼플렉서티 범위를 벗어나는 문서를 제거한다.
연구에 따르면 이렇게 정제된 데이터로 훈련된 대형 모델은 성능이 크게 향상될 수 있다.
분류기 기반 점수화는 소규모의 인간이 직접 레이블링한 고품질 대 저품질 데이터셋으로 분류기를 훈련시키는 방법이다. fastText나 BERT 스타일 모델과 같은 분류기를 활용하며, 이를 통해 대규모 코퍼스의 모든 문서에 품질 점수를 부여한다. 이후 특정 임계값 이상의 점수를 받은 문서만 유지하여 데이터 품질을 보장한다.
“품질”의 정의는 보편적이지 않으며 최종 모델의 목적에 따라 달라지고 진화한다.
필터링 기준 자체는 최종 모델이 어떤 능력을 가져야 하는지에 대한 편향과 가정을 내포한다. 예를 들어 C4 데이터셋의 엄격한 “자연스러운 영어” 필터링은 소수 집단의 텍스트와 LGBTQ+ 정체성에 대한 논의를 불균형적으로 제거했다. 이는 겉보기에 중립적인 휴리스틱이 사회적 편향을 내포할 수 있음을 보여준다.
퍼플렉서티 필터링은 일반적이고 예측 가능한 텍스트를 선호하는 경향이 있어 창의적이거나 새로운 언어 스타일의 가중치를 낮출 수 있다. RefinedWeb 연구는 종종 저품질로 여겨지는 웹 데이터가 올바르게 필터링되면 선별된 코퍼스를 능가할 수 있음을 보이며 고품질 소스의 정의 자체에 의문을 던진다.
따라서 데이터 파이프라인 설계자는 필터링 선택이 하류에 미치는 영향을 인식해야 한다. 목표는 추상적으로 완벽한 데이터셋을 만드는 것이 아니라 최종 LLM의 의도된 능력과 가치에 최적화된 데이터셋을 만드는 것이다. 이는 문서화의 필요성과 직접적으로 연결된다.
개인 식별 정보(PII) 삭제는 개인정보 보호 및 GDPR과 같은 규제 준수를 위해 매우 중요하다. 이름, 주소, 전화번호 등 PII 유형을 식별하고 삭제하거나 마스킹하기 위해 명명된 개체 인식(NER) 모델을 사용한다.
규칙 기반 시스템에서 spaCy, BERT, 또는 미세 조정된 대형 언어 모델과 같은 더 강력하고 문맥을 인식하는 ML 모델로 진화하는 접근을 채택한다. 다만 마스킹된 데이터조차도 재구성 공격에 취약할 수 있다는 위험을 명확히 인지해야 한다.
유해성 필터링은 유해하거나 편향적이거나 해로운 콘텐츠를 식별하고 제거하는 과정이다. 이 과정은 단순한 차단 목록 기반 필터링을 포함할 수 있으나, 더 효과적인 방법은 전용 유해성 분류기를 훈련시켜 사용 중인 코퍼스 전체에 점수를 매기고 임계값 기준으로 필터링하는 방식이다.
벤치마크 오염 제거는 평가 벤치마크와 그 정답이 훈련 데이터에 유출되어 모델의 성능 지표가 부풀려지는 문제를 다룬다. 이를 방지하기 위해 모든 평가 데이터셋의 n-그램 표현을 생성하고 사전 훈련 코퍼스 내에서 이러한 n-그램을 검색하여 상당한 중복이 있는 문서를 제거한다. 이 절차는 평가의 무결성을 보장하기 위한 필수적인 단계이다.
종합하면, 안전 및 무결성 프로토콜은 기술적 필터링과 윤리적 고려를 결합한 체계이다. 필터링 기준은 모델의 목표와 가치에 맞추어 설계되어야 하며, PII 삭제, 유해성 필터링, 벤치마크 오염 제거 같은 구체적 절차가 포함되어야 한다. 또한 필터링이 사회적 편향을 야기할 가능성을 지속적으로 모니터링하고 문서화하여 의사결정의 투명성을 확보해야 한다.
견고한 데이터 파이프라인은 몇 가지 핵심적인 소프트웨어 공학 원칙 위에 구축된다.
모듈성(Modularity)은 정제, 필터링, 중복 제거 등 각 정제 단계가 독립적이고 자체 완비된 구성 요소로 설계되는 것을 의미한다. 이는 테스트와 유지보수, 그리고 특정 단계의 구현을 교체하는 과정을 용이하게 한다.
멱등성(Idempotency)은 각 태스크가 동일한 입력에 대해 여러 번 실행되더라도 항상 동일한 출력을 생성하도록 보장하는 성질이다. 이는 장애가 발생했을 때 데이터 손상 없이 복구할 수 있게 하므로 매우 중요한 원칙이다.
관찰 가능성(Observability)은 파이프라인이 진행 상황을 추적하고 장애를 진단하며, 시간 경과에 따른 데이터 품질 지표를 모니터링할 수 있도록 강력한 로깅, 모니터링, 경고 시스템을 갖추는 것을 의미한다. 이는 데이터 파이프라인이 신뢰할 수 있는 운영 환경에서 안정적으로 동작하도록 하는 핵심 요소이다.
대규모 데이터 처리 워크플로우는 수많은 단계와 복잡한 종속성을 가지므로 이를 안정적으로 관리하기 위해서는 오케스트레이션 도구가 필수적이다.
Apache Airflow는 워크플로우를 프로그래밍 방식으로 작성, 스케줄링 및 모니터링하는 오픈소스 플랫폼이다. 핵심 개념은 방향성 비순환 그래프(DAG)로, 태스크와 그들 간의 종속성을 코드로 정의한다.
LLM 데이터 파이프라인은 DAG로 구조화할 수 있다. 예를 들어, [시작] → [Common Crawl 인덱스 다운로드] → [분산 크롤링 및 추출] → [휴리스틱 필터링] → [중복 제거] → [품질 점수화] → [최종 혼합] → [종료]라는 개념적 흐름으로 표현할 수 있다.
Airflow는 MLOps 환경에서 특히 유용한 기능들을 제공한다. 데이터 청크의 병렬 처리를 가능하게 하는 동적 태스크 매핑, 지수 백오프를 사용하는 자동 재시도, 장애 발생 시 경고, Git과 같은 버전 관리 시스템과의 통합 기능이 그 예이다. 이러한 기능은 복잡한 LLM 데이터 파이프라인을 안정적으로 운영하고 관리하는 데 중요한 역할을 한다.
페타바이트 규모의 데이터를 처리하기 위해서는 작업을 클러스터에 분산시켜야 하며, Apache Spark는 이를 위한 사실상의 표준이다.
Spark는 단일 머신으로는 처리할 수 없는 대용량 데이터를 다루기 위해 반드시 필요한 분산 처리 엔진이다. 대표적인 사례로 오픈소스 C4-on-Spark 구현이 있다.
C4-on-Spark 파이프라인은 Common Crawl WET 경로를 읽고 다운로드 및 초기 처리 작업을 Spark 워커에 분산시킨다. 이후 휴리스틱 필터링과 중복 제거 로직이 분산 데이터프레임에 대해 병렬로 작동하며, 이러한 연산은 Spark의 map, filter, reduceByKey와 같은 변환 연산으로 표현된다. 이를 통해 대규모 데이터 정제와 변환이 효율적으로 수행된다.
의존성 관리는 conda-pack과 같은 도구를 통해 이루어진다. Python 환경을 패키징한 뒤 Spark 클러스터로 전송하여 모든 워커가 nltk와 같은 필수 라이브러리를 갖추도록 보장한다. 이는 대규모 분산 환경에서 일관된 실행 환경을 유지하는 핵심 절차이다.
Airflow와 Spark의 통합은 SparkSubmitOperator를 통해 이루어진다. Airflow는 상위 수준의 스케줄러 역할을 하며, 실제 데이터 처리의 무거운 연산은 Spark 잡이 수행하도록 트리거한다. 이러한 구조는 워크플로우 관리와 대규모 데이터 처리를 분리하여 안정성과 확장성을 동시에 확보한다.
LLM 데이터 파이프라인은 일회성 스크립트가 아니라 지속적으로 관리되고 개선되어야 하는 프로덕션 시스템이다. 따라서 MLOps 모범 사례를 적용하는 것이 중요하다.
버전 관리는 모든 파이프라인 코드, 즉 DAG, Spark Job, 구성 파일을 Git과 같은 버전 관리 시스템에 저장하여 이루어진다. 이렇게 하면 변경 내역을 추적하고 협업 환경에서 충돌을 최소화할 수 있다.
CI/CD는 데이터 처리 코드와 Airflow DAG의 변경 사항에 대한 테스트, 린팅, 배포를 자동화하는 파이프라인을 설정하는 것을 의미한다. 이를 통해 안정성을 보장하고 수동 오류를 줄일 수 있다.
코드형 인프라(IaC)는 Spark 클러스터와 Airflow 환경 같은 기본 컴퓨팅 인프라를 Terraform이나 CloudFormation과 같은 도구를 사용하여 코드로 정의하고 관리하는 방식이다. 이 방식은 재현성을 보장하고 인프라 운영을 일관되게 한다.
데이터 및 모델 버전 관리는 처리된 데이터셋과 파이프라인 내에서 사용되는 모든 모델을 명확한 명명 규칙으로 관리하는 것을 의미한다. 이를 위해 객체 저장소나 MLflow와 같은 전용 도구를 활용하면 된다. 이 과정을 통해 데이터와 모델의 변경 이력을 추적할 수 있으며, 재현 가능한 연구와 안정적인 운영을 동시에 달성할 수 있다.
LLM 데이터 준비의 복잡성, 규모, 그리고 신뢰성 요구는 이 분야를 단순한 스크립팅에서 공식적인 데이터 엔지니어링 및 MLOps의 영역으로 이끌었다. 페타바이트, 수조 개의 토큰 규모는 단일 머신 처리로는 불가능하기 때문에 Spark와 같은 분산 시스템이 필수적이다.
다단계 종속 워크플로우는 단순한 셸 스크립트로는 관리할 수 없으며, Airflow와 같은 정교한 오케스트레이터가 필요하다. 파이프라인 실패 시 발생하는 막대한 비용, 즉 낭비된 컴퓨팅과 손상된 데이터는 CI/CD, 모니터링, 자동 재시도와 같은 프로덕션 수준의 관행을 요구한다.
커뮤니티가 Airflow와 Spark 스택, 그리고 이러한 MLOps 관행으로 수렴하고 있다는 사실은 임시적인 연구 과제가 견고한 엔지니어링 프로세스로 전환되었음을 보여주며, 표준 아키텍처 패턴이 등장했음을 시사한다.
오케스트레이션 도구인 Airflow는 단순한 스케줄러가 아니라 전체 데이터 생명주기를 제어, 문서화, 거버넌스하는 중심 허브이다.
Airflow DAG는 전체 데이터 파이프라인의 실행 가능한 문서로서 모든 단계와 종속성을 코드 형태로 보여준다. DAG는 Git에 저장되므로 파이프라인 로직의 모든 변경 사항이 버전 관리되고 감사 가능하다.
Airflow의 로깅과 UI는 모든 데이터 처리 실행의 상태와 이력을 중앙에서 관찰할 수 있는 기능을 제공한다. 따라서 “이 데이터셋을 생성한 클리닝 코드의 버전은 무엇인가?”, “어젯밤 파이프라인이 왜 실패했는가?”, “지난 6개월 동안 데이터 처리 로직은 어떻게 발전했는가?”와 같은 중요한 거버넌스 질문에 답할 수 있다. 이는 파이프라인을 블랙박스에서 투명하고 감사 가능한 시스템으로 변환하는 역할을 한다.
마지막 장은 LLM 데이터셋 생성의 중요한 비기술적 측면을 다루는 부분이다. 법규 준수, 편향에 대한 윤리적 책임, 그리고 책임감 있는 사용을 보장하기 위한 철저한 문서화의 필요성을 중심으로 논의한다.
LLM 훈련은 방대한 데이터를 복제하는 과정을 포함하며, 상당 부분은 저작권의 보호를 받는다. 이는 저작권 침해에 대한 심각한 우려를 낳는다.
미국 저작권법의 공정 이용 방어는 사용 목적과 성격, 저작물의 성격, 사용된 부분의 양과 중요성, 잠재적 시장 영향이라는 네 가지 요소를 고려한다.
최근 법원 판결은 판사들 사이의 긴장과 시각 차이를 보여준다. 일부는 훈련을 변형적 사용으로 보고 공정 이용에 해당할 가능성이 높다고 판단하지만, 다른 일부는 시장 피해와 가치 희석을 우려한다. 특히 Books3와 같이 불법 복제된 자료의 합법성은 여전히 논쟁적이다.
따라서 공개 라이선스 데이터, 정부 문서, 비상업적 연구 데이터와 같이 합법성이 더 명확한 소스를 우선적으로 사용하는 위험 회피적 접근이 권장된다. 모든 데이터의 출처와 라이선스는 꼼꼼하게 문서화해야 한다.
LLM은 훈련 데이터에 존재하는 사회적 편향을 반영하고 증폭시킬 수 있다.
이를 완화하기 위해 전처리 단계에서 반사실적 데이터 증강 기법을 활용하여 고정관념을 체계적으로 깨뜨릴 수 있다.
또한 데이터 소스의 다양성을 확보하고 소외된 집단의 콘텐츠를 적극 포함하는 것이 중요하다.
후처리나 훈련 단계에서 강화 학습을 통해 편향된 출력을 처벌하는 방법 등도 추가적으로 적용할 수 있다.
기계 학습 커뮤니티는 데이터셋을 문서화하는 표준화된 프로세스가 부족하다.
Gebru 등이 제안한 데이터시트는 데이터셋의 동기, 구성, 수집 과정, 전처리, 용도 및 한계, 유지보수 계획을 포함하여 투명성을 보장하는 도구이다.
데이터시트는 데이터 거버넌스 프레임워크와 연결되어야 하며, 데이터 소유자와 스튜어드의 역할 정의, 품질 표준, 접근 제어, 보안 프로토콜을 포함해야 한다. 이는 필터링과 소싱 결정이 가져오는 법적, 윤리적 결과를 관리하는 핵심 장치이다. The Pile에 Books3를 포함하거나 C4에 엄격한 영어 필터를 적용한 사례는 기술적 선택이 법적 및 사회적 결과를 초래한다는 점을 잘 보여준다.
데이터셋이 공개되면 제작자가 예측하지 못한 방식으로 사용된다. 따라서 데이터시트는 제작자가 의도, 가정, 알려진 한계를 하류 사용자와 대중에게 소통하기 위한 중요한 메커니즘이다.
데이터시트가 없으면 데이터셋은 블랙박스이며 사용자는 해당 데이터셋의 적합성과 위험을 알 수 없다. 데이터시트는 데이터에 대한 필수적인 API 문서로서 책임감 있는 혁신을 가능하게 하고, 모델이 사회적 피해를 야기했을 때 책임 근거를 제공한다. 이는 “쓰레기가 들어가면 쓰레기가 나온다”라는 문제를 사회적 규모에서 완화하는 핵심 도구이다.