알려진 결함 예시는 새로운 감사를 돕는가?
출처를 분리한 벤치마크 결함 탐지의 소규모 반복 실험
Environment Foundry · Defect Lab technical report v1 · 2026-09-19
상태: 로컬 연구 초고. 동료 심사나 외부 등록을 거치지 않았다. 설계·구현·실행·분석에는 AI 에이전트를 사용했다. 연구 책임과 최종 통합은 Astra, 구현은 Sol, 공개 목록 정리는 Luna가 맡았다. 평가 대상 모델은 GPT-5.5 high다.
초록
벤치마크 결함을 LLM에 알려주면 다른 결함을 더 잘 찾을 수 있는지 조사했다. 공개 기록에서 도출한 7개 결함 메커니즘을 짧은 Python 함수로 독립 재구성하고, 각각의 수리 대조군과 정보가 부족한 2개 사례를 만들었다. 예시에는 평가와 다른 벤치마크 계열의 결함 2개를 사용했다. 동일한 16개 사례에서 예시 없는 조건과 예시 제공 조건을 5쌍 반복했다. 수리 전후가 같은 문맥에 노출되지 않도록 조건마다 두 호출로 나눴으며, 실제 모델 호출은 총 20회였다. 두 조건의 반복 평균 F1은 모두 0.9867, recall은 1.0000이었다. 정상 대조군에 대한 오탐은 조건별 35회 판단 중 각각 1회였다. 이 작은 표본에서 예시의 개선 효과를 관측하지 못했다. 별도 HumanEval 원문 탐색에서는 Python 최적화 옵션에 따라 누락된 문제를 거르는 검사가 사라지는 동작을 재현했으나, 의도된 실행 조건과 신규성은 확인하지 못했다. 결과를 영속 저장, 근거와 판정의 연결, 한국어 검토 화면을 갖춘 로컬 도구로 제공한다.
1. 질문과 선행 연구의 위치
Task Verification Bench(TVB)는 유지관리 기록에서 얻은 결함을 LLM이 원래 task에서 다시 찾는지 평가한다. 현재 저자 PDF와 공식 목록을 대조하면 해당 연구는 ICML 2026 DL4C 워크숍 포스터이며 본회의 논문으로 확인된 것은 아니다. 현재 PDF와 앞선 블로그의 제목·표본·수치는 구분해야 한다. 정확한 최종 평가 데이터, prompt와 실행 결과는 공개 자료에서 찾지 못했다. 저자 PDF, 공식 포스터 목록, 워크숍 안내
이 보고서는 TVB를 재현한 결과가 아니다. 질문은 다음 세 가지다.
- 다른 벤치마크 계열의 결함 예시가 고정 평가셋의 판별을 개선하는가?
- 결함 판단에 붙은 위치와 반례가 실제 코드 동작을 설명하는가? 정상 코드를 얼마나 자주 의심하는가?
- 별도 원문 코드에서 나온 후보를 재현된 동작, 유효한 결함, 신규 발견으로 구분할 수 있는가?
사전 가설 H1은 예시 제공이 F1과 유효 반례 수를 높이고 정상 대조군의 위양성률은 높이지 않는다는 것이었다. 로컬 사전 계획·데이터·러너·채점기 등 10개 파일의 해시를 첫 평가 호출 전에 고정했다. 타임스탬프는 외부 사전등록 증명이 아니며, 제공자의 sampling seed를 통제하지 못했다.
2. 자료와 누출 통제
실험 단위는 완전한 벤치마크 task가 아니라 명시적 계약을 가진 짧은 재구성 코드다. 공개 코드의 동작 또는 공개 장부의 메커니즘을 토대로 직접 작성했다. 상류 보고, 상류 코드 읽기, 자체 재현을 각각 provenance에 남겼다. 모든 양성 라벨이 유지관리자에게 확인된 결함인 것은 아니다.
| 평가 계열 | 메커니즘 | 이번 검증의 범위 |
|---|---|---|
| LiveCodeBench | wheel 하위 패키지 누락 | 패키지 선택을 모델링한 함수 |
| LiveCodeBench | not-fast 경로의 날짜 필터 누락 | 날짜와 행 목록의 순수 함수 |
| LiveCodeBench | dict를 속성으로 접근 | 입력 행 정렬과 필드 접근 |
| LiveCodeBench | fence 없는 코드의 추출 실패 | 제한된 입력 형식에서의 추출 |
| Terminal-Bench 2 | 추가 생성 파일까지 거부 | 필수 파일 존재 계약 |
| CRUST | 낮은 false-positive 비율도 실패 | 허용 상한에 대한 수학적 재구성 |
| Aider Polyglot | 테스트 0개를 성공 처리 | 비어 있는 결과 목록의 합격 판정 |
각 메커니즘에는 저자가 수리한 정상 대조군을 붙였다. clean은 주어진 계약과 검사 범위에서의 라벨이며 상류 전체가 무결함이라는 뜻이 아니다. 정보가 없는 외부 함수 두 개는 unknown으로 뒀다. 합계는 defect 7, clean 7, unknown 2다. 출처별 연결과 버전은 dataset/provenance.json 및 자료집의 source manifest에 있다.
예시는 BFCL의 ID 구분자 불일치와 SWE-bench의 출력·종료 코드 불일치에서 만들었다. 형식 점검에만 쓴 개발셋은 자체 작성한 별도 두 문제다. 예시와 평가의 source family·메커니즘·수정 쌍은 겹치지 않는다. 수정 쌍은 같은 평가 split 안에 있지만 한 호출에서 함께 보여주지 않았다. 모델 입력에서는 이슈 제목, URL, 패치, 출처 이름, 정답 라벨을 제거했다. 검색과 shell은 비활성화했고, 도구를 사용한 호출은 무효 처리하도록 설계했다. 실제 20회 모두 도구 사용이 없었다.
일부 출처는 해석에 주의가 필요하다. Terminal-Bench PR #53은 병합된 수정이 아니며, fence 없는 코드의 허용 여부는 원래 실행 계약에 달려 있다. dict 접근 사례는 자료 조사 중 확인한 코드 메커니즘으로, 모델의 신규 발견이 아니다. 사전학습에서 공개 코드를 보았을 가능성도 남는다. 출처를 가리는 것만으로 오염이 제거되지는 않는다.
3. 모델, 반복, 채점
기존 ChatGPT 로그인으로 사용 가능한 Codex CLI 0.142.5의 GPT-5.5, reasoning high를 사용했다. API 키나 신규 유료 자원을 구매하지 않았다. 모델로 보낸 것은 공개 정보와 자체 작성 사례다. 주 연구 에이전트인 Astra와 평가 대상 GPT-5.5를 구분한다.
순서 seed 101·202·303·404·505로 다섯 블록을 만들었다. 블록 안에서 baseline과 few-shot은 같은 사례와 순서를 사용하고 조건 순서를 번갈아 배치했다. 각 조건의 수정 전후 쌍을 두 개의 새 세션으로 나눠 총 20회 호출했다. seed는 입력 순서에만 적용되며 provider sampling seed와 temperature는 미상이다. 이 반복은 모델 출력의 변동을 보는 것으로, 다섯 독립 데이터셋이나 다섯 연구가 아니다.
출력은 판정, 결함 줄, 원인 설명, JSON 반례다. 알려진 라벨에 대한 precision·recall·F1·정상 위양성률을 계산했다. unknown 두 개는 이진 점수에서 제외하고 보류 판단을 따로 셌다. 위치는 사전 지정 줄과 겹치는지 확인했다. 모델의 JSON 입력을 검토된 고정 함수와 계약 함수에 넣어 실제 차이를 검사했다. 모델이 생성한 코드는 실행하지 않았다. 원인 설명은 보존했지만 의미 일치 점수는 계산하지 않았다. 이 결과를 TVB의 root-cause precision으로 부르면 안 된다.
4. 결과
| 반복 | baseline F1 | 예시 제공 F1 | baseline 오탐 | 예시 제공 오탐 |
|---|---|---|---|---|
| 1 | 0.9333 | 1.0000 | 1 | 0 |
| 2 | 1.0000 | 0.9333 | 0 | 1 |
| 3 | 1.0000 | 1.0000 | 0 | 0 |
| 4 | 1.0000 | 1.0000 | 0 | 0 |
| 5 | 1.0000 | 1.0000 | 0 | 0 |
| 반복 평균 | 0.9867 | 0.9867 | 0.2 | 0.2 |
두 조건의 평균 precision은 0.9750, recall은 1.0000, 정상 위양성률은 0.0286이었다. 조건별 defect 판단 35/35에서 위치를 맞췄고, 유효한 반례가 재구성 함수의 잘못된 동작을 보였다. 이는 7개 고유 메커니즘을 다섯 번 본 35회 판단이다. 독립 결함 35개를 찾은 것이 아니다. 조건별 unknown 10/10 판단은 보류였고, 알려진 사례에서는 보류가 없었다.
평균 F1 차이는 0.0000이다. 블록별 차이는 +0.0667, −0.0667, 0, 0, 0이었다. H1을 뒷받침하지 못했다. 완전한 task보다 쉬운 짧은 코드, 제한된 계약, 네 계열뿐인 표본 때문에 천장 효과가 강하다. 통계적 유의성이나 일반화 신뢰구간을 산출하지 않았다.
반례 1: 문제의 의도까지 추측한 오탐. baseline 첫 반복은 정상 wheel 함수를 보고 “모든 파일을 포함하므로 누락 문제를 모델링하지 못한다”고 지적했다. 그러나 주어진 계약은 모든 패키지 파일을 포함하라는 것이었다. 제출한 입력에서 실제값과 기대값도 같았다. 코드의 계약보다 실험의 숨은 의도를 추정한 판단이다.
반례 2: 계약 밖 입력을 만든 오탐. 예시 제공 두 번째 반복은 정상 추출기에 문자열 내부 backtick이 있을 수 있다고 주장했다. 해당 입력은 사전에 명시한 계약에서 제외돼 있었다. 반례는 out_of_contract로 기각됐다. 더 많은 의심을 생성하는 것과 유효한 결함을 찾는 것은 다른 성능이다.
5. 시간, 사용량, 실행 실패
| 항목 | 봉인 평가 20회 |
|---|---|
| 입력 토큰 | 286,026 |
| 그중 cached input | 150,528 |
| 출력 토큰 | 27,247 |
| 별도 보고된 reasoning output | 14,116 |
| 각 호출 소요시간의 합 | 560.445초 |
| 첫 시작부터 마지막 완료까지 | 313.449초 |
| 실패·도구 사용 | 0 · 0 |
| 결제액 | 미측정 |
캐시 토큰은 입력의 부분집합이다. reasoning token은 제공자가 별도로 보고한 값이며 출력에 다시 더해 총량을 부풀리지 않는다. 두 packet을 병렬 실행하므로 시간 합계와 경과시간은 다르다. 구독 할당량 사용을 비용 0원이라고 해석하지 않았다.
봉인 평가와 별도의 전송 점검에서 요청한 GPT-5.6-Sol이 CLI에서 지원되지 않아 실패했고, 실제 접근을 확인한 GPT-5.5로 실험 계획을 고정했다. 로컬 제품의 첫 MLX 서버는 GPU 스레드 문제로 실패해 단일 메인 스레드 서버로 바꿨다. Qwen2.5-0.5B의 제품 검토는 JSON 형식 실패 2회 후 완료 1회였고 모두 보존했다. 사전 계획의 제품 smoke 2회 상한을 넘긴 세 번째 호출은 프로토콜 이탈이다. 이 과정은 봉인 평가와 다른 모델·경로이며 평가 점수에 포함하지 않았고, 평가 prompt를 수정하지 않았다.
6. 별도 탐색: HumanEval의 최적화 실행 조건
평가에 쓰지 않은 HumanEval evaluator 원문을 별도 새 호출에 제시했다. 모델은 전체 문제의 completion이 있는지 확인하는 assert가 최적화 모드에서 제거될 수 있다고 제안했다. Python 공식 문서도 -O에서 assert가 제거됨을 설명한다.
고정한 원문을 그대로 compile하되 optimize=0과 1을 비교했다. 문제 A·B와 A의 completion 하나만 주고, 데이터 I/O와 정답 검사는 안전한 stub으로 바꿨다. optimize=0은 누락 문제를 이유로 AssertionError를 냈고, optimize=1은 pass@1: 1.0을 반환했다. 평가 코드의 guard와 집계 경로에 대한 조건부 동작 재현이다. 실제 생성 코드를 실행한 HumanEval 점수 실험은 아니다.
이 후보는 아직 신규 결함으로 확정하지 않았다. 의도된 배포가 -O를 지원하는지, 상류가 문제로 인정하는지, 이미 알려진 보고가 있는지 미확인이다. 제한된 공개 검색에서 정확히 일치하는 보고를 찾지 못한 사실은 신규성 증명이 아니다. 앱에는 별도 의심 후보로 남겼다. 외부 제보는 하지 않았다.
7. 도구 구현과 선행 연구와의 비교
독자 구현한 Defect Lab은 benchmark·버전·케이스·증거·LLM 검토·판정·이력을 SQLite에 저장한다. 공개 장부는 출처 상태를 유지한 채 가져오며, 버튼으로 최신 commit을 확인하고 변경을 반영한다. LLM 결과만으로 검증 상태가 되지 않는다. 결정적 재현 또는 독립 검토는 현재 케이스 내용의 해시에 묶이며, 내용이 바뀌면 기존 검증은 의심 상태로 내려간다. 이 구조는 증거의 연결을 검사하는 로컬 도구이며 사용자가 입력한 증거의 진실성을 자동 보증하지 않는다.
| 비교축 | TVB 공개 연구 | 이번 pilot |
|---|---|---|
| 대상 | 실제 task와 유지관리 기록 | 독립 재구성한 짧은 함수 |
| 핵심 질문 | 기존 결함과 원인의 재발견 | 두 예시의 추가 효과와 오탐 |
| 실행 | 논문에 보고된 agent/harness 조건 | 도구 없는 판별 + 고정 반례 실행 |
| 검증 | 논문 기준의 judge/주석 | 계약·줄 위치·실행 차이 |
| 재현 공개 범위 | 최종 harness·prompt 미확보 | 입력·해시·안전 응답·러너 보존 |
| 이번에 주장할 수 없는 것 | — | TVB 재현, 탐지 성능 우월성, 신규 결함 확정 |
추가 가치는 한국어 작업 화면과 근거 추적, 정상 대조군, 수리 쌍의 문맥 분리, 실제 반례를 이용한 작은 비교를 함께 제공한 것이다. 기능이 많다는 이유로 논문보다 우수하다고 주장하지 않는다.
8. 한계와 다음 실험
평가 계열이 네 개이고 LiveCodeBench 비중이 높다. 정상 대조군도 자연 발생한 clean task가 아닌 저자 수리본이다. 명확한 계약과 짧은 코드가 결함을 지나치게 쉽게 만들었을 수 있다. 공개 코드의 사전학습 노출은 통제하지 못했다. 위치 지표는 줄의 교집합만 보며 원인 의미 일치를 대체하지 못한다. wheel 입력 검증기는 모든 parent 초기화 파일 조건을 완전히 강제하지 않지만, 저장된 실제 반례는 독립 검토에서 계약을 충족했다. 동결 채점기를 사후 수정하지 않았다.
다음 버전은 새로 봉인한 자연 task로 구성해야 한다. 여러 benchmark의 실제 verifier·환경 실패와 모델 실패를 구분하고, 알려진 결함과 독립 검토한 정상 task를 함께 확보한다. 예시는 개수와 유사도를 개발셋에서만 선택한다. 동일 모델·도구·호출 예산을 맞춘 뒤 family 단위로 분석하고, 두 검토자가 원인 및 상류 적용 가능성을 판단한다. 후보 재현까지 든 모델 토큰과 사람 시간을 함께 측정한다. TVB의 최종 artifact가 확보되면 그때 동일 조건 재현을 별도 수행한다. 이번 평가셋으로 다시 튜닝한 점수를 새 최종 성능으로 보고하지 않는다.
재현 자료
- 사전 계획:
knowledge/lab/experiments/defect-lab-v1/PROTOCOL.ko.md - 버전·분할·라벨: 같은 경로의
dataset/manifest.json,cases.json,examples.json,provenance.json - 봉인 근거:
freeze.json; 실행별runs/repeat-*/prompt.txt,response.txt,response.json,receipt.json - 채점:
grade.py, 결과analysis.json; 모델을 다시 호출하지 않고 재집계할 수 있다. - 별도 발견:
discovery/reproduce.py,reproduction.json,runs/discovery-source-a/ - 출처·권리와 독립 검토: 자료집의
corpus/,research/,reviews/
원문과 재현 명령은 자료집의 재현 가이드에서 연결한다. 라이선스를 확인한 코드·문서만 원문을 보관했고, 일반 웹페이지와 논문은 요약·분석·원문 링크로 제공한다.
공개 출처를 인용한 Environment Foundry의 독립 작성 자료입니다.