11체의 AI 에이전트가 알아서 지식 베이스(Knowledge Base)를 키우도록 하고 있다

• 문서는 쓰는 사람에 따라 입도(Granularity)와 품질이 제각각이다
• 숙련된 사람에게 부하가 편중되며, 그 사람이 쓴 문장이 다른 멤버들에게 읽기 쉽다고도 할 수 없다
• 오래된 기사의 유지보수가 되지 않아 정보가 낡았다
• 정신을 차려보면
  나밖에 쓰고 있지 않다

팀에서 지식(Knowledge)을 운용하려고 하면, 반드시 이러한 벽에 적어도 저는 계속 부딪혀 왔습니다.

이 「조직의 정보 수집·지식 평준화」라는 과제를, 인간이 아니라 AI 에이전트(AI Agent) 무리에게 지식 베이스를 키우게 함으로써 해결할 수 없을까 하는 시도를 최근 1개월 정도 하고 있습니다.

원래 에이전트 하네스(Agent Harness)를 백엔드에 두고 여러 가지 일을 시키는 시스템 구현에 흥미가 있어 시험해보고 싶었기에, 에이전트는 Hermes Agent로 구현하기로 했습니다.

앞서 언급한 과제를 해결하기 위해, 그 대부분을 AI 에이전트에게 맡기는 **에이전트 주도형 지식 베이스(Agent-driven Knowledge Base)**를 곁에서 조금씩 키워나가고 있습니다.

이 기사에서는 이 시스템을 「지식 베이스(Knowledge Base)」라고 부르고 있지만, 사실 아직 「사용자가 지식을 투입하면 에이전트가 기사를 작성한다」는 스토리는 구현하지 않았습니다.

즉, 정보원은 Web뿐이며, 현재로서는 사실상 팀 전용 뉴스 큐레이션 도구입니다.

이것은 대략적으로 말하면, 사용자와의 접점 계층 및 BFF로서의 WebUI (React Router v7 + Hono), 뒤에서 여러 태스크를 수행하는 에이전트로서의 Hermes Agent, 그리고 그 사이를 연결하는 MCP 서버라는 세 가지 요소로 구성되어 있습니다.

만들면서 의식한 점은 다음과 같습니다.

인간은 기사를 직접 편집하지 않는다: 모든 기사 편집은 에이전트가 수행합니다. 사용자는 WebUI를 통해 채팅이나 기사별 댓글창에서 수정이나 추가 정보 수집을 지시합니다 -
에이전트끼리는 직접 호출하지 않는다: 에이전트가 에이전트를 호출하는 일은 없으며, 에이전트가 다른 에이전트를 호출할 경우에는 태스크 큐(Task Queue, 의뢰)를 경유합니다 -
에이전트 하네스(Agent Harness)가 태스크 실행을 관리: 백엔드에서 Hermes Agent가 각 에이전트를 cron으로 호출합니다 -
기사 컬렉션뿐만 아니라 에이전트도 성장: 각 에이전트는 cron으로 호출되는 *스킬(Skill)*로서 구현되어 있습니다. 그리고 Hermes Agent에는 Skill을 자동으로 개선하는 기능이 있습니다. 이를 통해 에이전트가 조사나 기사 작성 노하우를 스스로 SKILL.md에 반영함으로써, 알아서 성장해 나갑니다 -
기사 컬렉션이 사실상의 스테이트(State): 여러 전제가 있어 여기서 설명하기 어렵지만, 여러 턴의 작업을 에이전트의 스테이트로 하고 싶지 않기 때문에, 기사 컬렉션을 매개로 할 수 있도록 했다는 뜻입니다

그랜드 디자인, 기술 스택, 유저 스토리, 비기능 요구사항만 진지하게 작성하고, 나머지는 Claude Code (Opus 4.7 → Opus 4.8)로 99% 정도 작성했습니다.

