글결 프로젝트: 한국어 블로그 데이터셋 구축의 기록

태그 글결 분류 일반

2024년 9월 1일부터 개발되어 2025년 2월에 첫 크롤링해 6월 6일까지 업데이트된 글결 프로젝트 1차, 그 과정을 기록했습니다.

2025년 6월 15일 오후 9:35

글결 프로젝트 로고

출발

LLM의 출발과 끝은 데이터라 해도 과언이 아니다. LLM 성능의 발전에는 데이터셋의 발전이 함께 했고, 대부분의 언어 모델이 영어를 잘하는 이유 또한 방대한 영어 데이터셋 덕분이다. 하지만 2025년 현재에도 오픈 소스 한국어 LLM은 부족한 수준이다. Qwen3나 HyperCLOVA X Seed 등의 모델이 등장해 상황이 나아졌지만, 여전히 겨우 GPT-3.5를 따라잡는 수준이라고 생각한다. 이 문제를 해결하기 위한 오픈 소스 커뮤니티의 여러 시도가 있었지만, 공개된 한국어 데이터셋 부족이 발목을 잡았다.

모두의말뭉치와 AI Hub의 한국어 데이터셋을 생각하는 이들 또한 있을 것이다. 이들 데이터는 물론 좋지만, 규모가 문제다. 수십 GB 정도의 데이터는 요즘의 LLM들에게 턱없이 부족하다. 영어는 이미 GPT-2조차 40GB의 데이터를 사용했고, Llama 3은 150억 가량의 토큰으로 학습되었다. 공개된 한국어 데이터셋으로는 이 규모를 따라가기 어렵고, 품질까지 좋은 데이터는 더욱 부족하다.

HyperCLOVA는 562B 중 48.7%인 273.6B의 블로그 데이터로 학습되었다[1]. 네이버는 자사의 블로그 데이터를 약관에 따라 학습에 사용했지만, 외부에서는 그 방대한 한국어 데이터의 존재에도 불구하고 이를 활용할 수 없었다. 한국어 데이터셋을 위한 여러 시도가 있었지만, 그 규모는 제한적이었다.

이러한 상황에서 나는 블로그 데이터를 수집하면 한국어 데이터셋의 규모를 늘릴 수 있겠다고 생각했다. 블로그만큼 다양한 주제로 많은 사람들의 생각을 써낸 곳은 많지 않다. 따라서 나는 이러한 데이터셋을 직접 구축하고자 했다. 2024년 9월 1일, 글결 프로젝트는 이렇게 시작되었다.

목표와 계획

글결 프로젝트의 목표는 한국어 블로그 데이터를 수집하고, 이를 정제하여 공개하는 것이었다. 웹 데이터는 이미 대부분 수집되어 있지만, 한국어 블로그는 크롤링에 친화적이지 않아 많이 수집되지 않았다. 글결은 가장 널리 쓰이는 한국어 블로그 플랫폼인 네이버 블로그와 티스토리를 대상으로 글을 수집하고, 이를 정제하여 공개하는 것을 목표로 했다.

저작권 문제도 고려해야 했다. 블로그 글은 당연히 작성자의 저작물이다. 글을 수집하는 것 자체는 문제가 없지만, 목표를 달성하려면 이를 공개해야 했다. 이는 저작권 침해의 소지가 있었다. 이 문제를 해결하기 위해, 블로그 글들 중 CCL, 그 중에서도 공개에 문제가 없다고 판단한 BY, BY-SA, BY-NC, BY-NC-SA 라이선스가 적용된 글만을 공개하기로 했다. ND 조항이 있는 글이나, CCL이 없는 글은 메타데이터만 공개하기로 했다.

방대한 규모의 블로그를 크롤링하는 시도는 처음이었다. 그 규모 때문에 나는 아키텍처부터 신중하게 설계해야 했다. 그럼에도 부족함이 있었고, 시즌 1은 그 한계로 중단되었다. 다음은 간단한 시즌 1의 아키텍처이다. 정확한 구조는 코드를 참고해도 좋다.

• 크롤러: Kotlin, GCP Pub/Sub
• DB: Cloudflare R2 → MongoDB
• 정제/공개: Python

크롤러는 크게 두 개의 작업을 처리한다. 글을 수집하는 것과, 수집할 글을 탐색하는 것이다. 두 작업을 스케줄링하기 위해 메시징 시스템인 GCP Pub/Sub를 사용했다. Kafka를 고려해 보았으나, 따로 구축하기보다 GCP Pub/Sub를 사용하는 것이 더 간편하고 안정적이며, 가격에도 큰 부담이 없을 것이라고 판단했다.

