Defect 루프: 캡처, 감사, 노출, 재평가
벤치마크는 패치되고 기준은 계속 움직이는데, 리더보드는 정작 어떤 버전을 돌렸는지 말해주지 않습니다. 이 문제를 풀려고 만든 루프 전체를 소개합니다. 모든 defect를 캡처하고, 하나의 공개 store로 감사하고, 어디에서나 노출하고, 그 위에서 평가합니다.
Terminal-Bench이 2.1을 내면서 89개 task 중 28개를 패치했는데, 그 즉시 모든 모델의 점수가 6~12점씩 뛰었습니다. Opus 4.6은 12.1점 올랐죠. 그 주에 더 좋은 모델이 나온 게 아닙니다. 자(尺)가 바뀐 겁니다. (Terminal-Bench 팀에 크레딧을 보냅니다. 버전을 나누고 모든 delta를 공개했죠. 대부분의 벤치마크는 그냥 조용히 in-place로 패치하고 맙니다.)
그러니 패치 전후의 점수는 같은 측정값이 아닙니다. 그런데 리더보드와 system card는 어떤 commit을 돌렸는지 거의 밝히지 않죠. 이번 릴리스에서 순위 자체는 대체로 유지됐지만 margin은 그렇지 않았습니다. 결함 있는 버전에서 한 번 재고 그대로 박제한 숫자는, 모든 점수를 두 자릿수로 움직이는 패치를 버텨내지 못합니다.
이 일은 계속 반복됩니다. 벤치마크에 결함이 있고, 그게 고쳐지고, 기준은 계속 움직입니다. 무언가를 공정하게 비교하려면 지금은 없는 두 가지가 필요합니다. 어떤 task가 깨졌는지에 대한 공유된 실시간 기록, 그리고 그걸 우회해서 평가하는 방법입니다.
지금 그 기록은 GitHub인데, 그걸로는 부족합니다
지금 그 기록은 GitHub 이슈와 PR입니다. 토론과 패치에는 맞는 자리고, 거기 있어야 합니다. 하지만 진짜 결함은 docs, 기능 요청, 그리고 task 여섯 개를 조용히 깨뜨리는 한 스레드 밑에 묻혀 있습니다. 모든 repo에 흩어져 있고, 실시간 상태도 없죠. GitHub은 대화와 merge를 담지, 벤치마크를 담지 못합니다. 이슈 하나로는 깨진 task도, 영향받는 버전도, 결함을 드러낸 trajectory도, 점수에 미친 영향도 실을 수 없습니다.
그래서 우리는 루프 전체를 만들었습니다. 모든 defect를 캡처 → 하나의 공개 store로 감사 → 어디에서나 노출 → 연속 재평가.
캡처 & 큐레이션 → Open Defect
defect는 두 곳에서 옵니다. 앞서 말한 upstream GitHub 스레드, 그리고 /report-defect입니다. eval 도중 깨진 task를 마주쳤을 때 에이전트의 trajectory를 증거로 붙여 한 줄로 신고하는 것이죠. LLM이 각 소스를 읽고, 노이즈를 걸러내고, 멀티-task 스레드를 쪼개서, task당 깨끗한 레코드 하나를 씁니다. 원인이 짚혀 있고, 증거가 링크돼 있고, PR로 고칠 수 있는 형태로요.
그 결과물이 Open Defect, task별로 정리된 공개 ledger입니다. 이 글을 쓰는 시점 기준으로 465개의 확정 defect가 우리가 추적하는 72개 벤치마크 중 40개에 걸쳐 있습니다. 62개는 아직 open, 48개는 수정 진행 중, 355개는 fixed. 각 레코드에는 그 defect가 루프의 어디에 있는지와 출처 upstream 스레드가 담깁니다. 전형적인 예가 SWE-bench Verified의 sympy-13031입니다. 문제 설명은 DenseMatrix를 고치라 하는데 정답 패치는 SparseMatrix(다른 클래스)를 바꿉니다. task와 그 “정답”이 어긋나는 거죠 (issue #514).
open이고 PR로 고칠 수 있습니다. 틀렸거나 빠진 항목은 pull request로 바로잡을 수 있죠. platform은 우리 것이고, 데이터는 open입니다.
노출, 당신이 일하는 모든 곳에서
defect 레코드는 그 defect를 마주칠 자리에 있어야 쓸모가 있습니다. 그래서 같은 store를 네 가지로 노출합니다.
- README health badge: 벤치마크 README에 found → fixing → fixed 실시간 상태. “maintained”를 가정이 아니라 눈에 보이게.
- Delphik Web: posttrain.dev/benchmarks에서 모든 defect 탐색.
- Raw JSON: ledger 전체를 repo에서 그대로.
- CLI (
pip install delphik): 터미널에서 open-defect 세트를 바로 받아, 깨진 task를 빼고, 버전을 핀으로 박고, 자기만의 공정한 eval을 돌립니다.
CLI는 오늘 라이브입니다. open-defect repo를 직접 읽어 필요한 Harbor exclude 인자를 그대로 뽑아 줍니다. 누구의 리더보드도 기다릴 필요 없이 깨진 task를 빼고 버전을 핀으로 박은 깨끗한 eval을 돌릴 수 있죠.

delphik defects <benchmark>가 깨졌거나 진행 중인 task를 나열하고, 버전을 핀으로 박은 Harbor 실행에 그대로 넣어 줍니다. (예시 이미지이며, 숫자는 ledger 업데이트에 따라 달라집니다.)만들고 있는 것: 연속, task 단위 평가
지향점은 패치 한 번으로 조용히 흔들리지 않는 리더보드입니다. open defect는 점수에서 빼 두고, 하나가 고쳐지는 순간 그 task만 모든 모델에 대해 다시 돌리고, 모든 점수를 commit id에 핀으로 박습니다. 그래서 어떤 두 모델이든 항상 같은 깨끗한 세트 위에서 비교되고, 2.0 vs 2.1 불일치가 순위를 몰래 움직일 수 없습니다. 모든 결과는 감사 가능합니다. pass든 fail이든 클릭하면 에이전트의 전체 trajectory가 열립니다.
그리고 리더보드 자체도 open입니다. 믿어야만 하는 블랙박스가 아니라, 누구나 재현하고, 검증하고, 자기 실행을 추가할 수 있는 공개 repo죠. 이 부분은 아직 만드는 중입니다. 오늘 라이브인 것은 Open Defect ledger, health badge, CLI입니다.

써 보기
전부 open이고 아직 초기입니다. 피드백, 정정, PR 모두 환영합니다.
- defect 탐색: github.com/delphik-ai/open-defect · posttrain.dev/benchmarks
- 깨끗한 eval 실행:
pip install delphik후delphik defects <benchmark> - 다음에 마주친 깨진 task 신고:
npx skills add delphik-ai/delphik --skill report-defect
벤치마크 품질 시리즈의 세 번째 글입니다. 누가 defect를 찾는가, 찾은 다음 무슨 일이 일어나는가, 그리고 이 글, 캡처를 고쳐진 점수로 잇는 루프.
