Paperclip vs Buzz vs Multica, 그래도 dira 를 만든 이유

개발자로 사회생활을 시작했습니다

저(임한솔)는 2014년에 프랜차이즈 주문 시스템을 만들며 개발을 시작했습니다. 전자책 서비스의 CMS 를 만들었고, 토스에서는 사내 시스템과 업무 자동화를 도맡았습니다. 지금은 프루퍼를 운영하면서 한 커머스 플랫폼팀의 팀장을 겸합니다. 경력으로 치면 12년째입니다.

직함은 바뀌었지만 일하는 방식은 개발자의 태도가 남아있는 것 같습니다. 도구를 적극적으로 활용하고, 마음에 안 들면 바꾸고, 바꿔도 안 되면 직접 만들어서라도 문제를 해결합니다.

에이전트 오케스트레이션 도구인 Paperclip, Buzz, Multica 를 써 본 것도 이 습관에서 나왔습니다. 시작은 IDE 였습니다.

그동안 사용해온 개발 도구들

UX 는 역시 IntelliJ

IntelliJ IDEA 는 JetBrains 가 2001년에 내놓은 Java IDE 입니다. 처음부터 코드 탐색과 리팩터링을 IDE 안에 깊이 넣은 것으로 이름을 얻었고, 지금은 Kotlin 까지 아우르는 JetBrains 제품군의 중심입니다.

개발자로 일한 시간 대부분을 IntelliJ 에서 보냈습니다. 리팩터링, 검색, 디버거 단축키가 손에 붙어 있었고, 편집기 사용감만 놓고 보면 IntelliJ 가 가장 좋았습니다.

그러나 AI 코딩 도구가 나오면서 그 기준이 바뀌었습니다. 편집기가 얼마나 손에 맞는지보다 AI 가 제 코드를 얼마나 알고 제안하는지, 그리고 그 AI에게 지시하는 도구의 사용성이 더 크게 다가왔고, 그 점에서는 Cursor 가 훨씬 앞서 있었습니다.

코드 컨텍스트는 Cursor

Cursor 는 Anysphere 가 2023년 3월에 내놓은 AI 코드 에디터입니다. VS Code 를 포크해 만들어서 확장과 단축키를 그대로 쓸 수 있습니다. 코드베이스를 조각내 임베딩으로 색인해 두고, 질문할 때마다 관련 있는 코드를 찾아 모델에 함께 넘깁니다. 모델은 여러 회사 것 가운데 골라 쓸 수 있습니다.

Cursor 로 옮긴 건 코드베이스 컨텍스트를 잘 쓰고 붙어 있는 모델 성능이 좋아서였습니다. 편집기 사용감은 내려놓았지만, 제 레포를 읽고 내놓는 제안이 그만큼 쓸모 있었습니다.

Cursor 를 내려놓게된건 비용 때문이었습니다. 그 무렵 팀과 회사 전체에 Claude Team 을 들이는 중이었고, Cursor 와 Claude 에 비용을 겹쳐 내는 것이 팀 입장에서 큰 부담이었습니다.

Claude 로 통일한 VS Code 와 Claude Code

Claude Code 는 Anthropic 이 만든 에이전트형 코딩 도구입니다. 터미널에서 시작했고, VS Code 확장은 같은 에이전트를 편집기 옆 패널로 가져옵니다. 계획을 미리 읽고 고친 뒤 승인하거나, 수정 사항을 인라인 diff 로 보거나, 선택한 코드 범위를 @ 멘션으로 넘길 수 있습니다. Claude 유료 구독이 있으면 API 키 없이 씁니다.

이미 Claude 를 쓰고 있어서 편집기는 VS Code, 에이전트는 Claude Code 확장으로 모았습니다. 구독과 모델이 한곳에 있으니 어느 도구에서 무엇을 썼는지 따질 일이 줄었습니다.

쓰다 보니 코드를 직접 통제하면서 여러 컨텍스트를 동시에 오가려니 머리가 따라가지 못했습니다. 그래서 코드를 일일이 들여다보지 않는 바이브 코딩을 시도해 봤고, 그러면서 코드를 보는 도구인 IDE 의 중요성이 흐려졌습니다.

