실전 Kimi K3: 직접 사용 경험과 Claude Code 비교

저자의 실험은 어떻게 끝났나#

Kimi K3는 2026년 7월 16일 출시됐다. 매개변수는 2조 8천억 개이고, 컨텍스트 창은 100만 토큰이며, 가중치가 공개되어 있고, 블라인드 프런트엔드 비교에서 1위를 차지했다. 아키텍처, 벤치마크, 가격에 관한 세부 사항은 Kimi K3와 Claude Code의 전체 리뷰에 정리했으므로 여기서 반복하지 않겠다.

그 리뷰의 마지막에는 이렇게 썼다. 설정에 하루를 쓸 위험이 있지만, 둘째 주부터는 청구액이 줄어들 수 있다는 것이었다. 나는 내 작업으로 실험해 봤다.

처음 몇 시간은 정말 흥미롭다. 모델은 작업을 기꺼이 맡고, 일관성 있는 프런트엔드 결과물을 만들며, 큰 파일도 망설임 없이 다룬다. 그래서 채널에 꽤 놀랐다고 썼다. 문제는 여러 에이전트와 함께하는 긴 세션, 반복적인 수정 과정, 그리고 저녁 시간의 터미널 작업에서 드러났다.

결국 이전 설정으로 되돌렸다. 이 결정을 내리게 된 이유를 수치와 1차 출처 링크와 함께 살펴보자. 직접 모든 것을 확인할 수 있다.

벤치마크에서는 왜 Kimi K3가 Claude를 앞서는가?#

Kimi K3가 Claude Fable 5를 앞서는 벤치마크는 다음과 같다.

llm-stats가 벤치마크를 모았으며, 각 행은 Claude Fable 5와 비교한 결과다.

수치는 실제 결과다. 같은 자료에 포함된 35개 벤치마크 전체에서 Claude Fable 5가 22개, Kimi K3가 12개에서 이겼고, 한 번은 동점이었다.

Kimi K3가 뒤처지는 분야는 더 흥미롭다. 코딩 벤치마크의 격차는 4~5점으로 크지 않다. 하지만 지식과 추론에서는 밀린다. HLE에서는 Claude가 거의 10점 앞선다. 장시간 작업이 벽에 부딪히는 지점이 바로 여기다. 먼저 이해해야 하고, 그다음에야 작성할 수 있다.

Moonshot은 출시 게시물의 주요 섹션에서 이렇게 설명한다.

실제로 Kimi K3가 두 배 느리게 느껴지는 이유는?#

비교 자료는 Kimi K3와 Claude Opus 4.8을 비교하며, 완전한 속도 측정 결과가 있는 Claude 버전은 Opus 4.8이다.

Kimi K3는 더 빨리 응답을 시작하므로 짧은 대화에서는 주관적으로 더 빠르게 느껴진다. 업무에서는 다른 부분이 중요하다. 전체 응답이 얼마나 느리게 도착하는가다. 이 부분에서 거의 절반 수준으로 밀리고, 긴 응답에서는 차이가 몇 분까지 쌓인다.

Kimi Code는 초당 180~260토큰을 광고하는데, 내 측정치인 34.7과 비교하면 그럴듯해 보인다. 하지만 이는 이전 세대의 고속 빌드인 K2.7 Code HighSpeed의 수치다. Kimi K3에는 그런 빌드가 없으며, 독립 벤치마크는 Kimi K3 자체를 측정한다.

일곱 번째 오류에서 중단되고 반복 호출로 토큰을 소모하는 세션은 컨텍스트 엔지니어링의 실패다. 이 경우 모델 선택은 부차적이다. 전체 설정은 AI 복제본 + Second Brain + Context Engineering이라는 세 가지 축을 기반으로 한다. AI가 환각을 일으키지 않으려면 이 세 가지가 필요하다.

추론을 끌 수 없다면 토큰은 어디에 쓰이나?#

노력 수준을 낮출 수는 있다. 문서에는 낮음, 높음, 최대의 세 단계가 나와 있다. 그러나 추론을 완전히 끌 수는 없다. 문서에는 Kimi K3의 추론과 추론 기록 저장이 항상 활성화되어 있다고 명시되어 있다. API를 직접 호출하면 최대 수준이 기본값이며, 대부분의 래퍼 프로그램은 이를 바꾸지 않는다.

