Shopify CEO 토비 뤼트케, AGENTS.md 파일 문제로 Claude Code 금지 검토 — 이 '작은' 파일이 AI 코딩을 재편할 수 있는 이유

핵심 요약

• Shopify CEO 토비 루트케는 2026년 8월 25일 Claude Code가 AGENTS.md, .agents/skills/ 및 유사한 벤더 중립적 에이전트 설정을 직접 읽을 수 있을 때까지 Shopify 내 사용 금지를 고려 중이라고 밝혔습니다.
• 이 논쟁은 단일 Markdown 파일 이름에 관한 것이 아닙니다. 저장소 수준의 AI 지시사항이 특정 코딩-에이전트 벤더에 귀속되어야 하는지, 아니면 도구 간에 이식 가능하게 유지되어야 하는지에 관한 문제입니다.
• Claude Code는 여전히 CLAUDE.md를 자체 네이티브 프로젝트 메모리 파일로 취급합니다. 팀들은 AGENTS.md를 가져오거나, CLAUDE.md에서 참조하거나, 심볼릭 링크를 사용할 수 있지만, 이러한 접근 방식은 대규모 저장소에서 조정 오버헤드를 증가시킵니다.
• Shopify는 이 문제에 특별히 민감한데, 그 이유는 회사 차원의 AI 에이전트가 사용하는 코드, 스킬, 규칙, 실행 매뉴얼, AGENTS.md 파일 및 기타 기계 가독 엔지니어링 지식을 포함하는 World 모노레포를 보유하고 있기 때문입니다.
• 장기적으로 가능성 있는 아키텍처는 벤더 중립적 지시사항 레이어 하나에 도구별 선택적 오버라이드를 추가하는 방식이며, 모든 AI 코딩 제품마다 동일한 규칙을 별도로 복제하는 방식은 아닐 것입니다.
• 2026년 8월{masked} 일 기준, Claude Code는 마이그레이션 및 상호 운용성 기능을 개선했지만, 공식 프로젝트-메모리 동작은 여전히 CLAUDE.md와 네이티브 AGENTS.md 발견을 구분합니다.

Shopify와 Claude Code 사이에 무슨 일이 있었나요?

2026년 8월 25일, Shopify CEO 토비 루트케는 Claude Code가 저장소 지시사항을 처리하는 방식에 대해 Anthropic에 공개적으로 문제를 제기했습니다.

루트케는 Claude Code가 AGENTS.md, .agents/skills/ 및 관련 공유 에이전트 설정을 직접 읽을 수 있을 때까지 Shopify 내에서 해당 도구 사용을 금지하는 것을 고려 중이라고 밝혔습니다. 그의 우려는 CLAUDE.md를 고집할 경우 동일한 저장소에서 작업하는 엔지니어들이 서로 다른 AI 코딩 에이전트를 사용할 때 분리된 의사 결정 문제가 발생할 수 있다는 점이었습니다.

표현이 중요합니다. Shopify는 완료된 전사적 사용 금지를 발표한 것이 아닙니다. 이 발표는 조직 규모에서 비용이 많이 드는 도구 설계 결정에 대한 공개 경고였습니다.

Claude Code 팀 멤버 타리크 시히파르는 Anthropic이 Claude Code를 더 쉽게 수정 가능하게 만드는 작업을 진행 중이라고 응답했으며, 여기에는 Agents.MD 사용 편의성 개선과 더 광범위한 시스템 프롬프트 사용자 정의가 포함됩니다.

이 응답은 해당 사건을 단순한 소셜 미디어 논쟁 이상으로 만듭니다. 이는 빠르게 성장하는 인프라 문제를 드러냅니다: AI 코딩 에이전트가 의존하는 프로젝트 컨텍스트의 소유자는 누구인가요?

AGENTS.md가 중요한 이유

AGENTS.md는 코딩 에이전트에게 지속적인 프로젝트 컨텍스트를 제공하기 위해 설계된 저장소 수준의 지시사항 파일입니다.

유용한 AGENTS.md는 에이전트에게 다음을 알려줄 수 있습니다:

• 저장소 구조가 어떻게 구성되어 있는지;
• 사용할 패키지 관리자와 명령어;
• 테스트 실행 방법;
• 건드리지 말아야 할 아키텍처 경계;
• 수동으로 편집해서는 안 되는 생성된 파일;
• 데이터베이스 마이그레이션 처리 방법;
• 적용되는 보안 또는 호환성 제약 조건;
• 더 광범위한 기본값을 재정의하는 디렉터리별 규칙.

