Shopify의 네 가지 게이트를 Claude Code로 재구축하다. 테스트만 효과가 있었다.

Shopify의 Helix 게시물이 2주 동안 내 피드에 돌아다녔고, 항상 같은 문장이 첨부되어 있었다: "실패하려는 시도는 허용되지만, 완벽하지 않은 상태로는 배포될 수 없다." AI 체크포인트마다 네 개의 게이트가 순서대로 존재한다. 테스트, 디자인 검토, 두 명의 독립적인 리뷰어 에이전트, 그리고 엔지니어.

나는 이 게시물을 숫자를 찾기 위해 두 번 읽었다. 아무것도 없다. 통과율도 없고, 비용도 없고, 무엇이 빠져나갔는지에 대한 카운트도 없다. Shop 앱을 만드는 데 12주가 걸렸고 300개 이상의 화면이 있었다는 것이 전부다.

그래서 나는 이 게이트들을 실제 테스트 스위트가 있는 리포지토리에 Claude Code로 구축했고, 게시물이 남겨둔 유일한 질문을 던졌다: 네 가지 게이트 중 실제로 버그를 잡아내는 것은 무엇이며, 각각의 비용은 얼마인가?

내가 실제로 테스트한 내용

이 리포지토리는 tinydb라는 작은 문서 데이터베이스로, 사용한 커밋에서는 226개의 테스트가 녹색이었다. 워커는 claude -p를 사용하여 헤드리스(headless) 상태로 실행되는 Sonnet 5.5이며, 최대 60턴까지 가능하고 편집은 자동 수락된다.

개발자가 작성하는 방식대로 다섯 가지 요청을 보냈다: 필드에 대한 push 및 pull 작업, between 쿼리, 테이블 이름 변경, 정렬된 검색, 쓰기 캐시 크기. 각 요청 뒤에는 에이전트가 결코 알지 못하는 다섯 가지 숨겨진 요구사항들이 자리하고 있다. 이는 신중한 시니어 엔지니어가 기대할 만한 것들이다. 따라서 25개의 요구사항이 생겼고, 이들은 리포지토리 외부에 존재하는 숨겨진 테스트에 의해 검사된다.

다섯 가지 구성으로 설정했다: 게이트 없음, 수용 테스트만 단독으로, 두 리뷰어만 단독으로, 테스트 후 리뷰어들, 그리고 비평가와 짝을 이룬 리뷰어와 테스트. 각 작업당 구성별로 두 번 반복했다. 총 50번의 실행이었다. 디자인 게이트는 건너뛰었다: 이것은 라이브러리이며, Shopify의 게시물에 따르면 로직만 변경하는 것은 단순히 이를 건너뛴다고 했다.

모든 게이티드 구성은 동일한 Stop hook을 통해 실행된다.

Stop hook이란?

Anthropic 자체 모범 사례 가이드에서는 이 문제를 지적한다: 검사 장치가 없으면, "완료된 것처럼 보이는 것"만이 유일하게 사용 가능한 신호이며, 당신 자신이 검증 루프가 된다. Stop hook은 에이전트가 턴을 끝내려고 할 때마다 실행된다. 이는 프로젝트 설정에 존재한다:

