Verify — 변경이 실제로 배포·동작하는지 구동 확인

"고쳤다"·"커밋했다"가 아니라 "신 코드가 라이브에서 실제로 도는가" 를 grep·프로세스·실행으로 확정한다. 어댑터(claude/codex/openai) 무관 — 전부 Bash 명령 수준. SYSTEM.md §1 「완료」 정의의 실행 절차.

0. 무엇을 확인하고 언제 멈추나

• 검사는 근거로 고른다 — 요청한 동작, 실제로 바뀐 경로, 그 경로에 닿는 인접 위험, 그 프로젝트가 필수로 정한 검사. 줄 수만 보고 좁히지도, 「작은 수정」에 전체 검사 목록을 관성으로 붙이지도 않는다. 프로젝트 필수 검사는 임의로 빼지 않는다 — 과해 보이면 그 규칙을 따로 짚는다.
• 유지·복원의 기준은 사용자가 정한 버전이다(지정이 없으면 수정 전 동작) — 대조 방법은 §C. 새 구현·목업을 정답 자리에 놓지 않는다.
• 유효한 근거는 다시 만들지 않는다 — 같은 후보·관련 환경에서 이미 통과한 근거는 재사용한다. 그 뒤 코드·생성물·검사 신뢰성에 영향을 준 변경이 있으면 그 범위만 다시 확인한다. 커밋·문서 정리·보고 단계로 넘어갔다는 이유만으로 전부 반복하지 않는다.
• 자원을 다투는 검사는 겹치지 않는다 — 무거운 빌드·브라우저·GPU 검사와 시간·성능 예산 검사는 무리하게 병렬로 돌리지 않는다. 가볍고 독립적인 검사는 병렬로 둔다. 경합 중에 난 시간초과·성능 실패는 경합을 걷어 낸 뒤 다시 보고 제품 결함과 가른다.
• 멈출 때 — 요청 동작·변경 분기(§B)·필요한 인접 회귀가 확인됐고 새 위험 신호가 없으면 끝낸다. 무관한 기존 실패는 따로 보고하고, 승인 없이 수정 범위를 넓히지 않는다. 날짜 있는 기록은 «전에도 실패했다» 까지만 보인다 — «이번 변경과 무관» 은 수정 전 같은 조건 대조처럼 영향을 가른 근거가 있을 때만 쓰고, 없으면 «귀속 미확정» 으로 적는다. 맡은 필수 검사의 실패는 기존 실패여도 미완이다.
• 보고는 근거로 — 무엇을 바꿨고, 무엇으로 확인했고, 무엇이 미검증·한계인가. 검사 개수는 결과를 대신하지 않는다.

A. 반영 실측 — 변경이 실제로 도는가

원칙: 네가 바꾼 소스와 지금 실제로 도는 것이 같은지 확인한다. 인터프리트 실행이면 리로드로, 컴파일·빌드 산출물이면 재빌드+재배포 후에야 반영된다 — 그 프로젝트의 배포·실행 방식을 따른다. ③은 늘 한다. ①은 반영 확인이 요청 범위에 있거나 바꾼 소스가 빌드·변환을 거친 산출물로 실행될 때, ②는 그중 빌드·배포·재기동을 거쳐 반영되는 방식에서만 한다(핫리로드는 아래 예처럼 ①③). 생산 빌드에서만 CSS 가 변환되는 식이면 그 경로는 확인하되, 개발·생산 실행을 늘 둘 다 돌리라는 뜻은 아니다.

• ① 산출물–소스 일치: 이번에 바꾼 고유 마커(새 함수명·새 문구)가 실제로 도는 산출물에도 있는지 grep. 없으면 빌드/배포 누락(소스만 바뀐 상태). 옛 마커가 산출물에 남았는지 역방향으로도 확인하라 (신·구 공존 = 부분 빌드 신호).
• ② 시각 순서: 소스 수정 ≤ 빌드/배포 ≤ 프로세스 기동 순서여야 신 코드가 로드된 것. mtime 은 ls -la, 프로세스 기동은 ps -o lstart= -p <pid>. 소스가 산출물보다 새로우면 빌드 후 재수정된 것 — 재빌드부터.
• ③ 실동작 마커: 바뀐 경로를 실제 1회 흘려 로그·출력·응답에서 신 동작을 관측한다.
• 불일치 → 그 런타임의 재빌드·재배포 → 재실측. 소스 저장·커밋·typecheck 통과만 = 미완.

