프로젝트 루트가 AI 설정 파일의 무덤이 되고 있다
Cursor를 쓰는 팀원은 .cursorrules를, Claude Code를 쓰는 팀원은 CLAUDE.md를, Copilot 사용자는 .github/copilot-instructions.md를 각각 관리합니다. 내용은 거의 같습니다 — "Python 프로젝트, FastAPI 사용, pytest로 테스트, PEP 8 준수" — 그런데 파일은 6개이고, 한 곳을 고치면 나머지 다섯 곳은 드리프트합니다. AI-First를 선언한 팀일수록 이 문제가 먼저 터집니다. 도구를 많이 쓸수록 설정의 엔트로피가 빠르게 증가하기 때문입니다.
이 문제에 정면으로 대응한 도구가 dotai입니다(dev.to, Lakshmi Sravya Vedantham). .ai/config.yml 하나를 단일 진실 공급원(Single Source of Truth)으로 두고, 어댑터 패턴을 통해 Claude·Cursor·Copilot·Windsurf·Cline·Aider 등 6개 도구의 네이티브 포맷으로 동기화합니다. dotai init이 프로젝트를 자동 감지하고, dotai sync가 설정을 일괄 생성하며, dotai diff로 변경 사항을 미리 확인할 수 있습니다. 어댑터 하나 추가하는 데 약 50줄이면 되니, 새 도구가 등장해도 체인에 빠르게 편입시킬 수 있습니다.
MCP 서버 설정 지옥, 패키지 매니저로 해결한다
도구 설정 통합이 '입력 쪽' 문제라면, MCP(Model Context Protocol) 서버 관리는 '연결 쪽' 문제입니다. AI 에이전트가 외부 서비스 — DB, 클라우드, 파일시스템 — 에 접근하려면 MCP 서버를 띄워야 하는데, npm 패키지 이름을 찾고, JSON 설정을 손으로 편집하고, API 키를 맞는 위치에 끼워 넣는 과정이 매번 반복됩니다. 같은 개발자가 만든 mcpx는 이 과정을 pip install mcpx → mcpx search → mcpx install로 축약합니다. 50개 이상의 큐레이션된 서버 레지스트리, Claude Code·Cursor·VS Code 플랫폼 자동 감지, mcpx doctor를 통한 설정 진단까지 — MCP 생태계에 '패키지 매니저'라는 결여된 레이어를 채워 넣은 셈입니다.
요구사항이 채팅 창에서 증발하지 않으려면
설정과 연결을 잡았다면 다음 병목은 컨텍스트 유실입니다. AI 코딩 도구에 요구사항을 채팅으로 던지는 순간, 그 맥락은 에디터 히스토리 속에 묻힙니다. Rizm은 셀프호스트 태스크 + 위키 도구로, MCP를 통해 Cursor와 직접 연결됩니다(dev.to, Kent). Cursor의 Plan Mode에서 태스크 키를 입력하면 Rizm에서 요구사항을 가져와 구현 계획을 생성하고, 구현 후에는 계획 문서를 태스크 코멘트로 자동 기록합니다. 하나의 태스크 안에 요구사항·구현 계획·브랜치 참조가 모두 남으니, '채팅이 아니라 태스크가 워크플로우의 중심'이라는 AI-First 팀의 원칙이 구조적으로 강제됩니다.
Amazon이 Claude Code를 막고 Kiro를 밀어붙이는 이유
도구 체인 통합이 개별 팀의 문제라면, 도구 선택의 자유 자체가 제한되는 상황은 조직 차원의 문제입니다. KM Journal 보도에 따르면, Amazon은 내부 개발자의 Claude Code 사용을 제한하고 자체 AI 코딩 도구 Kiro 사용을 권장하고 있습니다. 외부 고객에게는 AWS를 통해 Claude를 판매하면서, 내부에서는 차단하는 모순적 구도입니다. 그 이면에는 세 가지 논리가 있습니다. 첫째, AI 코딩 어시스턴트가 내부 코드베이스·아키텍처 패턴과 상호작용하면서 축적되는 메타데이터의 데이터 주권 문제. 둘째, 자체 도구를 실전에서 갈아 닦는 독포딩(dogfooding) 전략. 셋째, AI 도구 사용량을 인사 평가에 반영하면서 '어떤 AI를 쓰느냐'가 기술적 선호가 아닌 거버넌스 이슈로 격상된 현실.
AI-First 팀의 도구 거버넌스: 세 가지 레이어로 설계하라
이 네 가지 소스를 겹쳐 놓으면, AI-First 팀이 도구 체인을 관리해야 하는 레이어가 명확히 드러납니다.
- 설정 레이어 — dotai처럼 단일 설정 파일에서 모든 도구의 규칙을 동기화합니다. 도구가 바뀌어도 규칙은 유지됩니다.
- 연결 레이어 — mcpx처럼 MCP 서버 의존성을 코드 의존성 수준으로 관리합니다.
package.json이 npm 생태계를 제어하듯, MCP 레지스트리가 에이전트의 외부 연결을 제어합니다. - 컨텍스트 레이어 — Rizm처럼 요구사항-구현-결과를 태스크 단위로 묶어 AI가 참조하는 맥락의 수명을 채팅 세션이 아닌 프로젝트 생애 주기로 확장합니다.
그리고 이 세 레이어 위에 Amazon 사례가 던지는 거버넌스 레이어가 놓입니다. 팀이 어떤 도구를 쓸 수 있는지, 내부 코드가 외부 모델에 노출되는 범위는 어디까지인지, 도구 선택의 자율성과 조직의 데이터 주권 사이 균형점을 어떻게 잡을 것인지. AI 도구가 난립할수록 이 질문은 더 절박해집니다.
결국 AI-First 팀의 진짜 경쟁력은 '어떤 AI 도구를 쓰느냐'가 아니라 '도구 체인을 얼마나 일관되게 제어할 수 있느냐'에 달려 있습니다. dotai·mcpx·Rizm 같은 도구들이 이제 막 등장하기 시작했다는 건, 이 문제가 더 이상 개인의 .dotfiles 취향이 아니라 팀 인프라의 영역으로 넘어왔다는 신호입니다. AI 도구를 도입하는 속도보다, 도구들을 하나의 체인으로 엮어 관리하는 시스템을 먼저 만들어야 합니다. 그래야 도구가 바뀌어도 팀은 흔들리지 않습니다.