코딩 에이전트를 쓰는 방식이 빠르게 파편화되고 있다. Claude Code, Codex, Cursor, OpenCode, Grok 등 각 도구가 저마다의 CLI와 세션 관리 방식, 출력 형식을 갖고 있어, 여러 에이전트를 오가는 개발자는 터미널 창과 로그를 계속 분산해서 관리해야 한다. 최근 Show HN에 공개된 '와쿠(Waku)'는 이 문제를 정면으로 겨냥한다. 사용자가 이미 로컬에 설치해 둔 에이전트 CLI들을 하나의 네이티브 앱 안으로 끌어모아, 세션과 대화 기록, 도구 실행 내역, 체크포인트를 단일 타임라인에서 다루도록 하는 것이 핵심이다.
왜 네이티브인가
와쿠가 가장 먼저 내세우는 차별점은 구현 스택이다. 이 앱은 러스트(Rust)와 GPUI로 작성됐다. GPUI는 코드 에디터 Zed를 떠받치는 GPU 가속 UI 프레임워크로, 와쿠는 이를 통해 즉각적인 실행, 수년치 대화 기록을 훑어도 끊기지 않는 스크롤을 구현했다고 설명한다. 명시적으로 언급되는 대비 대상은 일렉트론(Electron)이다. 많은 개발자 도구가 웹 기술 기반의 일렉트론으로 만들어지면서 무거운 메모리 사용과 느린 반응 속도라는 비판을 받아 왔는데, 와쿠는 처음부터 네이티브 경로를 택해 이 지점을 회피하려 한다.
에이전트를 연결하는 방식도 단순 화면 캡처나 텍스트 스크래핑이 아니다. 와쿠는 각 에이전트를 그 도구가 가진 가장 견고한 네이티브 인터페이스로 붙인다. stream-json, JSON-RPC, 실시간 이벤트 스트림 같은 것들이다. 그리고 이렇게 서로 다른 형식으로 들어온 데이터를 하나의 공급자 중립(provider-neutral) 모델로 정규화한다. 사용자 입장에서는 어떤 에이전트를 쓰든 동일한 타임라인 형태로 세션과 도구 활동을 보게 되는 셈이다.
코드와 대화를 함께 되돌리는 체크포인트
실무적으로 눈여겨볼 기능은 체크포인트다. 와쿠는 프롬프트를 보낼 때마다 작업 트리(working tree)를 숨겨진 git ref 아래에 체크포인트로 저장한다. 덕분에 코드와 공급자 쪽 대화를 함께 되돌릴 수 있다. 단순히 채팅 로그만 이전 상태로 돌리는 것이 아니라, 그 시점의 코드 변경과 에이전트 대화 맥락을 한 묶음으로 롤백한다는 점이 차이다. 에이전트가 여러 파일을 건드린 뒤 방향이 어긋났을 때, 실험적 변경을 손쉽게 취소하고 이전 지점에서 다시 시도하려는 용도로 유용할 만하다.
조작 흐름은 키보드 중심으로 설계됐다. ⌘N으로 세션을 시작하고, 에이전트가 작업하는 동안 ⏎로 후속 프롬프트를 대기열에 넣으며, ⌘⏎로 진행 중인 턴에 개입해 방향을 바꾸고, Escape로 중단한다. 모든 제어가 마우스 없이 동작한다는 점을 강조하는데, 에이전트를 하루 종일 붙잡고 반복적으로 지시를 주고받는 워크플로에서는 이런 키보드 우선 설계가 실제 생산성에 직결된다.
전부 로컬에 남는다는 약속
프라이버시 측면의 설계도 분명하다. 프로젝트와 세션, 대화 기록, 공급자 ID가 모두 사용자 디스크에 저장되며, 계정 생성이나 텔레메트리, 와쿠 클라우드가 사용자와 에이전트 사이에 끼어들지 않는다. 즉 와쿠는 에이전트를 대신 실행해 주는 중개 서비스가 아니라, 사용자가 이미 갖고 있는 CLI를 구동하는 로컬 프런트엔드에 가깝다. 코드와 대화가 외부 서버를 거치지 않는다는 점은 사내 코드베이스를 다루는 팀이나 규정 준수가 중요한 조직에서 특히 의미가 있다. 배포는 서명·공증을 거쳤고 Sparkle을 통해 바이너리 델타 방식으로 자동 업데이트된다.
다만 공개된 정보만으로는 판단을 유보해야 할 부분도 있다. 원문에서 확인되는 지원 대상과 기술적 세부는 위에 정리한 것이 전부이며, 가격 정책이나 지원 운영체제, 성능 수치, 실제 사용자 규모 같은 정보는 드러나 있지 않다. 특히 GPUI와 Sparkle, ⌘ 키 조합 언급으로 미루어 macOS 중심임을 짐작할 수 있으나 이는 명시되지 않은 추정이다. 여러 에이전트를 하나의 정규화된 모델로 묶는 접근은 각 도구의 고유 기능이 얼마나 손실 없이 노출되는지, 그리고 에이전트 CLI들이 업데이트될 때 정규화 계층이 얼마나 잘 따라가는지에 성패가 달려 있다. 여러 코딩 에이전트를 병행하는 개발자라면, 자신이 쓰는 도구가 지원 목록에 있는지와 로컬 우선 설계가 팀 정책에 맞는지를 기준으로 한 번쯤 시험해 볼 만한 시도다.