멀티 세션을 위한 herdr 와 Orca

에이전트를 활용하다보니 에이전트가 일하는 동안 손 놓고 기다리기가 아까워 세션을 여러 개 띄웠습니다. 세션이 늘어나자 어느 창에서 무엇이 도는지 한번에 볼 수 없었고, 바로 그 일을 덜어 주는 도구가 tmux를 탑재한 herdr 와 Orca 였습니다.

herdr 는 Can Celik 이 만든 Rust 터미널 멀티플렉서입니다. Claude Code 나 Codex 를 감싸지 않고 그 터미널을 그대로 품습니다. 창마다 에이전트가 일하는 중인지, 막혔는지, 쉬는지 보여 주고, 창을 분리하거나 노트북을 덮어도 세션이 이어집니다. SSH 로 여러 기계의 세션을 한 화면에서 볼 수도 있습니다.

Orca 는 에이전트마다 git worktree 를 따로 잡아 나란히 돌리는 데스크톱 앱입니다. 같은 프롬프트를 여러 에이전트에 보내 결과를 비교하고, 나은 쪽을 골라 병합할 수 있습니다. herdr 가 터미널 안에서 세션을 다룬다면, Orca 는 화면에서 worktree 단위로 다룹니다.

둘 다 써 봤지만 저는 TUI 를 선호하지 않아서, 채팅 UI 기능이 있는 Orca 를 조금 더 쓰다가 다음 도구로 옮겨 갔습니다. 터미널과 worktree 만으로는 담기 어려운 일들의 우선순위가 더 높아졌기 때문입니다.

개발 밖의 일을 맡기려고 붙인 Hermes 와 Slack

Hermes Agent 는 Nous Research 가 만든 오픈소스 에이전트입니다. 쓰면서 스킬을 만들고 고치는 학습 루프와 에이전트가 직접 관리하는 메모리가 있고, 게이트웨이 프로세스 하나로 Slack, Telegram, Discord 같은 메신저에 붙습니다. 크론 스케줄러도 내장돼 있습니다.

개발이 아닌 일도 에이전트에게 넘기기 시작했습니다. 사업 아이템을 두고 하는 고민, 서비스 기획의 발산, 법무 검토와 거버넌스 검토 같은 일입니다. 이런 일은 터미널보다 대화 창이 편해서 Hermes 를 Slack 에 붙였습니다. 팀이 이미 쓰는 채널에서 에이전트를 부르면 되니 따로 도구를 익힐 일도 없었습니다.

Hermes 와 Slack 조합은 쓸 만했지만 제가 짜 맞출 것이 많았습니다. 에이전트마다 맡을 일, 깨어날 때, 결과를 둘 곳을 제가 일일이 정해야 했습니다.

알아서 해 주길 바란 Paperclip

그래서 처음 찍먹해본 Paperclip 은 에이전트 팀에게 회사를 맡기는 오픈소스 오케스트레이터입니다. 조직도에 CEO, CTO, 엔지니어 에이전트를 두고 목표를 주면, 에이전트가 배정이나 메시지, 스케줄에 맞춰 깨어나 일을 쪼개 처리합니다. 예산 한도와 승인 게이트도 있습니다.

Claude Code, Codex, Cursor, Gemini CLI 같은 코딩 에이전트는 물론 Hermes 도 에이전트로 붙일 수 있습니다. 회사 단위로 작업과 권한, 이력이 나뉘고, 회사 구성을 템플릿으로 내보내 다른 곳에서 가져올 수도 있습니다.

알아서 해 주는 도구를 찾다가 Paperclip 을 썼습니다. 목표만 주면 조직도와 하트비트가 나머지를 굴려 주니, Hermes 때 제가 일일이 정하던 부분을 도구가 맡아 주리라 기대했습니다.

너무 제멋대로였던 Paperclip

커버리지는 넓었습니다. 목표 하나를 주면 하위 이슈를 스스로 쪼개 끝까지 밀고 갔습니다. 다만 그 과정이 잘 보이지 않았습니다.

