AI 튜토리얼

Solo to Team 튜토리얼: 협업 스킬 패키지를 설치하고 한 사람이 여러 AI 어시스턴트를 관리하기

이 튜토리얼에서는 Solo to Team 스킬 패키지를 설치하고 네 가지 핵심 스킬을 이해한 뒤, 하나의 간단한 작업을 통해 ‘배정, 수락, 회수, 검증, 판단’으로 이어지는 협업 과정을 직접 진행합니다. 또한 여러 호스트 환경의 구성, 자동화의 범위와 한계, 고급 활용법도 설명합니다.

2026년 11월 10일약 19분 소요

Solo to Team 튜토리얼: 협업 스킬 패키지를 설치하고 여러 AI 어시스턴트 관리

프로젝트 소개

Solo to Team · 한 사람이 팀이 되다는 저장소 이름이 solo-to-team-skills인, “한 사람이 전체를 통제하고 여러 장기 AI 어시스턴트를 활용하는” 상황을 위한 중국어 협업 스킬 패키지입니다. AI가 자동으로 팀을 구성하도록 하는 것이 아니라, 작업을 전달하고, 진행 상황을 확인하고, 증거를 대조한 뒤, 사람이 최종 판단을 내릴 수 있도록 반복 실행 가능한 방법을 제공합니다.

프로젝트의 현재 상태는 v0.9-draft이며, 계속 수정될 예정입니다. Codex, WorkBuddy, DeepSeek Harness, Cursor, CodeBuddy, Kimi Work, QwenWork 등 호스트에서 제한적인 실제 사용 검증을 완료했습니다. Grok Bot은 수동 설정이 필요합니다. Claude Code는 플러그인 구조를 준비했지만 아직 최초 지원 범위에는 포함되지 않았습니다.

“지원”은 지정된 설치 및 호출 방식이 실제로 작동한 기록이 있다는 뜻이며, 모든 작업을 안정적으로 완료할 수 있거나 네 가지 스킬이 모든 호스트에서 각각 검증되었다는 뜻은 아닙니다.

프로젝트가 해결하는 문제

여러 AI 어시스턴트가 협업할 때 실제로 통제하기 어려운 것은 모델의 능력보다 프로세스인 경우가 많습니다. 작업을 전달한 뒤 아무도 확인하지 않거나, 실행자가 “완료했다”고 말하지만 증거가 없거나, 검수와 결과 수령을 혼동하거나, 작업 안내가 작성자만 이해할 수 있는 경우가 그렇습니다.

Solo to Team은 협업 과정을 다음의 흐름으로 정리합니다.

목표 제시 → 분담 → 인계 → 대조 → 판단

목표 제시: 무엇을 할지, 결과물을 어디에 둘지, 언제 납품할지, 무엇을 완료로 볼지 명확히 합니다.
분담: 작업을 배정하기 전에 “수령 대기”를 등록하고, 실행자, 수령자, 기한 확인 담당자를 명확히 적습니다.
인계: “작업 수락 완료”와 “결과 수령 완료”를 각각 기록하여 메시지를 받은 것을 완료로 오인하지 않도록 합니다.
대조: 현재 버전에 대응하는 유효한 증거를 확인하며, 수정되었거나 실패했던 부분은 반드시 다시 검증합니다.
판단: 사람은 승인, 반려 또는 방향 전환을 결정합니다.

네 가지 핵심 스킬

dispatch-accept-verify

표시 이름은 “맡긴 작업을 반드시 돌려받기”이며, 분담과 인계를 담당합니다. 작업을 전달하기 전에 “수령 대기”를 등록하고, 작업 수락, 결과 수령, 검수 완료를 별도로 기록하도록 요구합니다. 검수가 완료되거나 취소 권한을 받아야만 작업을 미완료 목록에서 제거할 수 있습니다.

evidence-before-done

표시 이름은 “작업을 넘기기 전에 증거 남기기”이며, 대조를 담당합니다. 완료 결론은 현재 버전에 대응하는 증거를 기반으로 해야 한다는 점을 강조합니다. 예를 들어 결과물을 열어 확인하거나, 다시 계산하거나, 명령을 실행하거나, 원래 절차를 처음부터 다시 수행하는 방식입니다.

beginner-ops-writing

