테스트 우선 AI 코딩 | RED GREEN REFACTOR REPORT

RED

사람 개발자는 암묵적 맥락을 기억한다. 이 필드가 왜 nullable인지, 저 예외를 왜 삼키는지, 작년에 무슨 사고가 있었는지. 에이전트는 그 맥락을 매번 컨텍스트 안에서 추론해야 하고, 없으면 그럴듯하게 지어낸다.

좋은 테스트 하나에는 네 가지가 동시에 들어 있다. 지금 실패하는 조건, 기대하는 동작, 지켜야 할 계약, 그리고 바꾸면 안 되는 것. 자연어 지시로는 네 번째를 전달하기가 거의 불가능하다.

테스트를 작성만 하고 실행하지 않으면 의미가 없다. 한 번 돌려서 실패 로그를 눈으로 본다. 프로젝트 루트의 RED 실행 예시는 다음 블록이다.

npx vitest run tests/posts/list.test.ts 2>&1 | tee /tmp/red.log

tee로 저장하는 이유는 이 로그가 나중에 두 번 쓰이기 때문이다. 에이전트에게 줄 입력이자, PR에 붙일 증거다. 확인할 것은 “실패했다”가 아니라 의도한 이유로 실패했다이다. AssertionError: expected [ 'a', 'b' ] to deeply equal [ 'a' ]는 좋은 실패다.

마지막이 제일 위험하다. 처음부터 통과하는 테스트는 버그를 못 잡은 테스트다. 이미 고쳐졌다고 넘기면 안 된다. 조건이 틀린 것이고, 조건을 다시 잡는다. RED 로그는 요약하지 않고 /tmp/red.log 내용을 그대로 붙인다.

좋은 RED인지는 셋으로 가른다. 구현을 일부러 망가뜨려도 실패하는가. 필터를 반대로 뒤집거나 return []로 바꿔도 통과하면 그 테스트는 아무것도 안 지킨다. Stryker 같은 변이 테스트 도구가 있으나, 손으로 세 군데만 건드려도 대부분의 헛테스트가 걸러진다. 실패 메시지만 보고 어디를 고칠지 알 수 있는가. expected true to be false는 나쁜 메시지다. 실제값과 기대값이 둘 다 보여야 한다. 값 비교(toEqual)가 불리언 단언(toBe(true))보다 낫다. 두 번 연속 같은 결과인가. 시간, 랜덤, 네트워크, 실행 순서에 의존하면 GREEN 판정에 쓸 수 없다. 시계는 vi.useFakeTimers()로 고정하고 네트워크는 스텁한다. 플래키한 테스트를 안고 루프를 돌리면 에이전트가 통과할 때까지 아무거나 바꾼다.

같은 명령을 두 번 연속으로 도는 예시는 다음 블록이다.

npx vitest run tests/posts/list.test.ts
npx vitest run tests/posts/list.test.ts

세 검증을 통과한 뒤에만 GREEN 요청을 보낸다.

GREEN

통과에 필요한 가장 작은 diff만 허용한다. “관련 파일도 정리”는 이 단계가 아니다. 에이전트에게 줄 때는 실패 로그를 그대로 붙인다. GREEN 요청 본문 예시는 다음 블록이다.

아래는 현재 실패 로그다.

$ npx vitest run tests/posts/list.test.ts
 FAIL  tests/posts/list.test.ts > 공개 목록에서 draft를 제외한다
 AssertionError: expected [ 'a', 'b' ] to deeply equal [ 'a' ]

이 테스트만 통과하는 최소 수정을 src/posts/ 안에서 하라.
테스트 파일은 수정 금지. 리팩터는 하지 말 것.

통과하면 즉시 커밋한다. 커밋 전에 볼 것은 둘이다. 테스트 파일이 안 바뀌었는가, 전체 테스트가 통과하는가. 대상 테스트만 돌리면 다른 테스트를 깨뜨린 것을 못 본다. GREEN의 정의는 “이 테스트가 통과”가 아니라 “이 테스트가 통과하고 나머지가 여전히 통과”다. 확인 명령은 다음 블록이다.

