# 사진 판독기

> 기록으로 결과를 못 정하는 검사는 사진으로 판정합니다. 그 판정을 규칙이 다시 거르고, 다른 회사의 모델이 한 번 더 봅니다.

- 수치: 거짓 통과 0
- 상태: wip
- 사람이 보는 화면: https://nobles92ts-ship-it.github.io/ko/built/android-qa/judge/
- 반대 언어: https://nobles92ts-ship-it.github.io/en/built/android-qa/judge/index.md
- 이 사이트 안내(AI용): https://nobles92ts-ship-it.github.io/ko/llms.txt

---

**사진 판독기는 자동 검사가 찍어 둔 게임 화면 사진을 AI가 읽고, 검사 항목마다 «통과·실패·판정 불가·해당 없음» 중 하나를 적는 프로그램입니다.** 게임이 남긴 기록만으로는 결과를 정할 수 없는 검사를, 사람 대신 판정하려고 만들었습니다.

> **[도판]** 사진 판독기가 도는 순서. AI 가 판정하고, 코드로 짠 규칙이 그 판정의 근거를 다시 확인하고, 사람이 다시 안 볼 판정만 다른 모델이 한 번 더 본다.
>
> 로그로 결과를 못 정한 검사의 화면 사진이 다섯 칸을 차례로 지난다. 화면 사진은 판정 기준·누른 순서와 함께 판독기(AI)로 가고, 판독기는 네 판정 중 하나와 근거 사진을 낸다. 규칙 검사가 근거 사진을 정말 열었는지 등 다섯 가지를 확인해 판정을 낮출 수 있다. 두 번째 눈은 통과와 해당 없음만 다른 모델로 다시 보고, 판독기와 다르면 보고서에서 사람이 먼저 본다.

## 기록으로 결과를 못 정하는 검사가 생각보다 많습니다

이 QA 서버는 결과를 **게임이 남긴 기록**으로 판정합니다([조작과 판정](/ko/built/android-qa/driving/index.md)). 로그인이 됐는지는 서버와 주고받은 기록을 보면 압니다.

그런데 검사 목록에는 이런 항목이 섞여 있습니다.

| 검사 항목 | 기록으로 정해지나 |
|---|---|
| 로그인이 되는가 | 정해집니다 — 서버와 주고받은 기록이 남습니다 |
| 화면 왼쪽에 이름, 가운데에 캐릭터, 오른쪽에 목록이 보이는가 | 안 정해집니다 — 무엇이 **보이는지**는 기록에 없습니다 |

이런 항목은 사진만 남겨 두고 사람이 한 장씩 넘겨 보며 판정했습니다. 판독기를 처음 돌린 날에는 171건을 판정하려고 사진 193장을 봐야 했습니다. 그 자리를 판독기가 맡았습니다.

## AI의 답을 그대로 믿지 않습니다 — 규칙이 한 번 더 거릅니다

AI는 그럴듯한 답을 잘 만듭니다. 그래서 판정마다 **어느 사진에서 무엇을 봤는지**를 적게 하고, 그 답을 코드로 짠 규칙이 다시 검사합니다.

| 규칙이 묻는 것 | 걸리면 |
|---|---|
| 근거로 적은 사진이 실제로 있나 | 판정을 낮춥니다 |
| 그 사진을 **정말 열어 봤나** | 판정을 낮춥니다 |
| «눌러서 결과를 보는» 항목인데, 결과 없이 통과를 줬나 | 판정을 낮춥니다 |

「정말 열어 봤나」는 AI가 남긴 작업 기록(어떤 파일을 열었는지)과 대 봅니다. **말로 적은 근거를 행동 기록으로 확인하는** 셈입니다. 규칙은 판정을 낮출 수만 있고 올리지는 못합니다.

하나 더 있습니다. 검사가 끝난 뒤 **버튼 좌표를 고친 적이 있으면** 그 판정에 경고를 붙입니다. 사진은 맞는 화면처럼 보여도, 그 검사 때는 다른 버튼을 눌렀을 수 있어서입니다. 이 경고가 없었으면 거짓 통과가 한 건 나갈 뻔했습니다.