각 턴마다 토큰 100만 개당 $15의 출력 토큰이 수천 개씩 추가된다. 게다가 Moonshot은 추론 기록을 포함한 어시스턴트의 전체 메시지를 다시 보내도록 요구한다. 이렇게 보낸 출력 토큰은 다음 턴에서 다시 입력 토큰이 된다.

따라서 같은 추론에 두 번 비용을 지불한다. 모델이 추론을 생성할 때 한 번, 그 내용을 모델에 다시 보낼 때 한 번이다.

전체 지수 기준으로 Kimi K3는 이전 모델인 K2.6보다 출력 토큰을 21% 적게 사용한다. 자체 이전 버전보다 더 경제적이 된 것이다. 하지만 같은 작업에서 Claude는 여전히 토큰을 더 적게 사용한다.

“hi”라는 프롬프트는 86토큰으로 청구된다. 내부적으로 약 85토큰의 숨겨진 시스템 프롬프트가 포함되어 있으며, 요청할 때마다 그 비용을 지불한다.

사용량 계산 방법과 남은 잔액 확인 위치를 다룬 별도의 리뷰도 있다. Claude Pro와 Max에서 제공하는 토큰 수를 참고하자. 계산 방식은 같고 가격만 다르다.

모델이 추론에 갇히면 어떻게 되나?#

이런 식이다. 모델이 생각하기 시작하지만 생각을 발전시키는 대신 텍스트가 반복으로 빠져든다. 같은 단어를 되풀이하고, 이어서 음절 조각을 끝없이 반복한다. 토큰 카운터는 계속 돌아가지만 작업은 멈춘다.

7월 28일 Moonshot의 알려진 문제 목록에 올라온 보고에는 Kimi K3가 같은 파일을 연달아 여섯 번 읽으려 하고, “no-op 호출, 이전 읽기 이후 파일이 변경되지 않았음”이라는 거부 응답을 일곱 번 받은 뒤 아무 일도 없었던 것처럼 턴을 종료한 사례가 설명되어 있다. Kimi CLI 이슈 트래커에서 작성자는 읽기, 교체, 테스트, 분석 등 같은 종류의 멈춤 현상 네 가지를 나열하고 한 문장으로 요약한다.

Moonshot은 원인을 직접 밝힌다. 모델은 추론 기록을 보존하는 모드로 학습되었으며, 이전 추론 전체를 다시 받아야 한다. 기록이 불완전하게 전달되면 모델은 답을 재구성하려고 같은 도구 호출을 다시 생성하고 또 다른 루프를 시작한다.

서드파티 요청 라우터에서 작성된 분석의 저자도 같은 진단을 내린다. Kimi는 추론 기록이 불완전한 요청을 거부할 만큼 엄격하다. 외부 래퍼는 이런 엄격함을 모르고 기록을 잘라낸다.

Kimi K3에서 멀티 에이전트 설정이 무너지는 이유는?#

Moonshot 공식 문서는 이를 명확히 밝힌다. API는 아직 WebFetch를 지원하지 않는다. 즉, 보통 웹에 접속해 페이지를 가져오는 Claude Code가 Kimi K3에서는 그렇게 할 수 없다. 해결 방법은 콘텐츠를 직접 붙여 넣거나 서드파티 도구를 연결하는 것이다.

Claude Code는 필요할 때 도구를 불러올 수 있으며, 기록에 tool_reference 유형의 서비스 블록을 넣는다. Kimi는 이 유형을 허용하지 않고 400 오류를 반환한다. 필드 이름이나 이유는 알려 주지 않는다.

{"error":{"type":"invalid_request_error","message":"Invalid request Error"},"type":"error"}

비교를 위해 Anthropic의 기본 API에서 같은 오류가 어떻게 표시되는지 보자. 이 경우 서버는 적어도 필드 이름과 허용되는 유형 목록을 알려 준다.

messages.166.content.0.tool_result.content.0: Input tag 'tool_reference' found
using 'type' does not match any of the expected tags: 'document', 'image',
'search_result', 'text'

이 차이는 중요하다. 첫 번째 메시지만으로는 진단할 수 없다. 클라이언트도 사용자도 어떤 블록이 거부됐는지 알 수 없다. 보고서 작성자들이 바로 이 문제를 지적한다. 프로바이더 전환 도구 개발자들은 이미 Kimi에서 도구 지연 로딩을 기본적으로 끄거나, Moonshot API가 이런 블록을 허용하지 않는다고 표시하는 방안을 제안하고 있다.