간소화된 예시는 다음과 같습니다:

# 저장소 지침

패키지 관리자: pnpm

풀 리퀘스트를 열기 전에:
- pnpm lint 실행
- pnpm test 실행
- pnpm typecheck 실행

생성된 GraphQL 파일을 수동으로 편집하지 마세요.

packages/payments 아래의 변경사항은 하위 호환성을 보존해야 합니다.

중요한 속성은 마크다운 자체가 아닙니다. 중요한 속성은 이식성입니다.

동일한 저장소가 Codex, Gemini CLI, Cursor, GitHub Copilot, Claude Code 및 향후 에이전트들과 함께 사용된다면, 의미적으로 동등한 여섯 개의 복사본을 유지하는 것보다 하나의 표준 프로젝트 규칙 집합을 유지하는 것이 더 안전합니다.

CLAUDE.md vs AGENTS.md: 진정한 차이점

Claude Code는 CLAUDE.md를 기본 저장소 메커니즘으로 사용합니다.

이를 통해 Anthropic은 Claude 모델과 Claude Code 워크플로우에 특화된 지침을 최적화할 수 있습니다. 도구별 구성은 본질적으로 나쁜 것이 아닙니다. 사실, 특정 지침은 Claude Code에만 유용할 수 있습니다.

문제는 도구별 구성이 공유 저장소 정책에 대한 유일한 신뢰할 수 있는 경로가 될 때 시작됩니다.

건전한 구분은 다음과 같습니다:

이 계층화된 모델을 통해 팀은 이번 분기에 인기 있는 에이전트와 관계없이 프로젝트 진실성을 독립적으로 유지할 수 있습니다.

코딩 저장소에서 "분열된 두뇌"는 무엇을 의미하나요?

중첩된 지침이 있는 대규모 모노레포를 고려해보세요:

world/
├── AGENTS.md
├── CLAUDE.md
├── checkout/
│   ├── AGENTS.md
│   └── CLAUDE.md
├── payments/
│   ├── AGENTS.md
│   └── payments-api/
│       └── AGENTS.md
└── storefront/
    ├── AGENTS.md
    └── CLAUDE.md

이제 payments-api/AGENTS.md에 중요한 규칙이 포함되어 있다고 가정합니다:

모든 결제 API 변경은 하위 호환성을 유지해야 합니다.

결제 상태 전환을 수정하기 전에 통합 테스트 스위트를 실행하세요.

중첩된 AGENTS.md 파일을 자동으로 발견하는 에이전트는 해당 규칙을 받을 수 있습니다.

다른 계층의 CLAUDE.md 파일에만 의존하는 Claude Code 세션은 저장소가 의도적으로 미러링하거나 가져오지 않는 한 동일한 정보를 받지 못할 수 있습니다.

따라서 두 엔지니어는 서로 다른 에이전트에 동일한 패키지를 수정하도록 요청하면서도 무의식적으로 서로 다른 정책 집합을 제공할 수 있습니다.

이것이 분열된 두뇌입니다:

저장소 진실
 |
 +--> 에이전트 A는 루트 + payments + payments-api 규칙을 봄
 |
 +--> 에이전트 B는 루트 + payments 규칙만 봄

코드는 공유되지만, AI 컨텍스트는 공유되지 않습니다.

작은 프로젝트의 경우 이는 불편함일 수 있습니다. 대규모 회사의 경우 이는 엔지니어링 거버넌스 문제가 됩니다.

심볼릭 링크가 완전한 기업 솔루션이 아닌 이유

명백한 해결책은 간단합니다:

ln -s AGENTS.md CLAUDE.md

또 다른 옵션은 공유 지침을 가져오는 CLAUDE.md 파일입니다:

@AGENTS.md

## Claude 코드

src/billing/ 아래 변경 사항에 대해 계획 모드를 사용하세요.

두 가지 모두 유용하며 중소 규모 저장소에서는 완전히 합리적일 수 있습니다.

문제는 이 해결책이 작동하는지 여부가 아닙니다. 문제는 거대한 디렉토리 트리 어디에서도 이 해결책이 작동하지 않는 일이 절대 발생하지 않도록 보장하는 것입니다.

대규모에서는 팀이 다음과 같은 질문에 답해야 합니다:

