Kimi K2.6 에이전트 스웜 실전 가이드 — 혼자서 팀 수준 작업 처리하는 법

---

13시간 동안 코드베이스 4,000줄을 수정하고 시스템 처리량을 185% 올린 AI가 있습니다. 사람 없이, 혼자서요. 이게 Kimi K2.6 에이전트 스웜이 실제로 한 일입니다.

---

에이전트 스웜이 뭔지부터

기존 AI 에이전트는 순차적으로 움직입니다. 하나 하고, 다음 하고, 또 다음 하는 구조입니다. 큰 작업을 던지면 시간이 선형으로 늘어납니다.

K2.6 에이전트 스웜은 반대로 움직입니다. 복잡한 작업이 들어오면 코디네이터(K2.6 자체)가 태스크 구조를 분석하고, 코드 리팩토링은 코드 에이전트에, 리서치 합성은 리서치 에이전트에, 문서 생성은 라이팅 에이전트에 배분합니다. 동일한 에이전트를 복제해서 뿌리는 게 아니라 서브태스크 유형에 맞게 각기 다른 스페셜리스트 에이전트를 동적으로 생성합니다.

K2.5의 100 서브에이전트, 1,500 스텝에서 K2.6은 300 서브에이전트, 4,000 스텝으로 3배 확장됐습니다. 이 병렬화가 단순히 속도만 높이는 게 아니라 출력 품질과 작업 가능 범위 자체를 넓혔습니다.

수학적으로 보면, 300 에이전트가 4,000 스텝 예산을 쓰면 에이전트당 평균 약 13스텝이 됩니다. 즉 각 서브에이전트는 깊게 순차 추론하는 게 아니라 짧고 전문화된 서브태스크를 처리하는 구조입니다. 태스크 설계를 어떻게 하느냐에 따라 이 예산이 의미 있게 달라집니다.

---

실제로 무엇을 했나 — exchange-core 사례

K2.6은 8년 된 오픈소스 금융 매칭 엔진 exchange-core를 혼자 13시간 동안 자율 개선했습니다. 12가지 최적화 전략을 반복 실행하고, 1,000회 이상의 툴 콜로 4,000줄 이상의 코드를 수정했습니다. CPU·allocation 플레임 그래프를 분석해 숨겨진 병목을 찾아내고, 코어 스레드 토폴로지를 4ME+2RE에서 2ME+1RE로 재구성했습니다. 결과는 중간 처리량 185% 향상(0.43 → 1.24 MT/s), 성능 처리량 133% 향상(1.23 → 2.86 MT/s)이었습니다.

사람 시니어 엔지니어가 같은 작업을 한다면 아마 며칠에서 일주일 이상 걸렸을 겁니다.

---

3단계 아키텍처 — 내부에서 어떻게 돌아가나

K2.6 스웜은 오케스트레이터 → 도메인 에이전트 → 출력 집계, 3단계로 작동합니다. 오케스트레이터가 프롬프트를 받아 태스크 복잡도를 분석하고 분해 계획을 생성합니다. 그 다음 각기 다른 시스템 프롬프트와 툴셋을 가진 도메인 특화 서브에이전트를 생성합니다. 각 도메인 에이전트는 자신의 스코프 안에서 독립적으로 멀티스텝 툴 체인(코드 생성, 웹 브라우징, 파일 조작, 데이터 분석)을 실행합니다. 오케스트레이터는 진행 상황을 모니터링하고 에이전트 간 의존성을 처리하며, 모든 서브태스크가 완료되면 병합 단계를 실행합니다.

---

Kimi Code CLI로 스웜 실전 사용

스웜 기능은 Kimi Code CLI에서 바로 쓸 수 있습니다. kimi.com/code에서 설치 후 아래처럼 사용합니다.

먼저 계획 먼저 확인합니다. 바로 스웜을 돌리기 전에 K2.6이 어떻게 작업을 쪼갤지 확인하는 게 좋습니다:

/plan 이 Node.js 프로젝트의 API 응답 속도를 최적화하고,
      병목 지점을 찾아서 수정하고,
      수정 전후 벤치마크를 포함한 리포트를 작성해줘

계획이 맞다고 판단되면 스웜 실행합니다:

