Claude Code와 Codex 사이에서 복사-붙여넣기 전달자가 되지 않기 위해 agmsg를 만들었습니다
요약
Claude Code와 Codex 사이에서 발생하는 번거로운 복사-붙여넣기 작업을 자동화하기 위해 개발된 agmsg를 소개합니다. SQLite를 기반으로 CLI AI 에이전트들이 서로 메시지를 직접 주고받을 수 있게 설계되었습니다.
핵심 포인트
- agmsg는 에이전트 간 메시지 전달을 자동화하는 CLI 도구입니다.
- SQLite를 활용하여 데몬이나 네트워크 없이 가볍게 작동합니다.
- Claude Code와 Codex의 협업 효율을 극대화합니다.
- Agent Skill 프레임워크를 기반으로 구축된 오픈 소스 프로젝트입니다.
저의 주력 도구는 Claude Code이며, 어려운 부분과 리뷰를 위해 Codex를 보조적으로 사용하고 있습니다. 이 분업 방식은 놀라울 정도로 잘 작동합니다. 하지만 시간이 흐른 뒤 저는 바보 같은 사실을 깨달았습니다. 제가 두 AI 사이에서 인간 복사-붙여넣기 전달자(copy-paste relay)가 되어 있었다는 점입니다.
Claude Code가 작성한 것을 복사해서 리뷰를 위해 Codex에 붙여넣고, Codex의 피드백을 복사해서 다시 Claude Code에 붙여넣습니다. 하루에도 수십 번씩 말이죠. 이는 지루하고, 집중력을 깨뜨리며, 가끔은 엉뚱한 것을 붙여넣기도 합니다. 저는 유능한 두 에이전트(agent)를 나란히 두고, 루프(loop) 내에서 가장 멍청한 일인 메시지 전달을 직접 하고 있었습니다.
에이전트들은 그냥 서로 직접 메시지를 주고받을 수 있어야 합니다. 그래서 저는 agmsg를 만들어서 GitHub에 올렸습니다: https://github.com/fujibee/agmsg
먼저 체험해 보세요 (30초 소요)
당신은 엔지니어니까, 읽는 것보다 직접 실행하는 것을 선호하겠죠.
bash <(curl -fsSL https://raw.githubusercontent.com/fujibee/agmsg/main/setup.sh)
그 다음 Claude Code / Codex를 재시작하고 /agmsg를 실행하세요 (Codex에서는 $agmsg). 처음 사용할 때는 팀 이름(team name)과 에이전트 이름(agent name)을 묻습니다. README에 전체 퀵스타트(quickstart)와 복사-붙여넣기 명령어가 있습니다.
두 에이전트가 동일한 "팀"에 합류하면 서로 메시지를 보낼 수 있습니다. 그 이후에는 에이전트에게 말만 하면 됩니다: "alice에게 리뷰가 끝났다고 전해줘", "메시지 온 거 있어?" — 그게 전부입니다.
유일한 의존성(dependencies)은 bash와 sqlite3뿐입니다. 데몬(daemon)도, 네트워크도, Python도 필요 없습니다.
왜 굳이 두 개의 코딩 에이전트를 사용하는가
이것은 우연히 시작되었습니다. Claude Code (Opus 4.6)가 까다로운 구현 문제에 막혀 버렸습니다 — 제가 어떻게 질문을 다시 구성해도 계속 제자리를 맴돌았습니다. 문득 같은 사양(spec)을 Codex (GPT-5.3)에게 전달해 보았는데, 거의 즉시 정확한 버전을 만들어냈습니다. 그것은 조용한 충격이었습니다.
그 이후로 저는 역할을 나누었습니다:
- Claude Code — 일상적인 주력 도구. 빠르고, 처리량이 많으며, 지시를 잘 따릅니다.
- Codex — 리뷰어이자 어려운 문제에 대한 최후의 수단. 일상적인 작업에는 다소 서툴 수 있지만, 까다로운 코드의 정확성에 있어서는 제가 신뢰하는 도구입니다.
어느 쪽이 더 "낫다"고 할 수도 없습니다. 성격이 다르기 때문에 각기 다른 순간에 유용할 뿐입니다. 그리고 제가 두 도구를 동시에 실행하기 시작한 순간, 전서구(carrier-pigeon) 문제가 발생했습니다.
agmsg란 무엇인가
한 줄로 요약하자면: CLI AI 에이전트들이 공유된 SQLite 데이터베이스를 통해 서로 메시지를 주고받는 것입니다. Claude Code, Codex, Gemini CLI 등 어떤 CLI 에이전트라도 작동합니다.
이 도구는 Agent Skill로 구축되었으므로, 스킬로서 설치하며 에이전트 자체는 건드리지 않습니다. 예상보다 결과가 좋아서 오픈 소스로 공개하게 되었습니다.
설계 결정 사항
제가 거쳐온 과정과 그 이유입니다.
먼저 내장 기능들을 확인했습니다. 무언가를 새로 만들고 싶지 않았기에 Claude Code의 팀(team) / 서브 에이전트(subagent) 기능을 살펴보았습니다. 이 기능들은 수명이 짧은 세션(short-lived sessions)을 중심으로 설계되어 있어, 일회성 서브 태스크를 분리해내는 데는 훌륭하지만, 두 에이전트가 지속적인 대화를 이어가는 데는 적합하지 않았습니다.
처음에는 일반 텍스트 파일로 시작했습니다. 내장된 팀 에이전트가 파일 기반의 단순한 방식이었기에 저도 똑같이 했습니다. 수명이 짧은 용도로는 괜찮지만, 지속성(persistent)과 동시성(concurrent)이 필요한 순간 바로 무너집니다. 쓰기 충돌(write conflicts)이나 파일 손상(corrupted files)이 발생하기 때문입니다.
그래서 SQLite (WAL 모드)로 전환했습니다. 여러 명의 읽기 사용자(readers)와 한 명의 쓰기 사용자(writer)가 충돌 없이 작동하며, 동시 접속 중에도 살아남는 트랜잭션(transactions)을 제공하고, 메시지 기록(message history)을 무료로 얻을 수 있습니다.
하지만 의존성은 최소한으로 유지했습니다. 이 부분이 제가 가장 신경 쓴 대목입니다. 원하는 만큼 기능을 풍부하게 만들 수도 있었지만, 저는 누구의 컴퓨터에서든 가져다 놓는 즉시 실행되기를 원했습니다. 그 결과: bash와 sqlite3가 실행되는 곳이라면 어디서든 작동합니다. 자체 데몬(daemon)도 없고(agmsg는 상주 프로세스가 없으며, monitor 모드만이 Claude Code의 내장 Monitor에 올라타 작동합니다), 네트워크도 필요 없으며(모두 로컬에서 처리), Python도 필요 없습니다.
전달 모드 — monitor가 사용 가능하게 만든 핵심
메시지가 에이전트에게 도달하는 방식은 대략 세 가지가 있습니다:
- manual (수동) —
/agmsg를 실행하거나 에이전트에게 "수신함을 확인해봐"라고 요청합니다. 신뢰할 수 있지만, 사용자가 직접 기억하고 실행해야 합니다. - hook (훅) — 턴 사이(Stop hook에서) 확인합니다. Codex는 Monitor 도구가 없기 때문에 이 방식을 기본값으로 사용합니다.
솔직히 말해서, 모니터 (monitor) 기능이야말로 이것을 단순한 장난감에서 유용한 도구로 격상시킨 핵심입니다. 수동(manual) 또는 훅(hook) 방식에는 간극이 존재합니다. 상대방은 이미 응답했지만, 직접 확인하기 전까지는 이를 알아차리지 못한다는 점입니다. 하지만 모니터 방식에서는 대화가 끊김 없이 흐릅니다.
그 메커니즘(차단형 SQLite 읽기(blocking SQLite read) 위에 Claude Code의 모니터 기능을 얹는 방식)은 충분히 흥미로워서 나중에 별도로 정리해보고 싶습니다.
그리고 재미있는 부분이 있습니다. 모니터 모드(monitor-mode)로 설정된 두 개의 Claude Code 인스턴스를 같은 팀에 두고 그대로 내버려 두면, 인간의 입력 없이도 계속해서 대화를 나눕니다. 두 인스턴스에게 "틱택토(tic-tac-toe) 게임을 해봐"라고 시켰더니, 서로 수를 주고받으며 게임 전체를 끝까지 진행했습니다. 딱히 유용한 작업은 아니었지만, 두 에이전트(agent)가 자율적으로 공을 주고받듯 대화하는 모습을 지켜보는 것은 진심으로 즐거운 경험이었습니다.
agmsg를 통해 인간의 개입 없이(no human in the loop) 틱택토 게임을 하는 두 개의 모니터 모드 Claude Code 인스턴스 (실제 게임이며, 정적인 간격은 제거됨, 약 2.5배 속도).
다음 단계
이것을 만들면서 가장 치열하게 싸웠던 부분은 Claude Code와 Codex가 완전히 다른 훅(hook) 및 설정(config) 모델을 가지고 있다는 점이었습니다. Claude Code에는 모니터(Monitor)와 풍부한 세션 시작(SessionStart) 훅이 있지만, Codex에는 둘 다 없습니다. 전달(delivery) 과정을 모니터(monitor)와 턴(turn)으로 분리한 이유는 바로 그 간극을 메우기 위함이며, 설정 파일(config files) 또한 각기 다른 위치와 형식으로 존재합니다. 서로 다른 기반을 가진 두 에이전트 사이에서 "메시지가 도착했을 때 알림을 받는" 동일한 기능을 구현하는 데 가장 많은 고민이 필요했습니다.
이러한 이기종 에이전트(heterogeneous-agent) 간의 경계를 어떻게 매끄럽게 처리했는지, 그리고 앞서 언급한 모니터 내부 구조에 대해서는 다음 글에서 다루도록 하겠습니다.
우선은, 지금 바로 설치해서 Claude Code와 Codex가 서로 직접 대화하게 만들어 보세요.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기