검증 경로 고르기

무엇이 참이어야 하는지 문장으로 쓸 수 있으면 재라. 쓸 수 없을 때만 봐라.

0. 왜 있는가

화면을 직접 조작해 눈으로 보는 것은 강력하다. 그리고 편하다. 도구가 있으면 쓰게 된다.
그런데 그것은 사다리의 맨 아래 칸이다.

세 가지 비용이 있다.

• 사람의 입력장치를 점유한다. 같은 기계에서 사람이 일하고 있으면 그 일을 멈춘다
• 사용량을 크게 먹는다. 화면 한 장을 보는 값이 수치 백 개를 재는 값보다 비싸다
• 근거가 남지 않는다. "봤더니 괜찮아 보였다"는 검수자가 확인할 수 없다 ([[work-review]] §2-1)

셋째가 가장 크다. 앞의 둘은 불편이지만 셋째는 검증이 성립하지 않는 것이다.

1. 사다리 — 위에서부터 시도한다

#	경로	언제 쓰나	남는 것
1	정적 검사	실행하지 않고 답이 나옴	파일·해시·문법·설정값
2	수치 계측	참/거짓이 수치로 정해짐	로그에 적힌 실측치
3	기록된 산출물	사람이 봐야 하지만 지금 볼 필요는 없음	캡처·연속 프레임·영상
4	화면 직접 조작	무엇을 봐야 할지 모름	없음

한 칸 내려갈 때마다 이유를 댈 수 있어야 한다. 이유가 "그게 빠르니까"면 내려가지 마라.

2. 판별 질문 하나

"무엇이 참이어야 하는지 문장으로 쓸 수 있는가?"

쓸 수 있으면 잰다. 문장이 그대로 계측 항목이 된다.

확인하려는 것	잴 수 있는 형태
"집게가 물체에 닿고 멈춘다"	집게-물체 최소 거리, 접촉 중 물체 변위·속도 최댓값
"바닥에 부딪히지 않는다"	하강 중 최하단 Z 와 바닥 Z 의 최소 간격
"설정이 반영됐다"	런타임 API 로 값을 읽어 기댓값과 비교
"창이 제자리에 있다"	UI 상태 조회, 또는 애초에 위치를 코드로 지정
"키를 누르면 다시 시작된다"	프로그램이 스스로 그 경로를 트리거하고 결과를 로그로

쓸 수 없으면 본다. 다만 대개는 쓸 수 있는데 써보지 않은 것이다.
"눈으로 봐야 안다"고 결론내기 전에 위 표처럼 한 줄로 바꿔보라.

3. 이미 있는 프로그램 경로부터 읽어라

실측 사고: 화면을 직접 조작해 확인한 항목이 애초에 그 스크립트가 스스로 찍고 있던 것이었다.
프레임 캡처 호출이 이미 코드 안에 있었고, 그때까지 받은 산출물 전부가 그 경로로 나온 것이었다.
아무도 그것을 확인하지 않고 "이건 봐야 안다"로 넘어갔다.

→ 대상 프로그램이 이미 무엇을 남기는지 먼저 읽어라. 검증 수단이 이미 있을 때가 많다.

4. 정지 캡처와 연속 프레임은 다른 수단이다

움직임의 결함은 정지 캡처로 잡히지 않는다.

실측 사고: 오차 수치와 정지 캡처 몇 장을 보고 "화면에서는 제자리로 보인다" 고 판단했다.
사람이 실제로 실행해보니 그 오차는 제자리가 아니라 물체가 튕겨나간 거리였다.
정지 화면에는 튕기는 순간이 없었다. 수치는 맞았고 해석이 틀렸다.

무엇을 확인하나	수단
상태가 맞는가	정지 캡처 한 장
거동이 맞는가	연속 프레임
왜 그렇게 됐나	연속 프레임 + 같은 구간의 수치

연속 프레임은 화면 조작이 아니다. 3번 칸이지 4번 칸이 아니다 — 프로그램이 찍고
사람은 나중에 넘겨본다. 그 사이에 아무의 마우스도 멈추지 않는다.

5. 그래도 사람이 봐야 하는 것

• 주관적 판단 — "시연으로서 그럴듯한가", "읽기 편한가". 이건 재지지 않는다
• 예상 못 한 상태 — 팝업·권한 요청·처음 뜨는 창
• 무엇이 잘못됐는지 모를 때의 첫 탐색

앞의 둘째·셋째는 화면을 봐야 한다. 첫째는 다르다 —
주관적 판단은 대개 사람의 몫이지 실행자의 몫이 아니다.
실행자가 "괜찮아 보인다"고 판정하면 그건 결정을 대신 내린 것이다([[task-brief]] §0).

