AI 에이전트에게 우체통을 만들어 주었습니다. 그 결과는 이렇습니다.

제가 시도해 본 모든 AI 에이전트 프레임워크는 동일한 문제를 가지고 있었습니다. 바로 에이전트들이 서로 대화할 수 없다는 점입니다.

엄밀히 말하면 틀린 말은 아닙니다. 그들은 오케스트레이션 레이어 (orchestration layers)를 통해 데이터를 전달하거나, 벡터 스토어 (vector stores)를 공유하거나, 도구 호출 (tool calls)을 사용할 수 있습니다. 하지만 에이전트 A가 에이전트 B가 알아야 할 무언가를 발견했을 때, 여전히 메신저 역할을 하는 것은 인간인 당신입니다. 당신은 창 사이에서 컨텍스트 (context)를 복사합니다. 출력값을 새로운 프롬프트 (prompt)에 붙여넣습니다. 당신이 이 모든 것을 하나로 묶어주는 접착제 역할을 하고 있는 것입니다.

멀티 에이전트 프레임워크 (Multi-agent frameworks)들은 이를 해결하려 노력했습니다. CrewAI, AutoGen, LangGraph 등은 모두 에이전트들을 서로 연결하는 방법을 제공합니다. 하지만 이들은 모든 에이전트를 각자의 샌드박스 (sandbox) 안에 격리시킵니다. 분리된 컨텍스트, 분리된 메모리. 한 에이전트는 다른 에이전트가 방금 구축한 것을 볼 수 없습니다.

그것은 팀이 아닙니다. 헤드폰을 쓰고 있는 사람들로 가득 찬 방일 뿐입니다.

실제로 작동했던 가장 단순한 아이디어

저는 AIPass를 구축하고 있습니다. 이는 지속적인 에이전트 워크스페이스 (persistent agent workspace)로, 기억하고 협업하며 결코 처음부터 다시 시작하지 않는 AI 에이전트들을 지향합니다. 핵심 아이디어는 에이전트가 프로젝트 디렉토리에 거주하며, 세션 사이에도 지속되고, 시간이 지남에 따라 메모리를 축적한다는 것입니다.

약 6개월 전, 저는 조정의 벽 (coordination wall)에 부딪혔습니다. 8개의 에이전트가 프로젝트의 서로 다른 부분에서 작업하고 있었습니다. 각 에이전트는 자신의 업무를 잘 수행했습니다. 하지만 그들 중 누구도 다른 에이전트가 무엇을 하고 있는지 알지 못했습니다. 한 에이전트가 다른 에이전트의 도메인에 영향을 미치는 버그를 발견했을 때, 저는 수동으로 정보를 복사하고, 새 세션을 열고, 컨텍스트를 붙여넣고, 응답을 기다려야 했습니다.

그래서 저는 제가 생각할 수 있는 가장 단순한 것을 만들었습니다. 바로 우체통 (mailbox)입니다.

모든 에이전트는 .ai_mail.local/inbox.json에 있는 JSON 수신함 (inbox)을 가집니다. 그게 전부입니다. 한 에이전트가 다른 에이전트에게 무언가를 알려줘야 할 때, 이메일을 보냅니다:

drone @ai_mail send @quality "Bug in hook loader" "The pre_edit_gate hook references src/aipass/ but this is a vera_studio project. Path needs updating."

메시지는 보낸 사람, 제목, 본문, 타임스탬프 (timestamp), 상태 (status)를 포함한 JSON 객체로서 Quality의 수신함에 도착합니다. Quality가 다음 세션에서 깨어날 때, 자신의 메일을 읽고 그에 따라 행동합니다.

공유 데이터베이스 없음. 오케스트레이션 프레임워크 (Orchestration framework) 없음. 복잡한 발행/구독 (Pub/sub) 시스템 없음. 그저 특정 이름을 수신인으로 지정하여 디렉토리에 저장된 파일들뿐입니다.

그 다음에 일어난 일

첫 일주일 동안은 제가 수동으로 에이전트 간에 메시지를 보냈습니다. 유용하긴 했지만 혁신적인 수준은 아니었습니다.

그러고 나서 저는 dispatch를 구축했습니다:

drone @ai_mail dispatch @quality "Audit draft" "이 기사 초안을 팩트 체크하세요. 정직성, 어조, 기술성이라는 3단계 품질 게이트 (Quality gate)를 실행하세요. 조사 결과를 보고하세요."

dispatch는 한 번의 명령으로 세 가지 일을 수행합니다:

1. 이메일 전송
2. 대상 에이전트 깨우기 (해당 에이전트의 디렉토리에서 새로운 Claude 세션 생성)
3. 프로세스를 모니터링할 워치독 (Watchdog) 실행

