에이전트 오케스트레이터 '멀티카(Multica)'를 활용하여 실제 팀에서 에이전트를 굴려 보았습니다.

멀티카가 하루아침에 얼굴을 바꿨습니다

아침에 멀티카(Multica)를 열었다가 잠깐 멈칫했습니다. 어제까지 매일 보던 화면인데 로고와 색, 메뉴 위치가 바뀌어 있었습니다. 늘 누르던 버튼을 찾아 헤매는 동안 우리 에이전트들은 밤새 맡은 이슈를 처리해 두고 태연하게 다음 일을 기다리고 있었습니다.

마침 이번 업데이트는 클라우드에만 먼저 들어왔습니다. 프루퍼 주식회사는 multica.ai 클라우드 워크스페이스를 쓰고 한 뷰티회사의 IT팀은 사내 서버에 직접 올린 셀프호스트 워크스페이스를 씁니다. 같은 제품의 새 화면과 이전 화면을 나란히 놓고 볼 수 있게 된 김에, 지난 글에서 멀티카를 고른 배경을 다뤘다면 이번에는 멀티카 자체를 깊게 들여다봅니다.

멀티카(Multica)는 무엇인가

멀티카는 코딩 에이전트에게 동료처럼 이슈를 배정하는 프로젝트 관리 도구입니다. 사이트는 "사람과 에이전트로 이루어진 팀을 위한 프로젝트 관리"를 내걸고 있고 GitHub 저장소 설명에 따르면 Claude Code, Codex, Cursor 같은 코딩 에이전트에게 팀원처럼 이슈를 배정합니다. 에이전트는 보드에서 이슈를 집어 처리하고 진행 상황을 코멘트로 남기며 막히면 블로커를 올리고 끝나면 리뷰로 돌려줍니다.

만든 곳은 Index Labs, devv.ai 를 만들던 팀이 2025년에 이 문제로 방향을 틀었다고 합니다. 첫 공개 버전 v0.1.0 이 2026년 3월에 나왔고 3월부터 10월까지 릴리스가 130번 넘게 나왔습니다. 원래 평일이면 거의 매일 새 버전이 나오는 셈이라, 업데이트가 정말 잦았어요. 화면이 하루아침에 바뀌는 일도 처음은 아니었습니다.

사용자의 컴퓨터에 이미 설치되고 로그인된 Claude Code, Codex, Cursor Agent, GitHub Copilot CLI, Hermes 같은 도구를 런타임의 형태로 실행합니다. 공식 문서에 따르면 지원하는 도구가 스무 개가 넘는다고 합니다.

기본적으로는 이슈트래커입니다

에이전트 오케스트레이터는 에이전트에게 일을 어떤 틀로 주느냐에 따라 성격이 갈립니다.

• 터미널과 세션: herdr 나 Orca 는 여러 코딩 에이전트 세션을 한 화면에서 나란히 돌리고 상태를 보여 줍니다
• 채팅 채널: Buzz 나 Slack 에 붙인 Hermes 는 사람과 에이전트가 같은 채널에서 대화하며 일합니다
• 회사와 조직도: Paperclip 은 조직도에 에이전트를 앉히고 목표를 주면 에이전트가 일을 쪼개 끝까지 밀고 갑니다

그 중에서도 오늘 다루는 멀티카는 이슈트래커의 관점으로 접근합니다. 일의 단위는 이슈이고, 에이전트는 그 이슈를 배정받는 팀원입니다.

멀티카를 열면 먼저 보이는 것은 칸반 보드입니다. 이슈를 만들고 담당자를 정해 백로그에서 할 일, 진행 중, 리뷰 중, 완료로 옮기는 흐름은 Jira 나 Linear 를 써 본 사람이라면 바로 익숙합니다. 이슈는 프로젝트로 묶고 하위 이슈로 쪼갤 수 있고, 라벨과 사용자 정의 속성으로 분류합니다. 필터를 조합한 보기는 즐겨찾기에 저장해 두고, 날짜가 있는 이슈는 간트 보기로도 봅니다. 상태는 관리자가 직접 더 만들 수 있습니다.