가장 크게 데인 건 2026년 9월입니다. 회사용 Paperclip 인스턴스에 "첫 엔지니어 채용"이라는 목표를 줬더니 에이전트가 하위 이슈 여러 개로 쪼갰습니다. 그 끝에서 에이전트는 회사 GitHub 조직에 새 레포를 만들어 커밋을 올렸고, Vercel 에 프로덕션 배포까지 마쳤습니다. 만든 것은 회사 사업과 상관없는 소비자용 AI 사주 앱이었고, 제품명으로 회사 이름을 달았습니다. 사업 후보 선정도, 레포 이름도, 배포도 사람이 승인한 적이 없습니다.

제 설정이 잘못이었습니다. 회사 레포 생성 권한과 배포 권한을 열어 둔 채 목표만 던졌고, 에이전트는 "채용"을 "코드베이스를 만들고 배포하기"로 해석했습니다. 막을 게이트는 없었습니다. 이틀 뒤 배포를 멈추고 레포를 아카이브했습니다. 그때 정한 규칙은 지금도 지킵니다. 새 레포나 새 배포 프로젝트를 만들 때, 회사 이름을 단 제품을 낼 때는 사람이 승인합니다. 사업 후보는 에이전트에게 고르게 하지 않습니다.

권한을 막은 뒤에도 일이 어디까지 갔는지는 여전히 따라가기 어려웠습니다.

결국 정착한 곳은 Multica

Multica 는 코딩 에이전트에게 동료처럼 이슈를 배정하는 워크스페이스입니다. 에이전트는 보드에 팀원으로 올라가 이슈를 집어 가고, 진행 상황을 코멘트로 적고, 막히면 블로커를 올리고, 끝나면 리뷰로 돌려줍니다. 실행은 제 기계에서 도는 런타임 데몬이 맡습니다.

Paperclip 과는 일을 나누는 단위가 다릅니다. 에이전트가 하는 일이 이슈와 코멘트로 기록되니 저는 언제든 들여다보고 끼어들 수 있었습니다.

Paperclip 과 Multica 는 한동안 같이 썼습니다. Multica 는 2026년 8월부터 팀 업무 보드로 쓰고 있었고, 둘을 함께 굴리다가 Paperclip 을 내려놓았습니다.

써 보니 크게 다르지 않던 Buzz

2026년 7월 Block 이 Buzz 를 공개했습니다. 사람과 에이전트가 같은 채널에서 일하는 Slack 형 오픈소스 워크스페이스입니다. 에이전트는 자기 암호키와 채널 멤버십, 감사 기록을 받아 멤버로 들어오고, 메시지부터 git 이벤트까지 서명된 기록으로 한 로그에 쌓입니다.

Buzz 의 바탕은 Nostr 릴레이입니다. YAML 워크플로로 메시지, 리액션, 스케줄, 웹훅에 반응하게 만들 수 있고, 셀프호스트하거나 Block 이 운영하는 buzz.xyz 를 쓸 수 있습니다. 공개 당시 README 에는 모바일 앱과 워크플로 승인 게이트가 아직 연결 중이라고 적혀 있었습니다.

써 보니 Hermes 를 Slack 에 붙였을 때와 크게 다르지 않았습니다. Anthropic 이 2026년 6월 Slack 에 낸 Claude Tag 와도 비슷했습니다. Claude Tag 는 채널마다 Claude 를 하나 두고 팀이 함께 일을 맡기는 기능입니다. 셋 다 채팅 창에 에이전트를 들이는 방식이었고, 오히려 팀이 이미 쓰는 Slack 을 떠나 Buzz 로 옮겨 가는 일이 비용이었습니다.

Paperclip, Buzz, Multica 비교

Multica, 개발 외에도 쓸 만했습니다

지금 프루퍼의 정기 업무 상당수를 Multica 에이전트가 처리합니다. 코드 티켓을 맡기려고 들였는데, 이슈 하나를 일 하나로 다루는 방식이 사업 업무에도 맞았습니다.

사람 손이 필요한 일은 판단으로 좁혔습니다. 에이전트가 에스컬레이션 티켓을 만들면서 그 티켓에 코멘트로 웨이크업 트리거를 걸어 두기 때문에, 제가 멘션을 찾아 붙이지 않고 제 생각과 판단만 적어놔도 에이전트가 붙어줍니다.

