10초에서 갈라진 두 답
AI 둘이 같은 코드를 반대로 고쳤다. 가상의 예다. 검색 요청을 10초까지 기다리던 코드에서 A는 3초로 줄이고, B는 30초로 늘린다. A의 이유는 “오래 기다리게 하지 말자”, B의 이유는 “느려도 답을 받자”다. 두 수정은 각각 그럴듯하지만, 같은 요청에 동시에 적용할 답은 아니다.
바로 하나를 버리기보다 두 시도를 남겨 두고 싶다. 무엇을 고쳤는지뿐 아니라 왜 고쳤는지까지 비교하기 위해서다. Git 저장소는 코드와 변경 이력을 담는다. 여기서 궁금한 것은 AI의 수보다, 각 시도를 어디까지 따로 취급할 것인가다.
수정본과 접근 권한을 함께 나누기
Cloudflare Artifacts는 에이전트 작업용 Git 저장소를 만들고 관리하는 서비스다. 공식 구조 문서에 따르면 포크는 독립 저장소다. 이력·원격 주소·Git 토큰·수명이 각각 구분된다.
인증 문서에서 저장소 토큰은 Git용이다. 저장소 분리가 Cloudflare API나 Workers 바인딩의 관리 권한까지 자동 축소하지는 않는다.
가상 예에 적용하면 검토한 10초 버전에서 A와 B의 저장소를 따로 만들고, 각 작업에는 자기 저장소에 쓸 권한만 주는 구상이다. B가 다시 검토 중이라는 이유로 A의 쓰기 권한까지 계속 열어 둘 필요는 없게 설계한다. 단, 실행하는 프로그램이 읽을 파일과 이용할 네트워크는 별도로 제한해야 한다. Git 접근 범위를 나눴다는 설명을 실행 샌드박스의 보증으로 읽어서는 안 된다.
3초와 30초를 고르는 일은 남는다
이제 검토자는 같은 출발점과 두 변경을 나란히 놓는다. 가상의 시험으로 2초 만에 돌아오는 응답, 8초가 걸리는 응답, 끝내 돌아오지 않는 요청을 넣어 보자. 8초 응답을 포기해도 되는 화면인지, 사용자가 그만큼 기다릴 이유가 있는 기능인지에 따라 판단이 달라진다. 숫자가 짧다는 이유만으로 A가 낫다고 할 수 없다.
V라면 병합 전에 “이 화면은 언제 기다림을 끝내야 하는가”를 먼저 결정하겠다. 선택한 변경과 선택 이유를 기준 코드에 반영하고, 필요하면 두 제안을 모두 고칠 수도 있다. 분리해 둔 이력은 비교할 대상을 보존한다. 제품에 들어갈 동작의 정답까지 골라 주지는 않는다.
V의 기준: 끝나는 시점이 다른가
V는 작업마다 저장소를 만들기 전에 두 가지를 묻고 싶다. 이 시도의 접근 권한은 언제 끝나야 하는가? 결과는 언제까지 남겨야 하는가? 예를 들어 A는 오늘 검토를 마쳤지만 B는 다음 주까지 비교 자료로 남겨야 한다면, 서로 다른 종료 조건을 관리하는 이유가 생긴다. 이때는 채택 여부, 남길 근거, 정리 담당자를 함께 기록하는 편이 낫다.
반대로 같은 팀이 같은 코드에 계속 접근하고 모든 시도를 같은 기간 보관한다면 어떨까. V는 이 경우 한 저장소 안의 브랜치부터 검토하겠다. 따로 끝낼 권한이나 보관 기간이 없는데 저장소만 늘리면, 이름과 정리 대상을 더 챙겨야 한다. 이는 운영 선택에 대한 판단이며 비용이나 속도 개선을 측정한 결과는 아니다.
보관 문서는 명시적 삭제까지 저장소가 남는다고 설명한다. 채택 거절이나 토큰 만료도 삭제를 대신하지 않는다.
어디까지 확인한 설명인가
2026년 10월 6일 확인: Artifacts는 Workers Paid 플랜에서 이용하는 공개 베타다. 한도는 저장소 1GB, 파일·블롭 32MB, 계정 1TB다. 계정 증액은 요청할 수 있다. 베타 안내 · 요금 · 한도
공개 문서를 바탕으로 한 설명이며 직접 운영하거나 성능을 시험하지 않았다. 도입 전에는 현재 요금과 한도를 다시 확인해야 한다.
NDA 문서를 보려다 프로그램을 실행할 뻔했다는 저장소를 읽는 일과 프로그램이 실행되는 일 사이의 경계를 살핀다. 이 글에서 분리해 둔 실행 쪽 질문을 이어 볼 수 있다.