Multica로 AI 태스크 관리 해보기 (GCE 런타임 구축까지)

AI 에이전트를 태스크 보드에서 관리할 수 있는 「Multica」를 시도해 보고, 나아가 보안을 위해 GCE 상에 런타임을 구축하는 것까지 진행해 보았습니다.

Multica

Multica는 AI 에이전트를 마치 팀원처럼 만들어 줍니다. issue 등의 태스크 보드를 인간과 AI 에이전트가 공동으로 관리 및 소비할 수 있습니다. SKILL의 자동 업데이트 기능도 갖추고 있어, 한 번 완료한 태스크는 다음부터 원활하게 소화할 수 있습니다.

기능

Agents as Teammates— 에이전트를 팀원처럼 할당할 수 있습니다. 프로필을 가지며, 보드에 등장하고, 댓글을 게시하고, issue를 생성하며, 블로커(blocker)를 선제적으로 보고합니다. -
Autonomous Execution— 태스크의 라이프사이클 전체(enqueue / claim / start / complete / fail)를 관리하며, WebSocket을 통해 실시간으로 진행 상황을 스트리밍합니다. -
Reusable Skills— 한 번 구현한 해결책은 재사용 가능한 Skill로서 팀 전체에 축적됩니다. 배포, 마이그레이션, 코드 리뷰 등 팀의 능력이 시간이 지남에 따라 쌓여갑니다. -
Unified Runtimes— 로컬 데몬(daemon)과 클라우드 런타임을 단일 대시보드에서 일원 관리합니다. 사용 가능한 CLI를 자동으로 감지하고 실시간으로 모니터링할 수 있습니다. -
Multi-Workspace— 팀별로 워크스페이스를 분리하여 관리할 수 있습니다. 각 워크스페이스는 독자적인 에이전트, issue, 설정을 가집니다.

Claude Managed Agents와의 비교

Claude Managed Agents와 매우 유사한 특징도 가지고 있습니다.

Claude Managed Agents	Multica
에이전트 정의·재사용	○
...

환경 구축

Windows에서도 사용할 수 있으며, 셀프 호스팅도 가능합니다. 이번에는 MacOS CLI, 클라우드 전제로 구축해 나가겠습니다.

brew install multica-ai/tap/multica
multica setup

로그인합니다.

multica login

런타임을 실행합니다.

multica daemon start

백그라운드에서 실행되었습니다. 이것은 폴링(polling)으로 통신하며, Go 바이너리로 가볍고, 기본적으로는 계속 켜두어도 된다고 합니다. (용도에 따라 다름)

중지할 때는 다음 명령어를 입력합니다.

multica daemon stop

사용해 보기

데스크톱 앱도 있지만, Electron 기반이라 메모리가 신경 쓰이는 저는 Web UI로 진행하기로 했습니다. 이후로는 Web UI로 작업하겠습니다.

Runtimes 확인

방금 로컬에서 daemon을 실행했을 때, 런타임이 자동으로 등록되어 있습니다. daemon을 중지해도 남아 있었기 때문에, 디바이스별로 남겨두는 것으로 보입니다. 저의 경우에는 Cursor, Claude Code, Codex가 등록되어 있었습니다. 설치 상황을 보고 자동으로 등록해 주는 것 같습니다.

Agents 생성

에이전트를 생성합니다. 「Local Claude Code」로서, 자신의 머신의 Claude Code를 등록했습니다. Teammate와 Private을 선택할 수 있어 팀에서 사용할 경우의 선택지가 넓어집니다.

생성 후, 다음과 같은 정보도 등록할 수 있게 됩니다.

Instructions: 시스템 프롬프트 (System Prompt) -
Custom Env: CLI 프로세스에 주입할 환경 변수 (ANTHROPIC_API_KEY, ANTHROPIC_BASE_URL, CLAUDE_CODE_USE_BEDROCK 등) -
Custom Args: CLI 실행 시의 추가 인자 (--model, --thinking 등) -
Skills: 워크스페이스의 Skill

issue 생성

Issue는 다음과 같은 상태(status)가 있습니다.

Backlog: 축적
Todo: 실행 대기
In Progress: 실행 중
In Review: 리뷰 대기
Done: 완료

Assignee(담당자)에 방금 전의 Local Claude Code를 지정하고, 다음과 같은 issue를 생성했습니다.

Say hello

곧바로 Claude Code가 issue의 상태를 변경하였고, 잠시 후 "hello"라고 답장한 뒤 issue는 In Review 상태로 이동되었습니다.

조사

로컬의 Claude Code는 어디에서 실행되고 있는 것일까요? 다음과 같은 issue를 던져보았습니다.

Show me pwd

pwd는 현재 디렉터리를 표시하는 명령어입니다. 결과는 다음과 같았습니다.

