Work Radar — Local-first AI 워크플로우 콕핏

핵심 성과

개요

Work Radar는 개인 업무, 코드 리뷰, 로컬 worktree, 캘린더, 루틴, AI agent 세션을 한 화면 체계로 묶는 local-first 데스크톱 운영 콕핏이다. 일반적인 todo app처럼 "할 일 목록"을 정리하는 데서 멈추지 않고, 들어온 신호를 분류하고, 오늘의 시간 위에 배치하고, agent 실행을 추적하고, 주간 회고로 다시 접는 전체 루프를 제품으로 만든다.

각 화면은 신호 수집·시간 배치·agent 실행·governance·회고 중 하나의 책임을 맡고, 전체 흐름은 다시 다음 작업 사이클로 되돌아온다. 아키텍처는 Rust side-effect boundary와 React operating UI가 분리되어, 많은 integration을 다루면서도 사용자의 명시적 판단 게이트를 유지한다.

문제 정의

현대적인 개인 개발자의 업무는 한 도구로 들어오지 않는다. 캘린더 일정, GitHub PR, Notion 백로그, 로컬 worktree, Hermes 패널, Codex job, 루틴, 브레인덤프가 서로 다른 속도로 동시에 들어온다. 실제 병목은 자동화 부족보다 "지금 무엇을 봐야 하는지"를 잃는 데 있다.

Work Radar는 이 문제를 task manager가 아니라 운영면의 문제로 본다. 모든 일을 하나의 list로 평탄화하는 대신, 각 신호가 어떤 레일에 있어야 하는지 드러낸다.

• Capture Board는 들어온 신호를 Eisenhower matrix로 받는다
• Today는 신호가 오늘의 시간을 점유하게 만든다
• PR Radar·Worktree Diff는 코드 상태를 운영 위험으로 분리해 보여준다
• Jobs는 agent 실행을 bounded log로 남긴다
• Control Room은 자동 개발 시스템이 지금 실행 가능한지, 어디서 사람이 개입해야 하는지를 보여준다

Control Room · Boule Governance

Control Room은 Work Radar의 핵심이다. Boule Governance, 즉 자동 개발 구현 시스템을 단일 job queue가 아니라 운영 가능한 복잡계로 다룬다. 자동 개발은 spec → plan → task → session → handoff가 서로 연결되며 진행되는 event-sourced workflow이고, 여러 agent session과 worktree, human gate가 동시에 존재하면 상태는 쉽게 창발한다. Control Room은 그 창발 상태를 숨기지 않고 posture·readiness·vitals·flow graph로 접어낸다.

설계의 핵심은 ticker와 autonomy를 분리한 것이다. ticker는 app/operator가 제공하는 bounded heartbeat clock이고, autonomy level은 heartbeat가 돌 때 무엇을 허용할지 정하는 permission envelope이다. 따라서 tick_enabled=true와 autonomyLevel=manual은 모순이 아니라 "Clock on, autonomy manual — 사람 게이트 대기 중" 상태다.

안전 경계도 명확하다. snapshot은 read-only이고 repo path는 renderer 입력이 아니라 DB에서 resolve된다. ticker는 무한 daemon이 아니라 app-bound runner로, per-repo no-overlap lock과 timeout을 가진다. halted_decision·needs_human·stalled는 fail-closed로 attention latch를 켜고, 원인이 남아 있으면 다음 tick에서 다시 걸린다.

자동화 경계 — Calendar · MCP · Hermes

외부 연동은 모두 같은 원칙 아래 붙는다. 외부 agent와 협업 채널은 Work Radar의 판단을 대체하지 않는다.

• Google Calendar — Today/Routine의 시간 상태를 외부 캘린더와 맞추는 mirror surface다. 읽기는 ambient signal로 병합하되, 쓰기는 stage_calendar_write가 로컬 mirror를 먼저 갱신하고 pending_calendar_writes 큐에 넣는다. 백그라운드 SyncEngine이 bounded retry로 flush한다.
• MCP gateway — 내장 stdio MCP 서버의 write tool(wr_github_comment, wr_calendar_create_event 등)은 기본적으로 실행하지 않고 external_actions approval queue에 제안만 넣는다. token이나 raw credential은 MCP 표면에 노출되지 않는다.
• Hermes ACP — session/request_permission을 AskUserCard로 바꿔 사용자가 승인한 action만 즉시 실행 경로를 탄다. 그래서 Hermes의 확인 card가 human gate가 되고, 같은 결정을 두 번 묻지 않는다.

결과적으로 자동화는 timeout·max turns·cost cap·accept/reject 로그를 남기는 감사 가능한 운영 단위가 된다.

결정 레일에서 자동화를 빼다

이 제품에서 가장 중요한 선은 기능이 아니라 자동화가 들어갈 수 없는 곳이다. 신호는 자동으로 모이지만, 그것을 백로그·안건·일정·실행 작업으로 올리는 승격은 전부 사람이 한다. Codex는 결정 레일에 붙지 않고 제안 레일과 실행 레일에만 붙는다.

제안은 항상 게이트를 통과해야 한다. agent job이 성공하고 제안이 나오면 awaiting_approval로 멈추고, 사람이 편집·accept한 뒤에야 반영된다. accept조차 외부를 바꾸지 않는다 — 수락 기록은 로컬 SQLite에만 남고 GitHub·Notion 제출은 사람이 직접 한다. 샌드박스는 read_only와 workspace_write 둘뿐이고 danger_full은 아예 제공하지 않는다.

이 원칙 때문에 이미 만들던 기능을 들어내기도 했다. 앱 안에서 Codex가 백로그를 구현하고 push해 draft PR까지 여는 실행 레일(옛 Phase 10)을 폐기했다 — 외부 코딩 에이전트와 역할이 겹치는 데다 위험 대비 이득이 없었다. 만든 것을 지우는 판단도 설계의 일부로 기록에 남겼다.

핵심 메시지

Work Radar의 철학은 자동화의 양을 늘리는 것이 아니라, 판단이 필요한 것들을 사람이 다룰 수 있는 한 곳에 모으는 것이다. Capture Board는 흩어진 신호를 아이젠하워 매트릭스로 받고, Today는 그것이 실제 시간을 점유하게 만들며, PR Radar와 Worktree Diff는 코드 운영 위험을 분리해 읽게 한다. Jobs와 Control Room은 agent 실행의 현재성과 감사 trail을 남긴다.

그래서 이 앱은 AI가 일을 대신 해주는 도구가 아니라, AI가 만들어낸 상태까지 포함해 사람이 운영하는 cockpit에 가깝다. 자동화를 어디까지 허용할지가 아니라 어디에는 절대 넣지 않을지를 먼저 정한 것이 이 제품의 설계 기준이다.

동작 흐름

화면

기술 스택

• Tauri 2
• Rust
• SQLite
• Vite
• React
• TypeScript
• Tailwind v4
• shadcn/ui
• TanStack Query
• Zustand
• Google Calendar
• GitHub
• Notion
• Codex CLI
• Hermes ACP
• cmux
• MCP