큐레이션
TeamAI: 여러 코딩 에이전트에 팀 규칙과 지식을 어떻게 나눌까
Claude Code·Codex·Cursor 같은 코딩 에이전트에 팀의 Skills·Rules·MCP·지식을 Git으로 나눌 때, 저장소 권한과 에이전트별 적용 범위를 먼저 판단하는 방법
Claude Code, Codex, Cursor 같은 코딩 에이전트를 팀에서 함께 쓰면 규칙·Skills·MCP 설정이 사람마다 달라지기 쉽습니다. TeamAI는 공유 Git 저장소의 팀 리소스를 여러 에이전트에 나누고, 팀 지식을 검색하는 흐름까지 연결하려는 CLI입니다. 도입 전에는 어떤 내용을 공유할지, 에이전트가 어디까지 실행할지, 사람이 어디서 승인할지를 먼저 정하면 작은 범위로 시험할 수 있습니다.
팀의 AI 사용 방식은 왜 자주 달라지나요?
개인이 만든 작업 지침은 그 사람의 에이전트 설정에만 남기 쉽습니다. 한 사람이 정리한 규칙이나 실패 기록을 다른 구성원이 다음 작업에서 바로 참고하지 못하면, 같은 문제를 다시 설명하고 같은 실수를 반복하게 됩니다.
TeamAI 공식 README는 팀의 Skills, Rules, Docs, Env, Agents, Hooks, MCP를 공유 Git 저장소에 두고 각자의 AI 도구로 배포하는 흐름을 설명합니다. push → 검토·병합 → pull을 기본 단위로 삼기 때문에, 공유 파일을 바꾸는 과정에 기존 코드 협업의 검토 절차를 적용할 수 있습니다.
무엇을 공유하고 무엇을 나중에 붙일까요?
먼저 팀 실행 규칙을 나눕니다
TeamAI의 기본 실행 영역은 init, pull, push와 Skills, Rules, Docs, Agents, Hooks, MCP, 환경 설정입니다. 팀이 자주 쓰는 요청 형식과 결과 확인 항목을 Skills나 Rules로 정리하고, 도구 연결은 필요한 에이전트와 저장소에만 적용하는 식으로 범위를 정할 수 있습니다.
공식 사용 가이드는 프로젝트 범위와 사용자 범위를 구분합니다. 프로젝트 범위는 현재 저장소에 필요한 규칙을 두는 방식이고, 사용자 범위는 여러 프로젝트에서 공통으로 쓸 리소스를 관리하는 방식입니다. 처음에는 별도 테스트 저장소의 프로젝트 범위로 시작하는 편이 적용 대상을 확인하기 쉽습니다.
팀 지식은 실행 규칙과 구분합니다
공식 문서가 설명하는 Team Context 영역에는 recall, learnings, 문서와 코드베이스 그래프가 있습니다. 이 영역은 에이전트가 팀의 과거 지식과 코드 구조를 찾도록 돕는 기능입니다.
지식 검색이 된다는 사실과 검색 결과가 현재 업무에 맞다는 사실은 다릅니다. 먼저 검색 결과가 어떤 원문 파일을 가리키는지 확인하고, 오래된 규칙이나 프로젝트 전용 지식이 다른 구성원에게 섞이지 않는지 점검해야 합니다.
개선 기능은 beta로 따로 판단합니다
TeamAI는 세션의 마찰을 바탕으로 learnings를 공유하고, session save, digest, dashboard로 사용 흐름을 살펴보는 Team Improvement 영역도 안내합니다. 공식 README에서 Team Context와 Team Improvement는 beta로 표시되어 있으므로, 핵심 규칙 배포와 같은 안정성으로 가정하지 않는 편이 좋습니다.
도입 전에 어떤 권한 경계를 정해야 하나요?
TeamAI 공식 시작 절차는 공유 경험 저장소를 만들고 팀 구성원에게 쓰기 권한을 준 뒤 teamai init을 실행하는 방식입니다. 따라서 도입의 첫 질문은 어떤 AI 도구를 지원할지가 아니라 누가 팀 저장소를 바꾸고 누가 검토할지입니다.
다음 항목은 저장소와 팀 규칙에 먼저 적어 두는 편이 좋습니다.
- Skills·Rules·MCP 설정을 작성할 수 있는 사람과 검토할 사람은 누구인가요?
- 프로젝트 범위와 사용자 범위 중 어느 곳에 리소스를 설치하나요?
- Claude Code·Codex·Cursor 등 각 에이전트에 실제로 적용할 기능은 무엇인가요?
- 에이전트가 읽을 수 있는 폴더와 호출할 수 있는 MCP 도구는 어디까지인가요?
- 발송·삭제·배포처럼 되돌리기 어려운 작업을 실행하기 전에 누가 확인하나요?
공식 README도 공유 환경 변수에 비밀값을 넣지 말라고 안내합니다. API 키와 개인 토큰은 팀 리소스 배포 파일과 분리하고, 실제 연결 전에는 읽기 전용 계정과 허용된 작업부터 시험해야 합니다.
공식 원문에서 확인한 현재 범위는 무엇인가요?
공식 README는 npm install -g teamai-cli로 설치한 뒤 공유 Git 저장소에 teamai init을 실행하는 시작 흐름을 안내합니다. GitHub·GitLab·GitCode·CNB·TGit과 사설 Git 서비스에 대한 저장소 연결도 설명합니다.
README의 에이전트별 표에는 Claude Code, Codex, Cursor, CodeBuddy, WorkBuddy, OpenCode 등이 나오며 기능별 지원 범위가 서로 다르게 표시됩니다. 여러 에이전트를 지원한다는 문구만 보고 모든 기능이 같은 방식으로 작동한다고 판단하면 안 되는 이유입니다.
2026년 9월 12일 GitHub API에서 Tencent/teamai-cli는 별 4,150개, 주 언어 TypeScript, 2026년 9월 11일 최근 push로 확인했습니다. 같은 저장소의 최신 안정 릴리스는 v0.23.1이고, v0.24.0-beta.8은 사전 공개 버전입니다. 별 수와 릴리스 기록은 공개 활동과 변경 시점을 보여 줄 뿐, 팀의 보안 적합성이나 운영 성과를 보증하지 않습니다.
어떤 한계를 먼저 확인해야 하나요?
- 팀 저장소의 쓰기 권한과 검토 절차가 없으면 설정을 모으는 것만으로 끝날 수 있습니다.
- 에이전트마다 Hooks·Agents·Team Improvement 같은 기능의 지원 표시가 다르므로 실제 적용 결과를 도구별로 확인해야 합니다.
pull로 최신 팀 리소스를 배포하는 흐름은 편리하지만, 검토되지 않은 규칙이 여러 개발 환경에 퍼지는 범위도 커질 수 있습니다.- 팀 지식 검색과 코드베이스 그래프가 원문을 대신 검수해 주지는 않습니다. 오래된 문서와 프로젝트별 권한을 계속 관리해야 합니다.
- 이 저장소에서 TeamAI를 직접 설치하거나 여러 에이전트의 동작·비용·성능을 비교한 것은 아닙니다.
처음에는 어떻게 시험할까요?
버려도 되는 테스트 저장소를 하나 만들고 Skills 하나, Rules 하나, 동작을 바꾸지 않는 예시 MCP 하나만 넣어 보세요. 프로젝트 범위로 teamai init을 실행한 뒤 한 구성원이 변경을 push하고, 다른 구성원이 검토·병합한 다음, 두 종류의 에이전트에서 실제 파일과 설정이 의도한 범위에만 들어오는지 확인합니다.
그 다음에는 다음 실패 상황을 차례로 시험하세요.
- 지원 대상에서 제외한 에이전트에 리소스가 설치되지 않는지 확인합니다.
- 비밀값이 들어간 파일이 공유 대상에 포함되지 않는지 확인합니다.
- 잘못된 Rule을 되돌리고 다음
pull에서 이전 상태로 복구되는지 확인합니다. - MCP는 읽기 전용 도구부터 연결하고, 외부 변경 작업은 별도 승인 단계로 남깁니다.
팀의 AI 활용 목적에 맞춰 역할·참고 자료·도구·권한·승인 단계를 정리하려면 AI 에이전트 설정과 활용 과정에서 교육 대상과 실습 결과물을 확인할 수 있습니다. TeamAI 자체의 배포를 대신하는 과정이 아니라, 어떤 업무를 에이전트에 맡기고 어떤 결과를 사람이 확인할지 정하는 실습에 초점을 둡니다.