모델보다 오래 가는 에이전트 하니스 만들기 — Shopify

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

Shopify는 Dispatch 기반의 에이전틱 하네스를 구축하여 모델이 제안한 후보 취약점을 통합 테스트 오라클로 증명하고 검증된 수정안을 PR로 자동 생성하는 흐름을 운영하고 있다. 파티셔닝과 디프 기반 스캔으로 토큰 소비를 줄였고 수천 건의 스캔 중 300건 이상의 파인딩을 도출하여 보수적으로 $400,000 이상의 가치를 확인했다. 이 접근은 모델 교체가 빈번해도 하네스만 개선하면 검증 프로세스는 재현 가능하다는 운영적 이점을 제공한다.

빠른 이해

새로운 점

하네스 자체를 지속 발전시켜 새 모델을 교체해도 검증·재현 과정은 유지된다는 운영적 차별성이 강조되었다.

핵심 메커니즘

입력으로 리포지토리와 커밋 디프를 받고 파이프라인은 파일 카탈로그화→파티셔닝→병렬 Hunting으로 후보 추출→순차 Verifier로 실제 통합 테스트 실행→후처리 및 PR 생성의 순서로 동작한다. 각 단계는 아티팩트(JSON 파티션, 아키텍처 문서 등)를 생성하여 이후 스캔에서 재사용되며 증분 스캔 시에는 변경점만을 대상으로 처리하여 토큰 소비를 줄이는 출력물을 만든다. 이로 인해 모델이 생성한 후보를 테스트 오라클로 증명하여 신뢰성 높은 결과를 확보하는 구조적 이점이 발생한다.

핵심 수치

스캔 대상 애플리케이션 수: 80+
도출된 파인딩 수: 300+
보수적 가치 추정: $400,000+
전체 스캔 비용 범위: $50~$300
증분 디프 스캔 비용 범위: $5~$50

섹션별 상세

하네스의 목적과 전체 흐름

Shopify는 모델들이 더 많은 후보 취약점을 생성하지만 오탐도 증가한다고 관찰했다는 문제를 제기했다. 이를 해결하기 위해 에이전틱 하네스는 리포지토리를 입력으로 받아 파티셔닝과 문서화 아티팩트를 생성하고, 병렬 Hunting 에이전트로 후보를 추출한 뒤 순차 Verifier가 통합 테스트를 실행하여 검증 결과를 출력하는 흐름으로 설계되었다. 이 설계는 후보를 단순 리스트로 전달하는 대신 증거 기반 테스트(검증 실패·성공)로 심각도를 확정함으로써 개발자 신뢰를 유지하는 목적을 달성했다.

근거

어느 한 감사에서 모델이 30개 이상의 후보 취약점을 식별했으나 검증 후 모두 저등급, 오탐 또는 방어적 분류로 처리되었다 — 도입부와 사례 언급에서 특정 감사 결과가 기술되어 있음

Dispatch 오케스트레이터와 파이프라인 단계

Dispatch는 Ruby 클라이언트로서 스캔 저자들이 에이전트 기반 스캔을 쉽게 구성하도록 추상화하는 역할을 수행한다는 점에서 핵심 구성 요소이다. 입력으로 타깃 리포지토리와 커밋을 받고 프로세스로는 테스트 부트스트랩→아키텍처 문서화→파일 카탈로그→파티셔닝→Hunting 병렬 실행→Verifier 순차 실행→후처리→리포팅→수정안 작성의 단계를 거쳐 출력으로 PR 초안과 인간 판독 가능한 리포트를 생성한다. 이 단계별 분리는 테스트 실행 환경 충돌을 막고, 재사용 가능한 아티팩트를 남겨 후속 스캔 비용을 절감하는 운영적 이점을 제공한다.

테스트 오라클로 취약성 입증하는 방법

웹 취약성은 메모리 안전성처럼 컴파일러 플래그로 자동 검증되는 오라클이 드물다는 문제를 제시했다. Shopify는 Verifier 에이전트가 후보를 받아 앱의 기존 통합·기능 테스트 파이프라인에 맞게 픽스처와 크로스-테넌시 조건을 생성하고 실제 퍼블릭 콜사이트를 거꾸로 추적하여 검증을 실행하는 방식으로 문제를 해결했다는 구현 방식을 채택했다. 이 검증 규칙은 단위 모델 테스트만으로는 판단하지 않고 두 개 테넌트 픽스처 생성, 공용 스택을 통한 검증, 중요 업스트림 제어의 비스텁 금지 등을 요구하여 오탐을 낮추는 근거를 제공했다.