/swarm 이 Node.js 프로젝트의 API 응답 속도를 최적화하고,
       병목 지점을 찾아서 수정하고,
       수정 전후 벤치마크를 포함한 리포트를 작성해줘

K2.6이 자동으로 태스크를 분해해서 병렬로 처리합니다. 프로파일링 에이전트, 코드 수정 에이전트, 테스트 에이전트, 문서 작성 에이전트가 동시에 돌아갑니다.

---

API로 스웜 직접 제어하기

Kimi Code CLI가 아니라 API로 직접 통합하고 싶다면 이렇게 씁니다:

from openai import OpenAI
import asyncio
import json

client = OpenAI(
    api_key="YOUR_MOONSHOT_API_KEY",
    base_url="https://api.moonshot.cn/v1",
)

# 오케스트레이터 프롬프트 — 스웜 분해 전략을 여기서 정의
ORCHESTRATOR_PROMPT = """
당신은 복잡한 소프트웨어 엔지니어링 태스크를 병렬 서브태스크로 분해하는 오케스트레이터입니다.
태스크를 받으면:
1. 독립적으로 처리 가능한 서브태스크로 분해하세요
2. 각 서브태스크에 필요한 전문성과 툴을 명시하세요
3. 서브태스크 간 의존성을 파악하세요
4. JSON 형식으로 분해 계획을 출력하세요
"""

def decompose_task(task: str) -> dict:
    """오케스트레이터가 태스크를 서브태스크로 분해"""
    response = client.chat.completions.create(
        model="kimi-k2.6",
        messages=[
            {"role": "system", "content": ORCHESTRATOR_PROMPT},
            {"role": "user", "content": f"다음 태스크를 분해해줘:\n{task}"}
        ],
        response_format={"type": "json_object"}
    )
    return json.loads(response.choices[0].message.content)

async def run_sub_agent(subtask: dict, semaphore: asyncio.Semaphore) -> dict:
    """개별 서브에이전트 실행 — 세마포어로 동시 실행 수 제어"""
    async with semaphore:
        loop = asyncio.get_event_loop()
        response = await loop.run_in_executor(
            None,
            lambda: client.chat.completions.create(
                model="kimi-k2.6",
                messages=[
                    {
                        "role": "system",
                        "content": f"당신은 {subtask['specialty']} 전문가입니다. "
                                   f"주어진 서브태스크만 처리하세요."
                    },
                    {"role": "user", "content": subtask["task"]}
                ]
            )
        )
        return {
            "subtask_id": subtask["id"],
            "result": response.choices[0].message.content
        }

async def run_swarm(task: str, max_concurrent: int = 50):
    """
    스웜 실행 메인 함수
    max_concurrent: 동시 실행 에이전트 수 (권장 50~100)
    """
    # 1. 태스크 분해
    print("태스크 분해 중...")
    plan = decompose_task(task)
    subtasks = plan.get("subtasks", [])
    print(f"서브태스크 {len(subtasks)}개 생성됨")

    # 2. 세마포어로 동시 실행 제한
    semaphore = asyncio.Semaphore(max_concurrent)

    # 3. 병렬 실행
    print(f"스웜 실행 시작 (최대 {max_concurrent}개 동시 실행)...")
    results = await asyncio.gather(
        *[run_sub_agent(st, semaphore) for st in subtasks]
    )

    # 4. 결과 집계
    aggregation_prompt = f"""
다음 서브태스크 결과들을 하나의 일관된 최종 결과물로 합쳐주세요:

{json.dumps(results, ensure_ascii=False, indent=2)}

원래 태스크: {task}
"""
    final_response = client.chat.completions.create(
        model="kimi-k2.6",
        messages=[{"role": "user", "content": aggregation_prompt}]
    )

    return final_response.choices[0].message.content

# 실행 예시
if __name__ == "__main__":
    task = """
    우리 Python 백엔드의 데이터베이스 쿼리 성능을 최적화해줘.
    - 슬로우 쿼리 파악
    - 인덱스 최적화 제안
    - N+1 문제 탐지 및 수정
    - 수정 전후 예상 성능 비교 리포트 작성
    """
    result = asyncio.run(run_swarm(task, max_concurrent=50))
    print(result)