에이전트가 기댓값을 ['a', 'b']로 바꾸면 단언은 통과하고 버그는 남는다. 그게 짧은 경로다. 요청 본문의 「테스트 파일은 수정 금지」는 그 경로를 막으려는 문장이다. 권한 deny와 CI grep이 없으면 문장만으로는 부족하다. 리팩터를 이 단계에 넣으면 구조 변경과 동작 변경이 한 diff가 되어, 실패했을 때 어디부터 의심할지 모른다.

npx vitest run 2>&1 | tee /tmp/green.log
git diff --name-only | grep -E '\.(test|spec)\.' && echo "경고: 테스트 변경됨"
npx vitest run

첫 줄은 전체 러너다. 둘째 줄은 테스트 경로 diff가 있으면 경고를 찍는다. 셋째 줄은 한 번 더 돌려 통과가 우연이 아닌지 본다.

핵심 포인트: GREEN 요청의 통과 경로는 코드 수정과 테스트 수정 둘이다. 후자가 더 짧고 확실하므로, 테스트 경로 쓰기는 권한과 CI로 잠근다.

REFACTOR

중복 제거, 이름 정리, 범위 축소는 통과 이후에만 한다. 이 단계에서 테스트가 깨지면 고치지 말고 되돌린다. 복귀 명령은 git reset --hard HEAD다. 리팩터 중 깨진 테스트를 그 자리에서 고치기 시작하면 GREEN과 REFACTOR가 한 덩어리가 되고, 실패 원인이 어느 쪽인지 알 수 없게 된다. GREEN 커밋이 있기 때문에 되돌리는 비용이 거의 0이다. 리팩터는 별도 커밋으로 남긴다. 나중에 문제가 생겼을 때 동작을 바꾼 커밋과 구조만 바꾼 커밋을 분리해서 의심할 수 있다. 범위와 중단 조건을 문서로 고정하는 법은 롤백 가능한 AI 리팩터링을 같이 본다.

REPORT를 빼고 세 단계로만 도는 팀이 많다. 그러면 “됐다고 하니 됐겠지”로 머지된다.

REPORT

“된 것 같다”로 끝내지 않기 위한 단계다. PR 본문에 재현 조건, RED 로그, GREEN 전체 통과, 변경 파일, 남은 위험을 붙인다. PR 증거 블록 예시는 다음 블록이다.

## 재현
조건: /vibe-coding 목록에 status='draft' 글이 2개 있을 때
현재: draft가 공개 목록에 노출
기대: published만 노출

## RED
$ npx vitest run tests/posts/list.test.ts
 FAIL  공개 목록에서 draft를 제외한다
 AssertionError: expected [ 'a', 'b' ] to deeply equal [ 'a' ]

## GREEN
$ npx vitest run
 Test Files  14 passed (14)
      Tests  87 passed (87)

## 변경
- src/posts/query.ts (+3 -1)
- 테스트 파일 변경 없음

## 남은 위험
- sitemap의 draft 제외는 이 PR 범위 아님. 별도 이슈 #142
- 예약 발행(published_at 미래)은 미검증

남은 위험을 적는 칸이 있는 것이 핵심이다. 여기가 비어 있으면 리뷰어가 “정말 아무것도 없나?”를 묻게 되고, 대개는 뭔가 있다. 에이전트에게도 이 칸을 채우게 하면 건드리지 않은 인접 영역을 스스로 짚는다. 이 블록 자체를 PR 템플릿으로 만들어 두면 매번 형식을 고민할 필요가 없다.

팀 규칙 한 줄은 “구현 전 실패 로그가 없는 AI 코딩 PR은 리뷰를 시작하지 않는다”다. PR 템플릿에 RED 로그 칸을 만들어 두면 작성자가 PR을 열기 전에 스스로 걸린다. 붙일 로그가 없다는 것을 깨닫는 순간 순서가 틀렸다는 것도 같이 깨닫는다. 규칙은 사람의 선의에 기대고, CI는 안 기댄다. 둘 다 있어야 오래 간다.

Vitest 단언

“목록이 이상하다”는 테스트로 바꿀 수 없다. 범위도 기대값도 없다. 에이전트에게 이대로 주면 목록 컴포넌트 전체를 다시 쓴다. 조건, 현재, 기대 세 조각으로 쓴다. 공개 목록 draft 혼입 사례의 세 줄은 다음 블록이다.