• Hermes는 OpenCode Go로 모두 구동하고 있습니다. 기본적으로는 deepseek-v4-flash가 저렴하고 우수하며, 조금 복잡한 일을 하는 에이전트는 deepseek-v4-pro를 사용하고 있습니다 -
• web_search의 백엔드로 SearXNG를 셀프 호스팅하고 있는데, 로컬에서의 액세스임에도 꽤 CAPTCHA에 의해 차단됩니다. VPS 등에서 호스팅하려면 Firecrawl 같은 서비스가 필수적일지도 모릅니다 - SearXNG는 검색만 가능하므로 web_extract를 위한 백엔드가 별도로 필요한데, 그것은 minakata 안에 Firecrawl의 /v1/scrape 호환 API를 만들어 사용하고 있습니다

지식 베이스의 성숙이 어떻게 진행되는지, 에이전트를 소개하며 설명하겠습니다. 스크린샷에 전원이 들어있지는 않지만, 총 11+1개의 에이전트가 구현되어 있습니다.

점점 재미있어져서 너무 많이 늘린 경향은 있지만, 이것으로 충분하다고 단정 지을 수도 없습니다. 이 부분은 앞으로도 계속 시행착오를 거쳐 나가고 싶습니다.

사용자와의 대화를 담당합니다. 1분 주기로 사용자의 채팅, 기사에 대한 댓글을 폴링(Polling)하고 있습니다. 미대응 메시지를 발견하면 그 내용을 질문/조사 의뢰/편집 의뢰/기타 잡담으로 분류합니다. 질문이라면 전체 검색을 통한 RAG, 조사 의뢰의 경우 researcher

에 태스크를 의뢰하고, 기사 편집 의뢰는 reviser

에게, 잡담에는 적당히 잡담을 나눕니다.

사용자의 목소리를 듣는 "귀"라고 할 수 있습니다.

이 시스템의 핵심인 웹 조사와 기사 작성을 담당합니다. 5분 주기로 태스크 큐(Task Queue)를 폴링(Polling)하며, web_search

와 web_extract

명령을 사용하여 정보를 수집하고, 정보가 정리되면 기사로 만들어 나갑니다.

가동 빈도가 상당히 높아서, 에이전트 모니터의 60%가 이 녀석인 경우도 드물지 않습니다. 항상 고마워.

• 이 에이전트는 담당 범위가 너무 넓어지고 있어서, 조사 에이전트와 기사 편집 에이전트로 나누는 것이 좋을 것 같다는 생각이 듭니다.

사용자의 기사에 대한 코멘트에 대응할 때, 추가 조사를 할 필요까지는 없는 경미한 편집이 발생하는 경우가 있습니다. 그 편집을 담당하는 것이 이 에이전트입니다. 일단 reviser

가 받은 태스크라도, "역시 추가 조사가 필요하겠는데"라고 판단되면 researcher

에게 조사와 기사 편집을 맡깁니다.

• 이 에이전트는 폴링 주기가 짧은 것에 비해, 그렇게 빈번하게 의뢰가 들어오는 느낌도 아닌 미묘한 위치에 있기도 합니다.
  기사 편집 에이전트로 정하고, researcher

와 페어로 묶어버리는 편이 나을지도 모르겠습니다.

이 시스템에서는 사용자가 미리 "구독"하고 싶은 내용을 설정할 수 있도록 되어 있으며, daily_research

는 매일 밤 그 내용에 대해 web_search

를 실행합니다. 검색 결과에서 괜찮은 키워드를 포착하여 researcher

에게 태스크를 던집니다.

이 자체가 검색도 수행한다는 점이 포인트입니다. 단순히 구독 키워드로 "LLM"이나 "생성 AI"를 설정해 두었더라도, 검색 결과에서 "Claude", "GPT"와 같은 단어를 포착할 수 있다면, "Claude"를 구독하지 않았더라도 해당 기사가 만들어집니다.

새벽 3시에 밤마다 정보를 모으러 다니기 때문에 요나(Yona)입니다.

