나는 별생각 없이 슥 훑어보는 것만으로도 내 컴퓨터가 과부하 상태인지, 그리고 내가 실제로 의존하고 있는 4개의 백그라운드 서비스가 여전히 살아있는지 알 수 있기를 원했습니다. 작업 관리자 (Task Manager)는 직접 찾아 들어가야 합니다. 위젯은 데스크톱을 어지럽혔습니다. 그래서 나는 ClawMonitor를 만들었습니다. 화면 상단 가장자리에 고정된 슬림하고 프레임이 없으며 항상 위에 떠 있는 (always-on-top) 바입니다. 신스웨이브 (synthwave) 스타일로 디자인되었으며, CPU / RAM / GPU / 네트워크 / 디스크 상태를 한눈에 보여주고 — 다른 모니터는 하지 못하는 부분인 — 내 개발 스택 (dev stack)의 실시간 업/다운 상태를 보여줍니다. 이것은 ClawPorts와 같은 방식으로 구축된 네온 형제입니다.

그것은 무엇인가

ClawMonitor는 내 주 모니터 상단에 도킹된 단일 수평 스트립입니다. 왼쪽에는 CPU %, RAM %, GPU % 및 온도, 네트워크 처리량 (throughput), 디스크 사용량이 표시됩니다. 오른쪽에는 내 스택 — :18789의 로컬 게이트웨이, WSL, Docker, 그리고 :11434의 Ollama — 를 위한 색상 점들이 한 줄로 나열되어 있으며, 작동 중일 때는 초록색, 중단되었을 때는 흐릿하게 표시됩니다. 디자인은 전형적인 신스웨이브 (synthwave) 스타일입니다. 거의 검은색에 가까운 그리드 위에 시안 (cyan) / 마젠타 (magenta) / 보라 (purple) / 초록 (green) 네온 컬러가 적용되었으며, 전체적으로 Cascadia Code 폰트를 사용합니다.

바의 어디든 마우스를 올리면 3개의 타일로 구성된 패널이 아래로 슬라이드되어 내려옵니다: 코어별 CPU 바와 부하가 높은 상위 프로세스, 상세한 GPU 정보 (VRAM, 전력 소모, 팬 속도), WSL의 vmmem 공유를 분리하여 보여주는 RAM, 그리고 각 서비스의 포트와 상태를 명시하는 "Your Stack" 타일이 나타납니다. 무언가 한계치에 도달하면 — CPU 또는 GPU가 90%를 초과하거나, 온도가 80°C를 넘거나, 디스크 여유 공간이 하한선 아래로 떨어지거나, 게이트웨이가 다운되면 — 해당 섹션이 빨간색으로 깜빡입니다. 전체 시스템은 클릭 관통 (click-through) 방식이므로 아래에 있는 앱을 절대 가로막지 않으며, 작업 표시줄처럼 화면 공간을 예약하므로 최대화된 창이 바에 가려지는 대신 그 아래에서 시작됩니다.

이 프로젝트는 구축되어 공개되었으며 내 컴퓨터에 설치되어 있습니다. 저장소는 GitHub (MIT)에 있으며, 바를 실시간으로 상호작용하며 재현해 볼 수 있는 랜딩 페이지가 있습니다. v0.1.1 버전은 서명되지 않은 NSIS 설치 프로그램으로 제공됩니다.

어떻게 구축되었는가

다른 프로젝트들과 마찬가지로 동일한 루프를 따랐습니다. 제가 무엇을 만들지 결정하면, Claude가 페어 프로그래머 (pair programmer)로서 거의 모든 코드를 작성했습니다. 우리는 사양 (spec)을 브레인스토밍하고, 이를 마일스톤(milestones)에 따른 18개의 작업 계획으로 전환했으며, Claude는 별도의 리뷰어 패스 (reviewer passes)를 거치며 테스트 우선 (test-first) 방식으로 이를 구현했습니다. 저는 최종 빌드를 라이브로 실행해 본 후 승인했습니다. 사양과 계획은 docs/superpowers/에 저장되어 있습니다.

