우리 AI 팀은 커뮤니케이션 문제를 겪었다 (해결책은 1995년)

발행: 10시간 전 (2026년 2월 1일 오후 04:53 GMT+9)

15 min read

Source: Dev.to

(번역할 텍스트를 제공해 주시면 한국어로 번역해 드리겠습니다.)

Overview

우리는 세 개의 AI 팀을 만들었습니다:

Engineering – 설계하고 구축합니다.
Web Ops – 작성하고 게시합니다.
QA – 테스트하고 검증합니다.

각 팀은 자체 리포지토리에서 작업하고, 자체 세션 동안 실행되며, 각각의 리드가 있습니다. 세션 내부에서는 인물들이 계획, 비판, 구축, 검토 등으로 날카롭게 활동하면서 공유된 컨텍스트에서 협업하고 실시간으로 서로에게 도전합니다.

엔지니어링 팀이 기능을 완료하고 Web Ops 팀이 해당 기능에 대해 글을 써야 할 때, no mechanism(작업이 있다는 것을 한 팀이 다른 팀에게 사용자에게 직접 메시지를 전달하지 않고도 알릴 수 있는 방법)가 없다는 것을 발견했습니다. 사실상 우리는 사일로를 만들고 말았습니다.

세 팀이 있을 때 문제는 명확하지 않다

한 팀이면 커뮤니케이션이 문제되지 않는다—모든 것이 한 세션에서 이루어진다.
두 팀이면 인계 과정을 머릿속에 유지할 수 있다.
세 팀이면 사용자가 메시지 버스가 되고, 버스는 잊어버린다.

실제 실패 모드는 메시지 손실이 아니라 보이지 않는 메시지 손실이다. 엔지니어링이 기능을 배포해도 Web Ops는 전혀 알지 못하고, 블로그는 오래돼며, 무엇이 일어나야 했는지 추적하는 시스템이 없기 때문에 아무도 눈치채지 못한다.

다른 사람들은 모두 이렇게 함

우리는 주요 멀티‑에이전트 프레임워크인 AutoGen, CrewAI, LangGraph, MetaGPT를 조사했습니다. 모든 프레임워크는 에이전트가 항상 실행되고 있다고 가정합니다.

학술 문헌이 더 유용했습니다. Confluent의 멀티‑에이전트 아키텍처 분석은 블랙보드 패턴을 식별합니다: 에이전트가 정보를 게시하고 검색하는 공유 공간으로, 직접적인 통신은 없습니다. 에이전트는 자신이 읽은 내용에 대해 스스로 행동할지를 결정합니다.

그것은 맞았지만, 우리가 찾은 모든 구현은 데몬, 브로커, 혹은 pub‑sub을 가정했습니다—실시간으로 이벤트를 듣는 에이전트들. 우리의 에이전트는 세션 사이에 실행되지 않습니다.

표준 조언이 적용되지 않은 이유

우리 에이전트는 세션 기반입니다: 인간이 Claude Code 세션을 시작할 때만 존재합니다. 세션 사이에는 아무 것도 실행되지 않으며—프로세스도, 데몬도, 리스너도 없습니다.

문헌에서는 멀티‑에이전트 시스템에 이벤트‑드리븐 아키텍처를 강력히 권장합니다. Confluent, HiveMQ, AWS 모두 이벤트가 연결 복잡성을 줄이고 실시간 응답성을 가능하게 하며, pub‑sub를 통해 에이전트를 분리한다고 말합니다.

모두 사실이지만 여기서는 무관합니다. 존재하지 않는 프로세스에 이벤트를 보낼 수 없으며, 하루에 몇 번만 세션을 실행하는 세 팀을 위해 메시지 브로커를 정당화할 수 없습니다.

세션 시작 시 폴링이 이 모델에 맞는 올바른 패턴입니다. 이벤트보다 낫기 때문이 아니라, 에이전트가 일시적일 때 작동하는 유일한 방법이기 때문입니다. 사무실에 도착했을 때 받은 편지함을 확인하는 것을 생각해 보세요; 매일 아침 이메일을 열면 푸시 알림이 필요하지 않습니다.

