Prism: AI 에디터가 위임(Delegate)할 수 있게 만들기

Bryan Barton 작성

개발자용 AI 툴링(tooling)이 점점 좋아지고 있지만, 많은 워크플로우(workflow)가 여전히 동일한 나쁜 형태를 띠고 있습니다:

프리미엄 모델에게 모든 것을 하라고 요구하는 것.

작업을 부여합니다. 저장소 규칙(repo rules)을 줍니다. 런북(runbooks)을 줍니다. 기술 문서(skill docs)를 줍니다. CI 출력값을 줍니다. Kubernetes 덤프를 줍니다. 이전 채팅 내역을 줍니다. 그러고 나서 모델이 유용한 것을 만들어낼 수 있을 만큼 충분히 집중력을 유지하기를 바랍니다.

그 방식은 작동하다가, 어느 순간 작동하지 않게 됩니다.

모델은 플래너(planner), 연구자(researcher), 셸 운영자(shell operator), 로그 판독기(log reader), 문서 스크래퍼(docs scraper), 코드 리뷰어(code reviewer), 그리고 최종 작성자(writer)가 됩니다. 매 턴(turn)마다 작업은 무거워집니다. 모든 답변은 더 많은 컨텍스트(context)를 뒤에 끌고 다닙니다.

Prism은 다른 형태를 시도하는 실험입니다:

프리미엄 모델을 오케스트레이터(orchestrator)로 유지하십시오. 좁은 범위의 작업은 로컬 전문가(local specialists)에게 넘기십시오.

문제는 단순히 토큰 비용만이 아닙니다

토큰 비용은 측정하기 쉬운 요소입니다. 컨텍스트(context)의 품질은 개발자가 실제로 체감하는 요소입니다.

메인 AI 세션에 모든 기술, 지침, 증거 데이터(evidence blob)가 가득 차게 되면, 당신은 두 번의 비용을 지불하게 됩니다:

• 프리미엄 모델이 필요하지 않았던 토큰에 대한 비용
• 제어하기 점점 더 어려워지는 대화에 대한 주의력(attention)

대부분의 에이전트 프레임워크(agent frameworks)는 스스로 새로운 오케스트레이터(orchestrator)가 됨으로써 이 문제를 해결하려 합니다. Prism은 그렇게 하지 않습니다.

Prism은 당신의 에디터가 이미 컨트롤 플레인(control plane)이라고 가정합니다. Cursor, Claude Desktop, 또는 어떤 MCP 호스트(host)라도 결정이 내려지는 위치에 그대로 머물 수 있습니다. Prism은 그 아래에서 위임 계층(delegation layer)으로 자리 잡습니다.

오케스트레이터가 도움을 요청합니다. Prism은 제약된 로컬 전문가(local specialist)를 실행합니다. 전문가는 압축된 요약본을 반환합니다. 오케스트레이터는 그 결과를 합성(synthesize)합니다.

스웜(swarm)도 없습니다. 대체 IDE도 없습니다. 거대한 숨겨진 워크플로우 엔진도 없습니다.

그저 작은 프롬프트(prompt)가 중요한 곳에 더 작은 프롬프트를 사용할 뿐입니다.

Prism이란 무엇인가

Prism은 로컬 Ollama에서 저장소 정의 전문가(repo-defined specialists)를 실행하기 위한 MCP 서버 및 CLI입니다.

각 전문가는 일반 텍스트로 구성됩니다:

• 에이전트 사양 (agent spec)
• 선택적 기술 (optional skills)
• 선택적 헌법 (optional constitution)
• 작업별 증거 (task-specific evidence)

그러한 사양(specs)은 사용자의 저장소(repo)에 존재합니다. 이는 다른 엔지니어링 산출물(engineering artifact)과 마찬가지로 검토, 변경, 버전 관리 및 벤치마킹(benchmarking)이 가능합니다.