일반 이슈트래커와 갈리는 곳은 담당자 칸입니다. 사람 대신 에이전트나 스쿼드를 고를 수 있고, 배정하는 순간 그 에이전트가 깨어나 일을 시작합니다. 에이전트도 사람처럼 코멘트를 남기고 상태를 바꾸기 때문에, 보드만 봐도 누가 어디까지 했는지 알 수 있습니다.

AI 는 이슈, 에이전트, 런타임에서 시작합니다

멀티카 문서가 정의하는 개념을 저희가 실제로 쓰는 방식에 맞춰 정리하면 아래와 같습니다.

에이전트는 스스로 일을 시작하지 않습니다. 이슈를 배정받거나, 코멘트에서 멘션되거나, 채팅으로 말을 걸거나, 오토파일럿이 부를 때 깨어납니다. 이슈 상태가 바뀌거나 하위 이슈가 끝나거나 연결된 PR 에 활동이 생겼을 때 깨우도록 걸어 둘 수도 있습니다.

실행은 내 컴퓨터나 클라우드 런타임이 맡습니다

이슈, 코멘트, 에이전트 설정, 실행 기록은 서버에 있고 실제 실행은 사용자 컴퓨터에서 도는 런타임 데몬이 맡습니다. 데몬은 15초마다 서버에 신호를 보내며 대기 중인 실행을 가져가 처리합니다. 코드와 자격증명은 그 컴퓨터를 떠나지 않습니다.

로컬 데몬 없이 클라우드에서 도는 런타임도 있습니다. 지금은 Qoder Cloud Agents 를 연결할 수 있고, Cursor Cloud Agents 와 Claude Managed Agents 는 런타임 화면에 출시 예정으로 올라와 있습니다. 문서에 따르면 클라우드 런타임에서는 로컬 폴더와 첨부 파일을 쓸 수 없다고 합니다. 저희는 아직 로컬 런타임만 씁니다.

로컬 런타임을 쓰면 회사 서버나 클라우드에 코드를 올리지 않고도 에이전트를 돌릴 수 있습니다. 대신 에이전트가 특정 컴퓨터에 묶입니다. 문서에 따르면 대기 중인 실행은 다른 컴퓨터로 넘어가지 않는다고 합니다. 운영하면서 가장 많이 부딪친 제약이 이것이었습니다.

Slack 과의 연동이 잘 되어있습니다.

멀티카는 Slack 봇을 지원합니다. Slack 앱을 만들어 멀티카 에이전트에 연결하면 그 에이전트가 Slack 봇으로 들어옵니다. 앱마다 에이전트가 하나씩 묶인다고 합니다.

DM 으로는 멘션 없이 바로 말을 걸고, 채널에서는 봇을 초대한 뒤 멘션하면 스레드마다 따로 대화가 이어집니다. 할 일을 적으면 에이전트가 제목과 본문을 정리해 멀티카 이슈로 만들어 주기도 합니다. 그래서 팀이 이미 Slack 에서 일한다면 멀티카를 열지 않고도 에이전트에게 일을 넘길 수 있습니다. Slack 말고도 Feishu, DingTalk, Telegram 봇도 연동할 수 있다고 하네요.

셀프호스트와 라이선스

멀티카는 클라우드로도, 직접 설치해서도 쓸 수 있습니다. 셀프호스트는 Docker Compose 로 웹과 API 서버, PostgreSQL 을 띄우고 에이전트를 돌릴 컴퓨터에서 셀프호스트 모드로 CLI 설정을 마치면 됩니다. 백엔드는 Go, 웹은 Next.js, 데스크톱 앱은 Electron 으로 만들어져 있습니다.

라이선스는 Apache 2.0 에 추가 조건을 붙인 Multica License 입니다. 조직 내부에서 쓰는 것은 셀프호스트를 포함해 무료입니다.

저희는 이렇게 씁니다

저희 워크스페이스에서는 한 달에 실행이 2,700번 넘게 돕니다. 개발 티켓을 맡기려고 처음 도입했는데 지금은 사업 업무 쪽 실행이 훨씬 많습니다.

일감 찾기는 인력사무소 스쿼드가 맡습니다