표시 이름은 “초보자용 작업 안내”이며, 배경을 전혀 모르는 사람도 그대로 따라 할 수 있는 절차를 작성하는 데 사용합니다. 핵심 원칙은 한 번에 한 단계씩 작성하고, 대상이 하나로 명확하도록 하며, 완료 후 무엇이 보여야 하는지 설명하는 것입니다. 로그인, 결제, 삭제, 공식 발송 등 본인이 직접 해야 하는 동작은 “본인이 직접 수행해 주세요”라고만 작성해야 하며, 대신 처리하는 방법을 설계해서는 안 됩니다.

ops-case-notes

표시 이름은 “비식별화 운영 기록”이며, 실제 운영에서 얻은 비식별화 사례 두 건을 포함합니다. 실제 문제, 수정 방법, 결과 및 아직 해결되지 않은 제한 사항을 기록합니다. 프로세스에 문제가 발생한 후 회고 자료로 활용하기에 적합합니다.

시작 전 준비

먼저 저장소를 다운로드하거나 클론하고, 로컬에 skills/ 디렉터리가 있는지 확인합니다. 이 디렉터리에는 네 개의 스킬 하위 디렉터리가 있어야 하며, 각 디렉터리에는 SKILL.md가 포함되어 있습니다.

git clone YOUR_REPOSITORY_URL
cd solo-to-team-skills

클론 주소는 프로젝트가 정식 공개된 후 실제 저장소 주소로 바꿔야 합니다. 압축 파일을 다운로드해 프로젝트를 받은 경우에는 바로 압축을 풀어 사용할 수도 있습니다.

설치 시 다음 원칙을 지키세요.

skills/스킬명/ 디렉터리 전체를 복사하고 SKILL.md만 복사하지 마세요.
dispatch-accept-verify는 디렉터리 안의 템플릿에도 의존합니다. 본문만 복사하면 등록 행 템플릿이 누락됩니다.
dispatch-accept-verify와 evidence-before-done을 함께 설치하는 것을 권장합니다.
evidence-before-done은 단독으로 사용할 수도 있습니다.
beginner-ops-writing과 ops-case-notes는 선택적으로 함께 사용할 수 있으며, 설치하지 않아도 주요 작업 전달 및 수령 프로세스에는 영향을 주지 않습니다.

호스트 선택 및 설치

Codex

Codex에서 검증된 방식은 저장소에 포함된 .agents/plugins/marketplace.json을 사용합니다. 먼저 Codex CLI를 설치하고 로그인한 다음 프로젝트 루트 디렉터리에서 실행하세요.

cd /path/to/solo-to-team-skills
codex plugin marketplace add "$(pwd)"
codex plugin add solo-to-team-skills@solo-to-team-skills

명령이 0이 아닌 상태를 반환하면 실행을 중지하고 현재 디렉터리가 .agents/plugins/marketplace.json을 포함한 패키지 루트 디렉터리인지 확인해야 합니다. 설치 후 새 세션을 열거나 codex exec로 스킬을 호출하세요.

codex exec -s workspace-write --skip-git-repo-check -C "$(pwd)" '请使用技能 dispatch-accept-verify，写一行待收登记到 T044_dispatch_line.md'

설치를 철회하려면 다음을 실행하세요.

codex plugin remove solo-to-team-skills@solo-to-team-skills
codex plugin marketplace remove solo-to-team-skills

Cursor

필요한 스킬 디렉터리 전체를 사용자 스킬 디렉터리에 복사하세요.

mkdir -p ~/.cursor/skills/
cp -R skills/dispatch-accept-verify ~/.cursor/skills/
cp -R skills/evidence-before-done ~/.cursor/skills/

그다음 Cursor Agent에서 스킬 이름으로 호출합니다. cursor agent --print 형식의 CLI를 사용할 수도 있습니다. 새 작업 공간에서 비대화형으로 실행할 때 호스트가 --trust 사용을 요구할 수 있습니다. 이 매개변수는 작업 공간을 신뢰한다는 뜻이며 보안 기능을 끄는 것은 아닙니다.

WorkBuddy 및 CodeBuddy

두 제품은 이름이 비슷하지만 서로 다른 호스트이므로 설치 디렉터리를 함께 사용할 수 없습니다.

WorkBuddy: ~/.workbuddy/skills/ 또는 프로젝트 내부의 .workbuddy/skills/에 복사합니다. SKILL.md가 포함된 스킬 디렉터리 또는 zip 파일을 인터페이스에서 업로드할 수도 있습니다.
CodeBuddy: ~/.codebuddy/skills/ 또는 프로젝트 내부의 .codebuddy/skills/에 복사한 다음 인터페이스나 CLI에서 이름으로 호출합니다.

관련 공식 안내는 WorkBuddy Skills 문서와 CodeBuddy Skills 문서를 참고하세요.