팀에서도 같은 방식으로 일합니다. 2026년 8월에 업무 트래킹을 Jira -> Slack 리스트 -> 셀프호스트 Multica 로 옮겼고, 그때 옮긴 이슈가 1,423건입니다. 그 뒤로 에이전트에게 맡기는 일이 개발 티켓이 아닌 일로도 넓어졌습니다.

• 사업계획 숫자는 에이전트가 운영 DB 를 읽기 전용으로 조회해 채웠습니다. 하루에 1차부터 23차까지 고쳐 썼고, 그 지표는 지금 Metabase 대시보드로 봅니다.
• 성능 점검은 에이전트가 APM 을 이틀마다 훑으며 합니다. 이슈 수집, 원인 분석, 개선안을 단계별 이슈로 나눠 올립니다. 개선안을 맡은 에이전트가 레포 코드를 직접 읽고 수집 단계의 원인 전제를 고친 적도 있고, 제안에서 그치지 않고 PR 까지 낸 회차도 있습니다.

다른 팀 팀장들에게도 이렇게 일하는 방식을 전파하는 1:1 밀착 세션을 해보고 있습니다.

에이전트, 스쿼드, 오토파일럿

Multica 에서 일을 굴리는 단위는 에이전트, 스쿼드, 오토파일럿입니다. 에이전트가 작업자라면 스쿼드는 팀이고, 오토파일럿은 정기 일정입니다.

에이전트

에이전트 하나에는 지시문, 스킬, 런타임이 붙습니다. 지시문에는 역할과 판단 기준, 하지 않을 일을 적고, 스킬에는 필요할 때 꺼내 읽을 절차를 넣습니다. 런타임은 그 에이전트가 어느 기계에서 돌지를 정합니다.

에이전트는 이슈를 배정받거나, 코멘트에서 멘션되거나, 오토파일럿이 부르면 깨어납니다. 한 번 깨어나 일한 결과는 코멘트, 상태 변경, PR, 첨부로 이슈에 기록됩니다.

지시문에서 제가 가장 공들이는 부분은 하지 않을 일 목록입니다. PM 은 코드를 짜지 않고, 모호한 부분을 추측으로 메우지도 않습니다. QA 는 버그를 직접 고치지 않으며 취향은 지적하지 않습니다. 개발자는 스스로 검증한 것만으로 완료를 선언하지 않습니다. 이 경계가 흐려지면 에이전트끼리 서로의 일을 덮어씁니다.

스쿼드

제가 운영하는 개발 스쿼드에는 PM, 디자이너, 개발자, QA, 아카이브 매니저 에이전트와 사람인 제가 있습니다. 이슈를 스쿼드에 배정하면 리더인 PM 만 받습니다. PM 이 한 세션(5분에서 25분) 크기로 하위 이슈를 쪼개 스테이지를 정하고, 구성원을 멘션해 깨웁니다. 앞 스테이지가 모두 끝나야 다음 스테이지가 열립니다.

디자이너와 QA 는 직접 오가지 않습니다. 화면이 어떻게 보이는지는 디자이너가, 어떻게 동작하는지는 QA 가 보고, 둘 사이 빈틈은 PM 이 메웁니다.

수용 조건은 "명령 X 를 돌리면 Y 가 나온다" 형태로 씁니다. 범위 항목마다 확정, 미확정, 제외를 붙이고 확정된 항목만 진행합니다. 디자인이 안 나온 항목까지 쪼개 PR 을 올렸다가 되돌린 뒤에 생긴 규칙입니다.

이 방식으로 처음 실배포까지 간 티켓은 파트너용 화면의 배너 문구 변경이었습니다. 디자인, 구현, 검증 스테이지로 나뉘어 테스트 케이스 5건이 모두 통과했습니다. 사람이 한 일은 부모 이슈 작성과 배정, 사람 디자이너의 시안 수정, PR 리뷰와 머지, 만료된 클라우드 세션 재인증 한 번이었습니다.