에이전트는 깨어나서 자신의 여권 (정체성)을 읽고, 자신의 기억 (세션 히스토리)을 읽고, 수신함을 확인하여 dispatch 작업을 찾아낸 뒤, 업무를 수행하고, 기억을 업데이트하고, 답장을 보냅니다. 이 모든 과정이 자율적으로 이루어집니다.

그때부터 상황이 흥미로워지기 시작했습니다.

저는 연구 작업을 5명의 에이전트에게 병렬로 dispatch하기 시작했습니다. 각 에이전트는 경쟁 환경, 어조 패턴, 커뮤니티 정서, 기술 아키텍처, 콘텐츠 전략 등 서로 다른 관점을 조사했습니다. 그들은 모두 조사 결과를 참조 문서 (Reference docs)에 남겼습니다. 오케스트레이터 (Orchestrator) 에이전트는 이 결과들을 종합하여 하나의 통합된 입장을 만들어냈습니다. 저는 이를 검토하고 피드백을 주었으며, 필요한 경우 방향을 수정했고, 우리는 다음 단계로 넘어갔습니다.

한 에이전트가 다른 에이전트의 도메인에서 버그를 발견하고 이메일로 버그 보고서를 보냈습니다. 수신 에이전트는 다음 세션에서 이를 확인하고 수정했습니다. 전달 과정에 개입한 인간은 아무도 없었습니다.

메일 시스템은 프로젝트 단위로 범위가 지정됩니다. 프로젝트 내의 에이전트들은 서로 이메일을 보낼 수 있지만, 다른 프로젝트로 dispatch할 수는 없습니다. 이는 설계 의도입니다. 각 프로젝트는 자체 에이전트를 가진 독립적인 생태계입니다.

하지만 프로젝트들이 완전히 격리된 것은 아닙니다. 버그를 보고하거나 AIPass 오케스트레이터 (orchestrator)에 직접 기능을 요청할 수 있는 별도의 피드백 채널이 존재합니다. 그리고 GitHub 이슈 (issues)는 유실되어서는 안 될 모든 사항을 위한 지속적인 경로 역할을 합니다. 오늘 제 마케팅 프로젝트는 피드백을 통해 API 팀에 dev.to 게시 드라이버 (publishing driver)를 요청했습니다. API 브랜치 (branch)의 내부 구조를 이해할 필요 없이, 필요한 사항을 설명하기만 하면 그들이 구축해 줍니다. 하지만 우체통 자체는 로컬 (local)에 머뭅니다. 당신의 에이전트들은 당신의 에이전트들과 대화합니다.

정체성 (Identity)은 어려운 문제였습니다

메시지를 보내는 것은 쉽습니다. 하지만 누가 보냈는지 아는 것은 쉽지 않습니다.

에이전트 A가 에이전트 B에게 메시지를 보낼 때, 시스템은 양측을 모두 확인(resolve)해야 합니다. 즉, "@quality"가 누구인지(그들의 편지함은 어디에 있는지?), 그리고 발신자가 누구인지(현재 내가 어느 브랜치에 있는지?)를 알아야 합니다.

라우팅 (routing) 측면은 간단했습니다. 레지스트리 (registry)가 브랜치 이름을 경로 (path)에 매핑하기 때문입니다. 하지만 발신자 감지 (sender detection)를 제대로 구현하기 위해서는 7번의 세션과 36번의 테스트가 필요했습니다.

문제는 다음과 같습니다: 에이전트들은 서로 다른 디렉토리 (directory)에서, 서로 다른 메커니즘 (직접 CLI 호출, dispatch wake, cron 데몬 등)을 통해 호출될 수 있으며, 설정된 환경 변수 (environment variables)도 제각각일 수 있습니다. 발신자 감지 체인은 우선순위에 따라 7가지의 서로 다른 방법을 시도합니다:

1. 드론 라우터 (drone router)로부터 전달된 명시적 환경 변수
2. dispatch 모니터에 의해 설정된 브랜치 이름
3. 연락처 주소록 조회
4. 이름에 의한 레지스트리 조회
5. 현재 디렉토리에서 여권 (passport)을 찾기 위해 상위 디렉토리로 탐색
6. 경로에 의한 레지스트리 조회
7. 오버라이드 (override)를 위한 명시적 --from 플래그

실제 발생했던 버그 하나를 말씀드리자면: dispatch에 의해 생성된 에이전트의 환경 변수가 잘못 설정되어, 해당 에이전트가 보내는 모든 이메일에 잘못된 발신자가 표시되었습니다. 수신자는 답장을 보낼 수 없었습니다. 답장 경로가 아무 곳도 가리키지 않았기 때문입니다. 잘못된 정체성은 침묵보다 더 나쁘기 때문에, 우리는 결국 발신자 정체성 주변에 36개의 테스트로 이루어진 요새를 구축하게 되었습니다.