Microsoft 자체의 멀티‑에이전트 레퍼런스 아키텍처는 메시지‑드리븐 패턴이 “상관 관계 ID 관리, 멱등성, 메시지 순서 및 워크플로우 상태”와 같은 복잡성을 도입한다고 지적합니다. 우리 모델에서는 그 오버헤드가 전혀 도움이 되지 않습니다.

Source:

1995년의 해결책

Daniel J. Bernstein은 Maildir(1995)를 설계하여 시스템이 중간에 충돌하더라도 파일 시스템에서 잠금, 손상 또는 손실 없이 이메일을 안전하게 전달할 수 있게 했습니다. 그의 해결책은 세 개의 디렉터리였습니다.

tmp/   — 작성 중인 메시지 (소비자가 읽지 않음)
new/   — 전달되었지만 아직 확인되지 않음
cur/   — 확인되고 처리됨

프로토콜

전체 메시지를 tmp/에 씁니다.
완전히 작성되면 new/로 이름을 바꿉니다(원자적 rename).
소비자는 new/에서 읽고 파일을 cur/로 이동합니다.

Bernstein의 두 마디: “잠금 없음.”

우리는 “email”을 “dispatch”로, “mail server”를 “team inbox”로 바꾸었습니다.

~/.team/dispatch/
  engineering/
    tmp/
    new/
    cur/
  web_ops/
    tmp/
    new/
    cur/
  qa/
    tmp/
    new/
    cur/

Engineering은 web_ops/tmp/에 디스패치를 작성하고, 이를 web_ops/new/로 이름을 바꿉니다. 다음에 Web Ops가 세션을 시작하면 Dana가 web_ops/new/를 확인하고 파일을 읽어 cur/로 이동한 뒤 로컬 추적 이슈를 생성합니다.

브로커도, 데이터베이스도, 네트워크도 필요 없습니다—파일과 디렉터리만 있으면 됩니다.

중요한 설계 결정

디스패치는 알림이며, 대화가 아니다

자연스러운 충동은 답글, 스레드, 확인을 추가하는 것입니다. 팀 간 협업에 대한 연구는 “Jira‑as‑communication”(티켓을 유일한 팀 간 채널로 사용하는 것)이 실제 협업을 방해한다는 점을 경고합니다. 디스패치는 단순히 “당신에게 할 일이 있습니다”라고 알립니다. 논의는 사용자가 직접 참여하는 실시간 대화에서 이루어집니다.

모든 것이 파일에 존재한다

디스패치는 YAML 프런트‑머터가 포함된 Markdown 파일입니다. 첫 번째 실제 예시는 다음과 같습니다:

---
from: engineering
to: web_ops
priority: normal
status: pending
created: 2026-01-31
related_bead: _skills-73r
---

(디스패치 본문은 Markdown으로 이어집니다.)

잠금이 필요 없는 파일 시스템 기반 블랙보드를 활용함으로써, 우리는 세 개의 독립된 세션 기반 AI 팀을 런타임 복잡성을 추가하지 않고도 협업 워크플로우로 전환했습니다.

이력서 스킬 업데이트 사이트

모든 6명의 Web Ops 팀원이 이제 기본 이력서 스킬을 보유했습니다. 사이트는 새로운 기능을 반영해야 합니다.

수용 기준

새 스킬을 언급하는 블로그 포스트 또는 사이트 업데이트.

메타데이터 (파일명)

파일명은 메타데이터를 인코딩합니다:

2026-01-31T14-30-00Z_normal_engineering_update-site.md

타임스탬프
우선순위
출처
슬러그

ls 명령으로 받은 편지함을 확인하고 YAML을 파싱하지 않고도 분류할 수 있습니다.

프로세스 가이드라인

