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

87개의 deep-dive 레포지토리. 3,500개 이상의 한국어 기술 문서. 그리고 곧 발행될 500개 이상의 블로그 포스트.

이 모든 것을 한 명이 만들 수 있을까? 직접 쓰는 방식으로는 불가능하다. 그래서 다른 방식을 시도했다 — 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에 모든 것을 맡긴다. 그러면 평균 품질의 글이 양산될 뿐, 진짜 가치 있는 글은 안 나온다.

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

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

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

iq-blogger도 같은 원칙을 따른다. deep-dive 문서를 블로그 포스트로 변환할 때, 11개의 하드 컨스트레인트가 적용된다.

▸ 11개 하드 컨스트레인트 (요약)

1. 챕터 단위 변환 — 한 deep-dive 문서는 한 블로그 포스트
2. 핵심 통찰 우선 — 표면 정보가 아닌 “왜”에 집중
3. 수식 보존 — KaTeX 렌더링 가능한 형태로 유지
4. 코드 예제 검증 — syntax 오류 자동 검출
5. MDX 컴포넌트 사용 — Callout, Theorem, Proof 등 일관성
6. 한국어 톤 유지 — 학술적이지만 친근한 어조
7. 메타데이터 검증 — Zod 스키마로 frontmatter 보장
8. 링크 정합성 — 깨진 링크 자동 검출
9. 이미지 alt 텍스트 — 접근성 강제
10. 태그 표준화 — 정의된 태그 풀에서만 선택
11. 시리즈 연결성 — 시리즈 내 글들의 순서 검증

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

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

답은 Zod 스키마였다. 모든 결과물은 발행 전 Zod로 정적 검증을 거친다. frontmatter 구조, 필수 필드, 타입, 길이 제약 — 이 모든 게 코드 레벨에서 검증된다.

검증 실패 시 자동 재시도 루프가 작동한다. 최대 3회까지. 각 재시도에서는 이전 실패 이유가 프롬프트에 포함되어 AI가 학습한다. 3회 모두 실패하면 인간 검토 큐로 들어간다.

// 단순화된 흐름
async function generatePost(chapter: Chapter): Promise<Post> {
  for (let attempt = 1; attempt <= MAX_RETRIES; attempt++) {
    const draft = await generateWithAI(chapter, previousErrors);
    const result = PostSchema.safeParse(draft);

    if (result.success) return result.data;
    previousErrors = result.error.issues;
  }

  throw new ValidationFailure('Manual review required');
}

이 패턴 하나가 전체 시스템의 품질 보증 메커니즘이다.

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

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

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

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

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

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

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

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

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

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

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

정리

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

• 87개 레포 → 3,500+ 문서 (이미 완료)
• iq-blogger → 500+ 블로그 포스트 (진행 중)
• agent 시스템 → 다른 도메인 확장 (다음 단계)

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

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