이 기사의 실시 기록 (2026년 5월 6일): Claude Code의 에이전트 조직에서 「기사가 부실하다」는 문제의 원인을 특정하고, 대화 아카이브 시스템을 설계부터 구현까지 1세션 만에 구축했다. COO가 직접 구현한 파일은 5개. 스크립트 없음. 외부 도구 불필요.

왜 AI에게 쓰게 하면 기사가 부실해지는가

AI에게 기사를 쓰게 해봤지만, 왠지 모르게 내용이 부실하다 —— 이런 느낌을 받은 적이 있는 사람은 적지 않을 것이다.

프롬프트 (Prompt)를 다듬는다. 리뷰 (Review) 루프를 늘린다. 그래도 개선되지 않는다.

나 또한 그중 한 명이었다. Claude Code로 에이전트 조직을 구성하고, Writer 에이전트에게 기사 작성을 맡기고 있었다. 결과물은 정확하고 구조는 잘 잡혀 있다. 다만, 읽다 보면 「살아있지 않다」. 말투가 교과서적이고, 대화 속에서 생겨났을 갈등이나 판단의 망설임이 사라져 있다.

어느 세션에서, 나는 그 원인을 언어화했다.

「다른 이야기지만, Writer가 집필할 때 나나 COO의 실제 과거 발언을 참조하지 못하고 있다. 이 때문에 기사의 깊이가 생기지 않으니 어떻게든 하고 싶다.」

문제는 쓰는 방식이 아니라, 소재의 구조에 있었다.

「쓰는 법」보다 「소재에 대한 액세스 (Access)」가 문제였다

Writer 에이전트가 참조할 수 있는 것은 content/writing/netacho/ (네타초/아이디어 노트)뿐이다.

설계 논의에서 주고받은 발언, 사용자가 순식간에 내린 판단, 「왜 이 선택을 했는가」의 근거 —— 이것들은 네타초에 전사(Transcription)되지 않는 한 사라진다.

대화 로그는 세션이 끝나면 소실된다. Writer는 존재하지 않는 소재로부터 「생생한 기사」를 쓸 수 없다. 당연한 일이다.

즉, 해결책은 「더 잘 쓰게 만드는 것」이 아니라, 대화의 생생한 발언을 Writer가 참조할 수 있는 장소에 저장하는 것이다.

이 깨달음으로부터 설계를 구체화하기로 했다.

3가지 안을 비교하여, 사용자가 10초 만에 선택했다

접근 방식은 주로 3가지로 생각할 수 있었다.

입구에서 포착하는 안: 네타 채굴 시 대화의 생생한 인용 블록을 네타초에 반드시 전재한다 (운영 규칙 강화)

물리적 저장 안: 세션의 발언을 구조화하여 저장하고, Writer가 grep 할 수 있는 인용 소재 데이터베이스를 만든다

집필 시 참조 안: Writer 프롬프트에 「대화 인용을 최소 N건 포함할 것」을 필수화한다

나는 2안을 선택했다.

「2번, 내가 저장하라고 말할 때만 하면 돼」

이 한마디가 설계의 방향을 결정했다. 자동 저장이 아닌 유저 트리거 (User Trigger)형 —— 「내가 필요하다고 생각한 대화만 저장한다」라는 제약이 시스템을 심플하게 유지하는 근거가 되었다.

「거창한 시스템을 만들 마음은 없다」라고 생각하는 독자도 있을지 모른다. 이 판단이 있는 한, 불필요한 자동화는 들어가지 않는다.

설계 구체화 —— 저장 범위와 저장 위치

다음으로 두 가지 설계 판단이 필요했다.

저장 범위의 선택지:

• (a) 직전의 사용자 발언 1개만
• (b) 최근의 화제 덩어리 (문맥 판단으로 턴(Turn) 그룹을 포착)
• (c) 범위 지정형 (매번 지시)

저장 위치·단위의 선택지:

• (a) 날짜 단위 파일:
  knowledge/dialogue/2026-05-06.md

• (b) 테마 단위 파일:
  knowledge/dialogue/<slug>.md

• (c) 네타초에 직접 소재 인용으로서 혼합

COO의 권장 사항은 「화제 덩어리 × 테마 단위 파일」이었다. 이유는 간단하다. Writer가 「그 이야기 어디 있더라」 하고 찾을 때, 테마로 묶여 있는 편이 grep으로 끌어오기 쉽기 때문이다.

「권장대로」

사용자의 승인은 이 세 글자였다.

architect에게 위임하여 설계서 작성

설계 방향이 확정되었으므로, architect 에이전트에게 설계서 작성을 위임했다.

완성된 ops/playbooks/dialogue-archive.md의 요점은 다음과 같다:

