로컬 1.7B 모델에서 PI-Desktop의 Plan, Goal 및 Subagent 모드를 실행해 본 결과와 문제점

Pi는 오픈 소스 코딩 에이전트 엔진으로 10월 1일에 1.0 버전에 도달했습니다. 3일 후인 10월 4일에는 Pi 1.0.0을 기반으로 구축된 첫 번째 릴리스인 v0.16.1 PI-Desktop이 출시되었습니다. PI-Desktop은 해당 엔진의 데스크톱 GUI입니다: 프론트엔드는 Electron을 사용하고, 그 아래에는 Rust '호스트 코어'가 있으며, Pi 에이전트 패키지는 Node 사이드카에서 실행됩니다.

먼저 명확히 할 것이 있습니다. PI-Desktop은 Pi 팀의 제품이 아니라 vastsa의 커뮤니티 프로젝트입니다. 라이선스는 LGPL-3.0이며, GitHub 스타는 약 6.4k개이고, README에는 0.16.x 라인을 'Early Preview'라고 명시하고 있습니다. 다른 여러 프로젝트들도 'pi-desktop'이라는 이름을 사용하므로, 찾아볼 때는 레포지토리와 공식 문서부터 시작하는 것이 좋습니다.

저는 기능 목록을 작성하고 싶지 않았습니다. 대신 일반 Linux 환경에 설치한 후 터미널 에이전트와 차별화되는 세 가지 요소, 즉 Plan 모드, Goal 모드 및 Subagent를 실행했을 때 실제로 무슨 일이 일어나는지 알고 싶었습니다.

솔직한 전제 조건

테스트 장치에는 클라우드 API 키가 없었습니다. 그래서 모든 것을 Ollama를 통해 qwen3:1.7b 모델을 CPU만 사용하여 실행했습니다: Debian 13, 8 vCPU, GPU 없음. 이 모델은 프롬프트 처리에서 약 250 토큰/초, 생성에서 약 8 토큰/초의 성능을 보였습니다.

이는 공정한 벤치마크가 아닌 스트레스 테스트입니다. 1.7B 모델은 앱이 볼 수 있는 가장 취약한 설정입니다. 작동하지 않은 부분 중 일부는 모델 자체의 결함이며, 저는 어떤 부분이 그러했는지 밝힐 것입니다. 다른 문제들은 모델과 관계없이 발생했으며, 이들이 더 유용한 발견점들입니다.

테스트 프로젝트는 lukeed/clsx v2.1.1이었으며, 21개의 파일과 32개의 통과 테스트로 구성되어 있어 작은 모델도 시도해 볼 만한 크기였습니다.

설치: 빠르고 문제없이 진행됨

Linux에서는 AppImage, .deb 및 .rpm을 얻을 수 있습니다 (glibc 2.35 이상이므로 Ubuntu 22.04+, Debian 12+ 또는 Fedora 36+ 필요). 저는 libfuse2가 필요하지 않도록 마운트하는 대신 추출하는 방식을 사용하여 AppImage를 사용했습니다:

wget https://github.com/vastsa/PI-Desktop/releases/download/v0.16.1/PI-Desktop-0.16.1-linux-x86_64.AppImage
chmod +x PI-Desktop-0.16.1-linux-x86_64.AppImage
./PI-Desktop-0.16.1-linux-x86_64.AppImage --appimage-extract
...

측정한 내용:

• 다운로드: 164.8 MB이며, SHA-512는 latest-linux.yml과 일치했습니다.
• 추출: 약 3초가 소요되었고 디스크에 414 MB를 차지했습니다. ldd에 따르면 누락된 공유 라이브러리는 없었습니다.
• 첫 실행: 콜드(cold) 상태에서 1.56초, 웜(warm) 상태에서 0.54초 만에 창이 나타났습니다.
• 메모리: 에이전트가 아무 작업도 수행하기 전, Electron, host-core 및 sidecar 프로세스 전체에서 약 630 MB RSS를 사용했습니다.
• --no-sandbox는 추출된 트리의 chrome-sandbox가 setuid로 설정되어 있지 않기 때문에 필요했습니다. 설치된 패키지들은 이를 필요로 하지 않을 것입니다.