기술 스택은 **Electron + systeminformation**이며, 테스트 스위트 (test suite)로는 Vitest (35개의 유닛 테스트)를 사용합니다. 아키텍처는 Electron 프로세스 경계(process boundary)를 기준으로 엄격하게 분리되어 있습니다. 메인 프로세스는 **모듈형 수집기 오케스트레이터 (modular collector orchestrator)**입니다. cpu, memory, gpu, disk, network, sensors, stack과 같은 작은 리더(readers)들이 각각 정규화된 슬라이스 (normalized slice)를 반환합니다. 렌더러 (renderer)는 프레임이 없는 투명한 페이지로, IPC를 통해 전달된 최신 스냅샷 (snapshot)만을 사용하여 바 (bar)와 패널을 순수하게 그립니다. UI 자체에는 어떠한 로직도 포함되지 않으며, 하나의 데이터 객체를 보여주는 뷰 (view) 역할만 수행합니다.

수집기들은 두 개의 계층으로 실행됩니다. 빠른 계층 (fast tier) (기본 2초)은 비용이 적게 드는 부하 지표 (load metrics)를 폴링 (polling)합니다. 느린 계층 (slow tier) (기본 8초)은 스택 상태 (stack health)를 폴링합니다. 4개의 서비스가 작동 중인지 확인하는 작업은 HTTP 프로브 (probes)와 tasklist를 포함하므로 초당 두 번씩 실행할 필요가 없기 때문입니다. 모든 수집기는 타임아웃 (timeout)으로 감싸져 있어, 하나의 느리거나 실패한 리더가 나머지 작업을 절대 차단할 수 없습니다. 실패한 리더는 해당 슬라이스를 null로 강등시키며, 병합된 스냅샷은 그대로 진행됩니다. 그 mergeSnapshot 단계는 의도적으로 관대하게 설계되었습니다. 실패한 리더는 null 필드와 errors 맵의 항목이 될 뿐, 전체 바를 빈칸으로 만드는 예외 (exception)를 발생시키지 않습니다.

흥미로운 결정들

클릭 통과(click-through) 창은 호버(hover) 이벤트를 받지 못하므로, 호버 패널은 메인 프로세스(main process)에서 제어됩니다. 바(bar)는 setIgnoreMouseEvents(true)로 설정되어 클릭이 아래에 있는 요소로 그대로 통과합니다. 이는 항상 떠 있는 오버레이(always-on overlay)에 정확히 필요한 동작이지만, 동시에 DOM이 mouseenter를 절대 감지할 수 없음을 의미합니다. 따라서 이 패널은 CSS 호버 방식이 아닙니다. 메인 프로세스는 120ms마다 screen.getCursorScreenPoint()를 폴링(polling)하여 커서가 바 위에 있는지 판단하고, IPC를 통해 렌더러(renderer)에 패널을 열거나 닫으라고 명령합니다. 창을 클릭 통과 상태로 만드는 순간 명확한 메커니즘을 사용할 수 없기 때문에, 호버 동작을 수동으로 재구현한 것입니다.

화면 공간을 예약하는 것은 Win32 호출이며, 주의하지 않으면 누수(leak)가 발생합니다. 최대화된 앱이 바에 가려지는 대신 바 아래에 위치하도록 하기 위해, ClawMonitor는 Windows AppBar로 등록됩니다. 이를 위해 shell32의 SHAppBarMessage를 사용하는데, Electron API가 존재하지 않기 때문에 koffi FFI 라이브러리를 통해 접근합니다. 이 과정에서 상단 34px(물리 픽셀 기준이므로 디스플레이의 스케일 인자(scale factor)를 곱해야 함)을 예약합니다. 함정은 다음과 같습니다. 앱이 강제 종료되거나 충돌하면 Windows는 해당 예약 공간을 회수하지 않으며, 단순하게 재실행할 경우 두 번째 예약이 그 위에 쌓이게 됩니다. 즉, 34px이 68px이 되고, 결국 모든 화면 상단에 점점 커지는 빈 공간이 생기게 됩니다. 해결책은 윈도우 핸들(window handle)을 디스크에 유지하고, 시작 시 새로운 예약을 등록하기 전에 이전 예약을 제거하여 재시작 시 스스로 복구(self-heals)되도록 하는 것입니다. (강제 종료된 개발 빌드는 별도로 설치된 복사본과 상태를 따로 유지하므로 여전히 누수가 발생할 수 있지만, 이는 한 줄의 SystemParametersInfo 작업 영역(work-area) 리셋으로 복구 가능합니다.)