무언가 잘못되었을 때를 아는 법

자율 에이전트 (Autonomous agents)가 업무를 수행한다는 것은 멋진 일처럼 들리지만, 에이전트 하나가 멈추거나, 충돌하거나, 혹은 응답이 없을 때 이야기가 달라집니다. 안전망은 단 하나가 아니라, 여러 층 (layers)으로 이루어져 있습니다.

인간 계층 (Human layer): 에이전트들이 작업하는 동안 터미널에서 PraxMonitor를 실행합니다. 이는 시스템 전체에서 일어나는 모든 일을 실시간으로 보여줍니다. AIPass에는 후크 소리(hook sounds)와 도구 소리(tool sounds)도 있습니다. 에이전트가 처리 중일 때를 말 그대로 소리로 들을 수 있습니다. 만약 작업이 진행 중이어야 할 시점에 소리가 들리지 않는다면, 그것이 무언가 잘못되었다는 첫 번째 신호가 됩니다. 저는 로그를 역추적하여 에이전트가 답장 이메일을 보냈는지 확인하고 무슨 일이 일어났는지 파악합니다.

코드 계층 (Code layer): 디스패치 모니터(dispatch monitor)는 깨어난 모든 에이전트를 시작 시간 제한(startup timeouts), 재시도 로직(retry logic), 그리고 바운스 프로토콜(bounce protocol)로 감쌉니다. 만약 에이전트가 90초 이내에 응답하지 않으면 종료됩니다. 두 번의 재시도 후에도 안 되면 새로 시작하고, 그 후에는 에러 상세 정보와 함께 발신자에게 바운스 이메일을 보냅니다. PID 기반 잠금(PID-based locking)은 두 세션이 동일한 브랜치에서 실행되는 것을 방지합니다. 백그라운드 에러 와처(error watcher)는 충돌을 자동으로 포착합니다.

AI 계층 (AI layer): 오케스트레이터(orchestrator) 에이전트는 결과가 돌아오기를 기다리고 있습니다. 만약 디스패치가 나갔는데 답장이 오지 않는다면, 응답이 없는 열린 작업(open task)으로 나타나므로 이를 확인할 수 있습니다. 에이전트들 또한 자신의 브랜치에서 무슨 일이 일어났는지 이해해야 할 때 명령어를 통해 로그를 확인할 수 있습니다.

이는 자연스러운 흐름입니다. 많은 에이전트를 실행할 때 저는 모니터를 켭니다. 처리 소리가 들리지 않으면 확인합니다. 에이전트가 멈추면 알림을 받습니다. 인간의 감시, 코드의 실패 포착, 그리고 오케스트레이터의 열린 작업 추적 사이에서, 상황이 조용히 사라지는 일은 없습니다.

우체통이 실제로 가능하게 하는 것

기술적인 세부 사항보다 중요한 것은 그것이 무엇을 가능하게 하느냐입니다. 실제로 작동하는 것을 확인한 사례는 다음과 같습니다:

병렬 연구 (Parallel research): 5개의 디스패치 이메일을 보내고, 5개의 독립적인 연구 보고서를 돌려받습니다. 각 에이전트는 깨끗한 컨텍스트(context)를 가지고 작업하며, 연구 스트림 간의 오염이 없습니다. 결과가 동일한 발견 사항으로 수렴한다면, 이는 결론이 실제라는 강력한 신호가 됩니다.

연속적인 오케스트레이션 (Continuous orchestration): 작업을 할당하면 에이전트가 업무를 수행하고, 자신의 메모리 (Memories)를 업데이트하며, 응답을 보냅니다. 하지만 도움이 필요하다면 어떻게 될까요? 혹은 5단계 계획 중 1단계라면 어떨까요? 바로 여기서 watchdog이 등장합니다. 오케스트레이터 (Orchestrator) 에이전트가 계속 살아있는 상태로 응답을 감시하며 계획을 계속 진행시킵니다. 에이전트가 1단계를 마치고 결과와 함께 응답하면, 오케스트레이터가 이를 받아 다음 에이전트에게 2단계를 할당합니다. 잘 설계된 계획이 있다면, 인간의 개입 없이도 여러 에이전트에 걸쳐 여러 단계를 지속적으로 수행할 수 있습니다.

팀 협업 (Team coordination): CEO 에이전트 (Vera)가 작가 에이전트에게 콘텐츠 브리프 (Content briefs)를 할당하고, 품질 검사를 위해 초안을 콜드 리드 (Cold-read) 리뷰어에게 전달하며, 피드백을 종합하여 게시합니다. 에이전트들은 동일한 세션에 있을 필요도, 심지어 동시에 실행될 필요도 없습니다.

