← 주요 프로젝트← Key projects

오픈 소스 개발 도구

OPEN SOURCE DEVELOPER TOOL

Schutz

Schutz

AI의 작업 과정과 코드 변경을 확인하는 데스크톱 편집기입니다. 변경을 줄 단위로 검토하고 수락하거나 되돌릴 수 있습니다.

A desktop editor for following AI actions and reviewing code changes. Changes can be accepted line by line or rolled back.

ELECTRONREACTMONACOTYPESCRIPTMCP
담당 작업Work involved

편집기 UI, AI 작업 실행과 변경 검토, 앱 패키징

Editor UI, AI execution, change review and app packaging

현재 상태Current status

주요 편집 기능과 설치본 제공 · 확장 API와 코드 서명 보완 필요

Core editor and installers available; extension API and code signing need further work

01

프로젝트 개요

Schutz의 제품 문제와 핵심 경험

Schutz는 AI의 작업 과정과 파일 변경을 확인하는 데스크톱 코드 편집기다. 사용자는 에이전트가 읽는 파일과 변경 이유를 보고, 수정한 줄을 수락·거절하거나 작업 전체를 되돌릴 수 있다.

네 가지 핵심 경험

  • 편집 내용을 타이핑처럼 재생하고 변경 라인에 짧은 glow를 표시한다.
  • 변경 이유가 있는 diff와 줄 단위 accept/reject를 제공한다.
  • Agent의 계획, 현재 단계와 tool 호출을 실시간 패널에 표시한다.
  • 여러 파일이 바뀔 때 상태와 변경량을 한 화면에서 보여준다.

제품 범위

Electron, React와 Monaco 기반 자체 편집기에 터미널, Git, LSP, DAP, Open VSX 확장과 MCP host를 통합한다. Claude, OpenAI 계열과 로컬 서버를 교체 가능한 provider 계약 뒤에 둔다.

현재 상태: 크로스플랫폼 설치본과 주요 편집 경험이 구현되었다. 아직 얇은 확장 API와 코드 서명 같은 한계는 별도로 공개한다.

01

Overview

Product problem and core experience of Schutz

Schutz is a desktop code editor that shows AI actions and file changes. Users can see which files an agent reads and why it proposes a change, accept or reject individual lines, and roll back a complete turn.

Four core experiences

  • Replay edits like typing and briefly glow changed lines.
  • Present rationale-aware diffs with per-line acceptance.
  • Stream agent plans, current state and tool calls into an activity panel.
  • Keep multi-file changes and their status visible in one overview.

Product scope

An Electron, React and Monaco editor integrates terminal, Git, LSP, DAP, Open VSX extensions and an MCP host. Claude, OpenAI-family and local servers sit behind replaceable provider contracts.

Current status: cross-platform packages and the core editing experiences are implemented. Thin extension APIs and unsigned installers remain documented limitations.

02

아키텍처

자체 렌더러, Agent, Provider와 도구의 연결 구조

1. 프로세스와 권한 경계

Electron main process가 workspace 파일, PTY, Git과 운영체제 기능을 소유하고 context-isolated bridge가 허용된 IPC만 renderer에 노출한다. React renderer는 shell, panel과 Agent activity를, Monaco는 text model·selection·decoration을 담당한다. 이 경계는 웹 콘텐츠가 Node 권한을 직접 얻지 못하게 한다.

2. Provider 정규화

Claude, OpenAI와 local model adapter는 서로 다른 streaming 응답을 text, reasoning, plan, tool call, edit, usage와 error event로 정규화한다. renderer는 vendor payload 대신 공통 event stream을 구독하고, provider registry가 model capability와 credential 상태를 Orchestrator에 전달한다.

3. Agent 실행 루프

Orchestrator가 conversation turn과 budget을 시작하고 model event를 순서대로 기록한다. tool call은 permission과 schema를 확인한 뒤 Workspace Tools queue로 보내며 결과를 다음 model context에 다시 넣는다. cancel, timeout과 tool error도 terminal event가 되어 UI activity와 내부 상태가 어긋나지 않게 한다.