Prism은 기본적으로 다음과 같은 분야의 전문가(specialists)를 포함합니다:

• GitHub PR 및 CI 분류 (triage)
• Kubernetes 진단 (diagnostics)
• Argo CD 및 Workflow 디버깅 (debugging)
• 문서(docs) 및 릴리스 노트(release-note) 조회
• 집중적인 Go 헬퍼 및 패키지 스캐폴딩 (scaffolding)
• 간단한 프론트엔드 구현 작업

이 패턴은 의도적으로 단순합니다:

1. 최상위 브리프(top-level brief)를 짧게 유지합니다.
2. 증거 집약적인(evidence-heavy) 하위 작업들을 위임(delegate)합니다.
3. 전문가(specialists)를 로컬에서 실행합니다.
4. 프리미엄 모델(premium model)에 압축된 요약본을 제공합니다.
5. 에디터-오케스트레이터(editor-orchestrator)가 최종 결정을 내리도록 합니다.

구체적인 예시

저는 작지만 실제적인 코딩 요청을 대상으로 벤치마크를 수행했습니다:

HTML, CSS, 바닐라 자바스크립트(vanilla JavaScript)를 사용하여 최소 기능의 싱글 페이지 투두(todo) 앱을 구축하세요. 사용자는 할 일을 추가하고, 완료 표시를 하고, 삭제할 수 있어야 하며, 할 일은 localStorage에 저장되어야 합니다. 또한 로컬 실행 방법이 포함된 README를 생성해야 합니다.

Prism이 없다면, 오케스트레이터(orchestrator)가 전체 작업 컨텍스트(context)를 직접 받게 됩니다.

Prism을 사용하면, 오케스트레이터는 집중된 부분들을 위임합니다:

• UI 구조
• localStorage + 투두 로직 (todo logic)
• README 지침
• 압축된 전문가 요약본으로부터의 최종 합성 (final synthesis)

실제 실행 결과는 다음과 같습니다:

모드	오케스트레이터 입력 (input)	오케스트레이터 출력 (output)
Prism 미사용	6,191 토큰 (tokens)	811 토큰 (tokens)
Prism 사용	363 토큰 (tokens)	1,072 토큰 (tokens)

이는 해당 작업에 대해 오케스트레이터 입력 토큰을 94.1% 감소시킨 결과입니다.

두 출력물 모두 동일한 품질 루브릭(quality rubric)을 통과했습니다: 필수 파일, localStorage 동작, 추가/완료/삭제 흐름, 그리고 README 지침을 모두 충족했습니다.

솔직한 경제성

이것은 투두 앱 하나가 기업의 비용을 수천 달러 절감한다는 주장이 아닙니다.

그렇지 않습니다.

현대의 API 가격 책정 체계에서 단일 소규모 코딩 프롬프트(prompt)는 저렴합니다. 흥미로운 점은 이 패턴이 반복적이고 컨텍스트 집약적인(context-heavy) 작업 전반에 걸쳐 복리로 적용될 때 어떤 일이 발생하는가 하는 점입니다.

실제 투두 벤치마크를 단위 작업량으로 사용하고, 프롬프트 사용량이 많은 개발자 한 명이 하루에 20개의 코딩 프롬프트를 보낸다고 가정하면:

모델	Prism 미사용 시 월간 비용	Prism 사용 시 월간 비용	월간 절감액	연간 절감액
gpt-5.5	$22.12	$13.60	$8.52	$102.24
...
위 모델 이름은 testdata/benchmarks/orchestrator-models.yaml에서 가져온 벤치마크 가격 프로필(OpenAI/Anthropic 리스트 요율 가정)이며, 고정된 하나의 워크로드 하에서 상대적인 경제성을 비교하는 데 사용되었습니다.

이 수치들 자체가 삶을 바꿀 정도의 엄청난 액수는 아닙니다. 하지만 이는 우리가 나아가고 있는 방향이 측정 가능하다는 증거입니다.