크롤러는 GCP Pub/Sub를 통해 수집할 글의 URL을 받아와 크롤링하고, 이를 저장한다. 처음에는 S3 호환 스토리지인 Cloudflare R2에 저장했지만, 비용과 속도, 관리 등의 문제로 인해 MongoDB로 변경했다. 종료 시점에서 500GB+의 데이터를 MongoDB에 저장했다. 이러한 자원을 감당할 클라우드 서비스를 쓰기에는 비용이 곤란했기 때문에, MongoDB는 데스크탑에서 구동했다. Cloudflare D1도 고려했으나, 비용이 훨씬 비쌌다. 다른 SQL 데이터베이스를 사용해도 큰 문제는 없었겠지만, 향후의 확장성을 고려해 MongoDB를 선택했다. 결과적으로는 나쁘지 않은 선택이었고, BSON으로 덤프를 떠 후처리할 수 있었기 때문에 정제 작업도 수월했다.

공개할 메타데이터와 본문 또한 계획했다. 제목과 URL, 작성자, 작성일, 읽은 시간, 본문, 라이선스 등을 수집/저장했다. 본문은 text only, 마크다운(이미지 포함/미포함), raw elements 4가지로 제공했다^[*1]. 이 중 ND 조항이 있거나 CCL이 없는 글은 메타데이터만 공개했다. 이 작업은 Python으로 작성했으며, MongoDB에서 데이터를 읽어와 정제하고, JSON으로 저장했다. 이후 Hugging Face에 공개했다.

수집할 글의 탐색은 여러 방법을 고려했으나, 각 블로그의 특성을 고려해 사용된 방법은 다음과 같다.

• 네이버 블로그: 글에 공감한 사람과, 작성자 블로그의 글들을 탐색한다.
• 티스토리: 글에 댓글을 단 사람과, 작성자 블로그의 글들을 탐색한다.

검색 API를 사용하지 않은 이유는 검색어 선정의 문제가 있었기 때문이다. 웹 크롤러들은 흔히 링크된 글을 계속 탐색하는 방식으로 글을 수집한다. 하지만 모든 블로그를 탐색하기에는 부족하기 때문에 추가적인 방법을 적용한 것이다. 최초로 수집할 여러 글과 작성자를 선택했고, 이를 기반으로 점점 많은 글들을 수집해 나갔다.

시작

먼저 마크다운 라이브러리를 제작했다. 그 결과물이 devngho/kmarkdown이다. Kotlin으로 작성된 DSL 기반 마크다운 빌더로, 파서에서 마크다운을 생성하는 데 사용했다.

이후 본격적인 크롤러 작성을 시작했다. 가장 중요한 부분인 파서는 각 블로그의 HTML 구조를 분석하고, 이를 기반으로 작성했다. HTML 파싱에는 skrape-it과 jsoup가 사용되었고, o1-preview의 큰 도움을 받아 초안을 작성했다. 두 블로그 각각의 파서가 글을 BlogComponents로 변환하고, 이를 마크다운과 텍스트 등으로 변환했다. 네이버 블로그는 스마트에디터 ONE에만 대응하도록 했다. 두 블로그 모두 fallback으로 flexmark를 사용해 HTML을 마크다운으로 변환했다.

이 외에도 사용된 것을 말하자면, Koin을 사용해 의존성 주입을 적용했고, Ktor를 사용해 HTTP 요청을 처리했다. GCP Pub/Sub는 공식 라이브러리를 사용했다. MongoDB는 공식 Kotlin 라이브러리를 사용했다. crawler-commons를 통해 robots.txt를 준수했다. 이 외에도 여러 라이브러리를 사용했지만, 크롤러의 핵심은 위와 같다.

크롤러를 운용할 서버는 내 데스크탑과 개인적으로 사용하던 Vultr의 한국 리전 서버, 총 2대였다. GCP Pub/Sub를 사용해 두 서버에 작업이 분산되도록 했다. 한동안 서버 한 대를 추가한 적이 있었으나, 어느 정도 후 크롤링이 안정되자 서버를 줄였다.

앞서 말했듯 R2에서 수백만 건의 글을 수집하고 MongoDB로 이전한 적이 있다. 작업은 간단히 R2의 데이터를 모두 나열한 후 저장해 MongoDB로 옮기는 방식으로 진행했다. 수 시간이 소요되었고, 이후에는 바로 MongoDB에 저장하도록 변경했다.

정제 작업은 초반에는 클라이언트로 직접 MongoDB에 접근해 데이터를 읽어왔으나, 점점 데이터가 많아지자 속도가 저하되었다. 이후에는 mongodump를 사용해 BSON으로 덤프를 떠서 정제 작업을 진행했다. 정제 작업은 Python으로 작성되었고, MongoDB에서 데이터를 읽어와 분류와 배포를 진행했다. 이후 멀티스레딩으로 전환하고, 덤프를 gzip로 압축하는 등 여러 개선 작업을 거쳤다. 이 정제 작업은 마지막 배포 때에도 덤프와 정제 합쳐 약 12시간이 소요되었다.