4. 검토 가능한 편집 트랜잭션

파일 제안은 즉시 저장하지 않고 base revision, range, replacement와 rationale을 가진 pending transaction으로 만든다. Monaco가 inline diff와 multi-file status를 표시하고 사용자가 accept 또는 reject한다. 적용 전 revision이 바뀌면 conflict로 중단하며 turn checkpoint가 묶인 변경을 되돌릴 수 있다.

5. 도구·확장·실패 경계

Workspace Tools가 files, search, terminal, Git, LSP/DAP와 MCP를 공통 contract로 감싼다. provider와 tool을 분리해 모델 교체가 편집기 핵심을 바꾸지 않고, MCP 실패가 기본 파일 편집을 중단시키지 않게 한다. 민감한 작업은 명시적 승인과 로그 가능한 activity를 거치며 부분 실패는 transaction을 적용 전 상태에 남긴다.

6. 프로세스·상태 소유권

Renderer는 탭·편집·검토 UI 상태를, Electron main은 파일·프로세스 권한과 IPC를, agent runtime은 provider 세션과 tool loop를 소유한다. checkpoint 계층은 변경 전 복구점을 별도로 보존해 AI 응답과 디스크 적용을 하나의 상태로 취급하지 않는다.

7. 성능·격리·복구

대형 diff, Monaco model 수, agent streaming과 터미널 출력이 renderer 압력을 만든다. 배치된 activity event, bounded log, 파일 잠금과 checkpoint 복원을 검증해야 하며 provider/MCP 실패가 기본 편집 기능으로 전파되지 않는 것이 핵심 fallback이다.

8. 보안·관측·기술 부채

Preload IPC allowlist, 도구 승인, workspace 경로 검증이 권한 경계를 만든다. crash policy와 activity log는 로컬 진단을 지원하지만 원격 telemetry·SLO는 미구현이다. .cjs main 모듈과 TypeScript renderer 사이 계약을 타입으로 생성하는 작업이 남아 있다.

02

Architecture

Connection between the renderer, agent, providers and tools

1. Process and permission boundary

The Electron main process owns workspace files, PTY, Git and operating-system capabilities. A context-isolated bridge exposes only allowed IPC to the renderer. React renders the shell, panels and agent activity, while Monaco owns text models, selections and decorations. Web content never receives direct Node authority.

2. Provider normalization

Claude, OpenAI and local adapters normalize different streams into text, reasoning, plan, tool-call, edit, usage and error events. The renderer consumes shared events rather than vendor payloads, and a provider registry gives the Orchestrator model capability and credential state.

3. Agent execution loop

The Orchestrator opens a conversation turn and budget, then records model events in order. Tool calls pass permission and schema checks before entering the Workspace Tools queue; results return to the next model context. Cancellation, timeout and tool errors become terminal events so visible activity and internal state converge.

4. Reviewable edit transactions

File proposals are not saved immediately. They become pending transactions containing base revision, range, replacement and rationale. Monaco renders inline diffs and multi-file status for accept or reject. A changed base revision creates a conflict instead of a blind write, while turn checkpoints support grouped undo.

5. Tool, extension and failure boundary

Workspace Tools wrap files, search, terminal, Git, LSP/DAP and MCP behind common contracts. Provider-tool separation allows model changes without editor-core changes and keeps an MCP failure from disabling basic editing. Sensitive operations require explicit approval and observable activity; partial failures leave transactions unapplied.

6. Process and state ownership

The renderer owns tab, editor and review UI state; Electron main owns filesystem, process permissions and IPC; the agent runtime owns provider sessions and the tool loop. Checkpoints preserve a separate pre-change recovery point so an AI response and a disk write are never one implicit state.

7. Performance, isolation and recovery

Large diffs, Monaco model count, agent streaming and terminal output can pressure the renderer. Batched activity events, bounded logs, file locks and checkpoint restore require validation; provider or MCP failure must not propagate into basic editing.

8. Security, observability and debt