번들 내부에는 Chromium 150, Rust로 작성된 pi-desktop-host-core 바이너리, Pi sidecar, 8,344개의 모델을 담은 번들된 models.dev 카탈로그, 그리고 두 개의 내장 플러그인(브라우저 및 파일 관리자)이 포함되어 있습니다.

첫 화면은

Fetch list를 통해 모델과 제공업체를 확인했을 때 "Connected · 1 model found"라는 메시지가 표시되었습니다. 제공업체 목록도 길었습니다: 구독 로그인(Claude Pro/Max, ChatGPT, GitHub Copilot, SuperGrok/X Premium 등)과 약 30개의 API 키 제공업체가 있었습니다.

스모크 테스트("Reply with exactly: PI-Desktop smoke test OK")는 성공적으로 작동했지만, 1분 54초가 걸렸고, 저는 첫 실제 수치를 확인했습니다:

• 앱의 시스템 프롬프트와 도구 스키마가 약 4.1k 토큰을 차지했습니다 (Ollama가 4,717개의 프롬프트 토큰 중 4,098개를 캐시함).
• 작성기(composer)의 컨텍스트 링은 한 번의 상호작용 후 **96%**를 표시했는데, 이는 제가 Ollama에 16k 컨텍스트를 설정했고 커스텀 모델의 컨텍스트 창이 UI에서 "— —"로 표시되었기 때문입니다.
• 추론 설정(reasoning setting)은 프롬프트에 /think를 추가했습니다 (Qwen의 추론 스위치). 그리고 모델은 답변에서 이를 그대로 반영했습니다.

첫 번째 교훈: 로컬 모델을 추가할 때는 해당 모델의 Advanced 설정을 열고 컨텍스트 창(Context Window)을 직접 설정해야 합니다. 16k의 컨텍스트를 사용하면, 아무것도 입력하기 전에 이 장치(harness)가 그 사분의 일을 소모합니다.

Plan 모드: 작동했지만 계획은 허구였다

저는 clsx 폴더를 프로젝트로 열고, 스위치를 Plan으로 "Ask every time"을 설정한 뒤, 중첩 배열과 거짓 값(falsy values)에 대한 테스트를 계획하도록 요청했습니다.

작동 원리는 견고했습니다:

• 계획이 실제 파일, .pi/plan/add-nested-array-falsy-values-tests-for-clsx-20261007-1108.md (315 bytes)로 저장되었습니다.
• Open plan, Reject, **Approve (Ask)**가 표시된 계획 카드가 나타났고, 파일 관리자(File Manager) 창이 열리면서 마크다운 파일을 보여주었습니다.
• 채팅창은 자동으로 적절한 제목을 얻었습니다.

내용은 그렇지 않았다. 플랜(Plan)에서는 존재하지 않는 경로인 /work/clsx/tests에 테스트 파일을 추가하라고 지시했다. 실행 로그에는 “3 issues · 4 tools”가 표시되었는데, 검색 실패, 읽기 실패, 첫 번째 SubmitPlan 실패, 두 번째 성공으로 나타났다. 앱은 “Processed for 5m 19s”를 보고했지만, 프롬프트를 보내고 카드를 보는 데 걸린 실제 시간(wall-clock time)은 약 17분이었다. 컨텍스트 미터는 95%에 머물렀다.

이것은 대부분 모델의 문제였다. 컨텍스트의 4분의 1을 지침(instructions)으로 사용하는 1.7B 모델이 임의로 경로를 만들어낸 것이다. 하지만 그 주변 워크플로우(별도의 아티팩트, 명시적인 승인 게이트)는 더 강력한 모델 앞에 배치하고 싶은 바로 그런 부분이다.

Goal 모드: 권한 스위치가 스스로 변경되다

