Delphik의 벤치마크 결함 연구와 공개 운영 방법

확인일: 2026-09-19 KST. 소유자: Environment Foundry. 이 문서는 공개 자료에 대한 연구 메모이며, Delphik의 운영 성과를 독립 검증한 보고서는 아니다.

공개 근거는 세 종류로 나뉜다. TVB 논문은 이미 알려진 결함을 LLM이 다시 찾는지 평가한다. open-defect는 GitHub의 결함 제보를 확인하고 장부로 정리하는 운영 코드다. 홈페이지의 납품 검수·가격 비교·보증은 서비스 제공자의 설명이다. 한쪽의 존재를 다른 쪽의 성능 증거로 사용하면 안 된다.

이 문서의 표지는 SITE CLAIM(사이트·작성자 주장), PAPER CLAIM(논문 보고), CODE OBSERVED(직접 읽은 공개 코드), INFERENCE(이 연구의 판단), UNKNOWN(확인하지 못한 사항)이다. 코드나 JSON에서 L3, confirmed, fixed를 읽었다는 사실은 우리가 그 실행을 재현했다는 뜻이 아니다.

1. 논문과 공개물의 정확한 위치

공식 DL4C 2026 Poster 목록에 Can LLMs Detect Benchmark Defects? A Meta-Benchmark from Benchmark Updates가 올라 있고 OpenReview QdDcI0Ftvo로 연결된다. 공식 CFP는 DL4C를 non-archival 워크숍으로 설명한다. 따라서 ‘ICML 2026 DL4C 워크숍 포스터’라고 부르는 것이 정확하다. ICML 본회의 논문이나 PMLR 본회의 논문으로 확인한 것은 아니다.

5월 15일 블로그는 부제를 Benchmark Version Diffs라고 쓰며 제출 상태로 남아 있다. 현재 그 페이지에서 내려받는 PDF는 12쪽이고 첫 장에 Preprint. May 20, 2026이라고 적혀 있다. 블로그와 PDF를 같은 버전으로 합치지 않았다. PDF SHA-256은 ec2d2241816f3e30c6071aa650913d3779d55947512715b5f8bf963140630620이다. 웹서버의 Last-Modified는 논문의 작성일이나 학회 확정일이 아니다.

논문의 핵심 수치·실험 조건은 짧은 한국어 요약에 모았다. 원문 전문과 전체 번역은 복제·번역 라이선스를 확인하지 못해 보관하지 않았다. 저자가 제공하는 한국어 블로그는 별도 외부 링크로 읽을 수 있다.

UNKNOWN: TVB의 정확한 평가 코드, 동결된 최종 task 목록, 원본 실행 결과, prompt 파일을 공개 저장소에서 찾지 못했다. 블로그는 코드와 데이터의 향후 공개를 예고한다. 공개 조직 저장소에서 찾은 open-defect와 humaneval-gradient-fp는 TVB 평가 harness와 다른 프로젝트다. OpenReview 포럼은 browser challenge, 공개 notes API는 403으로 세부 메타데이터를 확인하지 못했다.

2. 서비스가 설명하는 운영

SITE CLAIM: 홈페이지는 공급업체 비교, 무작위 표본 재측정, 납품 배치 검수, 결함 보증, 환경 점검을 제공한다고 설명한다. 공급업체 수, 실제 거래가격, 고객 효과는 공개 자료만으로 검증하지 않았다. 연구자 페이지는 제보→분류·중복 제거→upstream 수정→근거 확인→기여 표시 흐름을 설명한다. fixed 표시는 유지관리자의 변경 근거를 가리켜야 하며, 접수나 PR 생성만으로 수정 완료가 되는 것은 아니다.

공개 report-defect 스킬은 task ID와 버전, 문제의 원인, 선택적인 실행 기록을 모으도록 한다. ID의 우선순위는 task 정의→실행 메타데이터→trajectory→폴더 이름이며, 공개 catalog의 실제 task와 대조한다. 스킬은 외부 제출 전에 설명과 첨부를 사용자에게 보여주도록 한다. 이 저장소에 TVB 판정 모델이나 TVB 점수 계산 코드는 없다. 라이선스 파일이 없어 전체 스킬 원문은 로컬에 복제하지 않았다.