Windows는 일반 앱으로부터 CPU 온도를 숨깁니다. 제 환경에서는 systeminformation이 CPU 패키지 온도(CPU package temp)를 단순히 읽을 수 없습니다. ACPI 센서가 null을 반환하기 때문입니다. 솔직한 답변은 커널 수준의 센서 드라이버(kernel-level sensor driver)가 필요하다는 것입니다. 그래서 ClawMonitor의 sensors 수집기(collector)는 **LibreHardwareMonitor (LHM)**로부터 데이터를 읽습니다. 만약 원격 웹 서버를 켠 상태로 LHM을 실행하면, 수집기가 localhost:8085/data.json에서 데이터를 가져와 CPU 코어 온도를 파싱(parse)합니다. LHM이 실행 중이지 않으면 해당 필드는 그냥 숨겨지며 나머지 기능은 정상 작동합니다. GPU 온도는 쉬운 사례입니다. systeminformation이 별도의 드라이버 없이도 즉시 반환하기 때문입니다(내부적으로 nvidia-smi를 호출합니다). 저는 가짜 숫자를 보여주느니 차라리 솔직하게 "CPU 온도 없음"이라고 표시하는 쪽을 택하겠습니다.

개발 스택(dev-stack) 타일은 이 프로젝트가 존재하는 이유 그 자체입니다. 일반적인 모니터는 시스템이 바쁘다는 것만 알려줍니다. 하지만 왜 바쁜지 — 즉, 로컬 게이트웨이(gateway)가 죽었는지, 혹은 WSL의 vmmem이 RAM을 잡아먹고 있는지 — 는 알려주지 못합니다. stack 수집기는 각 서비스에 대해 고유한 방식으로 조사합니다. 게이트웨이와 Ollama에는 HTTP GET 요청을 보내고, Docker에는 docker ps를 사용하며, tasklist 필터를 통해 vmmem / vmmemWSL 프로세스를 합산하여 WSL의 실제 메모리 점유율(memory footprint)을 보여줍니다. 네 가지의 이질적인 상태 확인(health checks) 작업이 동일한 상/하(up/down) 형태의 데이터로 정규화되어 바(bar)에 점(dots)으로 렌더링됩니다. 이것이 차별점입니다. 단순히 실리콘(silicon)을 감시하는 것이 아니라, 스택(stack)을 감시하는 것입니다.

출시 사항

v0.1.1이 빌드, 테스트 및 설치되었습니다. 이 바(bar)는 제 메인 모니터 상단에 실시간으로 렌더링되며, 안정적인 CPU / RAM / GPU+온도 / 네트워크 / 디스크 정보와 함께 WSL / 게이트웨이 / Docker / Ollama 점들을 표시합니다. 커서 추적에 따라 호버 패널(hover panel)이 아래로 슬라이드되며, 경계값(redline)에 도달하면 알림이 깜빡입니다. AppBar는 공간을 확보하며 재시작 시에도 스스로 복구(self-heals)됩니다. 이 제품군은 수집기, 병합/타임아웃 오케스트레이션(merge/timeout orchestration), 알림 로직 및 설정을 포함하여 35개의 단위 테스트(unit tests)를 거쳤습니다. GitHub에서 MIT 라이선스로 공개되어 있으며, 랜딩 페이지, 기여자 문서(contributor docs), 그리고 Releases 섹션에 서명되지 않은 NSIS 설치 파일이 포함되어 있습니다.

솔직한 주의 사항을 말씀드리자면: 설치 프로그램에 아직 코드 서명 (code-signing)이 되어 있지 않아, 처음 실행 시 SmartScreen 경고가 발생합니다 (서명 작업은 할 일 목록에 있습니다). 또한 이 프로젝트는 Windows 전용입니다. Electron과 systeminformation 기반은 크로스 플랫폼 (cross-platform)이지만, AppBar와 WSL 타일은 플랫폼별 작업이 필요하므로 Linux 포팅은 현실적이지만 아직 시작되지 않았습니다. 그리고 v1 버전은 읽기 전용 (read-only)입니다. 스택을 보여주기는 하지만, 아직 바 (bar)에서 서비스를 시작하거나 중지할 수는 없습니다. 서비스 제어 기능과 히스토리 그래프 (history graphs) 추가가 v1.1의 위시리스트 (wishlist)입니다.

이 글은 이러한 방식으로 구축된 프로젝트들에 대한 진행 중인 시리즈의 일부입니다. 전체 목록은 projects page에서 확인할 수 있습니다.