# 플랜: 프리뷰(콜드스타트 정렬) 재설계 — 필요성 재검토 + 대안 비교

> 작성일: 2026-07-06
> 선행 근거: 오늘 실로봇 세션 2개(171922/172030) 분석, PG2 시절 세션 20+개 cx/액션 재확인,
> `stage2_v2_inference_server.py` preview 코드 리딩(L760-993)

## 1. 왜 다시 보는가 (현재 상태 요약)

- preview는 `inference_count==0`일 때만, 최대 5회, **오직 ROT_L/ROT_R만** 낼 수 있음
- 실패 시 고정 방향(`VLA_PREVIEW_ROT_DIR`, 기본 R)으로만 스윕 — 반대쪽에 있으면 최대 5번 다 헛돎
- `hint_cx`는 grounder가 "필터된 후보"(area 작음/화면 상단)를 준 경우에만 작동 — 완전 미탐지(오늘
  171922처럼 has=0 전체)면 무용지물
- 오늘 유일한 실측(n=1): preview=True 세션에서 탐지 0/10, 스핀만 하다 종료 → **실패**
- 반면 PG2 시절 일부 세션은 grounding 신호 없이도(cx 계속 0.5) 본 모델이 FWD+L→RIGHT→FORWARD로
  스스로 방향을 바꾼 사례 확인 — **본 모델이 raw image만으로도 방향 판단 능력이 있을 가능성**

→ preview가 있어야 첫 프레임이 정렬되는지, 아니면 없어도 본 모델이 알아서 하는지부터 불확실.

## 2. 옵션 비교

### 옵션 A — 프리뷰 제거 (본 모델에 위임)
- 방법: `VLA_PREVIEW_ENABLED` 끄고 그대로 운영, 콜드스타트도 처음부터 본 모델(exp71)이 처리
- 장점: 로직 단순화, 실패 리스크(고정방향 헛스윕) 원천 제거, 레이턴시 절감(5회 재시도 왕복 없음)
- 단점: 본 모델이 raw image 방향판단을 "일관되게" 하는지 검증 안 됨 (PG2 시절 사례는 우연/일부일 수 있음)
- 검증 비용: 낮음 — 그냥 끄고 다음 세션들 비교(이미 172030이 사실상 이 조건의 표본 1개)

### 옵션 B — 양방향 탐색 + 방향 누적치 관리
- 방법: 고정 한쪽 스윕 대신, 실패할 때마다 반대 방향 시도하되 "순 회전량"을 누적 추적해서 반대편도
  커버(예전 RLRLR 상쇄 버그를 "탐색 폭 넓히기"로 재설계 — 완전 교대가 아니라 R→R→L→L→R 식
  단계적 확장 스윕)
- 장점: 고정 방향이 틀렸을 때의 실패를 줄임
- 단점: 로직 복잡도 증가, 회전 스텝 크기/타이밍이 실제 로봇 액추에이션과 안 맞으면 여전히 무용
- 검증 비용: 중간 — 로봇에서 실측 필요, 리플레이로는 검증 불가(물리 회전이 핵심이라)

### 옵션 C — 물리 회전 없는 광각/재시도 스캔
- 방법: 로봇을 돌리지 않고, 같은 프레임을 더 높은 해상도/여러 크롭으로 여러 번 쿼리하거나
  confidence threshold를 프리뷰 전용으로 낮춰서(예: 0.10) 탐지 기회를 늘림
- 장점: 액추에이션 타이밍 이슈(서버 판단과 실제 회전 완료 시점 불일치 의심) 회피, 레이턴시 최저
- 단점: 애초에 화각 밖에 있는 타겟은 여전히 못 잡음 — "화면 안에 있는데 실패"만 개선
- 검증 비용: 낮음 — 서버에서만 재현 가능(기존 라이브 프레임 재사용해서 threshold만 바꿔 테스트 가능)

### 옵션 D — 프리뷰 유지 + 진단 로깅 강화 (당장 구조 변경 없이 먼저 원인 확인)
- 방법: 구조는 그대로 두고, preview 각 시도(attempt)별로 실제 회전 전/후 cx, bbox 여부를 h5에
  기록하는 로깅만 추가 — "5번 다 실패"가 진짜 타겟 부재 때문인지 회전량 부족 때문인지부터 확인
- 장점: 가장 저비용, 다음 로봇 테스트(계획된 obj_right 5개)에서 자연히 데이터 축적됨
- 단점: 당장 문제를 고치지는 않음, 근본 개선은 한 텀 늦어짐

## 3. 추천

**옵션 D(진단 로깅) → A/C 중 택1로 이어가는 순서**를 추천합니다.

이유:
- 지금 preview 구조를 바꾸는 결정(A/B/C 중 하나)을 내리기엔 **표본이 n=1**이라 근거가 너무 약함
- 마침 다음 로봇 테스트가 "obj_right preview=False 5개"로 이미 계획되어 있어서, **옵션 A(제거)의
  실측 데이터가 그 자체로 쌓임** — 별도 작업 없이 "프리뷰 없이 본 모델이 얼마나 버티는지"를 알 수 있음
- 옵션 B(양방향 탐색)는 지금 근거로는 고칠 대상이 진짜 "방향"인지 "회전량/타이밍"인지 불명확해서
  섣부른 구조 변경은 위험 — 옵션 D로 attempt별 cx 로그부터 남기고 판단하는 게 안전
- 옵션 C(threshold 낮추기)는 서버에서만도 검증 가능하니 비용이 가장 낮음 — 원하면 옵션 D와 병행 가능

## 4. 결정이 필요한 것 (사용자 확인)

- [ ] 이번엔 A(제거) / B(양방향) / C(threshold) / D(로깅만) 중 뭘 먼저 할지
- [ ] "필요 없다"고 판단되면(A 데이터가 충분히 나쁘지 않으면) 아예 프리뷰 코드 제거할지, 아니면
      옵션으로만 꺼둘지(향후 재사용 가능성 남겨둠)

## DoD

- [ ] 위 옵션 중 승인된 것 1개(또는 조합) 확정
- [ ] (A 선택 시) 다음 로봇 세션 결과로 "프리뷰 없이 본 모델 direction 성공률" 정리
- [ ] (D 선택 시) attempt별 cx 로깅 코드 추가 + push
- [ ] (C 선택 시) threshold sweep 스크립트로 서버 재현 테스트 후 결과 문서화