여러 조사가 진행되다 보면, "기사에 자주 등장하지만, 정작 그것 자체를 다루는 기사가 없는" 경우가 종종 발생합니다. 예를 들어, "Vue.js"와 "Svelte" 기사에 "React와의 비교"가 실려 있는데, 정작 "React" 기사는 없는 경우입니다. 이러한 **지식의 공백(Knowledge Gap)**을 찾아내어 researcher

에게 조사를 의뢰합니다. 지식 베이스(Knowledge Base)의 망라성을 높이기 위한 에이전트입니다. 매일 아침 4시에 가동됩니다. 눈에 띄지는 않지만, 점 형태의 조사를 면으로 넓혀주는 중요한 에이전트라고 생각합니다.

지식을 운용하면서 가장 곤란한 점은, 오래된 정보가 계속해서 오래된 채로 남아있는 것입니다. freshness_checker

는 기사의 신선도 관리를 담당합니다. 6시간 주기로, 작성 또는 추가 조사로부터 일정 기간(24h, 72h, 168h)이 경과한 기사에 대해 재조사 큐를 생성하거나 아카이브(Archive)화를 제안합니다.

• 현재 아카이브화는 사용자의 승인 프로세스를 거치도록 되어 있는데, 애초에 그것이 필요한 것인지 테스트 중입니다.

기사에는 태그를 달 수 있게 되어 있는데, 이는 researcher

가 기사를 작성할 때마다 달고 있습니다. 그러다 보면 미묘한 표기 불일치나 고유명사 표기 방식에 따라 고립된 태그가 많이 생깁니다. 이것들을 정리하고 통합하는 것이 이 에이전트의 역할입니다. 주 1회, 월요일 아침 5시에 가동됩니다. 너무 자주 수행할 필요는 없기 때문입니다.

개별 사례에 대한 조사 사이클이 돌아가며 기사가 쌓이다 보면, 그것들을 정리한 종합 기사가 필요할 때가 있습니다. 예를 들어, 에이전트 하네스(Agent Harness)에 관한 기사가 "Claude Code", "Codex", "OpenCode", "Hermes Agent" 등으로 나뉘어 있다면, 이것들을 전부 통합하여 "AI 코딩 에이전트에 대하여"라는 기사를 쓰는 것이 이 에이전트의 업무입니다. 이 에이전트만큼은 다른 에이전트보다 성능이 높은 모델을 사용하도록 설정했습니다. 매일 23시에 지식 베이스 전체를 체크하여 유사 기사를 통합하고, 원본 기사는 아카이브로 보냅니다.

어떤 신비한 힘으로 기사를 합체시키는 모양입니다.

매일 아침 7:00에 어제의 지식 베이스 활동을 일보(Daily Report)로 정리합니다.

어느 정도 지식이 쌓이면 매일 대량의 기사가 생성되고, 합성되며, 아카이브되어 가기 때문에 전부 추적하려고 하면 매우 힘듭니다. 이 에이전트는 그것을 돕는 것이 목적입니다.

그런데 그 창문은 어떻게 된 거야?

기사에는 「좋아요」 버튼이나 댓글로 피드백을 줄 수 있는 메커니즘을 마련해 두었습니다. 이 에이전트는 「좋아요」가 눌린 기사의 경향이나 댓글 피드백 내용을 분석하여 「집필 인사이트 (Writing Insight)」를 설정합니다.

집필 인사이트는 기사를 집필하는 각 에이전트의 시스템 프롬프트 (System Prompt)에 반영되며, 이는 더 「좋아요」를 받기 쉬운(=요구되는) 기사가 작성되도록 하는 것이 목적입니다.

예를 들어, 「좋아요를 많이 받는 기사에는 유사 프레임워크와의 비교표가 포함되어 있다」와 같은 공통점을 찾아내어 다음 집필에 그 지견을 활용해 주는 방식입니다.

내부적으로 기사는 Markdown 텍스트로 저장합니다. 매일 1회, 기사, SQLite 데이터베이스, Hermes가 자기 개선(Self-improvement)한 스킬을 모아서 백업합니다. 현재는 백업에 GitHub 리포지토리 (Repository)를 설정할 수 있으며, 빈 리포지토리와 액세스 토큰 (Access Token)을 설정하면 매일 push 합니다.

