CLI 에이전트 메시징 레이어를 오픈 소스로 공개하며 얻은 교훈 (일주일 만에 320 stars 달성)

약 일주일 전, 저는 CLI AI 에이전트들이 서로 직접 메시지를 주고받을 수 있게 해주는 약 500줄 규모의 bash + SQLite 도구인 agmsg를 오픈 소스로 공개했습니다. 제가 이 도구를 만든 이유는 다소 단순했습니다. Claude Code와 Codex 사이에서 인간 복사-붙여넣기 전달자 역할을 하는 데 지쳤기 때문입니다. 하루 종일 한 터미널에서 코드를 선택해 다른 터미널에 붙여넣고, 답변을 다시 가져오는 과정을 반복하는 것에 질려 있었습니다.

저는 친구들에게 몇 개의 star를 받는 것 외에는 아무것도 기대하지 않았습니다. 하지만 결과는 일주일 만에 5개에서 320개로 늘어났고, 포크(forks), 파생 프로젝트, 그리고 한 번도 만난 적 없는 사람들의 풀 리퀘스트(pull requests)가 이어졌습니다. 제가 예상했던 것과 실제로 일어난 일 사이의 그 간극이 흥미로운 지점입니다. 그래서 수치, 성공한 것, 실패한 것, 그리고 저를 진정으로 놀라게 했던 것들에 대해 솔직한 회고를 남겨보고자 합니다.

수치 (The numbers)

예산도 없고 딱히 관객도 없는 상태에서 약 일주일 동안 일어난 변화는 다음과 같습니다:

• GitHub stars: 5 → 320
• Forks: 0 → 15
• 3개의 파생 프로젝트 — 누군가는 이 아이디어를 shogi로 포팅했고(agmsg-shogi), 누군가는 이를 MCP 서버로 래핑했으며(agmsg-mcp), 누군가는 Go 언어로 다시 작성했습니다(agmsg-go).
• 외부 기여자들의 풀 리퀘스트 (Pull requests) — Gemini CLI, Antigravity 지원, 그리고 현재는 GitHub Copilot CLI 지원과 더불어 역할 격리(role-isolation) 경합 조건(race conditions)에 대한 수정 사항이 포함되었습니다.

이 중 어느 것도 단 한 번의 큰 급증으로 이루어진 것이 아닙니다. 여러 채널에 걸친 일련의 게시물들로부터 비롯되었으며, 그중 일부는 효과가 있었고 일부는 완전히 효과가 없었습니다.

성공한 것 (What worked)

설명이 아닌 영상으로 시작하기. 가장 큰 호응을 얻었던 첫 번째 게시물은 아키텍처(architecture)에 대한 설명이 아니었습니다. 그것은 두 개의 Claude Code 인스턴스가 인간의 입력 없이 agmsg를 통해 자율적으로 틱택토(tic-tac-toe) 게임을 하는 23초짜리 영상이었습니다. 사람들은 에이전트들이 스스로 무언가를 수행하는 움직이는 영상을 보면 스크롤을 멈춥니다. 하단의 텍스트는 짧아도 상관없었습니다. 영상이 제 역할을 다했기 때문입니다.

공감할 수 있는 문제, 그리고 솔직한 서술. "두 AI 사이에서 복사-붙여넣기 중계기가 되어버렸다"라는 문구가 먹힌 이유는, 지금 이 순간에도 수많은 사람들이 조용히 정확히 그 일을 하고 있기 때문입니다. 저는 기술적인 설계(technical design)로 시작하지 않았습니다. 짜증 나는 상황(annoyance)으로 시작했습니다. 설계는 갈고리(hook)가 아니라, 그에 따른 보상(payoff)이었습니다.

긴 글(long-form post)을 착륙 지점으로 활용하기. 타임라인 게시물은 도달 범위(reach)에는 좋지만 깊이(depth)는 부족합니다. 그래서 스레드(threads)를 통해 설계 근거(design rationale), 트레이드오프(trade-offs), 그리고 전체 재현 프롬프트(reproduction prompt)가 담긴 더 긴 글을 가리키도록 했습니다. 한 채널에서는 도달 범위를, 다른 채널에서는 깊이를 확보한 것입니다.

단일 출시가 아닌 시리즈로 취급하기. 모든 것을 짊어져야 하는 단 하나의 게시물 대신, 저는 내용을 분산시켰습니다. 먼저 탄생 서사(origin narrative)를 올리고, 그다음 첫 외부 기여(outside contribution), 그다음 새로운 기능(actas, 하나의 워크스페이스 내 여러 에이전트 역할), 마지막으로 기본 메커니즘(underlying mechanism)에 대한 심층 분석(deep dive) 순으로 진행했습니다. 각 조각은 프로젝트를 약간씩 다른 타겟층에게 다시 노출시켰고, 첫 24시간이 지난 후에도 프로젝트가 계속 살아있게 만들었습니다.

실패한 점