/Users/masaaki/multica_workspaces/10ecbf59-dd7a-4068-b94a-a0c1d23fea30/e427aa83/workdir

이 경로는 agent + issue 조합으로 유니크(Unique)하게 생성된다고 합니다.

다른 디렉터리도 읽을 수 있을까요? 다음과 같은 issue를 던져보겠습니다.

Move to User Directory. And show me pwd.

결과는 다음과 같았습니다.

Moved to user directory. pwd output: /Users/masaaki
Note: Shell state (including cwd) does not persist between commands in this environment, so the working directory was reset back to the workdir after the command.

초기 디렉터리에서 사용자 디렉터리로 이동되었습니다. 명령어를 한 줄로 실행한 것으로 보여 Claude Code의 Note가 나타났지만, 실용적인 측면에서는 문제가 없을 것으로 보입니다.

보안 리스크

초기 디렉터리 외에서도 작업할 수 있다는 점이 확인되었는데, 이는 관점을 바꾸면 보안 리스크가 될 수 있습니다. AI가 폭주할 경우 로컬 데이터가 소실되거나, 가장 무서운 시나리오는 로컬에 있는 비밀 정보(Secret)를 이용해 GitHub 리포지토리 등을 파괴하는 상황도 고려할 수 있습니다.

로컬 운용은 권장하지 않습니다.

로컬 이외에서 실행하기

Multica의 아키텍처는 "서버(issue 보드)"와 "daemon(agent 실행 환경)"이 분리되어 있으며, 위험한 쪽은 후자입니다. daemon을 메인 머신 이외에서 구동하는 선택지를 정리했습니다.

선택지	격리도	수고	코멘트
자신의 메인 Mac	최저	0	모든 비밀 정보에 접근 가능
...

Provider에 따른 구분

Provider에 따라 보호 수준도 달라집니다.

Claude Code: 파일 시스템 샌드박스(Sandbox) 없음 (OS 권한에 의존) -
Codex: 버전에 따른 독자적인 샌드박스 있음 (Multica 공식 문서에도 언급) -
Cursor Agent / Gemini 등: 각 CLI의 구현 방식에 따름

당면한 해결 방법

Hetzner나 Vultr에서 월 수백 엔 정도의 Linux VM을 빌려 그곳에서 multica daemon start 실행. 키(Key) 종류는 일절 두지 않고, PR(Pull Request)만 생성하게 한 뒤 머지(Merge)는 사람이 GitHub에서 수행
Docker / Kubernetes를 사용하여 daemon + CLI를 컨테이너화하고, 볼륨을 제한적으로 마운트
"issue에 쓰는 내용 = 해당 VM에서 수행해도 되는 작업"이라고 선을 긋기

용도 생각하기

예를 들어 다음과 같은 사용 방법이 가능합니다.

완전히 자신 전용

완전히 자신 전용이라면 가장 심플합니다. 원하는 디렉터리를 지정하여 그곳에서 다양한 태스크를 실행할 수 있습니다.

팀 단위 운용

팀 단위가 되면 성격이 달라집니다. 워킹 디렉터리(Working Directory)에 매번 데이터를 가져와야 합니다. 예를 들어 매번 git clone을 하여 코드를 수정하고 PR을 내는 등의 사용법이 상정됩니다.

참고로 팀 운용 시 로컬에서 실행하는 것은 가장 위험합니다.

역할 특화 에이전트의 병행 운용

공식 문서나 리뷰 기사에서 자주 언급되는 구성은 역할을 나눈 여러 에이전트를 동시에 실행하는 방식입니다. 예를 들어 「Frontend Agent」, 「Backend Agent」, 「Security Agent」, 「QA Agent」를 각각 별도의 Instructions(지침) 및 Skill(기술)로 생성하고, issue의 라벨이나 Assignee(담당자)를 통해 배분합니다. 혼자 개발하더라도 담당을 나누는 것만으로 Skill이 섞이지 않아 정밀도가 안정됩니다.

장시간 태스크의 방류

리팩터링(Refactoring), 의존 라이브러리의 일괄 업데이트, 테스트 추가, 문서 정비 등 "하면 좋지만 뒤로 미루게 되는 작업"을 issue에 쌓아두고, 여유 시간에 모아서 할당하는 방식입니다. 사람이 손대지 않는 야간이나 주말에 AI가 작업을 진행합니다.

정기 운용 (Autopilot)

cron 방식의 트리거로 issue를 자동 생성 및 자동 할당하는 Autopilot 기능이 있으며, 다음과 같은 운용에 사용할 수 있습니다.

