제 생각은 이렇습니다, Pi 팬들이 여기 숨어 있나요?

당신을 위한 것이 아닐 수도 있습니다. Pi의 제작자인 Mario Zechner의 여러 인터뷰를 본 후, 저는 고통스러운 깨달음에 도달했습니다: Pi는 로컬 LLM (Local LLMs)을 전혀 염두에 두고 설계되지 않았다는 것입니다. 그는 본질적으로 Claude CLI의 더 가벼운 버전을 만들고 있습니다. Pi는 다른 에이전트 프레임워크 (Agentic frameworks)에 비해 현저히 짧은 시스템 프롬프트 (System prompt)와 적은 기본 제공 도구 (Out-of-the-box tools)를 사용하는 것으로 알려져 있습니다. 하지만 만약 Pi가 주로 API 사용자들을 위한 것이라면, 왜 갑자기 더 긴 시스템 프롬프트와 더 풍부한 도구 가용성이 문제가 되는 것일까요:

KV 캐시 (KV cache) 효율성: 주요 API 제공업체들(특히 DeepSeek)은 입력 토큰의 미스율 (Miss rates)을 최소화하기 위해 거대한 KV 캐시를 구축합니다. 따라서 짧은 시스템 프롬프트가 여러분이 기대하는 것만큼 많은 비용을 절약해주지는 않을 것입니다. 게다가 출력 토큰 (Output token) 절약을 위해서라면, 제가 알기로는 거의 모든 AI 에이전트에서 caveman을 사용할 수 있습니다.

가능한 한 오랫동안 "스마트 존 (Smart zone)"에 머무르기: 아무리 노력하더라도 토큰의 상위 10%만이 전체 어텐션 예산 (Attention budget)을 할당받습니다. 로컬 LLM과 달리, SOTA 모델들은 추론 품질을 유지하기 위해 훨씬 더 큰 컨텍스트 윈도우 (Context windows, 최대 1M 토큰)를 갖는 경향이 있어, 이들에게 긴 시스템 프롬프트는 문제가 되지 않습니다.

Pi는 로컬 사용자의 요구사항을 해결하지 못하는 반면, API 사용자들에게는 실제로 중요하지 않은 문제들을 해결하고 있는 것처럼 보입니다. 그렇다면 타겟 오디언스 (Target audience)는 누구일까요? 분명 오랫동안 Claude를 사용해온 Mario가, 이러한 SOTA 모델들이 Pi의 기본 경험을 얼마나 많이 뒷받침하고 있는지(heavy-lifting) 깨닫고 있는지 확신할 수 없습니다.

저는 객관적으로 Gemma-4-26B-A3B 및 Qwen3.6-35B-A3B보다 약한 두 모델을 테스트했습니다:

• Nvidia-Nemotron-Cascade-2-30B-A3B
• Nvidia-Nemotron-3-Nano-Omni-30B-A3B

권장되는 샘플링 파라미터 (Sampling parameters)를 사용하고 추론 (Reasoning)을 off로 설정했을 때, 추가 지침 없이도 절반 이상의 경우에서 이 두 모델은 현재 작업 디렉토리를 Pi의 설치 디렉토리로 생각했으며, 순정 Pi를 사용한 C++/Qt 프로젝트에서 단 한 번의 툴 콜 (Tool call)도 수행하지 못했습니다 (아래 참조). llama.cpp에서 제가 명시적으로 reasoning = on으로 설정한 후에야 이 모델들이 안정적으로 작동하기 시작했습니다.

Nemotron-3-Nano-Omni가 혼란을 겪음
Nemotron-Cascade-2가 도구 호출(Tool Calling)을 거부함

요약하자면, 이 두 모델보다 성능이 낮은 모델은 순정(vanilla) Pi를 구동할 것으로 기대해서는 안 됩니다. 그동안 OpenCode, Claude CLI, 혹은 little-coder(이에 대해서는 나중에 더 자세히 다루겠습니다)에서는 이러한 문제들이 발생하지 않았습니다. 제가 이 두 형편없는 모델(LOUSY MODELS)을 Pi와 함께 실행한 가장 큰 이유는 Pi의 기본 성능의 하한선(lower bound)을 보여주기 위해서였습니다. 즉, 성능이 좋은 모델(클라우드 또는 로컬)을 사용한다면 에이전트/하네스(harnesses) 자체의 품질은 일반적으로 사용자에게 투명하게 느껴집니다. 오직 형편없는 모델들만이 이 에이전트의 진정한 본색을 드러낼 수 있습니다.

Pi란 무엇인가? 저는 많은 사람들이 데스크톱 세계의 Arch Linux와 Pi를 비교하는 것을 들었습니다. 제 생각에 더 적절한 비유는, 프로그래밍 언어에서 Lisp/Scheme이 그러하듯 Pi가 AI 에이전트에게 갖는 위치입니다: 소규모이지만 열정적인 팬층; 미니멀리즘 디자인 철학; 적은 가드레일(guardrails)과 최대의 유연성; 많은 변형/포크(variants/forks); 모든 것을 처음부터 직접 만들 의지가 있는 기술 숙련 사용자들에게 믿을 수 없을 정도로 강력함; … 최근 r/PiCodingAgent에서 해당 서브레딧의 멤버가 약 15,000명뿐이라는 게시물을 읽었습니다. 아마도 Pi는 결코 주류(mainstream)가 되지 못할지도 모릅니다. 하지만 Lisp나 Scheme과 마찬가지로, 깊이 파고들 준비가 된 사람들에게 독특한 무언가를 제공하기 때문에 이를 지지하는 충성스러운 팬들은 항상 존재할 것이라고 생각합니다.

대안들
어떤 이들은 Oh-My-Pi를 제안할 수도 있습니다. 이 인기 있는 도구를 사용하며 최근 제가 겪은 개인적인 경험은 엇갈렸습니다. 약 일주일 전, Konsole에서만 발생하는 TUI 렌더링 문제를 겪었습니다. 저는 재현(repro) 화면 녹화본과 함께 상세한 GitHub 이슈를 제출했습니다(링크 여기). 한 시간 이내에 봇이 이슈를 수집하여 자동으로 PR(Pull Request)을 생성했습니다. 수정 사항은 바로 다음 날 main 브랜치에 병합되었습니다. 제 문제가 전혀 해결되지 않았다는 것을 깨닫기 전까지는 해피엔딩처럼 보였습니다. 이 과정은 OMP 코드베이스의 전반적인 품질을 다시 생각하게 만들었습니다. 반대로, Pi 개발자들은 상당히 보수적이며 기본적으로 사용자가 오픈한 이슈들을 모두 닫아버립니다. 어느 쪽이 더 나은지는 모르겠습니다.

제가 현재 가장 좋아하는 것은 소규모 로컬 모델에 맞춰 튜닝되었다고 주장하는 Pi의 포크(fork)인 little-coder입니다. 이 모델은 OpenCode보다 훨씬 짧은 시스템 프롬프트 (system prompt)를 사용하지만, 성능이 낮은 모델에서도 문제없이 도구 호출 (tool calling)을 처리합니다. 개발 팀과 커뮤니티의 규모는 더 작지만, 프로젝트는 유망해 보입니다. Pi를 사용하는 로컬 LLM 사용자로서 여러분의 생각을 알려주세요. /u/L0stInHe11 제출 [link] [comments]