조작과 판정

붙잡을 게 없는 화면이니 조작 경로가 이렇게 된다.

최대 개선은 판정을 옮긴 것이었다

처음엔 “로그로는 게임 내부 상태를 알 수 없다”고 단정했다. 표준 로그 채널이 막혀 있었기 때문이다.

틀렸다. 막혀 있던 건 그 채널 하나였고, 엔진이 기기에 직접 쓰는 파일 로그에는 상태 머신 전이와 모든 RPC 송수신이 그대로 남아 있었다.

여기서 증거 우선순위가 정해졌다.

수신 RPC > 상태 전이 > 화면

화면이 왜 마지막인가

픽셀은 두 가지를 구분하지 못한다.

• 로딩 스피너와 멈춘 화면 — 둘 다 “돌고 있는 그림”이다
• 같은 화면이 뜻하는 두 가지 상태 — 예를 들어 요청이 처리 중인 화면과 이미 실패해서 되돌아온 화면이 같아 보일 수 있다

로그는 그걸 구분한다. 요청을 보낸 기록이 있고 응답을 받은 기록이 있으면, 화면이 무엇이든 어느 상태인지가 결정된다.

그리고 판정을 픽셀에서 로그로 옮기고 나서야 무인 장시간 운전이 가능해졌다. 비전 판정은 애매한 화면에서 사람을 부르는데, 사람이 없으면 부를 곳이 없다.

비전은 조작에만 남겼다

판정에서 뺐다고 비전을 버린 건 아니다. 조작에는 여전히 비전밖에 없다.

버튼이 어디 있는지 알 방법이 그것뿐이라서다. 다만 조작과 판정은 요구가 다르다.

• 조작은 틀려도 복구된다. 엉뚱한 데를 누르면 화면이 안 바뀌고, 안 바뀐 걸 알면 다시 찾는다.
• 판정은 틀리면 그대로 결과가 된다. 잘못 PASS를 준 케이스는 아무도 다시 안 본다.

그래서 틀려도 되는 자리에 비전을 두고, 틀리면 안 되는 자리에 로그를 뒀다. 같은 도구를 두 목적에 쓰면서 신뢰도만 다르게 요구하는 건 성립하지 않는다.

아직 무는 곳

• 무증상 정지는 에러 카운터로 안 잡힌다. 아무것도 실패하지 않은 채로 멈춘다. 그래서 화면 변화량을 별도 축으로 두고, 변화가 없으면 단계적으로 복구하다 끊는다
• 캡처를 탭보다 먼저 — 새 프로세스는 화면 배율 상태가 비어 있다
• 재기동하면 옛 세션 로그가 로테이션 전에 다시 노출된다. 로그를 지우고 오프셋 0에서 읽어야 한다
• 자동 접속 체인이 기억된 계정으로 내달려서, 첫 화면 케이스는 앱 데이터를 지운 신규 부팅으로만 실측된다