그 결과는 7월 17일에 열렸지만 아직 답변이 없는 별도 보고서에 나와 있다. 작성자는 한 세션에서 이 오류를 일곱 번 겪었다. 세션은 처음 여섯 번은 버텼지만 일곱 번째 오류로 완전히 중단됐다. 그 뒤로는 단순한 텍스트 “continue”를 입력해도 충돌이 발생했다. 작성자는 컨텍스트 한도와는 거리가 멀었다고 별도로 언급했으므로, “기록이 너무 길었다”는 설명은 성립하지 않는다.

다음은 Moonshot API가 허용하거나 거부하는 블록 유형을 요약한 것이다.

여기서 “호환”은 요청 형식만을 가리킨다. 허용되는 블록 유형, 기록에 포함해야 하는 내용, 사용 가능한 도구 등 나머지는 모두 다르다.

Kimi K3에서는 무엇이 이어지지 않는가?#

출시 게시물의 제한 사항 섹션에는 다음과 같이 적혀 있다.

모델 개발자의 말은 이렇다. 우리 클라이언트를 사용하라. 다른 클라이언트가 어떻게 동작하는지는 보장하지 않는다는 것이다.

같은 섹션의 두 번째 항목은 모델의 고집으로 여겼던 또 다른 문제를 설명한다.

내 CLAUDE.md는 정반대의 습관을 따르도록 작성했다. 질문하고, 계획을 보여 주고, 확인을 기다리라는 것이다. 지침은 그대로지만 이제는 성향이 다른 모델이 이를 읽는다.

여러 에이전트가 하나의 규칙 파일을 공유하도록 하는 설정은 별도로 다뤘다. Claude Code, Codex, Cursor용 단일 지침 파일을 참고하자.

Kimi K3의 실제 비용은 얼마인가?#

먼저 Kimi K3에 유리한 가격을 살펴보자.

Kimi 가격은 컨텍스트 캐싱 문서에서 가져왔다. 오른쪽 열은 2026년 7월 30일 기준 Claude Opus 5 가격이다.

Kimi의 캐시는 자동으로 작동하고 비활성화할 수 없으며 요청 시작 부분의 해시를 기준으로 식별된다. 시스템 프롬프트나 도구 목록을 조금이라도 수정하면 메시지 캐시가 완전히 초기화된다.

Claude Code가 평범한 업무일에 하는 일은 다음과 같다.

1. 작업 진행에 따라 외부 도구를 연결하고 연결을 해제한다.
2. 필요할 때 도구를 불러온다.
3. 다른 도구 집합을 사용하는 하위 에이전트를 실행한다.
4. 지침 파일을 시스템 프롬프트에 추가한다.
5. 컨텍스트를 압축할 때 기록을 재구성한다.

목록의 각 항목은 요청의 시작 부분을 바꾸고, 따라서 캐시를 초기화한다. 입력 토큰 비용은 30센트가 아니라 다시 토큰 100만 개당 $3이 된다. 10배 더 비싸다. 여기에 출력 토큰 100만 개당 $15의 지속적인 추론 비용이 더해지고, 같은 토큰은 다음 턴에 입력으로 돌아온다. 이렇게 표시 가격이 낮은 모델도 예상치 못한 청구액을 만들 수 있다.

OpenCode의 집계 데이터에 따르면, 실제 세션 약 28만 건에서 Kimi K3 세션당 평균 비용은 $1.86이고 평균 사용량은 310만 토큰이다. 이 수치는 입력 토큰의 93%가 캐시에 적중한다는 조건에 기반한다. 요청의 시작 부분을 바꾸면 더는 이 수치가 적용되지 않는다.

Kimi 요금제는 $19, $39, $99, $199이다. 사용량은 전체 멤버십이 공유하는 풀에서 차감되고, 사용하지 않은 양은 이월되지 않은 채 매주 초기화되며, 5시간 이동 시간 창을 사용한다. 요금제 리뷰의 설명은 이렇다. 계속 추론하는 Kimi K3를 터미널 네 개에서 실행하면 5시간 할당량이 빠르게 소진된다.

$99 요금제의 코딩 할당량은 Anthropic의 $200 요금제에 필적해, 내가 주장해 온 입장과 어긋난다. Kimi는 토큰당 저렴하지만 저녁 청구서에서는 더는 그렇게 보이지 않는다.

Kimi K3가 객관적으로 잘하는 일은?#