파티셔닝과 비용-정확도 절충 설계

모든 파일을 대상으로 전체 에이전트 파이프라인을 돌리면 비용이 급증한다는 절박한 문제가 있었다는 관찰이 있었다. 해결책으로 파티셔닝은 파일을 도메인이나 기능 단위로 묶어 모델의 컨텍스트 윈도우 가운데 20~30% 수준을 토큰 예산으로 남기면서 코드 탐색과 툴 사용을 허용하는 방식으로 구현되었다는 구체적 절차를 제시했다. 벤치마크 실험에서 파티셔닝을 적용했을 때 비용을 낮추면서 정확도와 재현율이 개선되는 결과를 확인했다고 보고했으며 이로 인해 전체 스캔 비용을 $50~$300, 증분 스캔을 $5~$50으로 운영할 수 있었다는 근거가 제시되었다.

근거

전체 애플리케이션 스캔 비용 범위는 $50~$300이고 증분 디프 스캔은 $5~$50이다 — 'The results' 단락에서 비용 범위가 수치로 제시되어 있음

운영 결과와 가치 산정

해당 워크플로우로 Shopify는 80개가 넘는 애플리케이션을 완전 스캔했고 수천 건의 개별 스캔을 수 주간 실행했다는 운영적 사실을 보고했다. 결과로 300건 이상의 파인딩을 도출했고 보수적으로 이 가치를 버그 바운티 등가액으로 환산하면 $400,000 이상으로 평가된다는 수치 증거를 제시했다. 이 중 두 건은 내부 심각도 산정기준상 Critical에 해당한다고 보고되어 도출된 결과의 실무적 중요성을 입증했다.

근거

완전한 애플리케이션 스캔을 80개 이상 수행했다 — 본문 'The results' 단락에 운영 규모와 애플리케이션 수가 명시되어 있음
스캔으로 300건 이상의 파인딩을 생성했고 보수적으로 $400,000 이상의 가치를 평가했다 — 'The results' 단락에서 발견 수와 등가 보상 가치가 제시되어 있음

용어 해설

에이전틱 하네스(agentic harness): — 에이전틱 하네스는 에이전트들을 오케스트레이션하여 코드 탐지→검증 테스트 실행→수정안 작성 흐름을 자동화하는 시스템이다. 입력으로 리포지토리와 변경점(diff)을 받고 파티셔닝과 문서화 아티팩트를 생성하며 출력으로 검증된 리포트와 PR 초안을 생성한다. 모델 교체에 따라 하네스만 유지·개선하면 성능은 재현 가능하다는 점에서 실무적 이점이 있다.
테스트 오라클(test oracle): — 테스트 오라클은 후보 취약점의 실체성을 검증하기 위해 기존 애플리케이션의 통합·기능 테스트로 재현 가능한 검증 코드를 생성하는 구성요소이다. 입력으로 후보 취약점과 앱의 테스트 스위트를 받고 프로세스로는 격리된 픽스처와 크로스-테넌트 조건을 만들며 출력으로 통과·실패 결과를 남긴다. 이 결과를 기준으로 심각도를 확정하거나 거부함으로써 오탐을 크게 줄이는 역할을 한다.
파티셔닝(partitioning): — 파티셔닝은 리포지토리 파일을 도메인·기능·공유 의존성 기준으로 묶어 각 에이전트가 처리할 토큰량을 제한하는 절차이다. 입력으로 파일 카탈로그를 받고 처리 과정에서 모델 컨텍스트의 20~30% 수준의 토큰 예산을 목표로 묶음을 생성하며 출력으로 JSON 파티션 아티팩트를 생성한다. 이 방식은 비용을 낮추면서 recall과 정확도를 개선하는 경험적 근거가 확보된 방법이다.
디프 기반 스캔(diff-based scan): — 디프 기반 스캔은 최신 커밋과 이전 커밋의 차이만 검사하여 다음 스캔의 입력을 좁히는 검사 전략이다. 입력으로 이전 스캔의 영속화된 아티팩트와 새 커밋을 받고 프로세스로는 변경 파일만 재파티셔닝·문서화하여 출력으로 갱신된 아티팩트와 제한된 스캔 결과를 제공한다. 이 접근은 토큰 소비를 크게 줄여 증분 비용을 $5~$50 수준으로 유지하는 근거가 된다.

기술

Dispatch
Ruby
Rails
integration tests
Git
PR

언급된 리소스

문서원문 링크