예 — 컴파일·빌드 후 배포되는 서비스: 소스 수정 → 재빌드 → 재배포/프로세스 재시작 → 도는 산출물에서 마커 grep(①) + 산출물 mtime vs 프로세스 기동시각(②) + 런타임 로그·응답에서 신 동작 관측(③). 인터프리트·핫리로드 런타임이면 빌드 단계 없이 리로드 후 ①③. 정적 사이트·스크립트도 같은 골격: 바꾼 것이 실제로 서비스되는 것에 반영됐는지 대조한다.

B. 분기 커버리지 — 새 분기를 실제로 탔는가

• 이번 변경에서 새로 만들거나 바꾼 조건분기를 나열한다(diff 또는 확보한 원문과 대조해 if/삼항/switch/단락 연산/길이·개수 비교를 확인한다).
• 분기마다 그 분기를 실제로 타는 입력 최소 1개로 실측한다(단위 실행·수동 호출·실메시지). 예: length > 4096 분기를 새로 만들었으면 4096자 초과 입력을 반드시 하나 넣어본다.
• 기존 픽스처·테스트가 전부 같은 분기만 치면 새 경로는 미검증으로 명시하라 — "테스트 통과"가 그 분기의 검증이 아니다.

C. 행동 보존 대조 — 기존 동작을 바꾸는 수정

• 교체·리팩터뿐 아니라 기존 조건·기본값·변환을 바꾸는 버그 수정에도 적용한다.
• 변경이 영향을 주는 입력 유형별로 수정 전 동작과 요구된 변경을 대조한다. 테스트에 없는 기존 분기도 포함해 대표 입력으로 확인한다. 수정 전 코드는 git show 등으로 읽고, 버전 관리가 없으면 편집 전에 원문을 확보한다. 신 코드만 보고 옛 동작을 추정하지 않는다.
• 삭제·통합이면 지우는 쪽에만 있던 사용자 가시 정보·동작(위치·힌트 등)이 남는 쪽에 있는지도 대조한다 — 사용자가 승인한 제거는 의도적 변경이다.
• 신 구현과 항목별 대조: 각 옛 동작이 보존 / 의도적 변경 / 회귀 중 무엇인지 명시한다.
• 회귀를 '의도적 다운그레이드'로 합리화하지 마라 — 의도적 변경이면 그 근거와 사용자 영향을 적고, 근거가 없으면 복구한다.

D. 완료 보고 전 체크리스트

보고 직전 아래를 확인하고, 미충족 항목은 "미완/보류"로 명시한다(조용한 '완료' 금지):

• 라이브 반영됨 — 단 배포가 요청 범위 안일 때만 실행한다. 범위 밖이면 돌리지 말고 «반영했으나 미배포» 로 적어라. 헌법이 "「고쳐줘」에 커밋·배포까지 하지 마라" 고 못 박았고, 배포는 돌고 있는 응답을 끊는다. 미배포는 결함이 아니라 상태다.
• (§A① 적용 시) 산출물 마커 grep + 빌드·재기동 방식이면 시각 순서(소스≤산출물≤기동, ②) 통과
• 새 분기마다 실입력 1개 실측 (§B)
• 기존 동작을 바꿨으면 수정 전후 대조 완료 (§C)
• 실동작 마커로 신 경로 1회 관측 (§A③)

경계 — code-review 와의 분업 (중복 구현 금지)

• code-review = 정적 결함 탐지("이 코드에 버그·더 나은 방법이 있나" — diff 를 읽는다). 반영 전.
• verify = 동적 구동 확인("이 변경이 실제로 반영·동작하나" — 산출물을 돌린다). 반영 후.
• verify 는 결함 분석을 재구현하지 않고, code-review 는 배포·부팅·분기 실측을 하지 않는다.