Verify

---
name: verify
description: "변경이 실제로 배포·동작하는지 구동으로 확인하는 검증 스킬 (결함 탐지가 아니라 '진짜 도는가'). (1) '배포/반영/라이브 적용 다 됐어?', '이거 실제로 돌아?' 확인, (2) 코드 수정·리팩터·교체를 '완료' 보고하기 직전 DoD 점검, (3) 빌드·배포가 필요한 런타임에서 도는 산출물이 실제로 갱신됐는지 실측(반영 누락·스테일 산출물 방지), (4) 새 조건분기를 만든 뒤 그 분기가 실제로 타지는지 확인, (5) 함수·포맷터·모듈 교체 후 옛 동작 회귀 여부 대조. 코드의 '결함'을 찾는 code-review 와 구분 — 이건 변경이 *실제로 반영되고 의도대로 도는지*를 grep·프로세스·실행으로 구동 확인하는 스킬이다. 재빌드·재배포 후 마커 실측, 분기별 실입력 1개, 교체 시 옛 행동 인벤토리 대조, 완료 보고 전 체크리스트."
---

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

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

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

원칙: 네가 바꾼 *소스*와 지금 *실제로 도는 것*이 같은지 확인한다. 인터프리트 실행이면 리로드로,
컴파일·빌드 산출물이면 재빌드+재배포 후에야 반영된다 — 그 프로젝트의 배포·실행 방식을 따른다.

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

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

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

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

## C. 행동 보존 대조 — 교체가 무엇을 잃었나 (교체·리팩터 시만)

- 옛 구현의 **동작 인벤토리**를 먼저 만든다: 입력 유형별 관측 동작·엣지 케이스·포맷 보장.
  (git show 로 교체 *전* 코드를 읽고 목록화 — 신 코드만 보고 추정 금지.)
- 신 구현과 항목별 대조: 각 옛 동작이 **보존 / 의도적 변경 / 회귀** 중 무엇인지 명시한다.
- 회귀를 '의도적 다운그레이드'로 합리화하지 마라 — 의도적 변경이면 그 근거와 사용자 영향을 적고,
  근거가 없으면 복구한다.

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

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

- [ ] 라이브 반영됨(빌드·배포가 필요한 런타임이면 재빌드·재배포 실행)
- [ ] 산출물 마커 grep + 시각 순서(소스≤산출물≤기동) 통과 (§A①②)
- [ ] 새 분기마다 실입력 1개 실측 (§B)
- [ ] (교체·리팩터면) 옛 행동 인벤토리 대조 완료 (§C)
- [ ] 실동작 마커로 신 경로 1회 관측 (§A③)

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

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