이 블로그는 어떻게 만들어졌나

86개의 deep-dive 레포지토리. 3,500개 이상의 한국어 기술 문서. 거기서 양산해 발행한 600개 이상의 블로그 포스트.

이 모든 것을 한 명이 만들 수 있을까? 직접 쓰는 방식으로는 불가능하다. 그래서 다른 방식을 시도했다 — AI로 양산하고, 인간이 큐레이션하는 시스템.

이 글은 그 시스템의 회고다. 무엇을 만들었고, 어떤 결정을 내렸고, 무엇이 한계로 남았는지. 그리고 이 블로그가 왜 그 시스템의 첫 번째 검증 사례인지.

문제: 86개의 주제, 한정된 시간

처음 시작은 단순했다. Spring Core를 진짜로 이해하고 싶었다. 표면적인 사용법 — @Autowired를 어디 쓰는지, @Transactional이 어떻게 동작하는지 — 가 아니라, 왜 그렇게 설계됐는가를 알고 싶었다.

깊게 파고들면 한 주제가 끝없이 확장된다. Spring Core 하나만 해도 IoC 컨테이너 내부, Bean 생명주기, AOP Proxy, BeanFactory와 ApplicationContext의 차이, 순환 참조 처리 메커니즘 — 이런 것들이 각각 한 권의 책이 될 만큼 깊다.

그래서 한 주제에 51개 문서로 정리하기로 했다. spring-core-deep-dive. 그 다음은 spring-data-transaction, spring-mvc-deep-dive, spring-security-deep-dive. 백엔드 영역만 38개 레포가 필요했다.

여기서 끝이 아니었다. AI 영역도 같은 방식으로 정리하고 싶었다. Linear Algebra부터 Frontier LLM까지, 11개 레이어 48개 레포. 도합 86개.

각 레포는 평균 40개 문서. 총 3,500개의 한국어 기술 문서.

직접 쓰면 몇 년이 걸릴까? 하루 한 개씩 써도 3년. 현실적으로 불가능했다.

가설: AI 양산 + 인간 큐레이션

해결책의 방향은 명확했다. AI를 활용한 양산. 하지만 단순히 Claude에 프롬프트를 던지는 건 답이 아니었다. 그건 누구나 할 수 있고, 결과물의 품질도 일관되지 않는다.

진짜 필요한 건 시스템이었다.

• 인간이 정의한다: 학습 경로, 톤, 깊이, 검증 기준
• AI가 양산한다: 일관된 템플릿으로 콘텐츠 생성
• 인간이 검증한다: 발행 전 큐레이션

이 세 단계의 분리가 핵심이었다. 콘텐츠 생산을 자동화하려는 시도는 많지만, 대부분 AI에 모든 것을 맡긴다. 그러면 평균 품질의 글이 양산될 뿐, 진짜 가치 있는 글은 안 나온다.

시스템 설계: 12개 컨스트레인트

deep-dive 레포의 모든 문서는 동일한 10섹션 한국어 템플릿을 따른다. 🎯 핵심 질문, 🔍 표면적 이해, 😱 진짜 이유, ✨ 작동 원리, 🔬 깊은 분석, 💻 코드 예제, 📊 비교 분석, ⚖️ 트레이드오프, 📌 실무 적용, 🤔 추가 탐구.

이 구조를 강제하는 이유는 명확하다. 자유도가 높을수록 품질이 떨어진다. AI는 형식이 명확할 때 가장 잘 작동한다.

iq-blogger의 변환 단위는 챕터가 아닌 폴더다. 한 폴더(5–7 챕터, ~3,500줄)를 한 편의 합성 에세이(~1,000단어)로 압축한다. 단순 요약이 아니라 챕터들을 관통하는 공통 원리를 추출하는 작업이다. 이 단위에 12개의 컨스트레인트가 적용되며, 9개는 hard error(재시도 트리거)이고 3개는 warning(통과는 하되 정보용)이다.

▸ 12개 컨스트레인트 (실제 validator.ts 룰)

Hard errors (재시도 트리거)

1. 단어 수 500–2000 — 권장 700–1500, 1000 목표
2. H2 5–7개, 마지막 H2는 정확히 “정리”
3. 인트로 — H2 없이 시작, 5문장 이내
4. tags 3–5개 + kebab-case
5. 경어체 금지 — ~합니다 → ~한다
6. 제목 이모지 금지 — 본문은 허용
7. 특정 섹션 제거 — 💻 실전 실험, 🤔 생각해볼 문제는 통째 드롭
8. frontmatter draft: true, featured: false (기본값)
9. Reference 환각 방지 — 본문에 인용된 논문만 사용 (메타데이터 검증)

Warnings (통과는 가능, 정보용)

9. 미사용 MDX import
10. 코드블록 언어 태그 누락
11. $$ 수식 블록 위아래 빈 줄

검증: Zod 스키마 + 재시도 루프

가장 어려운 건 품질 검증이었다. AI가 만든 결과물이 위 12개 컨스트레인트를 모두 만족하는지 어떻게 자동으로 확인할까?

답은 두 층위로 갈라진다. frontmatter 구조는 Zod 스키마로 정적 검증한다(title, description, pubDate, category, series 등). 본문 내용 룰은 별도 validator가 워드 카운트, H2 구조, 경어체, 태그 형식 같은 12개 룰을 검사한다.

검증 실패 시 자동 재시도 루프가 작동한다. 최대 3회까지. 각 재시도에서는 이전 실패 이슈가 다음 프롬프트에 명시적으로 포함되어 AI가 어디를 고쳐야 할지 안다. 3회 모두 실패하면 사람 검토 큐로 들어간다.

