지난주 Block은 Buzz를 오픈 소스로 공개했습니다. 이는 AI 에이전트들이 인간 옆의 채널에 앉아 git, 워크플로우(workflows), 음성(voice)을 하나의 릴레이(relay)에서 사용하는 워크스페이스입니다. 이는 Apache-2.0 라이선스이며, 팀은 빠르게 움직이고, 그들의 VISION.md는 이례적으로 솔직합니다. 저를 멈추게 한 문장은 상태 테이블에 있었습니다. 워크플로우 승인 게이트(workflow approval gates)는 부분적으로 구축되었으며, "request_approval 단계에 도달하는 실행은 현재 Failed(실패)로 표시됩니다"라고 되어 있습니다. 그들은 심지어 그 공백에 WF-08이라는 이름까지 붙였습니다.

저는 코딩 에이전트를 위한 승인 게이트를 구축하는 데 수개월을 보냈기에, 자원이 풍부한 팀이 동일한 카테고리의 제품을 무료로 출시하는 것을 지켜보며 제가 더 일찍 깨달았어야 했던 무언가를 명확히 알게 되었습니다.

게이트는 범용화(commodity)되고 있습니다. 하지만 핸드오프(handoff)는 그렇지 않습니다.

새벽 2시의 문제

운영자의 노트북 덮개가 닫히는 순간, 에이전트가 긴 실행 과정의 중간에 있는 상황을 상상해 보십시오. 이는 가설이 아닙니다. 코딩 에이전트를 관리자 없이 실행한다면, 이는 흔히 일어나는 일입니다.

뻔한 답은 "클라우드 러너(cloud runner)가 이를 이어받는다"일 것입니다. 하지만 그 문장은 실제 엔지니어링 문제를 숨기고 있습니다. 어떻게 하면 정확히 하나의 머신이 해당 작업을 소유하도록 보장할 수 있을까요?

왜냐하면 실패 모드는 실행이 중단되는 것이 아니기 때문입니다. 중단된 실행은 짜증스럽지만 복구 가능합니다. 재개하면 될 뿐이며, 약간의 시간을 잃을 뿐입니다. 진짜 실패 모드는 두 개의 실행기(executors)가 모두 자신이 스레드(thread)를 소유하고 있다고 믿는 상황입니다. 이로 인해 쓰기 작업이 뒤섞이고(interleaved writes), 상태가 갈라지며(diverging state), 각자 자신이 유일하다고 생각하는 두 명의 저자가 있는 git 히스토리가 만들어집니다. 중단된 실행은 몇 분의 시간을 낭비하게 하지만, 스플릿 브레인(split-brain) 실행은 작업 트리(working tree) 자체를 잃게 만들 수 있습니다.

하나의 스레드에 두 개의 실행기(executors)가 있는 것은 아무것도 없는 것보다 나쁩니다.

이것은 UI 문제가 아니라 임대(lease) 문제입니다

분산 시스템(Distributed systems)은 오래전에 이러한 형태의 문제를 해결했으며, 그 답은 더 똑똑한 대시보드가 아니었습니다. 그것은 임대(leases)와 펜싱(fencing)이었습니다:

• 잠금(lock)이 아닌 임대(lease). 소유권은 갱신되지 않으면 만료됩니다. 소유권을 가진 머신은 갱신을 통해 생존(liveness)을 증명합니다. 충돌(crash)이 발생하거나 오프라인 상태가 된 소유자는 누군가 충돌을 감지할 필요 없이 기본적으로(by default) 소유권을 상실합니다.
• 짧은 만료 시간. 임대 기간은 최악의 경우 발생하는 핸드오프(handoff) 지연 시간을 제한합니다. 90초 임대는 스레드 소유자가 누구인지에 대한 모호함이 최대 90초임을 의미합니다.
• 펜싱(Fencing). 다음 소유자는 이전 소유자의 뒤늦게 도착한 쓰기(write) 작업이 데이터를 손상시키지 못하는 방식으로 업무를 인계받습니다. 즉, 이전 임대는 무효화되며 해당 임대 하에 서명된 작업은 반영되지 않습니다.

이 중 어느 것도 생소한 것이 아닙니다. 새로운 점은 이를 에이전트 실행(agent runs)에 적용하는 것입니다. 여기서 "리소스(resource)"는 절반쯤 완료된 작업 단위이며, "노드(nodes)"는 사용자의 노트북과 VPS입니다.

