본 글은 Moonshot AI가 2026년 6월 12일 공개한 로컬 데스크톱 에이전트 Kimi Work의 구조와 도입 판단 기준을 정리합니다. 클라우드 에이전트가 아닌, 사용자의 실제 브라우저 세션과 로컬 파일에 접근해 작업을 수행하는 방식이 핵심 차이입니다.
확인 시점은 2026년 7월입니다. 지원 환경은 macOS(Apple Silicon)와 Windows이며, 백엔드 모델은 커뮤니티 관측 기준 Kimi K2.6으로 알려져 있습니다.
1. Kimi Work의 정의
Kimi Work는 웹 챗봇이 아니라 다운로드 형태의 데스크톱 애플리케이션입니다. 사용자가 자연어로 목표를 지시하면 로컬 머신에서 그대로 작업을 수행합니다. Moonshot 공식 발표에 따르면 300개의 sub-agent를 병렬로 조정하며, K2.6 스웜은 최대 4,000 단계의 조정 절차가 문서화되어 있습니다.
백엔드 모델인 Kimi K2.6은 2026년 4월 20일 공개된 오픈웨이트 MoE(Mixture-of-Experts) 모델입니다. 릴리즈 자료 기준 토큰당 약 32B 파라미터를 활성화하고 256K 토큰 컨텍스트 윈도우를 제공합니다. 오픈웨이트 MoE 도입 판단 기준 자체가 궁금하다면 Inkling 정리 포스트에서 별도로 다뤘습니다.
2. Agent Swarm 아키텍처
Agent Swarm은 하나의 큰 목표를 여러 sub-agent로 분할해 병렬 처리한 뒤 결과를 조정하는 구조입니다. Moonshot 공식 발표 기준으로 최대 300개 sub-agent가 동시에 동작할 수 있습니다. 이 확장성은 대량 문서 요약, 다수 URL 스크래핑, 다중 소스 조사 같은 fan-out 작업에서 실효가 큽니다.
2-1. 언제 실제 이득이 되는가
단일 문서 QA처럼 병렬화 여지가 없는 작업에서는 300개 스웜의 이득이 미미합니다. 반면 100개 PDF를 요약해 하나로 통합하거나, 여러 티커의 과거 시세를 각각 다른 페이지에서 수집하는 시나리오는 스웜과 잘 맞습니다. 각 sub-agent가 독립 파일 하나씩을 담당하고, 최종 조정 단계에서 결과가 병합됩니다.
3. WebBridge — 실제 브라우저 세션 사용
WebBridge는 브라우저 확장 형태로 동작합니다. 클라우드 에이전트가 호스팅 가상 브라우저를 새로 띄우는 방식과 다르게, 사용자의 실제 브라우저와 이미 로그인된 세션을 그대로 사용합니다. 그 결과 SNS 계정, 사내 대시보드, 유료 리서치 사이트에도 재로그인 없이 접근할 수 있습니다.
이 방식은 편의성이 크지만, 세션 노출 리스크도 함께 상속합니다. 에이전트가 잘못된 클릭이나 폼 전송을 하면 계정 상태에 그대로 반영되므로, 뒤에서 다룰 승인 게이트(Ask before acting) 설정을 활성화하고 발동 대상을 좁혀두는 편이 안전합니다.
4. 크론 스케줄러와 로컬 실행
내장 스케줄러는 표준 cron 표기를 지원합니다. minute / hour / day-of-month / month / day-of-week 5필드 구조이며, 아래 예시가 그대로 유효합니다.
# 매일 오전 7시
0 7 * * *
# 매시 정각
0 * * * *
# 평일 08:30
30 8 * * 1-5
# 매월 1일 00:00
0 0 1 * *로컬 파일에 대해서는 마운트한 폴더만 접근하고, Python 스크립트를 백그라운드로 실행합니다. Moonshot 공식 자료 기준 원본 파일은 사용자 승인 없이 변경되지 않으며, “Keep Computer Awake” 토글로 야간 실행이 중단되지 않도록 지정할 수 있습니다.
5. 요금제와 300-agent 풀 스웜 조건
앱 자체는 무료로 다운로드할 수 있지만, 실질적인 에이전트 기능은 유료 플랜에서 열립니다. Moonshot 요금제 기준으로 정리하면 다음과 같습니다.
- Moderato — 월 $19: K2.6 모델, Deep Research, Kimi Code 사용
- Allegretto — 월 $39: 제한된 규모의 Agent Swarm
- Allegro — 월 $99: 300개 sub-agent 풀 스웜과 전문가 워크플로우
- Vivace — 월 $199: 최고 사용량 등급
즉 “300개 스웜”이라는 마케팅 문구를 실제로 활용하려면 Allegro 등급 이상이 필요합니다. 단일 작업 자동화 수준이라면 Moderato 또는 Allegretto로도 충분합니다. 더 작은 규모의 온디바이스 LLM 사례와 비교하고 싶다면 Bonsai 27B 온디바이스 LLM 정리에 함께 담아뒀습니다.
6. 클라우드 에이전트와의 결정 차이
Kimi Work의 로컬 실행 모델은 데이터가 사용자 디바이스에 머문다는 점, 이미 로그인된 브라우저를 그대로 활용한다는 점에서 클라우드 에이전트와 명확히 다릅니다. 반면 설치·업데이트·보안 책임은 사용자에게 전가됩니다.
- 실행 위치: 로컬 데스크톱 vs 벤더 서버
- 파일 접근: 마운트한 폴더 vs 업로드/샌드박스
- 브라우저: 실제 로그인 세션 vs 호스팅 가상 브라우저
- 스케줄링: 내장 크론 vs 외부 툴 조합
- 보안 책임: 사용자 vs 벤더
오픈소스 계열의 로컬 AI 어시스턴트 대안과 비교하려는 경우 OpenClaw 오픈소스 개인 AI 어시스턴트 정리도 함께 참고하는 편이 유리합니다.
7. 도입 판단 체크리스트
실제 팀에서 Kimi Work를 검토할 때는 다음 항목을 먼저 점검하는 편이 안전합니다.
- 병렬 처리로 이득을 볼 fan-out 작업이 실제로 존재하는가
- 브라우저 세션 상속으로 발생할 사고에 대한 롤백 절차가 준비되어 있는가
- Windows 또는 macOS(Apple Silicon) 환경이 조직 표준인가
- 300개 스웜 활용을 위한 Allegro 요금제(월 $99) 예산이 확보 가능한가
- 내부 규정상 로컬 실행형 AI 도구 사용이 승인 가능한가
이 다섯 항목 중 두 개 이상에서 부정형 답이 나온다면, 클라우드 에이전트 또는 커스텀 파이프라인이 상대적으로 안전한 선택입니다. 반대로 사내 데이터의 외부 반출 제약이 강하고 fan-out 작업 수요가 크다면 Kimi Work 계열이 유효합니다.
관련 글
Kimi Work의 로컬·오픈웨이트 맥락은 최근 정리한 다음 글들과 이어집니다.
- 로컬에서 도는 오픈소스 개인 AI 어시스턴트의 접근 방식은 OpenClaw 정리 — 로컬에서 도는 오픈소스 개인 AI 어시스턴트 (2026-07)에서 다뤘습니다.
- Kimi K2.6과 유사한 오픈웨이트 MoE 도입 판단 기준은 Inkling 정리 — 첫 오픈웨이트 975B MoE 도입 판단 기준 (2026-07)에서 정리했습니다.
- 더 작은 규모의 온디바이스 LLM 사례가 궁금하다면 Bonsai 27B 정리 — 폰에서 돌아가는 27B급 온디바이스 LLM (2026-07)이 좋은 비교점이 됩니다.
📌 함께 보시면 좋은 글
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요