The preload IPC allowlist, tool approval and workspace-path validation establish permission boundaries. Crash policy and activity logs support local diagnosis, while remote telemetry and SLOs are missing. Generating typed contracts between .cjs main modules and the TypeScript renderer remains debt.

구조와 데이터 흐름

Structure and data flow

도식을 누르면 크게 볼 수 있습니다. 구현 여부와 참고한 코드도 표시했습니다.

Select a diagram to enlarge it. Labels show implementation status and source files.

01
시스템 컨텍스트 · 신뢰 경계System context · trust boundaries개발자, Electron IDE, AI 제공자와 로컬 워크스페이스의 권한 경계입니다.Permission boundaries across developer, Electron IDE, AI providers and local workspace.
선택하면 전체 화면에서 세부 구조와 근거 번호를 볼 수 있습니다.Select to inspect the structure and evidence references full screen.
02
런타임 · 모듈 · 상태 소유권Runtime · modules · state ownershipRenderer, preload IPC, main process, agent runtime을 분리합니다.Separates renderer, preload IPC, main process and agent runtime.
선택하면 전체 화면에서 세부 구조와 근거 번호를 볼 수 있습니다.Select to inspect the structure and evidence references full screen.
03
핵심 사용자 흐름 · 요청 시퀀스Core user flow · request sequence프롬프트에서 도구 실행, diff 검토, 체크포인트까지의 에이전트 루프입니다.Agent loop from prompt through tool execution, diff review and checkpointing.
선택하면 전체 화면에서 세부 구조와 근거 번호를 볼 수 있습니다.Select to inspect the structure and evidence references full screen.
04
데이터 · 배포 · 보안 · 복구Data · delivery · security · recovery로컬 상태, 패키징, 비밀·권한, 크래시 정책을 연결합니다.Connects local state, packaging, secrets, permissions and crash policy.
선택하면 전체 화면에서 세부 구조와 근거 번호를 볼 수 있습니다.Select to inspect the structure and evidence references full screen.
03

기술적 결정

Schutz가 자체 렌더러와 관찰 가능한 편집을 선택한 이유

Code-OSS를 fork하지 않음

초기 설계는 확장 API의 시각적 한계를 해결하기 위해 Code-OSS fork를 고려했다. 조사 결과 앱이 이미 Electron + React + Monaco 자체 renderer를 갖고 있어 fork 유지 비용을 감수할 이유가 없었다. 현재 구조를 심화하는 쪽으로 결정을 수정했다.

Provider-agnostic 계약

특정 모델 SDK를 UI에 직접 연결하지 않고 공통 stream event로 정규화한다. 새 provider adapter 비용은 남지만 편집·계획·tool UI는 재사용된다.

제안과 파일 쓰기 분리

AI edit를 즉시 저장하면 빠르지만 사용자가 변경 경계를 잃는다. pending → accepted/rejected 트랜잭션을 적용해 human-in-the-loop를 기본값으로 삼았다.

관찰 가능성을 기본값으로

tool 호출과 계획을 숨기면 UI는 단순해지지만 실패 이유를 파악하기 어렵다. 진행 상태를 노출하고 autonomy policy로 자동 적용 범위를 조절한다.

03

Decisions

Why Schutz chose its own renderer and observable editing

Do not fork Code-OSS

The original design considered a Code-OSS fork to escape extension rendering limits. A code survey showed the application already owned an Electron, React and Monaco renderer, removing the reason for a fork and its upstream maintenance cost.

Normalize providers

Model SDKs do not connect directly to UI features. Provider output becomes a common stream-event contract. Adapter work remains, but edit, plan and tool interfaces are reused.

Separate proposals from writes

Immediate writes are fast but remove user control. The pending → accepted/rejected transaction model makes human review the default and gives undo a clear boundary.

Observable by default

Hiding tools and plans produces a simpler interface but makes failures opaque. Schutz exposes activity and uses an autonomy policy to decide which low-risk actions may apply automatically.

04

검증

Schutz의 자동 검사와 실제 한계

자동 검사