## 손으로 해 둔 판정과 대 보니 171건 중 170건이 같았습니다

처음 만든 날(2026-09-11), 이미 손으로 판정해 둔 171건에 판독기를 돌려 대 봤습니다. **170건이 같았고, 통과가 아닌 것을 통과라고 한 경우는 0건**이었습니다.

다른 한 건은 판독기가 더 조심스러웠던 경우입니다. 그리고 판독기가 **손판독의 실수 두 개**를 찾아냈습니다 — 판정 기준을 중간에 잘린 채 읽은 것, 입력 칸에 남아 있던 옛 글자를 「입력했다」로 본 것.

2026-09-23 에는 모델을 새 판으로 바꾸고, 판독할 때마다 딸려 들어가던 도구 목록·설정 같은 **짐을 덜었습니다.** 같은 171건에 **비용 $40.51 → $16.00, 걸린 시간 약 15분 → 8분**, 거짓 통과는 그대로 0건입니다. 판독 모델은 이제 **가장 새 Opus를 자동으로 따라가게** 묶어 두었습니다.

## 두 번째 눈 — 다른 회사의 모델이 «통과»와 «해당 없음»을 한 번 더 봅니다

통과와 해당 없음은 **사람이 다시 안 보는 판정**입니다. 실패나 판정 불가는 어차피 누군가 들여다봅니다. 그래서 이 둘만 한 번 더 봅니다.

보는 쪽은 **Jev**라는, TypeSafe 가 만든 판정용 모델입니다. 정해 준 선택지 중 하나를 고르고, 얼마나 자신 있는지를 숫자로 냅니다. 다만 Jev는 사진을 못 봅니다. 그래서 다른 AI가 **판정 기준을 모르는 채로** 그 검사의 사진에 무엇이 있는지 글로 옮기고, Jev가 그 글과 판정 기준을 읽고 고릅니다.

판독기와 답이 다르면 보고서 맨 위 «두 번째 눈» 표에 올라가고, **사람이 그것부터 봅니다.** 판정 자체는 바꾸지 않습니다.

## 판독기가 틀린 건, 판독기에게 건넨 메모가 틀려서였습니다

판정 규칙을 정하고(아래) 정답지를 고친 뒤 다시 대 보니, 판독기가 <strong>틀린 «해당 없음»</strong>을 낸 건이 하나 남았습니다.

원인은 판독기가 아니라 **판독기에게 건넨 메모**였습니다. 한 화면에 「가운데 모델은 보유했을 때만 보인다」고 적어 뒀는데, 기획서에는 「선택한 항목의 외형을 보여 준다」고 되어 있었고 나중 빌드에서도 보유와 상관없이 나왔습니다. 판독기는 이 메모를 **사실로 믿고**, 가운데가 빈 화면을 «실패»가 아니라 «전제가 안 맞아 해당 없음»으로 판정했습니다.

메모를 지우고 같은 사진으로 다시 판독하니 <strong>«실패»</strong>가 나왔습니다. 그 뒤로 판독기에게 주는 메모에는 **요구 조건(무엇을 갖고 있어야 하나)만** 적습니다. 화면이 어떻게 동작한다는 주장은 적지 않습니다 — 판독기는 그걸 사실로 읽습니다.

## 사진으로도 못 푸는 것 — «누른 적이 없는» 검사

판정 불가가 왜 많이 나오는지 세어 봤더니(2026-09-10), <strong>판정 불가 126건 중 97건이 「화면은 맞는데 누른 결과가 없음」</strong>이었습니다. 자동 검사가 그 화면까지 가기만 하고, 정작 **눌러야 할 것을 안 누른** 것입니다.

이건 판독기를 아무리 잘 만들어도, 다시 돌려도 안 풀립니다. **누르는 단계를 넣는 것**만이 답입니다.

