ProofTicket: 에이전트의 작업을 검토 가능한 에이전트 티켓으로 전환하기

이 게시물은 GitHub Finish-Up-A-Thon Challenge를 위한 제출물입니다.

내가 만든 것

ProofTicket은 GitHub 협업 (coworking)을 컨텍스트 (context), 승인 (approval), 영수증 (receipts), 그리고 증거 (evidence)를 포함한 티켓 (ticket)으로 전환합니다.

아이디어는 간단합니다. 하나의 거대한 저장소 정책 (repo policy)을 작성하고 모든 인간 또는 에이전트 (agent)의 행동이 이에 부합하기를 바라는 대신, 각 티켓이 자체적인 지침 (instructions), 승인 경로 (approval path), 산출물 (artifacts), 그리고 증거 (proof)를 지니게 하는 것입니다. 친구가 개선 사항을 제안할 수 있습니다. AI 동료가 작업을 완료하는 것을 도울 수 있습니다. 작업이 공유된 프로젝트 상태 (project state)가 되기 전에는 여전히 인간이 최종 승인 단계를 거칩니다. 다음에 친구가 아이디어를 떠올리면, Git 저장소 (repo)가 아니라 티켓을 보내세요.

회사에서 티켓을 여는 것은 이미 올바른 형태를 갖추고 있습니다: 여기에 문제가 있고, 여기에 컨텍스트가 있으며, 여기에 다음 단계를 누가 담당하는지가 명시되어 있습니다. ProofTicket은 GitHub에서의 AI 협업 (coworking)에도 동일한 형태를 적용합니다.

완성된 슬라이스 (slice)에는 에이전트 제출 티켓, 인간 승인, 영수증 검사, 증거 내보내기, 증명 스타일의 프로필 카드, 서명된 GitHub 및 머신 웹훅 (machine-webhook) 수집, 로컬 MCP 어댑터 (MCP adapter), 그리고 5분 데모 경로가 포함되어 있습니다.

데모

Repo: https://github.com/dodge1218/pt

npm install
npm run setup:local
npm run dev

다른 터미널에서:

bash examples/five-minute-demo/print-demo-commands.sh

데모 경로:

1. 로컬 데모 에이전트 (agent) 등록.
2. 증거를 포함하여 에이전트가 생성한 티켓 제출.
3. 대기 중인 작업 영수증 (receipt) 검사.
4. 작업 승인.
5. 앱에서 생성된 티켓 열기.
6. 증거 번들 (evidence bundle) 내보내기.

재기 스토리 (The Comeback Story)

ProofTicket는 티켓에 증거(proof)를 첨부한다는 핵심 개념에서 시작되었습니다. 저는 여전히 Coordinate라는 브랜드가 더 좋다고 생각하는데, 그 이유는 동작이 단순하게 느껴져야 하기 때문입니다. 당신은 업무를 조정(coordinating)하는 것이지, 사람들에게 에이전트 협업(agent collaboration)에 관한 완전히 새로운 이론을 배우라고 요구하는 것이 아닙니다.

이전 프로젝트는 매칭, 컨텍스트 매니페스트(context manifests), 지급(payouts), ZK 증명(ZK proofs), GitHub 동기화, 호스팅된 SaaS 제어 등 너무 많은 미래 기능들이 결합된 광범위한 협업 제품으로 커졌습니다.

해결해야 할 유용한 문제는 더 작았습니다:

인간과 에이전트가 모두 실제 업무를 수행하고 있다면, 그 업무가 검토, 승인, 증거 제시 또는 후속 조치가 필요할 때 어디에 머물러야 하는가?

마무리 작업(finish-up work)은 프로젝트를 해당 워크플로우(workflow)로 축소하는 것이었습니다. 이전에는 광범위한 조정 앱이었으나, 이후에는 에이전트가 작업을 제안하고, 인간이 이를 승인하거나 거부하며, 증거가 계속 첨부되어 있고, 검토자가 나중에 영수증을 검사할 수 있는 집중된 프로토타입(prototype)이 되었습니다.

또한, 진심으로 이 챌린지를 만들어 주신 분들께 감사드립니다. 물론 저는 제출 직전까지 기다렸습니다. 저와 같은 사람들에게는 바로 이런 종류의 '마무리 해커톤(finish-up-a-thon)'이 필요했습니다. 빈 페이지에서 시작하는 또 다른 해커톤이 아니라, 미완성된 더미에서 오래된 것을 꺼내 누군가에게 보여줄 수 있을 만큼 일관성 있게 만드는 추가적인 자극 말입니다.

GitHub Copilot 사용 경험

지난 4월, 저는 약 40달러씩 14개의 Copilot Pro+ 구독을 구매했습니다. 이에 대해 많이 생각해 보았는데, 저는 아마도 미끼 상품(loss-leading) 가격 모델을 작동하지 않게 만드는 바로 그 유형의 고객일 것입니다. 저는 최고의 고객은 아닙니다. 그럼에도 다시 한번 감사드립니다.

저는 그 모든 시행착오에 대해 The Best $40 Addendum에서 작성했습니다. 그러고 나서 GitHub Copilot이 얼마나 유용한지에 대해 여러 편의 글을 쓴 후, 약 한 달 동안 GitHub Copilot 계정이 잠겼습니다. 이는 마치 Vitalik의 마법사(warlock) 이야기의 축소판처럼 느껴졌습니다. 플랫폼 전환이 한 번 일어나자, 당신의 워크플로우(workflow)가 중앙 집중식 서비스에 얼마나 많이 의존하고 있는지를 갑자기 깨닫게 되는 것입니다.

GitHub Copilot이 여기서 실질적인 역할을 했습니다. ProofTicket의 전반부는 Copilot Opus 4.6의 도움을 받아 완성되었습니다. 후반부 마무리 작업은 Copilot GPT 5.5의 도움을 받아 더 좁혀진 목표, 즉 아이디어를 확장하는 것을 멈추고 실제 데모 경로가 작동하도록 만드는 데 집중하여 완성되었습니다.

Copilot이 비록 비용은 조금 더 비싸졌을지라도, 다시 정상적으로 작동하게 되어 매우 기쁩니다.

여기서 얻은 교훈은 "AI가 앱을 작성했다"가 아닙니다. 유용했던 부분은 모호한 야망을 테스트 가능한 단계들로 전환하는 것이었습니다: 로컬 설정(local setup), 타입이 지정된 에이전트 작업(typed agent actions), 인간의 승인(human approval), 영수증 검사(receipt inspection), 증거 내보내기(evidence export), 그리고 프로토타입의 범위를 과장하지 않는 공개용 카피(public copy) 등이 그것입니다.

"AI 협업 앱을 만든다"는 모호합니다. 반면 "에이전트가 작업을 제출하고, 인간이 이를 승인하며, 증거 번들(evidence bundle)이 깔끔하게 내보내지는 5분짜리 흐름을 만든다"는 완성할 수 있을 만큼 충분히 구체적입니다.