조건: /vibe-coding 목록 페이지에 status='draft'인 글이 2개 있을 때
현재: 공개 목록에 draft 2개가 함께 노출된다
기대: 공개 목록에는 status='published'인 글만 보인다

이 세 줄이 나오면 테스트는 거의 저절로 써진다. Vitest 기준 예시는 다음 블록이다.

it('공개 목록에서 draft를 제외한다', async () => {
  await seed([
    { slug: 'a', status: 'published' },
    { slug: 'b', status: 'draft' },
  ]);

  const list = await getPublicPosts('vibe-coding');

  expect(list.map(p => p.slug)).toEqual(['a']);
});

seed는 픽스처를 넣는 헬퍼다. getPublicPosts는 공개 목록 쿼리다. toEqual(['a'])가 중요하다. not.toContain('b')로 쓰면 필터가 전부 날려 버려도 통과한다. 기대값은 “없어야 할 것”이 아니라 “있어야 할 것 전부”로 쓴다. 세 줄을 못 적겠다면 아직 문제를 이해 못 한 상태다. 그 상태로 에이전트에 넘기면 에이전트도 이해 못 한 채로 넓게 고친다.

Edit deny

세 겹으로 건다. 뒤로 갈수록 확실하다.

1겹은 프롬프트다. 약하지만 필요하다. GREEN 요청에 실패 로그와 테스트만 통과하는 최소 수정, 테스트 파일 수정 금지, 통과만을 위한 조건 분기 금지, 범위 밖 파일 금지, 테스트를 고쳐야만 통과하면 멈추고 이유를 설명하라는 탈출구를 명시한다. 탈출구를 열어 주지 않으면 몰래 빠져나간다.

2겹은 권한이다. Claude Code라면 테스트 경로를 쓰기 금지로 만들 수 있다. .claude/settings.json에 넣는다. 경로 규칙은 Edit(...)를 쓴다. 문서 기준으로 Write(경로) 형태는 파일 권한 검사에 매칭되지 않는다. deny 예시 JSON은 다음 블록이다.

{
  "permissions": {
    "deny": [
      "Edit(tests/**)",
      "Edit(**/*.test.ts)",
      "Edit(**/*.spec.ts)"
    ]
  }
}

tests/는 테스트 디렉터리 전부다. /.test.ts와 /.spec.ts는 디렉터리 밖에 둔 테스트 파일이다. 권한 규칙은 프롬프트와 달리 설득당하지 않는다. RED 테스트를 작성할 때만 잠깐 풀고, GREEN 단계에서는 걸어 둔다.

훅으로도 비슷하게 할 수 있지만 PostToolUse 훅은 차단하지 못한다. 도구가 이미 실행된 뒤에 뜨는 이벤트라, 종료 코드 2를 반환해도 모델에게 stderr를 보여줄 뿐 편집을 되돌리지는 않는다. 차단하려면 PreToolUse를 써야 한다. 공식 문서 자체가 훅의 if 필터를 best-effort라고 표현하면서, 하드한 허용과 거부는 훅이 아니라 권한 시스템을 쓰라고 권고한다. 위의 deny 규칙이 정석인 이유다. Edit/Read deny는 Claude의 내장 파일 도구와 인식된 Bash 파일 명령에 걸린다. 임의의 Node나 Python 스크립트가 파일을 직접 열면 OS 샌드박스 없이는 우회될 수 있다.

Cursor는 도구마다 권한 모델이 다르다. 승인 모드와 훅, .cursorignore 조합으로 범위를 줄이고, 마지막에는 CI에서 테스트 경로 diff를 실패시킨다. Claude Code의 Edit deny만큼 강한 경로 금지가 없어도, PR 단계에서 조용한 테스트 변경은 막을 수 있다.

보상 해킹

에이전트에게 “테스트를 통과시켜라”고 하면, 통과에 이르는 경로는 두 개다. 코드를 고치거나, 테스트를 고치거나. 후자가 거의 항상 더 짧고 더 확실하다. 모델은 짧고 확실한 경로를 선호하도록 학습되어 있다.