예를 들어 「ID 입력 칸에 글자를 넣을 수 있나」는 늘 판정 불가였습니다. 자동 검사가 칸을 누르기만 하고 글자는 안 넣었고, 칸에 보이던 글자는 **지난번에 남은 값**이었기 때문입니다. 2026-09-28 에 두 단계를 넣었습니다 — 넣기 전에 한 장 찍고, 이번 계정 ID를 넣는다. 두 사진에서 칸의 글자가 바뀐 것이 보이자 판독기는 통과를 줬고, 두 번째 눈도 같은 답이었습니다.

## 판독기가 따로 적어 둔 메모에서 버그가 하나 나왔습니다

판독기는 판정 기준과 상관없는 이상도 <strong>«별건»</strong>으로 따로 적습니다. 그중 하나가 실제 버그였습니다.

한 화면의 이름 칸에 이름 대신 `Not Found '…'` 같은 **내부 키가 그대로** 나왔습니다. 데이터를 대 보니 그 화면이 가리키는 이름 키가 번역 문자열 표에 없었습니다. 휴대폰 두 빌드와 PC 판(에디터)에서 같은 모양이 나와 2026-09-28 에 버그로 등록했습니다.

## 못 한 것

- **정답지도 AI가 사진을 한 장씩 보며 만든 것입니다.** 그래서 171건 중 170건은 «정확도»가 아니라 «손판독을 얼마나 재현하나»에 가깝습니다.
- **두 번째 눈은 아직 진짜 오류를 잡은 적이 없습니다.** 잰 범위(휴대폰 31건·PC 17건의 통과)에서 진짜 오류는 0건이었고, 경보 대부분은 「판독기가 이웃 검사의 사진을 빌려 썼으니 같은 화면인지 확인하라」는 뜻이었습니다. 계속 둘지는 전체 검사를 한 번 돌려 본 뒤에 정합니다.
- **사진 한 장으로는 «시간»을 못 봅니다.** 「다시 접속해도 그대로인가」, 「동작이 재생되나」는 앞뒤 두 장이 있어야 합니다. 자동 검사가 한 장만 찍는 항목은 여전히 판정 불가입니다.
- «해당 없음»까지 두 번째 눈에 넣은 것(2026-09-28)은 아직 **전체 검사에서 한 번도 안 돌았습니다.** 부분 실행에서만 확인했습니다.

## 여기부터는 자세한 기록입니다

`shot_judge` — 러너(시트의 검사 목록을 휴대폰에서 돌리는 프로그램)가 끝나면 자동으로 돈다. 입력은 러너가 남긴 판정·재현 스텝·사진, 출력은 보고서(`report.md`)와 검사별 AI 판정이다. 시트에는 따로 올린다 — 러너 판정 위에 AI 판정을 얹는 한 명령이고, 순서가 뒤집히면 판독이 지워진다.

## 판독은 다섯 단계이고, 코드가 게이트다

| 단계 | 하는 일 |
|---|---|
| ① 색인 | 사진마다 축소판 + 제목·좌표·빌드 표시를 잘라 붙인 몽타주(8장씩)를 싼 모델이 «화면·좌표·빌드» 표로 적는다. 런 폴더에 캐시 |
| ② 대상 | 러너가 로그로 못 정한 것(EVIDENCE·FAIL·BLOCKED·SKIP) 중 사진이 있는 것. 로그로 난 PASS 는 안 건드린다 |
| ③ 판독 | 같은 화면이 이어지는 검사를 한 세션에 묶는다. 판정 근거의 정본은 시트의 판정 기준 열, 조작은 러너 steps 에서 자동으로 만든 재현 스텝 |
| ④ 게이트 | G1 누락 · G2 형식 · G3 인용 실존 · G4 인용 사진을 실제로 열었나(세션 기록의 파일 읽기) · G5 조작 기준인데 결과 없는 PASS. 전부 낮추기만 한다 |
| ⑤ 교차 검증·보고 | 판독기 PASS·N/A 를 두 번째 눈에 넘기고, 보고서 머리에 한 줄, 다르게 본 것은 표로 |

