
Kimi K3.1 Pro 평가: 코딩, 3D 모델링과 조사 능력
공개 벤치마크와 작업 사례로 살펴보는 Kimi K3.1 Pro의 코드 수정, Blender·CAD, 데이터 분석과 최종 답변 지연.
목차
Kimi K3.1 Pro의 공개 테스트에서는 코드 수정과 데이터 조사에 성공한 사례와 함께, 브라우저 검증의 빈틈과 데이터 그룹 분류 오류도 확인됩니다. Moonshot AI의 공식 3D 사례는 여기에 또 다른 측면을 더합니다. 모델이 Blender와 CAD 도구를 사용해 구조를 갖춘 장면과 객체를 만들 수 있다는 점입니다.
실무에서 중요한 질문은 결과물이 얼마나 잘 작동하는지, 무엇을 확인해야 하는지, 최종 답변까지 얼마나 걸리는지입니다. Artificial Analysis, Atomic Agent, PacBench, Plotly의 구체적인 결과를 Moonshot AI의 공식 사례와 함께 살펴봅니다.
Kimi K3.1 Pro 평가: 코딩, 에이전트, 추론
Artificial Analysis가 2026년 10월 23일 공개한 출시 평가에는 터미널 작업, SaaS 워크플로, 지식 업무, 고난도 추론 문제가 포함됩니다.
| 평가 | K3.1 Pro 결과 | 주요 평가 대상 |
|---|---|---|
| Terminal-Bench 4.0 | 67% | 터미널 환경의 코딩과 운영 작업 |
| AutomationBench-AA | 73% | 에이전트의 SaaS 워크플로 실행 |
| GDPval-AA | 1,846 Elo | 지식 업무 결과물의 상대적 성능 |
| Humanity’s Last Exam | 52% | 고난도 지식 및 추론 문제 |
네 평가는 서로 다른 업무를 다룹니다. 터미널과 SaaS 작업은 에이전트가 환경 안에서 행동하도록 요구하고, 지식 업무 평가는 만들어 낸 결과물을 봅니다. 어려운 질문은 복잡한 추론을 거쳐 정답에 도달하는 능력을 더합니다. 한 범주의 좋은 성적과 워크플로의 다른 부분에 있는 약점은 함께 존재할 수 있습니다.
개발자에게 이 구분은 코딩 벤치마크와 생성된 애플리케이션이 다르게 보이는 이유를 설명합니다. 저장소의 과제를 해결하려면 파일을 읽고, 수정하고, 검사를 실행하고, 실패를 해석해야 합니다. 대화형 애플리케이션을 전달하려면 조작, 렌더링, 실행 후 사용자가 겪는 동작까지 확인해야 합니다. 다음 사례에서 이런 차이가 드러납니다.
코딩: 코드 수정과 장시간 작업
Python 수정 과제에서 비교한 low와 max
Atomic Agent는 의도적으로 다섯 개의 버그와 두 개의 미구현 기능을 넣은 Python 패키지를 테스트했습니다. 빠진 기능은 정산 함수와 명령줄 도구였습니다. 에이전트에는 과제 파일을 읽고, 작업을 마치고, 테스트가 통과할 때까지 실행하라는 짧은 지시가 주어졌습니다. 모든 실행은 같은 과제와 도구를 사용한 Atomic Agent v0.6.9 환경에서 진행됐습니다.
추론 설정마다 세 번 실행했고, 실행마다 비공개 검증문 32개로 결과를 확인했습니다. 이는 작업 중 에이전트가 볼 수 있는 테스트와 분리된 검사입니다. 두 설정 모두 모든 검증을 통과했습니다.
| 설정 | 세 번의 실행에서 통과한 검증 | 평균 시간 | 평균 모델 호출 수 |
|---|---|---|---|
| Low | 96/96 | 2.2분 | 19회 |
| Max | 96/96 | 4.9분 | 28회 |
이 과제에서는 low가 더 효율적이었습니다. 보고된 평균으로 계산하면 max는 약 2.2배의 시간과 약 47% 더 많은 모델 호출을 사용했으며, 통과 결과는 같았습니다.
코드 수정에서는 완성된 패치가 유용한 비교 기준입니다. 요청한 동작을 고쳤는지, 공개 인터페이스를 유지했는지, 관련 없는 변경을 피했는지를 봐야 합니다. 높은 추론 단계는 이런 결과를 개선할 때 가치가 있습니다. 설명이 길거나 도구 호출이 많다는 것은 실행 특성이며, 그 자체로 더 나은 패치를 뜻하지는 않습니다.
긴 작업 중 진단 방향을 바꾸기
시뮬레이터는 골격 구성 요소 296개와 근육 구성 요소 402개를 포함한 human-atlas 해부 모델을 바탕으로 만들어졌습니다. Moonshot은 모델이 개방 루프 동역학 시험으로 팔 움직임 문제를 조사한 다음 계산을 수정하고 제어기를 다시 학습했다고 설명합니다.
서로 연결된 시스템에서는 이 순서가 중요합니다. 잘못된 시뮬레이션을 상대로 제어기를 학습할 수 있고, 애플리케이션 코드를 고장 난 의존성이나 잘못된 테스트 준비 데이터에 맞춰 조정할 수도 있습니다. 바깥쪽 루프를 계속 개선해도 근본 결함은 남을 수 있습니다. 이 사례에서는 학습 목표에서 학습 환경을 정의하는 시뮬레이터로 조사 대상이 바뀌었습니다.
따라서 긴 코딩 작업의 진전에는 의존성 읽기, 수치 가정 확인, 새로운 결과에 따라 초기 설명 수정하기 같은 진단 전환도 포함됩니다. 결과물에는 변경 파일, 테스트 명령, 측정 결과 등 충분한 흔적을 남겨 다른 개발자가 작업을 이어 갈 수 있어야 합니다.
생성된 게임과 남아 있는 검증의 빈틈

