에이전트 협업 환경 구축 3주차 기록: 결국 살아남은 것은 '누가 호출하는가'로 결정된다
요약
본 글은 여러 AI 에이전트를 협업 환경으로 구축하려 했으나 실제 사용 패턴을 분석한 기록입니다. 다양한 도구(agmsg, claude-squad 등)를 도입했음에도 불구하고, 실제로 가장 많이 쓰인 것은 단일 모델 호출 방식이었음을 데이터로 증명합니다. 복잡한 에이전트 협업보다 단순하고 직접적인 호출이 더 효율적임을 강조합니다.
핵심 포인트
- 복잡한 에이전트 협업은 실제 사용성이 떨어질 수 있다.
- 여러 도구 도입보다 단일 모델의 직접 호출(Single Call)이 효율적이다.
- 실제 사용 패턴을 분석하는 것이 기술 도입 성공의 핵심이다.
3주 전, 저는 의기양양하게 이런 환경을 구축했습니다.
Claude Code와 Codex를 agmsg로 대화시키고, claude-squad로 여러 세션을 병렬 배치하며, h5i로 병렬 구현을 안전하게 머지하는—'인간이 복사/붙여넣기 담당일 시대는 끝났다'라는 그런 것이었습니다. Brewfile에도 전부 적었고, 기사도 쓰고 있었습니다.
그리고 오늘 문득 생각나서 셸(shell)의 히스토리를 세어봤습니다. 결과는 이랬습니다.
agmsg 메시지 DB에 대화가 단 한 건만 들어있었습니다.
이 글은 그 전말과 '왜 그렇게 되었는지'에 대한 분석입니다. 도구 소개 기사로 쓰기 시작했는데, 실제로 측정해보니 다른 내용의 글이 되었습니다. 같은 실수를 하는 사람이 줄면 원래 목적을 달성할 수 있습니다.
📊 먼저 숫자를 봐주세요
도입 후 3주간의 대화 셸(dialogue shell)에서의 수동 실행 횟수와 최종 사용일입니다.
# fish의 경우. zsh라면 ~/.zsh_history를 보세요
grep -c "^- cmd: .*agmsg" ~/.local/share/fish/fish_history
| 도구 | 수동 실행 횟수 | 최종 사용일 | 실제 상태 |
|---|---|---|---|
| agmsg | 9회 | 2026-07-17 | 도입 및 테스트만 |
| claude-squad | 10회 | 2026-07-09 | 모든 것을 시운전(-y -n debug reset 등) |
| h5i | 2회 | 2026-07-08 | 기사를 쓰던 날에 중단 |
| agy (Antigravity CLI) | 1회 | 2026-07-27 | 현역 |
| ccusage | 2회 | 2026-07-11 | 현역 |
마지막 두 줄에 주목해 주세요. 수동 실행 횟수가 가장 낮은 도구가, 현역입니다. 여기에 답의 절반이 있습니다.
그리고 또 하나의 움직일 수 없는 증거가 있습니다.
sqlite3 ~/.agents/skills/agmsg/db/messages.db "select count(*) from messages;"
# => 1
에이전트끼리 대화시키기 위해 넣은 도구였는데, 오고 간 대화는 평생 단 한 번(2026-07-10, 아마도 통신 확인)이었습니다. claude-squad의 10회 분량도 내용을 보면 ln -s
로 별칭(alias)을 건 행이나 --help
같은 호출만 많았고, 실무에서 사용된 흔적은 제로입니다.
🔍 왜 사용하지 않게 되었나
변명을 찾기 전에, 먼저 기각된 가설부터 말씀드립니다.
'도구가 나빴다'가 아닙니다. 세 가지 모두 설계는 건전했고, 지금도 상위 레벨(upstream)에서는 활발하게 업데이트되고 있습니다. 'Codex에 로그인하지 않았다'도 아닙니다 — 확인해보니 Logged in using ChatGPT
로 언제든 사용할 수 있는 상태였습니다 (저는 제 메모에 '미로그인'이라고 적어두었고, 그것이 틀렸습니다).
실제 원인은 세 가지가 있었다고 생각합니다.
① 협업 비용이, 협업으로 얻는 것보다 컸다
agmsg로 'Claude Code에게 설계시키고, Codex에게 리뷰시키기'를 하려면 이런 절차가 필요합니다.
- 터미널 A에서 Claude Code를 실행
- 터미널 B에서 Codex를 실행
- 양쪽 모두에서
/agmsg
을 입력하여 같은 팀에 참여 - A에게 '설계를 정리해서 Codex에게 던져줘'라고 지시 - B로 전환하여 수신 확인 및 리뷰시키기
- A로 돌아와 결과를 반영
반면, 같은 '두 번째 의견이 필요하다'는 목적은, 실제로는 이것으로 충분했습니다.
codex exec "이 설계를 리뷰해줘: $(cat design.md)"
한 줄입니다. 세션을 두 개 띄울 필요도, 팀에 참여시킬 필요도 없습니다. '에이전트끼리 자율적으로 대화한다'는 그림은 매력적이지만, 제가 실제로 원했던 것은 '다른 모델에게 한 번 던져 의견을 받는 것'뿐이었습니다. 목적에 비해 시스템이 너무 무거웠습니다.
② '사람이 수동으로 실행하는 도구'는 죽고, '실행 중에서 호출할 수 있는 것'이 살아났다
이것이 서두의 '수동 실행 1회인 agy가 현역'의 답입니다.
agy는 제가 손으로 치는 경우는 거의 없습니다. **Claude Code가 작업 중에 Bash를 통해 `agy -p
반대로 agmsg와 claude-squad는 구조상 사람이 직접 수동으로 시작하지 않으면 작동하지 않습니다. 별도의 터미널을 열고 팀에 참여시키며, 양쪽을 지켜봐야 했습니다. 이 '사람이 진행자 역할을 해야 한다'는 전제가 일상적인 작업에서 그대로 마찰로 작용했습니다.
측정 시 주의사항: 수동 실행 횟수는 '사용하지 않았다'는 증거가 될 수 없습니다. 제 경우, 현역인 agy가 1회였고, 사장된 claude-squad가 10회였습니다. 수동으로만 시작할 수 있는 도구에 한해서 이 숫자는 의미를 가집니다.
③ 병렬화하기 전에, 직렬로 충분했다
h5i와 claude-squad가 해결하려 했던 것은 '여러 에이전트를 동시에 실행했을 때의 충돌'이었습니다. 하지만 3주를 되돌아보면, 저는 애초에 여러 개를 동시에 실행하고 있지 않았습니다. 개인 개발이라 작업은 기본적으로 한 가지였습니다. 존재하지 않는 문제에 대한 해결책을 먼저 넣었던 형태입니다.
게다가 병렬화가 정말 필요해졌을 때, Claude Code 쪽에 서브 에이전트와 백그라운드 태스크가 추가되었고, 격리된 worktree도 표준 기능이 되었습니다. 외부 도구로 메우려 했던 구멍이 본체 쪽에서 채워졌다는 측면도 있습니다.
🛠️ 결국 살아남은 것은 무엇인가
3주 후에 실제로 작동하는 구성은 다음과 같습니다.
1차 에이전트: Claude Code (판단・통합・문서 작성) -
세컨드 오피니언: agy -p "..."
/codex exec "..."
을 한 줄로 호출합니다. 대화시키지 않고 그냥 던져 놓는 방식 -
병렬화: Claude Code의 서브 에이전트 (외부 도구가 아닌 본체 기능) -
시각화: ccusage를 스크립트에서 주기적으로 실행
화려하진 않지만, 모두 '현재 실행 중인 세션 내에서 호출할 수 있는' 형태로 수렴했습니다. 공통점은 사람이 새로운 창을 열 필요가 없다는 것입니다.
물론 이 3가지 도구를 삭제한 것은 아닙니다. 여러 명의 팀원이 각기 다른 머신에서 에이전트를 구동한다면, h5i의 '흔적을 git ref에 남기는' 설계는 여전히 매력적이라고 생각합니다. 제가 개인 개발이라 필요하지 않았을 뿐, 도구의 패배는 아닙니다.
⏱️ 추가: 7주 후 (2026-09-13)
이 글을 작성한 것이 7월 말입니다. 그대로 공개하지 않고 보관해 두었기 때문에, 같은 측정을 다시 해보았습니다.
결론부터 말하자면, 예상보다 가혹한 결과였습니다.
| 도구 | 기사 작성 시점 (7월 말) | 오늘 (2026-09-13) |
|---|---|---|
| agmsg | 수동 9회 / 최종 07-17 | 설치 해제됨. messages.db 모두 소멸 |
| claude-squad | 10회 / 최종 07-09 | 7/31~8/19에 5회 구동 → 설치 해제됨 |
| h5i | 2회 / 최종 07-08 | 2회 그대로. 최종 사용도 07-08 이후 작동 안 함 |
| agy | 1회 / 최종 07-27 | 3회 / 최종 09-07. 현역 |
$ which agmsg claude-squad
agmsg not found
claude-squad not found
...
평생 단 한 번의 메시지 DB는 한 번 그대로 사라졌습니다.
유일하게 예상 밖이었던 것은 claude-squad입니다. 기사 본문에서 '실무에서 사용한 흔적은 제로'라고 썼지만,
이후 cs 플러그인
cs photo
cs github
와 실제 프로젝트 이름 같은 인수로 5회 구동된 흔적이 남아 있었습니다.
한때는 진심으로 실무에 넣으려고 했던 것입니다. 그럼에도 정착하지 못하고, 최종적으로 삭제했습니다.
즉, '시도해보지 않아서 사용하지 않은' 것이 아닙니다. 시도해 본 후, 수동으로 진행자 역할을 하는 비용이 매번 승리한 것입니다.
이는 원래 분석 ②를 오히려 보강합니다.
그리고 h5i. 7주 동안 1회도 늘지 않았지만, 이것만은 아직 삭제하지 않았습니다.
'여러 명의 팀원이면 매력적'이라고 판단한 것은 지금도 변함없으므로, 제가 사용하는 방식이 따라잡을 때까지 놓아두었습니다.
사용하지 않는 것과 틀렸다는 것은 다릅니다.
💡 요약: 넣기 전에 '누가 구동할지'를 생각하기
실측해 보니, 도입한 3가지 도구의
실사용은 거의 제로(agmsg의 생애 메시지 수는 1통)였습니다. 원인은 도구의 품질 문제가 아니라,
협조에 드는 비용이 목적 대비 너무 컸기 때문입니다.
사람이 손으로 직접 실행해야 하는 도구는 지속되지 않습니다. 이미 작동하는 에이전트로부터 호출할 수 있는 것만 남습니다. 병렬화 도구를 넣기 전에,
내가 정말로 병렬 작업을 하고 있는지를 확인해 보세요. 수동 입력 횟수로 측정하는 것은 편리하지만,
스크립트나 에이전트를 통한 호출은 셀 수 없습니다. '수동 입력 0 = 미사용'이라는 등식은 성립하지 않습니다.
판단은 시간을 두고 재점검할 때 가능합니다. 7주 후에 다시 측정해 보니, 3가지 도구 중 2개는 제가 직접 삭제했습니다.
새로운 도구를 넣을 때는, 이제부터 '이것을 누가 호출하는가?'를 먼저 질문하기로 했습니다. 답이 '내가 매번 손으로'라면, 아마 3주 후에는 사용하지 않을 겁니다.
3주 전의 저에게 말한다면, 아마 이렇게 말할 것 같습니다. '그 환경은 만들기 전에 일주일만 수동으로 해보는 건 어때?'
💬 댓글로 꼭 알려주세요!
넣었지만 사용하지 않게 된 도구가 있나요? '이것은 오히려 정착했다'는 이야기도 듣고 싶습니다. 여러분의 멀티 에이전트 환경에서 실제 살아남은 것은 무엇인가요?
Discussion

AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기