우체통 (Mailbox)은 고립되었던 에이전트들을 실제로 팀과 유사한 무언가로 탈바꿈시켰습니다. 이는 통신 프로토콜이 정교해서가 아니라 — 말 그대로 JSON 파일일 뿐이지만 — 에이전트들이 서로를 찾고, 이름으로 서로를 지칭하며, 지속되는 메시지를 남길 수 있는 방법을 제공하기 때문입니다.

인간이 루프 안에 머무릅니다 (The human stays in the loop)

이 시스템은 감독 없이 실행되는 시스템이 아닙니다. 그것은 한계가 아니라 설계 의도입니다.

저는 완전히 통제권을 쥐고 있습니다. 오케스트레이터 에이전트와 저는 모든 에이전트가 정확히 무엇을 하고 있는지 볼 수 있습니다. 아무것도 숨겨지지 않습니다. 에이전트가 다른 에이전트를 호출하면 우리는 그것을 볼 수 있습니다. 오류가 계속 발생하면 로그 (Logs)에 나타납니다. 에이전트들이 자율적으로 작동하는 이유는 우리가 신뢰할 수 있는 시스템을 구축했기 때문이지만, 결국 그들은 여전히 LLM (Large Language Models)입니다. 가끔 실수를 합니다.

하지만 복구는 쉽습니다. 에이전트의 작업에 대해 표준 감사 (Standards audit)를 실행하고, 준수 여부를 확인한 뒤, 놓친 부분을 수정하라고 지시하면 됩니다. 로그에 오류가 지속되면, 시스템에 내장된 에러 와처 (Error watcher)가 반복되는 실패를 포착하고 조사할 적절한 에이전트를 할당합니다. 경고 (Warnings)는 나중에 무시할 수 있지만, 실제 실패 (Failures)는 처리됩니다.

에이전트들에게는 여전히 방향성이 필요합니다. 그들은 서로 자유롭게 이메일을 보내고 작업을 할당(dispatch)합니다. 만약 한 에이전트가 다른 에이전트의 도메인에서 버그를 발견하면, 메시지를 보내거나 직접 수정 사항을 할당합니다. 더 큰 규모의 빌드 과정에서 그들은 끊임없이 협력합니다. 하지만 누군가는 목표를 설정해야 합니다. 오케스트레이터(Orchestrator)가 무엇을 빌드할지 결정합니다. 에이전트들은 그 과정에서 누구와 대화해야 할지를 스스로 파악합니다.

확장성(Scale)은 미지의 영역입니다. 13개의 에이전트는 잘 작동합니다. 문제 없이 30개까지 실행해 보았습니다. 그 이상으로 넘어가면 파일 기반 방식은 분명한 한계가 있지만, 실제 소프트웨어 프로젝트를 관리하는 데에는 아마 그 이상은 필요하지 않을 것입니다.

수치 (The numbers)

현재 AIPass의 현황: 13개의 에이전트가 136,000줄 이상의 코드에 걸쳐 730개 이상의 Python 모듈을 관리하고 있으며, 8,400개 이상의 테스트와 600개 이상의 풀 리퀘스트(Pull Requests)의 지원을 받고 있습니다. 테스트 수가 높은 이유는 각 에이전트가 자신만의 테스트 스위트(Test suite)를 유지하기 때문입니다. 프레임워크가 브랜치(Branch)별로 커버리지(Coverage) 표준을 강제하므로, 에이전트 수에 따라 함께 확장됩니다. 메일 시스템 하나에만 712개의 테스트가 있습니다. 모든 에이전트는 여권(신원), 세션 기록(메모리), 그리고 협업 패턴(관찰)을 가집니다. 그들은 세션을 넘나들며 기억을 유지합니다. 메일을 통해 협력합니다. 결코 처음부터 시작하지 않습니다.

모두를 위한 것은 아닙니다. 이것은 터미널에서 작업하는 사람들을 위한 CLI 네이티브 워크스페이스입니다. UI는 없습니다. SaaS도 아닙니다. 여러분의 프로젝트를 가져오면, AIPass가 인프라를 제공합니다.

하지만 AI 도구 간에 컨텍스트(Context)를 복사하거나, 새로운 에이전트에게 같은 내용을 다시 설명하거나, 에이전트들이 그냥 서로 대화할 수 있기를 바랐던 적이 있다면 — 우체통(Mailbox)이야말로 실제로 작동하는 가장 단순한 해결책이 될 수 있습니다.

사용해 보기:

pip install aipass
mkdir my-project && cd my-project
aipass init run

GitHub | r/AIPass | aipass.ai

AIPass를 공개적으로 빌드하고 있습니다. 가공되지 않은 개발 로그는 r/AIPass에서 확인하세요.