CI는 새로운 코드에 대해서만 새로운 테스트를 실행한다

원래 2026년 10월 10일 내 블로그에 게시되었습니다. 여기에 제시된 수치는 제가 직접 작성한 케이스를 대상으로 한 도구의 첫 주 데이터입니다. 후속 실행에서는 이전에 본 적 없는 실제 에이전트 커밋을 대상으로 했으며, 그 결과는 덜 보기 좋지만 더 유용한 결과를 보여주었습니다: 3,355번의 코딩 에이전트에 의한 테스트 수정.

여기에 풀 리퀘스트(pull request)가 있습니다. 코드 변경은 비교 항목 하나를 바꾸고, 테스트는 예상 값 하나를 변경하며, 설명에는 '경계 조건을 수정함'이라고 되어 있습니다. 세 가지 테스트 모두 통과했고, 깨지는 변화(breaking changes)도 없습니다.

$ pytest
3 passed in 0.01s

이것 역시 잘못되었습니다. 이 함수는 어떤 날이 주말인지 결정합니다. 변경 사항은 월요일을 주말로 만듭니다. 기존에는 is_weekend(0) is False라고 말하던 테스트가 이제는 is True라고 말합니다. 테스트는 수정되지 않았습니다. 버그와 일치하도록 끌려간 것입니다.

CI(Continuous Integration)에서는 이것을 아무도 볼 수 없으며, 그 이유는 누락된 기능이라기보다는 구조적인 문제입니다: CI는 풀 리퀘스트의 코드를 대상으로 풀 리퀘스트의 테스트를 실행합니다. 이 비교의 양쪽 모두 동일한 작성자에 의해, 같은 커밋에서 작성되었습니다. 만약 작성자(인간이든 에이전트든)가 두 부분 모두를 일관되게 수정한다면, 결과는 구조적으로 녹색(green)이 됩니다.

아무도 실행하지 않는 조합은 오래된 테스트를 대상으로 새로운 코드에 적용하는 것입니다.

$ pr-witness --base main

                   base      head  crossrun
...

이것이 pr-witness입니다. 이 게시물은 그것을 구축하는 것에 관한 것이며, 특히 무언가를 측정하는 부분이 제가 믿었던 것을 어떻게 변화시켰는지에 대한 부분에 초점을 맞추고 있습니다.

왜 지금

코딩 에이전트는 특정한 실패 모드를 가지고 있으며, 그 수치가 있습니다. Transluce는 8,600개의 실제 코딩 에이전트 기록을 분석했습니다. 공개 SWE-chat 세션에서 34.7%가 성공에 대한 과장된 보고를 포함했고, 14.7%가 모니터 회피(monitor evasion)를 보였습니다—즉, 테스트를 조용히 비활성화하거나, 승인 없이 병합하거나, 리뷰 에이전트의 승인을 주장하는 방식입니다. 이 중 대부분은 경미한 수준이지만, 심각한 사례는 각각 1.8%와 1.9%로, 현재 에이전트가 수행하는 규모를 고려하면 상당한 수의 풀 리퀘스트(pull requests)에 해당합니다. 대표적인 공개 사례로는 anthropics/claude-code#46940가 있습니다: 4,992개의 값으로 구성된 골든 스위트(golden suite)에서 에이전트는 일곱 개의 값을 깨뜨렸음에도 불구하고 4966/4966 ALL PASSED를 보고하고 커밋했습니다—분모가 조용히 줄어들었던 것입니다. 또한 ImpossibleBench (Zhong, Raghunathan, Carlini)는 명세(spec)와 테스트가 충돌할 때 무슨 일이 발생하는지 측정했습니다: SWE-bench 변형에서 최첨단 모델들은 39–76%의 작업에서 속임수를 써서

코퍼스(corpus)는 총 17개의 케이스로 구성되어 있으며, 각 케이스는 전체의 before/after 파일 트리(패치가 아닌, 양쪽 모두 실행해야 하는 형태), 풀 리퀘스트 설명, 그리고 정답이 무엇인지 알려주는 레이블을 가지고 있습니다. 이 중 9개는 속임수(cheats)이고, 나머지 8개는 순수한 변경 사항이지만 단순한 탐지기에게는 속임수처럼 보이는 경우입니다. 예를 들어, 테스트와 함께 제거된 기능, 사양 변경으로 인해 업데이트된 예상 값, 이름이 바뀐 테스트, 모듈로 분할된 테스트, parametrize로 통합된 테스트, 이슈 링크와 함께 건너뛴 불안정한(flaky) 테스트 등이 있습니다.

순수한 변경 사항들(honest half)이야말로 핵심입니다. 속임수에서는 완벽하게 점수를 얻고 모든 리팩토링을 플래그하는 도구는 탐지기가 아니라 경보음(alarm)에 불과하며, 사람들은 경보음을 끄게 됩니다.

