Claude Code 끼리끼리 사용법, 고정 AI 팀은 판단을 일관되게 할까

Claude Code에 같은 전문가 팀을 계속 붙이면 판단도 한결같아질까. 끼리끼리(kkirikkiri)는 자연어 요청을 팀 구성과 실행으로 바꾸는 플러그인이다. 이 글은 설치부터 재사용까지 따라가며, 고정 팀이 실제로 고정하는 것이 무엇인지 묻는다.

끼리끼리는 고정 팀보다 저장 가능한 동적 팀에 가깝다

끼리끼리 README는 입력 뒤 2~3개 질문을 거쳐 팀을 만든다고 설명한다. 플러그인이 작업 의도와 설치 환경을 먼저 읽어 리서치, 개발, 분석, 콘텐츠, 제품 가운데 프리셋을 고른다. 같은 문장을 넣어도 환경과 답변에 따라 구성이 달라질 수 있다.

리서치는 기본적으로 리더와 리서처 둘로 시작한다. 개발은 리더와 개발자 둘, 콘텐츠는 작성자와 검토자를 붙인다. 프리셋은 완성된 조직도가 아니라 출발점이다.

방에서 고정 구성을 활용하자는 의견이 나온 이유는 이해하기 쉽다. 같은 역할과 검토 순서를 쓰면 판단 기준을 반복하기 편하다. 그러나 저장소는 동일한 결론이나 정확도를 보장하지 않는다. 모델 버전과 입력 맥락이 달라지면 결과도 바뀔 수 있다.

고정 팀은 실행 후 따로 저장해야 생긴다. 사용자가 저장에 동의하면 구성이 `.kkirikkiri/shared/saved-teams/` 아래에 남는다. 다음 세션에서 `/kkirikkiri use the research team from last time`처럼 불러올 수 있다. 잘 맞은 개별 에이전트는 `.claude/agents/`에 저장해 다른 프로젝트에서 재사용한다.

설치부터 report.md까지 네 번의 입력으로 이어진다

먼저 Claude Code에서 `/plugin marketplace add https://github.com/fivetaku/gptaku_plugins.git`를 실행한다. 이어 `/plugin install kkirikkiri@gptaku-plugins`로 플러그인을 설치한다. Anthropic은 외부 플러그인을 설치하기 전에 코드와 포함된 서버를 신뢰할 수 있는지 확인하라고 안내한다.

Agent Teams를 쓰려면 `~/.claude/settings.json`의 `env`에 `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`을 넣는다. 그다음 프로젝트 폴더에서 `/kkirikkiri 리서치 팀 만들어줘`처럼 목적을 적는다. Node.js는 외부 CLI 연동에 필요하다. tmux는 분할 화면을 볼 때만 선택 사항이다.

플러그인은 Codex CLI, Antigravity CLI의 `agy`, gajae-code의 `gjc`, 기존 `.claude/agents/`를 찾는다. 최근 계열은 외부 작업자 후보를 Codex, agy, gjc로 정리했다. 외부 CLI가 없어도 Claude만으로 실행할 수 있다.

사용자는 짧은 인터뷰에 답하고 제안된 역할과 실행 방식을 확인한다. Agent Teams 경로를 고르면 프로젝트에 세션별 폴더가 생긴다. `TEAM_PLAN.md`에는 목표와 담당을, `TEAM_PROGRESS.md`에는 진행 상태를 기록한다. `TEAM_FINDINGS.md`는 발견과 실패한 접근을 남긴다. `report.md`가 최종 결과를 모은다.

입력은 한 문장이지만 산출물은 계획, 작업 기록, 근거, 보고서로 나뉜다.

Agent Teams와 Workflow는 같은 병렬 실행이 아니다

Claude Code 자체도 자연어로 Agent Teams를 만들 수 있다. Anthropic 공식 문서에 따르면 팀원은 각자 독립 컨텍스트를 쓰고 공유 작업 목록과 메시지로 협업한다. 그러므로 "한 문장으로 팀 생성"만 끼리끼리의 독점 기능은 아니다.