노출 기준은 보이면 PASS, 조작 기준은 «누른 결과»가 보여야 PASS 다. «일부만 확인»은 PASS 가 아니라 BLOCKED 에 N/M 을 붙인다. LLM 은 판단만 하고 합격 여부는 게이트가 정한다.

## 2026-09-11 자동화 3원칙에서 나왔다

| 원칙 | 무엇 |
|---|---|
| 1 재현 스텝 + 판정 기준 | 무엇을 눌렀고 무엇을 봐야 하는지가 명확해야 돌린다. 재현 스텝은 steps 에서 자동으로 만들고, 시트가 조작을 요구하는데 steps 가 화면까지 가기뿐이면 실행 전에 「조작 누락」으로 드러낸다 |
| 2 같은 화면이면 다시 안 찍는다 | 248건 중 111건이 같은 화면 반복이었다 — 사진 한 장을 공유(런당 약 9분·사진 45% 절감) |
| 3 이미지로 판정 | 판독기 — 이 편 |

## 수치

- **2026-09-11 첫 판** — 런 7개·171건·사진 193장. 손판독 대비 **170/171(99.4%)·거짓 PASS 0**. 세션 33개, 3개 동시로 벽시계 약 15분.
  오조준 경고(좌표 프로필 백업으로 «런 당시 좌표»를 되살려, 런 뒤 59px 넘게 고친 탭에 경고)가 공통 토스트 검사 한 건의 거짓 PASS 를 막았다. 그래서 **좌표를 고칠 땐 백업을 반드시 남긴다** — 백업이 곧 이 경고의 재료다.
- **2026-09-23 A/B(같은 171건)** — Opus 5·세션 짐 실음 $40.51·벽시계 약 15분 → **Opus 5.5·medium·짐 덜기 $16.00·8.0분**, 거짓 PASS 0.
  옛 정답과 어긋난 17건은 정답지를 만든 **뒤에** 케이스에 붙은 전제 메모(«전제가 안 맞으면 N/A») 때문이었다 — 정답지가 낡았다는 뜻이라, 모델을 탓하기 전에 규칙부터 정했다.
- **2026-09-28** — 규칙 확정 뒤 정답지를 고쳐(N/A 13건·BLOCKED 1건) 다시 대면 **168/171·거짓 PASS 0**. 남은 셋 = 정답이 판독 런 밖 사진(보충 런·손으로 찍은 사진)에 있는 둘 + 아래 메모 사고 하나.
- 판독 모델은 설정에 `opus` 별칭으로 두고, 판독 세션에만 그 별칭을 CLI 의 최신 Opus 로 풀게 했다. 버전이 바뀐 런은 결과마다 찍히는 도장(모델·effort·코드 버전)으로 가른다.

## 규칙 둘은 사람이 정했다 (2026-09-28)

- ① **같은 화면·같은 상태를 찍은 이웃 검사의 사진으로 판정해도 된다** — 자기 사진이 너무 일찍(컷씬·로딩) 찍혔거나 가려졌을 때.
- ② **자동화가 전제(재화·보유·캐릭터 수)를 못 만든 검사는 BLOCKED 가 아니라 N/A.**
- 움직임을 보는 기준은 정지 사진 두 장(누른 직후·1초 뒤)의 자세가 다르면 PASS 다. 영상은 없어도 된다.

## 두 번째 눈은 잰 범위에서 아직 진짜 오류를 못 잡았다