문제들

먼저 방대한 규모를 감당해내기 역부족이었다. 대상 서버에 부담을 주지 않고자 크롤링 속도를 조절했고, 다행히 IP가 차단되는 등의 불상사는 없었다. 하지만 2대의 서버로도 초당 20건이 한계였다. 다른 글을 탐색하거나 크롤러가 중단되는 등의 상황을 고려하면 속도는 더욱 떨어졌다.

데이터베이스 구조 설계 또한 미흡했다. 실제에 비해 4배가 넘는 크기의 데이터를 저장해야 했고, HTML은 저장하지 않아 다시 파싱할 수도 없었다. 이는 여러 모로 부담이 되었고, 데이터 품질에도 영향을 미쳤다.

정제 또한 빠르다곤 할 수 없었다. 덤프 도중에는 데이터베이스에 큰 부하를 주고, 작업 도중 사용하는 저장 공간 또한 커졌다. 정제 작업은 멀티스레딩으로 개선했지만, 여전히 속도는 느렸다. 덤프와 정제 작업을 합쳐 약 12시간이 소요되었다.

이 외에도 메모리 누수가 있는 것으로 추정되고, 요청이 길어질 때 다른 요청이 같이 지연되는 등 여러 문제가 있었다. 이러한 문제들은 크롤러가 중단되는 원인이 되었고, 결국 이런 문제들을 점진적으로 수정할 수 없는 상황에 도달하며 시즌 1은 종료되었다.

종료

시즌 1은 2025년 2월 6일에 종료되었다. 약 4개월간의 크롤링으로 66,637,241건의 글을 수집했고 그 중 1,750,768건의 글이 본문까지 공개되었다. 글결 허깅페이스 페이지에서 확인할 수 있다. 이 데이터는 내가 아는 바 중 가장 방대한 한국어 블로그 데이터셋이다.

향후 LLM을 활용해 보다 학습에 용이하도록 가공하고, 여러 형식으로 바꿀 계획이 있었으나 수집하지 못한 글들이 많아 보류했다.

시즌 2

올해 안에는, 구체적으로 7~8월에는 시즌 2를 준비하고 시작할 것이다. 구체적이지는 않지만, 간략한 변경 사항으로는 다음을 계획하고 있다.

• HTML을 저장하고, 공개 시점에 파싱한다. 이를 통해 파서 변경에 유연하게 대응할 수 있다.
• 서버 확충으로 속도를 개선한다.
• 후처리 작업을 개선한다.
• 도커/쿠버네티스를 도입하고, CI/CD를 도입해 배포를 용이하게 한다.
• 티스토리 글 수집을 개선한다.
  • 티스토리 글은 댓글을 통해 탐색하는데, 검색어 기반으로 이를 보완한다.
  • 티스토리 스킨에 따라 다른 목록 페이지를 처리한다.

마치며

글결 프로젝트에 참가하거나, 서버 지원 등의 도움을 주려고 하시거나, 그냥 조금의 궁금함이라도 있다면 이곳이나 [email protected]로 (제발!) 주저하지 말고 연락해 주시길 바란다. 나 또한 학생이고, 팀 프로젝트는 처음인 만큼 누군가와 함께 작업하고 싶다. 누구라도 환영한다.

글결은 나에게 큰 도전이었다. 처음으로 방대한 규모의 데이터를 수집하고, 이를 정제하여 공개하는 작업을 했다. 이 과정에서 많은 것을 배웠고, 여러 문제를 경험했다. 시즌 1은 종료되었지만, 시즌 2를 통해 더 나은 데이터셋을 구축할 것이다.

이 글이 LLM을 개발하고 데이터셋을 제작하려는 누군가에게 도움이 되었기를 바란다.

@misc{devngho202520250615geulgyeolreport1,
  author       = {Yu, Dongho},
  title        = {글결 프로젝트: 한국어 블로그 데이터셋 구축의 기록},
  howpublished = {\url{https://ngho.dev/posts/20250615-geulgyeol-report-1}},
  year         = {2025},
  month        = {jun},
  note         = {Accessed: 2025-06-17}
}

@misc{devngho202520250615geulgyeolreport1,
  author       = {Yu, Dongho},
  title        = {글결 프로젝트: 한국어 블로그 데이터셋 구축의 기록},
  howpublished = {\url{https://ngho.dev/posts/20250615-geulgyeol-report-1}},
  year         = {2025},
  month        = {jun},
  note         = {Accessed: 2025-06-17}
}