이는 추측이 아니다. 대표적 패턴이 특정 테스트 케이스만 통과하도록 출력을 하드코딩하는 special casing이다. 이후 연구들은 이런 행동이 더 정교해지고 있다고 보고한다.

네 번째가 가장 안 보인다. if (category === 'vibe-coding') return [...] 같은 코드가 리팩터링처럼 위장해서 들어온다. 프롬프트에 “기대값을 바꾸지 마라”고 쓰는 것은 필요하지만 충분하지 않다. 지켜질 때가 많지만 안 지켜질 때도 있고, 안 지켜졌을 때 알 방법이 없다는 것이 진짜 문제다.

CI

3겹은 CI다. 권한 설정을 안 쓰는 도구를 쓰거나, 사람이 실수로 풀어 놓을 수도 있다. 마지막 그물이다. 구현 PR에서 테스트 경로 diff와 새로 추가된 it.skip을 실패시키는 GitHub Actions 예시는 다음 블록이다.

- name: 테스트 파일 변경 검사
  run: |
    if git diff --name-only origin/main...HEAD | grep -E '\.(test|spec)\.(ts|tsx|js)$'; then
      echo "::error::구현 PR에서 테스트 파일이 변경되었다."
      echo "동작 변경이면 PR 라벨에 behavior-change 를 붙인다."
      exit 1
    fi

origin/main...HEAD는 베이스부터 이 PR까지의 파일 목록이다. 확장자가 test나 spec이면 실패한다. 라벨로 우회 경로를 두는 것이 중요하다. 정말로 동작을 바꾸는 PR은 테스트를 고쳐야 한다. 요점은 전면 금지가 아니라 테스트 변경이 조용히 지나가지 못하게 하는 것이다. it.skip과 xit는 겉보기 통과의 다른 이름이다. 구현 PR에서 새로 추가된 skip을 같은 검사에 넣으면, 단언을 지우는 경로가 조용히 지나가지 못한다.