1. 프런트엔드. 현업 개발자들의 블라인드 비교에서 1위다. 깔끔하고 감각 있는 레이아웃을 만든다.
2. 규모. 컨텍스트 창은 100만 토큰이며 긴 파일도 문제없다. 대규모 저장소를 분석하고 구조를 파악하는 작업에 적합하다.
3. 첫 응답. 첫 토큰까지 걸리는 시간은 Claude의 절반이다. 짧은 대화에서는 그 차이가 느껴지고 쾌적하다.
4. 토큰당 가격. Claude Opus 5 가격의 약 60%다. 요청의 시작 부분이 바뀌지 않는다면 규모가 크고 반복적인 작업에서 실질적인 비용 절감이 된다.
5. 공개 가중치. 하나의 프로바이더에 묶이지 않는다.

마지막 장점에는 단서가 있다. 이런 모델을 집에서 실행하는 것은 현실적이지 않다. 압축된 상태에서도 가중치 용량이 테라바이트에 이른다. 여기서 공개성이란 단일 프로바이더에 대한 의존에서 벗어날 수 있다는 뜻이다.

저녁 한 번으로 직접 확인하는 방법#

1. 안내에 따라 접근을 설정한다. 세 가지 환경 변수와 등급별 모델 교체 방법은 Kimi K3와 Claude Code 리뷰에 설명했다. /status 명령으로 설정을 확인하자. Kimi는 별칭 목록이 내장되어 있어 모델 선택 메뉴에 표시되지 않으며, 이를 수정할 필요는 없다.
2. 기존 키를 제거한다. 이전에 ANTHROPIC_API_KEY를 설정했다면 제거한다. ANTHROPIC_AUTH_TOKEN과 함께 설정되어 있으면 충돌이 생겨 이유 없이 인증 오류가 발생한다.
3. 도구 지연 로딩을 즉시 끈다. 첫 실행 전에 끄자. 첫 세션이 중단된 뒤에 하지 말자.
4. 작업 도중 모델을 바꾸지 않는다. Kimi K3로 시작했다면 Kimi K3로 끝내자. 반대의 경우도 마찬가지다. 위에서 인용한 Moonshot의 직접적인 요구 사항이다.
5. 자신의 실제 작업을 사용한다. 어제 작업한 것처럼 복잡하고 미완성된 부분이 남아 있는 작업이어야 한다. 스네이크 게임으로는 차이가 드러나지 않는다. 장기간 사용해야 나타난다.
6. 수치 두 가지를 기록한다. 걸린 시간(분)과 그날 저녁에 쓴 비용이다. 평소 Claude를 쓰는 저녁과 비교한다.
7. 유휴 시간을 따로 기록한다. 에이전트가 멈추거나, 같은 파일을 반복해서 읽거나, 오류를 반환하면 그것도 비용의 일부다.

저녁 청구액이 예상보다 높다면 거의 항상 캐시가 원인이다. 그날 저녁 요청의 시작 부분이 몇 번이나 초기화됐는지 세어 보자. 토큰당 가격은 거의 관계가 없다.

최종적으로 유지한 것#

채널에서 나와 함께 모델을 시험한 독자들도 독립적으로 같은 설정에 도달했다. Kimi K3로 저장소를 살펴보고 두 번째 의견을 얻는 동안, 주 작업은 익숙한 에이전트에 맡기는 방식이다. 기존 래퍼를 옮기거나 잘 작동하는 것을 망가뜨릴 필요가 없으므로 이 설정은 안정적이다.

이렇게 정리할 수 있다. 완결된 단일 작업은 Kimi K3에, 도구와 하위 에이전트가 얽힌 긴 작업 흐름은 Claude Code에 맡긴다. 작업에 필요한 도구 전환이 많을수록 Kimi K3의 비용은 커지고 세션이 망가질 가능성도 높아진다.

두 에이전트의 역할이 섞이지 않게 배정하는 방법은 별도의 리뷰에서 다뤘다. 두 에이전트와 함께 일하는 세 가지 방법을 참고하자.

벤치마크는 “실험실 조건에서 누가 더 강한가?”라는 질문에 답한다. 저녁 청구서와 완료한 작업 목록은 “나에게 누가 더 강한가?”라는 질문에 답한다. 두 답이 다르면 두 번째를 믿자. 마케팅 부서가 아니라 직접 계산한 결과다.

이 모든 내용을 살펴본 뒤 내린 결론은 이렇다. 새 모델에 대해 무슨 말을 하든, 선두 주자는 여전히 선두 주자다. Claude Code는 계속 내 주력 엔진이다.

완전한 바이브 코딩 설정: AI 복제본 + Second Brain + Context Engineering.