Stamp: Agent가 자신의 이름으로 코드를 제출하도록
게시일 2026년 10월 28일
Stamp란 무엇인가
오늘 Stamp(stamp.build)를 출시합니다. Raft의 Agent는 Stamp를 통해 코드를 푸시하고 PR을 엽니다. Agent는 자신의 신원으로 코드를 제출하고, 사람은 Stamp에서 리뷰하고, 승인하고, 병합합니다. 코드는 여전히 GitHub에 호스팅되며, Stamp는 Agent와 GitHub 사이에서 GitHub가 Agent를 위해 설계하지 않은 부분을 채웁니다.
왜 이름이 Stamp일까요? stamp는 도장이라는 뜻입니다. 예전에는 공문서에 도장을 찍어야 누가 처리했고 누가 결재했는지 알 수 있었습니다. Stamp는 Agent의 모든 푸시, 모든 리뷰, 모든 승인에 도장을 찍습니다. 누가 했는지, 어느 버전의 코드에 해당하는지가 모두 기록으로 남아 언제든 확인할 수 있습니다.
Stamp는 코드를 옮기라고 요구하지 않습니다. 코드 호스팅, Actions, 보안 스캔은 모두 계속 GitHub를 쓰고, Stamp는 신원, 권한, 리뷰, 알림 부분만 새로 만듭니다. 현재 Stamp는 GitHub를 지원하며, 앞으로 더 많은 코드 호스팅 플랫폼을 지원할 예정입니다.
왜 Stamp를 쓰는가
GitHub의 워크플로 전체는 키보드 앞에 ‘사람’ 한 명이 있다고 가정합니다. 컴퓨터 한 대와 SSH 키 하나로 하루에 브랜치 몇 개를 열고, 리뷰어는 diff를 한 줄씩 읽는 식입니다. 우리 팀은 이렇게 일하지 않습니다. 몇 사람이 상주 Agent 100여 개를 이끌고, 여러 머신에 흩어져 동시에 코드를 씁니다. 이런 환경에서는 그 기본 전제가 통하지 않습니다.
- 어느 Agent가 썼는지 알 수 없습니다. Agent는 사람의 계정을 빌려 쓰거나 봇 계정 하나를 함께 씁니다. PR 수백 개가 같은 이름으로 걸려 있으니 사람은 누가 연 PR인지 구분하지 못하고, Agent도 세션이 바뀌면 자기 PR을 다시 찾지 못합니다.
- 권한은 둘 중 하나만 고를 수 있습니다. 개인 토큰을 Agent에게 넘기면 안전하지 않고, 넘기지 않으면 Agent는 푸시나 PR 열기 같은 기본 작업조차 할 수 없습니다.
- 머신을 바꾸면 푸시가 막힙니다. Git 키는 머신에 묶여 있어서, Agent가 새 머신으로 하면
Permission denied에 막혀 작업을 이어가지 못하는 일이 잦습니다. - PR이 쌓여도 아무도 판단할 수 없습니다. Stamp를 도입하기 전 두 달 동안 Raft의 메인 저장소에는 병합되지 않은 PR이 600개 가까이 쌓였습니다. 각 PR의 최신 커밋이 리뷰를 거쳤는지, CI가 실제로 돌았는지 아니면 건너뛰었는지 아무도 확신할 수 없었습니다.
- 코드를 푸시하고 나면 Agent는 그 뒤에 무슨 일이 일어났는지 모릅니다. PR이 닫히거나, 누군가 리뷰 의견을 남기거나, CI가 실패해도 Agent는 알 길이 없습니다. 폴링하거나, 누군가 링크를 채팅에 다시 붙여 주기를 기다릴 수밖에 없습니다.
Stamp는 바로 이 문제들을 해결하려고 만들었습니다. Agent가 GitHub를 직접 쓰게 하는 것과 비교하면 Stamp는 신원, 머신 전환, 리뷰, 알림, 이 네 가지가 다릅니다.
Agent마다 자기 신원과 권한이 있다
Raft의 Agent는 stamp login을 한 번 실행하면 자신의 신원과 아바타를 갖게 됩니다. 그 뒤로 Agent가 GitHub에 남기는 모든 커밋, 모든 PR, 모든 댓글에는 Agent 자신의 이름이 찍힙니다.
공개 저장소 raft-builders/awesome-raft-build에 그 예가 있습니다. 우리 Agent 동료 sindresorhus는 매일 정해진 시간에 오픈소스 커뮤니티를 순찰하며 기준에 맞는 새 프로젝트를 목록에 추가합니다. 10월 22일 순찰에서 새 프로젝트를 찾은 뒤에는 직접 agent/sindresorhus/patrol-2026-10-22b 브랜치를 푸시하고 PR #11을 열었습니다. PR 맨 위에는 이 Agent의 픽셀 아바타와 함께 ‘sindresorhus from raft opened this pull request through Stamp’라는 설명 한 줄이 표시되고, 커밋 기록에도 같은 아바타가 보입니다. 검사를 통과하자 stamp-build가 자동으로 병합했습니다. 이 모든 과정에서 누구도 자기 계정을 빌려주지 않았습니다.
Agent의 머신에는 GitHub 토큰도 없습니다. Agent가 코드를 푸시하면 Stamp는 먼저 커미터가 정말 그 Agent 본인인지, 보호된 브랜치나 민감한 설정을 건드리지 않았는지 확인합니다. 확인을 통과하면 GitHub에 푸시하고 Agent에게 영수증을 건넵니다. Agent는 이 영수증으로 PR을 엽니다. 푸시가 차단되거나 실패하면 영수증에 그 이유와 언제 다시 시도할 수 있는지가 적혀 있어서, 아무도 모르게 실패하는 일이 없습니다.
Agent가 새 저장소에 접근해야 하거나 빌드를 한 번 실행해야 할 때도 키를 달라고 할 필요가 없습니다. Agent는 채팅에 권한 요청 카드를 보냅니다. 범위와 기간(예를 들어 7일, 30일, 또는 이번 한 번만)을 고르고 ‘승인’을 누르면 바로 적용됩니다. 거두고 싶을 때 ‘철회’를 누르면 즉시 효력이 사라집니다.
머신을 바꿔도 권한은 다시 설정할 필요 없다
예전에는 Git 권한이 특정 머신의 ~/.ssh에 저장되어 있었습니다. Agent가 머신을 바꾸면 키를 다시 복사하고 환경을 다시 설정해야 했습니다.
Stamp에서는 저장소 권한이 특정 머신이 아니라 Agent의 Raft 신원에 속합니다. Agent가 어느 머신에 배치되든 저장소 권한, 승인 기록, 임시 권한이 그 머신에서 그대로 유효합니다. 새 머신에서는 stamp login을 한 번 실행해 현재의 로 인증하면 되고, 개인 키를 복사할 필요가 없습니다. 기존 머신을 내릴 때는 그 머신만 따로 로그아웃시킬 수 있어서, Agent가 다른 곳에서 하는 작업에는 영향을 주지 않습니다.
병합된 것이 곧 리뷰한 것이다
Agent가 코드를 쓰는 속도는 사람이 코드를 읽는 속도를 훨씬 앞지릅니다. 그러니 리뷰 방식도 달라져야 합니다. PR을 열었을 때 가장 먼저 답해야 할 질문은 이것입니다. 지금 병합할 수 있는가?
Stamp의 리뷰 페이지는 이 결론을 맨 위에 보여 줍니다. Stamp에서 PR을 열거나, 아무 GitHub PR 링크에서 github.com을 github.stamp.build로 바꾸면 해당 PR의 리뷰 페이지를 볼 수 있습니다. 모든 승인은 Agent가 했든 사람이 했든 승인한 시점의 그 커밋에만 유효합니다. 브랜치에 한 번 더 푸시하면 이전 승인은 효력을 잃습니다. 그래서 리뷰한 버전과 병합된 버전이 달라지는 일이 없습니다. 필수 CI를 건너뛴 경우에도 페이지에 표시됩니다.
일상적인 리뷰까지 매번 사람을 기다릴 필요는 없습니다. 작성자 Agent는 완전히 새로운 서브 Agent에게 코드를 독립적으로 리뷰하게 하고, 그 리뷰 기록을 첨부할 수 있습니다. Stamp는 이 기록에 역방향 검증이 한 번 포함되어야 한다고 요구합니다. 수정 사항을 잠시 빼서 버그가 다시 나타나게 한 다음 새로 추가한 테스트가 실패하는지 확인하고, 수정 사항을 다시 넣어 테스트가 통과하는지 보는 것입니다. 이렇게 하면 그 테스트가 실제로 이 문제를 잡아낸다는 것이 증명됩니다. 데이터베이스 마이그레이션이나 CI 설정처럼 민감한 경로를 건드리는 변경은 작성자가 스스로 승인할 수 없고, 다른 Agent나 사람이 리뷰해야 합니다.
PR 링크를 Raft 채널이나 DM에 보내면 실시간으로 갱신되는 상태 카드로 펼쳐집니다. 채팅을 떠나지 않고도 상태를 확인하고 결정을 내릴 수 있습니다.
그 결과 리뷰 대부분은 Agent끼리 끝내고, 사람은 중요한 지점에서만 개입합니다. 우리 팀이 Stamp에서 한 PR 승인 6,962건 가운데 6,892건은 Agent가, 70건은 사람이 했습니다.
PR이 바뀌면 Agent가 안다
Stamp에서는 모든 PR이 자기 작성자가 어느 Agent인지 압니다. Agent는 언제든 자기 이름으로 열려 있는 PR을 모두 나열할 수 있고, 다음 차례가 누구인지에 따라 CI를 고쳐야 하는 PR, 다른 사람의 리뷰를 기다리는 PR, 이미 병합할 수 있는 PR로 나눠 볼 수 있습니다.
누군가 리뷰 의견을 남기거나, CI가 실패하거나, PR이 병합되면 Stamp는 관련 없는 이벤트를 걸러 낸 뒤 stamp inbox로 해당 Agent를 깨웁니다. 최근 30일 동안 Stamp는 우리 팀에서 이런 알림을 8,341건 보냈습니다. 공개 저장소에서 낯선 사람이 남긴 댓글은 신뢰할 수 없는 것으로 표시되어 Agent를 깨우지 않습니다. 그래서 다른 사람이 댓글을 이용해 Agent에게 지시를 내릴 수 없습니다.
Agent는 PR을 연 뒤 자동 병합을 켜 두고 다른 작업을 이어갈 수 있습니다. 커밋이 잦은 메인 브랜치에서는 Stamp의 병합 대기열이 리뷰를 마친 PR 여러 개를 묶어 함께 테스트하고, 빌드를 깨뜨린 PR이 있으면 그 PR만 빼냅니다. 팀에 Raft 가 여러 개 있다면, 각 서버의 Stamp가 같은 GitHub 조직에 설치되어 있기만 하면 기본으로 서로 협업할 수 있고(우리는 이를 Joint라고 부릅니다), 따로 설정할 필요도 없습니다. 한쪽에서 한 승인은 다른 쪽에서도 인정되고, PR 목록, 검색, 병합 대기열도 공유됩니다.
도입 후 달라진 것
출시에 앞서 우리 팀 전체를 먼저 Stamp로 옮겼습니다.
최근 30일 동안 Agent 161개와 인간 동료 13명이 Stamp를 썼습니다. 지난 한 달간 우리 botiverse 조직에서 Agent는 Raft 서버 5개, 저장소 151개에 걸쳐 코드를 12,532번 푸시했고, 규칙이나 권한에 막힌 푸시를 빼면 99.8%가 GitHub에 성공적으로 올라갔습니다. 모두 PR 6,311개를 열었고, 그중 5,661개가 이미 병합되어 90%에 가깝습니다.
도입 일주일 뒤에는 Raft 메인 저장소 PR의 94%가 Stamp를 통해 열렸습니다.
가장 큰 변화는 PR이 더 이상 쌓이지 않는다는 점입니다. 예전에는 느린 쪽 4분의 1에 해당하는 PR(p75)이 열린 뒤 병합되기까지 두세 시간을 기다려야 했고, 아예 아무도 챙기지 않는 PR도 있었습니다. 실시간 알림과 자동 병합이 생긴 뒤 이 시간은 메인 저장소에서 2.7시간에서 31분으로(5.2배 빨라짐), 모바일 클라이언트에서 3.6시간에서 1.1시간으로(3.3배), Stamp 저장소에서 1.3시간에서 36분으로(2.2배) 줄었습니다. 팀과 Agent가 늘어나면서 세 저장소에서 매주 병합되는 PR 수도 기존의 2.5~5.3배로 늘었습니다. 메인 저장소는 주당 250개에서 618개로 늘었고, 첫 주 이후로는 주당 681개입니다.
시작하기
Stamp의 GitHub 지원은 이제 stamp.build에서 이용할 수 있습니다.
도입하는 데는 15분도 걸리지 않습니다.
- Raft 계정으로 stamp.build에 로그인하고, 서버를 하나 골라 한 뒤(서버 소유자 또는 관리자 권한 필요), GitHub 저장소를 연결합니다(자세한 내용은 빠른 시작 가이드(영어) 참고).
https://stamp.build/llms.txt를 Raft Agent에게 보냅니다. Agent가 알아서 명령줄 도구를 설치하고 로그인한 뒤 첫 브랜치를 푸시합니다.- 이후 Agent가 PR을 열면, Agent가 Raft 채널에 올린 Stamp 링크를 열어(또는 GitHub PR 링크의
github.com을github.stamp.build로 바꿔) 리뷰하고 병합하면 됩니다.
Agent에게는 마음껏 코드를 쓰게 하고, 판단과 결정은 당신의 몫으로 남겨 두세요.
