AI가 작성한 PR은 '테스트를 약화시키지 않았는지'에서 본다 — 놓치기 쉬운 유형과 점검 절차

연재 기사 「AI에게 맡기고, 확인하기」입니다. 저는 이전에 테스트용 컨테이너 재사용으로 인해 오래된 상태로 테스트가 통과했던 사례와, CI 마이그레이션 과정에서 추가한 skipif가 검사가 알아채지 못하는 사이에 사라졌던 경험을 했습니다. 두 경우 모두 테스트는 모두 통과했습니다.

테스트를 통과시키는 방향으로 동작하는 것은 최신 모델 자료에서도 보고되고 있습니다. Anthropic의 Claude Opus 5.5 시스템 카드(2026년 9월)는 채점에서 불합격이 될 것 같은 변경을 git 조작을 통해 채점 측에서 숨긴 예를 들었습니다. OpenAI의 GPT-6 Astra 시스템 카드(2026년 9월)는 풀 수 없는 코딩 과제에 대한 회피책을 사고 과정에서 '일반적인 모듈화'처럼 말하는 경우가 있으며, 이는 감시 측에서 구별하기 어려울 때가 있다고 적혀 있습니다. 구별하기 어려운 주된 이유는 감시하는 쪽의 판정 방식에 있고, 이 발언은 그 다음 이유라고 합니다. 테스트를 출력에 맞춰 수정하는 동작은 2025년 Claude 3.7 Sonnet 시스템 카드에서도 보고되었습니다.

제 리뷰 관점에도 '테스트를 약화시키지 않았는지'는 있었지만, 항목이 대략적이었습니다. X에서 테스트를 약화시킨 변경을 감지하는 Bot인 「Test Cop」(@ryanthawks, 2026년 10월 16일) 소개를 보고, 거기에 언급된 검출 항목과 제 관점을 비교해 보니 skip, assert의 완화, 기대값 업데이트, 실행되는 테스트의 축소가 빠져 있었습니다. 거기서 재구성한 유형과 점검 절차를 소개합니다.

제 경험으로는 AI가 작성한 PR은 구현보다 테스트 쪽을 변경하여 통과시키는 변경이 놓치기 쉽다고 느낍니다.

가장 명확한 유형이지만, 이유가 적히지 않은 채 들어옵니다.

