melororium.com에는 291개의 페이지가 있습니다. 이 모든 페이지는 TypeScript 데이터 레이어(data layer)에서 생성됩니다. 한 사람이 모든 콘텐츠를 작성했습니다. 바로 저입니다.

문제점: 291개의 페이지를 수동으로 감사할 수는 없습니다. 이를 수행할 만한 실질적인 집중력을 유지할 수 없습니다. 50번째 페이지를 확인할 때쯤이면, 12번째 페이지에서 무엇을 보았는지 잊어버리게 됩니다.

그래서 저는 Claude Code를 사용하여 멀티 에이전트 워크플로우(multi-agent workflow)를 구축했습니다.

설정
Claude Code를 사용하면 워크플로우(Workflow) 도구를 통해 병렬 서브 에이전트(subagents)를 생성할 수 있습니다. 작업을 단계별로 구성할 수 있으며 — 일부는 순차적으로, 일부는 병렬로 — 각 에이전트에게 특정되고 제한된 작업을 부여할 수 있습니다.

감사 단계(audit phase)에서는 10개의 에이전트를 병렬로 실행합니다. 각 에이전트는 291개 페이지 전체에 대해 하나의 품질 차원을 동시에 확인합니다:

// SEO 감사 워크플로우 — 의사 코드 (pseudocode)
// 10개의 병렬 에이전트, 291개 페이지, 총 약 20분 소요

