Plandex 리뷰: 대규모 다단계 작업을 위해 구축된 터미널 기반 AI 코딩

대부분의 AI 코딩 도구들은 인너 루프(inner loop), 즉 한 줄의 자동 완성, 함수 리팩토링(refactor), 커서 아래의 테스트 수정과 같은 작업에 맞춰 조정되어 있습니다. Plandex는 다른 곳을 목표로 합니다. 이는 사용자가 맡기는 작업이 여러 파일과 여러 단계에 걸쳐 있다는 가정하에 구축된 오픈 소스(open-source) 기반의 터미널(terminal) 에이전트입니다. 이는 단 한 번의 채팅 턴(chat turn)으로는 중간에 무너져 버릴 법한 종류의 작업입니다.

우리는 이 설계가 실제로 유효한지, 아니면 "대규모 작업"이라는 말이 단순히 프레이밍(framing)에 불과한지 확인하기 위해 실제 다중 파일 변경 작업에 Plandex를 실행하며 시간을 보냈습니다. 요약하자면, 모델을 둘러싼 구조가 곧 제품이며, 그 구조가 유용한 실행과 통제 불능의 실행을 가르는 차이점입니다.

Plandex가 실제로 다르게 수행하는 방식

Plandex는 Go 언어로 작성된 CLI(Command Line Interface)로, 단일 바이너리(binary)로 설치하여 프로젝트 디렉토리 내부에서 구동합니다. 에디터도, GUI 패널도 없습니다. 사용자는 터미널에 머물러 있고 에이전트는 사용자의 레포지토리(repo)를 대상으로 작업합니다.

핵심 아이디어는 **누적 디프 샌드박스(cumulative diff sandbox)**입니다. Plandex에 작업을 주면, 파일을 제자리에서 직접 수정하지 않습니다. 대신 별도의 샌드박스(sandbox)에서 제안된 변경 사항을 구축하며, 여러 단계에 걸쳐 디프(diff)를 누적합니다. 사용자는 전체 세트를 검토한 다음, 만족스러우면 한 번의 동작으로 워킹 트리(working tree)에 적용하거나, 거절하고 계속 반복할 수 있습니다. 이러한 분리는 생각보다 훨씬 중요합니다. 디스크에 직접 쓰는 채팅 에이전트는 모든 수정 사항을 일일이 감시하게 만들지만, Plandex는 모델이 10단계를 수행하게 한 뒤 검토 가능한 결과를 사용자에게 전달합니다.

그 위에는 **버전 관리되는 플랜(version-controlled plans)**이 자리 잡고 있습니다. 모든 플랜은 자체적인 히스토리(history)를 가집니다. 이전 상태로 되돌리거나(rewind), 다른 접근 방식을 시도하기 위해 플랜을 브랜치(branch)하고 비교할 수 있습니다. 만약 모델이 6단계에서 잘못된 경로로 빠진다면, 처음부터 다시 시작하거나 수동으로 수정을 되돌리는 대신 5단계로 되돌리면 됩니다. 이것이 긴 작업을 생존 가능하게 만드는 기능입니다. 대규모 작업은 옆길로 새기 마련이며, 그 옆길로 새는 비용이 보통 에이전트 기반 코딩(agentic coding)을 망가뜨리는 주범이기 때문입니다.

컨텍스트 관리(Context management)는 세 번째 기둥입니다. Plandex는 파일, 디렉토리 또는 URL을 플랜의 컨텍스트에 명시적으로 로드할 수 있게 해주며, 무엇이 로드되었는지 추적합니다. 이를 통해 모델이 대규모 코드베이스의 일부를 추측하는 대신, 정확한 코드 조각을 바탕으로 작업할 수 있도록 합니다. 사용자가 에이전트가 볼 내용을 직접 결정하므로, 관련성(relevance)과 토큰 비용(token cost)을 모두 제어할 수 있습니다.

Plandex는 진정한 오픈 소스(MIT 라이선스)이며 셀프 호스팅(self-hostable)이 가능합니다. 자체 인프라에서 서버를 실행하여 코드베이스를 제3자 서버에 전혀 노출하지 않을 수도 있고, 직접 운영하기를 원치 않는다면 호스팅된 Plandex Cloud를 사용할 수도 있습니다. 네트워크 외부로 코드를 반출할 수 없는 팀에게 셀프 호스팅 경로는 부가적인 기능이 아니라 핵심적인 특징입니다.

워크플로우에서의 위치 — 그리고 적합하지 않은 경우

Plandex는 평소라면 기피했을 작업에서 최고의 성능을 발휘합니다. 수십 개의 파일에 걸쳐 패턴을 마이그레이션하거나, API 레이어, 데이터 레이어, 테스트를 동시에 건드리는 기능을 스캐폴딩(scaffolding)하거나, 형태는 정해져 있지만 타이핑하기 지루한 보일러플레이트(boilerplate)를 연결하는 작업 등이 이에 해당합니다. 사용자는 결과물을 설명하고 관련 컨텍스트를 로드하기만 하면 됩니다. 그러면 Plandex는 작업 내용이 브랜치에 반영되기 전에 사용자가 감사(audit)할 수 있는 디프(diff)를 축적합니다.

