## 계기 — 그리고 정정
2026-09-28 A34 에서 0cm 정렬 뒤 `align_0cm_imu.csv` 가 없다고 판단해 원인을 쫓았다.
BLE 로그·parseRim 로그로 IMU 가 20/20 도착한 것까지 확인한 뒤 "사이드카 콜백이
덮였다"는 가설로 진단 로그를 넣어 재설치했다. 그런데 파일은 **처음부터 있었다** —
0cm·1cm 모두 09:49/09:51 에 20 cycle × 15 sample 로 써졌다. `adb shell` 이 보는
`/sdcard`(FUSE · MediaProvider 뷰)가 앱이 방금 쓴 파일을 한동안 안 보여 준 것이고,
`find -type f` 는 한 파일만, `find -mmin` 은 아무것도 돌려주지 않았다. 진단은
불필요했다. 코드에 결함은 없었다.
## 그래도 남기는 것
- `restore()` 방어: 지금 걸린 콜백이 **자기 것일 때만** 되돌린다. LaunchedEffect 가
재시작하면 옛 인스턴스의 restore 가 새 인스턴스의 install 뒤에 실행될 수 있고
(취소된 코루틴의 finally 는 나중에 돈다 · 새 코루틴은 Main.immediate 로 즉시 시작),
그러면 새 훅이 옛 previous 로 덮여 그 자리 20회가 전부 IMU 없이 저장된다.
이번엔 그 순서가 아니었지만 순서 자체는 가능하다.
- 로그(태그 ImuSidecar · AnchorAlign): install 시 이전 콜백 종류 · 콜백 도착 ·
await 결과 · 회차별 imu 수. "IMU 가 왔나" 는 파형 해석에서 제일 먼저 묻는 질문인데
답이 BLE 로그를 뒤져야 나왔다. 이제 logcat 한 줄로 답이 나온다.
## 교훈 (도구)
앱이 공용 Downloads 에 방금 쓴 파일은 `adb shell ls/find` 에 늦게 나타난다. 파일
유무를 근거로 결론 내리기 전에 `run-as`(앱 내부 경로) 로 보거나, 몇 분 뒤 다시 보거나,
앱이 남긴 로그·업로드 표식으로 교차 확인할 것.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
dw.jang
00fef4a99d