const auditPhase = {
type: "parallel",
agents: [
{ id: "seo-desc-auditor", task: 모든 seoDesc 필드를 확인하십시오. 길이는 145-160자여야 합니다. 금지된 문구('freelancer', 'lifetime deal', 'pay once')를 표시하십시오. 오래된 가격($149, $299, $499)을 표시하십시오. },
{ id: "pricing-auditor", task: 모든 콘텐츠를 스캔하여 오래된 가격($149/$299/$499)을 찾으십시오. 현재 정확한 가격은 Starter $29/mo, Agency $59/mo, Studio $119/mo입니다. 오래된 가격이 나타나는 모든 위치를 보고하십시오. },
{ id: "dead-link-checker", task: 모든 내부 링크를 검증하십시오. 모든 /task-tracker/* 경로는 존재해야 합니다. 모든 /pricing 링크는 연결되어야 합니다. 깨진 경로를 보고하십시오. },
{ id: "editorial-note-scanner", task: 렌더링된 콘텐츠에 보이는 개발자 노트를 찾으십시오. 패턴: 'Context:', 'CTA here', 'Note:', 'TODO', 'PLACEHOLDER'. 이들은 프로덕션(production) 기사 본문에 나타나서는 안 됩니다. },
{ id: "duplicate-faq-auditor", task: 2개 이상의 포스트에서 재사용되는 FAQ 답변 블록을 찾으십시오. 모든 블로그 콘텐츠에 대해 정확히 일치하는지 비교하십시오. 중복된 항목과 위치를 표시하십시오. },
{ id: "schema-auditor", task: 모든 페이지의 JSON-LD 스키마 마크업(schema markup)을 검증하십시오. 필수 필드가 반드시 포함되어 있어야 합니다.

필수 위치에 정의되지 않은(undefined) 값이나 null 값이 없어야 합니다.}, { id: "linkbox-auditor", task:모든 CTA linkBox 라벨을 확인하십시오. 올바른 라벨: 'Melororium'. 'Melororium Task Tracker' 또는 기타 변형이 나타나는 모든 사례를 표시(Flag)하십시오.}, { id: "internal-link-auditor", task:가격(pricing)을 언급하지만 /pricing 링크가 없는 포스트를 찾으십시오. 기능을 설명하지만 일치하는 /task-tracker/* 링크가 없는 포스트를 찾으십시오. 누락된 부분을 보고하십시오.}, { id: "compare-data-auditor", task:비교 페이지의 경쟁사 가격을 검증하십시오. ClickUp Business = 사용자당 월 $12. Asana = 사용자당 월 $11. 현재 공개된 요금과 다른 모든 값을 표시(Flag)하십시오.}, { id: "audience-targeting-auditor", task:'freelancer', 'solo', 'self-employed'를 타겟팅하는 seoDesc 또는 H1을 표시(Flag)하십시오. Melororium은 4~25명 규모의 팀을 타겟으로 합니다. 잘못된 타겟팅은 잘못된 쿼리(queries)로 이어집니다.` }
]
};
각 에이전트는 관련 데이터 파일을 읽고, 점검을 실행하며, 발견 사항을 공유 결과 파일에 작성합니다. 총 소요 시간: 291개 페이지 전체에 대해 약 20분 소요되었습니다.

발견된 내용: 155개의 결함
주요 결함 사항:

운영 환경(production)에 개발자 노트가 포함된 35개 섹션. "Context: Natural mention — include CTA here"와 같은 문자열이 게시된 블로그 기사 본문 내부에 있었습니다. HTML 주석이 아니라 렌더링된 텍스트 안에 있었습니다. Google이 해당 페이지들을 크롤링했습니다. 실제 방문자들도 그 텍스트를 읽었습니다. 저는 스캐폴딩(scaffolding)을 운영 환경에 배포하고도 인지하지 못한 채 몇 주 동안 그대로 방치했습니다.

잘못된 제품명이 포함된 28개의 linkBox 라벨. 사이트 전반의 CTA 버튼에 "Melororium Task Tracker"라고 적혀 있었습니다. 이는 이전 제품명입니다. 28곳에서 일관성 없이 나타났으며, 이는 검토 과정을 통과해버린 순수한 찾기 및 바꾸기(find-and-replace) 문제였습니다.

이전 가격이 포함된 7개의 포스트. 기사들에 가격이 $149로 표시되어 있었습니다. 현재의 Starter 플랜은 월 $29입니다. 이 기사들은 가격 모델 변경 이전에 작성되었으며 저는 이를 업데이트하지 않았습니다. 가격 페이지에 도달하기 전 해당 포스트 중 하나를 접한 독자들은 제품에 대해 잘못된 정보를 머릿속에 담게 되었을 것입니다.

11개의 seoDesc 필드가 잘못된 타겟을 대상으로 하고 있었습니다. "freelancer" 또는 "solo" 포지셔닝이 포함된 메타 설명 (Meta descriptions)이 발견되었습니다. Melororium은 4명에서 25명 규모의 에이전시와 스튜디오를 타겟으로 합니다. 잘못된 타겟팅은 전환되지 않을 방문자들을 유도하는 쿼리(queries)에 대해 검색 순위가 매겨지게 만듭니다.

수정 워크플로우 (The fix workflow)
동일한 대형 파일에 병렬로 작성하는 에이전트들은 충돌을 일으킵니다. 메인 콘텐츠 파일은 13,000줄에 달합니다. 해당 파일의 경우, 저는 각 에이전트가 특정 라인 범위를 처리하도록 순차적 (sequential) 에이전트를 실행합니다.

// 수정 워크플로우 — 의사 코드 (pseudocode)
// 대형 파일은 순차적으로, 그 외 모든 것은 병렬로

const fixPhase = {
mainFile: {
type: "sequential", // 하나의 대형 파일에 대한 쓰기 충돌 방지
agents: [
{ id: "fixer-1", task: "content.ts의 1-3250행에 있는 모든 결함 수정" },
{ id: "fixer-2", task: "content.ts의 3251-6500행에 있는 모든 결함 수정" },
{ id: "fixer-3", task: "content.ts의 6501-9750행에 있는 모든 결함 수정" },
{ id: "fixer-4", task: "content.ts의 9751-13000행에 있는 모든 결함 수정" }
]
},
otherFiles: {
type: "parallel", // 별도의 파일들이므로 충돌 위험 없음
agents: [
{ id: "data-fixer", task: "/data/.ts 전체의 모든 결함 수정" },
{ id: "config-fixer", task: "/lib/seo/.ts 전체의 모든 결함 수정" }
]
}
};

순차적 단계는 대형 파일을 깔끔하게 처리합니다. 병렬 단계는 그 외의 모든 것을 동시에 처리합니다.

배운 점
감사 (audit)에는 20분이 소요되었습니다. 수정에는 2시간이 걸렸습니다. 이 비율은 타당합니다. 대규모로 결함을 찾는 것은 빠르지만, 이를 신중하게 수정하는 것은 느립니다.

더 뼈아픈 교훈: 프로덕션 환경에 35개의 개발자 노트가 있었고, 몇 주 동안 Google 크롤링이 진행되었음에도 저는 전혀 알지 못했습니다. 수동 검토 (Manual review)로도 이를 잡아낼 수 없었을 것입니다. 291개의 페이지를 읽으면서 13,000줄의 TypeScript에 삽입된 스캐폴딩 문자열 (scaffolding strings)을 찾아내는 현실적인 방법은 없습니다.

체계적인 감사는 확장 가능합니다 (scales). 인간의 검토는 그렇지 않습니다.

수정이 올바르게 적용되었는지 확인하기 위해 배포 후 이 감사를 다시 실행할 것이며, 그 후 main 브랜치로 머지 (merge)될 때마다 실행되도록 CI에 연결할 것입니다.

만약 데이터 레이어 (data layer)로부터 대규모로 콘텐츠를 생성한다면, 페이지 수가 100개에 도달하기 전에 감사 (audit) 워크플로우를 구축하십시오. 291개 페이지에 걸쳐 155개의 결함을 수정하는 것은 하루 꼬박 걸리는 작업입니다.

기술 스택: 멀티 에이전트 워크플로우 (multi-agent Workflow)를 활용한 Claude Code, TypeScript 콘텐츠 생성, 프론트엔드에는 Next.js를 사용했습니다. 결과물을 확인하고 싶다면 사이트는 melororium.com입니다. 이와 유사한 작업을 해보셨거나, 대용량 파일에 대한 병렬 처리 대 순차 처리 (parallel-vs-sequential)의 트레이드오프 (tradeoff)에 대한 의견이 있다면 듣고 싶습니다.