PacBench의 K3.1 Pro 항목은 high를 사용했고, 모델 응답 17회에 약 11.5분이 걸렸습니다. 생성된 Pac-Man 게임은 실행 기록과 함께 공개되어 직접 플레이할 수 있습니다.
평가자는 잘된 부분도 기록했습니다. 전통적인 28×31 미로, 244개 점 모두에 도달 가능한 구조, 테스트한 프레임 속도에서 이동이 막히지 않는 동작입니다. 이 정보가 있어 남은 결함을 단순히 ‘작동한다’ 또는 ‘작동하지 않는다’보다 구체적으로 이해할 수 있습니다.
남은 일은 브라우저 검증이었습니다. Node 대체 환경은 게임 상태 전환을 실행할 수 있어도 키보드 포커스와 백그라운드 탭 오디오는 브라우저 동작입니다. 대화형 결과물에서는 승리 조건을 확인하는 일과 실제 플레이 경험을 확인하는 일이 별개의 완료 항목입니다.
3D 모델링: Blender, CAD와 결과물 검토
CAD 벤치마크가 재구성하는 것
지표는 Voxel IoU로, 생성 형상과 기준 형상이 복셀 공간에서 얼마나 겹치는지 측정합니다. 형상 유사도를 나타내며 제작에 바로 쓸 수 있는 자산의 비율은 아닙니다. 그럴듯한 이미지를 만드는 일보다는 객체 구조를 복원하는 일에 가깝습니다.
보이는 형상에서 편집 가능한 자산으로
개별 자산은 세 가지 측면에서 살펴볼 수 있습니다.
| 관찰 측면 | 확인할 내용 |
|---|---|
| 전체 형상 | 윤곽, 비율, 공간 배치 |
| 세부 구조 | 연결, 가림, 대칭, 세부 요소 |
| 실제 활용 | 원본 파일, 치수, 토폴로지, 내보내기 결과 |
자산 검토 항목: 이 글에서 정리했습니다.
기계 객체라면 연결 부품이 제자리에서 맞닿는지, 치수를 바꿔도 관계가 유지되는지를 확인하면 좋습니다. 건축 장면에서는 반복 구성 요소, 개구부, 공간 배치를 살펴봅니다. 이런 검사는 한 시점에서 가려질 수 있는 교차나 누락된 연결을 드러내는 데 도움이 됩니다.
전달 형식도 중요합니다. 미리보기는 외관 검토를, 편집 파일은 후속 수정을, 내보내기 파일은 다른 도구에서의 활용을 지원합니다. 작업을 시작할 때 원하는 형식을 정하면 보기 좋은 전시물과 다른 사람이 실제로 이어서 작업할 수 있는 자산을 구분하기 쉽습니다.
데이터 분석: Plotly의 42/43과 그룹 분류 오류
모델은 42개를 통과했으며, 숨은 패턴 질문 다섯 개와 데이터 품질 질문 세 개를 모두 맞혔습니다.
질문에서 직접 언급하지 않은 문제 찾기
데이터 품질 사례에서 K3.1 Pro는 중복 행과 월말 마지막 날의 누락을 찾았고, 퇴역해서 데이터가 없는 터빈과 실제 발전량이 0인 터빈을 구분했다고 Plotly는 보고했습니다. 단순 집계에서는 비슷해 보여도 서로 다른 데이터 상태입니다.
숨은 패턴 질문에는 정확히 무엇을 찾아야 하는지 지시받지 않은 상태에서 관계를 조사하는 작업도 필요합니다. 앞선 쿼리에서 발견한 내용에 따라 다음 쿼리를 정하는 탐색적 분석과 관련 있는 결과입니다.
작은 그룹 분류 오류가 답을 바꾸는 방식
이렇게 하면 비교 모집단이 바뀝니다. 아예 펌웨어가 없는 기록이 섞여 있다면 ‘이 펌웨어를 쓰지 않음’과 ‘다른 펌웨어를 사용함’은 다른 그룹입니다. 설치 전 상태의 기록을 추가하는 순간 통계 검정을 적용하기도 전에 비교 기준이 달라집니다.
따라서 분석 방법이 꼼꼼해 보여도 이미 다른 질문에 답하고 있을 수 있습니다. 검토는 모집단부터 시작하는 것이 좋습니다. 어떤 기록이 각 그룹에 들어갔는지, 무엇이 제외됐는지, 이 데이터에서 결측값은 무엇을 뜻하는지 봅니다. 그런 다음 계산과 설명문이 실제 필터에 부합하는지 확인합니다. 그룹이 업무 정의와 일치해야 계산도 의도한 질문에 답합니다.
금융 모델과 조사 결과물

