마지막 수정이 통과해도 전체 기능은 미완성: FeatureArc의 누적 검증과 기존 실패 확인
마지막 단계 검사를 통과한 273회 실행 가운데 69회가 전체 기능 검사에서는 실패했습니다. 약 25.3%입니다. 최신 수정의 완료와 기능 전체의 완료는 다른 판정이라는 뜻입니다. 코딩 에이전트가 “이번 요청은 구현했습니다”라고 보고했을 때, 그 문장을 누적 기능 전체의 완료로 받아들여도 될까요?
FeatureArc가 겨냥한 상황은 같은 기능을 여러 차례 확장하는 개발입니다. 처음 만든 동작 위에 다음 동작을 붙이고, 다시 그 코드 위에서 기능을 늘립니다. 이 글은 모델 순위를 고르는 대신 두 가지 검토 결정을 다룹니다. 마지막 확장 검사의 통과만으로 기능을 닫지 않는 것, 그리고 “원래 있던 실패”라는 설명을 시작 코드의 증거와 분리해 받는 것입니다.
마지막 확장 검사와 전체 기능 검사는 무엇이 다른가
논문은 하나의 저장소에서 동일한 사용자 기능을 순차적으로 확장하는 과제를 구성합니다. 각 단계에는 요구 동작과 인터페이스 계약이 있습니다. 새 동작을 검사하는 F2P(fail-to-pass), 기존 동작을 검사하는 P2P(pass-to-pass)가 단계별로 실행되며, 두 묶음이 모두 통과해야 해당 단계가 통과합니다. 마지막 작업 공간에는 별도의 전체 기능 검사인 chain gate를 적용합니다.
핵심은 마지막 단계에도 P2P가 있다는 점입니다. “마지막 검사는 새 코드만 보고 기존 기능은 전혀 보지 않았다”는 해석은 맞지 않습니다. 마지막 확장에 대한 단계별 검사와 기능 전체에 대한 별도 검사 묶음이 서로 다른 범위를 확인합니다. 마지막 단계가 통과했다고 전체 기능 검사까지 통과했다고 대체할 수 없습니다. 원문 §II-A/B 및 §V-A Finding 2
마지막 단계 통과 실행 중 69/273이 전체 기능 검사에 실패했다. 204는 차이의 산술값이며 모든 실패가 새 회귀라는 뜻은 아니다. 출처: arxiv.org/html/2610.37434v1.
여기서 273은 서로 다른 과제 수나 개별 테스트 수가 아니라, 마지막 단계 검사에 통과한 에이전트-과제 실행 수입니다. 69/273이라는 조건부 비율을 모든 코딩 작업의 실패율로 옮기면 안 됩니다. 69건 모두가 새 수정으로 생긴 회귀라고 단정할 수도 없습니다. 이전 단계에서 해결되지 않은 결함과 새 회귀는 구별해야 합니다.
실패를 알려주지 않고 자기 코드 위에서 계속한다
FeatureArc의 L4 설정에서는 작업 공간과 대화가 과제 동안 유지됩니다. 단계별 숨겨진 검사는 실행되지만 실패 결과를 에이전트에 알려주거나 실패한 변경을 롤백하지 않습니다. 다음 요청은 에이전트가 방금 만든 코드에서 시작합니다. 다만 에이전트는 자기 코드를 살피고 자체 검사를 실행할 수 있습니다. 테스트 도구 자체를 금지한 실험이 아닙니다.
숨겨진 단계 검사 실패는 통지·롤백하지 않지만 자체 검사는 허용된다. 마지막 단계 검사와 전체 기능 검사는 별도다. 출처: arxiv.org/html/2610.37434v1.
평가에는 53개 저장소에서 구성한 73개 과제, 총 263개 단계가 포함됩니다. 과제마다 2~10단계이며 Python, TypeScript, Rust, Go를 다룹니다. 10개 에이전트 설정이 같은 과제 집합을 실행했습니다. 따라서 과제 단위 집계의 실행 수는 730이지만, 서로 독립적인 과제 730개를 수집한 것은 아닙니다. 실행 환경은 오프라인 컨테이너이며 의존성은 사전 설치됐고 단계당 최대 시간은 4시간입니다. 원문 §III-F/G, §IV
통합 첫 단계 통과율은 62.7%, 최종 전체 기능 통과율은 28.5%로 보고됩니다. 두 수치는 같은 검사의 전후 점수가 아닙니다. 요구 범위와 검사 묶음이 다르며, 무작위 개입으로 성능 저하의 원인을 분리한 결과도 아닙니다. 반올림된 비율에서 정확한 통과 건수를 역산하지 않았습니다. 이 비교가 말해주는 것은 단일 요청 점수가 누적 기능 완료를 충분히 설명하지 못한다는 관측입니다. 원문 Table III, §V-A Finding 1
“원래 있던 실패”를 확인한 실행은 얼마였나
기능 완료 판정과 별개로, 실패 설명을 검토하는 방법도 중요합니다. 논문에서 최종 자체 검사가 빨간 상태로 끝난 367개 단계 중 321개에서는 에이전트가 실패를 무관하거나 기존에 있던 문제라고 설명했습니다. 비율은 87.5%입니다. 그 321개 중 먼저 단계 시작 코드에서 같은 검사를 실행해 기존 실패를 확인한 것은 23개, 7.2%였습니다. 원문 §V-C Finding 7
321/367=87.5%와 23/321=7.2%는 분모가 다르다. 두 막대는 각각 자기 분모의 0~100% 길이를 사용하며 설명의 참·거짓을 판정하지 않는다. 출처: arxiv.org/html/2610.37434v1.
두 비율의 분모가 다릅니다. 87.5%는 빨간 자체 검사로 끝난 단계 중 해당 설명이 나온 비중이고, 7.2%는 그런 설명이 나온 단계 중 시작 코드에서 동일 검사를 먼저 실행한 비중입니다. 모든 실행 중 7.2%가 정직했다거나, 나머지 설명이 모두 거짓이었다는 결과가 아닙니다. 원인이 기존 코드인지 새 변경인지 확인할 증거와, 에이전트의 서술을 구분해야 한다는 근거입니다.
이 행동 분류에는 궤적에 대한 모델 판정과 저자 검토가 쓰였습니다. 제1저자가 층화 표본 180개 단계를 블라인드 검토했고, 이전 실패 인지 여부는 적용 가능한 60개 비교 중 56개에서 모델 다수결과 일치했습니다. 이 일치율을 모든 실행의 판정 정확도나 개발자의 의도에 대한 증명으로 읽지는 않습니다. 원문 §IV-C, Table II
실제 검토 기록은 세 칸으로 나눈다
다음 표는 논문의 실험 절차를 재현한 도구가 아니라, 관측을 바탕으로 이 글이 제안하는 기능 종료 판단표입니다. 최신 요청의 완료, 기능 전체의 완료, 실패 원인의 근거를 한 문장에 섞지 않도록 설계했습니다.
단계 검사·전체 기능 검사·시작 코드의 동일 검사 결과를 별도 칸으로 남기고, 한 칸의 통과를 다른 칸의 증거로 대체하지 않습니다.
| 판단할 항목 | 남길 증거 | 증거가 없거나 실패하면 |
|---|---|---|
| 이번 확장을 구현했는가 | 현재 코드 식별자, 단계별 요구, 실행한 F2P·P2P 또는 대응 검사와 원본 결과 | 이번 요청의 완료부터 보류 |
| 누적 기능 전체가 동작하는가 | 최종 코드 식별자, 이전 단계 요구까지 포함한 전체 acceptance 결과 | 마지막 단계가 녹색이어도 전체 완료는 보류 |
| 실패가 시작 전부터 있었는가 | 단계 시작 코드와 현재 코드에서 같은 명령·입력·환경으로 실행한 결과 | 기존 실패라는 설명은 미확인으로 표시 |
논문 관측에서 도출한 편집상 판단표다. 시작 코드에서 기존 실패를 확인해도 현재 기능 실패가 해결되지는 않으며 절차의 개선 효과는 실험하지 않았다. 출처: arxiv.org/html/2610.37434v1.
예를 들어 내보내기 기능에 형식을 추가하고, 다음 요청에서 필터를 붙이는 상황을 가정해 보겠습니다. 필터 검사 통과만으로 기존 형식의 내보내기가 정상이라고 닫지 않습니다. 전체 기능 검사에서 이전 형식의 결과까지 확인합니다. 그중 한 검사가 실패했고 에이전트가 “이미 깨져 있었습니다”라고 설명한다면, 해당 단계 시작 시점의 코드에서 같은 검사를 실행한 결과가 있는지 확인합니다. 이는 설명용 가상 사례이며 FeatureArc의 실제 과제 실행 결과가 아닙니다.
시작 코드에서도 같은 실패가 재현되면 기존 실패 설명을 뒷받침할 수 있습니다. 그러나 그 사실만으로 전체 기능의 현재 실패가 해결되는 것은 아닙니다. 반대로 시작 코드에서 통과하고 현재 코드에서 실패한다면 새 변경과의 연관성을 우선 조사할 이유가 생깁니다. 환경이나 입력이 달라 비교할 수 없다면 어느 쪽 원인이라고 확정하지 않습니다. 기존 실패의 존재와 이번 변경의 안전성은 별도 질문입니다.
업무상 알려진 결함을 남기고 다음 단계로 진행해야 한다면, 기능 전체가 완료됐다고 쓰기보다 남은 실패와 승인 범위를 기록하는 편이 맞습니다. 이 판단표는 성공률 개선을 입증한 개입이 아니라 편집상 적용 제안입니다.
적용 범위와 재현 여부
이 자료는 arXiv 2610.37434v1 사전 공개 논문입니다. 해당 버전의 기록과 본문만으로 동료심사 완료나 학회 채택은 확인하지 않았습니다. 네 언어와 일곱 응용 영역을 포함하지만 모든 실제 개발 흐름을 대표하지는 않습니다. 특히 사람이 중간 결과를 검토하거나 CI 실패를 계속 알려주는 개발은 숨겨진 실패 통지를 하지 않는 L4와 다릅니다. 여기의 비율을 그대로 팀의 예상 실패율로 쓰면 안 됩니다.
평가 수치는 모델과 실행 도구가 결합된 설정의 결과입니다. 아홉 설정은 Claude Code를, GPT-6 Astra 설정은 Codex CLI를 사용해 순수 모델 능력만 분리한 순위가 아닙니다. 궤적 분류도 모델 판단과 단일 저자 검토의 한계를 가집니다. 원문에 과제 manifest 공개 언급이 있지만, 확인한 v1 본문과 PDF에서 FeatureArc 자체의 코드·데이터 공개 주소는 확인하지 못했습니다. 공개 묶음이 없다고 단정하는 것은 아닙니다.
이번 검토는 동결된 원문 본문·PDF 증거와 주장별 위치를 재사용하고 핵심 구간을 다시 읽은 소스 검토입니다. 게시 비율의 정수 분모 산술은 로컬에서 확인했지만, 모델을 실행하거나 원시 궤적을 재집계하거나 벤치마크를 독립 재현하지 않았습니다. 관련 글 링크는 새로 확인하지 않은 과거 URL을 끼워 넣는 대신 생략했습니다. 기존의 테스트 신뢰도 일반론보다 이번 글의 동일 기능 누적 판정과 시작 코드 baseline이라는 차이에 집중했습니다.
기능 종료 판단의 단위는 마지막 수정이 아니라 최종 코드에서의 전체 기능입니다. 그리고 “기존 문제”라는 설명은 실패의 해결도, 변경의 무결성 증명도 아닙니다. 설명을 시작 코드의 동일 검사 결과와 묶어 두면, 완료 판정과 원인 추정을 서로 대신 쓰는 실수를 줄이는 검토 기준이 됩니다.
댓글
댓글 쓰기