Moonshot, Kimi를 Codex와 Claude Code에 개방하며 Anthropic-Moonshot 갈등 재구성
Moonshot AI는 모델 학습과 접근 권한을 둘러싼 Anthropic-Moonshot 분쟁이 해결되지 않은 가운데, 9월 2일 Kimi를 두 경쟁 코딩 환경에 개방했다. 이제 Kimi API는 Codex의 OpenAI Responses API 요청과 Claude Code의 Anthropic Messages API 요청을 모두 수용한다. Moonshot은 개발자가 포맷 변환기나 로컬 프록시 없이 연결할 수 있다고 밝혔다.
이 변화는 호환성 업데이트처럼 들린다. 그러나 코딩 에이전트는 일반적인 텍스트 완성 기능뿐 아니라 세부적인 프로토콜 동작에 의존하기 때문에 그 영향은 더 크다. 클라이언트는 도구 정의를 전송하고, 구조화된 호출을 수신한 뒤, 실행 결과를 반환하며, 작업이 끝날 때까지 이 주기를 반복한다.
따라서 Moonshot은 코딩 인터페이스를 그것을 만든 회사와 분리하려 하고 있다. 개발자는 Codex를 계속 클라이언트로 사용하면서 OpenAI 모델 대신 Kimi 모델을 쓸 수 있다. Claude Code 역시 익숙한 워크플로를 유지한 채 요청을 Anthropic이 아닌 Moonshot으로 보낼 수 있다.
이 전략은 OpenAI와 Anthropic에 다른 종류의 압박을 가한다. 어느 회사도 자사 클라이언트나 프로토콜의 소유권을 잃는 것은 아니다. 하지만 두 회사 모두 자신들이 정립하는 데 기여한 워크플로 내부에서, 호환성을 무기로 경쟁하는 또 다른 제공업체와 맞서게 됐다.
Kimi API의 Codex 지원, 실질적인 장벽 제거
Moonshot의 핵심 변화는 새로운 코딩 인터페이스가 아니라 네이티브 프로토콜 지원이다.
Moonshot의 9월 2일 발표에 따르면, Kimi는 Codex가 사용하는 Responses API 형식을 지원한다. 또한 Anthropic 및 Claude Code와 연관된 Messages API도 지원한다. 회사는 각각의 경로를 위한 별도 구성 가이드를 공개했다.
Codex용으로 Moonshot은 자사 API 기본 URL과 Responses 와이어 형식을 사용하는 커스텀 제공업체를 안내한다. 커스텀 제공업체는 클라이언트에 모델 요청을 보낼 위치와 사용할 프로토콜을 알려준다. 그러면 개발자는 Codex 안에서 계속 작업하면서 Kimi 모델을 선택할 수 있다.
Moonshot은 kimi-k3, kimi-k2.7-code-highspeed, kimi-k2.7-code, kimi-k2.6를 호환 가능한 선택지로 제시한다. 다만 실제 사용 가능 여부는 계정, 엔드포인트, 클라이언트 버전, 현재 플랫폼 구성에 따라 달라질 수 있다.
Codex 구성이 주목할 만한 이유는 기존 통합에서 흔히 필요했던 변환 계층을 없애기 때문이다. 로컬 어댑터는 한 요청 형식을 받아 다른 API용으로 다시 작성하고, 스트리밍 응답을 다시 변환해야 했다.
모든 어댑터는 또 하나의 변수가 된다. 도구 호출을 잘못 처리하거나, 이벤트 유형을 누락하거나, 자격 증명을 노출하거나, 업데이트 이후 클라이언트와의 호환성을 잃을 수 있다. 또한 장애가 클라이언트, 어댑터, 네트워크, 업스트림 모델 중 어디에서 발생했는지 알기 어려워 디버깅도 복잡해진다.
네이티브 Responses 지원은 이러한 통합 범위를 줄인다. 그렇다고 OpenAI가 호스팅하는 모델과 동일한 동작을 보장하는 것은 아니다. 이는 Moonshot 서버가 클라이언트가 기대하는 와이어 계약을 수용한다는 의미다.
이 차이는 Codex가 프롬프트를 보내고 답을 출력하는 것 이상의 역할을 하기 때문에 중요하다. OpenAI의 Codex 에이전트 루프 설명은 모델 추론과 도구 실행 사이의 반복적 교환을 다룬다. 클라이언트는 이러한 교환 전반에 걸쳐 메시지, 지침, 도구 정의, 추론 관련 항목, 도구 결과를 전달한다.
호환 서버는 루프가 지속될 수 있도록 그 구조를 충분히 보존해야 한다. 텍스트 생성만으로는 충분하지 않다. 스트리밍 이벤트, 도구 호출 식별자, 입력 항목, 종료 동작은 모두 클라이언트의 안정적 작동 여부에 영향을 준다.
따라서 Kimi API의 Codex 경로는 Codex 인터페이스를 선호하면서 다른 모델 백엔드를 원하는 개발자를 겨냥한다. 또한 팀이 터미널 워크플로를 바꾸거나 주변 스크립트를 재구축하지 않고도 모델을 비교할 수 있는 방법을 제공한다.
커스텀 제공업체를 사용할 수 있다면 같은 논리는 데스크톱 환경에도 적용된다. Moonshot 문서에 따르면 구성된 백엔드가 Kimi더라도 모델 선택기에는 일반적인 커스텀 라벨이 표시될 수 있다. 이러한 인터페이스 제약 때문에 검증이 중요해질 수 있다.
개발자는 구성, 요청 로그, 통제된 테스트를 통해 활성 제공업체를 확인해야 한다. 응답이 성공적으로 돌아왔다고 해서 어떤 백엔드가 요청을 처리했는지가 자동으로 입증되지는 않는다.
Moonshot은 또한 자사의 Responses 구현이 텍스트와 이미지 입력은 수용하지만 현재 비디오 입력은 지원하지 않는다고 밝혔다. 이 제약은 네이티브 지원의 의미를 제한한다. 프로토콜 호환성은 모든 가능한 입력이나 플랫폼 기능을 포괄하지 않더라도 코딩 작업에는 충분히 넓을 수 있다.
그럼에도 즉각적인 이점은 분명하다. 개발자는 문서화된 경로를 위해 더 이상 로컬 프로토콜 브리지를 유지할 필요가 없다. 이는 설정 작업을 줄이고 Moonshot에 기존 에이전트 워크플로로 진입하는 더 직접적인 경로를 제공한다.
Kimi의 Claude Code 지원, 클라이언트를 배포 채널로 전환
Claude Code의 구성 가능한 API 경로는 Moonshot이 동등하게 익숙한 클라이언트를 구축하지 않고도 추론 수요를 두고 경쟁할 수 있게 한다.
Kimi의 Claude Code 설정은 Moonshot의 Anthropic 호환 엔드포인트를 사용한다. Claude Code는 Messages API 요청을 보내고, 선택된 Kimi 모델이 추론을 수행한다. 클라이언트는 파일, 도구, 권한, 대화형 워크플로를 계속 관리한다.
Moonshot의 Claude Code 가이드는 필요한 엔드포인트와 자격 증명을 설명한다. 이는 요청 형식 변환만을 위해 로컬 릴레이를 설치해야 했던 기존 방식을 대체한다.
Anthropic의 Messages API는 대화, 콘텐츠 블록, 도구 사용을 위한 구조화된 인터페이스다. 이 형태를 지원하면 해당 계약을 중심으로 설계된 소프트웨어에서 다른 제공업체가 요청을 받을 수 있다. 그렇다고 Kimi 모델이 Claude가 되거나 Anthropic의 모델 동작이 이전되는 것은 아니다.
이 구분은 분명히 유지돼야 한다. Claude Code는 에이전트 클라이언트다. Claude는 Anthropic의 모델 제품군이다. 사용자는 호환되는 외부 엔드포인트에 클라이언트를 연결할 수 있지만, 그 결과물은 구성된 제공업체에서 나온다.
Anthropic의 자체 게이트웨이 문서는 지원되는 API 형식이 Claude Code와 게이트웨이를 연결할 수 있음을 인정한다. 동시에 Anthropic은 서드파티 게이트웨이 제품을 보증, 유지보수, 감사하지 않는다고 명시한다. 더 나아가 Anthropic은 게이트웨이를 통해 Claude Code를 Claude가 아닌 모델로 라우팅하는 방식은 지원하지 않는다고 밝힌다.
Moonshot은 Anthropic이 Kimi를 지원한다고 주장하는 것이 아니다. 이는 클라이언트가 기대하는 요청 형식을 구현하는 것이다. 이 차이는 기술적 상호운용성과 상업적 파트너십을 구분한다.
이 구성은 개발자에게 실질적인 사용 사례를 제공한다. 팀은 하나의 코딩 클라이언트를 유지한 채 테스트 환경을 Kimi로 연결하고, 동일한 저장소 작업을 다른 백엔드에서 실행할 수 있다. 익숙한 제어 방식으로 패치 품질, 도구 신뢰성, 지연 시간, 장애 복구를 비교할 수 있다.
이 워크플로는 전환 비용도 낮춘다. 이전에는 다른 모델을 평가하려면 전용 클라이언트를 도입하거나 프록시를 유지해야 했을 수 있다. 네이티브 호환성은 이 결정을 구성 변경에 가까운 수준으로 옮긴다.
이는 모델 제공업체에 압박을 가한다. 사용자 충성도가 기반 모델보다 에이전트 셸에 붙을 수 있기 때문이다. 개발자는 하나의 인터페이스를 선호하면서도 코드 리뷰, 저장소 탐색, 이미지 보조 디버깅, 장시간 편집 작업에는 서로 다른 모델을 선택할 수 있다.
그 결과 프로토콜은 배포 채널이 된다. 클라이언트가 커스텀 엔드포인트를 수용하면, 충분히 호환되는 모든 제공업체가 해당 사용자에게 접근하려 할 수 있다. 원래 공급업체는 여전히 클라이언트의 발전을 통제하지만, 모든 추론 요청을 통제하지는 못한다.
제약도 있다. Claude Code는 시간이 지나며 기능을 추가하고, 외부 구현은 그 기능에 필요한 요청 및 응답 필드를 계속 따라가야 한다. Anthropic은 게이트웨이가 새로운 동작을 전달하지 못하면 기능이 중단될 수 있다고 경고한다.
직접 연결된 서드파티 엔드포인트도 동일한 호환성 부담을 안는다. Claude Code가 또 다른 도구 스키마, 헤더, 콘텐츠 블록, 스트리밍 이벤트를 도입한다면 Moonshot은 이를 정확히 구현해야 한다. “네이티브”는 현재의 통합 경로를 설명할 뿐, 영구적인 기능 동등성을 뜻하지는 않는다.
인증은 신뢰 경계도 바꾼다. Moonshot으로 전송된 요청은 Moonshot의 서비스, 데이터 처리, 보존 규칙, 지역별 가용성의 적용을 받는다. 화면에 Claude Code가 남아 있다는 이유만으로 Anthropic 계정 아래에서 처리되는 것은 아니다.
팀은 제공업체 선택을 인프라 결정으로 다뤄야 한다. 소스 코드, 프롬프트, 도구 출력, 저장소 컨텍스트는 구성된 엔드포인트를 통과할 수 있다. 보안 검토는 해당 자료를 수신하는 백엔드를 따라야 한다.
따라서 Kimi의 Claude Code 경로는 일반적인 플러그인보다 더 단순하면서도 더 큰 의미를 갖는다. Moonshot이 경쟁사와 동일시되는 워크플로에 진입하는 동시에, 그 아래에서 모델 서비스를 제공할 책임을 지게 하기 때문이다.
Anthropic-Moonshot 갈등의 핵심은 호환성이 아닌 통제권
기술적 개방성과 상업적 불신은 공존할 수 있다는 점이 핵심 긴장이다.
주요 키워드인 anthropic moonshot은 협력적 관계가 아니라 적대적 관계를 가리킨다. Moonshot의 Messages 호환성을 Anthropic과의 합의로 오해해서는 안 된다.
2026년 2월 23일, Anthropic은 Moonshot, DeepSeek, MiniMax가 이른바 산업 규모의 증류 캠페인을 벌였다고 공개적으로 비난했다. 증류는 한 모델이 다른 모델이 생성한 출력을 활용해 학습하는 방식이며, 접근 권한과 허가가 있을 때는 정당한 방법일 수 있다.
Anthropic은 세 회사가 약 24,000개의 사기 계정을 통해 합산 1,600만 건이 넘는 Claude 교환을 생성했다고 주장했다. 이 가운데 340만 건 이상을 Moonshot에 귀속시켰으며, 해당 활동이 코딩, 도구 사용, 추론, 데이터 분석, 컴퓨터 사용, 비전을 겨냥했다고 밝혔다.
이는 이 기사에서 검토한 자료 기준으로 독립적으로 입증된 사실이 아니라 Anthropic의 주장이다. Moonshot이 새로 발표한 API 호환성은 이를 확인하거나 해결하지 않는다. Anthropic의 메시지 형식을 지원한다는 사실만으로 Kimi의 학습 방식에 관한 어떤 추론도 내려서는 안 된다.
그럼에도 이 이력은 이번 출시를 읽는 방식을 바꾼다. Anthropic은 모델 출력과 접근 제한에 더 강력한 보호가 필요하다고 주장한다. 한편 Moonshot은 Anthropic과 연관된 인터페이스를 경쟁 모델과 함께 더 쉽게 쓰도록 만들고 있다.
따라서 Anthropic-Moonshot 갈등은 두 층위에서 작동한다. 하나는 누가 어떤 조건으로 모델 역량에 접근할 수 있는지에 관한 것이다. 다른 하나는 클라이언트 프로토콜이 널리 구현되는 인터페이스로 기능할 수 있는지에 관한 것이다.
Anthropic의 증류 관련 주장은 첫 번째 층위를 강조한다. Moonshot의 호환성 출시는 두 번째 층위를 강조한다. 양측은 모두 통제권을 두고 다투고 있지만, 기술 스택의 서로 다른 부분을 놓고 있다.
프로토콜 자체가 모델의 모든 동작을 담고 있는 것은 아니다. 이는 요청, 콘텐츠, 도구, 응답이 클라이언트와 서버 사이를 오가는 방식을 정의한다. 여러 제공업체가 유사한 인터페이스를 구현하면서도 서로 다른 결과를 낼 수 있다.
이러한 분리는 다른 컴퓨팅 시장에서도 익숙하다. 애플리케이션은 동일한 데이터베이스 엔진을 사용하지 않으면서도 공유 데이터베이스 프로토콜을 사용할 수 있다. 클라우드 서비스는 모든 운영 세부 사항이 같지 않아도 호환되는 객체 스토리지 인터페이스를 제공할 수 있다.
AI 에이전트는 모델의 동작이 클라이언트 루프에 영향을 미치기 때문에 이 분리를 더 어렵게 만든다. 코딩 에이전트는 모델이 도구를 선택하고, 결과를 해석하며, 유효한 수정을 만들고, 오류 이후 복구할 것으로 기대한다. 정식 API 호환성은 필요하지만, 경험의 유용성을 좌우하는 것은 행동 호환성이다.
개발자들이 Codex와 Claude Code를 중립적인 셸로 인식한다면 Moonshot에 이득이 된다. 사용자가 각 클라이언트를 해당 클라이언트에 맞춰 특별히 최적화된 모델과 연결한다면 OpenAI와 Anthropic에 이득이 된다. 경쟁의 핵심은 어느 관점이 우세해지느냐에 있다.
셸이 독립적이 되면 모델 라우팅은 더 쉬워진다. 기업은 제공업체 접근 권한을 협상하고, 지역별로 서로 다른 정책을 적용하거나, 특정 워크로드에 모델을 배정할 수 있다. 개발자는 추론 공급업체를 바꾸면서도 익숙한 작업 방식을 유지할 수 있다.
모델과 클라이언트의 긴밀한 튜닝이 승리한다면, 호환 가능한 경쟁 제품은 부차적 위치에 머물 수 있다. 도구 호출, 컨텍스트 관리, 캐싱, 추론 제어, 오류 복구의 미묘한 차이가 공유 엔드포인트의 편의성을 능가할 수 있다.
이것이 9월 2일의 변화가 단순한 API 체크박스 하나가 아닌 이유다. 이는 코딩 에이전트의 배포가 모델 소유권에서 분리될 수 있는지를 시험한다.
네이티브 형식이 네이티브 성능을 보장하지는 않는다
성공적으로 시작된 연결도 에이전트 실행의 까다로운 단계에서는 실패할 수 있다.
Moonshot의 발표는 문서화된 경로를 마련했다. 하지만 나열된 Kimi 모델 전반에서 모든 Codex 또는 Claude Code 기능이 동일하게 작동한다는 독립적인 증거를 제공하지는 않는다.
첫 번째 불확실성은 프로토콜 범위다. Responses와 Messages는 단일 텍스트 필드가 아니다. 여기에는 스트리밍, 멀티모달 콘텐츠, 도구 스키마, 도구 결과, 메타데이터, 사용량 보고, 오류 구조가 포함된다.
제공업체는 주요 요청을 수락하면서도 예외 상황을 다르게 처리할 수 있다. 병렬 도구 호출은 다른 순서로 도착할 수 있다. 스트림은 클라이언트가 기대하는 이벤트를 누락할 수 있다. 긴 명령 실행 중 취소 동작도 다를 수 있다.
두 번째 불확실성은 행동적 적합성이다. 코딩 클라이언트는 모델이 특수한 지침을 따르고 도구를 신중하게 사용할 것에 의존한다. 코딩 벤치마크에서 높은 점수를 받은 모델도 특정 클라이언트의 프롬프트나 리포지토리 워크플로에서는 어려움을 겪을 수 있다.
따라서 유용한 평가는 연결 성공 여부가 아니라 작업 완료를 측정해야 한다. 팀은 모델이 올바른 파일을 수정하는지, 프로젝트 지침을 준수하는지, 명령 출력 결과를 해석하는지, 승인이 필요할 때 중단하는지를 테스트해야 한다.
세 번째 불확실성은 클라이언트 변화다. OpenAI와 Anthropic은 새로운 기능이 등장함에 따라 클라이언트를 수정할 수 있다. 외부 제공업체는 그 시점을 통제하지 못한 채 이러한 변화를 따라가야 한다.
OpenAI의 Codex 설명은 에이전트 루프가 얼마나 세밀해졌는지 보여준다. 도구 호출 출력은 이후 요청에 추가되며, 대화 컨텍스트는 반복되는 턴에 걸쳐 확장된다. 이러한 객체의 변화는 엔드포인트가 /responses로 유지되더라도 호환성에 영향을 줄 수 있다.
Anthropic도 게이트웨이 운영자에게 비슷한 경고를 한다. 해당 문서는 게이트웨이가 새 Claude Code 기능을 전달하지 않으면 기능이 실패할 수 있다고 밝힌다. 형식을 직접 구현하는 제공업체도 유사한 유지보수 위험을 안게 된다.
네 번째 불확실성은 데이터 거버넌스다. 백엔드를 교체하면 코드와 컨텍스트가 이동하는 위치도 바뀐다. 조직은 OpenAI 또는 Anthropic 계정에 연결된 통제 수단이 Moonshot으로 전달되는 요청에도 그대로 적용된다고 가정할 수 없다.
보안 검토는 자격 증명 저장, 보존, 로깅, 지리적 처리, 사고 대응, 접근 제어를 다뤄야 한다. 또한 실제 프로덕션 작업을 보내기 전에 에이전트가 읽을 수 있는 리포지토리 파일이 무엇인지 파악해야 한다.
다섯 번째 불확실성은 관측 가능성이다. 일반적인 모델 라벨은 실제 활성 백엔드를 덜 명확하게 만들 수 있다. 조직은 각 요청을 제공업체, 모델 식별자, 개발자, 리포지토리, 정책과 연결하는 로그가 필요하다.
이 지점에서 내부 engineering knowledge base가 도움이 될 수 있다. 팀은 개인의 기억에 의존하지 않고 승인된 구성, 평가 결과, 알려진 비호환성, 롤백 절차를 기록할 수 있다.
이러한 우려가 이번 출시의 가치를 부정하는 것은 아니다. 이는 실제로 “네이티브 지원”이 무엇을 의미해야 하는지 정의한다. 이는 제공업체가 필수 번역 구성 요소를 제거했다는 뜻이지, 모든 클라이언트 기능이 영구적인 동등성을 달성했다는 뜻은 아니다.
책임 있는 시험은 대표적인 리포지토리와 제한된 권한으로 시작한다. 파일 검색, 여러 파일 수정, 테스트 실행, 명령 실패, 이미지 입력, 긴 도구 시퀀스가 포함된 작업을 수행해야 한다.
팀은 최종 패치와 그것을 만들어 낸 과정을 함께 비교해야 한다. 불필요한 파일 접근이나 반복적인 실패 명령을 거쳐 얻은 올바른 결과도 운영상 위험 신호다.
최선의 증거는 클라이언트 업데이트 전반에 걸친 지속적인 사용에서 나올 것이다. Moonshot은 도입을 더 쉽게 만들었다. 이제 첫 번째 프롬프트가 성공한 뒤에도 호환성이 신뢰할 만하게 유지된다는 것을 보여줘야 한다.
개발자가 9월 2일 이후 주목해야 할 사항
이번 출시가 모델 경쟁을 바꿀지, 아니면 편리한 통합 옵션에 머물지를 세 가지 신호가 결정할 것이다.
첫 번째 신호는 클라이언트 업데이트 전반에서의 기능 동등성이다. 개발자는 새로운 Codex 및 Claude Code 기능이 Moonshot의 엔드포인트를 통해 신속하게 작동하는지 지켜봐야 한다.
여기에는 새로운 콘텐츠 유형, 도구 정의, 스트리밍 이벤트, 추론 제어, 인증 동작이 포함된다. 신속한 지원은 Moonshot이 일급 제공업체로 운영될 수 있다는 주장을 강화할 것이다. 반복적인 장애는 이를 약화할 것이다.
공개 문서는 초기 지표를 제공할 것이다. 명확한 호환성 매트릭스, 버전 요구 사항, 알려진 제한 사항, 날짜가 표시된 업데이트는 포괄적인 지원 주장보다 더 중요하다.
두 번째 신호는 검증된 워크로드 성능이다. 독립적인 테스트는 고립된 코딩 질문 대신 완전한 리포지토리 작업을 살펴봐야 한다. 유용한 지표에는 성공적인 패치, 테스트 통과율, 불필요한 도구 호출, 지연 시간, 명령 오류 이후의 복구, 사람의 수정 시간이 포함된다.
관련 비교는 단순히 채팅 창에서 Kimi를 Claude 또는 OpenAI 모델과 비교하는 것이 아니다. 개발자가 사용하려는 정확한 클라이언트 루프 안에서의 Kimi를 비교하는 것이다.
서로 다른 모델은 서로 다른 워크로드에서 우위를 보일 수 있다. 빠른 모델은 리포지토리 검색과 일상적인 변환에 적합할 수 있다. 더 신중한 모델은 아키텍처 변경이나 어려운 디버깅에서 더 좋은 성능을 낼 수 있다. 네이티브 호환성은 이런 비교를 더 쉽게 하지만, 그 결과를 결정하지는 않는다.
세 번째 신호는 OpenAI와 Anthropic이 제공업체 이식성에 어떻게 대응하는지다. 이들은 모델-클라이언트 최적화를 심화하거나, 지원 제공업체 정책을 강화하거나, 엔터프라이즈 라우팅을 개선하거나, 공식 클라우드 선택지를 더 매력적으로 만들 수 있다.
Anthropic은 이미 문서화하는 게이트웨이와 지원하지 않는 비-Claude 모델 사이에 경계를 긋고 있다. 해결되지 않은 anthropic moonshot 분쟁은 그 경계가 더 엄격해지는지 지켜봐야 할 또 하나의 이유가 된다.
OpenAI는 Codex의 Responses 엔드포인트가 구성 가능하다고 명시적으로 설명했다. 이러한 아키텍처 선택은 이식성을 뒷받침하지만, 구현 세부 사항과 지원되는 구성은 바뀔 수 있다. Moonshot의 출시는 개발자가 이 유연성을 어디까지 활용할지 시험한다.
개별 개발자에게 즉각적인 조치는 간단하다. Kimi를 즉시 대체 가능한 정체성이 아니라 평가할 또 하나의 백엔드로 다뤄야 한다. 일회용 브랜치에서 시작하고, 활성 모델을 확인하며, 자격 증명을 제한하고, 모든 패치를 검토하라.
엔지니어링 리더에게 더 큰 질문은 의존성에 관한 것이다. 조직은 하나의 통합된 공급업체를 원하는가, 아니면 여러 제공업체 사이를 라우팅할 수 있는 클라이언트 계층을 원하는가? 호환성은 두 번째 접근 방식을 더 실용적으로 만들지만, 테스트와 거버넌스 작업도 고객에게 이전한다.
짧은 평가 기록을 personal knowledge base에 보관하라. 클라이언트 버전, 선택한 모델, 리포지토리 유형, 작업, 관찰된 실패, 최종 인적 검토를 기록하라. 업데이트 후 같은 테스트를 반복하면 호환성이 개선되고 있는지 알 수 있다.
Moonshot은 Kimi, Codex, Claude Code 사이의 눈에 보이는 장벽 하나를 제거했다. 다음 장벽은 반복된 에이전트 실행을 통해 쌓이는 신뢰다. 클라이언트가 바뀌고, 작업이 길어지며, anthropic moonshot 갈등이 접근 권한과 통제에 관한 의문을 계속 제기하는 상황에서도 네이티브 프로토콜 지원은 신뢰성을 유지할 수 있을까?