Goal 모드는 결과와 수용 기준(acceptance criteria)을 담은 .pi/goal/*.md 파일을 작성하고, 승인을 기다린 다음, 에이전트(Agent)로 전환하여 어떤 기준을 검증했는지 보고할 때까지 작업하도록 설계되었다.

나는 Goal에 도달하기 위해 모드 스위치를 두 번 클릭했다. 그러자 그 옆의 권한 스위치가 내가 건드리지 않았는데도

실패한 실행은 모델의 잘못입니다. 권한 전환과 중국어 제목 문제는 앱에서 발생하는 것이므로, 유지 관리자들에게 보고할 가치가 있습니다. 솔직히 말해서, 문서에는 Plan과 Goal이 '엄격한 읽기 전용 보안 프로필이 아닌 계약 모드(contract modes)'라고 명시되어 있기는 합니다. 그래도 모드를 전환할 때마다 해당 칩을 확인하는 것이 좋습니다.

Subagents: 유일하게 깔끔했던 성공 사례

PI-Desktop은 정의된 도구 세트를 가진 다섯 가지 내장 subagent를 제공합니다:

• Explorer: Read, Glob, Grep, Bash
• Code reviewer: Read, Glob, Grep (읽기 전용)
• Test runner: Read, Glob, Grep, Bash
• Fixer: Edit과 Write를 추가함
• UI designer: BrowserPreview, Edit과 Write를 추가함

사용자는 ~/.agents/subagents/에 마크다운 파일 형태로 자신만의 subagent를 추가할 수 있습니다(최대 16개). 위임(Delegation)은 백그라운드에서 실행되어 위임 ID를 반환하는 Task 도구를 사용하며, 이와 함께 TaskWait, TaskList, TaskStop이 존재하고 세션당 최대 10개를 사용할 수 있습니다. subagent는 Agent 모드에서만 작동합니다.

Agent 모드에서 저는

• UI에는 작은 위임 그래프가 그려졌습니다: Main agent → test-runner, "1 delegated task 조정 중".
• 권한 프롬프트는 명확하게 이것이 **"test-runner 서브 에이전트에서 요청됨"**이라고 표시했으며, 정확한 명령어(npm test)를 보여주고 **높은 위험(HIGH RISK)**으로 라벨링했습니다. 셸 명령을 실행하는 것은 플래그가 필요한 올바른 조치입니다.
• '허용(Allow)'을 한 번 거친 후, 서브 에이전트는 2분 44초 (3단계) 만에 완료되었습니다. 전체 과정은 5분 55초가 소요되었습니다.
• 결과는 exit 0, 32/32 통과였으며, 이는 제가 직접 셸에서 npm test를 실행했을 때 얻은 결과와 일치합니다.

서브 에이전트 자체의 기록(transcript)은 읽기 전용으로 표시된 사이드 패널에 열렸습니다("Subagents are driven by the main agent"). 그리고 채팅창 이름도 다시 "npm 테스트 성공"으로 변경되었습니다.

교훈: 작은 모델에게 좁고 명확하게 정의된 작업을 주면 시스템이 수행합니다. 하지만 개방형(open-ended) 작업을 계획하도록 요청하면 무너집니다.

모델과 관련 없는 두 가지 발견 사항

1. "OS 키체인"은 아직 완벽하지 않습니다. 랜딩 페이지와 README에는 자격 증명(credentials)이 OS 키체인에 저장된다고 나와 있습니다. 저는 Secret Service가 사용 가능한 상태로 gnome-keyring을 실행하고 Ollama provider를 저장했지만, 어떤 항목도 키링에 들어가지 않았습니다. 대신 두 개의 파일이 나타났습니다:

~/.pi-desktop/secrets/<sha>.bin    48 B   mode 644
~/.pi-desktop/secrets/.machine-key 32 B   mode 600

프로젝트 자체의 저장소 사양(storage spec)이 이를 설명합니다: 배포된 백엔드는 "host-core가 한 번 생성하고 옆에 보관하는 머신 키(machine key)로 암호화된 AES-256-GCM 파일 스토어"이며, OS 키체인 백엔드는 "현재 host-core나 Electron main이 구현하지 않은 것으로, 데이터 디렉터리를 읽을 수 있는 동일 사용자 프로세스도 비밀 정보를 복호화할 수 있다."는 것입니다. 사양은 이 점에 대해 정직합니다. 마케팅 자료가 그렇지 않습니다. 만약 여기에 실제 클라우드 키를 넣는다면, ~/.pi-desktop 폴더를 민감한 정보로 취급해야 합니다.

2. 마우스를 움직일 때만 창이 다시 그려집니다. Xvfb/xfwm4 데스크톱 환경에서 타이머와 스트리밍 출력은 커서를 움직이기 전까지 멈춰 있었습니다. 이것이 제 헤드리스(headless) 설정에 국한된 문제일 수도 있지만, 긴 로컬 실행 시간을 더욱 길게 느껴지게 만들었습니다.

나머지 내용은 간략하게