Multica: AI 에이전트를 팀원처럼 운영하는 AI 네이티브 프로젝트 관리 도구

AI 코딩 에이전트가 점점 똑똑해지면서, 이제 문제는 “에이전트가 코드를 잘 짜는가”가 아니라 “그 에이전트를 팀 안에서 어떻게 운영할 것인가”로 넘어가고 있습니다. 채팅창에서 한 번 요청하고 끝나는 수준이 아니라, 이슈를 받고, 상태를 바꾸고, 댓글을 남기고, 실제 로컬 코드베이스에서 작업까지 수행하는 존재로 다뤄야 하기 때문입니다. Multica는 바로 그 지점을 겨냥합니다. 이 프로젝트는 AI를 보조 도구가 아니라 프로젝트 관리 시스템의 정식 팀원으로 끌어올리려는 시도입니다. (GitHub)

 

multica/README.md at main · multica-ai/multica

 

---

프로젝트 소개

Multica는 한 문장으로 요약하면 “Linear 같은 프로젝트 관리 UX 위에, 로컬에서 실행되는 AI 에이전트를 1급 구성원으로 올린 시스템”입니다. 저장소 설명에서도 스스로를 “AI-native project management”라고 소개하고 있고, 에이전트는 이슈에 할당될 수 있으며 댓글을 남기고 상태를 갱신하고, 사용자의 로컬 머신에서 실제 작업을 수행할 수 있습니다. 즉, 단순히 LLM에게 답변을 받는 제품이 아니라, 이슈 트래커와 실행 런타임을 결합한 협업 플랫폼에 가깝습니다. (GitHub)

구성은 생각보다 명확합니다. 프런트엔드는 Next.js 16 App Router 기반의 웹 앱이고, 백엔드는 Go + Chi 라우터 + WebSocket 구조이며, 데이터 저장소는 PostgreSQL 17과 pgvector를 사용합니다. 여기에 별도로 각 사용자의 로컬 머신에서 동작하는 multica CLI/daemon이 붙어서 Claude Code 또는 Codex 같은 에이전트 CLI를 감지하고 작업을 실행합니다. 즉, SaaS형 이슈 관리 앱 + 로컬 에이전트 실행기 + 실시간 동기화 계층이 합쳐진 형태입니다. (GitHub)

이 프로젝트를 만든 주체는 저장소 기준으로 multica-ai 조직입니다. 저장소에는 클라우드로 바로 시작하는 방식과 셀프 호스팅 방식이 둘 다 제공되고, CLI와 데몬, 백엔드 서버, 웹 프런트가 한 저장소에 함께 들어 있어 제품 전체를 오픈소스로 공개하는 방향을 취하고 있습니다. (GitHub)

---

왜 이 프로젝트가 등장했을까

지금까지 AI 코딩 도구의 기본 사용 방식은 대체로 비슷했습니다. 개발자가 IDE나 채팅창에서 모델에게 요청하고, 모델이 답하고, 사람이 그 결과를 다시 프로젝트 관리 흐름에 반영합니다. 이 구조에서는 AI가 아무리 잘해도 여전히 **“작업 단위의 주체”**가 아니라 **“대화 상대”**에 머뭅니다. 이슈 담당자, 상태 변경자, 진행 상황 보고자라는 역할은 끝내 사람이 대신해야 했습니다. Multica는 이 단절을 줄이기 위해, 프로젝트 관리 도구의 객체 모델 안에 에이전트를 넣으려 합니다. 에이전트를 이슈에 직접 할당하고, 작업 진행을 실시간으로 업데이트하고, 결과를 다시 시스템에 반영하도록 설계한 이유가 여기에 있습니다. (GitHub)

또 하나의 배경은 실행 위치입니다. 많은 AI 제품은 중앙 서버에서 모든 작업을 처리하려 하지만, 실제 코드 작업은 로컬 저장소 접근, 개발자 인증 정보, 도구 체인, 브랜치 상태, OS 환경에 크게 의존합니다. Multica는 이 점을 인정하고, 에이전트 실행을 서버가 아니라 사용자 머신의 로컬 데몬에 맡깁니다. README와 CLI 문서 모두 에이전트가 로컬에서 실행되며, 데몬이 설치된 AI CLI를 감지하고, 작업이 오면 격리된 워크스페이스 디렉터리를 만들어 실행한 뒤 결과를 서버로 보고한다고 설명합니다. 이 구조는 “클라우드에서 다 해주겠다”보다 덜 마법 같지만, 실제 개발 워크플로에는 훨씬 현실적입니다. (GitHub)