• 모든 중첩된 AGENTS.md에 Claude가 볼 수 있는 해당 경로가 있습니까?
• 팀이 새 패키지를 만들고 어댑터를 잊어버리면 어떻게 됩니까?
• 심볼릭 링크가 Windows 및 모든 개발 환경에서 일관되게 처리됩니까?
• 생성된 CLAUDE.md가 표준 AGENTS.md와 차이가 생길 수 있습니까?
• CI가 이 관계를 검증합니까?
• 로컬 재정의가 일관되게 해석되고 있습니까?
• 마이그레이션 도구가 구성을 한 번만 복사하도록 합니까, 아니면 시간이 지나도 동기화를 유지하도록 합니까?

따라서 이 해결책은 테스트, 린팅, 자동화 및 소유권이 필요한 추가 시스템을 만들 수 있습니다.

이것이 바로 이 논쟁을 마크다운 논쟁이 아닌 복잡성 부담 논쟁으로 이해하는 것이 가장 좋은 이유입니다.

Shopify가 중요한 테스트 케이스인 이유

Shopify는 이미 AI 에이전트 중심으로 엔지니어링 환경의 상당 부분을 재편성했습니다.

Shopify의 대규모 모노레포인 World는 단순한 코드 컨테이너가 아닙니다. Shopify는 이곳에 코드와 함께 스킬, 컨벤션, 의도 문서, 런북, AGENTS.md 파일 및 문서화된 도메인 지식이 담겨 있다고 설명했습니다.

이는 저장소 지침이 더 이상 장식용 문서가 아니라 기계가 읽을 수 있는 조직적 기억으로 점점 더 작용하고 있기 때문에 중요합니다.

Shopify의 내부 에이전트인 River는 관련 규모를 보여줍니다. 보고된 30일 동안 River는 수천 개의 Slack 채널에서 수만 건의 세션을 처리했으며 수천 개의 병합된 풀 리퀘스트를 공동 작성했습니다.

River는 Shopify의 에이전트 플랫폼인 Aquifer 위에 위치하며, 이 플랫폼은 지속적 세션, 에이전트 하네스, 샌드박스, 자격 증명, 게이트웨이 및 관찰 가능성을 분리합니다.

이 플랫폼의 중요한 아키텍처 목표 중 하나는 교체 가능성입니다: 모델, 런타임 및 하네스 구현은 주변 전체 시스템을 변경하도록 강제하지 않고 교체 가능해야 합니다.

한 벤더에 긴밀하게 연결된 저장소 지식 계층은 이 철학에 반합니다.

더 깊은 아키텍처: 저장소 지식은 에이전트보다 더 오래 지속되어야 한다

Shopify 분쟁에서 얻은 가장 중요한 교훈은 저장소가 AI 런타임 환경으로 진화하고 있다는 점입니다.

역사적으로 저장소에는 다음이 포함되었습니다:

README.md
package.json
.gitignore
CI 구성 파일
소스 코드
테스트 코드

에이전트 준비 저장소에는 점점 더 많은 내용이 포함됩니다:

README.md
AGENTS.md
skills/
runbooks/
아키텍처 결정 기록
도구 정책
평가 규칙
자동화 훅
저장소별 메모리

이러한 파일들은 수년간 유용하게 사용될 수 있습니다.

팀이 사용하는 AI 코딩 도구는 몇 달마다 변경될 수 있습니다.

이로부터 기본 설계 원칙이 도출됩니다:

지속 가능한 프로젝트 지식은 단일 에이전트 벤더의 수명보다 더 긴 라이프사이클을 가져야 합니다.

이는 팀들이 환경 변수, 패키지 메타데이터, 소스 제어, 프로토콜 인터페이스에 이식 가능한 표준을 선호하는 이유와 동일합니다.

Claude Code의 현재 지원 기능

2026년 8월 26일 기준, Claude Code는 의미 있는 상호운용성 기능을 가지고 있지만, 기본 프로젝트 메모리 모델은 여전히 CLAUDE.md를 중심으로 합니다.

이 차이는 놓치기 쉽습니다.

마이그레이션 지원은 지속적인 기본 검색과 동일하지 않습니다.

/import이 한 번 클로드 구성에 명령을 복사하면, 기본 파일을 참조하지 않는 한 원본 AGENTS.md의 향후 편집은 동기화 전략이 필요합니다.

