Executive Summary
2026년 2월 말, 페블러스 블로그는 사흘 동안 발행 기사를 79개에서 128개로 끌어올렸습니다. 당시 결산은 이 폭발을 "3일 스프린트"라고 불렀습니다. 그로부터 다섯 달이 지난 지금, 발행 기사는 883개입니다. 이 글은 3월부터 7월까지, 스프린트가 만든 숫자가 어떻게 지속 진화가 만든 숫자로 바뀌었는지 기록합니다.
다섯 달의 발행량은 3월 125편, 4월 160편, 5월 62편, 6월 234편, 7월 174편입니다. 5월의 숨 고르기와 6월의 폭발이 한 곡선 안에 함께 있습니다. 숫자만 보면 스프린트의 재현처럼 보이지만, 실제로 바뀐 것은 발행 속도가 아니라 발행을 떠받치는 구조였습니다. 단일 파일에 몰리던 병목이 샤딩으로 흩어졌고, 사람이 하던 검수가 파이프라인의 단계가 됐습니다.
콘텐츠와 코드가 같은 기간에 함께 자랐습니다. 기사가 883개로 늘어나는 동안 Claude Skills는 9개에서 43개로, 주제 허브는 16개로 늘었습니다. 아래 네 숫자가 다섯 달의 골격입니다.
128 → 883
발행 기사
2월 결산 대비 6.9배. 다섯 달 순증 755편
45 → 435
이중언어 쌍
KO+EN 완결 쌍 9.7배. EN 백필과 신규 병렬 작성
9 → 43
Claude Skills
품질·리서치·발행 스킬 4.8배. 코드도 함께 성장
209 → 16
고립 기사(orphan)
관련글 없는 글 92% 구제. 빌드타임 자동 계산
숫자로 본 다섯 달
2월 결산은 3월 2일 기준의 스냅숏이었습니다. 그때와 지금(7월 18일)을 나란히 놓으면 다섯 달의 궤적이 한 표에 담깁니다. 발행 기사는 6.9배, 이중언어 쌍은 9.7배가 됐고, 그 사이 스킬과 허브라는 새로운 축이 생겼습니다.
| 지표 | 2월 결산 (3월 2일) | 현재 (7월 18일) | 배수 |
|---|---|---|---|
| 발행 기사 | 128 | 883 | 6.9배 |
| 이중언어 쌍(KO+EN) | 45 | 435 | 9.7배 |
| Claude Skills | 9 | 43 | 4.8배 |
| Agents | 초기 | 16 | 신설 |
| 주제 허브 | 3 | 16 | 5.3배 |
| GitHub Actions | 4 | 6 | — |
| changelog 이력 | — | 574줄 | — |
1.1월별 발행 추이
다섯 달의 발행량은 고르지 않았습니다. 3월과 4월은 스프린트의 관성이 이어졌고, 5월은 62편으로 확연히 낮아졌습니다. 이 숨 고르기 뒤에 6월 234편이라는 최대 폭발이 왔습니다. 5월에 멈춘 것은 발행이지 작업이 아니었습니다. 그달 대부분의 손이 아키텍처 정비와 품질 파이프라인 구축으로 갔고, 그 투자가 6월의 처리량으로 돌아왔습니다.
1.2카테고리 분포
883개 기사의 무게중심은 tech입니다. 데이터 품질과 Physical AI를 다루는 tech가 530편으로 전체의 60%를 차지하고, 기업 분석 중심의 business가 175편으로 뒤를 잇습니다. story 101편과 art 77편은 DataClinic 진단 스토리와 데이터 아트가 꾸준히 채웠습니다.
| 카테고리 | 발행 수 | 비중 | 대표 내용 |
|---|---|---|---|
| tech | 530 | 60% | 데이터 품질, Physical AI, AI-Ready Data |
| business | 175 | 20% | 기업 분석, BizReport 시리즈 |
| story | 101 | 11% | DataClinic 진단 스토리 |
| art | 77 | 9% | 데이터 아트, 코드 페인팅 |
스프린트에서 시스템으로
2월의 사흘은 한 사람이 여러 창을 띄워 놓고 배치를 돌리는 방식이었습니다. 47개 포스팅을 8개 배치로 나눠 이중언어로 바꾸고, 공통 모듈을 뽑아내고, 스킬 세 개를 새로 만들었습니다. 강렬했지만 그 속도는 사람의 집중력에 묶여 있었습니다. 같은 방식으로 883개를 만들 수는 없습니다. 다섯 달 동안 바뀐 핵심은 발행을 사람의 스프린트에서 시스템의 일상으로 옮긴 것입니다.
전환의 신호는 5월에 가장 또렷했습니다. 발행이 62편으로 내려간 그달, 대부분의 작업은 화면에 보이는 글이 아니라 글을 떠받치는 구조로 갔습니다. articles.json이라는 단일 파일에 여러 작업이 동시에 손대며 생기던 충돌을 샤딩으로 끊어 냈고, 사람이 눈으로 하던 AI 문체 검수와 SEO 점검을 파이프라인의 게이트로 만들었습니다. 6월 234편은 그 정비가 없었다면 나올 수 없는 숫자였습니다.
2월 · 스프린트
- 사람이 배치를 직접 돌림
- articles.json 단일 파일에 동시 편집
- 품질 검수는 발행 뒤 사람 눈으로
- 속도가 집중력에 묶임
7월 · 시스템
- 엔진이 발견·작성·검수·발행을 이어 감
- 사이드카(articles.d/)로 충돌 원천 차단
- 문체·SEO 검수가 발행 전 게이트
- 처리량이 구조의 함수로
이 전환이 어떻게 작동하는지는 한 편의 글이 만들어지는 과정에서 가장 잘 보입니다. 에이전트 일곱이 블로그 한 편을 짓는 이야기는 데이터 수집, 시각 분석, 스토리 기획, 작성, 품질 검증, 번역, 발행을 각기 다른 에이전트가 릴레이로 넘기는 과정을 담았습니다. 한 사람의 손이 하던 일을 역할별로 나누자, 같은 품질을 유지하면서 여러 편을 동시에 진행할 수 있게 됐습니다.
스프린트는 폭발의 크기로 기억되고 시스템은 지속의 길이로 기억됩니다. 다섯 달의 결산이 2월과 다른 지점은 여기입니다. 883이라는 숫자보다 중요한 것은, 883번째 글이 128번째 글과 거의 같은 손을 필요로 하지 않았다는 사실입니다.
아키텍처의 진화
발행량이 늘자 2월엔 보이지 않던 구조적 병목이 드러났습니다. 다섯 달 동안 네 가지 아키텍처 변화가 이 병목을 하나씩 풀었습니다. 샤딩은 동시 편집 충돌을, 진본과 사본의 분리는 코드와 콘텐츠의 뒤섞임을, orphan 구제는 관련글 단절을, 자동 발행 엔진은 사람 손의 한계를 겨냥했습니다.
3.1샤딩 — 단일 핫스팟을 흩다
모든 기사의 메타데이터가 articles.json 한 파일에 모여 있었습니다. 여러 작업이 동시에 새 글을 등록하면 같은 파일의 같은 줄 근처를 고쳐 충돌이 났고, 한 번은 병합을 잘못해 82개 항목이 사라지는 사고까지 있었습니다. 해법은 글 하나당 사이드카 파일 하나였습니다. 새 글은 articles.d/<id>.json에 등록하고, CI가 이 조각들을 모아 articles.json을 생성합니다. 서로 다른 파일은 충돌하지 않으므로, 동시 작업의 병목이 원천에서 사라졌습니다.
3.2진본과 사본 — 코드와 콘텐츠를 갈라 두다
블로그를 굴리는 자산은 성격이 다릅니다. 글과 이미지 같은 콘텐츠는 라이브 사이트에서 바로 손대는 것이 자연스럽지만, 스킬·에이전트·빌드 도구 같은 코드는 한 곳에서 관리해야 어긋나지 않습니다. 그래서 코드 자산의 진본은 별도 레포에 두고, 라이브 사이트는 이를 자동으로 미러링하도록 나눴습니다. 진본에 변경이 들어가면 사본으로 동기화 PR이 자동 생성되고, 사람이 검토해 병합합니다. 콘텐츠는 사본에서, 코드는 진본에서. 이 분리로 두 종류의 변경이 서로를 덮어쓰지 않게 됐습니다.
3.3관련글 구제 — 고립된 209편을 16편으로
글이 883개가 되자, 아무 글과도 연결되지 않는 고립 기사가 209편이나 쌓였습니다. 독자가 한 글을 읽고 다음 글로 넘어갈 길이 없다는 뜻이고, 검색 엔진에도 좋지 않은 신호입니다. 태그 유사도로 관련글을 계산하되, 어떤 글도 완전히 고립되지 않도록 최소 한 번은 다른 글의 관련글 목록에 반드시 포함되게 하는 역보장 규칙을 더했습니다. 이 계산을 빌드타임에 돌려, 고립 기사를 209편에서 16편으로 줄였습니다. 92%가 다시 연결됐습니다.
| 변화 | 겨눈 병목 | 결과 |
|---|---|---|
| 샤딩 (articles.d/) | 단일 파일 동시 편집 충돌 | 충돌 원천 차단 |
| 진본/사본 분리 | 코드·콘텐츠 혼재 | 자동 미러 + 검토 병합 |
| 관련글 구제 | 고립 기사 209편 | 16편으로 92% 감소 |
| 자동 발행 엔진 | 사람 손의 처리량 한계 | 무인 파이프라인 + 이력 기록 |
3.4자동 발행 엔진 — 사람 손 밖의 처리량
마지막 조각은 발행 자체의 자동화였습니다. 무엇을 쓸지 발견하고, 초안을 작성하고, 품질 게이트를 통과시키고, 발행까지 잇는 파이프라인이 사람 개입 없이 한 바퀴를 돌 수 있게 됐습니다. 각 단계는 실행 이력을 남겨, 어떤 글이 어떤 경로로 나왔는지 추적할 수 있습니다. 이 엔진이 6월의 처리량을 뒷받침한 실질적 근육이었습니다.
네 변화에는 공통점이 있습니다. 모두 사람이 매번 신경 써야 하던 일을 구조가 대신 보장하도록 옮긴 것입니다. 충돌을 조심하는 대신 충돌이 불가능한 파일 구조를, 관련글을 챙기는 대신 계산이 보장하는 연결을 택했습니다. 이것이 다섯 달 아키텍처 진화의 문법입니다.
허브 생태계
883개 기사는 그냥 목록으로 두면 흩어진 점에 불과합니다. 다섯 달 동안 이 점들을 주제로 묶는 허브가 3개에서 16개로 늘었습니다. 허브는 하나의 주제 키워드 아래 관련 기사를 모아 보여 주는 이중언어 컬렉션 페이지입니다. 독자에게는 한 주제를 깊이 파고들 입구이고, 검색 엔진에는 주제의 권위를 신호하는 앵커입니다.
예를 들어 Physical AI Datasets 허브는 로봇·자율주행이 학습하는 물리 세계 데이터를 다룬 글들을 한곳에 모읍니다. 흩어져 있던 개별 기사가 이 허브를 중심으로 다시 배치되면서, 독자가 한 편을 읽고 같은 주제의 다른 편으로 자연스럽게 넘어갈 수 있게 됐습니다.
4.1양방향 연결 — 글과 허브가 서로를 가리키다
허브의 힘은 방향에 있습니다. 초기 허브는 글을 모으기만 했습니다. 허브에서 글로 가는 길은 있었지만, 글에서 자신이 속한 허브로 돌아오는 길은 없었습니다. 이번 다섯 달에 역링크 배지를 더해, 각 기사가 자신이 속한 허브를 가리키게 했습니다. 글과 허브가 서로를 가리키는 양방향 구조가 되자, 어느 지점에서 들어와도 주제 전체를 탐색할 수 있는 그물이 만들어졌습니다.
허브 16개와 관련글 구제는 같은 문제의 두 얼굴입니다. 둘 다 "글이 많아질수록 서로 멀어진다"는 규모의 부작용을 겨냥합니다. 관련글이 개별 기사 사이의 미세한 실이라면, 허브는 주제 단위로 묶는 굵은 밧줄입니다. 이 두 겹이 겹치면서 883개 기사가 흩어진 목록이 아니라 탐색 가능한 지형이 됐습니다.
품질을 1급 시민으로
발행량이 늘 때 가장 먼저 흔들리는 것은 품질입니다. 다섯 달의 결정 중 하나는 품질 검사를 발행의 부록이 아니라 발행의 조건으로 만든 것입니다. 글이 나가기 전에 반드시 통과해야 하는 게이트가 생겼고, 그 게이트를 스킬이 담당합니다.
5.1AI 문체 검수와 SEO 게이트
자동으로 쓴 글에는 특유의 티가 납니다. 줄표로 같은 말을 두 번 하고, 문장을 명사형으로만 닫고, 상투적인 비유를 반복하는 패턴입니다. ko-prose-humanizer 스킬은 이런 11가지 문체 신호를 진단하고 점수화해, 사실과 수치는 건드리지 않은 채 산문의 질감만 사람 글로 되돌립니다. 여기에 SEO 4계층을 자동 점검하는 seo-check가 더해져, 제목·설명·정형 데이터·헤딩 구조가 어긋난 글은 발행 전에 걸러집니다.
5.2참고문헌과 이미지 보강
학술·저널리즘 톤의 글에는 출처가 신뢰의 근거입니다. bibliography 스킬은 참고문헌을 표준 형식으로 관리하고, 본문에 참고문헌 섹션과 인용 다운로드 버튼, 검색 엔진용 메타 태그까지 자동으로 렌더링합니다. image-reinforce는 글의 맥락에 맞는 이미지를 찾아 검증하고 삽입해, 글이 텍스트만으로 비어 보이지 않게 채웁니다. 품질이 사람의 성실함에 기대던 것에서 파이프라인이 보장하는 것으로 옮겨 갔습니다.
5.3로컬 LLM 서빙 실험
품질 실험은 클라우드 모델에만 머물지 않았습니다. 사내 그린하우스 환경의 Ollama에 라마·젬마·큐원 같은 오픈 모델을 올려, 로컬에서 직접 서빙하며 실측하는 실험을 진행했습니다. 어떤 작업은 로컬 모델로도 충분하고 어떤 작업은 그렇지 않은지, 비용과 품질의 경계를 데이터로 확인하는 과정입니다. 발행 자동화의 다음 단계를 어디에 둘지 정하는 근거가 됩니다.
품질을 발행의 게이트로 세운 결정에는 페블러스가 데이터에 대해 해 온 주장이 그대로 겹칩니다. 데이터의 계통과 품질을 사후 점검이 아니라 파이프라인의 1급 시민으로 다루자는 것, 그것이 DataClinic이 데이터에 대고 해 온 이야기입니다. 다섯 달 동안 그 원칙을 블로그 운영 자신에게 적용한 셈입니다.
하반기 전망
상반기가 발행을 시스템으로 옮긴 시간이었다면, 하반기의 과제는 그 시스템의 품질과 폭을 넓히는 일입니다. 다섯 달 동안 세운 골격 위에 세 방향의 확장이 예정돼 있습니다.
- 다국어 확장. 상반기에 EN 백필과 일본어(ja) 실험을 시작했습니다. 이중언어 435쌍을 넘어, 언어별 검색 의도에 맞춘 다국어 발행을 파이프라인의 기본값으로 만드는 것이 다음 목표입니다.
- 로컬 서빙의 실전화. 그린하우스 Ollama 실험에서 확인한 경계를 실제 발행 경로에 적용합니다. 어떤 단계를 로컬 모델로 옮겨 비용과 지연을 줄일지, 실측 근거로 정합니다.
- 편집 편의의 회수. 발행 HTML은 여전히 라이브의 기준이지만, 사람이 본문만 고치기엔 무겁습니다. 발행 글마다 동반하는 HTML-중립 원고를 다듬어, 출간 후 수정을 더 쉽게 만드는 작업이 이어집니다.
2월 결산은 "3일이 만든 128개"의 기록이었습니다. 이 글은 "다섯 달이 만든 883개"의 기록입니다. 두 결산 사이에서 바뀐 것은 숫자의 크기가 아니라 숫자를 만드는 방식이었습니다. 스프린트가 한 번의 폭발이었다면, 지난 다섯 달은 그 폭발을 매일 반복 가능한 일상으로 바꾸는 과정이었습니다. 하반기 결산이 883을 얼마로 갱신하든, 그때 더 중요한 질문은 여전히 같을 것입니다. 그 숫자를 만든 손이 얼마나 가벼웠는가.
참고문헌
이 글은 페블러스 블로그 결산 시리즈의 이어지는 편입니다. 앞선 결산과 이번 다섯 달의 변화를 보여 주는 관련 글을 함께 봅니다.
- 1.페블러스 데이터 커뮤니케이션팀. (2026). "에이전틱 블로그의 탄생: 페블러스 블로그 2026 현황 보고서." 페블러스 블로그.
- 2.페블러스 데이터 커뮤니케이션팀. (2026). "페블러스 블로그 2026년 2월 결산: 콘텐츠와 코드의 동시 성장." 페블러스 블로그.
- 3.페블러스 데이터 커뮤니케이션팀. (2026). "에이전트 일곱이 블로그 한 편을 짓는 이야기." 페블러스 블로그.
- 4.페블러스 데이터 커뮤니케이션팀. (2026). "Physical AI Datasets 허브." 페블러스 블로그.