결국 Multica가 푸는 문제는 단순한 AI 보조가 아닙니다. 에이전트가 팀의 업무 시스템 안에서 어떻게 식별되고, 할당되고, 실행되고, 관찰되고, 기록되는가입니다. 그래서 이 프로젝트를 보면 프로젝트 관리, 런타임 등록, heartbeat, 작업 claim, 진행 보고, WebSocket 브로드캐스트, 워크스페이스 감시 같은 개념이 함께 등장합니다. 이것은 챗봇이 아니라 운영체계에 가까운 발상입니다. (GitHub)

---

핵심 기능

1. 에이전트를 사람처럼 이슈에 참여시키는 협업 모델

Multica의 가장 큰 특징은 에이전트를 “호출하는 도구”가 아니라 “참여하는 구성원”으로 취급한다는 점입니다. 저장소 설명에 따르면 에이전트는 이슈에 할당될 수 있고, 댓글을 남길 수 있으며, 상태를 갱신할 수 있습니다. 백엔드 라우터를 보면 실제로 이슈, 댓글, 타임라인, active task, task runs, agent, skill, runtime 관련 API가 분리되어 있어서, 단순 프롬프트 호출이 아니라 프로젝트 관리 도메인으로 구조화되어 있음을 확인할 수 있습니다. (GitHub)

이 관점은 개발자 경험을 크게 바꿉니다. 예를 들어 “이 기능 구현해줘”를 채팅에 던지는 대신, 이슈를 만들고 에이전트에게 할당하고, 팀원들은 같은 보드에서 진행 상태와 산출물을 확인할 수 있습니다. 사람과 AI가 같은 단위의 워크플로를 공유하게 되는 셈입니다. (GitHub)

2. 로컬 머신에서 동작하는 에이전트 런타임

Multica의 실행 핵심은 웹앱이 아니라 multica daemon입니다. CLI 문서에 따르면 데몬은 로그인 후 워크스페이스를 자동으로 watch list에 추가하고, 지원되는 AI CLI를 PATH에서 감지해 런타임으로 등록합니다. 현재 문서상 지원 대상으로 명시된 것은 claude와 codex입니다. 작업이 생기면 데몬은 격리된 워크스페이스 디렉터리를 만들고, 에이전트 CLI를 실행하고, 결과를 서버에 스트리밍합니다. (GitHub)

이 구조가 중요한 이유는 두 가지입니다. 첫째, 실제 코드베이스 접근이 쉽습니다. 둘째, 각 팀원이 가진 개발 환경을 그대로 활용할 수 있습니다. 중앙 서버에서 repo를 복제해서 추측성으로 실행하는 방식보다, 로컬 워크스페이스에서 도구 체인과 인증 정보를 활용하는 방식이 실제 업무에 더 가까운 경우가 많습니다. 데몬 코드에서도 watched workspace 로딩, repo cache 동기화, heartbeat, usage scan, poll loop 같은 운영 로직이 분리되어 있어 이 부분이 제품의 중심임을 알 수 있습니다. (GitHub)

3. 실시간 협업을 위한 WebSocket 기반 동기화

README는 보드 전반의 live update를 WebSocket 기반으로 제공한다고 설명합니다. 실제 코드에서도 realtime.Hub가 워크스페이스별 room을 관리하고, JWT와 워크스페이스 멤버십을 검증한 뒤 WebSocket 연결을 올립니다. 메시지는 특정 워크스페이스에만 브로드캐스트할 수도 있고, 특정 사용자에게 보낼 수도 있으며, 느린 클라이언트는 정리하는 구조까지 포함되어 있습니다. (GitHub)