• 저장 위치: knowledge/dialogue/<slug>.md (독립 디렉터리 신설)
• 트리거 패턴: 「저장해줘」, 「대화 저장해줘」, 「이거 저장해줘」, 「아카이브해줘」, 「이 대화 저장해둬」
• slug 결정: COO 제안 → 사용자 승인
• 추가 운영: 동일 테마는 ## YYYY-MM-DD 섹션으로 말미에 추가
• 발화 형식: User: / COO:를 사용하여, 요약하지 않고 발화 그대로 옮김

요약하지 않고 그대로 옮긴다 —— 이 점이 핵심이다. 요약하면 「생생한 언어」가 사라진다. 인용은 일자일구(一字一句)의 정밀도가 소재의 가치를 결정한다.

COO 직접 구현으로 5개 파일 구현

설계서가 완성된 후, 구현을 어떻게 진행할 것인가에 대한 판단이 있었다.

「5개도 COO로」

skilldev에게 위임하는 것이 아니라, COO가 직접 구현한다. 실제로 작성 및 변경한 것은 5개 파일이다.

knowledge/dialogue/README.md

(디렉토리 설명 · grep 예시) -
ops/playbooks/INDEX.md

(소재 채굴 섹션에 1행 추가) -
ops/playbooks/coo-trigger-list.md

(대화 아카이브 섹션 추가) -
.claude/agents/writer.md

(담당 업무 · 참조 Playbook 추가) -
ops/playbooks/dialogue-archive.md

(architect가 작성한 Playbook 본체)

스크립트는 없다. 기존 파일 구조에 5곳을 덧붙일 뿐이다. "나에게는 이런 시스템을 만들 수 없다"라는 우려가 있다면, 이 사실이 반론이 된다. architect 에이전트가 없는 환경에서도, 이 5개 파일은 COO(또는 당신 자신)가 직접 구현할 수 있다.

.gitignore라는 블록 장애

구현 후 git status를 확인했을 때 문제가 떠올랐다. /knowledge/가 .gitignore로 차단되어 있었다.

Zettelkasten 계열의 노트를 로컬로 운용하기 위한 설계였으나, 대화 아카이브까지 제외되어 버린 것이다. 즉, 이대로라면 저장한 대화 로그가 git 관리 대상에서 벗어나 소실될 위험이 남는다.

선택지는 두 가지다.

• A: knowledge/dialogue/를 gitignore의 예외로 설정한다.
• B: 현상 유지 (로컬 운용 상태 그대로 유지)

COO의 권장 사항은 A다. 이유는 "대화의 역사적 기록으로서 시간이 흐를수록 가치가 더해지는 성질이 있으며, 소실 위험을 피하고 싶기" 때문이다.

"A"

.gitignore 예외 설정으로 해결

기술적인 변경은 작았다.

.gitignore의 기술을 /knowledge/에서 /knowledge/*로 바꾸고, !/knowledge/dialogue/를 추가한다. 이렇게 하면 inbox-evernote 등의 기존 ignore 설정은 유지하면서, dialogue/만 git 관리 하에 둘 수 있다.

이 2줄의 변경이 설계 사상을 체현하고 있다. —— 대화는 사라져서는 안 된다, 라는 선택이다.

설계 논의 그 자체가 첫 번째 저장 대상이 되었다

구현이 완료된 시점에서 COO가 동작 확인을 제안했다.

"동작 확인으로서 '저장해줘'라고 말씀해 주시면, 본 세션의 직전 대화 덩어리로부터 테스트할 수 있습니다. 이번 대화 아카이브 설계 논의 그 자체를 첫 번째 저장 대상으로 삼으면 POC(Proof of Concept) 시작이 됩니다."

나는 그대로 말했다.

"이 대화를 저장해줘"

slug dialogue-archive-design으로 승인되어, knowledge/dialogue/dialogue-archive-design.md에 저장되었다.

대화 아카이브 시스템의 설계 논의가, 그 시스템으로 저장된 첫 번째 기록이 되었다. 설계가 가동된 순간의 기록이 설계의 기록 그 자체라는 메타(Meta)적인 구조 —— 이는 계산해서 나온 것이 아니라 자연스럽게 그렇게 되었다.

그리고 이것으로 이야기는 끝나지 않는다.

이 시스템이 정말로 기능했는지는 "저장한 소재가 실제로 기사에 사용되었는가"로 측정할 수밖에 없다. Hatena에 공개한 기사 "'후보를 올려줘'라는 한마디로 50분 만에 5개 스킬 완성 —— Claude Code가 스스로 설계·구현·push한 실록"의 본문에는 대화 아카이브를 출처로 명기한 부분이 있다. 저장했기에 인출할 수 있었고, 인출할 수 있었기에 기사에 사용할 수 있었다 —— 라는 사이클이 실제로 돌아갔다.

이 대화 자체도 이후의 기사에서 "메타 실연 구조"의 실례로 인용될 것이다. 저장했기에 인출할 수 있었다 —— 이 글을 쓰면서 그것을 실감하고 있다. 소재의 가치는 저장한 순간이 아니라, 인출하는 순간에 태어난다.

이 기사는 Hatena Blog로부터의 크로스 포스트입니다.

Discussion