반면, 긴밀한 이너 루프(inner loop) 작업에는 덜 매력적입니다. 타이핑하는 동안 1초 미만의 자동 완성(completions)을 원한다면 에디터 네이티브(editor-native) 도구가 더 적합합니다. Plandex의 '검토 후 적용(review-then-apply)' 모델은 작업 규모가 그 비용을 정당화할 만큼 충분히 클 때만 이득이 되는 마찰(friction)을 발생시키기 때문입니다. 이 두 방식은 경쟁 관계가 아니라 상호 보완적입니다. 많은 개발자가 라인 단위의 작업에는 에디터 어시스턴트를 유지하고, 작업이 플랜(plan), 샌드박스(sandbox), 그리고 되돌리기(rewind) 버튼이 중요해지는 임계점을 넘어서면 Plandex를 찾습니다.

자율성(autonomy)은 설정이 가능하며, 이는 올바른 결정입니다. 단계 사이에 사용자의 입력을 기다리는 더 직접적인(hands-on) 모드로 실행하거나, 더 긴 체인(chains)을 스스로 실행할 수 있도록 더 많은 재량권을 부여할 수 있습니다. 설정을 느슨하게 할수록 모델이 여러 단계에 걸쳐 경로를 이탈하지 않고 잘 따라올 것이라고 더 많이 신뢰해야 하며, 경로 이탈(drift)을 잡아내기 위해 마지막 단계의 차이점 검토(diff review)에 더 많이 의존하게 됩니다.

자율적인 다단계 실행은 토큰을 빠르게 소모하며, 비용은 로드하는 컨텍스트(context)의 양과 플랜(plan)이 수행하는 단계 수에 따라 비례하여 증가합니다. 프런티어 모델(frontier model)을 사용하여 대규모 작업에 에이전트(agent)를 투입하기 전에, 먼저 작은 범위의 작업을 실행하여 보정(calibrate)하십시오. 누적된 차이점(cumulative diff)은 여러분의 안전망입니다. 적용하기 전에 반드시 실제로 읽어보십시오. 10개의 파일을 자신 있게 다시 작성한 에이전트는, 10개의 파일을 자신 있게 잘못 작성할 수도 있는 에이전트입니다.

만약 여러분이 에디터 중심의 어시스턴트(editor-first assistant)를 사용해 왔고, Plandex를 무거운 작업(heavy lifting)을 위해 추가하면서도 빠른 내부 루프(inner loop)를 유지하고 싶다면, Cursor와 같은 도구가 이러한 종류의 터미널 에이전트와 자연스럽게 결합됩니다.

가격, 모델, 그리고 셀프 호스팅 (Pricing, models, and self-hosting)

Plandex는 모델에 구애받지 않습니다(model-agnostic). Anthropic의 Claude, OpenAI, 그리고 OpenRouter를 통해 접근 가능한 기타 여러 제공업체와 함께 작동하므로, 특정 벤더의 모델이나 특정 벤더의 청구서에 종속되지 않습니다. 서로 다른 역할에 서로 다른 모델을 지정할 수 있는데, 이는 플래닝(planning)에는 강력한 모델을 사용하고 일상적인 단계에는 더 저렴한 모델을 사용하고 싶을 때 유용합니다.

도구 자체가 오픈 소스(open source)이기 때문에 비용 구조는 두 가지로 나뉩니다. 소프트웨어는 무료입니다. 여러분은 모델 추론(model inference) 비용(본인의 API 키 사용)을 지불하며, 셀프 호스팅(self-hosting) 대신 호스팅된 서버를 사용하는 경우 선택적으로 Plandex Cloud 비용을 지불합니다. 셀프 호스팅을 한다는 것은 본인의 키를 제공하고 서버를 직접 실행한다는 의미입니다. 즉, 사용자당 플랫폼 수수료 없이 본인의 인프라와 추론 비용만 발생합니다. 이로 인해 총 비용은 고정된 구독료가 아니라, 얼마나 많이 실행하는지와 어떤 모델을 선택하는지에 따라 결정되는 함수가 됩니다.

실질적인 시사점은 다음과 같습니다: Plandex의 가격 모델은 제어권을 원하는 개발자들에게 보상을 제공합니다. 사용자는 코드가 어디에서 실행될지, 어떤 모델이 코드를 볼지, 그리고 에이전트(agent)가 어느 정도의 자율성을 가질지를 직접 결정합니다. 이는 폐쇄적인 SaaS 어시스턴트(SaaS assistant)와는 다른 거래 방식이며, Plandex가 타겟으로 하는 정확한 대상, 즉 제어권을 포기하지 않으면서도 구조화된 환경을 원하는 대규모의 민감한 다단계 작업을 수행하는 사람들에게 적합한 거래입니다.

Plandex는 자동 완성(autocomplete) 전쟁에서 승리하려는 것이 아닙니다. 이들은 에이전트 기반 코딩(agentic coding)의 어려운 점이 수정 사항을 생성하는 것이 아니라, 긴 작업 과정 전반에 걸쳐 그 수정 사항들을 관리하는 것이라고 확신하고 있습니다. 그리고 샌드박스(sandbox), 버전 관리되는 계획(version-controlled plans), 명시적인 컨텍스트 처리(explicit context handling)는 모두 이 확신을 뒷받침하기 위해 존재합니다. 만약 여러분의 고충이 채팅창으로는 감당할 수 없는 대규모의 다중 파일 작업이라면, 실제로 시도해 볼 가치가 있습니다.