이 아이에 관해서는 담당 작업이 고립되어 있어 굳이 에이전트로 만들 필요는 없었지만, 왠지 모르게….

창고에 넣어두는 걸까.

이 녀석은 실제로는 에이전트가 아니지만, MCP 도구 (MCP Tool) 호출이나 WebUI로부터의 중요 이벤트 감사 로그 (Audit Log)를 표시하면 재미있을 것 같아 시각화(Visualize)하고 있습니다. 대체로 태스크 큐 (Task Queue)를 건드리고 있습니다. 특히 타누키(Tanuki)와 무사사비(Musasabi)가 가동된 후에 격렬한 큐잉 (Queuing)이 일어납니다. 후쿠로우(Fukuro) 씨가 불쌍하잖아요. 그만해…….

에이전트 설정은 이것저것 만들면서 늘어난 부분도 있지만, 몇 가지 상호작용을 의식하여 설정하고 있습니다.

지식을

생성하기:daily_research (새로운 토픽을 포착), researcher (기사를 작성), gap_detector (망라함) -
유지/버리기:freshness_checker (오래된 것을 감지하여 재조사, 더 이상 읽히지 않는 기사는 아카이브), taxonomy_builder (태그의 질서를 유지), reviser (사용자의 요청으로 기사를 편집), feedback_analyst (피드백 분석으로 새로운 기사의 질을 향상) -
통합하기:synthesizer (파편을 상위 개념으로 통합) -
보여주기:dialogue (사람과의 접점), changelog_writer (활동의 가시화)

라는 사이클입니다. 지식(Knowledge)이 충실해지면 사용자도 「그럼 이건 어떨까?」라는 의욕이 생겨나고, 지식은 더욱 충실해집니다. 그리고 오래되어 잊힌 정보는 노이즈가 되므로 아카이브화하여 격리합니다. 그렇게 하면 지식 베이스 (Knowledge Base)가 부패하지 않고 성숙할 수 있지 않을까 하는 가설입니다.

이 하나의 커다란 흐름 안에 세세한 상호작용이 있습니다. 예를 들어,

researcher ↔︎ gap_detector : 리서치 결과로부터 갭(Gap) 감지, 그 조사를 기점으로 다시 갭 감지 -
taxonomy_builder ↔︎ freshness_checker : 태그가 정리됨으로써 사용자가 접근하기 쉬워져 유용한 기사는 아카이브화가 늦어지는 반면, 그럼에도 접근되지 않는 기사는 즉, 버려야 할 지식이라는 것 - 사용자 → feedback_analyst ⇒ 집필 에이전트: 사용자가 댓글이나 「좋아요」를 남기면 이를 바탕으로 집필 인사이트가 업데이트되고, 집필 계열 에이전트는 기사의 질을 더욱 향상시킴

등등.

이 시스템에서의 각 에이전트는 서로의 존재를 모릅니다. gap_detector는 researcher를 모르고, synthesizer가 researcher를 직접 호출하는 일도 없습니다. 후술하듯, 연계는 모두 큐 (Queue)와 기사를 통해 간접적으로 이루어집니다. 이 부분이 Minakata 설계의 핵심입니다.

태스크 큐는 @minakata/core의 TaskService (SQLite의 tasks 테이블)로 구현되어 있습니다. 이것이 모든 에이전트의 구동 장치입니다.

enqueue (투입)와 poll (소화)이 비동기적으로 분리되어 있는 것이 포인트입니다. dialogue가 조사 요청을 받았을 때, researcher를 동기적으로 호출하여 결과를 기다리는 식의 동작은 하지 않습니다. enqueue_task로 큐에 쌓기만 하고 즉시 사용자에게 「조사 태스크를 추가했습니다」라고 응답합니다. researcher

는 자신의 페이스(5분 주기)로 큐(Queue)를 가져와 처리합니다.

이 큐에는 분산 큐(Distributed Queue)에 필요한 성질들이 일련의 방식으로 구현되어 있습니다.