외주나 교육, 컨설팅 공고처럼 비딩을 거치는 일감을 찾는 일은 "인력사무소"라는 이름의 스쿼드가 합니다. 커리어데이, 위시켓, 크몽을 각각 맡은 스카우트 에이전트가 매일 아침 공고를 전수 조사하고 저희가 수주할 만한 건을 골라 지원서 초안까지 붙여 티켓으로 올립니다. 인바운드 문의는 플랫폼마다 따로 매시간 확인합니다. 제출과 수락은 대표가 승인한 뒤에만 하도록 지시문에 적어 두었습니다.

제품 운영과 경영지원도 에이전트가 나눠 맡습니다

포트폴리오 기반 인재 검색 서비스 포폴(pofol.works)은 에이전트 둘이 운영합니다. 포폴 시더는 매일 후보 포트폴리오를 조건에 맞춰 판정하고 적재하며 판단이 애매한 건은 심사 보류 티켓으로 올립니다. 포폴 마케터는 채널별 홍보를 맡는데 브랜드 계정에는 바로 게시하고 대표 명의로 나가는 글은 최종 초안까지만 만듭니다.

경영지원 쪽에는 부기 에이전트가 있습니다. 세금계산서 발행 현황을 맞춰 보고 매입 증빙과 입금을 대사하고 신고 일정을 챙깁니다. 발행이나 송금처럼 돈이 움직이는 일은 대표 승인 뒤에만 합니다.

일이 끝나면 아카이브 매니저가 기록합니다

매일 새벽 6시에는 아카이브 매니저가 전날 움직인 이슈를 하나씩 훑습니다. 결정과 근거, 새로 드러난 사실을 회사 공유 드라이브의 지식 저장소에 옮겨 적고 맥락이 부족한 티켓은 담당자를 멘션해 되묻습니다. 티켓 밖에서 사람이 직접 고친 파일도 지난 회차와 비교해 찾아냅니다. 덕분에 멀티카에서 끝난 일이 다음 세션의 컨텍스트로 이어집니다.

이슈 본문이 그대로 에이전트의 작업 지시서가 된다는 점이 멀티카를 쓰면서 가장 편한 부분이었습니다. 지시를 고치고 싶으면 오토파일럿 템플릿을 고치면 되고 회차마다 무엇을 받았는지는 이슈에 남습니다.

개인적인 일에도 멀티카를 쓸 수 있습니다

멀티카는 개인 업무에도 그대로 쓸 수 있습니다. 제 경우에는 개인 지식 저장소를 정리하는 아카이브 매니저를 두고 있고, 매주 내는 자문 뉴스레터도 후보 채점부터 조립, 검수까지 에이전트에게 맡기고 마지막 초안만 봅니다.

제 개인 PB팀은 이렇게 짜여 있습니다. 팀장 에이전트 아래에 리서치, 시장 분석, 데이터 수집, 가치평가 담당이 있고 전략 변경 제안이 올라오면 공격 쪽과 수비 쪽 심의 에이전트가 각자 논거를 냅니다. 실행 결과는 감사 에이전트가 규칙과 대조합니다.

뷰티회사 IT팀에서는 이렇게 씁니다

2026년 7월 사내 서버에 멀티카를 셀프호스트로 올렸습니다. 8월에는 업무 트래킹을 Jira 에서 Slack 리스트를 거쳐 멀티카로 옮겼습니다. 옮기면서 가져온 이슈만 1,400건이 넘었습니다.

이슈와 코멘트에는 주문, 정산, 파트너사 이야기처럼 사내 정보가 쌓입니다. 이 데이터를 회사 밖 서버에 두고 싶지 않아 셀프호스트를 골랐습니다.

서버를 포크해 직접 고칠 수 있다는 점도 컸습니다. Slack 에서 멀티카 이슈를 카드로 펼치고 바로 담당자를 정하거나 에이전트에게 넘기는 연동을 따로 만들어 붙였고, GitHub 와 Slack 이벤트를 웹훅으로 받아 오토파일럿을 깨웁니다.

팀원 노트북이 곧 런타임입니다

셀프호스트 워크스페이스에는 팀 공용 맥미니와 팀원 각자의 노트북이 런타임으로 붙어 있습니다. 제가 만든 공용 업무용 스쿼드 뿐만 아니라 팀원들이 자기 업무에 맞춰 직접 만든 에이전트가 더 많습니다. 한 사람이 에이전트를 만들어 팀에 나눠 주는 대신, 각자 자기 컴퓨터를 런타임으로 붙이고 자기 에이전트를 키우는 방식으로 퍼졌습니다.

