Kimi K3 Swarm Max: 단일 프롬프트로 300개의 리서치 에이전트를 실행하는 방법

Kimi K3이 2026년 7월 16일에 출시됐습니다. 2.8조 개의 파라미터, 100만 토큰 컨텍스트. 공개된 오픈 웨이트 모델 중 가장 큰 모델입니다.

가장 주목할 만한 기능은 K3 Swarm Max입니다. 최대 300개의 서브 에이전트가 병렬로 실행되며, 4,000단계에 걸쳐 협력하여 채팅 응답이 아닌 실제 파일을 생성합니다. 두 가지 변형이 동일한 두뇌를 공유합니다. K3 Max는 일상적인 작업을 처리합니다. K3 Swarm Max는 문제를 해결하기 위해 에이전트 집단을 투입합니다.

대부분의 사람들은 Kimi를 열고, 질문을 입력하고, 답변을 받고, 탭을 닫습니다. 이는 제품 기능의 약 10%에 불과합니다. 이 가이드는 나머지 90%를 다룹니다.

Swarm은 단순히 부착된 기능이 아닙니다. 오케스트레이터는 PARL(Parallel-Agent Reinforcement Learning)로 훈련된 학습된 정책입니다. 목표를 설명하면 Swarm이 작업을 분할하는 방법, 생성할 에이전트 수, 결과를 다시 결합하는 방법을 결정합니다. Swarm은 광범위하고 병렬화 가능한 작업에서 빛을 발합니다. 50개 이상의 소스에 대한 리서치, 일괄 분석, 경쟁사 모니터링, 데이터셋 구축 등이 이에 해당합니다. 3단계가 2단계에 의존하는 깊은 순차적 작업에는 어려움을 겪습니다.

• 프롬프트가 아닌 스펙을 작성하세요

"피트니스 앱 시장을 조사해줘"와 같은 요청은 크레딧만 낭비하고 쓰레기 같은 결과를 얻는 방법입니다. 한 줄짜리 프롬프트는 Swarm이 모든 것을 결정하도록 허용합니다. 그러면 잘못된 결정을 내릴 것입니다.

Swarm을 외부 계약자처럼 대우하세요. 스펙은 수집할 내용, 유효한 것으로 간주되는 기준, 허용되는 소스, 정확한 출력 형식, 충돌 발생 시 처리 방법을 정의합니다. 스펙은 전체 워크플로우에서 가장 영향력이 큰 요소입니다. 레벨 2에서는 재사용 가능한 Skill의 시드가 되기 때문입니다.

1# 프로젝트: [이름]
2목표: [한 문장, 주제가 아닌 결과물]
3범위: [포함되는 것, 명시적으로 제외되는 것]
4규칙: [검증, 검증된 결과로 간주되는 기준]
5출처: [공식 게시물, 논문, 1차 출처만, 집계 사이트 제외]
6출력: [파일 형식 / 개수 / 이름 지정 / 형식 세부사항]
7충돌 시: 해당 행에 플래그 표시, 자동 해결 금지
8중단 조건: [추측 대신 중단하고 보고해야 하는 시점]

• 실행 전에 분해 계획을 확인하세요

스펙을 제출하면 Kimi가 실행 계획을 보여줍니다. 서브 에이전트 수, 각 에이전트가 담당하는 작업, 의존성 순서, 단계 예산 등이 포함됩니다. 초보자들이 가장 많이 건너뛰는 단계이며, 건너뛰기에 가장 비용이 많이 드는 단계이기도 합니다.

200개의 에이전트로 구성된 Swarm이 잘못 분해되면 실제 비용이 발생합니다. 계획을 확인하는 것은 비용이 들지 않습니다. 확인해야 할 세 가지는 다음과 같습니다. 범위를 이해했는지, 에이전트 수가 작업에 적합한지, 출력 계획이 실제로 필요한 것과 일치하는지 여부입니다.

1실행 전에 제안된 분해 계획을 보여주세요:
2- 서브 에이전트 수와 각 에이전트가 담당하는 작업
3- 의존성 순서 (무엇이 무엇을 차단하는지)
4- 예상 단계 예산
5- 품질 저하 위험이 가장 큰 위치
6아직 실행하지 마세요. 제 확인을 기다려주세요.

알아두면 좋은 세부 사항: 4,000단계는 Swarm 전체의 총 조정 예산이며, 에이전트당 4,000단계가 아닙니다. 300개의 에이전트가 실행되는 경우 평균적으로 각 에이전트는 약 13단계를 수행합니다. 이는 작업이 Swarm에 적합한지 여부를 알려줍니다.

