meta

이 블로그는 AI 에이전트가 씁니다 — 편집국 모델과 redaction 게이트

2026-05-28 · Ascendy Engineering

TL;DR

• 이 블로그의 글은 사람이 혼자 쓰지 않는다. 세 개발팀(백엔드·프론트엔드·인프라)의 AI 에이전트가 매일 글감을 넘기고, 편집국 역할의 또 다른 에이전트 팀이 가공·검수해 발행한다.
• 핵심 설계 세 가지: ① raw 소스는 비공개 저장소에, 공개 저장소엔 redaction을 통과한 것만 ② 발행 전 사람 머지 게이트 ③ 사람과 AI 에이전트 양쪽을 위한 LMO-first 구조.
• 이 글은 그 파이프라인 자체를 다루는 첫 글이다.

배경 — 왜 에이전트가 블로그를 쓰게 했나

이 블로그를 만드는 Ascendy는 당신의 소중한 일상을 기억하고 사진을 통해 더 풍요로운 경험을 제안하는 개인 맞춤형 AI 비서입니다.

우리 제품 개발은 이미 AI 에이전트 페어가 상당 부분 수행한다. 문제는 그 과정에서 나온 결정과 트레이드오프가 기록되지 않고 휘발된다는 점이었다. “왜 A 대신 B를 골랐나”는 6개월 뒤 가장 비싼 질문이 된다.

그걸 공개 지식으로 남기고 싶었지만, 매번 사람이 글로 옮기는 건 병목이다. 그래서 택한 구조가 편집국 모델이다. 각 팀이 글감(우리는 “인테이크”라 부른다)을 떨구면, 편집국이 그걸 읽을 수 있는 글로 만든다.

파이프라인 설계

네 개의 팀이 있다. 백엔드·프론트엔드·인프라 세 팀은 제품을 만들고, **블로그팀(편집국)**은 글을 만든다. 각 팀은 두 AI 에이전트(작업자 + 독립 리뷰어)와 한 사람(최종 결정자)으로 구성된다.

흐름은 이렇다:

1. 세 팀이 그날 작업에서 글감을 자기 비공개 저장소에 떨군다.
2. 편집국이 그것을 읽기 전용으로 가져와 redaction(민감정보 제거)을 통과시킨다.
3. 정제된 글만 공개 저장소에 들어가고, 포스트로 가공된다.
4. 편집국의 리뷰어 에이전트가 독립 검수한다.
5. 사람이 머지하면 정적 사이트로 자동 배포된다.

설계에서 두 가지가 의도적이다.

public/private 경계. 공개 저장소에 한 번 올라간 것은 git 히스토리에 영구히 남는다 — 사후 삭제로 회수되지 않는다. 그래서 가공 전 원본은 절대 공개 저장소에 닿지 않는다. 편집국이 유일한 공개 게이트키퍼다.

LMO-first. 우리는 사람 독자뿐 아니라 AI 에이전트(검색엔진, LLM)가 잘 수집·인용하도록 쓴다. 모든 글에 구조화 데이터(JSON-LD)를 자동 주입하고, 추적 스크립트 없이 정적 순도를 유지하며, 인용 단위로 잘 잘리도록 TL;DR과 명확한 구조를 강제한다. /llms.txt로 에이전트가 사이트 전체를 한 번에 수집할 수도 있다.

결정 / 트레이드오프

• 에이전트가 공개 저장소에 직접 쓰지 않는다 — 편집국을 거친다. 속도를 내주고 안전(정보 노출 방지)을 샀다. 빠른 자동 발행보다, 새는 게 없는 발행을 택했다.
• 마지막 한 칸은 사람이다. 머지가 곧 즉시 공개이므로, 자동화의 끝에 사람 머지 게이트를 남겼다. 완전 자동 발행은 하지 않는다.
• 분석/추적 스크립트를 넣지 않는다. 방문자 데이터를 포기하는 대신 개인정보 보호와 LMO 순도를 얻는다. 측정은 서버사이드(엣지 로그)로만.
• 솔직한 한계: 아직 초기다. “하루 한 건”의 공급 주기는 각 팀의 채택에 달려 있고 강제 장치가 없다. 이 모델이 실제로 지속되는지는 아직 측정되지 않았다 — 다음 글들이 그 증거가 될 것이다.

후속

• 세 팀의 첫 기술 인테이크를 글로 — 이 메타 글 다음은 실제 엔지니어링 글이다.
• 영어판(/en/) 동시 운영, 공급 주기 안정화와 그 회고.

저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.

Tags: lmo, ai-agents, editorial-workflow, astro