.agents/skills/ 폴더가 같은 논쟁에 포함되는 이유

저장소 지침 파일은 다음과 같은 질문에 답합니다:

이 프로젝트에서 에이전트는 어떻게 작동해야 하는가?

스킬 파일은 다른 질문에 답합니다:

에이전트가 특정 작업을 수행해야 할 때 로드할 수 있는 재사용 가능한 능력은 무엇인가?

스킬에는 다음과 같은 내용이 포함될 수 있습니다:

release-check/
├── SKILL.md
├── scripts/
├── references/
└── assets/

예를 들어, 릴리스 스킬은 에이전트에게 다음 방법을 가르칠 수 있습니다:

• 변경 로그를 검증하는 방법;
• 버전 관리 규칙을 점검하는 방법;
• 릴리스 테스트를 실행하는 방법;
• 패키지 출처를 확인하는 방법;
• 릴리스 체크리스트를 작성하는 방법.

에이전트 스킬 형식은 스킬 구조와 점진적 로딩 동작에 중점을 둡니다. .agents/skills/ 위치는 핵심 형식에 정의된 유일한 설치 위치가 아니라 여러 클라이언트 간 상호 운용성 관습으로 등장했습니다.

그 미묘한 차이가 중요합니다.

생태계는 한 번에 두 가지 다른 계층에서 표준화되고 있습니다:

1. 에이전트 스킬의 형식;
2. 여러 클라이언트가 스킬을 발견해야 하는 위치.

Shopify의 요청은 두 계층 모두를 연결합니다. 모든 코딩 에이전트가 서로 다른 디렉토리 레이아웃을 요구한다면 이식 가능한 스킬의 유용성이 떨어지기 때문입니다.

Anthropic이 여전히 CLAUDE.md를 원할 수 있는 이유

Anthropic 측에도 합리적인 기술적 논거가 있습니다.

서로 다른 모델 계열은 동일한 시스템 지침에 최적으로 반응하지 않을 수 있습니다.

Claude 전용 파일은 다음과 같은 선호도를 표현할 수 있습니다:

@AGENTS.md

## Claude 전용 지침

복잡한 리팩토링 작업 시:
- 수정하기 전에 인접한 추상화를 점검하라;
- 세 개 이상의 패키지를 건드리기 전에 계획 모드를 사용하라;
- 구현 메모를 간결하게 유지하라;
- 생성된 산출물을 확인한 후 작업을 종료하라.

이러한 구성은 이식 가능한 기본 구성과 공존할 수 있습니다.

잘못된 접근은 이식성과 모델별 최적화를 상호 배타적으로 취급하는 것입니다.

더 강력한 아키텍처는 다음과 같습니다:

          저장소
               |
            AGENTS.md
      공유 프로젝트 정책
               |
     +---------+---------+
     |         |         |
 Claude Code  Codex   Gemini CLI
     |         |         |
 CLAUDE.md  재정의   재정의
 선택적 튜닝

이 모델에서 벤더 구성은 진실의 원본을 중복하는 것이 아니라 재정의 계층이 됩니다.

AGENTS.md가 생태계 표준으로 자리 잡고 있다

이 논의가 중요한 이유는 AGENTS.md가 더 이상 모호한 규칙이 아니기 때문입니다.

2025년 8월 출시 이후, 이 형식은 60,000개 이상의 오픈소스 프로젝트와 에이전트 프레임워크에서 채택된 것으로 보고되었습니다. 이 생태계에는 주요 코딩 에이전트 제품과 개발자 환경이 포함됩니다.

2025년 12월, AGENTS.md는 Linux Foundation 산하의 Agentic AI Foundation에 기여되어 이 규칙을 위한 중립적인 거버넌스 경로가 마련되었습니다.

Anthropic은 더 넓은 재단 활동의 일부이며, 그들의 Model Context Protocol은 또 다른 주요 오픈 에이전트 인프라를 대표합니다.

이로 인해 중요한 전략적 패턴이 형성되었습니다:

• MCP는 에이전트가 도구와 데이터에 연결되는 방식을 표준화합니다.
• AGENTS.md는 저장소가 프로젝트 지침을 전달하는 방식을 표준화합니다.
• Agent Skills는 절차적 지식의 재사용 가능한 묶음을 표준화합니다.
• 벤더별 파일은 특정 에이전트에 대한 동작을 최적화합니다.

이러한 계층들은 서로 다른 문제를 해결하며 함께 작동할 수 있습니다.

