※이 기사는 Zenn(https://zenn.dev/kimshoshi/articles/obsidian-multi-agent-orchestration)에서 전재되었습니다.

ChatGPT나 Claude에게 질문하여 답을 얻는다. 그것은 「채팅」이며, AI를 입력→출력의 함수로서 사용하고 있는 상태다.

하지만 실제 업무에는 다음과 같은 과제가 있다.

• 대화가 끝나면 문맥이 사라진다 (스테이트리스 (Stateless))
• 하나의 모델에 모든 것을 맡기면, 잘하는 것과 못하는 것의 벽에 부딪힌다
• 「AI가 낸 답」을 다음 AI에게 전달하는 가교 역할을 인간이 수동으로 하고 있다
• 자동화하려고 하면 「어디에 무엇이 적혀 있는지」의 관리가 붕괴한다

이것들을 해결하는 것이 **멀티 에이전트 오케스트레이션 (Multi-agent Orchestration)**이다. 본고에서는 Obsidian이라는 Markdown 기반의 노트 앱을 SSoT (Single Source of Truth)로 사용하여, 여러 AI에게 역할을 분담시키는 설계를 기술적으로 해설한다.

┌─────────────────────────────────────────┐
│ Obsidian Vault（SSoT） │
│ ┌──────────────────────────────────┐ │
...

포인트: 각 AI는 직접 통신하지 않는다. 모두가 Obsidian vault를 경유하여 주고받는다. 이것이 파일 기반 IPC의 핵심이다.

여러 LLM 에이전트가 각각 다른 **역할·권한·컨텍스트 (Context)**를 가지고, 협력하여 하나의 워크플로우를 실행하는 설계 패턴.

우려 사항	단일 모델	멀티 에이전트
컨텍스트 윈도우 (Context Window)	장대한 대화로 인해 고갈된다	태스크 단위로 분할하기 때문에 각 에이전트의 컨텍스트가 작다
...

Claude Opus ── 기획·판단·최종 승인 (사령탑)
Claude Sonnet── 문장 생성·정형·SNS 문구 (실행층)
Codex CLI ── 코드 구현·파일 일괄 처리 (구현층)
...

서로 다른 프로세스 간에 데이터를 주고받는 메커니즘의 총칭. 통상적으로는 소켓 통신이나 메시지 큐 (RabbitMQ 등)가 사용되지만, 본 구성에서는 Markdown 파일이 메시지 큐의 역할을 담당한다.

• 인간과 AI 모두가 읽고 쓸 수 있다
• 버전 관리 (iCloud 동기화)를 기본적으로 사용할 수 있다
• Obsidian이 실시간으로 렌더링하기 때문에, 인간이 모니터링하기 쉽다
• API가 필요 없다 (파일 I/O만으로 완결된다)

---
작성일: 2026-06-27
의뢰처: Sonnet
...

상태

필드가 유한 상태 기계 (FSM: Finite State Machine) 의 state로서 기능한다.

미착수 → 진행 중 → 확인 대기 → 완료
↓
보류 / 반려

각 에이전트는 자신이 담당하는 state의 파일만을 처리한다. 이를 통해 레이스 컨디션 (Race Condition, 경합 상태)을 방지하면서 느슨한 결합 (Loose Coupling)을 유지할 수 있다.

AI를 여러 개 사용하기 시작하면, 「어떤 AI가 최신 지시를 가지고 있는지」 알 수 없게 된다. ChatGPT의 대화, Claude의 대화, Notion 페이지, Slack 메시지── 정보가 분산되어 모순이 발생한다.

규칙은 Obsidian에 있다 → AI는 vault를 읽고 움직인다 → 업데이트도 vault에 쓴다

구체적으로는:

• 운영 규칙: AI会話ログ/Claude/memory/

다음 md 파일 -

• 태스크 관리: 🏠1.home/AIタスク/

다음 md 파일 -

• 제작물: 📋2.実務/

다음 각 폴더

어떤 AI도 대화를 시작하기 전에 vault의 관련 파일을 읽는다라는 규약을 지킴으로써, 모든 에이전트가 동일한 문맥을 갖는다.

macOS의 launchd를 스케줄러로 사용하여, 정기 실행으로 AI 워크플로우를 트리거한다.

<!-- ~/Library/LaunchAgents/com.businesshub.x-post.plist -->
<key>StartInterval</key>
<integer>900</integer> <!-- 15분마다 실행 -->
...

1. SNS 운영/X 게시물/ 을 readdirSync()로 스캔
2. /^\d{4}-\d{2}-\d{2}_.+\.md$/ 에 매칭되는 파일을 추출
3. frontmatter를 파싱하여 상태: 승인됨인 것만 대상으로 한정
   ...

포인트: AI는 파일을 쓰기만 하면 된다. "언제 실행할 것인가"의 판단을 launchd에 위임함으로써, AI의 컨텍스트에 스케줄링 로직을 포함시키지 않아도 된다 (관심사의 분리 (Separation of Concerns)).

Markdown은 본래 인간이 읽는 문서 포맷이다. 하지만 YAML frontmatter를 사용함으로써, **기계 가독성 메타데이터 계층 (Machine-readable metadata layer)**을 Markdown 위에 겹칠 수 있다.

---
상태: 승인됨 # FSM의 state
의뢰처: Sonnet # 라우팅 키
...

이는 REST의 HTTP 헤더, 메시지 큐의 메타데이터, gRPC의 메시지 정의와 동일한 역할을 수행한다. Markdown 본문이 페이로드 (Payload), frontmatter가 **엔벨로프 (Envelope)**다.

관점	채팅	본 구성
상태 관리	스테이트리스 (Stateless, 대화가 끝나면 사라짐)	스테이트풀 (Stateful, 파일에 영속화)
확장성 (Scalability)	인간이 병목 현상 발생	launchd가 자율 실행하므로 인간 없이도 작동
모델 선택	하나의 모델에 의존	태스크 특성에 따라 모델을 동적으로 선택
에러 복구	인간이 인지하고 재실행	실패 로그를 파일에 기록, 다음 실행 시 다시 확인
감사 가능성 (Auditability)	대화 로그가 산재함	vault 내의 md 파일에 모든 이력이 집약됨
컨텍스트 공유	동일 대화 내에서만 가능	모든 에이전트가 vault를 통해 동일한 컨텍스트를 참조
인간의 개입 지점	모든 단계	상태: 승인됨을 누르기만 하면 됨 (게이트 제어)

기술	용도
YAML frontmatter 파싱	js-yaml (Node.js) / yaml (Ruby)
파일 워치 / 폴링 (Polling)	fs.readdirSync + launchd
OAuth 2.0 PKCE	X API 인증
REST API 클라이언트	fetch (Node.js 18+)
ISO 8601 일시 파싱	new Date() / Date.parse()

기술	용도
launchd (macOS) or systemd (Linux)	이벤트 드리븐 (Event-driven) 스케줄링
...

• Docker (로컬 스크립트로 완결되기 때문에)

• 데이터베이스 (frontmatter가 KV 스토어의 대안이 됨)

• 웹 서버 (푸시 방식이 아닌 폴링 설계이기 때문에)

• 진입 장벽이 낮음: Markdown과 YAML 지식만으로 시작할 수 있음 -

• 관찰 가능성 (Observability)이 높음: Obsidian을 열면 모든 에이전트의 상태를 한눈에 파악할 수 있음 -

• 변경 비용이 낮음: 규칙 변경은 md 파일을 편집하는 것만으로 충분함

• 폴링의 레이턴시 (Latency): 15분 단위 스캔이므로 즉시성이 없음 (수동 실행으로 회피 가능) -

• 동시 쓰기 경합: 여러 에이전트가 동일 파일에 동시에 쓰면 파일이 손상됨 (FSM으로 방지하지만 완전하지는 않음) -

• 스키마 관리의 어려움: YAML 구조를 코드로 강제할 수 없기 때문에, 필드명의 오타가 조용히 오류를 일으킴

Obsidian을 SSoT로 삼은 멀티 에이전트 구성은, "AI에게 묻는 것"에서 "AI를 움직이는 것"으로의 이행을 최소 비용으로 실현하는 하나의 아키텍처다.

핵심은 3가지다:

1. Markdown 파일을 메시지 큐 (IPC)로 사용한다
2. YAML frontmatter의 state 필드로 유한 상태 기계 (FSM)를 구현한다
3. launchd로 에이전트를 이벤트 드리븐 방식으로 기동한다

RAG나 벡터 DB를 사용하지 않더라도, 적절하게 설계된 파일 구조와 폴링 루프만으로 놀라울 정도로 복잡한 멀티 에이전트 워크플로우를 구동할 수 있다.

오케스트레이션 프레임워크 (LangChain, AutoGen 등)를 사용하면 더 고도화된 작업이 가능하지만, 우선 이 "파일과 YAML만으로" 구성된 설계부터 시작하면 에이전트 간 통신의 본질을 이해하기 쉽다.