원문 캡처 · github.com
원문 캡처 · github.com

SelfBench는 병합된 PR을 과제로 만들고 숨겨진 테스트로 검증해, 코딩 에이전트와 모델이 실제 저장소 코드에서 얼마나 정확하게 작업하는지 비용과 함께 비교한다. 저장소에 맞는 모델을 찾으려는 팀에 쓸모가 있다.

이게 뭔데?

SelfBench는 저장소의 과거 변경을 이용해 코딩 에이전트 벤치마크를 만드는 도구다. 과제 모음은 시험 문제집을 떠올리면 쉽다. 각 PR의 요청이 지시문이 되고, 숨겨진 테스트와 기준 솔루션이 과제의 정답 여부를 가린다.

과제는 어떻게 검증하나?

각 병합 PR에 대해 SelfBench는 변경 전 커밋에서 과제를 다시 만든다. PR에 적힌 요청을 지시문으로 사용하고, 과제 작성 에이전트가 숨겨진 테스트와 기준 솔루션을 작성한다. 과제는 솔루션 없이 테스트가 실패하고, 원래 구현을 적용하면 통과해야 한다. 다시 실행해도 통과해야 하며, 별도의 독립 검토도 통과해야 한다. 승인된 과제는 모두 Harbor 형식의 과제다.

오픈소스 저장소가 selfbench.dev에 공개되면 실시간 리더보드가 제공된다. 모델, 하네스(에이전트를 실행하는 도구), 추론 설정을 과제당 정확도와 비용으로 비교한다. 두 기준 모두에서 더 나은 설정이 없는 지점을 파레토 경계로 표시한다. 공개된 리더보드에는 vercel/next.js, supabase/supabase, earendil-works/pi, getsentry/sentry, PostHog/posthog, pingdotgg/t3code, vercel/vercel이 있으며, 전체 저장소 목록도 제공한다.

직접 사용하려면 무엇을 하면 되나?

웹 앱 app.selfbench.dev에서 작업한다.

  1. GitHub로 로그인하고 저장소를 연결한다.
  2. Batch Generation에서 난도별로 만들 쉬움·보통·어려움 과제 수를 선택한다. 또는 Dataset 페이지의 Add PRs를 눌러 선택한 각 PR에서 과제 하나씩 만든다. 배치 생성에는 몇 시간이 걸리며, 페이지를 닫아도 계속 진행된다.
  3. Dataset에서 지시문, 실행 환경, 숨겨진 테스트, 기준 패치, 파이프라인 산출물을 확인한 뒤 과제를 승인하거나 거부한다.
  4. Run에서 모델, 하네스, 샌드박스를 선택하고 승인된 과제에 실행한다.
  5. Results에서 정확도와 비용을 비교하고, 각 실행(trial)의 대화 기록과 점수를 열어 볼 수 있다.
  6. Releases에서 공개 저장소의 결과를 selfbench.dev에 게시한다.

모델과 샌드박스는 Credentials에 등록한 조직 자체의 키로 실행한다. 공개된 결과는 Public Results API로 읽을 수 있고, API 키를 사용해 워크스페이스 작업을 자동화할 수도 있다.

자체 호스팅과 개발에는 무엇이 필요한가?

SelfBench의 기준 배포 구성은 GCP를 사용한다. Cloud Run이 API를 제공하고, GKE Autopilot이 Temporal 워크플로 작업자와 KEDA로 규모를 조절하는 Harbor 작업을 실행한다. Cloud SQL과 GCS도 사용한다. 대안으로 Cloud Run 작업자 풀을 선택할 수 있다.

자체 호스팅 단계는 다음과 같다.

  1. GCP 프로젝트와 결제, Terraform 상태 버킷, GitHub Actions Workload Identity Federation을 준비한다.
  2. Terraform 입력값을 설정하고 각 런타임 비밀 값을 각각의 Secret Manager 비밀 항목에 저장한다.
  3. Terraform으로 환경을 적용하거나, 보호된 GitHub dev 및 prod 환경을 설정해 Actions로 배포한다.
  4. 도메인을 생성된 로드 밸런서에 연결하고 앱 URL에 맞게 GitHub OAuth를 설정한다.

사전 요건, 정확한 Terraform 명령, 런타임 설정, GitHub Actions 설정, GKE 작업자 설정은 자체 호스팅 및 인프라 가이드에서 다룬다.

개발 환경에는 Bun 1.3.14 이상과 Docker 및 Compose가 필요하다. 의존성을 설치하고 검증하려면 다음을 실행한다.

bun install --frozen-lockfile
bun run validate

체크아웃한 저장소에서 API와 앱, 작업자, Temporal, Postgres, 로컬 Docker 샌드박스를 포함한 전체 스택을 실행하는 명령은 다음과 같다.

cp .env.example .env # GitHub OAuth app, session secret, credential key, managed keys
SELFBENCH_PUBLIC_URL=https://your-tunnel.example docker compose --profile sandbox up -d --build
docker compose port api 8080

Compose는 체크아웃 디렉터리 이름을 프로젝트 이름으로 사용하고, 호스트 포트를 임시로 할당한다. 따라서 여러 작업 트리를 나란히 실행할 수 있다. 실행 전에 SELFBENCH_PUBLIC_URL을 브라우저가 접속할 출처(터널 또는 리버스 프록시 주소)로 설정하고, OAuth 앱에 <origin>/auth/github/callback을 등록해야 한다. 프런트엔드 작업에는 bun run dev:site를 사용하면 API와 Vite를 핫 리로드로 실행한다. 비밀 값은 .env.site에 두며, 자세한 내용은 scripts/dev-site.ts에 있다.

문서에는 Mintlify 가이드, 공개 결과 API와 워크스페이스 API, 작동 방식 및 과제 유효성 설명, 인프라 가이드가 포함된다. 문서 개발 서버는 cd docs && npm ci && npm run dev로 실행한다. 라이선스는 MIT이며 저작권 표기는 © 2026 Mupt AI다.

사용을 시작하려면 저장소 연결 후 생성된 과제를 검토하고 승인해야 한다. 원문은 서비스 가격을 밝히지 않는다.