저는 지난 2주 동안 프로덕션 작업에서 Kimi K2.6 의 Agent Swarm 과 Claude Opus 4.8 의 Dynamic Workflows 를 나란히 실행해 왔습니다. 흥미로운 점은 "어느 것이 더 나은가"가 아닙니다. SWE-Bench 에서 둘은 동률입니다 (80.2 대 80.8). 흥미로운 점은 두 모델의 약점이 정반대이며, 이로 인해 각각 단독으로는 할 수 없는 방식으로 서로를 보완한다는 것입니다.
이 글은 전체 파이프라인, 프롬프트, 그리고 오늘 당장 실행할 수 있는 5가지 사용 사례를 담고 있습니다. 모두 가져가세요.
한 문장으로 요약한 핵심 아이디어
Kimi swarm 은 넓고 저렴합니다. Opus 4.8 은 깊고 비쌉니다. 따라서 swarm 이 모든 후보를 생성하게 하고, Opus 는 적대적으로 거짓된 것들을 제거하는 데만 사용합니다.
이 방법이 특히 효과적인 이유:
Kimi swarm 은 최대 300개의 하위 에이전트를 생성하여 작업을 스스로 분해합니다: LangGraph, CrewAI, 수동 워크플로우가 필요 없습니다. 모델에 내장되어 있습니다. 넓은 범위의 작업에서 약 4.5배 빠르고 비용은 약 $0.60/M (입력), $2.50/M (출력)이며, 캐싱을 통해 75-83%를 절감합니다. 낭비를 감수할 여유가 있습니다.
알려진 단점: 명시적으로 검증을 요구하지 않으면, 인용이 부족하고 지나치게 확신에 찬 주장을 생성하며, 하위 에이전트들이 서로 모순됩니다.
Opus 4.8 은 정반대입니다. Dynamic Workflows 는 오케스트레이션 스크립트를 작성하고, 독립적인 각도에서 문제를 공격하는 하위 에이전트를 실행한 다음, 발견 사항을 반박하는 것만을 목적으로 하는 적대적 에이전트를 배치하여 답이 수렴할 때까지 반복합니다. 결함이 있는 결과를 비판 없이 보고하는 데 있어 0%를 기록한 최초의 Claude 입니다. 4.7보다 약 10배 덜 확신에 차 있습니다.
비용: 단일 실행으로 최대 1,000개의 에이전트가 생성될 수 있으므로, 넓은 검색에는 사용하고 싶지 않을 것입니다. '제거' 작업에 사용하고 싶을 것입니다.
모두가 묻는 질문은 틀렸습니다
"어떤 모델을 사용해야 하나요?"는 현명한 질문처럼 보입니다. 하지만 그렇지 않습니다.
이 질문은 조용히 하나의 모델을 선택하고 다른 모델을 버려야 한다고 가정합니다. 그럴 필요가 없습니다.
2026년에 가장 많이 구축하는 사람들은 모델에 대해 생각하는 것을 멈추고 역할에 대해 생각하기 시작했습니다. 작가는 타자기와 편집자 사이에서 선택하지 않습니다. 다른 순간, 다른 작업을 위해 둘 다 사용합니다.
그것이 전부입니다. 이제 두 가지 역할을 소개하겠습니다.
엔진을 만나보세요: Kimi K2.6 이 조용히 판을 바꾼 이유
이 워크플로우에 스타가 있다면, 그것은 Kimi 입니다. 그리고 숫자를 자세히 살펴볼수록, 업그레이드라기보다는 치트 코드에 가깝다는 느낌이 듭니다.
가격은 거의 부담이 되지 않습니다. 공식적으로는 입력 토큰 100만 개당 $0.95, 출력 토큰 100만 개당 $4.00입니다. 이는 프리미엄 등급보다 입력은 약 5배, 출력은 약 6배 저렴합니다. 시작할 수 있는 무료 경로도 있습니다: 오늘 kimi.com에서 사용하거나 Cloudflare Workers AI 를 통해 무료 일일 크레딧으로 실행할 수 있습니다. 무언가를 시도하는 비용이 이렇게 낮아지면, 아이디어를 아끼지 않게 됩니다. 그냥 실행하면 됩니다.
지치지 않으며, 혼자 일하지 않습니다. 대부분의 사람들이 간과하는 부분입니다. Kimi 의 Agent Swarm 은 최대 300개의 특수 하위 에이전트를 생성하여 단일 자율 실행에서 약 4,000단계에 걸쳐 조정할 수 있으며, 이는 이전 버전의 3배입니다. 다른 모든 어시스턴트는 한 번에 하나의 작업을 수행하는 한 명의 작업자입니다. Kimi 는 수십 또는 수백 명의 작업자에게 동시에 작업 조각을 분배한 다음 결과를 병합하는 코디네이터입니다.
실제로 풀어 놓으면 다음과 같은 일이 벌어집니다:
- 사람들은 한 시간 안에 소규모 에이전시 분량의 결과물을 생성합니다: 웹사이트가 약한 지역 업체를 찾고, 각 업체의 랜딩 페이지 초안을 작성하고, 아웃리치 이메일을 작성하고, 시장 보고서를 생성합니다. 모두 단일 브리프에서 시작합니다.
- 빌더는 오후에 수천 개의 검증된 행을 깔끔한 스프레드시트로 가져오며, 각 행은 실제 출처에 대해 확인됩니다. 이는 단일 에이전트가 거의 하루 종일 걸리는 작업입니다.
- 널리 공유된 한 실행에서, Kimi 는 노트북의 소형 모델을 가리키며 더 빠르게 만들라고 지시받았습니다. 12시간 동안 감독 없이 실행되었고, 천 번 이상의 도구 호출을 수행했으며, 수천 줄을 다시 작성했고, 처리량을 초당 약 15토큰에서 거의 200토큰으로 끌어올렸습니다. 인간의 개입은 없었습니다. 목표만 있었습니다.
또한 오픈 웨이트입니다. 수정된 MIT 라이선스로 출시되었으며, 개발자들이 GitHub 에서 수천 개의 별표를 단 CLI 가 함께 제공됩니다. 블랙박스에 대한 액세스 권한을 임대하는 것이 아닙니다. 검사하고, 호스팅하고, 구축할 수 있는 무언가 위에 서 있는 것입니다.
Kimi 는 엔진룸입니다. 마일을 주행합니다. Swarm 을 운영합니다. "열 가지 버전을 시도해 볼 수 있었으면 좋겠다"를 "점심 먹기 전에 열 가지 버전을 시도했다"로 바꿔줍니다.
하지만 아무도 조종하지 않는 엔진은 잘못된 방향으로 빠르게 나아갈 뿐입니다. 바로 여기에 두 번째 역할이 등장합니다.
마무리 담당자를 만나보세요: Opus 4.8 이 제 역할을 하는 곳
Kimi 가 마일을 주행한다면, Opus 4.8 은 실수를 잡아냅니다.
Anthropic 이 이번 릴리스에서 강조한 것은 벤치마크가 아니었습니다. 정직함이었습니다. Opus 4.8 은 이전 버전보다 자체 코드의 결함을 플래그 없이 넘어갈 가능성이 약 4배 낮은 것으로 보고됩니다. 허세가 적고, "이 부분은 불안정하다"고 말하는 데 더 빠릅니다.
이 하나의 특성은 대량 워크플로우에서 금값입니다. Swarm 이 엄청난 양의 작업을 생성했을 때, 지치지 않는 또 다른 빌더가 필요한 것이 아닙니다. 진실을 말해줄 날카롭고 회의적인 눈이 필요합니다. Opus 는 또한 가장 확실하게 하고 싶은 부분, 즉 프로덕션 수준의 정밀성과 문서 및 시각 자료의 고충실도 판독에서 우세하는 경향이 있습니다.
또한 프로세스의 전면, 즉 하나의 좋은 아키텍처 결정이 잘못된 방향으로의 10시간 작업을 절약하는 부분에 대한 판단력을 제공합니다. 매우 큰 컨텍스트 창은 한 줄의 코드가 작성되기 전에 전체 문제를 머릿속에 담을 수 있음을 의미합니다.
시니어 리뷰어입니다. 아키텍트입니다. 엔진이 생성한 모든 것을 보고 침착하게 "이건 출시하되, 저건 먼저 수정하라"고 말할 수 있는 사람입니다.
정면 대결: Opus 4.8 vs Kimi K2.6
모두가 원하지만 거의 아무도 솔직하게 쓰지 않는 부분입니다.
Anthropic 은 Opus 4.8 을 진정한 업그레이드로 만들었습니다: 더 날카로운 판단력, 지금까지 만든 모델 중 가장 정직한 모델, 그리고 가장 어려운 코딩 및 추론 테스트에서 최고 점수. 진정으로 훌륭한 작업입니다.
그리고 그와 함께, Kimi K2.6 은 조용히 논쟁하기 어려운 무언가를 해냈습니다. 에이전트는 동일한 실제 작업을 수행하고, 대부분의 작업에서 의미 있게 나쁘지 않은 결과를 제공하며, 몇 배 더 저렴한 비용으로 수행합니다. 대부분의 사람들이 매일 실제로 출시하는 것들에서 출력 격차는 작고 가격 격차는 큽니다.
두 모델을 항목별로 비교하면 다음과 같습니다:
- 토큰당 가격. Opus 4.8 은 입력 100만 개당 $5, 출력 100만 개당 $25입니다. Kimi K2.6 은 입력 100만 개당 $0.95, 출력 100만 개당 $4.00으로, 전반적으로 약 5~6배 저렴합니다.
- 모델 가중치. Kimi 는 수정된 MIT 라이선스 하에 오픈되어 있어 자체 호스팅이 가능합니다. Opus 는 독점적입니다.
- 크기 및 컨텍스트. Kimi 는 1조 개의 파라미터 모델에 256K 컨텍스트 창을 가지고 있습니다. Opus 는 1M 컨텍스트 창을 가지고 있습니다.
- 에이전트. Kimi 의 핵심은 swarm 입니다: 단일 자율 실행에서 약 4,000단계에 걸쳐 조정되는 최대 300개의 하위 에이전트. Opus 는 Dynamic Workflows 를 통해 병렬 하위 에이전트를 실행합니다.
- 허용되는 입력. Kimi 는 텍스트, 이미지, 비디오를 받습니다. Opus 는 텍스트와 이미지를 받습니다.
- 가장 어려운 코딩 테스트 (SWE-bench Verified). 둘 다 높은 점수를 기록합니다. Kimi 는 낮은 80점대, Opus 는 높은 80점대로 한 단계 더 높습니다.
- 각각 가장 잘하는 것. Kimi: 비용, 병렬 볼륨, 개방성. Opus: 정직함, 판단력, 정밀성.
솔직하게 읽어보면 교훈은 "Kimi 가 이긴다" 또는 "Opus 가 이긴다"가 아닙니다. 그들은 서로 다른 부분에서 이긴다는 것입니다. 하나는 정확성이 가장 중요할 때 사용하는 정밀 도구입니다. 다른 하나는 마일을 주행하고, swarm 을 운영하며, 예산에 거의 영향을 미치지 않는 엔진입니다. 이것이 바로 현명한 선택이 한쪽을 고르는 것이 아니라 각각을 가장 강력한 위치에 배치하는 이유입니다.
워크플로우: 계획, Swarm, 판단, 출시
이 부분을 저장하세요. 4단계, 두 모델, 깔끔한 인계.
1. Opus 4.8 로 계획 (생각하기).
전체 문제를 Opus 에 설명하고 실행이 아닌 아키텍처를 설계하도록 요청하세요. 구조는 무엇인지, 위험은 무엇인지, 가장 깔끔한 경로는 무엇인지. 그런 다음 한 가지 구체적인 사항, 즉 서면 사양을 요청하세요 (이것이 중요한 이유는 잠시 후에 설명합니다). 의도적으로 프리미엄 토큰을 여기에 사용하는 것입니다. 이것은 당신이 살 수 있는 가장 저렴한 시간입니다. 비용이 많이 드는 실수를 방지하기 때문입니다.
2. Kimi K2.6 으로 Swarm (실행하기).
사양을 Kimi 에 넘기고 엔진을 작동시키세요. 이것이 볼륨이 발생하는 곳입니다: 코드 생성, 테스트 작성, 변형 초안 작성, 파일 전반에 걸친 반복적인 구축 수행. Swarm 이 힘든 작업을 병렬화하도록 하세요. 너무 저렴하기 때문에 첫 번째 시도를 버리고 다시 실행하는 것을 두려워하지 않습니다. 이 단계는 전체 비용의 극히 일부로 작업의 80%를 수행합니다.
3. Opus 4.8 로 판단 (진실을 말하는 사람).
Swarm 이 생성한 모든 것을 Opus 에 다시 제공하고 중요한 질문을 하세요: 이것의 문제는 무엇인가? 이것이 바로 정직함이 비용을 정당화하는 곳입니다. 조용한 결함, 뒷받침되지 않는 가정, 옳아 보이지만 실제로는 그렇지 않은 것들을 잡아냅니다. 프리미엄 가격을 지불하는 것은 생성을 위해서가 아닙니다. 검증을 위해서 지불하는 것이며, 이것이 비싼 토큰을 사용하는 가장 레버리지가 높은 방법입니다.
4. Kimi K2.6 으로 출시 (루프).
Opus 의 노트를 가져와 Kimi 에 넘기고, 엔진이 거의 비용 없이 수정 및 마무리 작업을 수행하도록 하세요. 그런 다음 출시하세요. Kimi 쪽 루프가 너무 저렴하기 때문에 미터기를 쳐다보지 않고 내일, 그리고 그 다음 날에도 다시 실행할 수 있습니다.
아키텍트와 계획하세요. 엔진으로 구축하세요. 진실을 말하는 사람과 판단하세요. 엔진으로 출시하세요. 반복하세요.
진정한 해결책: 프롬프트가 아닌 사양을 작성하세요
Swarm 에서 마법을 얻는 사람과 비싼 쓰레기를 얻는 사람을 구분하는 비결입니다.
대부분의 사람들이 "300 에이전트"를 들으면 "미국에 있는 모든 데이터 센터를 스크랩해"와 같은 한 줄짜리 프롬프트를 발사하고 훌륭한 결과를 기대합니다. 그것은 크레딧을 태우고 쓰레기를 얻는 가장 빠른 방법입니다.
실제 해결책은 swarm 을 지니가 아닌 계약자처럼 대우하는 것입니다. 한 줄짜리 대신, 정확히 무엇을 수집할지, 무엇이 유효한 것으로 간주되는지, 어떤 출처가 허용되는지, 출력 형식이 무엇인지, 상충되는 정보를 발견했을 때 어떻게 해야 하는지를 정의하는 2~3페이지 분량의 문서를 제공합니다. 프롬프트를 작성하는 것이 아닙니다. 사양을 작성하는 것이며, swarm 은 당신이 다른 일을 하는 동안 사양에 따라 실행됩니다.
이제 두 역할이 완벽하게 맞물립니다: 그 사양을 작성하기 위한 세계 최고의 도구는 당신의 신중하고 분별력 있는 모델입니다. Opus 4.8 은 모호한 목표를 PLAN 단계에서 정밀한 사양으로 바꿉니다. Kimi 의 swarm 은 SWARM 단계에서 그 사양을 대규모로 실행합니다. 생각하는 사람이 명령을 작성합니다. 군대가 그것을 수행합니다.
에이전트 swarm 을 "취약하다"고 부르는 사람들은 거의 항상 그들의 프롬프트가 취약했음을 의미합니다. 사양 기반 작업은 결과를 완전히 바꿉니다.
아키텍트가 작성하는 사양의 이 뼈대를 가져가세요:
그것을 엔진에 넘기고 떠나세요.
오늘 루프를 실행하세요: 가져갈 3가지 프롬프트
이것을 시도하기 위해 큰 프로젝트가 필요하지 않습니다. 일반적으로 단일 모델에 던질 모든 작업을 가져와 아래 세 가지 프롬프트를 모두 실행하세요. 대괄호를 채우고 시작하세요.
프롬프트 A. PLAN (Opus 4.8 에 붙여넣기)
1[목표를 평이한 언어로 설명하세요].2아직 아무것도 구축하지 마세요. 아키텍트 역할을 하세요.3이것을 정확히 다음 제목을 사용하여 정밀한 사양으로 바꾸세요:4목표, 범위, 규칙, 출처, 출력, 중단 조건.5마치기 전에, 계획에서 가장 위험한 두 가지 가정을 표시하세요.
프롬프트 B. SWARM (Kimi K2.6 에 붙여넣기)
1다음은 사양입니다. 처음부터 끝까지 실행하세요.2가능한 모든 곳에서 병렬화한 다음, 아래 정의된 최종 OUTPUT 으로 모든 것을 병합하세요.3사양이 실제로 모순되지 않는 한 나에게 질문하지 마세요.4[프롬프트 A의 사양을 붙여넣기]
프롬프트 C. JUDGE (Opus 4.8 에 붙여넣기)
1다음은 사양과 이에 대해 swarm 이 생성한 출력입니다.2회의적으로 임하세요. 당신의 임무는 무엇이 잘못되었는지 찾는 것이지, 칭찬하는 것이 아닙니다.3모든 결함, 뒷받침되지 않는 주장, 조용한 간격을 심각도 순으로 나열한 다음,4빌더에게 바로 넘겨줄 수 있는 짧은 수정 목록을 제공하세요.5[사양과 출력을 붙여넣기]
그런 다음 프롬프트 C의 수정 목록을 Kimi 로 가져가서 모든 것을 패치하고 출시하세요. 이것이 루프의 한 번의 전체 회전이며, 다시 실행하는 데 거의 비용이 들지 않습니다.
CFO 를 미소 짓게 만드는 숫자
이것이 단지 우아할 뿐만 아니라 경제적으로 명백한 이유입니다.
순진한 워크플로우에서는 모든 것을 프리미엄 토큰으로 실행합니다. 모든 버려지는 초안, 모든 테스트, 모든 어리석은 실험, 정가입니다.
이 워크플로우에서는 비싼 모델이 판단력이 실제로 중요한 두 순간, 즉 계획과 평결에만 관여합니다. 그 사이의 모든 것, 즉 토큰 볼륨의 80%를 차지하는 단순히 작업을 수행하는 부분은 몇 배 더 저렴한 모델에서 실행됩니다.
품질을 낮추는 것이 아닙니다. 비쌀 필요가 없었던 부분의 가격을 낮추는 것입니다.
이것이 팀들이 AI 비용을 크게 줄이면서도 출시량을 늘리는 방법입니다. 더 적게 사는 것이 아니라 현명하게 사는 것입니다.
이 조합이 각 모델 단독보다 나은 이유
더 깊은 원칙은 AI보다 오래되었습니다: 비교 우위입니다.
지치지 않고 저렴한 엔진을 볼륨에 사용하세요. 신중하고 프리미엄인 마인드를 판단에 사용하세요. 가장 비싼 사상가에게 잡일을 시키지 말고, 가장 빠른 빌더를 최종 판단자로 신뢰하지 마세요.
하나의 모델만으로는 절충을 강요합니다. 올프리미엄은 필요하지 않은 작업에 돈을 태웁니다. 올저렴은 아무도 잡지 못한 결함을 출시할 위험이 있습니다. 두 모델 루프는 절충을 완전히 거부합니다. 저렴한 모델의 경제성과 신중한 모델의 양심을 모두 얻습니다.
그것은 해킹이 아닙니다. 마침내 소프트웨어에서 사용할 수 있게 된 좋은 분업일 뿐입니다.
이 워크플로우를 조용히 망치는 하나의 실수
JUDGE 단계를 건너뛰는 것.
가장 유혹적인 지름길입니다. swarm 의 출력이 일반적으로 완료된 것처럼 보이기 때문입니다. 컴파일됩니다. 실행됩니다. 완료된 느낌입니다.
"완료된 것처럼 보인다"와 "올바르다"는 다른 행성이며, 이 워크플로우가 안전한 전체 이유는 당신이 신중하고 정직한 모델을 지정하여 그 차이를 알려주도록 했기 때문입니다. 몇 분을 아끼기 위해 그 단계를 생략하면, 훌륭한 시스템을 버그를 출시하는 빠른 방법으로 되돌린 것입니다.
저렴한 볼륨은 신뢰할 수 있는 무언가가 작업을 확인할 때만 슈퍼파워입니다. 판단자를 유지하세요.
결론
어느 모델이 "최고"인지에 대한 논쟁이 점점 더 거세지는 해에, 조용한 진실은 거의 우스울 정도입니다. 최고의 모델은 각각 태어난 일을 위해 지정된 두 개의 모델인 것으로 밝혀졌습니다.
Kimi 는 마일을 주행합니다. Opus 는 실수를 잡아냅니다. 좋은 사양이 둘 사이의 다리입니다.
여전히 논쟁하는 사람들은 계속 논쟁할 것입니다. 당신은 이제 워크플로우를 가지고 있습니다.
가서 다음 달에 사람들이 스레드를 쓸 무언가를 구축하세요.
이것을 저장하세요 🔖.