DeepSeek Harness

스킬 전체를 프로젝트의 .dsh/skills/, 사용자 디렉터리의 ~/.dsh/skills/ 또는 .agents/skills/에 복사한 다음 Harness를 다시 열거나 새로 고침하세요. 프로젝트에는 dsh plugin add가 이러한 스킬 본문을 설치하는 방법이 아니라고 명시되어 있습니다.

사용하기 전에 DeepSeek 계정 또는 API를 직접 준비해야 하며, 이 프로젝트는 키를 제공하지 않습니다. 구체적인 메커니즘은 DeepSeek Harness Skills 문서를 참고하세요.

Kimi Work

README에서 실제로 검증한 것은 Kimi Code CLI가 아니라 Kimi Work 데스크톱 버전입니다. macOS 검증 환경에서 스킬 디렉터리는 다음과 같습니다.

~/Library/Application Support/kimi-desktop/daimon-share/daimon/skills/

복사가 완료되면 Kimi Work 인터페이스에서 /를 입력해 스킬을 선택합니다. 이 경로는 커뮤니티 사용 사례에서 가져온 것이며, 공식적으로는 zip, Markdown, 링크 또는 스토어 설치 방식을 제공할 수도 있으므로 Kimi Skills 공식 페이지의 최신 안내를 기준으로 해야 합니다.

QwenWork

스킬 디렉터리를 다음 위치에 복사하세요.

~/.qwenworkcn/skills/

그다음 데스크톱 버전에서 /를 사용해 스킬을 선택하거나 대화에서 직접 이름을 지정합니다. QwenWork와 Tongyi Lingma는 서로 다른 제품이므로 같은 설치 디렉터리를 적용해서는 안 됩니다. QwenWork Skills 문서를 참고할 수 있습니다.

Grok Bot

Grok Bot은 로컬 디렉터리 설치를 사용하지 않습니다. 스킬의 SKILL.md를 열고, 대화에서 본문을 비공개 스킬로 저장하도록 요청한 뒤 파일 첫 부분의 name과 description을 사용합니다. 네 가지 스킬은 각각 별도로 저장해야 합니다.

dispatch-accept-verify를 저장할 때는 등록 행 템플릿도 함께 비공개 스킬에 붙여 넣어야 합니다. 이 방식은 비공개 스킬 저장 기능이 있는 Grok Bot에만 해당하며, 다른 Grok 제품도 동일한 설정을 사용할 수 있다는 뜻은 아닙니다.

Claude Code

저장소에는 .claude-plugin/plugin.json 및 marketplace 구조가 이미 제공되지만, 현재는 “구조는 준비되었고 실제 작동 검증은 보완 중”인 상태입니다. 따라서 최초 지원 호스트로 간주할 수 없습니다. 직접 시도하는 경우에는 Claude Code 공식 플러그인 문서의 최신 설치 방법을 따라야 합니다.

첫 실행: 작은 작업부터 시작하기

처음부터 복잡한 프로젝트를 여러 어시스턴트에게 맡기지 마세요. 먼저 결과를 쉽게 확인할 수 있는 작은 작업을 하나 선택하세요. 예를 들어 주어진 입력을 바탕으로 회의록을 정리하는 작업이 있습니다. 프로젝트에는 examples/의 주요 예시와 examples/walkthrough-meeting-notes/의 전체 따라 하기 자료가 제공되며, “주어진 입력, 결과 생성, 증거 확인, 수동 검수, 수정 반려”를 연습하는 데 사용할 수 있습니다.

1단계: 목표 명확히 작성하기

어시스턴트에게 작업 내용, 결과물 위치, 납품 시간 및 완료 기준을 설명하세요. 프롬프트는 다음 구조를 사용할 수 있습니다.

请使用 dispatch-accept-verify 管理这项任务。
任务：根据给定输入整理会议记录。
成果位置：指定的工作区文件。
交付时间：约定时间。
完成标准：内容与输入一致，必要字段齐全，并可由我打开检查。
请先生成一行“待收”登记。

2단계: “수령 대기” 등록하기

작업을 배정하기 전에 먼저 등록 행을 만드세요. 최소한 작업 상태, 실행 담당자, 수령 담당자, 기한 확인 담당자, 결과물 위치 및 납품 시간을 명확히 해야 합니다. 저장소의 templates/task-register-line.md를 직접 복사하는 것이 좋으며, 전체 필드를 임의로 추측해 작성하지 마세요.

3단계: 작업 수락과 결과를 각각 기록하기