3. 공개 코드에서 확인한 감사 흐름

기준 저장소는 delphik-ai/open-defect, commit e7938081c5592c5cc368162a47504adca037f64e다. 선택한 원문은 source-code-manifest.json에 URL, commit, SHA-256, 라이선스와 함께 보관했다. 코드는 Apache-2.0, 공개 결함 장부 데이터는 CC BY 4.0이다. upstream issue·댓글·diff의 권리까지 이 라이선스로 바뀌지는 않는다.

코드 위치: fetch, prepare, apply, validate, sync.

공개 스크립트 자체가 LLM API를 호출해 모든 의미 판단을 자동으로 끝내지는 않는다. 판단 절차는 Codex runbook에 적혀 있고, 결과 필드는 에이전트가 채운다. 이 구조로부터 실제 운영 시 쓴 모델, reasoning effort, 세션별 prompt, 실행비용을 역으로 확정할 수는 없다.

4. 데이터 단위와 상태

장부는 GitHub thread, root cause, task를 같은 단위로 세지 않는다. 하나의 thread가 여러 원인을 포함하면 suffix로 구분할 수 있고, 하나의 결함이 여러 task에 영향을 줄 수 있다. task_specific은 현재 task 이름 목록을 요구한다. benchmark_level은 task 목록이 비어 있으며 harness 전체 문제처럼 별도로 센다. 같은 task에 여러 결함이 있으면 서로 다른 상태 bucket에 동시에 들어갈 수 있다. 그러므로 화면의 bucket 합은 고유 task 수와 같다고 가정할 수 없다. 규칙과 예시

수정 상태는 별도의 축이다. found는 발견, fixing은 수정 진행, fixed는 병합·fix commit 등 근거가 있는 상태다. issue closed를 자동으로 fixed로 옮기지 않는다는 지침과, resolution 값을 실제로 갱신하는 코드를 함께 확인했다. upstream 상태가 바뀌면 원문을 다시 대조해야 한다.

defect_type_main, defect_type_sub는 artifact schema에서 선택적인 문자열이다. 논문의 여섯 범주를 강제하는 enum이 아니다. 실제 장부에는 Evaluation correctness, Dataset selection bug, harness, prompt_formatting 등도 나타난다. 논문 taxonomy와 운영 taxonomy를 같은 열로 강제 매핑하면 의미가 달라질 수 있다.

5. L1·L2·L3의 차이

다음은 공개 runbook의 지침이다. 실제 모든 기록이 이 지침을 만족한다는 독립 확인은 아니다.

• L1: thread 본문·댓글·연결 PR만으로 귀속, 결함, 중복, 범위, 해결 상태를 확인한다.
• L2: thread만으로 부족하면 diff, source, task artifact, task 표를 읽는다. 여러 task에 걸친 주장은 upstream 병합, 유지관리자 확인, 회귀 테스트 같은 근거도 요구한다.
• L3: 실행으로 원인과 결과를 확인한다. 범위가 큰데 upstream 확인이 없거나 Docker·빌드·parser 동작을 읽기만 해서 판단하기 어려우면 요구된다. oracle pass만으로 끝내지 않고 주장한 실패 signature를 확인한다.

수정안은 가능하면 pre-fix 실패와 post-fix 성공을 비교한다. flaky 주장에 대한 한 번의 성공은 한 번 재현됐다는 뜻만 가진다. 영향을 받는 task가 20개 이하면 전부, 더 많으면 SHA-256(seed + task_name) 순서의 5개를 보도록 규정하며 기본 seed는 defect ID다. 이 seed 규칙은 open-defect 운영 지침이다. TVB 논문 실험의 seed라고 옮겨 쓰면 안 된다.

일부 장부에는 이전 DB를 이전하면서 audit_level을 추정했다는 migration.legacy_audit_level_inferred가 있다. 예를 들어 원문이 L2라도 당시에 실제 수행한 source audit 기록과 동일한 증거라고 볼 수 없다. 관련 JSON에서 이 차이를 직접 확인했다. 예시

6. 이번 로컬 실험에 사용할 수 있는 근거