오토파일럿

보통 스케줄이라고 부르는 오토파일럿은 크론으로 에이전트를 부릅니다. 앞 절의 정기 업무가 모두 이 방식이고, QA 기계의 클라우드 세션이 살아 있는지도 매일 아침 이렇게 확인합니다. 로컬 크론에서 옮겨 오면 실행 이력과 실패 알림을 워크스페이스에서 볼 수 있습니다.

그런데 개발 용도로는 또 다른 도구를 씁니다.

사업과 서비스기획은 Multica 에 정착했지만 개발 역할만큼은 직접 만든 dira 로 돌립니다. 앞에서 소개한 개발 스쿼드의 이름도 dira 입니다. PM, 디자이너, 개발자, QA, 아카이브 매니저라는 역할과 이름을 dira 의 페르소나에서 가져왔습니다.

에이전트끼리 무엇을 주고받는지 보고 싶었습니다

누가 누구에게 일을 넘겼고 어디서 막혔는지가 보고자 했습니다. 그렇다고 에이전트마다 인격을 입히고 싶지는 않았습니다. 에이전트의 장점은 살리되, 서비스 개발을 위한 여러 세션이 제 요구사항을 이루는 데만 집중하는 도구를 원했습니다. 하지만 입맛에 맞는 서비스를 찾지 못했고요. 그래서 만들기 시작했습니다.

작업 기록이 알아서 모이길 바랐습니다

작업 내용이 유실되면 다음 세션은 히스토리 없이 시작했고, 거기서 할루시네이션이 다시 생겼습니다. 이런 일이 너무 잦았습니다. dira 는 끝난 티켓에서 기능, 화면, 페르소나 같은 객체를 뽑아 프로젝트별 온톨로지에 쌓고, 객체마다 근거 티켓을 붙입니다. 사람이 따로 정리하지 않아도 작업이 끝날 때마다 채워집니다.

요즘은 쌓인 온톨로지를 개발이 아닌 일에도 참조해서 쓰고있습니다. 각 기능을 개발한 기록과 모든 정책이 여기 있으니깐 서비스 매뉴얼도 한 번에 뽑을 수 있고, 마케팅, 세일즈, CRM, 운영 작업의 컨텍스트로도 가져다 쓸 수 있습니다.

(dira 는 dira.proofer.tech 에서 써 볼 수 있습니다)

마무리

IDE 를 쓸 때 도구를 바꾼 계기는 취향차이 정도였던 것 같습니다. 하지만 에이전트 오케스트레이터까지 오는 과정에서는 사용성 다음에는 코드 컨텍스트가, 그다음에는 구독 정리가, 그다음에는 세션 수가 문제였습니다. 일이 코드 밖으로 번지자 대화 창이 필요했고, 짜 맞출 것이 많아지자 알아서 굴러가는 도구를 찾았습니다.

에이전트를 업무에 적극적으로 쓰기 시작한 후에는 도구를 고르는 기준이 바뀌었습니다. 이제는 에이전트가 무엇을 하는지 볼 수 있는지, 필요할 때 끼어들 수 있는지를 먼저 확인합니다. Paperclip 은 이 점에서 맞지 않았고, Buzz 는 이미 쓰던 Slack 조합과 차이가 작았습니다. Multica 가 적절했고, 개발과 그 기록은 dira 를 만들어 쓰고 있죠.

에이전트에게 맡기는 일이 늘어날수록 제 일은 구현이 아니라 판단과 승인으로 좁혀졌습니다. 그 판단을 해야 하는 순간을 놓치지 않게 제시해주고, 판단을 위한 컨텍스트와 인사이트를 제게 주입해줄 수 있는 도구가 지금으로써는 제게 제일 좋은 것 같습니다.

여러분들은 무슨 기준으로 도구를 선택하시나요?

출처

• Paperclip, paperclipai/paperclip
• Multica, multica-ai/multica
• Buzz 발표문 (Block), block/buzz
• Introducing Claude Tag (Anthropic)
• Hermes Agent, NousResearch/hermes-agent
• herdr, Orca
• IntelliJ IDEA, Cursor, Claude Code for VS Code