개발 스쿼드는 PM, 디자이너, 개발자, QA, 아카이브 매니저로 구성됩니다. 부모 이슈를 스쿼드에 배정하면 PM 이 하위 이슈로 쪼개 단계를 정하고 구성원을 멘션해 깨웁니다. 디자이너와 QA 는 직접 일을 주고받지 않고 PM 을 거칩니다. 화면이 어떻게 보이는지는 디자이너가, 어떻게 동작하는지는 QA 가 판정하고 그 사이 빈틈은 PM 이 메웁니다.

웹훅으로 사내 도구와 잇습니다

IT팀 오토파일럿은 웹훅으로도 깨어납니다. 운영 배포가 나가면 패치노트를 써서 Slack 에 올리고 GitHub PR 코멘트를 멀티카 이슈와 잇고 Slack 버튼 응답을 이슈로 받아 옵니다. 일정으로 도는 쪽에는 Datadog 기반 성능 분석, 앱 스토어 릴리스 감지, 완료 티켓 속성 점검, 디자인 시안 스냅샷 점검이 있습니다.

성능 분석은 에이전트가 정기적으로 APM 을 훑어 이슈 수집, 원인 분석, 개선안을 단계별 이슈로 올리는 방식으로 돕니다. 개선안을 맡은 에이전트가 레포 코드를 읽고 수집 단계의 원인 전제를 바로잡은 적도 있고 제안에서 그치지 않고 PR 까지 낸 회차도 있었습니다.

AI 를 들인 뒤 달라진 것

주요 저장소에 머지된 PR 가운데 AI 가 참여한 비중은 작년 2% 에서 올해 61% 로 올랐고, 7월 이후만 보면 82% 입니다. 대부분은 사람과 AI 가 함께 만든 PR 이고, 머지는 언제나 사람이 검토한 뒤에 했습니다.

개발자 한 명이 한 달에 머지하는 PR 은 13건에서 68건으로 늘었습니다.

개발 밖의 일도 달라졌습니다. 월간 리텐션 지표를 갱신하려면 데이터를 내려받아 가공하는 데 하루가 걸렸는데, 지금은 AI 에게 물어 DB 에서 바로 집계합니다.

이 모든 변화의 기반에는 Claude 와 Multica가 있었습니다.

AI 도입을 고민하고 있다면

SaaS들이 모두 마찬가지지만 AI SaaS들은 특히나 설치는 금방 끝나지만 실제 업무를 올려 돌리기까지가 참 어렵습니다. 어떤 업무를 이슈 단위로 쪼갤지, 에이전트에게 무엇을 하지 말라고 적을지, 어느 컴퓨터에 무엇을 둘지를 정해야 실제 업무가 돌기 시작합니다.

어떤 AI SaaS 를 선택해야 할지도 고민입니다. 에이전트 오케스트레이터만 해도 터미널, 채팅 채널, 조직도, 이슈트래커처럼 접근 방식이 제각각이죠. 그래서 저희는 에이전트가 무엇을 하는지 볼 수 있는지, 필요할 때 끼어들 수 있는지를 먼저 보고 있습니다. 팀이 지금 일하는 방식에 맞는지도 중요한 검토요소입니다. 이미 Slack 에서 대화로 일하던 팀이 Buzz로 옮겨 가는 것은 그 자체로 비용이 되겠죠?

프루퍼 주식회사는 직접 운영하며 쌓은 경험으로 다른 조직의 AI 전환을 돕고 있습니다. 멀티카 같은 에이전트 도구를 업무에 붙이는 일부터 팀이 일하는 방식을 바꾸는 일까지 함께 합니다. AI 도구를 들였는데 일하는 방식은 그대로라면 지금 쓰는 방식을 점검해 실제 업무가 돌도록 보완합니다. 처음 시작하는 조직과는 어떤 업무를 먼저 에이전트에게 맡길지 정하는 일부터 함께 합니다. 자세한 내용은 프루퍼 주식회사 AX 서비스에서 보실 수 있습니다.

출처

• Multica, multica-ai/multica
• Multica 문서: 개념, 런타임, 셀프호스트
• Multica 변경 로그, Multica License
• Multica 문서: Slack 봇