4팀 에이전트 병렬 작업으로 블로그 인포그래픽 46개 만들기
블로그 글은 텍스트만으로도 충분할 때가 있다. 하지만 벤치마크 비교, 아키텍처 흐름, 시장 수치 같은 정보는 시각 자료가 있으면 이해 속도가 확 달라진다. 8개 블로그 포스트에 인터랙티브 인포그래픽 46개를 한번에 추가한 과정을 정리한다.
배경: 텍스트 블로그의 한계
기존 블로그 포스트는 마크다운 본문만 있었다. AI 모델 벤치마크를 표로 나열하거나, HBM4 스펙을 글로 설명하면 독자가 핵심을 파악하기까지 시간이 걸린다.
MCP 포스트에 처음 인포그래픽을 넣어봤더니 반응이 좋았다. SVG 다이어그램으로 스파게티 구조와 클린 구조를 비교하고, 플로우 차트로 아키텍처를 보여주니 글만 읽을 때보다 이해가 빨랐다. 나머지 포스트에도 확장하기로 했다.
레퍼런스: MCP 인포그래픽 패턴
첫 번째 인포그래픽이었던 MCP 포스트의 구조를 분석했다.
파일 구조
src/app/blog/mcp-linux-foundation-agentic-ai/page.tsx ← 커스텀 라우트
src/components/visuals/mcp/
├── MCPInfographic.tsx ← 오케스트레이터
├── SpaghettiDiagram.tsx ← SVG 다이어그램
├── CleanDiagram.tsx ← SVG 다이어그램
├── ArchitectureFlow.tsx ← 단계 플로우
└── SummaryCards.tsx ← 결과 카드
핵심 패턴
오케스트레이터가 sub-component를 조합하고 디바이더로 구분한다. SVG는 viewBox + width="100%"로 반응형 처리하고, motion.path로 라인 애니메이션을 건다. 카드는 CSS 변수 기반 테마에 group hover 인터랙션을 쓴다.
커스텀 page.tsx에서 dynamic(import, { ssr: false })로 클라이언트 전용 렌더링하면 Next.js의 [slug] 동적 라우트 대신 이 페이지가 우선 적용된다. 이 패턴을 그대로 복사해서 8개 포스트에 적용하면 된다.
설계: 4팀 병렬 작업
8개 포스트를 순차적으로 하면 시간이 오래 걸린다. Claude Code의 멀티에이전트를 활용해 4팀으로 나눠 병렬 작업했다.
| 팀 | 포스트 1 | 포스트 2 | 파일 수 |
|---|---|---|---|
| A | AI 에이전트 자율 업무 | Copilot vs Claude | 11 |
| B | Gemini 3.1 Pro | AI 트렌드 2025-2026 | 12 |
| C | 삼성 HBM4 | Seedance 2.0 | 11 |
| D | 멀티에이전트 리빌드 | 정렬/탐색 알고리즘 | 12 |
충돌 방지가 핵심이다
병렬 작업에서 가장 큰 리스크는 같은 파일을 동시에 수정하는 것이다. 세 가지 규칙을 세웠다.
공유 파일(animations.ts, globals.css, tailwind.config.ts)은 전부 READ-ONLY로 묶었다. 각 팀은 자기 디렉토리(src/components/visuals/{topic}/)만 생성한다. [slug] 동적 라우트는 건드리지 않고 커스텀 page.tsx로 오버라이드한다.
이 규칙 덕분에 4개 에이전트가 동시에 파일을 생성해도 충돌이 0건이었다.
구현 결과
4팀 병렬 작업의 결과를 정리하면 이렇다.
- 신규 파일 46개: 8 page.tsx + 8 orchestrator + 30 sub-components
- 커스텀 라우트 8개: 전부 정적 페이지로 생성
- 타입 에러 0건:
npx tsc --noEmit통과 - 빌드 성공:
npm run buildexit 0 - R-Review 9/9 통과: 사용하지 않는 import, 메모리 누수, 회귀 버그 등 전 항목 클리어
만든 인포그래픽 유형
| 유형 | 예시 | 적용 포스트 |
|---|---|---|
| SVG 라인 차트 | 시간복잡도 곡선 | 알고리즘 |
| 수평 바 차트 | ARC-AGI-2 벤치마크 | Gemini 3.1 Pro |
| 방사형 조직도 | 에이전트 팀 구조 | 멀티에이전트 |
| 비교 테이블 | Copilot vs Claude | 코딩 도구 |
| 플로우 차트 | 메모리 병목 | HBM4 |
| 결정 트리 | Binary vs Linear Search | 알고리즘 |
| Before/After | 챗봇 vs 에이전트 | AI 트렌드 |
교훈 세 가지
파일 소유권 분리. 각 팀의 디렉토리를 완전히 분리하고 공유 파일은 읽기 전용으로 묶으면 충돌 걱정 없이 속도를 낼 수 있다. 단순한 규칙이지만 가장 효과적이었다.
패턴을 먼저 확립하고 복제한다. MCP 포스트에서 검증된 패턴이 없었다면 8개를 한번에 만드는 건 불가능했다. 하나를 제대로 만들고 그 구조를 복사하는 접근이 훨씬 효율적이다.
빌드 검증은 타협하지 않는다. 46개 파일을 만들고 npm run build가 한 번에 통과한 건 각 에이전트가 동일한 패턴과 규칙을 따랐기 때문이다. 빌드가 깨지면 어떤 팀의 어떤 파일이 문제인지 추적하기 어려워진다.