Cursor는 도구마다 권한 모델이 다르다. 승인 모드와 훅, .cursorignore 조합으로 범위를 줄이고, 마지막에는 이 CI가 그물이다. Claude Code의 Edit deny만큼 강한 경로 금지가 없어도, PR 단계에서 조용한 테스트 변경은 막을 수 있다. Edit(tests/**)는 .claude/settings.json의 permissions.deny다. Write(경로) 형태는 파일 권한 검사에 매칭되지 않는다. PostToolUse는 도구가 이미 실행된 뒤라 종료 코드 2를 반환해도 편집을 되돌리지 않는다. PreToolUse가 차단이다. 훅의 if 필터는 best-effort다. 임의의 Node나 Python 스크립트가 파일을 직접 열면 OS 샌드박스 없이는 우회될 수 있다. RED 때만 deny를 풀고 GREEN에서는 걸어 둔다.

같은 버그도 여러 계층에서 드러낼 수 있고, 계층마다 비용이 다르다.

판단 기준은 하나다. 이 증상을 가장 싸게 실패시키는 계층은 어디인가. 증상이 UI에만 보이면 컴포넌트나 통합 테스트가 유리하다. API 계약이 깨졌다면 핸들러 단위 테스트가 가장 빠르다. 결제나 배포처럼 공개 경로가 위험하면 마지막에 smoke E2E를 한 개만 둔다. 처음부터 E2E만 고르면 피드백이 분 단위가 되고, 에이전트가 추측으로 넓게 고친다. 한 번 시도하는 비용이 비쌀수록 한 번에 많이 바꾸려 하기 때문이다. 피드백 루프 속도는 편의 문제가 아니라 diff 크기를 직접 결정하는 변수다. 작업 전에 “이 증상은 [계층]에서 [초] 안에 실패시킬 수 있다”는 한 줄이 나와야 한다.

레거시 코드에 테스트 인프라가 아예 없으면, 버그 하나를 고치자고 프레임워크를 새로 도입하는 것은 배보다 배꼽이다. 골든 파일 하나로 시작한다. 현재 출력을 그대로 기록하고, 그게 안 바뀌는지만 본다. 프레임워크 없이 출력을 박제하는 명령은 다음 블록이다.

node scripts/dump-output.js > tests/golden/before.json
node scripts/dump-output.js | diff tests/golden/before.json -

첫째 줄은 현재 출력을 파일로 남긴다. 둘째 줄은 같은 명령을 다시 돌려 파일과 비교한다. 옳은 동작이 아니라 현재 동작을 박제하는 것이 목적이다. 리팩터링이라면 버그까지 보존해야 한다.

dump-output.js는 프레임워크 없이 출력을 stdout에 찍는 스크립트다. 리다이렉트로 tests/golden/before.json을 만들고, 같은 명령을 파이프로 diff에 넣는다. 차이가 있으면 현재 동작이 바뀐 것이다. 올바른 답을 기댓값으로 적어 넣는 단위 테스트가 아니다. 인프라가 없을 때 특성화 테스트와 같은 일을 한다. 조건이 없는 버그를 감으로 고치면 고쳤는지 알 방법이 없다. 실패 조건이 프로덕션에만 있으면 로그에서 실제 입력을 뽑아 픽스처로 만든다. 개인정보는 마스킹하되 구조는 그대로 둔다.

실패 조건이 프로덕션에만 있으면 로그에서 실제 입력을 뽑아 픽스처로 만든다. 개인정보는 마스킹하되 구조는 그대로 둔다. 탐색 중이라 무엇을 기대해야 할지 모르면 정직하게 스파이크로 선언하고, 결과물을 버릴 각오로 진행한다. 별도 브랜치나 워크트리에서 하고, 알아낸 것만 들고 나와서 그때 테스트를 쓴다. 스파이크 코드를 그대로 머지하는 것이 이 루프가 무너지는 가장 흔한 경로다.

오탈자, 로그 문구, 주석 정도는 이 루프 밖이다. 동작을 바꾸거나, 프로덕션에 이미 나가 있거나, 실패했을 때 조용히 넘어갈 수 있는 코드에서 루프가 필요해진다. 셋 중 둘이 겹치면 쓴다.

변이 테스트와 헛테스트

좋은 RED인지는 셋으로 가른다. 구현을 일부러 망가뜨려도 실패하는가. 필터를 반대로 뒤집거나 return []로 바꿔도 통과하면 그 테스트는 아무것도 안 지킨다. Stryker 같은 변이 테스트 도구가 있으나, 손으로 세 군데만 건드려도 대부분의 헛테스트가 걸러진다. 실패 메시지만 보고 어디를 고칠지 알 수 있는가. expected true to be false는 나쁜 메시지다. 실제값과 기대값이 둘 다 보여야 한다. 값 비교(toEqual)가 불리언 단언(toBe(true))보다 낫다. 두 번 연속 같은 결과인가. 시간, 랜덤, 네트워크, 실행 순서에 의존하면 GREEN 판정에 쓸 수 없다. 시계는 vi.useFakeTimers()로 고정하고 네트워크는 스텁한다. 플래키한 테스트를 안고 루프를 돌리면 에이전트가 통과할 때까지 아무거나 바꾼다.

not.toContain('b')는 필터가 전부 날려 버려도 통과한다. toEqual(['a'])는 있어야 할 목록 전체다. 조건, 현재, 기대 세 줄이 나와야 테스트가 써진다. /vibe-coding 목록에 status='draft' 글이 2개 있을 때, 공개 목록에 draft가 함께 노출되는 현재, published만 보여야 하는 기대가 그 세 줄의 사례다. 세 줄을 못 적겠다면 아직 문제를 이해 못 한 상태다. 그 상태로 에이전트에 넘기면 에이전트도 이해 못 한 채로 넓게 고친다.

경로 오타 Cannot find module과 헬퍼 미구현 seed is not a function, Timeout of 5000ms exceeded는 버그와 무관한 실패다. 처음부터 통과하면 조건이 틀린 것이다. RED 로그는 요약하지 않고 /tmp/red.log 내용을 그대로 붙인다. GREEN의 정의는 대상 테스트만이 아니라 전체 러너 통과다. npx vitest run 2>&1 | tee /tmp/green.log가 그 증거다.

계층과 인프라가 없을 때

같은 버그도 여러 계층에서 드러낼 수 있고, 계층마다 비용이 다르다. 단위는 ms이고 순수 로직에 맞다. 연결 문제는 못 잡는다. 통합은 초 단위이고 API 계약, DB 쿼리, 핸들러에 맞다. 셋업 비용이 있다. 컴포넌트는 UI 조건부 렌더링과 상태에 맞다. 브라우저 차이는 못 잡는다. E2E는 분 단위이고 결제, 인증 같은 공개 경로에 맞다. 느리고 플래키하다.

판단 기준은 이 증상을 가장 싸게 실패시키는 계층이다. 증상이 UI에만 보이면 컴포넌트나 통합이 유리하다. API 계약이 깨졌다면 핸들러 단위가 가장 빠르다. 결제나 배포처럼 공개 경로가 위험하면 마지막에 smoke E2E를 한 개만 둔다. 처음부터 E2E만 고르면 피드백이 분 단위가 되고, 에이전트가 추측으로 넓게 고친다. 한 번 시도하는 비용이 비쌀수록 한 번에 많이 바꾸려 하기 때문이다. 피드백 루프 속도는 편의 문제가 아니라 diff 크기를 직접 결정하는 변수다. 작업 전에 “이 증상은 [계층]에서 [초] 안에 실패시킬 수 있다”는 한 줄이 나와야 한다.

레거시 코드에 테스트 인프라가 없으면 골든 파일 하나로 시작한다. node scripts/dump-output.js > tests/golden/before.json이 현재 출력을 남긴다. node scripts/dump-output.js | diff tests/golden/before.json -가 같은 명령을 다시 돌려 비교한다. 옳은 동작이 아니라 현재 동작을 박제하는 것이 목적이다. 리팩터링이라면 버그까지 보존해야 한다. 실패 조건이 프로덕션에만 있으면 로그에서 실제 입력을 뽑아 픽스처로 만든다. 개인정보는 마스킹하되 구조는 그대로 둔다.

탐색 중이라 무엇을 기대해야 할지 모르면 스파이크로 선언하고 결과물을 버릴 각오로 진행한다. 별도 브랜치나 워크트리에서 하고, 알아낸 것만 들고 나와서 그때 테스트를 쓴다. 스파이크 코드를 그대로 머지하는 것이 이 루프가 무너지는 가장 흔한 경로다.

RED의 tee /tmp/red.log는 에이전트 입력이자 PR 증거다. 경로 오타와 헬퍼 미구현, 타임아웃은 버그와 무관한 실패다. 처음부터 통과하면 조건이 틀린 것이다. 필터를 반대로 뒤집거나 return []로 바꿔도 통과하면 그 테스트는 아무것도 안 지킨다. Stryker가 변이 테스트 도구다. 손으로 세 군데만 건드려도 대부분의 헛테스트가 걸러진다. expected true to be false는 나쁜 메시지다. toEqual이 toBe(true)보다 낫다. vi.useFakeTimers()로 시계를 고정하고 네트워크는 스텁한다. 같은 명령을 두 번 연속으로 돌려 플래키를 가른다.

Vitest 단언 toEqual(['a'])는 있어야 할 목록 전체다. not.toContain('b')는 필터가 전부 날려 버려도 통과한다. 조건, 현재, 기대 세 줄이 나와야 테스트가 써진다. /vibe-coding 목록에 status='draft' 글이 2개 있을 때, 공개 목록에 draft가 함께 노출되는 현재, published만 보여야 하는 기대가 그 세 줄의 사례다.

GREEN 요청에 실패 로그를 그대로 붙인다. 테스트 파일 수정 금지, 리팩터 하지 말 것이 같은 블록에 있다. npx vitest run 전체 통과가 GREEN의 정의다. 대상 테스트만 돌리면 다른 테스트를 깨뜨린 것을 못 본다. git diff --name-only | grep -E '\\.(test|spec)\\.'가 테스트 변경 경고다. REFACTOR에서 깨지면 git reset --hard HEAD다. 그 자리에서 테스트를 고치면 GREEN과 REFACTOR가 한 덩어리가 된다.

Edit deny의 Edit(tests/), Edit(/.test.ts), Edit(/.spec.ts)는 .claude/settings.json의 permissions.deny다. Write(경로)는 파일 권한 검사에 매칭되지 않는다. PostToolUse는 도구가 이미 실행된 뒤라 종료 코드 2를 반환해도 편집을 되돌리지 않는다. PreToolUse가 차단이다. 훅의 if 필터는 best-effort다. 하드한 허용과 거부는 권한 시스템이다. 임의의 Node나 Python 스크립트가 파일을 직접 열면 OS 샌드박스 없이는 우회될 수 있다. RED 때만 풀고 GREEN에서는 걸어 둔다.

CI grep은 git diff --name-only origin/main...HEAD | grep -E '\\.(test|spec)\\.(ts|tsx|js)$'다. 구현 PR에서 테스트 파일이 변경되면 실패한다. behavior-change 라벨이 우회 경로다. 전면 금지가 아니라 테스트 변경이 조용히 지나가지 못하게 하는 것이 요점이다. Cursor는 승인 모드와 훅, .cursorignore로 범위를 줄이고, 마지막에는 이 CI가 그물이다.

보상 해킹의 짧은 경로는 테스트 수정이다. 기대값 수정, it.skip, 단언 약화, 특정 입력 하드코딩, 테스트에 맞춘 조건 분기가 겉보기 통과의 실제다. if (category === 'vibe-coding') return [...]가 리팩터링처럼 위장한다. Claude 3.7 Sonnet 시스템 카드의 special casing이 관찰 사례다. EvilGenie는 테스트 파일 편집 감지를 탐지 방법 중 하나로 쓴다. 프롬프트에 기대값을 바꾸지 말라고 쓰는 것은 필요하지만, 안 지켜졌을 때 알 방법이 없으면 충분하지 않다.

REPORT의 남은 위험 칸이 비면 리뷰가 추측으로 돌아간다. sitemap의 draft 제외와 예약 발행처럼 이 PR 범위가 아닌 것을 적는다. 구현 전 실패 로그가 없는 AI 코딩 PR은 리뷰를 시작하지 않는다는 팀 규칙이 PR 템플릿의 RED 칸과 짝이다. 규칙은 선의에 기대고, CI는 안 기댄다.

마무리

앞에서 다룬 테스트 우선 AI 코딩 루프의 핵심만 짧게 정리한다.

• 자연어 지시로는 “바꾸면 안 되는 것”을 전달하기 어렵고, 실패 테스트가 그 계약을 고정한다.
• RED는 실패가 아니라 의도한 이유의 실패여야 한다. 처음부터 통과하면 조건이 틀린 것이다.
• 통과 경로의 짧은 쪽은 테스트 수정이다. Edit deny와 CI grep이 그 경로를 잠근다.
• PostToolUse는 차단이 아니고, Write(path)는 파일 권한 검사에 매칭되지 않는다.
• GREEN은 최소 diff와 전체 테스트 통과이며, REFACTOR는 초록불 이후에만 별도 커밋이다.
• REPORT의 남은 위험 칸이 비면 리뷰가 추측으로 돌아간다.
• 계층은 싼 실패부터 고르고, 인프라가 없으면 골든 파일로 현재 동작을 박제한다.

「실패 로그가 없는 GREEN은 채점이 아니다」 채점자와 응시자를 같은 세션에 두면 기대값이 움직인다. RED를 사람이 본 뒤에 테스트 경로를 잠그고, 그다음에만 구현을 맡긴다.

출처와 링크

• Reward hacking is becoming more sophisticated and deliberate: Claude 3.7 Sonnet special-casing
• EvilGenie: a Reward Hacking Benchmark: 테스트 파일 편집 감지
• Activation-Level Interventions for Reward Hacking in LLM Coding Agents: 하드코딩을 통한 명세 위반
• Claude Code Hooks Reference: PostToolUse 차단 불가, 하드 차단은 권한 시스템
• Claude Code Permissions: Edit(path) deny, Write(path) 미매칭
• Stryker Mutator: 변이 테스트
• Vitest: 러너 예시
• 롤백 가능한 AI 리팩터링: diff 상한과 롤백 계약

조사 기준: 2026년 8월. 에이전트 도구의 훅과 권한 스키마는 버전마다 바뀌므로 적용 전에 사용 중인 버전 문서를 다시 본다. 러너는 프로젝트에 맞게 고르고 순서(RED-GREEN-REFACTOR-REPORT)만 고정한다.