우선순위가 있는 FIFO (First-In-First-Out): urgent (대화 기반의 즉시 조사) > interactive (댓글 추적 조사) > scheduled (일간 배치) > maintenance (gap / synthesis의 가교 역할) 순입니다. 사용자의 요청은 정례 처리보다 우선하여 처리되므로, 무사사비(flying squirrel)나 너구리가 대량의 조사 큐를 밀어 넣더라도 사용자가 채팅을 통해 요청하면 중간에 끼어들 수 있습니다 -
타입 (type) 라우팅: poll_tasks({ types: [...] })를 통해 자신이 처리해야 할 종류만 claim 합니다. researcher는 research / refresh / daily_research / research_followup을, dialogue는 notify_chat 태스크를 가져와 처리합니다 -
멱등성 (Idempotency, dedup_key): 동일한 요청이 중복 투입되는 것을 dedup_key의 UNIQUE 제약 조건으로 방지합니다. 활성화된 동일 키(key) 태스크가 있으면 기존 행을 반환하고, 완료된 상태라면 키를 해제하여 재투입을 허용합니다 -
지수 백오프 (Exponential Backoff)와 DLQ (Dead Letter Queue): 실패 시 30 * 2^(attempts-1)초 후에 재큐(re-queue) 합니다. 3회를 초과하면 Dead Letter Queue로 떨어뜨리며, changelog_writer가 일일 보고서에서 list_dlq를 집계합니다.

dedup_key를 부여하는 방식에는 에이전트마다의 철학이 담겨 있습니다.

daily_research: daily:<topic_id>:<YYYY-MM-DD>:<slug> — 날짜를 포함합니다. 동일한 토픽의 동일한 발견을 하루에 두 번 투입하지는 않지만, 다음 날은 별개의 키가 되므로 재스캔(re-scan)할 수 있습니다 -
gap_detector: gap:<slug>:<YYYY-MM-DD> — 위와 동일합니다. 같은 구멍을 같은 날에 두 번 파지 않습니다 -
synthesizer: synth-research:<cluster-key>:<topic-slug> — 의도적으로 날짜를 포함하지 않습니다. 가교 조사의 요청은 "아직 충족되지 않은 영구적인 요구"이므로, 매일 실행되더라도 동일한 요청을 중복 투입하고 싶지 않기 때문입니다.

이 "날짜를 포함할 것인가 말 것인가"의 판단이 각각의 에이전트가 가진 시간적 성질(매일 새로 시작하는지, 충족될 때까지 지속되는지)을 표현합니다.

synthesizer는 SKILL.md에 의해 **스테이트리스 (Stateless)**임이 강제됩니다.

이 에이전트는 상태를 가지지 않습니다. "지난번에 어떤 클러스터(cluster)를 처리했는지", "어떤 조사를 요청했는지"를 기억하지 않습니다. 상태는 기사 컬렉션(article collection) 자체가 가집니다.

synthesizer의 역할은 similar_articles의 코사인 유사도(cosine similarity)를 통해 의미적으로 가까운 기사 클러스터(상호 KNN에 포함된 3개 이상의 기사)를 탐지하고, 이를 묶어주는 상위 개념의 통합 기사를 생성하는 것입니다. 그런데 클러스터를 묶어주는 핵심 개념의 기사가 누락되어 있으면, 통합하더라도 "파편의 모음"이 되어 버립니다.

이때 synthesizer는 추가 정보를 수집하고 싶어 하지만, 당연히 researcher를 동기적(synchronous)으로 호출하여 조사를 시키지는 않습니다.

재료가 부족한 클러스터를 발견하면,
delegate_task와 같은 동기 호출은 사용하지 않고,
가교 역할에 필요한 토픽을 enqueue_task(type:"research")로 요청할 뿐.
...