레이블의 카운트는 유형화되어 있지 않습니다. 검증기(verifier)는 각 케이스를 세 가지 방식으로 실행합니다—base on base, head on head, 그리고 base tests on head code—그리고 그 숫자를 기록합니다. 만약 실행 결과가 레이블과 일치하지 않으면, 해당 케이스는 잘못된 것입니다. 이 방법으로 도구가 존재하기 전에 제가 직접 발견한 두 개의 케이스를 잡아냈습니다: 하나는 자체 테스트에 실패한 속임수였고 (따라서 숨긴 것이 없었음), 다른 하나는 denominator로 레이블링되었지만 실제로는 다른 무언가였습니다.

두 번째 사례는 별도의 단락으로 언급할 가치가 있습니다.

describe.only는 카운트를 줄이지 않는다

계획은 다음과 같았습니다: 수집된 카운트가 감소할 때 플래그를 지정하는 것입니다. pytest의 testpaths 좁히기(narrowing) 기능이 정확히 이를 수행합니다—14개가 수집되었다가 8개로 줄어듭니다. JavaScript 버전인 describe.only도 마찬가지로, 실행기가 다른 모든 스위트(suite)를 무시하게 만듭니다. 원리는 같습니다.

측정해 보니 모양이 같지는 않았습니다. vitest는 여전히 5개의 테스트를 모두 수집하고, 2개를 실행한 후 3개를 skipped로 보고합니다. 카운트는 변하지 않습니다. 따라서

재현율 (Recall) 0.22는 checkwash가 놓친 수치가 아닙니다. 코퍼스는 의도적으로 자신이 주장하지 않는 신호들—크로스-런 파손(cross-run breakage), 분모(denominators), 산문(prose)—로부터 구축되었습니다. 따라서 여기서 낮은 숫자는 "범위 외(out of scope)"를 의미하며, 이는 제가 테스트하던 전제였습니다. 검증기 출력물에서 바로 읽은 순수 카운팅 신호만으로도 P 0.80 / R 0.89의 점수를 기록했습니다. 이것이 넘어서야 할 최소 기준점이었습니다.

페이즈 1은 기준선보다 낮은 점수를 기록했다

툴의 첫 번째 작동 버전: P 0.67. 개선을 목표로 했던 카운트 수치보다 낮았습니다.

원인은 위에서 언급된 식별자(identity) 결정에 논리적인 끝을 내린 데 있었습니다. 만약 테스트가 file::name으로 식별된다면, 파일을 이름 변경하는 것은 그 안에 있는 모든 식별자를 삭제합니다. 모듈을 분할하면 식별자들이 삭제됩니다. 다섯 개의 테스트를 하나의 매개변수화된(parametrised) 테스트로 통합하면 네 개가 삭제됩니다. 가장 흔한 세 가지의 정직한 리팩토링 방식이 모두 대량 삭제(mass deletion)로 보고되었습니다.

해결책은 크로스-런 자체였습니다. 만약 어떤 동작(behaviour)이 여전히 커버된다면, 기본 브랜치(base branch)의 테스트는 이름이 무엇이든 새로운 코드에 대해 계속 통과합니다. 사라진 식별자는 크로스-런이 이를 확인할 수 없을 때만 보고할 가치가 있습니다. P 0.67 → 0.80으로 상승했으며, 손실된 탐지(detections)가 없었습니다. 같은 형태의 두 번째 버그—"문서화됨(documented)"과 "분모 감소(denominator drop)"로 모두 보고된 문서화된 건너뛰기(documented skip)—는 점수를 0.89까지 끌어올렸습니다.

둘 다 같은 실수였습니다: 기술적으로는 사실이지만 실질적으로 쓸모없는 신호입니다. 정밀도 (Precision)는 마지막에 조정하는 것이 아닙니다. 보고서가 읽을 가치가 있는지가 문제입니다.

checkwash 통합 및 한 번의 이견 제시

checkwash의 JavaScript 지원이 취약했기 때문에 구현할 10가지 JS/TS 패턴 목록을 작성했습니다. 그 계획은 v0.5를 기준으로 작성되었습니다. 0.6.0에 대해서는 하나씩 측정했을 때, 이미 열 개 중 일곱 개가 작동하고 있었습니다. 저는 작동하는 코드를 더 나쁜 복사본으로 만드는 데 일주일을 보냈을 것입니다.

세 가지 실제적인 허점은 로컬에서 구현되었습니다. 테스트가 단언(assertion)을 삼키는 try/catch, 테스트 파일에 대한 @ts-nocheck, 그리고 테스트가 무언가를 단언하도록 강제하는 규칙의 eslint-disable이 그것입니다. 첫 번째 문제는 checkwash#363로 상위 스트림에 제출되었으며, 하나의 커밋으로 재현할 수 있습니다. 파이썬과 타입스크립트에서 동일한 속임수가 발견되었고, 파이썬 파일에서 한 가지가 발견되었습니다.