찾을 것이 이미 특정돼 있고 각각 참/거짓이 정해지는 상황이라면, 화면 조작은 답이 아니다.
화면 조작이 강한 것은 "무엇을 봐야 할지 모를 때"다.

5-1. 이미지를 여는 것은 싸다 — 비용을 이유로 눈 검증을 줄이지 마라

캡처를 열어 보는 것이 사용량을 크게 먹는다고 넘겨짚기 쉽다. 실측하면 아니다.
이미지 호출 직후 컨텍스트 증가분을 재니 장당 평균 764 토큰, 71장 합쳐 54,264 토큰 —
그 세션 전체 96.9M 토큰의 0.06% 였다.

이 착각의 출처는 단위다. base64 로 실린 이미지는 도구 출력 문자수의 대부분을
차지한다(실측 95.6%). 그래서 문자수만 보면 주범처럼 보인다. 하지만 이미지는 패치 단위로
토큰화되므로 문자수와 토큰이 자릿수 단위로 어긋난다.

문자수로 토큰을 추정하지 마라. 컨텍스트 증가분은 재는 것이지 환산하는 것이 아니다.
세션 기록의 요청별 토큰 값을 앞뒤로 빼서 직접 재라.

실측 사고: 이 착각으로 "사용량의 79%는 스크린샷을 열어본 호출이 만들었다" 고 보고하고
캡처를 축소하자는 대책까지 제안했다. 진짜 원인은 따로 있었고(고정 프리픽스 + 누적
히스토리 x 요청 수), 그 대책을 실행했다면 검증만 나빠지고 사용량은 그대로였을 것이다.

그러니 위 사다리에서 3번(기록된 산출물)을 아낄 이유는 없다. 비싼 것은 이미지가 아니라
4번(화면 직접 조작) 이고, 그건 사용량이 아니라 사람의 손과 시간을 가져간다.

6. 지시서에 적지 않으면 막히지 않는다

도구가 있으면 쓴다. 금지만 적으면 우회하고, 대안만 적으면 편한 쪽으로 돌아간다.
둘을 함께, 이유와 함께 적는다([[task-brief]] §2).

화면을 직접 조작하지 마라. 이유는 두 가지다 —
사람이 같은 기계에서 일하고 있고, "봤더니 괜찮아 보였다"는 근거가 되지 않는다.

대신:
- 참/거짓이 수치로 정해지는 것은 스크립트가 재서 로그에 남겨라
- 거동은 연속 프레임으로 남겨라. 저장 위치는 <새 폴더>. 기존 산출물은 덮지 마라
- 키 입력이 필요한 경로는 프로그램이 스스로 트리거하는 경로를 만들어라

검증 결과는 파일로 남아야 한다. "확인했다"는 보고는 근거가 아니다.

연계

• 근거의 자격 — [[work-review]] §2-1
• 지시서에 넣는 법 — [[task-brief]] §2·§3
• 실행자 쪽 행동 규칙 — [[implementation-conduct]]

이력 (필수 기록)

• 생성일: 2026-08-31
• 업데이트 횟수: 1
• 최근 업데이트: 2026-09-01
• 사용 이력:
  • 2026-09-01 — "이미지가 사용량을 먹는다"는 넘겨짚기를 실측으로 기각했다.
    도구 출력 문자수의 95.6%가 base64 이미지라 주범으로 보였지만, 컨텍스트
    증가분은 장당 764 토큰(전체의 0.06%)에 불과했다. 문자수와 토큰이 자릿수
    단위로 어긋난 것이다. 이 착각으로 캡처 축소 대책까지 제안했는데, 실행했다면
    검증만 나빠지고 사용량은 그대로였을 것이다.
    → §5-1 신설. 문자수로 토큰을 추정하지 말고 직접 재라. 그리고 사다리 3번
    (기록된 산출물)은 싸므로 비용을 이유로 줄이지 않는다.
  • 2026-08-31 — 신규 생성. 사용자가 "화면 조작이 사용량을 많이 먹으니 상황에 맞는
    방법을 정리하고 올바른 선택을 하도록" 요청했다. 계기는 실행자가 GUI 검증에
    화면 직접 조작을 써서 사용자가 쓰던 마우스를 가져간 것이었다.
    검토해보니 확인해야 할 네 항목 중 셋이 수치로 판정 가능했고, 넷째(거동)는
    연속 프레임으로 충분했다. 게다가 프레임 캡처 경로가 이미 그 스크립트 안에
    있었다(§3). 같은 회차에 §4의 정지 캡처 오판도 실제로 겪었다 —
    수치는 맞았는데 정지 화면에 튕기는 순간이 없어서 결함을 놓쳤다.