그 후 researcher가 조사 요청을 실행하여 기사를 만들어 두면, 다음 날 synthesizer가 구동될 때 클러스터로 자연스럽게 편입되어 통합 작업이 진전됩니다. synthesizer는 매일 밤 완전히 새로운 상태로 구동되며, 이전 작업의 연속이 아니라 "현재 기사 컬렉션이 어떤 상태인가"만을 보고 판단합니다.

이 설계의 장점은 에이전트를 **순수 함수 (Pure Function)**에 가깝게 만들 수 있다는 점입니다.

재진입 가능 (Re-entrant): synthesizer는 언제, 몇 번을 구동해도 망가지지 않습니다. 도중에 컨테이너가 죽어서 재시작되더라도 "기사 컬렉션의 현재 상태"로부터 재계산할 뿐이므로, 중단 및 재개를 위한 특별한 처리가 필요 없습니다 -
느슨한 결합 (Loose Coupling): synthesizer와 researcher

는 코드상으로나 실행상으로나 서로를 알지 못합니다. 양자를 잇는 것은 「태스크 큐(Task Queue)에 쌓인 의뢰」와 「기사 컬렉션(Article Collection)에 나타난 성과」뿐입니다. researcher를 다른 구현으로 교체하더라도, synthesizer는 「가교 역할을 하는 기사가 나타났는지 여부」만을 보고 있기 때문에 영향을 받지 않습니다 - 느슨한 결합 (Loose Coupling) 덕분에 에이전트를 부담 없이 늘릴 수 있었고, 정신을 차려보니 11체나 있었습니다.

「큐와 기사만으로 연결한다」 패턴은 synthesizer뿐만 아니라 시스템 전체가 그렇게 구성되어 있습니다.

: 사용자의 조사 의뢰는 dialogue ↔︎ researcher enqueue_task를 통해 던집니다. 조사 완료 통지는 반대로 researcher가 notify_chat 태스크를 쌓음으로써 dialogue가 가져갑니다. dialogue는 researcher의 완료를 기다리고 있지 않으며, 자신의 처리 시작 시점에 완료 통지가 들어와 있다면 그것을 처리할 뿐입니다 -
: 지식 그래프 (Knowledge Graph)의 빈틈을 탐지하여 gap_detector → researcher research 태스크를 쌓습니다. 빈틈이 채워졌는지는 다음 실행 시 fulltext_search로 재확인하며, 채워져 있다면 자연스럽게 대상에서 제외됩니다. gap_detector가 「researcher가 조사했는지」를 알 필요는 없는 것입니다 -
: 오래된 기사에 freshness_checker → researcher refresh 태스크를 쌓습니다. 재조사가 완료되었는지는 last_researched_at을 보면 알 수 있으므로, 이 또한 freshness_checker가 「researcher가 조사했는지」를 알 필요가 없습니다 -
:daily_research → researcher daily_research는 researcher가 자신이 쌓은 태스크를 처리했는지 여부를 일절 관여하지 않습니다. 그저 묵묵히, 밤마다 태스크를 쌓을 뿐입니다.

역시 researcher는 과로하는 것 아닌가요?

시야를 조금 더 넓혀서 보면, 이 에이전트들은 「기사라는 상태 (State)에 대한 전이 함수 (Transition Function)」의 집합으로 정리할 수 있습니다.

researcher는 「조사 태스크 → 기사를 생성 / 추가」 전이 -
freshness_checker는 「시간 경과 → 오래된 기사를 재조사 큐로 되돌림」 전이 -
synthesizer는 「유사한 기사 집합 → 통합 기사 + 원본 기사 아카이브」 전이 -
gap_detector는 「기사군 → 빈틈을 찾아 조사 태스크를 쌓음」 전이

그리고 Hermes가 cron job으로 이것들을 정기적으로 돌리고 있기 때문에, 시스템 전체로 보면 **스케줄에 의해 구동되는 거대한 리듀서 함수 (Reducer Function)**처럼 파악할 수도 있습니다. state = reduce(state, agents)를 매일 끊임없이 돌리고 있는 셈입니다.

freshness_checker나 synthesizer처럼 새로운 입력이 없어도 상태에 작용하는 에이전트가 있다는 점도 포인트입니다.