이를 구축하며 놀랐던 점은, 핸드오프 자체를 **프로세스 마이그레이션(process migration)이 아닌 큐에 쌓인 프롬프트 핸드오프(queued prompt handoff)**로 모델링하는 것이 더 낫다는 사실이었습니다. 실행 중인 프로세스를 순간이동시키는 것이 아니라, 임대를 보유한 사람에게 다음 적격 작업 단위를 넘겨주는 것입니다. 이 차이가 펜싱(fencing)을 실행 가능하게 만듭니다.

Buzz의 로드맵이 말하는 것과 말하지 않는 것

Buzz는 WF-08을 완료할 것입니다. 스키마(schema), 엔드포인트(endpoints), UI는 이미 존재하며, 실행기(executor)가 승인 과정을 지속하고 재개하는 기능만 아직 구현되지 않았을 뿐입니다. 모바일은 활발히 개발 중이며, 푸시 알림(push notifications)도 계획되어 있습니다. 이 세 가지 모두 무료이며 오픈 소스입니다. 만약 당신의 "에이전트 안전 제품(agent safety product)"에 대한 멘탈 모델이 승인 프롬프트라면, 그 모델은 이제 확실한 만료 날짜를 맞이하게 되었습니다.

그들의 비전 문서 어디에서도 찾을 수 없는 것은 연속성(continuity)에 관한 절반의 이야기입니다. 즉, 실행 중인 머신이 사라졌을 때 진행 중인 실행(run in flight)은 어떻게 되는가 하는 점입니다. 임대(lease)도, 장애 조치(failover)도, 오프라인 정책도 없습니다. 이것을 허점으로 지적하려는 것이 아닙니다. 그들의 릴레이 중심(relay-centric) 모델은 우선순위가 다를 수 있으며, WF-08은 그들이 실행 의미론(execution semantics)을 진지하게 다루고 있음을 보여줍니다. 제가 이 말을 하는 이유는 이것이 아직 아무도 무료로 제공하지 않는 실제 미해결 과제(open problem)의 위치를 알려주기 때문입니다.

내가 테스트하고 있는 것, 솔직하게 라벨링된

ThumbGate는 최소한의 절반(least half)을 구현하려는 저의 시도입니다. 무료 브라우저 대시보드는 아웃바운드 HTTPS (outbound HTTPS)를 통해 머신과 페어링되며 — 인바운드 포트(inbound ports)는 필요하지 않습니다 — 머신이 온라인 상태인 동안 90초의 임대(lease)를 유지하며 작업은 로컬에 머뭅니다. 머신이 연결이 끊겼을 때, 사용자가 설정한 오프라인 정책(자동 또는 사전 확인)에 따라 격리된 VPS (fenced VPS)에서 적격한 (eligible) 작업을 이어받을 수 있는 선택적 유료 Continuity 애드온이 있습니다.

직접 발견하시기 전에 주의사항을 말씀드리자면: 라이브 페이지에는 Continuity가 "여전히 이를 입증하는 중(still proving this out)"이라고 명시되어 있으며, 이는 정확한 표현입니다. 제 테스트에서는 작동합니다. 하지만 현실 세계의 온갖 복잡한 상황들을 모두 겪어본 것은 아니며, 마치 그런 상황들을 다 해결한 것처럼 꾸며서 말하고 싶지는 않습니다.

에이전트(agents)를 밤새 실행하는 분들께 도움을 받고 싶은 미해결 과제(open question)는 이것입니다: 현재 핸드오프(handoff)를 어떻게 처리하시나요? Cron 재시작을 하고 운에 맡기시나요? 중단(stall)을 받아들이시나요? 아니면 더 스마트한 방법이 있나요? 저는 아무도 이 문제를 완전히 해결하지 못했다고 생각하며, 홍보를 하기보다는 서로의 노트를 비교해보고 싶습니다.

추가 정보: 무료 대시보드는 thumbgate.app에서 이용 가능하며, 브라우저에서 실행되므로 설치할 것이 없습니다. Buzz는 github.com/block/buzz에서 확인할 수 있습니다. 그들의 VISION.md를 읽어볼 가치가 있습니다.