Kimi K2.5 리뷰: Claude Opus급 오픈소스 모델의 등장과 로컬 구동의 현실


매일 아침 눈을 뜨면 새로운 LLM이 쏟아져 나오는 세상입니다. 개중 90%는 “OpenAI를 잡았다”고 주장하지만, 막상 써보면 벤치마크 점수만 높은 ‘종이 호랑이’인 경우가 허다하죠. 그런데 최근 Hacker News와 로컬 LLM 커뮤니티가 꽤 시끄럽습니다. 바로 Moonshot AI의 Kimi K2.5 때문입니다.

단순히 또 하나의 중국산 모델이 나왔다는 뉴스가 아닙니다. 엔지니어들 사이에서 “드디어 Claude Opus나 Sonnet과 비벼볼 만한 오픈소스 모델이 나왔다”는 평가가 나오고 있기 때문입니다. 저도 주말 동안 이 모델을 씹고 뜯고 맛보고 즐겨봤습니다. 과연 현업 시니어 엔지니어 입장에서 이 모델이 ‘실전 투입’ 가능한 물건인지, 아니면 그냥 스쳐 지나갈 바람인지 정리해 드립니다.

1. 코딩 에이전트로서의 성능: “Opus의 대안이 될 수 있는가?”

결론부터 말하자면, “네, 놀랍게도 그렇습니다.”

보통 오픈 웨이트(Open Weights) 모델들은 일반적인 대화에서는 그럴싸하지만, 복잡한 로직을 짜거나 레거시 코드를 리팩토링 시키면 문맥을 놓치고 환각(Hallucination)을 일으키기 일쑤입니다. Qwen Coder가 가성비로 버텨왔지만, 복잡도 높은 작업에서는 여전히 Claude 3.5 Sonnet이나 Opus에 밀리는 게 현실이었죠.

하지만 HN의 유저 anon의 코멘트가 정확했습니다:

“오픈소스 모델을 쓰면서 Anthropic이나 OpenAI의 최상위 모델과 차이를 못 느낀 건 이번이 처음이다.”

저 역시 CRUD 웹앱의 백엔드 로직을 OpenCode 와 붙여서 테스트해봤는데, 기존에 GLM 4.7이 뱉어내던 미묘한 버그들을 Kimi K2.5는 아주 깔끔하게 처리했습니다. 특히 Instruction Following(지시 이행) 능력이 탁월해서, 복잡한 요구사항을 던져도 ‘멍청한 짓’을 덜 합니다.

물론 단점이 없는 건 아닙니다. Kimi CLI 도구는 메모리 누수(Memory Leak) 이슈가 보고되고 있고, 장시간 오케스트레이션 작업 시 속도가 느려지는 현상이 관찰됩니다. 하지만 모델 자체의 ‘지능’만 놓고 보면 확실히 티어 1급입니다.

2. 로컬 구동의 현실: “집에서 돌릴 생각은 마세요”

이 모델의 성능 비밀은 무식할 정도로 거대한 파라미터 사이즈에 있습니다. 여기서 많은 분이 좌절하실 겁니다.

  • Full Model: 약 630GB (FP16 기준 추정)
  • 요구 사양: H200 GPU 4장

“우리 집 게이밍 PC로 돌릴 수 있나요?”라고 묻는다면, 대답은 “돌려는 드릴게”입니다. 하지만 속도가 문제죠.

대역폭(Bandwidth)의 병목

MoE(Mixture of Experts) 아키텍처 특성상 모든 파라미터를 항상 쓰진 않지만, 모델을 메모리에 올리는 것 자체가 일입니다. HN의 한 유저가 분석한 바에 따르면, NVMe SSD의 읽기 속도가 7GB/s~15GB/s라고 해도, 시스템 RAM이나 SSD로 오프로딩(Offloading)을 하게 되면 초당 토큰 생성 속도(t/s)는 처참해집니다.

“320억 개의 활성 파라미터(Active Params)를 처리하려면, 소비자용 SSD에서는 약 3초당 1토큰이 나옵니다.”

3초에 한 글자씩 찍히는 코드를 보고 있으면 속 터져 죽습니다. 1.8-bit 양자화(Quantization) 버전을 쓰면 24GB VRAM GPU 한 장과 256GB 시스템 RAM으로 구동은 가능하지만, 이건 학술적 호기심 충족용이지 실무용은 아닙니다. 제대로 쓰려면 최소 240GB 이상의 VRAM 이 필요합니다. 즉, Mac Studio Ultra 풀옵션이나 3090/4090을 주렁주렁 매단 채굴기급 리그가 아니면 로컬 구동은 사실상 불가능합니다.

3. 가성비와 API 전략

로컬 구동이 어렵다면 남은 건 API입니다. 다행히 Moonshot AI의 API 가격 정책은 꽤 공격적입니다. Anthropic의 Claude 3 Opus나 Sonnet 대비 훨씬 저렴한 가격에 비슷한 성능을 뽑아낼 수 있습니다.

특히 OpenCode 같은 서드파티 툴과 결합했을 때의 시너지가 좋습니다. 저의 경우, 단순한 코드 생성이나 보일러플레이트 작업은 Kimi에게 맡기고, 아키텍처 설계나 보안이 중요한 크리티컬 리뷰만 Claude에게 맡기는 하이브리드 전략 을 사용하고 있습니다. 이렇게만 해도 월 API 비용을 획기적으로 줄일 수 있습니다.

한 가지 아쉬운 점은 모델의 ‘성격’입니다. 이전 버전인 K2는 꽤 개성 있는 답변을 줬는데, K2.5는 마치 GPT-4나 Gemini처럼 매우 정제되고 딱딱한(corporate) 톤으로 변했습니다. 안전성(Safety) 튜닝이 강하게 들어간 것으로 보이는데, 개인적으로는 조금 심심해졌다는 느낌을 지울 수 없습니다.

4. 결론: 엔지니어를 위한 조언

Kimi K2.5는 오픈소스(정확히는 Open Weights) 진영이 빅테크의 폐쇄형 모델을 얼마나 바짝 추격했는지 보여주는 중요한 이정표입니다.

  1. SaaS/API 사용자: 무조건 써보세요. Claude Sonnet의 훌륭한 대체재이자 보완재입니다. 가성비가 압도적입니다.
  2. 로컬 LLM 사용자: 집에 H100/H200 클러스터가 없다면, 굳이 로컬에서 돌리려 애쓰지 마세요. 전기세와 정신 건강만 해칩니다.
  3. CTO/리드급: 팀원들에게 “코딩 어시스턴트로 이거 한번 테스트해봐”라고 권해볼 만한 가치가 충분합니다. 특히 예산 문제로 Copilot이나 Claude 구독이 부담스러운 스타트업에게는 단비 같은 존재가 될 것입니다.

오픈소스 AI의 겨울은 아직 오지 않았습니다. 오히려 지금이 가장 뜨거운 여름일지도 모르겠네요.