나의 첫 영어 게시물은 가라앉았다. 나의 첫 번째 영어 글은 약 3.6K의 노출(impressions)을 기록했지만, 전환(conversion)은 거의 없었습니다. 콘텐츠는 괜찮았습니다. 배포(distribution)가 전혀 없었을 뿐입니다. 저는 이를 뒷받침할 스레드도 없고, 유입을 유도할 장치도 없이 그냥 생으로(cold) 게시했습니다. 진입로(on-ramp)가 없는 좋은 글은 인터넷상의 단순한 파일일 뿐입니다.

Hacker News는 상황이 좋지 않았다. Show HN을 시도했는데, 내가 작성한 첫 번째 저자 댓글이 몇 초 만에 스팸 필터에 의해 자동으로 차단되었습니다. 너무 길었고, 너무 홍보성(promo-shaped)이었기 때문입니다. 그 후 게시물을 삭제하고 다시 올리는 실수를 저질렀는데, 이것이 교체된 게시물을 영구적으로 '사망' 상태로 표시하게 만드는 정확한 트리거라는 것을 알게 되었습니다. 혹독하게 배운 교훈은 다음과 같습니다: 첫 댓글은 링크 없이 두세 문장으로 작성해야 하며, 만약 플래그(flagged)가 지정된다면 그대로 두어야 합니다.

Reddit은 시작조차 할 수 없었다. 가치가 높은 서브레딧(subreddits)들은 신규 계정에 대해 계정 생성일과 카르마(karma) 제한을 두는데, 정작 필요할 때 내 계정에는 둘 다 없었습니다. 여기에는 지름길이 없습니다. 필요하기 전에 미리 활성화된 계정을 가지고 있거나, 아니면 그날은 참여할 수 없거나 둘 중 하나입니다.

놀라웠던 점

파생 프로젝트 (Derivative projects). 누군가 이 아이디어를 가져가서 동일한 메시징 레이어 (messaging layer) 위에서 에이전트들이 쇼기를 두는 agmsg-shogi를 만들 것이라고는 진심으로 예상하지 못했습니다. 포크 (Forks)는 이해할 수 있었지만, 다른 도메인에서 처음부터 다시 해석하여 구현하는 것은 완전히 다른 신호였습니다. 그때부터 이것이 단순한 저장소 (repo)가 아니라, 다른 사람들이 그 위에 구축하고 싶어 하는 작은 아이디어처럼 느껴지기 시작했습니다.

기여자(Contributors)들이 계속 나타났습니다. Gemini, Antigravity, 그리고 GitHub Copilot CLI에 대한 지원은 제가 한 번도 대화해 본 적 없는 분들에 의해 추가되었습니다. 이제 이 프로젝트는 다섯 가지의 서로 다른 CLI 에이전트와 통신하며, 그 폭넓은 확장성의 대부분은 외부에서 왔습니다. 표면적 (surface area)을 아주 작게 유지한 것 — bash와 sqlite3만 사용하고, 데몬 (daemon)도, 네트워크도, Python도 사용하지 않은 것 — 이 확장하기 쉽게 만드는 핵심 요소가 되었습니다.

북마크가 좋아요(likes)보다 별(stars)을 더 잘 예측했습니다. 기술적인 포스트의 경우, 북마크 대비 좋아요 비율이 GitHub 별(stars)의 추이를 추적하는 신호였습니다. 사람들은 "나중에 이게 필요할 거야"라며 북마크를 남기며, 그 의도는 실제 전환으로 이어집니다. 좋아요는 박수이고, 북마크는 의도입니다.

다음 단계 (What's next)

이 모든 것을 실시간처럼 느껴지게 만드는 요소인 Claude Code의 활용도가 낮은 Monitor 도구와, 프로덕션 환경에서 와처 (watcher)를 실행하기 위해 제가 반드시 제대로 구현해야 했던 6가지 디자인 패턴 (design patterns)에 대한 심층 분석 글을 방금 게시했습니다. "이게 실제로 어떻게 작동하는가"에 대한 답은 그곳에 있습니다.

로드맵 (roadmap) 상으로는, agmsg가 한 기기의 단일 SQLite 파일에 종속되지 않도록 스토리지 레이어 (storage layer)를 플러그인 방식으로 교체 가능하게 (pluggable) 만드는 작업이 예정되어 있습니다.

재정의 (The reframe)

제가 계속해서 되돌아보게 되는 지점은 이것입니다. 일주일이 지난 지금, "메시징 레이어 (messaging layer)"라는 표현이 과연 적절한 설명인지조차 확신할 수 없습니다. 사람들이 실제로 사용하고 확장하고 있는 것은 **AI 에이전트를 위한 공유 블랙보드 (shared blackboard for AI agents)**에 더 가깝습니다. 즉, 독립적인 에이전트들이 서로를 위해 메모를 남겨두는 멍청하고(dumb) 내구성이 있는(durable) 장소이며, 파일을 읽고 쓸 수 있는 것이라면 무엇이든 참여할 수 있는 곳입니다. 메시징은 제가 그것을 필요로 했던 첫 번째 용도였을 뿐입니다.

만약 두 개 이상의 AI 코딩 에이전트를 실행하고 있다면, GitHub에서 확인해 보세요. 저는 별을 하나 더 받는 것보다 무엇이 고장 나는지에 대한 이야기를 듣고 싶습니다.