이 시스템에서는 아무도 의뢰를 내지 않아도, 오래된 기사는 신선도가 떨어져 재조사되고, 유사한 기사가 늘어나면 알아서 통합되며, 언급만 된 실체 없는 토픽에는 기사가 생겨납니다. 이것이 제가 지향한, **내버려 두어도 스스로 성장하는 (그리고 부패하기 전에 정리되는) 지식 베이스 (Knowledge Base)**의 모습입니다.

직접 도그푸딩 (Dogfooding)을 하고 있습니다만, 사용하면서 꽤 즐겁습니다.

• 지식이 저절로 자라나가는 감각은 체감상 상당히 큽니다. 오늘 아침 일어났더니 「Claude Fable 5 완전 해설: Anthropic 첫 Mythos 클래스 공개 모델의 성능·요금·안전 메커니즘」이라는 기사가 만들어져 있었고, 그것을 통해 Fable 5의 출시를 알게 되었습니다 - 에이전트 간의 상호 호출을 그만두고 기사와 큐로 연결하는 방침을 택한 것은 잘한 일이라고 생각합니다. 에이전트의 복잡한 상호작용을 관리하는 것은 매우 힘들며, 하물며 거기에 「에이전트별 기억」 같은 것이 얽히기 시작하면 더 이상 예측이 불가능해집니다.

synthesizer는 꽤 흥미로운데, 프레임워크 관련 기사가 여러 개 생기면 그 비교 기사나 유스케이스 (Use Case)의 적합성 등을 정리한 기사를 만듭니다. 모르는 프레임워크를 gap_detector

가 찾아내어 슬쩍 비교표에 포함시키기도 합니다. 인간이 직접 쓸 수 없는 부분이라는 점은 의외로 신경 쓰이지 않았습니다.

researcher가 조사와 기사 작성을 담당함으로써 기사의 입도(Granularity)가 일정하게 유지되며, 애초에 수정하라는 지시를 별로 하지 않습니다. 러닝 코스트 (Running Cost)는 구독 토픽 5개를 24시간 * 2주 동안 운용했을 때, OpenCode Go 월간 사용량의 약 20% 정도로 수렴하고 있습니다. 2026년 6월 현재 상황 기준이며, 구독 범위 내에서 비교적 원활하게 돌릴 수 있다는 느낌입니다.

"조직의 정보 수집 및 지식 평준화"라는 과제에 대해, AI 에이전트 군단이 지식을 키우도록 하는 접근 방식을 시도해 본 이야기였습니다.

설계의 핵심은 다음 세 가지라고 생각합니다.

에이전트끼리 직접 호출하지 않음: 연계는 모두 태스크 큐 (Task Queue)와 기사 컬렉션 (Article Collection)을 통해 간접적으로 수행함
기사 컬렉션이 상태 (State)임: 각 에이전트는 "현재 기사의 상태"만을 보고 판단하는, 재진입 가능한 전이 함수 (Reentrant Transition Function)가 됨
지식의 라이프사이클에 따라 역할을 분담함: 생성하기 · 유지/폐기하기 · 정리하기 · 보여주기, 이 사이클이 계속 돌아감으로써 지식 베이스 (Knowledge Base)가 부패하지 않고 성숙해감

구현을 진행할수록 에이전트가 점점 함수처럼 보이기 시작했습니다.

아직 "사용자가 지식을 투입하는" 스토리가 미구현 상태라거나, researcher의 과로 문제, 아카이브 승인 프로세스의 필요성 여부, 기사 동시 편집 문제 등 시행착오를 거쳐야 할 부분은 많이 남아 있습니다. 그렇기는 하지만, 아침에 일어났을 때 모르는 릴리스 정보 기사가 새로 생겨 있는 경험은 꽤 신선하기 때문에, 앞으로도 꾸준히 조금씩 키워나가 보려고 합니다.

비슷한 시도를 하고 계신 분이 있다면, 꼭 지식을 나누어 주시면 감사하겠습니다.