• 실행하세요

이제 실행합니다. 최대 300개의 서브 에이전트가 각자의 제한된 컨텍스트 내에서 병렬 웨이브로 실행됩니다. 구조화된 출력만 코디네이터로 다시 흘러갑니다.

1스펙을 처음부터 끝까지 실행하세요.
2계획이 허용하는 곳에서는 병렬화하세요.
3차단 요소가 있으면 즉시 플래그를 표시하고, 조용히 해결하지 마세요.
4모든 것을 스펙에 정의된 출력 형식으로 병합하세요.

레벨 1 이후 얻을 수 있는 것

스펙을 기반으로 구축된 단일 Swarm 출력입니다. 가공되지 않았고 검증되지 않았지만 구조화되어 있습니다. 대부분의 사람들은 여기서 멈춥니다. 진정한 가치는 레벨 2에서 시작됩니다.

• 채팅 응답이 아닌 실제 파일을 요구하세요

"포괄적인 보고서"는 에이전트에게 일찍 중단해도 된다는 허가를 줍니다. 반면 "40페이지 PDF + 20,000개 행의 CSV 1개 + 내보내기 가능한 14개의 PNG 차트"는 품질 목표를 제시합니다.

항상 출력을 스펙의 최우선으로 두세요. 출력 수준의 구체성은 리서치 팀과 값비싼 제안 상자의 차이를 만듭니다.

1# 강력한 출력 예시:
2출력: 모델당 한 행의 .xlsx 1개 + 200단어 요약
3출력: 업체별로 명명된 30개의 HTML 파일 (매장당 1개)
4출력: 40페이지 PDF + 20,000개 행 CSV + 14개의 PNG 차트

• 채팅 응답이 아닌 실제 파일을 요구하세요

"포괄적인 보고서"는 에이전트에게 일찍 중단해도 된다는 허가를 줍니다. 반면 "40페이지 PDF + 20,000개 행의 CSV 1개 + 내보내기 가능한 14개의 PNG 차트"는 품질 목표를 제시합니다. 항상 출력을 스펙의 최우선으로 두세요. 출력 수준의 구체성은 리서치 팀과 값비싼 제안 상자의 차이를 만듭니다.

1# 강력한 출력 예시:
2출력: 모델당 한 행의 .xlsx 1개 + 200단어 요약
3출력: 업체별로 명명된 30개의 HTML 파일 (매장당 1개)
4출력: 40페이지 PDF + 20,000개 행 CSV + 14개의 PNG 차트

• 별도의 모델을 출력 검증에 사용하세요

Swarm의 알려진 결함: 명시적으로 검증을 요구하지 않으면 확신에 차 있지만 인용이 부족한 주장을 생성하며, 독립적인 서브 에이전트가 때로는 서로 모순되는 결과를 냅니다. "완료된 것처럼 보인다"와 "정확하다"는 완전히 다른 차원의 문제입니다.

두 번째 모델을 검증 게이트로 사용하세요. 이 모델의 유일한 임무는 칭찬이 아니라 반박하는 것입니다. 프리미엄 토큰을 생성에 사용하는 것이 아닙니다. 다음 단계에서 워크플로우를 재사용 가능한 Skill로 저장하기 전에 조용한 결함을 잡아내는 데 사용하는 것입니다.

1당신은 검증자입니다. 에이전트 Swarm이 첨부된 출력을 생성했습니다.
2당신의 유일한 임무는 무엇이 잘못되었는지 찾는 것입니다.
3
4확인할 사항:
5- 모든 주장된 수치가 명명된 출처로 추적 가능합니까?
6- 두 섹션 간에 모순되는 내용이 있습니까?
7- 사실로 제시되었지만 실제로는 추론에 불과한 것이 있습니까?
8- 출력이 스펙의 형식 요구사항과 일치합니까?
9
10각 문제에 대해: 정확한 위치와 수정 방법을 인용하세요.
11모든 것이 유효하면: 승인.
12문제가 하나라도 있으면: 거부 + 가장 중요한 수정 사항부터 먼저 제시하세요.

• 전체 워크플로우를 Skill로 저장하세요

검증된 실행 후, Kimi에게 전체 워크플로우(입력 형식, 에이전트 단계, 출력 형식, 검증 규칙)를 캡처하도록 지시하세요. 첫 번째 실행은 20분이 걸립니다. 이후의 모든 실행은 30초가 걸립니다. Skill은 시스템이 매번 재시작하지 않고 계속 발전할 수 있는 이유입니다.

