완전 가이드
빈 워크스페이스에서 시작해 개인 웹사이트 프로젝트로 Multica의 핵심 흐름을 모두 거칩니다. 에이전트를 만들고, 이슈로 결과물을 만들고, 스쿼드를 구성하고, 스킬을 축적하고, 자동화를 설정합니다.
Multica는 사람과 AI 에이전트가 함께 일하는 플랫폼입니다. 이 가이드는 아무것도 없는 상태에서 시작해 다음을 진행합니다.
- 자신의 워크스페이스 만들기
- 사람과 에이전트의 협업, 그리고 에이전트 사이의 자동 협업 구현하기
- 반복되는 작업을 자동화에 맡기기
- 효과가 있었던 방법을 스킬로 축적해 에이전트를 계속 개선하기
이 가이드는 개인 웹사이트를 예제 프로젝트로 삼아 Multica의 전체 흐름과 핵심 기능을 한 번씩 모두 다룹니다.
시작하기 전 준비물:
- Multica 계정(multica.ai에서 가입)
- Claude Code나 Codex 같은 AI 코딩 도구를 하나 이상 설치하고 로그인한 컴퓨터 한 대. 지원되는 도구 전체는 AI 코딩 도구 설치를 참고하세요.
워크스페이스 만들기
워크스페이스는 팀이 일하는 공간입니다. 이슈, 프로젝트, 에이전트는 모두 특정 워크스페이스에 속합니다. 가입 후 안내를 따라 첫 워크스페이스를 만들게 되며, 팀에 초대받아 참여한 경우에는 로그인하면 바로 팀의 워크스페이스로 들어갑니다.
이 가이드에서는 새 워크스페이스를 만들어 설명합니다. 사이드바 위쪽의 워크스페이스 이름을 클릭하고 워크스페이스 만들기를 선택합니다.
만들 때 두 항목을 입력합니다.
- 이름: 멤버에게 표시되는 이름이며 나중에 수정할 수 있습니다.
- URL: 워크스페이스 주소의 slug입니다. 예를 들어
multica.ai/my-team의my-team이며 만든 뒤에는 수정할 수 없습니다.
만들고 나면 새 워크스페이스로 들어갑니다. 왼쪽은 사이드바이며 이후 모든 작업은 여기에서 시작합니다. 가운데 이슈 목록은 아직 비어 있고, 다음 몇 단계에서 에이전트가 이 목록을 채우게 됩니다.
컴퓨터 연결
에이전트는 연결한 컴퓨터에서 작업을 실행하며, 그 컴퓨터에 설치된 AI 코딩 도구를 사용합니다.
이 가이드에서는 Multica Desktop으로 설명합니다. 내려받아 로그인하면 이 컴퓨터를 런타임으로 자동 등록하고 설치된 AI 코딩 도구를 감지합니다. 사이드바 아래쪽의 설정 → 런타임을 열고 이 컴퓨터가 온라인인지 확인합니다.
이 컴퓨터를 클릭하면 감지된 도구를 하나씩 확인할 수 있습니다.
Desktop을 쓰지 않아도 됩니다. 런타임 페이지에서 컴퓨터 추가를 클릭하고 안내에 따라 명령줄로 설치하면 데몬이 백그라운드에 상주하며 실행됩니다. 자세한 내용은 데몬과 런타임을 참고하세요.
첫 에이전트 만들기
에이전트는 워크스페이스의 정식 멤버입니다. 이슈를 할당받고, 댓글을 쓰고, 대화할 수 있습니다. 첫 에이전트로는 워크스페이스의 일상적인 일을 담당하는 helper를 만듭니다. 이후 가이드의 여러 작업을 이 에이전트에게 맡깁니다.
사이드바에서 에이전트를 열고 새 에이전트를 클릭한 뒤 빈 상태로 시작을 선택하고 세 항목을 입력합니다.
- 이름:
Multica helper. - 런타임과 모델: 앞 단계에서 연결한 컴퓨터와 AI 코딩 도구를 선택한 뒤, 그 도구가 지원하는 모델 중 하나를 고릅니다. 이 가이드에서는 Claude와 Sonnet을 사용합니다.
- 지시문: 실행할 때마다 에이전트에게 제공되는 프롬프트입니다. 무엇을 담당하고 무엇을 담당하지 않는지 명확히 적습니다.
You are the helper of this workspace.
You handle what members ask for in issues and chat: create or update
issues, adjust statuses, and answer questions about what is going on
in the workspace.
Keep replies short. After finishing something, reply with a one-line
summary of what you did. Do not touch code or repositories. If a
request is ambiguous, ask before acting.
나머지 항목은 기본값으로 두고 생성을 클릭합니다. 에이전트 페이지로 돌아오면 Multica helper가 온라인이며 작업을 받을 수 있습니다.
두 번째 에이전트: 대화로 만들기
웹사이트를 만들려면 코드를 작성할 엔지니어가 필요합니다. 이번에는 양식을 직접 채우지 않습니다. 워크스페이스에 이미 에이전트가 하나 있으므로 생성 작업을 그 에이전트에게 바로 맡길 수 있습니다.
사이드바에서 채팅을 열고 Multica helper를 선택해 이렇게 요청합니다. 같은 런타임에 Engineer라는 에이전트를 만들고, 모델은 Opus를 쓰며, 개인 웹사이트를 만들고 유지하는 일을 담당하게 합니다. Multica helper가 이 컴퓨터에서 생성을 실행하고 새 에이전트의 이름과 모델을 답변합니다. 새 에이전트는 기본적으로 생성자만 실행할 수 있으며, 이 가이드에서는 기본값 그대로 두면 됩니다.
에이전트 → Engineer를 열어 결과를 확인합니다. 모델은 Opus이고 지시문은 Multica helper가 생성했습니다. 담당 범위, 저장소 코드를 가져오는 방식, 변경 사항을 제출할 때의 요구 사항이 담겨 있으며 언제든 수정할 수 있습니다.
웹사이트 저장소 준비
웹사이트 코드는 GitHub 저장소에 둡니다. 저장소를 만들고 등록하는 일도 에이전트에게 맡깁니다. 단, 이 컴퓨터에 GitHub CLI가 설치되어 있고 로그인되어 있어야 합니다.
채팅에서 Engineer를 선택하고 이렇게 요청합니다. 내 GitHub 계정에 personal-website라는 빈 저장소를 만들고(이 컴퓨터에는 GitHub CLI가 있습니다) multica repo add로 이 워크스페이스에 등록해 달라고 합니다. Engineer가 로컬에서 저장소를 만들고 워크스페이스에 등록한 뒤 저장소 주소를 답변합니다. 메시지에서 공개 범위를 지정하지 않았으므로 기본값으로 만들고 답변에서 그 사실을 알려 줍니다. 공개든 비공개든 이후 단계에는 영향이 없습니다.
설정 → 저장소를 열어 확인합니다. personal-website가 목록에 있습니다. 이후 에이전트가 태스크를 실행할 때 여기에서 저장소를 선택합니다.
GitHub CLI를 쓰지 않는다면 GitHub에서 직접 저장소를 만들고 같은 페이지에서 수동으로 추가해도 결과는 같습니다.
마지막으로 같은 페이지에서 GitHub 연결을 클릭하고 안내에 따라 이 저장소를 인증합니다. 연결하면 이슈 번호를 참조한 pull request가 해당 이슈에 자동으로 연결되고, PR 상태와 CI 결과가 이슈에 바로 표시됩니다.
첫 이슈: 웹사이트 만들기
설정은 여기까지입니다. 지금부터는 Multica의 일상적인 작업 방식입니다. 요구 사항을 이슈로 쓰고 에이전트에게 실행을 맡깁니다.
웹사이트는 처음부터 만들지 않고 shadcn의 공식 템플릿에서 시작합니다. 템플릿에 기술 스택과 기본 설정이 이미 들어 있고, Engineer는 그 위에서 내용과 디자인을 작업합니다.
사이드바 위쪽의 새 이슈를 클릭합니다(단축키 C). 기본 에이전트 모드에서는 제목을 입력하지 않아도 됩니다. 생성자에서 Engineer를 선택하고 요구 사항을 설명에 바로 작성하면 제목은 만들 때 자동으로 생성됩니다. 수동 모드로 전환해 제목과 내용을 직접 입력할 수도 있습니다. 설명은 다음과 같습니다.
Work in the personal-website repository registered in this workspace.
Start from a template instead of scaffolding from scratch:
pnpm dlx shadcn@latest init --preset b5rR41Mtnc --template next --pointer
Run the command, commit the template as-is, then build on top of it.
The site is for a photographer. It needs:
- Introduction — who I am and what I shoot
- My work — a selection of photos
- Contact — an email link that is easy to find
- Pricing — decide where a pricing table fits and how to present it
- Use placeholder images (Unsplash or picsum.photos) wherever a photo
belongs, and list where I should replace them with my own work
Design:
- Pick a style that fits a photography portfolio. It should feel
refined and understated; express that through layout, typography
and spacing, and never use words like "premium" or "high-end"
in the copy.
- Choose the fonts.
Open a pull request when it is ready.이 설명에는 세 종류의 정보가 있습니다. 제약(지정한 템플릿에서 시작), 내용 요구 사항(항목별로 나열), 여지(스타일은 Engineer가 판단)입니다. 의도와 경계를 적고 구현 방식은 에이전트에게 맡깁니다.
제출하면 Multica가 이슈를 만들고(번호는 MUL-1, 제목은 자동 생성) Engineer를 담당자로 지정합니다. Engineer는 곧바로 실행을 시작하고 상태가 진행 중으로 바뀝니다. 이슈 오른쪽에는 이 이슈의 모든 상황이 모입니다. 상태, 담당자, 연결된 pull request, 실행 기록입니다.
실행에는 몇 분이 걸립니다. 진행 상황은 두 곳에서 확인합니다. 제목 옆의 작업 상태 배지, 그리고 오른쪽 실행 로그에서 현재 실행을 클릭하면 됩니다.
실행 기록에는 이번 실행의 모든 단계가 있습니다. Agent 줄은 에이전트의 설명이고, Bash, Read, Edit는 실행한 명령과 읽고 쓴 파일입니다. 이 스크린샷 시점에는 완성한 페이지를 스크린샷으로 찍어 스스로 점검하던 중이었고, 가격표의 구분선이 정렬되지 않은 것을 막 발견했습니다. 오른쪽 위의 ⓘ를 클릭하면 이번 실행에 사용한 컴퓨터, AI 코딩 도구, 작업 디렉터리를 확인할 수 있습니다.
검수: 이슈에서 대화하기
실행이 끝나면 Engineer가 상태를 리뷰 중으로 바꾸고 알림이 인박스로 들어옵니다. 이슈에는 완료 댓글과 함께 완성한 페이지 스크린샷을 남겼습니다.
스크린샷으로 대략은 알 수 있지만 검수는 브라우저에서 직접 열어 봐야 합니다. 웹사이트는 내 컴퓨터에서 빌드되므로 Engineer에게 로컬 서버를 실행하게 하면 접속할 수 있습니다. 그리고 오른쪽의 Pull requests 영역은 아직 비어 있습니다. 이슈에서 PR 제출을 분명히 요구했으니 이 점도 함께 물어봅니다.
이번에는 댓글을 쓰지 않습니다. 화면 오른쪽 아래에는 채팅 버튼이 있어 워크스페이스의 어느 페이지에서든 열 수 있으며, 사이드바의 채팅과 같은 기능입니다.
열어서 Engineer를 선택하고 @를 입력해 현재 이슈를 참조합니다. 대화가 이 이슈의 컨텍스트를 함께 가져가므로 위의 두 가지를 그대로 보냅니다.
Engineer의 답변은 두 부분입니다. 로컬 서버는 이미 실행했고 접속 주소를 알려 줍니다. PR도 이미 제출했지만 제목, 브랜치 이름, 본문 어디에도 MUL-1이 없어 자동 연결이 매칭되지 않았습니다. 이어서 PR 제목에 번호를 넣었습니다.
알려 준 주소를 브라우저에서 열면 웹사이트가 보입니다.
이슈로 돌아오면 오른쪽 Pull requests 영역에 PR 카드가 나타납니다. 상태와 변경 규모가 표시되고 클릭하면 GitHub의 PR이 바로 열립니다. CI를 설정한 저장소라면 check 결과도 표시됩니다.
피드백을 지시문에 반영하기
이번 검수에서 Engineer의 작업 습관 두 가지가 드러났습니다. 완료 후 스크린샷을 반복해서 찍으며 스스로 점검하느라 실행 시간을 적지 않게 썼고, PR을 제출할 때 이슈 번호를 넣지 않아 연결되지 않았습니다. 둘 다 이번에만 생긴 실수가 아니라 매번 반복되는 방식입니다. 고쳐야 할 대상은 이 이슈가 아니라 에이전트의 지시문입니다.
지시문은 직접 수정하지 않아도 됩니다. 에이전트는 multica CLI로 자기 설정을 업데이트할 수 있습니다. 앞의 대화에 이어서 Engineer에게 두 가지 규칙을 알려 주고 자기 지시문에 반영하게 합니다. 완료 후 스크린샷으로 자체 점검하지 말고 검수는 브라우저에서 진행한다는 것, 그리고 PR의 브랜치 이름이나 제목에 반드시 이슈 번호를 넣어야 한다는 것입니다.
Engineer는 multica agent update로 업데이트를 마치고 지시문에 작업 규칙 항목을 새로 추가했으며, 첫 번째 규칙의 대가도 함께 알려 줍니다. 더 이상 스크린샷으로 자체 점검하지 않으므로 페이지의 시각적 문제는 브라우저에서 직접 찾아야 합니다.
에이전트 → Engineer를 열면 지시문에 이 두 가지가 추가되어 있습니다.
이후 모든 실행에서 이 두 규칙이 지시문과 함께 적용됩니다. 에이전트를 다듬는 기본 방식이기도 합니다. 반복해서 나타나는 문제를 발견하면 매번 말로 상기시키는 대신 교정 내용을 지시문에 적습니다.
세 번째 에이전트: Reviewer
Engineer가 첫 번째 버전을 전달했지만 스스로 알아차리지 못하는 문제도 있습니다. 검토는 새 에이전트에게 맡깁니다. 완전히 새로운 컨텍스트에서 이슈의 요구 사항과 대조하며 코드 품질을 확인하는 역할입니다.
생성은 이번에도 Multica helper에게 맡깁니다. Reviewer라는 에이전트를 만들고, 이번에는 Codex와 GPT-5.6 Sol 모델을 선택해 Engineer가 쓰는 도구, 모델과 모두 다르게 합니다. 검토만 하고 코드는 수정하지 않으며 결론은 이슈 댓글로 씁니다. 지시문은 이번에도 helper가 생성합니다. PR의 실제 상태를 읽은 뒤 검토할 것, 발견한 내용은 파일 위치와 함께 댓글로 쓸 것, 코드는 절대 수정하지 말 것입니다.
검토를 위해 이슈를 새로 만들거나 담당자를 바꿀 필요는 없습니다. MUL-1의 댓글 입력란으로 돌아와 @Reviewer로 멘션하고 할 일을 적어 보냅니다. 입력란 아래에는 전송하면 Reviewer가 실행을 시작한다는 안내가 표시됩니다.
몇 분 뒤 검토 댓글이 돌아왔고 결론은 merge 전에 수정이 필요하다는 것입니다. 다섯 건의 발견은 두 그룹으로 나뉩니다. 코드 규범 세 건, 요구 사항 부합도 두 건이며 각 건마다 파일과 줄 번호가 붙어 있습니다. 요구 사항 부합도 두 건이 바로 Engineer가 스스로 알아차리지 못한 문제입니다. 가격표가 가상의 가격, 예약금, 세금 조항을 확정된 내용처럼 표시하면서 미정 표시를 전혀 하지 않았고, 연락처에는 확인되지 않은 Instagram 링크가 들어 있었습니다. 댓글 끝에는 자신이 검증한 부분도 밝혔습니다. typecheck, lint, build가 모두 통과했습니다.
수정에도 새로운 절차는 필요 없습니다. 댓글에서 @Engineer를 멘션해 발견된 문제를 모두 고치게 합니다. 보내면 Engineer가 곧바로 실행을 시작하며 제목 옆 배지와 오른쪽 실행 기록에서 확인할 수 있습니다.
몇 분 뒤 Engineer가 보고합니다. 다섯 건을 모두 수정해 같은 PR에 반영했습니다. 두 에이전트가 같은 타임라인을 공유하므로 보고는 발견 항목마다 결과만 답하면 되고 배경을 다시 설명할 필요가 없습니다.
다시 Reviewer를 멘션해 한 번 더 확인하게 하면 결론은 다섯 건이 모두 해결되어 merge할 수 있고 낮은 우선순위의 후속 제안 두 건이 남았다는 것입니다.
개발과 검토는 이렇게 오갑니다. 문제를 발견하고 문제를 고치면서 매 라운드마다 웹사이트의 정의가 조금씩 더 분명해집니다. 이제 하나의 이슈에 에이전트 두 명이 붙어 있습니다. Engineer가 구현하고 Reviewer가 검토하며, 짧은 댓글 몇 개로 이 순환 전체를 움직입니다.
merge로 마무리
merge도 댓글 하나로 지시합니다. Engineer에게 PR을 merge하고 이슈를 완료로 옮기게 합니다. Engineer는 merge하고, 브랜치를 삭제하고, merge된 main에서 검사를 다시 실행한 뒤 보고합니다. 이슈 상태는 완료로 바뀌고 인박스에 알림이 도착합니다.
첫 번째 이슈는 여기서 한 바퀴를 마칩니다. 요구 사항 작성부터 merge까지 구현, 검토, 수정, 검수, merge가 모두 같은 타임라인에 기록됩니다.
스쿼드 구성하기
MUL-1의 순환은 잘 돌아갔지만 이어지는 단계는 매번 사람이 시작했습니다. 검수 후 Reviewer를 멘션하고, 검토 후 Engineer를 멘션했습니다. 조율 자체가 내 일이 된 것입니다. 이 일도 넘길 수 있습니다. Multica가 이를 위해 제공하는 조직 형태가 스쿼드(squad)입니다. 에이전트와 멤버를 묶어 이름을 붙인 집합이며 리더 에이전트 한 명이 이끕니다. 이슈를 스쿼드에 할당하면 리더가 받습니다. 이슈를 읽고, 작업을 나눠 주고, 상태를 진행합니다. 멤버가 답하면 자동으로 깨어나 다음 단계를 결정하고, 마무리할 때는 결과물을 보고합니다. 리더가 맡는 역할이 바로 앞에서 내가 하던 역할입니다.
스쿼드는 기존 분업에 리더 한 명을 더한 것입니다.
- Lead(새로 만듦): 리더이며 관리를 담당합니다. 작업을 배분하고, 이슈 상태를 진행하고, 결과물을 보고하며 직접 구현하지는 않습니다.
- Engineer(기존): 개발.
- Reviewer(기존): 모든 PR 검토.
- 당신: 최종 검수.
멤버는 에이전트로 한정되지 않습니다. 각 멤버에는 한 줄짜리 역할 설명이 붙고 리더가 작업을 배분할 때 참고합니다.
이 구성은 Multica helper에게 설명하는 것으로 충분합니다. 스쿼드와 리더를 만들고, 멤버마다 역할을 정하고, Lead와 Engineer에 스킬을 하나씩 연결하고(다음 절에서 설명합니다), 스쿼드 지시문에 워크플로를 적습니다. 개발은 Engineer에게 배분하고, PR 검토를 통과해야 전달하며, 검수가 끝나면 Engineer가 merge합니다. helper가 CLI로 모든 설정을 한 번에 마칩니다.
사이드바에서 스쿼드 → Website Team을 열어 결과를 확인합니다. 리더, 멤버, 역할 설명이 모두 들어 있습니다. 스쿼드는 이 페이지에서 양식으로 만들 수도 있습니다. 전체 동작 방식은 스쿼드 문서를 참고하세요.
스킬: 재사용 가능한 방법
앞에서 피드백을 지시문에 반영한 것은 에이전트 한 명의 문제를 해결한 것입니다. 지시문은 그 에이전트에게만 속하기 때문입니다. 하나의 방법을 여러 에이전트가 공유하게 하거나 다른 사람이 이미 작성해 둔 방법을 그대로 가져오려면 스킬을 사용합니다.
스킬은 에이전트에게 주는 지식 묶음입니다. SKILL.md 하나와 선택적인 지원 파일로 구성되며, 특정 유형의 작업을 만났을 때 어떻게 생각하고 어떻게 처리할지 알려 줍니다. Multica는 Anthropic Agent Skills 공개 표준을 따르므로 규격에 맞는 스킬은 바로 가져올 수 있습니다. 에이전트에 연결하면 실행할 때 런타임으로 자동 동기화됩니다. 스킬 페이지를 열면 방금 가져온 두 개가 있고 오른쪽에는 각각 연결된 에이전트가 표시됩니다.
클릭하면 스킬의 모든 파일을 볼 수 있습니다.
이 두 스킬은 하나는 일하는 방식을, 하나는 말하는 방식을 담당합니다.
- tdd는 Engineer에 연결한 엔지니어링 방법입니다. 실패하는 테스트를 먼저 쓰고, 그 테스트를 통과시키는 만큼만 구현합니다.
- i-have-adhd는 Lead에 연결한 보고 스타일입니다. 첫 줄은 항상 실행 가능한 다음 단계이고, 여러 단계는 번호를 붙이며, 진행 상황이 드러납니다. 리더의 결과물은 전부 사람에게 보내는 보고이므로 이 스킬이 읽게 되는 형태를 결정합니다.
팀의 작업 방식을 스킬로 축적하면 새 에이전트는 연결하는 것만으로 이어받습니다. 가져오기만 있는 것은 아닙니다. 새 스킬은 직접 만들기, URL에서 가져오기, 로컬 런타임에서 복사하기 세 가지 방법을 제공합니다. 여기서는 다루지 않으며 스킬 문서를 참고하세요.
외부 스킬을 가져오기 전에 파일을 먼저 읽어 보세요. Multica는 샌드박스로 격리하지 않으며 스킬의 내용은 그대로 AI 코딩 도구에 전달됩니다.
두 번째 이슈: 스쿼드에 맡기기
스쿼드에 완결된 작업 하나를 맡깁니다. 웹사이트를 범용 템플릿으로 바꾸는 일입니다. 실제 이름은 플레이스홀더 사진작가 이름으로, 실제 이메일은 hello@example.com으로 바꾸고 레이아웃과 콘텐츠 구조는 그대로 둡니다. 이번 이슈는 직접 쓰지 않습니다. 채팅에서 Lead에게 요구 사항을 설명하고 에이전트로 만들기로 바로 만들며 담당자는 스쿼드입니다. 스쿼드도 에이전트, 멤버와 마찬가지로 담당자 자리에 올 수 있습니다.
생성된 이슈에는 요구 사항이 구조화된 설명으로 정리되어 있고, 제목 옆 배지는 리더가 이미 작업을 맡았음을 보여 줍니다.
이후는 전부 리더의 작업입니다. 작업을 배분하는 댓글은 단순 전달이 아닙니다. 이슈에 없던 제약 두 가지를 덧붙인 뒤(플레이스홀더 신원을 사이트 전체에서 통일, 점검 범위를 메타데이터와 README까지 포함) Engineer에게 넘깁니다. Engineer는 작업을 마친 뒤 같은 타임라인에 PR을 보고합니다.
검토에서 발견된 문제가 없자 Lead가 곧바로 전달합니다. 검수를 요청하며 멘션하고, 첫 줄은 결론, 그 아래는 PR 링크, 변경 설명, 판단이 필요한 두 가지 항목이며, 마지막 한 줄은 승인하기 전에는 merge하지 않는다는 내용입니다.
요구 사항 정리, 방안 확정, 개발, 검토, 전달 보고까지 이 이슈에서는 사람이 단계를 이어 줄 일이 한 번도 없었습니다. 검수 방식은 MUL-1과 같습니다. 로컬 서버를 실행하게 해 브라우저에서 확인할 수도 있으며 여기서는 다시 설명하지 않습니다. 완료는 여전히 사람의 몫입니다. merge하라고 답하거나 상태를 직접 바꿉니다. 타임라인의 모든 단계가 기록되며 사람으로 이루어진 팀의 이슈와 다르지 않습니다. 달라진 것은 실행하는 주체뿐입니다.
자동화: 오토파일럿
지금까지의 모든 트리거는 사람이 시작했습니다. 할당, 멘션, 대화입니다. 오토파일럿은 네 번째 트리거 방식으로, 시간에 맞춰 자동으로 작업을 시작합니다.
설정은 한 문장이면 됩니다. Multica helper에게 매주 월요일 아침 9시에 Reviewer가 웹사이트 코드베이스를 전면 점검하게 해 달라고 알려 줍니다. 중복과 죽은 코드, 부적절한 구조, 더 규범적으로 바꿀 수 있는 부분을 찾아 이슈 댓글에 쓰고 코드는 수정하지 않게 합니다.
오토파일럿 페이지를 열면 실행 주체, 프롬프트, 일정(cron과 시간대)이 모두 설정되어 있습니다. 실행 모드는 두 가지입니다.
- 이슈 만들기(기본값): 트리거할 때마다 이슈를 먼저 만들어 작업이 보드에 올라가며, 기록과 댓글이 일반 이슈와 완전히 같습니다.
- 실행만: 이슈를 만들지 않고 바로 실행하며 오토파일럿의 실행 기록에만 남습니다. 이번에 발견된 문제가 없다면 실행이 끝난 뒤 아무것도 남지 않습니다.
정기 점검에는 이슈 만들기 모드를 사용합니다. 월요일까지 기다리지 않으려면 지금 실행을 클릭해 바로 한 번 트리거합니다.
이슈가 곧바로 만들어지고 Reviewer가 점검을 시작합니다. 이후 매주 월요일 정해진 시각이 되면 같은 점검이 새 이슈를 자동으로 만들며 아무도 트리거할 필요가 없습니다.
트리거는 일정 외에 webhook도 지원하며 실행 주체를 스쿼드로 지정할 수도 있습니다. 오토파일럿 문서를 참고하세요.
여러 사람과 협업
여기까지 워크스페이스의 사람 멤버는 계속 한 명뿐이었습니다. 설정 → 멤버에서 이메일로 다른 사람을 초대하면 그들도 똑같이 이슈를 만들고, 에이전트를 @멘션하고, 스쿼드에 참여합니다. 여러 사람과 여러 에이전트가 같은 이슈들에서 함께 일합니다.
마치며
이슈가 많아지면 이를 정리하는 도구도 있습니다. 프로젝트는 관련 이슈를 한 묶음으로 모아 하나의 단위로 관리합니다(프로젝트 문서 참고). 비슷한 정리 방식이 계속 늘고 있으며 Space도 곧 사용할 수 있습니다.
지금까지의 경로를 되짚어 보면, 빈 워크스페이스에서 시작해 컴퓨터 한 대를 연결하고, 에이전트 네 명을 만들고, 이슈 두 건의 전체 생애 주기를 끝낸 뒤, 조율은 리더에게 정기 점검은 오토파일럿에 넘겼습니다. 사람의 참여는 단계마다 뒤로 물러나고 마지막에는 두 가지만 남습니다. 요구 사항을 설명하는 일과 결과를 검수하는 일입니다.
에이전트는 일급 멤버이고 모든 협업은 이슈의 타임라인에 남습니다. 이것이 Multica가 제공하는 작업 방식입니다. 제품은 계속 빠르게 발전하고 있으며 더 많은 기능은 문서에서 확인할 수 있습니다.