NVDA 화면에는 분기별·연도별 열과 매출, 이익, 이익률, 희석 주당순이익이 함께 보입니다. 재무 요약 페이지의 유용성은 주요 수치를 그 뒤의 가정과 보조 시트까지 얼마나 쉽게 연결할 수 있는지에 달려 있습니다.
모델링 워크북에서는 예측 하나를 골라 가정에서 수식 참조를 거쳐 요약까지 따라가 봅니다. 회계 기간이 맞는지, 가정을 바꾸면 의도한 출력이 갱신되는지 확인합니다. 보고서나 발표 자료에서는 중요한 주장을 출처까지 추적하고, 차트와 문장 결론이 같은 기간과 정의를 쓰는지 봅니다.
이 파일들은 조사 결과 전달이 긴 답변 생성보다 넓은 작업이라는 점도 보여 줍니다. 워크북에는 수치 의존 관계가 있고, 슬라이드에는 명확한 논증 순서가 필요하며, 보고서의 결론에는 추적 가능한 근거가 있어야 합니다. 다른 사람이 검토하고 수정할 수 있는 형식으로 이런 관계를 정리하는 것도 모델의 역할입니다.
이미지·동영상 이해: 실무 확인 항목
- 차트에서는 수치, 단위, 통계 정의를 함께 확인합니다.
- 공간 과제에서는 객체의 위치와 관계를 확인합니다.
- 동영상에서는 프레임 사이의 동작 순서와 상태 변화를 테스트합니다.
차트 과제는 읽기와 해석의 차이를 보여 줍니다. 한 계열의 단위, 기간, 모집단이 다르다면 수치 두 개를 추출하는 것은 시작일 뿐입니다. 유용한 답변은 값을 올바른 축, 범례, 주변 설명에 연결해야 합니다.
content를 메시지 부분의 배열로 받고, 이미지는 base64나 업로드한 파일 참조로 전달합니다. 가이드는 동영상 처리를 키프레임 기준으로 설명하며, 프레임 수와 해상도가 입력 크기에 영향을 줍니다. 자세한 내용은 시각 입력 가이드에 있습니다.동영상은 고장 전에 무엇이 달라졌는지, 어떤 동작이 먼저였는지처럼 단일 프레임보다 순서가 답을 결정하는 사례를 고르는 것이 좋습니다. 여기서 다룬 공개 테스트는 코딩과 데이터 작업에 집중되어 있습니다. 시각 애플리케이션에는 실제로 인식해야 할 사건과 세부 사항에 맞는 자체 사례가 필요합니다.
추론 지연: 최종 답변까지 기다리는 시간
2026년 10월 24일 AIHubMix는 해시맵 설명과 Python 코드를 요청하는 프롬프트 하나로 표준 Pro를 low에서 세 번 실행했습니다. 첫 추론 토큰과 첫 최종 답변 토큰까지의 대기 시간은 크게 달랐습니다.
첫 추론 토큰과 첫 최종 답변 토큰까지의 대기 시간
표준 Pro · 프롬프트 하나 · low · 세 번 실행
- 첫 추론 토큰
- 3.6–4.5 초
- 첫 최종 답변 토큰
- 71–91 초
요청 시작 후 경과 시간(초)
이 실행들에서는 완료 토큰의 약 85%–90%가 추론이었으며, 한 번은 완료 토큰 상한인 8,192개에 도달했습니다. 따라서 최종 답변만 표시하는 화면은 모델이 이미 추론을 스트리밍하고 있어도 멈춘 것처럼 보일 수 있습니다.
스트림 진행과 사용할 수 있는 답변
경험을 설명하는 시간은 세 가지입니다. 스트림이 시작되는 시점, 최종 답변 본문이 시작되는 시점, 응답이 완료되는 시점입니다. 연결이 정상이어도 사용자는 쓸 수 있는 답을 기다릴 수 있습니다. 첫 토큰 시간이 짧다는 사실만으로 전체 대기 시간을 설명할 수는 없습니다.
대화형 애플리케이션에서는 실제 사용자의 프롬프트로 세 시점을 모두 측정해야 합니다. 추론 단계와 완료 제한도 기록해 빠르지만 잘린 응답과 완성된 답변을 구분합니다. 백그라운드 작업에서는 첫 글자가 나타나는 속도보다 최종 품질과 총 소요 시간이 더 중요할 수 있습니다.
reasoning_content, 최종 답변 증분에 content를 사용합니다. 애플리케이션은 처리 상태와 표시하거나 파싱할 답변을 구분할 수 있습니다. 여러 턴의 도구 워크플로에서는 빠른 시작이 최종 답변만 남기지 말고 전체 assistant 메시지와 대응하는 도구 결과를 보존하도록 요구합니다.이렇게 시간 측정은 에이전트의 행동과 연결됩니다. 애플리케이션은 도구 요청, 반환된 관찰, 최종 답변을 포함하는 진행 중인 작업을 관리합니다. 추론 단계는 그 과정의 조절 항목 하나이며, 검증과 메시지 처리도 결과를 올바르게 전달하는 데 영향을 줍니다.
Kimi K3.1 Pro가 적합한 작업
사례마다 우선해서 볼 항목이 다릅니다.
| 능력 | 공개 근거가 뒷받침하는 내용 | 남아 있는 한계 |
|---|---|---|
| 코딩과 장시간 작업 | 코드 수정 완료와 지속적인 디버깅 | 큰 프로젝트의 신뢰성은 목표 환경에서 검증해야 함 |
| 3D와 공간 추론 | 도구를 활용한 장면과 객체 구성 | 형상 겹침만으로 토폴로지나 내보내기 품질을 판단할 수 없음 |
| 데이터 분석과 조사 | Plotly 전문 테스트의 좋은 성적 | 그룹 분류 규칙과 가정은 여전히 틀릴 수 있음 |
| 시각 이해 | 공식 이미지·동영상 입력 지원 | 이 테스트로 전문 시각 과제의 정확도를 판단할 수 없음 |
| 추론과 실행 | 상당한 추론과 도구 사용 | 추가 노력이 지연을 늘려도 측정 결과를 개선하지 못할 수 있음 |
앞에서 살펴본 출처를 정리한 표입니다.
먼저 평가할 수 있는 코드 수정이나 데이터 분석 작업으로 시작합니다. 수정 과제는 원래 실패 사례를 보관하고 최종 diff를 봅니다. 분석은 정답이 알려진 사례를 준비하고 결측이나 예외 상태를 포함합니다. 3D 결과물은 미리보기를 보기 전에 원본과 내보내기 형식을 합의합니다.
최종 품질, 실행 시간, 도구 호출, 토큰 사용량을 비교한 다음 구조가 덜 정해진 작업으로 넓혀 갑니다. Atomic의 low/max 비교, PacBench의 브라우저 검증 빈틈, Plotly의 분류 오류는 각각 구체적인 검사 항목으로 바꿀 수 있습니다. 이를 통해 평가를 모델이 실제로 수행할 일과 연결할 수 있습니다.
자주 묻는 질문
Kimi K3.1 Pro로 편집 가능한 3D 모델을 만들 수 있나요?
코딩에는 low와 max 중 무엇을 써야 하나요?
대표적인 작업 집합으로 먼저 비교하세요. Atomic Agent의 Python 실험에서는 같은 검증을 통과했고, low는 평균 2.2분·19회 호출, max는 4.9분·28회 호출을 사용했습니다. 더 높은 단계가 패치 품질이나 통과율을 개선해 추가 시간과 사용량을 정당화할 때 높이는 것이 좋습니다.
Kimi K3.1 Pro가 스트리밍 중인데 최종 답변이 없는 이유는 무엇인가요?
Plotly에서 42/43을 통과했다면 조사 결론을 바로 써도 되나요?
Plotly의 합성 풍력발전 데이터에서 얻은 좋은 결과입니다. 틀린 펌웨어 문제는 모집단과 그룹 분류 규칙을 여전히 검토해야 하는 이유를 보여 줍니다. 다른 데이터에서는 결측값, 기간, 수식, 출처를 확인한 뒤 결론을 사용해야 합니다.