차이는 팀을 짜는 정책에 있다. 끼리끼리는 인터뷰, 환경 스캔, 프리셋, 역할 카드, 검증 라운드를 한 흐름으로 묶는다. 1차 결과가 기준에 못 미치면 일부 팀원을 바꾸거나 전면 재구성한다. 공개 저장소는 이 과정을 최대 세 라운드로 제한한다.

Agent Teams는 서로 질문하고 반박해야 하는 조사와 디버깅에 맞는다. Anthropic은 독립 모듈 개발과 여러 관점의 리뷰도 강한 사례로 든다. 반대로 순차 작업, 같은 파일 수정, 의존성이 많은 작업에는 단일 세션이나 subagent가 낫다고 명시한다.

끼리끼리의 Workflow는 대량의 독립 작업을 정해진 순서로 흘려보내는 쪽이다. 최신 Claude Code의 Dynamic Workflows도 JavaScript로 병렬 실행과 교차검증을 구성한다. 팀원 대화가 필요하면 Agent Teams, 반복 가능한 팬아웃이면 Workflow라는 구분이 핵심이다.

일관성은 역할 이름보다 기록과 완료 조건에서 나온다

같은 팀 이름만 유지해도 기준이 자동으로 고정되지는 않는다. 역할 카드에 담당 범위, 사용 도구, 실패 조건, 산출물 형식을 적어야 한다. `CLAUDE.md`에는 파일 규칙과 테스트 명령을 분명히 두는 편이 좋다. 각 에이전트가 프로젝트 규칙을 따로 읽기 때문이다.

직접 운용해 본 사람들 사이에서는 역할보다 작업 경계가 중요하다는 반응이 많다. 한 에이전트에는 한 기능, 한 파일 묶음, 한 가설처럼 독립된 소유권을 주라는 조언이다. 팀원이 같은 파일을 만지면 덮어쓰기가 생길 수 있다는 Anthropic의 경고와도 맞는다.

판단형 작업은 반대 관점을 일부러 넣을 때 팀의 의미가 커진다. 예를 들어 리서처 둘이 같은 자료를 나누는 대신, 한쪽은 근거를 세우고 다른 쪽은 반례를 찾게 할 수 있다. 리더는 두 결과를 합치기 전에 불일치와 미확인 항목을 검사한다. 이런 프로토콜이 고정돼야 다음 실행과 비교할 수 있다.

`TEAM_FINDINGS.md`에 실패 경로까지 남기는 이유도 여기에 있다. 새 팀원이 결론만 읽으면 같은 실수를 되풀이할 수 있다. 판단의 재현성은 사람 구성이 아니라 판단 과정의 흔적에서 나온다.

작은 팀에는 세 명으로 시작할 이유가 있다

Agent Teams는 팀원마다 별도 컨텍스트를 사용한다. Anthropic은 토큰 사용이 팀원 수에 따라 늘고 조율 비용도 커진다고 밝힌다. 공식 권장은 대개 3~5명부터 시작한다. 다만 작고 명확한 팀이 더 낫다는 쪽이다.

써본 사람들 사이에서도 단순 병렬 작업은 subagent가 싸고 빠르다는 불만이 반복된다. 팀 간 메시지와 대기, 상태 복구가 실제 작업보다 길어질 수 있다는 것이다. 반면 여러 가설을 서로 깨뜨리거나 긴 조사를 분리할 때는 추가 비용을 받아들일 만하다는 의견도 있다.

현재 Agent Teams는 실험 기능이다. 공식 문서는 in-process 팀원의 세션 복원 불가, 늦게 갱신되는 작업 상태, 느린 종료를 제한으로 적는다. 한 세션에는 한 팀만 둘 수 있고 팀원이 다시 하위 팀을 만들 수도 없다.

개인 개발자와 소규모 팀이 끼리끼리에서 얻는 핵심은 인원 증가가 아니다. 잘 작동한 역할, 작업 경계, 검증 순서, 실패 기록을 다음 작업에 다시 적용하는 능력이다. 고정 팀이 일관성을 만드는 것이 아니라, 저장된 운영 규칙이 팀을 일관되게 만든다.