촘촘히 봐도 못 센다 — resume writer 모자이크 파일럿

TL;DR

비용은 해결됐다. 게이트웨이 경유 flash 는 이미지당 1,064 토큰 고정이라 해상도를 줄여도 0원 절감. 대신 16프레임을 2×2 합성 4장으로 보내면 현재 4장과 토큰·비용이 똑같다.
🔴 성능은 오르지 않았다 — 사전등록 반증. 같은 32행에서 rf-v3 .156 → .062 · vis-pure .312 → .312 · tagmem .219 → .188.
기제: tagmem DB 의 놓기 포착은 68 → 80% 로 올랐지만, writer 가 2초 간격 인접 칸에 보이는 같은 동작을 여러 번 기록해 과다 계수가 10 → 16 으로 늘었다. 결국 횟수 일치는 15/32 → 11/32.
resume 의 반복 횟수는 샘플링으로 안 풀린다. 모자이크 미채택, resume 3전략 전량($46) 보류, final_results 변경 없음.

= 현재

모자이크 비용

.188

tagmem (4장 .219)

.062

rf-v3 (4장 .156)

.312

vis-pure (동률)

10→16

과다 계수 과제

$8.67

실비

1배경 — resume 잔여 손실의 원인 후보는 writer 샘플링

쓰기 v7 + 읽기 v8 로 tagmem resume 은 .219(frames 동률, vis-pure .312 아래)까지 왔고, 남은 손실은 DB 의 반복 사건 수 오류였다. writer 는 30 s 청크당 균등 4프레임을 보는데, 누름·놓기 순간 ±1 s 안에 writer 프레임이 있는 비율은 16~25% 뿐이다. 프레임을 16장으로 늘리면 100% 가 되지만 세 writer 를 같이 바꿔야 공정해 비용이 문제였다. 사용자: "샘플링 수를 늘리는 대신 해상도를 줄이면 싸지나" → "얼마인지 확인" → "파일럿으로 성능이 달라지나".

2과금 프로브 — 해상도는 무관, 장 수만 과금

같은 청크, 답 "OK"	flash 토큰	flash $	luna 토큰	luna $
원본 1장 640×480	1,072	.000887	373	.0000794
절반 1장 320×240	1,072	.000887	109	.0000266
원본 4장 (현재 writer)	4,264	.003281	1,453	.000295
합성 4장 = 16프레임	4,264	.003281	1,453	.000295
원본 16장	17,032	.012860	5,773	.001159

resume 3전략 재ingest + 재읽기 전량(flash+luna): 합성 ≈$46 · 원본 16장 ≈$95(앞서 말한 $150 은 이미지 단가 과대 추정) · 절반 해상도 16장 ≈$91.

train_2978__2000 t=240–270 s 청크를 16프레임으로 뽑아 2×2 합성 4장으로 만든 실물(4장을 2×2로 다시 배열해 표시). 칸당 320×240 에서도 테이블 위 달걀 개수·팔 동작이 보이고, 기존 4장(t=240/250/260/270)이 건너뛰는 t=262–270 s 집기 연속 동작이 담긴다.

3파일럿 — 같은 32행, 청크당 4장 vs 16프레임

구현: SBENCH_WRITER_MOSAIC=1(기본 끔, 끄면 바이트 동일, 청커 관련 테스트 65 passed). rf-v3·vis-pure 현재 클립·tagmem writer 공통, F 번호는 청크 기준이라 저장·보관 프레임은 개별 원본으로 다시 렌더. 기준: rf-v3·vis-pure = final, tagmem = 쓰기 v7 + 읽기 v8 4장 파일럿. 사전등록은 제출 전.

전략	4장 resume_ok / remaining / slot / 기권	모자이크	짝비교	사전등록
rf-v3	.156 / .219 / .359 / .125	.062 / .094 / .250 / .094	1/4	≥.19 ❌ (반증선 <.15)
vis-pure	.312 / .312 / .391 / .094	.312 / .344 / .469 / .031 (press 1/4 · visit 1/5)	3/3	≥.31 ✅ (동률)
tagmem w7+r8	.219 / .312 / .406 / .000	.188 / .219 / .328 / .000	3/4	≥.28 ❌ (반증선 <.22)
frames-uniform · blind · textlog	.219 · .125 · .875 (writer 무관)

왜 촘촘히 봤는데 더 못 셌나 — tagmem DB

tagmem DB (쓰기 v7)	4장	모자이크
사건 포착 put · move · press	68% · 72% · 50%	80% · 67% · 60%
entries / 편	60.3	74.8
DB 항목 수 == GT 수행 횟수	15/32	11/32
DB − GT : 과다 · 부족	10 · 7	16 · 5
같은 30 s 청크 안 중복 사건 put · press	0 · 0	4 · 3

누락이 중복으로 바뀌었다. 16프레임에서는 한 번의 놓기·누름이 2초 간격 여러 칸에 걸쳐 보이고, writer 는 칸마다 새 사건으로 적는다. 포착은 늘었지만 부족 계수 7 → 5 를 얻는 대신 과다 계수 10 → 16 을 잃었다. rf-v3 는 요약을 통째로 다시 쓰는 방식이라 늘어난 장면에서 횟수가 더 흐려졌고(.156 → .062), vis-pure 는 세지 않고 프레임을 고르는 방식이라 영향이 없었다.

차이는 32행 중 1~4행이라 writer 확률성(같은 입력 두 번 ingest 의 사실 일치 Jaccard .44) 범위다. 다만 세 전략 어디에도 이득 신호가 없어 전량에서 뒤집힐 근거가 없다.

4Takeaway & Next

resume 반복 횟수는 writer 샘플링을 늘려도 안 풀린다. 모자이크 미채택, resume 3전략 전량 보류, final_results 변경 없음(resume tagmem 은 v5).
resume 보고 문안: tagmem 은 frames 수준·vis-pure 아래. 남은 과제 횟수는 writer 가 균등 샘플에서 반복 동작을 세는 한계이고, press 는 매체 한계(오라클만 정답).
이미지 예산은 앞으로 "장 수" 기준으로 논의(Gemini 3 는 해상도 무관 과금).
남은 후보: 같은 청크·같은 (행동, 물체, 도착지)·도착지 개수 변화 없음이면 1건으로 묶는 결정론 병합. 프롬프트 규칙은 writer 를 못 움직이는 게 반복 확인됨. 단 사용자 원칙 "인접 청크 중복 제거 금지"와 충돌 여부는 판단 필요.