매일 아침, 미처리 issue를 모아서 트리아지(Triage)
매주 월요일, 의존 패키지의 취약점 체크 및 PR(Pull Request) 생성
PR이 생성될 때마다 다른 에이전트가 자동 리뷰
정기 백업, 헬스 체크(Health Check), 리포트 생성

지식 축적 기반으로서의 이용

태스크를 수행할수록 Skill이 늘어나기 때문에, 개인의 노하우로 남기 쉬운 "배포 절차", "마이그레이션(Migration) 관례", "장애 대응 런북(Runbook)" 등을 에이전트에게 학습시키면 팀 전체의 공유 자산이 됩니다. 신규 멤버가 합류했을 때도 에이전트가 동일한 Skill로 동작하므로 적응이 빨라집니다.

지금까지의 소감

매우 편리하다고 생각하여 Multica를 시도해 보았지만, 로컬에서 사용하기에는 아직 용기가 필요할 것 같습니다. 개인 프로젝트이면서 별도의 PC에서 구동한다면 문제없을지도 모릅니다.

그럼, 지금부터는 실제로 로컬 이외의 런타임(Runtime)을 구축해 보겠습니다. Google Cloud의 GCE를 사용합니다.

GCE에 런타임 구축하기

GCE 구성

우선 무료 티어(Free Tier)로 테스트해 보았습니다.

name: claude-code-runtime
machine-type: e2-micro
region/zone: us-central1-a (무료 티어 중 가장 안정적이며 저지연)
image: ubuntu-2404-lts
disk: pd-standard 30GB
network tag: 없음 (multica daemon이 아웃바운드 통신만 한다면 ingress가 불필요. 호스팅을 하려면 별도로 개방)

GCE 구축

AI에게 맡기면 괜찮습니다. 이 기사를 읽히는 것만으로도 가능할 것이라 생각합니다. 단, gcloud 명령어는 설치해 두시기 바랍니다.

절차 (AI가 수행 가능)

Google Cloud에 프로젝트 생성
Compute Engine 인스턴스 생성
Swap을 4GB로 설정 (메모리가 적은 경우. 많다면 불필요)
Node.js 22 LTS 설치
Claude Code 설치
Multica 설치

절차 (수동)

https://multica.ai 설정에서 API 토큰 발행
ssh로 Compute Engine 접속 (AI가 명령어를 알려줍니다)
claude 실행. 로컬에서 URL을 열고 터미널에 코드를 붙여넣기
multica login --token으로 API 토큰 붙여넣기
multica daemon start 실행
Multica 페이지에 추가되므로, 이를 사용하여 Agent 생성

또한 항상 실행 상태를 유지하고 싶으므로, AI에게 다음과 같이 요청하는 것이 좋습니다.

GCE에서 Multica를 systemd 서비스로 등록해줘. env는 자유롭게 설정할 수 있도록.

React 페이지 호스팅해 보기

여러 가지를 고민한 끝에, 일단 실패할 확률이 적은 것을 골랐습니다. 클라이언트 전용(Client-only) 페이지를 호스팅해 보겠습니다.

포트 개방

먼저 80/443 포트를 열어야 합니다. 로컬 AI에게 다음과 같이 요청합니다.

방금 만든 GCE의 80, 443 포트를 열어줘

이것으로 공개 준비가 완료되었습니다.

권한 부여

VM 내부이므로, Claude Code에 모든 권한을 부여합니다. 로컬 AI에게 지시합니다.

Claude Code의 settings.json에 defaultMode: "bypassPermissions"를 추가해줘.

이로써 Claude Code가 VM 내에서 무쌍(unrivaled) 상태가 됩니다. API 키 등을 전달할 때는 충분히 주의해 주세요.

세계 시계 만들기

Multica로 issue를 던집니다. assignee는 GCE를 지정합니다.

Vite + React + TypeScript로 세계 시계를 배포해줘.
- 디렉토리: ~/world-watch 에 프로젝트 생성
- 포트: 80 (외부 공개)
...

결과

무사히 세계 시계가 배포되었습니다. 감동적입니다.

요약

로컬이 아닌 GCE를 런타임 (Runtime)으로 사용함으로써, 안전하게 Multica를 사용할 수 있었습니다. 이 정도라면 팀 운영에도 견딜 수 있을 것 같습니다.

다만 GitHub 등 여러 서비스와 연동하게 될 것이므로, API 키의 위험성은 여전히 존재합니다. 특히 권한 (Permission)을 우회하고 있기 때문에 AI의 폭주를 알아차릴 수 없습니다. 그 부분은 트레이드오프 (Trade-off)가 될 것 같습니다.

이러한 용도를 위해 GitHub의 별도 계정을 만드는 것도 방법일 수 있습니다. 다른 서비스도 마찬가지입니다. (Slack Bot 정도라면 문제없을 것으로 생각되지만)