AI 에이전트를 사용하여 여러 프로젝트를 병렬로 실행하면 직관에 반하는 효과가 나타납니다. 복리 효과를 내는 인프라가 없다면, 모든 실행은 제로(zero) 상태에서 시작됩니다. 메모리는 프로젝트에 국한되어 머무르고, 발견된 패턴은 전이되지 않으며, 리듬(cadence)은 전적으로 인간의 가용성에 의존하게 됩니다. 다음은 이 문제를 해결하는 인프라와 왜 규칙성(regularity)이 그 핵심 조건인지에 대한 설명입니다.

이 글에는 세 개의 실제 프로젝트가 사례로 활용됩니다: 사회 및 환경적 대안을 다루는 건설적 저널리즘 미디어 매체인 Bloomii, 프랑스 건설 계약업체를 위한 규제 관련 B2B SaaS인 Kalceo, 그리고 이 기사의 배경이 되는 에이전트 플릿(agent-fleet) R&D 프로젝트인 Ekioo입니다. 세 프로젝트 모두 AI 에이전트를 위한 칸반 오케스트레이터(kanban orchestrator)인 KittyClaw에서 운영됩니다.

오케스트레이션된 프로젝트의 구조

각 프로젝트는 네 가지 요소를 포함하는 .agents/ 디렉토리를 보유합니다:

.agents/
├── preamble.md          # 모든 에이전트 실행 시 주입되는 컨텍스트 (context)
├── automations.json     # 트리거 파이프라인 (trigger pipelines)
...

**preamble.md**는 일관성 벡터(coherence vector)입니다. 여기에는 git 워크플로우, 커밋 컨벤션(commit conventions), API 접근 권한 등 공유 규칙이 포함되어 있으며, 시작 시 모든 에이전트의 컨텍스트(context)에 주입됩니다. preamble.md에 정의된 내용은 모든 SKILL.md에서 반복할 필요가 없습니다.

**automations.json**은 파이프라인을 정의합니다. 핵심 자동화 기능인 assignee-dispatch는 티켓이 담당자가 지정된 상태로 'Todo'로 이동하는 즉시 세 가지 작업을 실행합니다:

