모든 에이전트 작업은 실행 가능한 명령어로 끝나야 한다

npm test -- --grep 

## 왜 이것이 실제 격차를 드러내는가

명령어는 에이전트 외의 누군가가 실행할 수 있어야 한다. 이 단 하나의 제약 조건은 요약본이 놓치는 세 가지를 강제한다:

1. **명령어가 존재해야 한다.** 에이전트는 테스트 명령어, 개발 서버 URL, 시드 스크립트를 알아야 한다. 만약 모른다면, 그것은 모델의 약점이 아니라 온보딩 문서에 실제 격차가 있다는 의미다.
2. **예상 결과가 구체적이어야 한다.** '테스트 통과'는 구체적이지 않다. '12 passing, 0 failing, ~3s'는 구체적이다. 모호한 예상 결과는 에이전트가 실제로 확인하지 않았다는 신호다.
3. **1분 안에 실행할 수 있어야 한다.** 회의적인 시각으로 접근하는 비용이 '에이전트의 diff를 열어 200줄을 읽기'에서 '한 줄 붙여넣고 3초 기다리기'로 떨어진다. 당신은 실제로 확인 작업을 시작한다.

## 명령어가 계약 검사일 때

API 작업의 경우, 실행 가능한 명령어는 보통 단위 테스트가 아니다. 그것은 실행 중인 서비스에 접근하여 응답을 에이전트가 이번 세션에서 작성하지 않은 계약(contract)과 비교하는 무언가이다.

이것이 규칙의 가장 높은 레버리지 버전이다: 명령어가 작업보다 앞선 아티팩트를 검사한다. 에이전트는 5분 전에 자신이 작성한 테스트는 합리화할 수 있다. 하지만 라이브 응답이 사양에 나열되지 않은 필드를 반환하는 경우, 3개월 동안 저장소에 있었던 명세(spec)를 합리화할 수는 없다.

우리는 이 루프를 중심으로 [Powerduck](https://www.powerduck.com/)을 구축했다: OpenAPI 파일이 로컬에 존재하고, 에이전트의 '완료' 명령어는 실행 중인 엔드포인트에 대한 계약 검사이다 — 상태 코드, 미디어 타입, 응답 본문 모두가 에이전트가 반환해야 한다고 생각하는 것과 비교되는 것이 아니라 명세와 비교된다. 만약 명령어가 실패하면, 요약본이 아무리 자신감 있게 들려도 에이전트는 끝나지 않은 것이다.

## 피해야 할 함정

명령어가 에이전트가 암기하고 당신이 읽는 것을 멈추게 하는 의식이 되도록 내버려 두지 마라. 모든 작업이 동일한 `npm test`로 끝나고 당신이 항상 '괜찮아 보인다'고 말한다면, 당신은 단지 신뢰 문제를 한 단계 아래로 옮긴 것뿐이다.

작업과 명령어를 회전시키세요. 응답 형태의 리팩토링은 단위 테스트(unit test)가 아니라 계약 검사(contract check)가 필요합니다. 레이스 조건(race-condition) 수정에는 반복 실행 명령어(repeated-run command)가 필요합니다. 새로운 엔드포인트는 라이브 경로에 대한 curl이 필요합니다. 명령어는 에이전트의 근육 기억(muscle memory)과 일치하는 것이 아니라 위험도와 일치해야 합니다.

## 다음 세션에서 시도해 보세요

실행하지 않고 닫으려던 다음 에이전트 작업을 골라보세요. 병합(merge)하기 전에 명령어를 요청하세요. 대부분의 경우 10초 안에 받고 실행하게 될 것입니다. 그렇지 않은 단 한 번의 경우—에이전트가 망설이는 순간—그것이야말로 이 규칙이 당신을 후회할 만한 병합으로부터 구해주었던 시간입니다.