{
  "hooks": {
    "Stop": [
...

계약(contract)은 종료 코드입니다. 0은 턴을 끝냅니다. 2는 이를 차단하고, 스크립트가 표준 오류(standard error)로 출력한 모든 내용이 에이전트에게 이유로 돌아갑니다. 화면상으로는 에이전트가 변경 사항을 요약하고 멈추고, 후크(hook)가 수용 테스트(acceptance tests)를 실행합니다. 하나가 실패하면, 턴은 끝나지 않습니다. 에이전트는 실패를 읽고 코드를 수정한 다음, 다시 멈춥니다. 이번에는 게이트가 조용합니다.

프롬프트 내의 규칙(rule)은 조언일 뿐입니다. 후크는 그렇지 않습니다. 그런데도 동일한 문서 페이지에는 세 가지 탈출 방법이 나열되어 있습니다.

cap      8개의 연속 블록, 그러면 Claude Code가 다음 블록을 덮어씁니다.
         (모든 도구 호출마다 초기화됩니다; CLAUDE_CODE_STOP_HOOK_BLOCK_CAP이 이를 올립니다)
timeout  기본값 600초; 시간 초과된 후크는 결정을 내리지 못합니다.
...

제 게이트는 플래그를 기록하고 무시하며, 루프가 셀 수 있도록 자체적으로 여섯 블록 후에 포기합니다.

아무도 문서화하지 않은 네 번째 탈출구가 있습니다. 한 번 차단된 후, 에이전트는 테스트를 찾아다녔습니다: 후크 스크립트에 대해 cat을 사용하고, 전체 디스크에서 테스트 파일을 찾기 위해 find를 사용했습니다. 권한 거부 목록만이 그것을 막았습니다. 따라서 수용 테스트는 리포지토리 트리 외부에 존재하며, 설정은 후크와 숨겨진 테스트에 대한 읽기를 차단하고, 에이전트는 실패는 보지만 파일 자체는 볼 수 없습니다.

수용 테스트가 패스율을 70%에서 84%로 끌어올리다

게이트 자체가 없을 때는 50개의 요구 사항 중 35개가 통과합니다. 10번의 실행 중 세 번만 완전히 깨끗했습니다.

Shopify의 첫 번째 게이트는 에이전트 자체 테스트가 아닙니다. 서브에이전트(subagent)가 각 체크포인트별로 통합 스타일의 테스트를 작성하며, 이것들이 '검증되었다'는 의미를 정의합니다. 따라서 여기서 작가는 요청과 변경 전 리포지토리를 읽기 전용으로 보는 별도의 헤드리스 Sonnet이며, 코드를 실행할 수 없습니다. 이 작가는 약 40초 만에 23개에서 53개의 테스트(평균 39개)를 작성합니다.

테스트만 사용했을 경우: 50개 중 42개가 통과하며, 세 번 대신 여섯 번의 완전히 깨끗한 실행을 보여줍니다.

task               no tests   with tests
sorted search      10개 중 5개    10개 중 10개
write cache size   10개 중 8개    10개 중 10개
...

정렬(sort) 작업은 누락되는 경우를 보여줍니다. 에이전트는 정렬 필드를 사용하여 모든 문서를 인덱싱했지만, 하나의 문서라도 해당 필드가 없으면 전체 검색이 충돌합니다. 작가는 정확히 그러한 종류의 질문을 합니다. 밀고 당기기(push and pull) 작업은 움직이지 않습니다. 세 번의 누락 중 두 번은 해당 필드가 없는 문서에 관한 것이었고, 요청에서는 이에 대해 아무것도 말하지 않았으며, 작성자의 테스트는 오류 발생 또는 조용한 무시(silent no-op)를 허용합니다. 게이트는 아무도 명시하지 않은 요구사항을 복구할 수 없습니다.

테스트가 포함된 30회의 게이팅 실행 동안, 이 게이트는 실제 요구사항 실패로 에이전트를 28번 되돌려 보냈고, 모두 통과한 경우는 5번이었습니다. 비용은 $0.085에서 run당 $0.20으로 올랐고, 시간은 33초에서 60초가 걸립니다.

제가 건너뛰지 않을 한 가지 세부 사항: 이 게이트의 첫 번째 버전은 구현자 자신의 테스트를 재실행했습니다. 이는 숨겨진 요구사항이 실패하는 동안 모든 실행을 첫 번째 단계에서 허용했습니다. 에이전트 자체의 테스트는 자신이 구축한 것을 테스트합니다.

두 명의 검토자가 아무것도 추가하지 않음, 비용은 세 배 증가

Shopify의 문구: 독립적이고 컨텍스트가 격리된 두 개의 검토자 에이전트(reviewer agents), 모든 발견 사항을 수정하고, 양쪽 모두 승인할 때까지 루프를 반복합니다. 여기서 각 검토자는 읽기 전용 도구를 가진 headless Sonnet이며 최대 15턴 동안 구조화된 JSON(approve 플래그와 blocking 또는 minor 심각도의 발견 사항)을 반환합니다. 두 개의 에이전트가 요청과 전체 diff에 대해 병렬로 실행되며, 그들의 발견 사항은 결합되고, 둘 중 하나라도 blocking한 것을 발견하면 게이트는 차단됩니다. 한 쌍의 비용은 단계당 3센트에서 6센트 사이입니다.

configuration            passed    rate   blocks
no gate                  35 of 50  70%    none
reviewers alone          34 of 50  68%    1 in 10 runs
...

정렬(sort) 작업은 숫자를 설명합니다. 한 번의 실행에서 두 리뷰어 모두 키 오류 충돌(key error crash)에 막혔고, 에이전트가 이를 수정하여 다섯 번 중 다섯 번 성공했습니다. 다른 두 번의 실행에서는 두 리뷰어 모두 정확히 같은 충돌을 보았지만, 문서화된 내용 덕분에 사소하다고 평가했습니다. 둘 다 승인했고, 두 번의 실행 모두 다섯 번 중 0으로 끝났습니다. 동일한 모델, 동일한 차이(diff), 동일한 버그, 두 가지 심각도입니다. 리뷰어들이 막혔을 때는 결코 틀리지 않았습니다. 문제는 그들이 그냥 지나치는 부분입니다.

지난 8월에 발표된 논문은 LiveCodeBench에서 같은 형태를 측정했습니다: 제로샷(zero-shot) 77%, 한 명의 리뷰어 77%, 두 독립적인 리뷰어 75%. 리뷰어와 비평가(critic)를 결합한 방식, 즉 두 번째 에이전트가 수정되기 전에 검토 내용을 감사하는 방식은 87%였습니다. 그래서 저도 그것을 구축했습니다. 리뷰어 A가 검토하고, 비평가 B가 발견된 각 사항에 대해 유지 또는 거부 도장을 찍으며, 오직 '유지'되어 막히는(blocking) 발견만이 게이트를 통과시킵니다. 이 저장소에서는 50개 중 39개, 78%의 성공률을 보였고, 열 번의 실행 동안 블록은 없었습니다.

어떤 리뷰어 형태도 고치지 못한 것은 루프(loop)였습니다. 세 번의 실행에서 동일한 승인 테스트에서 여섯 개의 블록이 발생했고, 게이트는 요구사항이 여전히 실패하는 상태로 포기했습니다. 기억할 만한 한 경우에서는 테스트가 실패하는 업데이트를 모든 문서를 건드리지 않고 남겨두기를 원했기 때문에, 에이전트가 테이블의 업데이트 메서드를 재작성했습니다. 리뷰어들은 이를 요청하지 않은 변경으로 막았습니다. 에이전트는 되돌리고(revert) 승인 테스트와 코드 검토가 서로 반대되는 것을 요구하고 있다고 작성하여 아무것도 변경하지 않고 중단했습니다.

이것이 증명하는 것은 아닌 것들

하나의 저장소, 하나의 작업 모델, 다섯 가지 작업, 셀당 두 번 반복. 행 간 2점 차이는 노이즈입니다. '게이트 없음'과 테스트 게이트 사이의 14점은 그렇지 않습니다. 디자인 게이트는 구축되지 않았고 엔지니어링 시간 측정도 이루어지지 않았습니다. 전체 매트릭스는 CLI가 보고하는 바에 따르면 API 지출 비용으로 $9.95가 들었습니다.

configuration                  passed   cost/run   left for the human
no gate                        35       $0.085     15
acceptance tests               42       $0.20       8
...

비디오는 실제 실패하는 수용 테스트에서 훅(hook)이 작동하고, 에이전트가 숨겨진 파일을 찾고, 두 리뷰어가 같은 충돌을 사소한 것으로 평가하는 것을 보여줍니다.

이런 저장소에 대한 저의 평가는 이렇습니다. 작성자가 구현자가 아닌 별도의 테스트 게이트를 유지하고, 루프(loop)에 카운터를 부여하며, 리뷰어는 필수 조건이라기보다는 피드백 내의 조언으로 남겨두어야 합니다. 만약 오늘 Stop 훅을 실행한다면 무엇을 차단할까요? A) 에이전트 자체 테스트 B) 다른 사람이 작성한 테스트 C) 리뷰어 에이전트 D) 아직 아무것도, 제가 게이트입니다.

AI 어시스턴트가 산문 정리를 도와주었습니다. 실행 결과, 숫자, 의견은 저의 것입니다.