- 흐름: 판독기 PASS·N/A → sonnet 이 판정 기준을 모른 채 **그 검사 자기 사진만** 글로 옮긴다 → Jev(`jev-1.13.0`, TypeSafe API)가 판정 기준·전제(메모의 요구 부분만)와 함께 읽고 PASS·FAIL·BLOCKED·NA 중 하나와 자신감을 낸다.
- 경보: PASS 인데 Jev 가 PASS 가 아님 · N/A 인데 Jev 가 PASS·FAIL 이거나 **판독기가 남의 사진으로 N/A 를 냈을 때**. 뒤의 것은 Jev 답과 무관하게 인용으로 계산한다 — Jev 는 자기 사진만 봐서 그걸 못 가린다.
- 규칙 ① 확정 뒤 잰 범위(휴대폰 31·PC 17 PASS)에서 진짜로 잡은 오류 0건. 경보 15건 중 10건이 «자기 사진 밖 근거»였다 — 경보는 «빌려 쓴 사진이 정말 같은 화면·같은 상태인가»를 확인하라는 표시로 남는다.
- N/A 쪽: 9/23 판독의 N/A 22건 중 남의 사진이 8건, 진짜로 틀린 것이 1건(아래 메모 사고).
- 속도: Jev 는 한 건 약 0.24초다. 병목은 사진을 글로 옮기는 쪽이다(휴대폰 171건에 14.4분).
- ⚠ 사진 기록을 묶어 부를 때 **한 검사의 칸에 옆 검사의 사진 설명이 들어간 적**이 있다. 그걸로 잰 «Jev 가 잡았다» 한 건은 착시였다. 기록 쪽 검사는 «사진을 열었나»만 보지 «칸이 맞나»는 안 본다.

## 메모 사고 — 판독기는 전제 메모를 사실로 읽는다

- 「셋업」은 시트에 전제가 비었을 때 오버레이(러너 steps 를 덧대는 파일)에 적는 전제 메모다. 판독기는 이걸 «전제 조건»으로 받는다.
- 9/11 에 한 화면에 적은 셋업 «가운데 외형은 보유했을 때만 보인다»가 기획서(선택한 항목의 외형을 출력)와 이후 두 빌드의 실측에 반대였다. 서버 데이터 초기화 **뒤** 상태를 보고 적은 문구였는데, 판독 대상 사진은 그 **전날** 것이었다(장착 표시가 있는데 가운데가 빔 = FAIL).
- 판독기는 셋업을 믿고 거짓 N/A 를 냈다. 문구를 지우고 같은 입력(런 7개)으로 다시 판독하니 FAIL. 셋업에는 요구(재료·보유 조건)만 적는다.
- 교차 검증에 「판독기가 남의 사진으로 N/A」 경보를 넣은 것도 이 건 때문이다.

## 누른 적 없는 검사는 steps 로만 풀린다

- 2026-09-10 BLOCKED 126건 중 97건 = «화면은 맞는데 누른 결과가 없음». 판독기로도 재실행으로도 안 풀린다 — 원칙 1 의 「조작 누락」 검사가 여기서 나왔다.
- ID 입력 항목: steps 를 「칸 탭」에서 「칸 탭 → 입력 전 한 장 → 이번 계정 ID 입력」으로 늘렸다. 「완료」는 누르지 않는다 — 로그인 제출은 다음 검사의 몫이고, 다음 검사는 칸을 지우고 다시 친다. 두 장의 칸 글자가 달라 PASS, 두 번째 눈도 같음(2026-09-28).

## 별건에서 나온 버그

- 판독 지침: 기준과 무관한 이상은 «별건»으로 따로 적는다. 빌드마다 늘 뜨는 표시·렌더링 경고 문구는 빼라고 적었다 — 안 그러면 매번 같은 별건이 쌓인다.
- 이름 칸에 `Not Found '<키>'` 가 나온 화면: 데이터 표가 가리키는 이름 키 6개가 번역 문자열 표에 없었다(표에는 다른 번호대의 키 24개). 휴대폰 두 빌드·PC 에디터에서 같은 문구 → 2026-09-28 등록.
- 같은 부류(다른 화면의 이름 키)가 9/10 에도 있었는데, 그쪽은 지금 데이터에서 고쳐져 있었다(키 40개 전부 번역 있음).