이건 단순히 화면이 실시간으로 바뀐다는 뜻이 아닙니다. 에이전트가 작업을 시작하고, 진행률을 보고하고, 완료하거나 실패했을 때, 그 상태가 팀 전체의 작업 보드와 인박스에 즉시 반영되는 기반입니다. 프로젝트 관리 도구에서 AI를 팀원처럼 느끼게 만들려면, 사실 이 WebSocket 계층이 필수입니다. (GitHub)

4. 워크스페이스, 런타임, 스킬을 분리한 운영 모델

라우터를 보면 Multica는 단순히 “에이전트 목록”만 두지 않습니다. 워크스페이스, 에이전트, 스킬, 런타임, 인박스가 모두 별도 API 단위로 존재합니다. CLI 문서에서도 watched workspace 개념이 있고, 데몬은 워크스페이스별로 런타임을 등록합니다. 즉, 한 사용자의 머신에서 여러 워크스페이스를 감시하고, 각 워크스페이스에 대해 어떤 에이전트 런타임이 online 상태인지 서버가 추적하는 구조입니다. (GitHub)

이 설계는 팀 단위 운영에 적합합니다. 에이전트의 정체성, 기능 집합, 실제 실행 주체를 분리했기 때문에, 나중에 특정 머신의 런타임 상태를 따로 관찰하거나, 워크스페이스별 권한과 사용량을 따로 관리하기 쉬운 형태입니다. (GitHub)

---

프로젝트 아키텍처 분석

Multica의 전체 구조는 표면적으로는 단순합니다. 하지만 내부를 뜯어보면 **“이슈 관리 시스템 + 이벤트 버스 + 실시간 브로드캐스트 + 로컬 실행기”**라는 네 층으로 나뉩니다. README의 아키텍처 설명에는 Next.js 프런트엔드, Go 백엔드, PostgreSQL, 로컬 Agent Daemon이 등장하고, 실제 서버 엔트리포인트에서는 DB 연결 후 event bus와 realtime hub를 만들고, 리스너를 등록한 뒤 라우터를 구성합니다. 이 순서 자체가 Multica의 핵심 실행 경로를 잘 보여줍니다. (GitHub)

