투명한 Codex 버그 재현 비교: 6/14 대 14/14
요약
코딩 에이전트를 위한 오픈 소스 버그 재현 워크플로우의 효과를 실험한 결과, 구조화된 브리프를 제공했을 때 버그 조사 완전성이 6/14에서 14/14로 크게 향상됨을 확인했습니다.
핵심 포인트
- 구조화된 버그 재현 브리프가 에이전트의 조사 완전성을 높임
- 간결한 지침 대비 워크플로우 지원 시 재현 성공률 대폭 상승
- 단순 수정 능력이 아닌 증거 수집 및 감사 가능성에 초점
- 실험 결과 및 벤치마크 데이터 GitHub에 공개
저는 코딩 에이전트(coding agents)를 위한 오픈 소스 버그 재현 워크플로우(bug-reproduction workflow)를 만들었습니다. 저는 이 워크플로우가 단순히 말이 되는 것처럼 들리는 것을 넘어, Codex 조사(investigation)의 완전성을 변화시키는지 테스트하고 싶었습니다.
결과는 간결한 대조군(concise control)에서 6/14, 수정된 워크플로우 지원 실행(corrected workflow-assisted run)에서 14/14였습니다.
이 헤드라인에는 맥락이 필요합니다. 이것은 하나의 합성 Python 피스처(fixture), 하나의 모델, 그리고 직접 작성한 루브릭(rubric)을 사용한 결과입니다. 워크플로우는 더 많은 토큰(tokens)을 사용했고 훨씬 더 긴 답변을 생성했습니다. 첫 번째 워크플로우 실행 역시 14/14를 기록한 것은 아니었습니다. 12/14를 기록했으며, 두 가지 약점을 노출했고, 최종 실행 전 수정을 이끌어냈습니다.
비교를 검토하는 데 필요한 모든 것은 공개되어 있습니다:
https://github.com/skyestrela/ai-agent-skill-preview/tree/main/evidence/bug-reproduction-benchmark
질문
구조화된 버그 재현 브리프(Bug Reproduction Brief)를 제공하는 것이 간결한 작업 지침(task instruction)만 있는 경우보다 모호한 버그 조사(vague-bug investigation)를 더 완전하고 감사 가능하게(auditable) 만드는가?
이 테스트는 구현 속도나 Codex가 버그를 패치(patch)할 수 있는지 여부를 측정하기 위해 설계된 것이 아닙니다. 두 프롬프트(prompts) 모두 파일을 수정하거나 수정안을 제안하는 것을 명시적으로 금지했습니다. 경계는 재현(reproduction)과 증거 수집(evidence collection)이었습니다.
대조군 (Controls)
두 실행 모두 다음을 사용했습니다:
- 동일한 인증된 Codex 모델:
gpt-5.4-mini; - 동일하게 커밋된 Python 피스처(fixture):
a4b9eab9dcc7b2ebbfe5f5d0502d4866cefd36ce; - 읽기 전용(read-only) Codex 샌드박스(sandboxes);
- 사용자 설정 및 리포지토리(repository) 규칙이 무시된 휘발성 세션(ephemeral sessions);
PYTHONDONTWRITEBYTECODE=1;- 전후 모두 깨끗한 워킹 트리(working trees);
- 파일을 수정하거나 수정안을 제안 또는 구현하지 말라는 동일한 지침.
워크플로우 지원 실행은 추가로 버그 재현 브리프(Bug Reproduction Brief) v1.0.1을 받았습니다.
피스처(fixture)에는 의도적으로 잘못된 송장 계산 로직이 포함되어 있습니다. 기존 테스트는 지원 보고서에 기술된 명시적 제로(explicit-zero) 엣지 케이스(edge case)를 다루지 않기 때문에 통과됩니다.
두 실행 모두에서 발견한 내용
대조군(control)과 워크플로 보조(workflow-assisted) 실행 모두에서:
- 실패를 유발하는 명시적 제로(explicit-zero) 입력을 식별했습니다.
- 예상 출력과 관찰된 출력을 기술했습니다.
- 기존 테스트를 실행했습니다.
- 실행 가능한 재현(reproduction)을 제공했습니다.
- 픽스처(fixture)를 변경하지 않고 그대로 두었습니다.
- 수정안(fix) 제안을 피했습니다.
이는 6/14점을 받은 대조군이 무용지물이 아니었기 때문에 중요합니다. 대조군은 핵심적인 실패 지점을 빠르게 찾아냈습니다.
워크플로가 추가한 것
워크플로 보조 답변은 또한 다음 사항들을 기록했습니다:
- 불변 커밋(immutable commit);
- 조사된 런타임 환경(runtime environment);
- 접수된 보고서가 간접적이며 검증되지 않았다는 사실;
- 명시적인 최소 픽스처(minimal fixture);
- 두 개의 별도 재현 사례;
- 해결되지 않은 미지의 요소(unknowns);
- 안전한 차후 가설;
- 재현된 관찰 결과와 진단(diagnosis) 사이의 엄격한 경계.
간결한 대조군은 재현 단계에서 곧바로 근본 원인(root-cause) 진술로 건너뛰었습니다. 최종 워크플로 답변은 관찰 가능한 증거와 테스트 가능한 차후 가설 단계에서 의도적으로 멈추었습니다.
결정론적인(deterministic) 14점 기준 루브릭(rubric)이 해당 기준들을 평가했습니다. 기준별 결과는 정확한 프롬프트(prompt) 및 최종 출력과 함께 score.json으로 커밋되었습니다.
실패한 첫 번째 워크플로 실행
첫 번째 워크플로 보조 실행은 14/14가 아닌 12/14점을 기록했습니다.
이는 워크플로의 두 가지 약점을 드러냈습니다:
- 답변이 보고서의 간접적이고 검증되지 않은 출처(provenance)를 명시적으로 보존하지 않았습니다.
- 재현에만 국한해야 하는 경계를 넘어 인과적 설명(causal explanation)을 기술했습니다.
저는 공개 스킬(public skill)을 v1.0.1로 강화하고 변경되지 않은 픽스처를 대상으로 다시 실행했습니다. 14/14라는 결과는 그렇게 수정된 워크플로에서 나왔습니다.
이로 인해 이것은 눈가림 방식의 학술 연구가 아닌, 반복적인 제품 개발 비교(iterative product-development comparison)가 됩니다. 제가 12/14 실행 결과를 공개하는 이유는, 이를 숨길 경우 최종 결과가 실제 과정보다 더 깔끔해 보일 수 있기 때문입니다.
토큰 및 장황함(verbosity) 비용
추가된 완전성(completeness)은 공짜가 아니었습니다.
| 실행 (Run) | 입력 토큰 (Input tokens) | 캐시된 입력 (Cached input) | 출력 토큰 (Output tokens) | 추론 출력 (Reasoning output) |
|---|---|---|---|---|
| 대조군 (Control) | 68,604 | 62,720 | 1,400 | 255 |
| 워크플로 (Workflow) | 74,547 | 67,328 | 4,471 | 2,661 |
워크플로 (Workflow)는 입력 토큰을 8.7% 더 많이 사용했으며, 실질적으로 더 긴 답변을 생성했습니다.
이러한 트레이드오프 (trade-off)가 모든 작업에 적합한 것은 아닙니다. 감사 가능성 (auditability)보다 속도가 더 중요한 저위험 버그의 경우, 간결한 지시문만으로도 충분할 수 있습니다. 구조화된 브리프 (structured brief)를 채택하는 팀은 최대의 상세함이 항상 더 낫다고 가정하기보다는, 출력 계약 (output contract)을 단축해야 합니다.
이 결과가 증명하지 않는 것
이 결과는 다음을 증명하지 않습니다:
- 모든 코딩 에이전트 (coding agent)가 이 워크플로 (workflow)를 통해 개선되는지;
- 결과가 여러 리포지토리 (repositories)나 모델 (models)에 걸쳐 반복되는지;
- 14/14 재현 브리프 (reproduction brief)가 더 나은 패치 (patch)로 이어지는지;
- 추가된 토큰이 긍정적인 경제적 가치를 제공하는지;
- 이 워크플로 (workflow)가 간결한 프롬프트 (prompt)보다 보편적으로 더 나은지.
출력은 모델의 반복 실행 사이에 달라질 수 있습니다. 평가 기준 (rubric)은 재현 브리프 (reproduction-brief)의 완전성을 보상할 뿐, 버그 수정 (bug-fix) 품질이나 개발자 생산성을 보상하지 않습니다.
더 강력한 후속 연구라면, 실행 전에 고정된 평가 기준 (rubric)을 사용하여 여러 리포지토리 (repositories)와 모델 (models)에 대해 여러 차례의 실험을 수행해야 할 것입니다.
재현하거나 비판하십시오
해당 리포지토리 (repository)에는 다음이 포함되어 있습니다:
- 정확한 대조군 (control) 및 워크플로 (workflow) 프롬프트 (prompts);
- 의도적으로 결함이 있는 피스처 (fixture) 및 통과하는 테스트 스위트 (test suite);
- 최종 대조군 (control) 및 워크플로 (workflow) 출력물;
- 기준 수준의 점수 산정 및 토큰 사용량;
- MIT 라이선스가 적용된 완전한 워크플로 (workflow).
벤치마크 (Benchmark) 및 재현 파일:
워크플로 (Workflow) 소스:
가장 유용한 피드백은 점수에 대한 일반적인 동의가 아니라, 통제 항목 (controls), 루브릭 (rubric) 또는 재현 경계 (reproduction boundary)에 대한 비판일 것입니다.
공개 사항 (Disclosure)
저는 이 워크플로 (workflow)를 제작하였으며, 편집 가능한 10개의 워크플로가 포함된 선택 사항인 더 넓은 범위의 엔지니어링 팩 (engineering pack)을 판매하고 있습니다. 여기서 사용된 전체 버그 재현 브리프 (Bug Reproduction Brief)는 이미 공개되어 있으며 MIT 라이선스를 따릅니다. 이 비교를 검토하거나 재현하기 위해 무엇인가를 구매할 필요는 없습니다.
선택 사항인 더 넓은 범위의 팩:
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기