{
  "id": "assignee-dispatch",
  "trigger": { "type": "ticketInColumn", "columns": ["Todo"] },
...

ticketCountInColumn == 0 조건은 통제되지 않는 병렬 실행을 방지합니다. 즉, 에이전트는 진행 중인 티켓이 있는 동안 새로운 티켓을 시작하지 않습니다. 마지막 작업인 commitAgentMemory는 매 실행 후 에이전트의 메모리(memory)를 자동으로 영구 저장하며, 이것이 바로 복리 효과(compounding)를 만드는 핵심입니다.

발전 도구로서의 메모리

대부분의 AI 에이전트 설정이 상태를 유지하지 않는(stateless) 상태로 남아 있는 반면, memory.md는 구조화된 영구 상태(persistent state)를 도입합니다. 각 에이전트는 각 교훈(lesson)이 몇 번이나 재적용되었는지 추적하는 [+N] 카운터가 포함된 교훈 파일을 유지합니다:

## API / tooling [+5]
- Windows에서의 curl은 JSON 바디의 UTF-8을 망가뜨립니다.
  대신 python3 urllib.request를 사용하세요. [+2]
...

이 카운터는 두 가지 기능을 수행합니다. 어떤 교훈이 가치가 있는지(반복되는지)를 보여주고, 통합(consolidation)을 안내합니다. 즉, 항목이 [5+]에 도달하면 안정적인 규칙으로서 SKILL.md로 마이그레이션됩니다. [0]인 항목은 삭제됩니다.

SKILL.md(안정적인 규칙, 거의 수정되지 않음)와 memory.md(활성 학습 내용, 매 실행마다 업데이트됨) 사이의 이러한 구분은 구조적입니다. 이는 메모리가 모든 것을 담는 잡동사니(catch-all)가 되는 것을 방지하고, 무엇을 보유할 가치가 있는지에 대한 규율을 강제합니다.

프로젝트 간 복리 효과 (Cross-Project Compounding)

에이전트는 자신의 실수로부터 배웁니다. 에이전트가 문제에 부딪히면, memory.md는 에이전트가 동일한 문제에 다시 부딪히지 않도록 보장합니다. 하지만 진정한 단계적 변화(step change)는 프로젝트들이 전체적인 역량(capabilities)을 공유하기 시작할 때 발생합니다.

공유된 이미지 생성

Bloomii의 콘텐츠 작성자(content-writer)는 삽화가 필요합니다. Ekioo의 콘텐츠 작성자는 커버 이미지가 필요합니다. 두 에이전트 모두 gpt-image-2가 어떻게 작동하는지 모르며, API 키를 관리하지도 않고, 속도 제한(rate limiting)에 대해 걱정하지도 않습니다.

중앙 워크스페이스(Workspace)에서 단일 프로세서가 10분 단위의 cron 작업으로 실행됩니다. 어떤 프로젝트의 에이전트든 image-enqueue.mjs를 통해 요청을 제출하고, ID를 돌려받은 뒤 다음 작업으로 넘어갑니다. 프로세서는 큐(queue)를 관리하며, 할당량(quota)에 도달하면 일시 중지하고 자동으로 재개합니다. 에이전트는 이미지가 준비되면 알림을 받습니다.

node C:/IA/Workspace/.agents/tools/image-enqueue.mjs \
  --prompt "..." --output path/to/cover.webp \
  --project bloomii --ticket 189

하나의 도구, 하나의 프로세서, N개의 소비자 프로젝트. 여섯 번째 프로젝트를 추가하는 데는 설정이 전혀 필요하지 않습니다. 그저 image-enqueue.mjs를 호출하기만 하면 됩니다.

Bloomii

Ekioo

Kalceo
agents

image-queue.json
single queue · cron /10min
auto rate limit

gpt-image-2
CDP processor

.webp

중앙 집중식 메일함 — 자동 디스패치

모든 프로젝트는 VizMail을 통해 노출되는 단일 메일함을 공유합니다 (40개 이상의 REST 엔드포인트를 가진 로컬 HTTP 서버). 이메일이 도착하면 — Kalceo 클라이언트 회신, Bloomii 리더 피드백, Ekioo 문의 양식 등 — 관련 프로젝트로 KittyClaw 티켓으로 자동 디스패치됩니다. 적절한 에이전트가 인간의 개입 없이 이를 처리합니다.

그 결과: 모니터링할 메일함은 하나이고, 수동 분류는 전혀 필요 없으며, 모든 프로젝트는 에이전트를 위한 실행 가능한 작업(actionable tasks)으로서 관련 이메일을 받게 됩니다.

IMAP
single mailbox
lain@ekioo.com

VizMail
classify + dispatch
→ KittyClaw ticket
per project

Kalceo
client reply → ticket

Bloomii
reader feedback → ticket

Ekioo
contact form → ticket

중앙 집중식 X 브랜딩

네 개의 프로젝트가 단일 X 계정(@LainAgent_AI)에 콘텐츠를 공급합니다. 각 프로젝트는 자체 게시 도구(x-post-tweet.mjs)를 가지고 있지만, 편집 전략은 중앙 워크스페이스의 단일 파일인 x-strategy.md에 존재합니다: 콘텐츠 기둥(content pillars), 목소리(voice), 참여 규칙(engagement rules) 등이 포함됩니다.

커뮤니티 매니저가 초안을 작성하고, lain이 승인합니다. 네 개의 가상 계정(ghost accounts)에 걸친 청중 분산이 없습니다. 단일 계정이 권위를 구축하며, 네 가지 다른 콘텐츠 소스에서 공급받습니다.

Ekioo · AI/Craft
Kalceo · BTP
Bloomii · Green
content pillars

x-strategy.md
single voice · approval
community-manager + lain

@lainagent_ai
single account · authority

Vizmail · Tooling

허브 앤 스포크 지식 기반

중앙 Workspace는 공유 인프라를 제공합니다: API 문서 (KittyClaw, Brevo, Chrome CDP), 중앙 집중식 자격 증명 (credentials), CLI 도구. 각 프로젝트는 자체적인 도메인 지식 기반 (domain knowledge base)을 유지합니다 — Kalceo를 위한 BTP 규제 및 장인들의 페인 포인트 (pain points), Bloomii를 위한 편집 연구 팩 및 배포 가이드 등입니다.

[IMG:1]

중앙 허브 — Workspace

knowledge/ · tools/ · credentials

KittyClaw API

Brevo API

Chrome CDP

[IMG:2]

스포크 (spoke) — 프로젝트 도메인

Kalceo
BTP 규제
장인 페인 포인트 (pain points) · 인용구

Bloomii
편집 기둥 (editorial pillars) · 소스
배포 팩 (distribution packs)

Ekioo · Vizmail
도메인 지식 기반 (KB) 없음
허브를 소비함

건강 신호로서의 리듬 (Cadence)

모든 프로젝트를 통틀어 주당 30개에서 50개의 티켓(ticket)이 처리됩니다. 이 수치는 생산성 목표가 아니라, 시스템의 건강 지표입니다.

프로젝트의 할 일 (Todo) 컬럼이 비워지지 않고 계속 쌓인다면, 신호는 명확합니다: 백로그 (backlog)의 우선순위 설정이 잘못되었거나, 대기 중인 작업에 적합한 에이전트 (agent)가 프로젝트에 부족하다는 것입니다. 주간 리듬 (weekly cadence)은 이러한 불균형을 즉각적으로 가시화합니다.

evaluator 에이전트는 각 티켓이 종료될 때마다 점수를 계산합니다: 초도 성공률 (first-pass success rate), 피드백 준수 여부 (feedback compliance), 전달 품질 (delivery quality). 이러한 지표들은 복리 효과 (compounding)가 실제로 작동하고 있는지를 측정합니다 — 초도 성공률이 상승한다는 것은 에이전트가 실행을 거듭할수록 개선되고 있음을 의미합니다. 정체된 성공률은 메모리 (memory)에 더 이상 데이터가 공급되지 않고 있다는 신호입니다.

정기적으로 실행되지 않는 에이전트는 사용 가능한 메모리를 축적하지 못합니다. 매번 초기화되어 동일한 실수를 반복하고, 동일한 확인 질문을 던지게 됩니다. 정기성 (regularity)은 단순히 발행을 위한 규율이 아닙니다. 그것은 시스템이 학습하기 위한 전제 조건입니다.

결론

이 인프라는 에이전트당 4개의 파일로 구성됩니다: preamble.md, automations.json, SKILL.md, memory.md. 이것을 효과적으로 만드는 것은 피딩 규율 (feeding discipline)입니다: 매 실행 후 메모리를 커밋하고 (commitAgentMemory 액션이 이를 자동으로 처리합니다), [0] 위치의 항목을 제거하며, [5+] 위치의 교훈을 SKILL.md로 승격시키십시오.

유일하게 중요한 규칙은 다음과 같습니다: 절대 2주 연속으로 거르지 마십시오. 한 번의 조용한 주는 리듬 (cadence)을 깨뜨리지 않습니다. 하지만 2주를 거르면 에이전트의 메모리, 프로젝트의 일관성 (coherence), 그리고 SEO 신호가 깨지게 됩니다.

일관성이 우선입니다. 양은 그다음입니다.