동시 실행 실용 권장치는 50~100개 요청이고, 나머지는 세마포어 기반 큐로 처리합니다. 위 코드가 그 패턴을 그대로 구현한 겁니다.

---

어떤 작업에 스웜이 맞나

스웜이 효과적인 경우는 태스크가 독립적인 병렬 서브태스크로 깔끔하게 분해되고, 자율적인 오케스트레이션이 수동 파이프라인보다 유리한 경우입니다.

실전에서 잘 맞는 작업들:

대규모 코드베이스 분석 + 수정: 여러 모듈을 동시에 분석하고, 각 모듈 담당 에이전트가 병렬로 수정안을 만들고, 마지막에 통합합니다. 200개 파일 리팩토링도 현실적입니다.

멀티소스 리서치 합성: 경쟁사 10곳을 동시에 분석하거나, 여러 문서를 병렬로 요약하고 합칠 때 적합합니다.

풀스택 기능 개발: 프론트엔드 에이전트, 백엔드 에이전트, 테스트 에이전트, 문서 에이전트가 동시에 돌아가면서 하나의 피처를 완성합니다.

반면 맞지 않는 경우도 있습니다. 오케스트레이터의 초기 태스크 분해가 잘못되면 서브에이전트들이 효율적으로 엉뚱한 방향으로 움직입니다. 프롬프트가 모호하거나 태스크가 진짜 참신한 문제라면 분해 품질 자체가 스웜의 첫 번째 실패 지점입니다.

또한 에이전트 스웜 내부는 블랙박스입니다. 분해, 라우팅, 중재가 모두 내부에서 처리되기 때문에, 에이전트 결정을 설명해야 하거나 오케스트레이션 로직을 직접 튜닝해야 하는 팀에게는 맞지 않습니다. 그런 경우 LangGraph 같은 명시적 프레임워크가 더 유리합니다.

---

비용 계산 — 스웜은 토큰을 빠르게 씁니다

300 에이전트 동시 실행은 토큰과 쿼터를 빠르게 소모합니다. 스웜 돌리기 전에 반드시 일일 지출 한도를 설정하세요.

K2.6 출력 토큰 기준 $2.50/백만 토큰이라고 해도, 에이전트가 많을수록 출력이 선형 이상으로 늘어납니다. 소규모 테스트(10~20 에이전트)부터 시작해서 분해 품질을 확인한 다음 규모를 키우는 게 맞습니다.

에이전트 수 적합한 태스크 규모

10~20개	단일 기능 개선, 소규모 분석
50~100개	모듈 단위 리팩토링, 중규모 리서치
300개	대형 코드베이스 전체 최적화, 대규모 합성 작업

---

K2.6 vs K2.7-Code — 무엇을 써야 하나

K2.7-Code는 MCP 툴 사용과 코딩 정밀도에 특화된 릴리즈이고, 추론 토큰을 30% 덜 씁니다. 에이전트 스웜 자체는 K2.6의 기능입니다. 현재 K2.7-Code에서 스웜 프리미티브가 동일하게 지원되는지는 Moonshot이 명시하지 않았습니다.

간단하게 정리하면, 스웜 오케스트레이션이 필요하면 K2.6을, MCP 멀티툴 에이전트 단일 세션이라면 K2.7-Code를 쓰는 게 현재 기준 자연스러운 선택입니다.

---

✅ 결론

• K2.6 스웜은 태스크를 300 서브에이전트에게 병렬 분배하는 오케스트레이션 시스템입니다
• 실제 13시간 자율 실행으로 레거시 금융 엔진 처리량 185% 향상을 검증했습니다
• API로 직접 제어할 수 있고, 세마포어로 동시 실행 수를 제한하는 게 필수입니다
• 태스크가 병렬 분해 가능한 구조일 때 효과가 크고, 모호한 태스크에서는 내부 분해 오류가 첫 번째 위험입니다

❌ 주의

• 스웜 내부는 블랙박스 — 중간 과정 디버깅이 어렵습니다. 장시간 실행엔 외부 체크포인팅 필수
• 일일 지출 한도 먼저 설정하세요. 에이전트가 많을수록 토큰 소모가 예상보다 빠릅니다
• /plan 먼저 실행해서 분해 계획 확인 후 /swarm을 실행하세요