1이 전체 워크플로우를 재사용 가능한 Skill로 저장하세요: "[이름]"
2캡처할 내용:
3- 입력 형식 (예상하는 파일/스펙 형태)
4- 효과적이었던 에이전트 단계
5- 출력 형식 및 명명 규칙
6- 스펙의 검증 규칙
7다음에 이 Skill을 실행할 때, 새 파일을 첨부하면 동일한 형태의 결과를 얻을 수 있습니다.

레벨 2 이후 얻을 수 있는 것

신뢰할 수 있는 검증된 출력과 스펙을 다시 구축하지 않고 재생할 수 있는 저장된 Skill입니다. 여기서부터 루프가 복리 효과를 내기 시작합니다.

• 자체 문서를 Swarm 지식으로 제공하세요

Skill은 프로세스를 캡처합니다. 문서를 Skill로 전환하면 도메인 지식이 캡처됩니다. 최고의 작업을 업로드하면 Kimi가 그 구조적 특징을 Skill로 캡처하여, 이후 모든 Swarm이 적용할 수 있게 됩니다.

제공하는 모든 PDF, 기록, 스프레드시트는 컨텍스트가 되어 300개 모든 에이전트가 훈련 데이터에 의존하는 대신 이 컨텍스트를 기준으로 작업합니다. 더 많이 제공할수록 출력이 일반 AI 결과물보다 더 당신의 작업물처럼 읽히게 됩니다.

1이 문서를 재사용 가능한 Skill로 캡처하세요. 무엇이 효과적인지 식별하세요:
2- 구조와 섹션 순서
3- 어조와 음성 레지스터
4- 섹션별 분석 깊이
5이를 "[이름]"으로 저장하세요. 그런 다음 캡처된 Skill을 사용하여 [다른 주제]에 대한 새 문서를 생성하세요. 내용이 아닌 품질 수준을 일치시키세요.

• 모든 거부 사항을 영구적인 규칙으로 전환하세요

검증 단계는 한 번의 결함을 잡아냅니다. 이 단계는 Swarm이 해당 결함을 다시는 만들지 않도록 보장합니다. 피드백을 엄격한 규칙으로 추출하고, Swarm이 어떤 작업을 수행하기 전에 읽는 제약 조건 파일에 작성하세요.

1# CONSTRAINTS.md, 자동으로 로드됨
2- 모든 주장된 수치는 1차 출처로 추적 가능하거나 플래그가 표시되어야 함
3- 충돌 시 자동 해결 금지: 모순점 표면화
4- [마지막 실행 검증자의 피드백에서 추출한 규칙]
5- [절대 반복하고 싶지 않은 실수]
6범위 고정: 스펙의 범위 블록 외부에 있는 것은 건드리지 마세요.

• 새로운 입력에 Skill을 재생하세요

여기서 "복리 효과"가 단순한 유행어가 아니라 실제로 나타납니다. 두 번째 실행은 0에서 시작하지 않습니다. 위에서 구축한 Skill, Swarm 지식, 제약 조건 파일에서 시작합니다. 동일한 워크플로우, 새로운 파일, 설정 시간은 극히 일부입니다.

재생 시 경제성은 극적으로 변화합니다. K3의 캐시 적중 가격은 반복 컨텍스트의 경우 백만 토큰당 $0.30으로, 첫 실행 입력 가격보다 10배 저렴합니다. Skill, 제약 조건, 스펙은 모두 반복 컨텍스트입니다. 새 입력 파일에만 정가가 적용됩니다. 첫 번째 실행은 투자입니다. 이후의 모든 실행은 수익을 거둡니다.

출력 또한 구조적으로 개선됩니다. Skill은 형식을 강제합니다. 제약 조건은 검증자가 이미 잡아낸 모든 실수를 차단합니다. Swarm 지식은 모든 에이전트를 훈련 데이터 대신 실제 문서에 기반하여 작업하도록 합니다. 네 번째 실행은 첫 번째 실행보다 비용이 덜 들 뿐만 아니라 더 나은 결과를 생성합니다. 시스템이 세 차례의 실제 피드백을 통해 학습했기 때문입니다.

1저장된 Skill "[이름]"을 이 새로운 입력에 대해 실행하세요.
2CONSTRAINTS.md를 적용하세요. 캡처된 출력 형식을 사용하세요.
3[새 파일 첨부]
4
5이번 실행의 출력을 마지막 실행과 비교하세요.
6보고:
7- 지난번에 없었던 새로운 발견 사항
8- 마지막 실행 이후 변경된 발견 사항
9- 사라진 내용 (잠재적 격차로 플래그 표시)
10- Skill의 예상 형태와의 차이점