조금 더 내부적으로 보면, 서버는 Chi 라우터 위에 인증, 워크스페이스 멤버십, 역할 기반 제어를 얹고, /ws 엔드포인트로 실시간 연결을 받습니다. 동시에 /api/daemon/* 아래에는 런타임 등록, heartbeat, task claim, progress reporting, completion reporting 같은 로컬 실행기 전용 API가 따로 열려 있습니다. 즉, 사용자용 API와 실행기용 API가 한 백엔드 안에서 공존하지만 역할은 분명히 분리되어 있습니다. (GitHub)

특히 흥미로운 부분은 event bus입니다. events.Bus는 인프로세스 synchronous pub/sub로 구현되어 있고, 이벤트 타입별 핸들러와 global handler를 등록할 수 있습니다. 서버 메인에서는 이 버스를 만들고, subscriber/activity/notification 리스너를 등록합니다. 이 말은 곧, 이슈 생성이나 상태 변경 같은 도메인 이벤트가 발생했을 때 DB 반영, 알림 생성, 실시간 브로드캐스트 같은 후속 작업이 이벤트 중심으로 엮여 있다는 뜻입니다. 구조가 거창한 분산 이벤트 시스템은 아니지만, 제품 특성에는 꽤 잘 맞습니다. (GitHub)

또 하나 눈에 띄는 것은 daemon 쪽의 repo cache와 watched workspace 모델입니다. 데몬은 실행 시 인증을 해석하고, 감시 중인 워크스페이스를 불러오고, 각 워크스페이스에 대해 사용 가능한 런타임을 등록합니다. 이후 새 워크스페이스를 API에서 발견하면 설정에 추가하고, config 변경을 감시해 런타임 구성을 다시 맞춥니다. 즉, 데몬은 단순한 작업 실행기가 아니라 로컬 런타임 매니저에 가깝습니다. (GitHub)

---

코드로 보면 더 잘 보이는 Multica의 작동 방식

Multica를 이해하는 가장 좋은 방법은 “어떤 API 흐름이 존재하는가”를 보는 것입니다. 저장소 라우터 기준으로 데몬은 대략 이런 흐름으로 서버와 통신합니다. (GitHub)

1. multica login
2. multica daemon start
3. daemon -> /api/daemon/register
4. daemon -> /api/daemon/heartbeat
5. daemon -> /api/daemon/runtimes/{runtimeId}/tasks/claim
6. daemon -> /api/daemon/tasks/{taskId}/start
7. daemon -> /api/daemon/tasks/{taskId}/progress
8. daemon -> /api/daemon/tasks/{taskId}/messages
9. daemon -> /api/daemon/tasks/{taskId}/complete or fail

이 흐름은 에이전트를 단순 RPC 호출로 다루지 않는다는 점을 잘 보여줍니다. 작업은 claim되고, 시작 상태가 찍히고, 중간 진행률과 메시지가 별도로 보고되며, 완료와 실패도 명시적으로 기록됩니다. 이런 식으로 모델 실행을 상태 기계처럼 다루면, 프로젝트 관리 시스템과 훨씬 잘 결합됩니다. (GitHub)

실제 사용 시작도 단순합니다. 문서 기준 quick start는 아래와 같습니다. (GitHub)

# 설치
brew tap multica-ai/tap
brew install multica-cli

# 로그인
multica login

# 로컬 에이전트 데몬 실행
multica daemon start

셀프 호스팅도 복잡한 편은 아닙니다. PostgreSQL은 pgvector/pgvector:pg17 이미지를 사용하고, 환경 변수에는 DB 연결, JWT, 서버/앱 URL, OAuth, S3/CloudFront 관련 설정이 포함됩니다. 즉, “프로젝트 관리 SaaS”에 필요한 기본 인프라와 “에이전트 협업 제품”에 필요한 업로드/인증/실시간 연결 구성이 함께 들어 있습니다. (GitHub)

git clone https://github.com/multica-ai/multica.git
cd multica
cp .env.example .env

docker compose up -d
make build
DATABASE_URL="your-database-url" ./server/bin/migrate up
DATABASE_URL="your-database-url" PORT=8080 ./server/bin/server

pnpm install
pnpm build
cd apps/web
REMOTE_API_URL=http://localhost:8080 pnpm start

---

기술 스택을 개발자 관점에서 해석해보면

프런트엔드는 Next.js 16 기반이고, 패키지를 보면 Tiptap, dnd-kit, react-markdown, Recharts, shadcn, zustand 같은 조합이 들어 있습니다. 이 선택은 꽤 의도가 분명합니다. 리치 텍스트 편집, 드래그앤드롭 보드 UX, 마크다운/코드 렌더링, 대시보드성 시각화, 상태 관리가 모두 필요하기 때문입니다. 즉, 단순 랜딩 페이지가 아니라 “실제로 매일 쓰는 작업 도구”를 만들기 위한 조합입니다. (GitHub)

백엔드는 Go 1.26 계열 위에서 Chi, CORS, JWT, Gorilla WebSocket, pgx, Cobra, AWS SDK, Resend SDK 등을 사용합니다. 여기서 읽히는 메시지는 간단합니다. HTTP 라우팅은 가볍게, 실시간 통신은 검증된 WebSocket 라이브러리로, CLI는 Cobra로, 스토리지와 비밀 관리는 AWS로, 이메일은 Resend로 처리하는 실용적 선택입니다. 거대한 프레임워크보다는 운영 단위가 분명한 조합입니다. (GitHub)

데이터베이스에 PostgreSQL 17과 pgvector가 들어 있는 점도 흥미롭습니다. 현재 확인한 라우팅/문서만으로는 vector search가 제품 어디에 깊게 쓰이는지까지 단정하긴 어렵지만, 최소한 저장소는 pgvector를 전제로 설치와 운영을 안내합니다. 따라서 장기적으로는 스킬, 문서, 컨텍스트 검색, 검색 보강형 에이전트 경험 같은 확장 지점을 염두에 둔 설계로 해석할 수 있습니다. 이 부분은 코드 단편만으로는 추정의 영역이므로, 현재 공개된 문서에서 확실한 사실은 “pgvector가 인프라 전제조건으로 포함되어 있다”는 점입니다. (GitHub)

---

이 프로젝트가 특히 잘 맞는 사용 시나리오

Multica는 “AI 채팅이 필요하다”는 이유만으로 도입할 도구는 아닙니다. 오히려 아래 같은 상황에서 진가가 큽니다. 첫째, 이슈 단위로 업무를 운영하고 있고 AI에게도 명확한 작업 단위를 넘기고 싶은 팀입니다. 둘째, 로컬 코드베이스 접근이 필요해서 에이전트를 중앙 서버보다 개발자 머신에 붙이는 편이 현실적인 조직입니다. 셋째, 사람과 AI의 작업 로그를 같은 보드와 타임라인 안에서 보고 싶은 팀입니다. 이 저장소의 워크스페이스, 이슈, 타임라인, active task, task runs, runtime usage, inbox 구조가 바로 그런 운영 모델을 향하고 있습니다. (GitHub)

예를 들어 이런 식입니다. 백로그에 “OAuth 로그인 리다이렉트 버그 수정” 이슈를 만들고, 이를 특정 에이전트에게 할당합니다. 데몬이 해당 워크스페이스를 감시 중이면 작업을 claim하고 로컬 저장소에서 에이전트 CLI를 실행합니다. 진행 상황은 보드에 실시간으로 반영되고, 완료되면 결과 메시지와 작업 상태가 다시 프로젝트 관리 시스템에 기록됩니다. 이 경험은 IDE 내부의 단발성 AI 호출보다 훨씬 팀 협업형입니다. (GitHub)

반대로, 개인이 혼자 짧은 코드 스니펫을 생성하는 수준이라면 Multica는 다소 무겁게 느껴질 수 있습니다. 이 프로젝트는 단순 프롬프트 도구가 아니라 운영 체계를 만드는 제품이기 때문입니다. 워크스페이스, 인증, 런타임 등록, 데몬, 실시간 업데이트 같은 계층이 모두 필요하다는 점이 장점이자 진입 비용입니다. (GitHub)

---

내가 본 Multica의 핵심 가치

Multica를 보며 가장 인상적인 점은 “AI를 더 똑똑하게 만드는 일”보다 “AI를 조직 안에서 다룰 수 있게 만드는 일”에 집중했다는 것입니다. 저장소의 핵심은 모델 추론 자체보다도, 런타임 등록, 워크스페이스 감시, 태스크 claim, heartbeat, 진행 보고, 실시간 브로드캐스트, 권한 검증 같은 운영 요소에 있습니다. 다시 말해 Multica는 새로운 LLM을 내세우는 프로젝트가 아니라, 에이전트 시대의 프로젝트 운영 소프트웨어를 만들고 있습니다. (GitHub)

이 방향은 앞으로 점점 중요해질 가능성이 큽니다. 에이전트의 성능이 상향 평준화될수록 차이를 만드는 것은 모델 자체보다도, 그 모델을 누가 어떤 권한으로 어디서 실행하고 어떤 기록을 남기며 팀과 어떻게 협업하게 할 것인지가 될 가능성이 높기 때문입니다. Multica는 바로 그 문제를 꽤 정직한 방식으로 풀고 있습니다. 서버는 조율하고, 로컬 데몬은 실행하고, WebSocket은 공유하고, 프로젝트 관리 UI는 그것을 사람의 업무 흐름과 연결합니다. (GitHub)

---

마무리

Multica는 “AI가 일을 대신한다”는 추상적 문장을, “AI가 이슈를 받고 로컬 환경에서 실행하고 결과를 보드에 남긴다”는 구체적 시스템으로 바꿔낸 프로젝트입니다. 그래서 이 저장소는 단순한 AI 툴이 아니라, 앞으로의 개발 조직이 에이전트를 어떤 단위로 운영할지 보여주는 흥미로운 프로토타입이기도 합니다. AI를 팀원처럼 다뤄야 한다고 느끼기 시작한 팀이라면, Multica는 꽤 진지하게 살펴볼 가치가 있는 오픈소스입니다. (GitHub)