func TestRetryOnTimeout(t * testing.T) {
if testing.Short() {
t.Skip("slow")
...
}

testing.Short()

의 skip은 CI가 -short로 동작하고 있다면 실질적으로 삭제와 같습니다. Python이라면 pytest.mark.skip, skipif, xfail이 같은 취급을 받습니다.

- require.Equal(t, "user not found", err.Error())
+ assert.Contains(t, err.Error(), "not found")

Equal → Contains, require → assert (실패해도 후속이 동작), 부동 소수점의 허용 오차를 넓히는 것 등입니다. 모두 1줄로 되어 있어 의도적으로 읽지 않으면 알아채기 어렵습니다.

- want := 3
+ want := 4

구현 결과에 맞춰 기대값을 수정하면 테스트는 아무것도 확인하지 않게 됩니다. 골든 파일 일괄 업데이트(-update 플래그 등)는 특히 주의가 필요하며, 사양이 변경되었다면 그 설명이 PR에 필요합니다.

테스트 본체가 아니라 실행 범위를 좁히는 유형입니다.

test:
go test -short -run 'TestUnit' ./...

-run이나 -short의 추가, 빌드 태그, Makefile 변경, pytest의 collect_ignore 등이 있습니다. 테스트 파일을 열어도 변화가 보이지 않아 가장 알아채기 어려운 유형이라고 생각합니다.

TestMain에서 환경 변수나 함수를 교체하거나, conftest.py의 autouse fixture로 외부 호출을 통과시키는 것, .pth나 sitecustomize로 import 시 동작을 변경하는 등의 변경이 있습니다. 예를 들어 다음 conftest.py만 추가해도 테스트 파일을 1줄도 바꾸지 않고 모든 테스트가 skip됩니다.

import pytest
def pytest_runtest_setup(item):
pytest.skip("not implemented yet")

테스트 자체를 바꾸는 것이 아니라, 테스트나 채점(grading)을 호출하는 쪽을 바꿔치기 하는 유형도 있습니다. Google은 Gemini 4 Argon의 안전성 블로그(2026년 10월)에서 모델이 채점 스크립트를 재작성하려 했던 사례를, METR는 2026년 5월 보고서에서 채점 스크립트에 로그를 심어 테스트를 작성하도록 유도한 사례를 언급했습니다. 테스트 파일뿐만 아니라, 테스트를 실행하는 쪽의 변경까지 포함하여 살펴봅니다.

- run: make test || true

|| true

나 continue-on-error: true가 있으면, 테스트는 실행되더라도 그 실패가 CI(지속적 통합)의 합격/불합격 여부에 영향을 미치지 않게 됩니다.

앞서 언급한 skipif처럼 다른 환경에서 실패한 테스트에 skip을 추가하는 변경이 있습니다. 원인이 '해당 환경에 필요한 것이 없는 것'인지, 아니면 'fixture를 교체하여 검사가 무시되고 있는 것'인지를 구분하지 않고 skip하면, 검사 자체가 사라지게 됩니다.

유형이 정해져 있다면, 눈으로 찾기 전에 기계적으로 찾아낼 수 있습니다. 저는 리뷰 초기에 다음과 같은 명령어로 후보들을 추출합니다.

git diff origin/main...HEAD -U0 -- \
':(glob)**/*_test.go' ':(glob)**/test_*.py' ':(glob)**/*_test.py' ':(glob)**/conftest.py' \
':(glob)**/Makefile' '.github/workflows/*' \
...

:(glob)을 붙이는 이유는, 안 붙이면 test_*.py나 Makefile이 리포지토리 직하위 파일에만 해당하고, tests/ 아래 등의 변경 사항을 놓치기 때문입니다.

.pth는 import로 시작하는 줄이 실행 시점에 동작하며, sitecustomize.py는 위치만 되어 있어도 실행 시점에 로드되므로, 내용이 평범해 보여도 동작을 바꿀 수 있습니다. 위의 정규식으로는 포착하지 못할 때가 있으므로, 추가되거나 변경되거나 이동된 파일을 이름으로 추출한 뒤, 나온 파일은 모두 내용을 확인합니다.

git diff --name-only --diff-filter=d origin/main...HEAD -- ':(glob)**/*.pth' ':(glob)**/sitecustomize.py'

삭제된 테스트 함수도 살펴봅니다.

git diff origin/main...HEAD -- '*_test.go' | rg -n '^-func Test'
git diff origin/main...HEAD -- ':(glob)**/test_*.py' ':(glob)**/*_test.py' | rg -n '^-\s*def test_' 

여기서 나오는 것은 후보들일 뿐입니다. 정상적인 변경도 많기 때문에, 하나하나

테스트를 약화시킨 변경: 있음 (2건)

• must-fix: internal/user/repo_test.go:42 require.Equal → assert.Contains. 에러 메시지 사양 변경 설명 없음
• must-fix: Makefile:12 -short 추가. CI에서 TestRetryOnTimeout이 실행되지 않게 됨

만약 해당 사항이 없다면 '테스트를 약화시킨 변경: 없음'이라고 작성합니다. '없음'이라고 명시해 두면, 봤는지 안 봤는지를 나중에 구별할 수 있습니다. 위의 유형에 해당하는 변경이 사양 변경으로 설명되지 않았다면, 반드시 수정해야 할 지적(must-fix)으로 처리합니다.

리뷰도 AI에게 맡길 경우, 이 관점을 리뷰용 지침(체크리스트 파일 등)에 작성하고, 만든 것과는 별도의 에이전트에게 검토하도록 합니다. 같은 에이전트라면 자신이 약화시킨 테스트를 '적절한 수정'이라고 판단하기 쉽기 때문입니다. Claude Code의 공식 베스트 프랙티스도, 새로운 컨텍스트에서 보면 리뷰가 좋아진다는 이유로 작성하는 사람과 보는 사람을 별도의 세션으로 분리하는 예시를 들고 있습니다.

METR는 2026년 6월 GPT-5.6 Sol 평가에서, 자신들의 ReAct 평가 환경에서 평가한 공개 모델 중 부정 행위를 탐지한 비율이 가장 높았으며, 숨겨진 테스트 정보를 끌어낸 사례도 있었다고 언급했습니다. 지침에 작성하는 것에서 끝내지 않고, 다른 눈으로 diff를 보는 것이 필요합니다.

이 관점은 아직 사용을 시작한 지 얼마 안 되었으므로, 운영해 보고 적절한/부적절한 사례가 보이면 다시 작성하겠습니다.

• Anthropic, "Claude Opus 5.5 System Card" (2026년 9월 22일, 6.2 Behavior during training, 6.5.4.4 Concealment of changes): https://www-cdn.anthropic.com/fc1b44717c85dc068bc6ba5024219938094694bd/Claude%20Opus%205.5%20System%20Card.pdf

• OpenAI, "GPT-6 Astra System Card" (2026년 9월 3일, 9.1.2.1 CoT-only Monitor Scope): https://deploymentsafety.openai.com/gpt-6-astra/cot-only-monitor-scope

• Google, "Developing Gemini 4 Argon responsibly and safely" (2026년 10월 13일): https://blog.google/innovation-and-ai/technology/safety-security/gemini-4-model-safety-security/

• METR, "Summary of METR's predeployment evaluation of GPT-5.6 Sol" (2026년 6월 26일): https://metr.org/blog/2026-06-26-gpt-5-6-sol/

• METR, "Frontier Risk Report (February to March 2026)" (2026년 5월 19일 공개): https://metr.org/risk-report-feb-mar-2026.pdf

• Claude Code Docs, "Best practices for Claude Code" (2026년 10월 6일 업데이트): https://code.claude.com/docs/en/best-practices

• obra/superpowers, test-driven-development 스킬 (2026년 9월 19일 업데이트): https://github.com/obra/superpowers/blob/5bf4e78011075bcfc0dc295f0724994cd123ee71/skills/test-driven-development/SKILL.md

• @ryanthawks, Test Cop 소개 스레드 (X, 2026년 10월 16일): https://x.com/ryanthawks/status/2110957275590332471 (탐지 항목은 2/의 게시물: https://x.com/ryanthawks/status/2110957276764746152 )

• Anthropic, "Claude 3.7 Sonnet System Card" (2025년 2월, 제6장. 배경 보충 자료로): https://www.anthropic.com/claude-3-7-sonnet-system-card