CI는 ide/에서 npm run typecheck, npm test, npm run build를 실행한다. type check는 전체 앱과 strict, noUncheckedIndexedAccess가 적용된 편집 엔진 영역을 별도로 검사한다. WorkspaceEdit는 생성·삭제·이름 변경 중 하나라도 안전하게 실행할 수 없으면 전체 작업을 중단하도록 설계되어 있다.

기능 검증

Phase 2 조사는 설계 문서의 네 가지 편집 경험을 실제 코드와 대조했다. extension event, decoration, active editor와 custom editor처럼 “호출은 되지만 화면에 반영되지 않는” 실패도 명시적으로 확인했다.

알려진 한계

  • 모델의 실제 token stream이 아니라 완성된 제안을 재생하는 경로가 남아 있다.
  • 일부 VS Code extension API와 debugger provider 계약은 완전하지 않다.
  • Windows 설치본은 아직 code signing이 없어 SmartScreen 경고가 표시될 수 있다.

전체 IDE 호환성을 단일 수치로 측정한 결과는 측정되지 않음이다.

04

Validation

Automated checks and explicit limitations

Automated checks

CI runs npm run typecheck, npm test and npm run build in ide/. Type checking covers the full application and a stricter editing-engine island using strict and noUncheckedIndexedAccess. WorkspaceEdit is all-or-nothing: if any create, delete or rename operation is unsafe, none is applied.

Feature verification

The Phase 2 survey maps the four promised editing experiences to code. It also records misleading cases where an extension call succeeds but cannot affect the visible editor, including event timing and decoration behavior.

Known limits

  • One path replays completed text instead of the provider’s live token stream.
  • Some VS Code extension and debugger-provider contracts remain incomplete.
  • Windows installers are not yet code-signed and may trigger SmartScreen.

A single compatibility percentage for the complete IDE surface is not measured.

05

로드맵

Schutz의 구현 완료 영역과 남은 확장

완료

  • Electron + React + Monaco 자체 편집기와 1·2·4분할 편집
  • 편집 재생, glow, ghost cursor, diff와 줄 단위 검토
  • Agent 계획·상태·tool timeline과 multi-file overview
  • Claude·Codex·OpenAI-compatible provider와 로컬 서버
  • Git, PTY terminal, LSP, DAP, Open VSX extension과 MCP host
  • Windows, macOS와 Linux 설치 패키지

진행 중

  • 코드베이스 indexing과 긴 프로젝트 context 품질
  • 실제 stream과 제안 승인 모델의 연결 방식 검토
  • extension compatibility의 얇은 영역 보강

계획

  • provider와 로컬 모델 연결 경험 개선
  • 팀 단위 세션 공유와 협업 흐름
  • installer 서명과 배포 신뢰성 강화

제외

Code-OSS fork는 현재 구조에서 명시적으로 제외한다. 자체 renderer로 달성 가능한 기능을 우선하며, upstream 전체를 추적하는 유지 비용을 만들지 않는다.

05

Roadmap

Completed capabilities and remaining Schutz work

Completed

  • Electron, React and Monaco editor with 1/2/4 split groups
  • Edit replay, glow, ghost cursor, diffs and per-line review
  • Agent plan, tool timeline and multi-file overview
  • Claude, Codex and OpenAI-compatible providers plus local servers
  • Git, PTY terminal, LSP, DAP, Open VSX extensions and MCP hosting
  • Windows, macOS and Linux packages

In progress

  • Codebase indexing and long-project context quality
  • Integration of true streaming with proposal approval
  • Coverage of thinner extension compatibility areas

Planned

  • Smoother provider and local-model setup
  • Team session sharing and collaboration
  • Installer signing and stronger delivery trust

Out of scope

A Code-OSS fork is explicitly excluded. The project will deepen its owned renderer instead of taking on full upstream maintenance.

확대 보기Expanded view

도식을 좌우로 이동하거나 확대해 세부 흐름을 확인할 수 있습니다.

Pan or zoom the diagram to inspect the detailed flow.