실행 보조자가 작업 수락을 확인한 후에는 “수락 완료”로 기록합니다. 결과 파일이 실제로 반환된 후에는 “결과 수령 완료”로 기록합니다. 두 상태는 합칠 수 없습니다. “누군가 작업을 하겠다고 답한 것”은 “결과물이 이미 전달된 것”과 같지 않기 때문입니다.

4단계: 증거로 확인하기

evidence-before-done을 호출하여 보조자에게 완료 결론을 뒷받침하는 현재 버전에 해당하는 증거를 제시하도록 요청합니다.

evidence-before-done을 사용하여 현재 결과물을 확인해 주세요.
최종 파일을 열고 원래 요구사항과 대조하여 항목별로 점검해 주세요.
수정했거나 실패했던 부분이 있다면 다시 확인해 주세요.
증거, 충족되지 않은 항목, 권장 결론을 나열하고, 저를 대신해 바로 승인하지는 마세요.

증거는 파일을 연 후의 내용 확인, 명령 출력, 재계산 결과 또는 원래 작업 절차를 처음부터 다시 수행한 결과에서 얻을 수 있습니다. 검증 후 결과물이 다시 수정되었다면 영향을 받은 부분을 다시 확인해야 합니다. 변경되지 않은 부분은 이전 검증 결과를 재사용할 수 있습니다.

5단계: 사람이 검수하기

증거를 바탕으로 승인, 반려 또는 방향 전환을 결정합니다. 사람이 직접 검수를 통과시킨 후에만 “검수 완료”로 기록합니다. 요구사항에 맞지 않으면 반려 사유를 명확히 작성하고 실행 보조자에게 수정하도록 한 다음, 다시 증거를 확보합니다.

“결과 수령 완료”는 “검수 완료”가 아닙니다. 증거가 현재 결과물과 일치하고 사람이 승인 판단을 내려야 작업이 진정으로 완료된 것입니다.

초보 사용자를 위한 권장 학습 순서

먼저 examples/의 주요 예제를 읽습니다.
examples/walkthrough-meeting-notes/를 따라 반려와 수정이 포함된 작은 작업을 한 번 완료합니다.
템플릿은 하나만 학습합니다: templates/task-register-line.md.
먼저 메모장이나 표를 사용하여 “수령 대기 → 수락 완료 → 결과 수령 완료 → 검수 완료”를 연습합니다.
방법에 익숙해진 후 지원되는 Agent 호스트에 스킬을 설치하고 이름으로 호출합니다.

이 방법 자체는 복잡한 프로그래밍 능력에 의존하지 않습니다. 작업을 명확히 작성하고, 실행 담당자를 배정하며, 결과를 확인할 수 있다면 공유 기록부터 시작할 수 있습니다.

고급 사용법

기록 필드를 기존 보드에 연결하기

이미 작업 시스템, 전자 스프레드시트 또는 프로젝트 보드를 사용하고 있다면 기록 행의 필드를 기존 흐름에 연결할 수 있습니다. 중요한 것은 어떤 도구를 사용하는지가 아니라 수령 대기 작업을 한눈에 볼 수 있게 하고, 작업 수락, 결과 수령, 검수 완료를 서로 다른 상태로 관리하는 것입니다.

여러 보조자의 역할 구분하기

스킬 패키지는 절차와 작성 방법을 제공하고, 호스트는 세션 시작, 명령 실행, 파일 읽기 및 쓰기, 그리고 가능한 경우 정기 알림이나 보조자 간 메시지 기능을 담당합니다. 사람은 목표 설정, 우선순위 결정, 위험한 작업 승인 및 최종 판단을 담당합니다.

흐름을 구축할 때는 다음을 차례로 확인할 수 있습니다.

호스트가 여러 세션 또는 하위 보조자를 동시에 열 수 있는가.
호스트가 보조자 간에 메시지를 보낼 수 있는가.
호스트에 정기 알림 또는 깨우기 기능이 있는가.
자동 알림이 없다면 누가 정해진 시간에 직접 확인할 것인가.
최종 검수와 위험한 작업을 누가 직접 확인하고 승인할 것인가.

영향을 받은 부분만 다시 확인하기

결과물이 수정된 후 모든 검사를 무조건 처음부터 다시 수행할 필요는 없습니다. 변경되지 않은 부분은 이전 검증 증거를 재사용할 수 있지만, 수정되었거나 실패했거나 수정의 영향을 받은 모든 부분은 다시 확인해야 합니다. 이렇게 하면 신뢰성을 유지하면서 반복 작업을 줄일 수 있습니다.