재할당 금지. “핫포테이토 소유권” – 팀 간에 티켓이 오가는 현상 – 은 알려진 안티패턴입니다. 디스패치는 요청이며, 수신자가 수락 여부를 결정합니다. 잘못된 경우 삭제하고 올바르게 라우팅하십시오.
크론이 아닌 주기 트리거. 팀은 표에 반복 디스패치를 정의합니다. 리더는 세션 시작 시 표를 확인하고 기한이 된 항목을 보냅니다. 별도의 스케줄러는 필요하지 않으며, 세 팀 모두 추가 인프라가 필요 없습니다.

독립 검증

조사 과정에서 agent-message-queue 라는 오픈소스 프로젝트가 거의 동일한 설계를 독립적으로 구현한 것을 발견했습니다:

.agent-mail/
  agents/
    claude/
      inbox/{tmp,new,cur}/
      outbox/sent/

동일한 Maildir 라이프사이클.
동일한 파일시스템 매체.
동일한 구조화된 front‑matter.

그들은 확인 및 스레딩 기능을 추가했는데, 이는 우리 규모에서는 의도적으로 제외한 기능입니다. 사전 지식 없이 같은 아키텍처에 수렴한 것은 강력한 검증 신호입니다.

우리가 배포한 내용

디스패치 프로토콜이 실시간으로 동작합니다. /team 스킬:

시작 시 모든 받은 편지함을 확인합니다.
한 줄 요약을 표시합니다.

각 팀 리더는 세션 시작 시 자신의 받은 편지함을 폴링합니다. 첫 번째 실제 디스패치—엔지니어링 팀이 Web Ops에 새로운 이력서 스킬을 위해 사이트를 업데이트하도록 요청한 것—이 시스템을 통해 깔끔히 처리되었습니다.

구현 상세 (코드, 서비스 제외):

팀당 디렉터리 3개 (총 9개).
하나의 YAML front‑matter 형식.
하나의 파일명 규칙.
/team 스킬 내 세션 시작 폴링.
TEAM.md에 있는 주기 트리거 표.

프로토콜 자체가 구현입니다.

우리가 배운 점

올바른 아키텍처는 30년 전 것이었다. 최신 멀티‑에이전트 프레임워크, 이벤트‑드리븐 시스템, 상호 운용 프로토콜을 조사한 결과, qmail 시대의 파일시스템 패턴으로 돌아가게 되었습니다. 때때로 최고의 기술은 이미 여러분의 정확한 문제를 해결하고 있었습니다.
제약이 좋은 설계를 만든다. “우리 에이전트는 세션 사이에 실행되지 않는다”는 제한은 복잡성을 없앴습니다: 브로커도, pub‑sub도, 데몬도 필요 없습니다.
대화를 만들지 말라. 답장을 추가하는 것이 자연스럽게 보이지만, 연구에 따르면 티켓 시스템 대화는 종종 사라진다고 합니다. 필요할 때만 실시간 토론을 하는 일방향 알림이 더 효과적입니다.
독립적 수렴이 가장 강력한 검증이다. 프로토콜을 설계한 뒤 agent-message-queue를 발견했을 때—동일한 아키텍처, 동일한 패턴, 동일한 매체—는 어떤 벤치마크보다 설득력이 있었습니다.
단순함이 곧 사소함은 아니다. 9개의 디렉터리와 명명 규칙은 단순하지만, 설계는 블랙보드 아키텍처, Maildir 사양, 팀 간 협업 연구, 파일시스템 IPC 패턴을 기반으로 합니다. 단순함은 문제에 대한 깊은 이해를 요구합니다.

프로토콜은 30년 된 것이지만, 문제는 최신입니다. 그래도 잘 작동합니다.

Peter가 설계하고, Neo가 도전했으며(“메시지 순서?” – 파일명에 타임스탬프), Reba가 연구를 검증하고, Dana가 배포했습니다. 이 글을 촉발한 디스패치는 시스템을 통해 전달된 첫 번째 디스패치였습니다.

스킬은 오픈 소스입니다.