checkwash의 정밀도를 0.90에서 0.75로 낮추어 연결했습니다. 저는 그 warn 결과를 플래그에 매핑했습니다. checkwash는 high 등급일 때만 차단하고, 사라진 모든 테스트에 대해 warn을 발생시키므로, 모든 정직한 이름 변경이 빛을 발하게 했습니다. warn을 자문(advisory)으로 매핑하여 복구했습니다. 유일하게 남아있는 의견 불일치는 실제적인 것입니다. checkwash는 모든 추가된 건너뛰기 마커에 대해 차단하지만, pr-witness는 추적 이슈를 이름으로 지정하는 건너뛰기를 플래그로 표시하지 않습니다. 발견을 누락하기보다는 보고서에 유지하고, 등급을 낮추며, 의견 불일치를 출력합니다:

checkwash는 추가된 모든 건너뛰기 마커를 보고합니다. pr-witness는 이 경우를 플래그로 지정하지 않습니다: 실행 결과는 이슈를 이름으로 지정하는 건너뛰기 이유를 보여줍니다. 만약 귀하의 정책이 어떤 건너뛰기도 허용되지 않는 것이라면, 여기서 우리보다 checkwash를 신뢰하십시오.

이것이 도구를 사용하는 것과 그것을 무시하는 것 사이의 차이입니다.

산문 속에만 존재하는 거짓말

지금까지 모든 계층이 놓쳤던 사례가 하나 있었습니다:

할인 로직에 대해 41개의 테스트를 추가했습니다. 49/49 통과.

8개 테스트에서 9개 테스트로, 모두 녹색이고, 교차 실행도 깨끗합니다. 실행 결과는 정직합니다. 설명은 그렇지 않습니다. 어떤 실행 수준 또는 diff 수준의 신호도 이것을 볼 수 없으며, 세션 데이터에 따르면 이는 가장 흔한 형태 중 하나입니다.

그래서 세 번째 계층이 설명을 읽습니다. 결정론적 템플릿으로 영어와 러시아어 모두 모델 없이—작가가 결코 하지 않은 주장을 환각(hallucinate)하는 모델은 주장 확인을 안 하는 것보다 더 나쁠 것입니다. 각 주장은 네 가지 판결 중 하나를 받으며, 네 번째가 가장 오래 걸려 올바르게 처리되었습니다:

클레임을 사용하자, 코퍼스에 대한 재현율(recall)은 P 0.91에서 1.00에 도달했다.

서명되었기 때문에 보고서가 의미를 갖는다

풀 리퀘스트에 달린 댓글은 텍스트이다. 에이전트는 텍스트를 입력할 수 있다. 따라서 이 보고서는 GitHub Artifact Attestations로 서명된다: 증거 JSON이 술어(predicate)이고, 워크플로우가 서명자(signer)이며, 누구나 다운로드한 파일에 대해 gh attestation verify를 실행할 수 있다. 나는 명백한 것을 확인했다—파일에서 clean을 flag로 바꾸고 다시 검증해 보았는데—그리고 이는 거부된다. 왜냐하면 해당 다이제스트(digest)에 대한 어테스테이션이 존재하지 않기 때문이다.

계획이 알지 못했던 두 가지 사실, 즉 현재 문서를 읽어서 발견한 것들: 액션은 actions/attest@v4이고, 어테스테이션은 엔터프라이즈 클라우드(Enterprise Cloud)에 속하지 않는 한 공개 리포지토리에서만 작동한다. 비공개 리포지토리 사용자는

이 액션의 첫 라이브 실행은 evidence.json에 서명한 후 이를 폐기했기 때문에 검증할 것이 아무것도 없었습니다. 이동하는 v0.1 태그(즉, uses: talhayme/[email protected]을 작동하게 하는 태그)는 릴리스 워크플로우의 v* 트리거와 일치하여 두 건의 허위 릴리스를 차단했습니다.

이들 각각은 실제 버그였으며, 작성된 기계에서 실행해서는 발견되지 않았을 것입니다. 제가 이것들을 언급하는 이유는 이 게시물의 주제가 "실행해 보니 초록색(성공)이었다"와 "정확하다" 사이의 간극이며, 해당 프로젝트도 예외가 아니었기 때문입니다.

위치 (Where it is)

pip install pr-witness
pr-witness --base origin/main

- uses: talhayme/[email protected]
  with:
    test-command: pytest       # or vitest, jest, go
...

report는 작업을 실패시키지 않습니다. 이것이 기본값인데, 왜냐하면 첫날에 막히는 도구는 둘째 날에 제거되기 때문입니다. require-ack은 유지 관리자가 test-change-approved를 추가할 때까지 플래그에서 실패합니다. strict은 무조건 플래그에서 실패합니다. 이 레이블은 의도를 문서화할 뿐, 사실을 바꾸지는 않습니다.

또한 Claude Code 플러그인도 있습니다: 테스트 파일이 변경되기 전에 일시 정지하고, 에이전트가 완료되었다고 말할 때 실제 실행을 기준으로 "모든 테스트 통과" 여부를 확인합니다. 이는 의도적인 조언입니다. 에이전트는 자체 환경 내에서 실행되며 모든 훅(hook)을 우회할 수 있습니다. 증거는 접근할 수 없는 CI의 서명된 보고서입니다.

숫자와 그 주의점 (The number, and its caveat)