레벨 3 이후 얻을 수 있는 것

자기 개선형 리서치 파이프라인입니다. Skill 라이브러리, 지식 베이스, 제약 조건 파일이 계속 성장함에 따라 각 실행은 이전보다 저렴하고, 빠르며, 정확해집니다.

• Skill을 예약 에이전트로 승격시키세요

루프가 안정적이고 Skill 기반이 되면 수동으로 실행을 중단합니다. Kimi에 트리거(일정, 새 파일 드롭, 모니터링되는 URL)를 지정하세요. 전체 Swarm을 사전에 실행하게 하고, 결과물과 주목할 만한 차이점만 표시하도록 하세요.

경쟁사 모니터링이 가장 좋은 예입니다. 첫 번째 실행: 수동으로 구축하고 검증합니다. 백그라운드 에이전트가 될 때쯤이면 매주 모든 경쟁사를 병렬로 확인하고 시간적 추가 비용 없이 브리핑을 받은 편지함에 전달합니다. 루프에 남은 인간은 당신이 설정한 질문과 그 답변에 대한 당신의 결정뿐입니다.

1Skill "[이름]"을 매주 일정으로 실행하세요.
2트리거: [일정 / 새 파일 / 모니터링 URL]
3각 실행 시: Swarm 실행, CONSTRAINTS.md 적용,
4검증 후, 출력물 + 마지막 실행 대비 차이점을 전달하세요.
5차이점이 [임계값]을 초과하는 경우에만 저에게 알리세요.

2.8T 파라미터로도 해결되지 않는 것

환각 현상은 병렬화에 비례하여 확장됩니다. 더 많은 에이전트가 검색할수록 검증 과정을 거치지 않으면 확신에 찬 잘못된 답변이 더 많이 생성됩니다. Swarm은 스스로 사실을 확인하지 않습니다.

K3는 K2.6보다 3-4배 비쌉니다. 입력: 백만 토큰당 $3.00 vs $0.95. 출력: 백만 토큰당 $15.00 vs $4.00. 캐시는 재생 시 도움이 되지만, 첫 번째 실행은 비용이 많이 듭니다. 순수 비용 최적화를 위해서는 K2.6이 여전히 예산 친화적인 선택입니다.

오픈 웨이트는 아직 공개되지 않았습니다. Moonshot은 2026년 7월 27일까지 공개하겠다고 약속했습니다. 그때까지 K3는 API와 Kimi 앱을 통해서만 실행할 수 있습니다.

Swarm은 나쁜 스펙을 증폭시킵니다. 하나의 에이전트를 통한 모호한 프롬프트는 하나의 컨텍스트 윈도우를 낭비합니다. 300개의 에이전트를 통하면 300개를 병렬로 낭비합니다.

요약

• 한 줄짜리 프롬프트. Swarm이 모든 것을 결정합니다. 그러면 잘못된 결정을 내립니다.
• 분해 검토 건너뛰기. 건너뛰기에 가장 비용이 많이 드는 단계입니다.
• 검증 과정 없음. "완료된 것처럼 보인다"는 "정확하다"는 의미가 아닙니다.
• 검증되지 않은 출력을 Skill로 저장하기. 실수가 모든 향후 실행에 복리 효과로 누적됩니다.
• 순차적 작업에 300개 에이전트 사용하기. Swarm은 사고의 사슬을 병렬화할 수 없습니다.
• K2.6으로 충분한 작업에 K3 사용하기. 모든 작업에 2.8T 파라미터가 필요한 것은 아닙니다.

결론

대부분의 사람들은 Kimi를 열고, 질문을 입력하고, 탭을 닫을 것입니다. 그것이 채팅 상자입니다. K3 기능의 약 10%에 불과합니다.

나머지 90%는 한 번 구축하면 영원히 재생할 수 있는 리서치 팀입니다. 각 레벨은 더 많은 영향력을 제공합니다. 첫 번째 실행, 그다음 신뢰, 그다음 복리 효과, 그다음 자율성입니다. 첫날부터 네 가지 모두가 필요하지는 않습니다. 하나의 스펙으로 레벨 1부터 시작하세요. 출력이 유용하다면 레벨 2로 이동하여 검증하세요. 다시 실행할 계획이라면 Skill을 저장하세요. 시스템은 그 이후로 스스로 더욱 정교해집니다.

프롬프트가 아닌 스펙을 작성하세요. 저장하기 전에 검증하세요. 그러면 모든 실행이 이전보다 저렴하고 정확해지는 것을 지켜보세요.