beginner-ops-writing으로 수동 단계 작성하기

로그인, 결제, 본인 확인처럼 반드시 사람이 수행해야 하는 단계가 있다면 beginner-ops-writing을 호출하여 한 번에 하나의 동작으로 단계를 나누고, 조작 대상과 예상 결과를 명확히 작성할 수 있습니다. 위험한 작업과 관련된 경우에는 “본인이 직접 진행해 주세요”라고만 안내하고, 보조자가 사람의 승인을 우회하려고 시도하게 해서는 안 됩니다.

ops-case-notes로 회고하기

작업 수락 누락, 검수 누락 또는 같은 실수가 반복해서 발생하면 ops-case-notes를 다시 확인합니다. 회고를 기록할 때는 실제 문제, 적용한 변경 방법, 실제 결과 및 아직 해결되지 않은 제한 사항 등 방법과 관련된 정보를 남기고, 개인 연락처, 자격 증명, 내부 경로 및 컴퓨터 정보를 제거해야 합니다.

반드시 알아야 할 자동화의 경계

이 패키지의 플러그인 목록에 있는 hooks: {}는 자동 깨우기 기능을 제공하지 않는다는 뜻입니다. 스킬을 설치했다고 해서 보조자가 이 방법에 따라 작업할 수 있게 될 뿐, 시스템이 자동으로 작업을 배정하거나, 정기적으로 재촉하거나, 세션 간에 메시지를 전달하거나, 자동 회신을 보내는 것은 아닙니다.

호스트에 정기 실행 기능이 있으면 호스트 기능으로 정해진 시간에 확인할 수 있습니다.
호스트에 정기 실행 기능이 없으면 사람이 정해진 시간에 확인해야 합니다.
보조자 간 알림, 그룹 채팅 및 공유 파일 읽기와 쓰기는 호스트에 따라 달라집니다.
비용 지출, 로그인, 결제 확인, 공식 발송 및 삭제 등의 작업은 반드시 사람이 승인해야 합니다.
수락, 반려 또는 방향 전환의 최종 결정은 항상 사람이 내립니다.

README에 언급된 약 10분은 설계 목표 중 하나일 뿐이며, 이미 검증된 보장으로 작성해서는 안 됩니다. 현재 Cursor CLI 측정은 호스트에 로그인과 설치가 완료되고, 저장소를 확보했으며, 프롬프트가 미리 준비된 조건에서 스킬 복사부터 기록 행 출력까지 약 29.6초가 걸린다는 결과입니다. 이는 처음 접하는 사용자가 호스트를 처음부터 설치하고 전체 작업을 완료하는 데 필요한 총 시간을 의미하지 않습니다.

설치가 실제로 성공했는지 판단하는 방법

프로젝트는 두 가지 엄격한 기준을 제시합니다.

설치하고 호출할 수 있는가: 확보, 설치 또는 구성을 완료하고 스킬 이름으로 호출하여 확인 가능한 기록 행을 생성할 수 있어야 합니다.
실제 작은 작업 하나를 완료할 수 있는가: 목표, 역할 분담 및 인계부터 증거 확인과 사람의 판단까지 진행하여 실제 결과물, 증거 및 검수 결론을 남겨야 합니다.

현재 8개 호스트에는 각각 제한된 작업에 대한 검수 기록이 하나씩 있지만, 이것이 안정성을 입증하는 것은 아니며 모든 작업을 완료할 수 있다는 뜻도 아닙니다. 프로젝트는 아직 대조 실험을 통해 전체 팀의 오류율이 낮아졌거나 재촉 횟수가 줄었다는 사실을 확인하지 못했습니다. 따라서 사용할 때는 사람의 감독을 유지해야 합니다.

맺음말

Solo to Team의 가치는 완전히 자동화된 AI 팀을 만드는 데 있지 않고, 명확하고 확인 가능하며 다른 환경으로 옮길 수 있는 협업 방법을 제공하는 데 있습니다. 먼저 dispatch-accept-verify와 evidence-before-done을 설치하고, 작은 작업 하나로 “수령 대기, 작업 수락, 결과 수령, 증거 확인, 사람의 검수”를 연습한 다음 여러 보조자와 기존 보드를 단계적으로 연결하세요. 어떤 호스트를 사용하든 같은 원칙을 지켜야 합니다. 보조자는 실행과 증거 제공을 담당하고, 사람은 목표, 권한 부여 및 최종 판단을 담당합니다.