떠오르는 오픈 에이전트 스택

완성된 에이전트 지원 프로젝트는 결국 다음과 같이 보일 수 있습니다:

project/
├── AGENTS.md
├── .agents/
│   └── skills/
│       ├── deploy/
│       │   └── SKILL.md
│       ├── database-migration/
│       │   └── SKILL.md
│       └── security-review/
│           └── SKILL.md
├── CLAUDE.md
├── .claude/
│   └── skills/
├── .cursor/
├── package.json
└── src/

장기적인 목표는 모든 벤더 디렉토리를 제거하는 것이 되어서는 안 됩니다.

목표는 벤더 디렉토리를 선택적인 전문화 계층으로 만드는 것이어야 합니다.

팀은 프로젝트의 아키텍처 메모리를 잃지 않고 하나의 코딩 에이전트를 제거하고 다른 에이전트를 채택할 수 있어야 합니다.

현재 다중 에이전트 팀을 위한 실용적 설정

원본 동작이 수렴될 때까지, 팀은 표준 소스 전략으로 위험을 줄일 수 있습니다.

1. 공유 정책을 AGENTS.md에 넣기

아키텍처, 명령어, 테스트, 안전 규칙 및 디렉토리별 제약 조건을 이식 가능한 파일에 유지하세요.

핵심 저장소 정보를 CLAUDE.md에만 두지 마세요.

2. CLAUDE.md가 표준 파일을 가져오도록 만들기

@AGENTS.md

## Claude Code 전용 지침

패크로스 패키지 리팩터링에는 계획 모드를 선호합니다.

이렇게 하면 중복을 최소화하면서 Claude 전용 튜닝을 보존할 수 있습니다.

3. 중첩 파일에 대한 CI 검사 추가

대형 모노레포는 호환 가능한 Claude Code 경로 없이 새로운 중첩 AGENTS.md가 생성될 때 이를 감지해야 합니다.

개념적 검사는 다음을 강제할 수 있습니다:

모든 중첩 AGENTS.md에 대해:
  Claude Code가 동일한 표준 지침에 도달할 수 있는지 확인

정확한 구현은 저장소 계층 구조와 선택한 가져오기 전략에 따라 달라집니다.

4. 에이전트 컨텍스트도 테스트하세요, 파일만이 아니라

저장소가 올바른 Markdown 파일을 포함하고 있어도 여전히 잘못된 컨텍스트를 로드할 수 있습니다.

팀은 주기적으로 다음을 확인해야 합니다:

• 에이전트가 실제로 로드한 메모리 파일은 무엇인지;
• 현재 작업 디렉토리에 적용되는 중첩된 지시사항은 무엇인지;
• 가져온 콘텐츠가 최신인지 여부;
• 충돌하는 규칙이 존재하는지 여부;
• 로컬 구성이 공유 정책을 의도하지 않게 재정의하는지 여부.

5. 벤더별 지시사항은 간결하게 유지하세요

CLAUDE.md가 두 번째 완전한 프로젝트 핸드북이 된다면, 구성 드리프트는 거의 불가피해집니다.

좋은 목표는 다음과 같습니다:

AGENTS.md = 프로젝트 진실
CLAUDE.md = Claude 전용 델타(차이점)

일반적인 함정

전체 지시사항 세트 복제하기

동일한 500줄 정책을 여러 벤더 파일에 복사하는 것은 처음에는 안전해 보입니다.

이는 일반적으로 가장 위험한 접근 방식입니다. 복사본들은 침묵 속에서 달라지기 때문입니다.

일회성 가져오기를 동기화로 취급하기

마이그레이션 도구는 채택을 도와줍니다. 하지만 이러한 도구가 미래의 변경사항이 자동으로 동기화 상태를 유지하도록 보장하지는 않습니다.

팀은 다음을 구분해야 합니다:

• 구성 복사하기;
• 구성 참조하기;
• 구성 네이티브하게 발견하기.

중첩 디렉토리 의미론 무시하기

가장 큰 실패는 종종 저장소 루트 아래에서 발생합니다.

루트 수준의 어댑터는 올바르게 보일 수 있지만, 패키지 수준의 지시사항은 한 에이전트에게는 보이지 않을 수 있습니다.

이식 가능한 정책과 모델 프롬프트 튜닝 혼합하기

데이터베이스 호환성 요구사항과 같은 규칙은 공유 프로젝트 정책에 속합니다.