더 큰 승리는 아키텍처(Architectural) 측면에서 나타납니다:

• 오케스트레이터(Orchestrator)가 무관한 정보를 덜 보게 됩니다.
• 전문가(Specialists)가 작업 범위(Scope) 내에 머무를 수 있습니다.
• 워크플로(Workflows)가 반복 가능해집니다.
• 팀이 막연한 느낌(Vibes)으로 논쟁하는 대신 자신들의 작업을 벤치마크할 수 있습니다.

만약 실제 워크로드에 긴 CI 로그, 클러스터 상태(Cluster state), 런북(Runbooks), 장애 대응 채팅 기록(Incident chat history), 그리고 내부 문서가 포함되어 있다면, 작업당 회피되는 컨텍스트(Context)의 양은 이 투두(Todo) 벤치마크보다 훨씬 더 커질 것입니다.

MCP가 이를 실용적으로 만드는 이유

MCP는 AI 에디터가 외부 도구를 호출할 수 있는 표준화된 방식을 제공합니다.

이것이 중요한 이유는 Prism이 여러분이 상주하는 애플리케이션 자체가 될 필요가 없기 때문입니다. Prism은 여러분이 현재 사용 중인 애플리케이션이 호출하는 하나의 도구가 될 수 있습니다.

Cursor에서의 흐름은 다음과 같습니다:

1. Prism을 MCP 서버로 등록합니다.
2. 에디터에 집중된 하위 작업(Subtask)을 위임(Delegate)하도록 요청합니다.
3. Prism이 로컬 전문가(Local specialist)를 실행합니다.
4. Cursor가 압축된 결과를 전달받습니다.

정확한 Cursor 설정 방법은 docs/usage.md의 MCP 설정 블록(

• 로컬 우선 실행 (local-first execution)
• 저장소 네이티브 설정 (repo-native configuration)
• 명시적인 기술 및 헌법 (explicit skills and constitutions)
• MCP 호환성 (MCP compatibility)
• 벤치마크 가능한 토큰 및 비용 차이 (benchmarkable token and cost deltas)

마지막 항목이 중요합니다. Prism에는 변경 사항을 측정할 수 있는 벤치마크 고정 요소 (benchmark fixtures)가 포함되어 있습니다. 이 포스트의 수치는 수기로 작성된 마케팅용 계산이 아니라, 커밋된 벤치마크 데이터로부터 생성된 것입니다.

이것이 위치하는 곳

Prism은 작업이 반복 가능한 전문가적 형태를 가질 때 유용합니다:

• “실패한 이 CI 실행을 요약해줘”
• “이 롤아웃 (rollout)을 점검해줘”
• “이 Kubernetes 포드 (pod) 이벤트들을 분류해줘”
• “이 SDK 변경 사항에 관련된 문서를 가져와줘”
• “이 작은 헬퍼 함수를 구현해줘”
• “이 프론트엔드 작업을 UI, 로직, 그리고 README로 나눠줘”

위임 오버헤드 (delegation overhead)가 모델에게 직접 물어보는 것보다 더 비용이 많이 들 정도로 작업이 이미 충분히 작을 때는 유용성이 떨어집니다.

그것이 핵심입니다: Prism은 모든 것을 위임하는 것에 관한 것이 아닙니다. 오케스트레이터 (orchestrator)를 비대하게 만드는 부분들을 위임하는 것에 관한 것입니다.

시도해보기

git clone https://github.com/bryanbarton525/prism.git
cd prism
go install ./cmd/prism
...

그런 다음 이를 MCP 호스트에 연결하고 run_agent를 호출하세요.

하나의 워크플로 (workflow)로 시작하세요. 측정하세요. 도움이 된다면 계속 유지하세요.

이것이 Prism의 제안입니다:

당신의 AI 에디터를 교체하지 마세요. 그것을 더 가볍게 만드세요.