// 단순화된 agent.ts 루프
async function convert(input: ConversionInput): Promise<ConversionResult> {
  for (let attempt = 1; attempt <= MAX_RETRIES + 1; attempt++) {
    const response = await client.messages.create({ ... });
    const mdx = extractTextContent(response);
    const validation = validate(mdx);  // 12개 룰

    if (validation.ok) return { ok: true, mdx, ... };

    // 다음 시도에 이슈를 피드백으로 첨부
    messages.push({ role: 'assistant', content: mdx });
    messages.push({ role: 'user', content: formatIssuesForRetry(validation.issues) });
  }
  return { ok: false, ... };
}

이 피드백 루프 하나가 전체 시스템의 품질 보증 메커니즘이다. 본격 양산 결과 600+ 폴더 중 약 95%가 첫 시도 통과, 나머지도 1–3회 재시도 안에 통과했다.

비용 최적화: Caching + Batch로 ~60% 절감

품질 시스템이 자리잡으니 다음 병목은 비용이었다. 폴더당 $0.21, 600 폴더 양산이면$130. 큰 돈은 아니지만 반복 양산을 고려하면 무시할 수 없다.

두 가지 Anthropic 기능을 차례로 적용했다.

1단계 — Prompt Caching. 모든 변환 요청은 같은 system prompt(~5.5K)와 동일한 few-shot 예시(~6.5K)를 포함한다. 이 ~12K 토큰을 1시간 TTL로 캐싱한다. 첫 요청은 cache write(2x 비용), 그 다음부터는 cache read(0.1x 비용). 폴더당 ~14% 절감.

캐싱은 마커 위치가 핵심이다. system + few-shot 블록에만 마커를 달고, 폴더마다 달라지는 task + chapters 블록에는 마커를 안 달았다. 후자에 마커를 달면 매 폴더마다 cache write 비용이 부과되어 오히려 손해(retry 빈도 ~12% 정도라서 read 이득이 write 손해를 못 따라잡는다).

2단계 — Batch API. Anthropic의 Message Batches API는 단일 요청에 N개 변환을 묶으면 모든 토큰 비용 50% 할인한다. 대신 결과는 비동기로 받아야 한다(보통 1시간 내, 최대 24시간 SLA).

iq-blogger의 convert-batch 명령은 N개 레포의 모든 폴더를 단일 batch로 제출하고, 결과를 폴더별로 검증해 디스크에 쓴다. 검증 실패한 폴더는 자동으로 sync API에 fallback해서 재시도 루프를 돌린다(batch 안에서는 retry가 불가능하므로).

두 기능이 곱해져서 폴더당 비용이 $0.21 →$0.086, 약 60% 절감.

모드	폴더당	vs base
sync (base)	~$0.21	—
sync + caching	~$0.18	-14%
batch + caching	~$0.086	-60%

실측 양산 결과: iq-dev-lab + iq-ai-lab + 책 시리즈 합쳐 86 레포 / 600+ 폴더를 변환하는 데 **누적 ~$100**. sync 단독으로 했다면 ~$170 정도 들었을 것.

한계: 인간 큐레이션 없이는 안 됨

시스템을 만들면서 가장 명확해진 사실은 자동화의 한계다.

iq-blogger는 형식적 일관성을 보장한다. 모든 글이 같은 구조, 같은 깊이, 같은 톤이다. 하지만 개별 글의 진짜 가치 — 이게 좋은 글인가 — 는 자동으로 판단할 수 없다.

좋은 글의 기준이 정량화 안 되기 때문이다.

• 이 비유가 적절한가?
• 이 예제가 핵심을 잘 보여주는가?
• 이 트레이드오프 분석이 진짜로 중요한가?

이런 질문은 결국 사람이 답해야 한다. 그래서 모든 글은 발행 전 큐레이션 검토를 거친다. 부족한 부분은 AI로 다시 증강하고, 필요하면 직접 수정한다.

다음 단계: Agent 시스템으로의 확장

iq-blogger는 첫 번째 검증이다. 텍스트 콘텐츠 자동화에서 작동한다는 것을 증명했다. 다음 질문은 이 패턴이 다른 도메인에도 적용되는가이다.

• iq-label: 음악 자동화 (작곡·편곡)
• iq-writer: 다른 형태의 글쓰기 (소설·에세이)
• iq-painter: 이미지·일러스트
• iq-curator: 도메인 통합 큐레이션

각 도메인은 검증 방식이 다르다. 텍스트는 Zod 스키마로 검증할 수 있지만, 음악은 어떻게? 그림은? 이런 질문들이 다음 단계의 핵심 도전이다.

궁극적으로 이 모든 것은 agent 시스템으로 수렴한다. 각 도메인의 자동화를 추상화하고, 공통 인프라로 통합하는 작업. 그게 다음 1~2년의 목표다.

정리

이 블로그는 글을 쓰는 곳이 아니다. 시스템의 첫 번째 검증 사례다.

• 86개 레포 → 3,500+ 한국어 문서 (이미 완료)
• iq-blogger → 600+ 폴더 / ~$100로 양산 완료 (Layer 0–6 + 책 시리즈 포함)
• 양산 비용 ~60% 절감 검증 (caching + batch)
• agent 시스템 → 다른 도메인 확장 (다음 단계)

표면적으로는 평범한 기술 블로그처럼 보일 수도 있다. 하지만 본질은 AI 자동화 인프라의 살아있는 실험이다. 매주 한 개씩 발행되는 글들은 그 시스템이 작동하고 있다는 증거다.

표면이 아닌 본질을 증명하는 기록 — 이 블로그의 슬로건은 콘텐츠뿐 아니라 시스템 자체에도 적용된다.