특정 모델이 대규모 리팩터링을 어떻게 계획해야 하는지와 같은 지시사항은 벤더별 구성에 속합니다.

이러한 관심사를 분리하면 마이그레이션이 훨씬 쉬워집니다.

모든 스킬 디렉토리가 동등하다고 가정하기

스킬 형식은 클라이언트 간 발견 경로가 다를 때에도 이식 가능할 수 있습니다.

팀은 각 클라이언트가 프로젝트 수준과 사용자 수준 스킬을 모두 어떻게 찾는지 테스트해야 합니다.

다음은 어떻게 될까요?

가장 가능성 높은 결과는 CLAUDE.md의 사라짐이 아닙니다.

더 가능성 높은 결과는 상호운용성의 증가입니다.

Claude Code는 이미 다른 코딩 도구로 생성된 구성에 대해 더 강력한 초기화 및 가져오기 경로를 추가했습니다. Anthropic은 또한 AGENTS.MD의 더 쉬운 사용이 Claude Code를 더욱 사용자 정의 가능하게 만드는 작업의 일부임을 공개적으로 언급했습니다.

주목해야 할 다음 의미 있는 이정표는 다음과 같습니다:

• 어댑터 없이 네이티브 AGENTS.md 발견;
• AGENTS.md와 CLAUDE.md 사이의 문서화된 우선순위 규칙;
• 네이티브 또는 공식적으로 표준화된 .agents/skills/ 발견;
• 중첩된 지시사항 파일에 대한 더 명확한 동작;
• 모델별 최적화를 보존하는 호환성 레이어; -J 기업이 각 도구가 실제로 로드한 지시사항을 확인할 수 있게 하는 교차 에이전트 테스트.

이러한 세부 사항들이 상호운용성이 개별 개발자에게만 편리한지, 아니면 대기업에 충분히 믿을 만한지 결정할 것입니다.

이 논쟁이 Claude Code보다 큰 이유

코딩 에이전트 경쟁은 단순한 모델 품질을 넘어서고 있습니다.

기업들은 점점 더 인프라스트럭처에 관한 답을 필요로 합니다:

• 리포지토리가 지식 레이어를 다시 작성하지 않고 코딩 에이전트를 변경할 수 있는가?
• 기술이 클라이언트 간에 이동할 수 있는가?
• 에이전트들이 동일한 아키텍처 제약 조건을 공유할 수 있는가?
• 조직이 자동화된 코드 변경에 영향을 준 지침을 감사할 수 있는가?
• 기본 모델이 변경될 때 에이전트 구성이 유효하게 유지될 수 있는가?
• 모노레포가 하나의 권위 있는 AI 판독 가능 정책 집합을 유지할 수 있는가?

이러한 질문들은 AI 코딩이 개인 생산성 도구의 모음으로 남을지, 아니면 지속 가능한 엔지니어링 인프라가 될지를 결정합니다.

Shopify 사건이 중요한 이유는 바로 Shopify가 이미 그 전환의 두 번째 측면에서 운영 중이기 때문입니다.

결론

Tobi Lütke의 Claude Code 비판은 AGENTS.md가 단순한 텍스트 파일로 보일 때만 사소해 보입니다.

기업 규모에서는 그것은 훨씬 더 큰 것을 의미합니다: 기계 판독 가능 엔지니어링 지식의 소유권과 이식성.

Claude Code의 CLAUDE.md는 Claude 특화 최적화에 여전히 유용합니다. AGENTS.md는 벤더 중립적 리포지토리 진실을 위해 유용합니다. 가장 견고한 미래는 아마 양쪽을 모두 지원하는 것이며, 팀이 구성을 중복하도록 강제하기보다 명확한 우선순위와 기본 상호운용성을 갖출 것입니다.

오늘날 여러 AI 코딩 에이전트를 사용하는 엔지니어링 팀에게 실용적인 규칙은 간단합니다: 공유 프로젝트 지식을 표준으로 유지하고, 벤더 특화 레이어를 얇게 유지하며, 에이전트가 실제로 로드하는 컨텍스트를 검증하세요.

AI 코딩의 다음 단계에서 승자들은 가장 독점적인 구성을 가진 도구가 아닐 수 있습니다. 가장 깔끔하게 개방적이고 이식 가능한 에이전트 스택에 맞는 도구들이 승자가 될 수 있습니다.