구체적 case와 code path는 source-case-manifest.json에 있다. LiveCodeBench는 MIT 원문을 저장했고, Terminal-Bench는 Apache-2.0 원문과 PR 제안본을 저장했다. Aider Go 문제는 해당 subtree의 라이선스를 확인하지 못했고 CRUST Rust 문제는 permissive 라이선스로 확인되지 않아, 원문 전문 대신 설명과 독립적인 수학·코드 재구성을 사용한다.

INFERENCE: 이 사례로 만들 수 있는 것은 공개 결함 메커니즘에 근거한 작은 감사 실험이다. 코드 몇 줄의 버그를 찾은 결과를 전체 벤치마크의 Docker 환경, 실제 task 수행, 전체 verifier, 상용 납품 검수 성능으로 확대하면 안 된다. 원문 그대로 추출한 함수와 직접 작성한 재구성 함수도 따로 표시해야 한다.

권장 비교는 같은 결함 메커니즘에 대해 결함본과 수리한 대조본을 모두 숨겨서 제시하는 방식이다. ‘defect’만 반복하는 모델은 결함본에서는 맞아도 대조본에서 오탐을 낸다. 두 버전은 같은 split에 두고, few-shot과 heldout은 source family를 분리한다. 같은 PR에서 온 서로 비슷한 수정 두 개를 독립 표본 두 개처럼 계산하지 않는다.

평가는 세 축을 기록한다. 첫째는 defect/valid 판정이다. 둘째는 어떤 입력·조건에서 어떤 코드 경로가 잘못 작동하는지 짚은 원인 일치다. 셋째는 그 주장을 실행했을 때 결함본에서 관측되고 수리본에서 사라지는지다. 마지막 축까지 통과해야 locally reproduced라고 부를 수 있다. 이 판정은 논문의 LLM judge를 복제했다는 뜻이 아니다.

반복 실험은 같은 고정 입력을 최소 다섯 번 주되 반복 ID, prompt hash, model ID, tool 권한, 결과 schema, wall time과 실제 token usage를 남긴다. 제공자가 seed를 노출하지 않으면 seed unavailable로 기록한다. 같은 모델의 다섯 반복은 다섯 모델의 독립 증거가 아니다. 주된 독립 단위는 root cause와 source family이며, 작은 사례군의 표준편차를 일반화 신뢰구간처럼 제시하지 않는다.

발견 실험은 알려진 정답 평가와 분리한다. 아직 이 pilot의 예시나 정답으로 사용하지 않은 HumanEval evaluator 원문을 후보로 저장했다. ‘이 pilot에서 아직 제시하지 않았다’는 뜻이며 모델의 학습 이력에서 본 적 없다는 뜻은 아니다. 거기서 나온 제안은 재현, 범위 확인, 알려진 issue 중복 확인을 마칠 때까지 new candidate다.

7. 과도한 결론을 막는 해석 기준

INFERENCE: 유지관리 기록에서 얻은 정답은 실제 결함 근거를 제공하지만, 보이지 않은 결함까지 없다고 보장하지 않는다. PR이 수정한 사실과 모든 수정이 심각한 결함이라는 주장은 다르다. 샘플을 만들 때 버전, scope, 정답 제외 이유를 남겨야 한다.

기존 root cause에 딱 맞추는 recall과 새로운 결함을 발견하는 능력도 다른 목표다. GT와 다른데 실제로 재현되는 결과는 바로 오답으로 버리지 말고 별도의 신규 후보로 검토해야 한다. 반대로 그럴듯한 설명이나 ‘possible’ 같은 유보 표현만으로 defect 양성으로 세면 진단 가치가 부풀려진다.

소규모 반복의 개선은 해당 prompt와 사례의 변화다. ‘Delphik보다 우수하다’, ‘TVB를 재현했다’, ‘RL training을 개선했다’는 결론에는 각각 상대 시스템 접근, 같은 task·budget·judge 조건, 실제 학습 후 heldout 평가가 추가로 필요하다. 이번 소스 조사에서 확보한 근거는 그 단계까지 가지 않는다.

UNKNOWN: 상용 검수의 누락률·오탐률·비용, 실제 고객 효과, 사람 검토시간, TVB의 정확한 실행 예산, stochastic verifier 반복률, 공개하지 않은 task 품질은 알 수 없다. CLI 구독으로 실행한 로컬 pilot도 API 달러 비용으로 임의 환산하지 않는다.