Performance Findings

주요 발견과 정정

보고서 78편에서 앞으로 수치를 읽는 법을 바꾼 것만 모았다. 원본은 기록 목록에서 찾는다.

1. 렌더 시간은 같은 코드에서도 12.6 ms 흔들린다

같은 commit · 같은 빌드 · 같은 시나리오로 5번 쟀다(2026-09-23).

회차	첫 렌더	메모리
01	78.6 ms	1,286,208 B
02	70.7 ms	1,286,208 B
03	73.0 ms	1,286,208 B
04	69.1 ms	1,286,208 B
05	65.9 ms	1,286,208 B

• 렌더 시간 — 65.9 ~ 78.6 ms, 폭 12.6 ms(최솟값의 19%). 다른 commit 사이의 10 ms 안팎 차이는 변경 탓이라고 말할 수 없다.
• 메모리 — 다섯 번 모두 바이트까지 같다. 번들이 정해지면 메모리도 정해진다. commit 사이의 메모리 차이는 작아도 실제 차이다.
• 다른 기록에서도 비슷한 폭이 나왔다 — 재전송 수정 기록 3회차 10.7 ms, 첫 화면 표시(lynxFcp)는 30~55 ms.

→ 원본

2. 1번에 따라 바로잡은 해석

보고서	처음 적은 것	바로잡은 것
설정 · 탐침 화면 주석 정리	메모리 +13 KB는 흔들림 안	코드가 바꾼 실제 차이
여정 맵 망라 검사	메모리 +14 KB는 흔들림 안	코드가 바꾼 실제 차이
학습 화면 주석 정리(④-A)	렌더가 커졌다(+5.8 ms)	흔들림 안 — 변경과 무관(④-B가 다시 읽음)
평가 화면 도입	+25 ms, 원인 미해결	회귀보다 흔들림일 가능성이 크다(낭독 순서 기록이 다시 읽음, 단정은 안 함)
에피소드 통화 01	여정 전환 36~49 ms	02에서 26~37 ms — 01은 시뮬레이터가 불안정했다

3. 메모리를 크게 늘린 것은 화면보다 데이터와 이미지였다

• 진입 화면 디자인(09-21) — 국가 목록 245개 · SVG가 메모리 +332 KB. 이 저장소에서 가장 큰 한 번의 증가다.
• 스플래시 로고 애니메이션(09-21) — WebP 디코딩으로 뷰 메모리가 약 3 KB → 2.4 MB.
• 속성 하나(data-testid)는 번들 +19 B, 메모리 0 — 작은 변경은 정말 작다.

4. 재지 못한 구간이 많다

화면에 계측점(timing flag)이 없으면 그 화면에 들어가는 비용을 못 잰다. 그래서 여러 기록이 여정 맵 첫 착지만 쟀다.

• 못 잰 곳 — 알림 push · 밀어서 삭제, 나가기 모달, 에피소드 표지 · 통화 · 최종 테스트 구간
• 09-28부터 학습 화면에는 계측점이 생겼다(첫 기준 18.9~41.4 ms)
• 9-28 이후 15편은 Release 빌드 없이 번들 크기만 쟀다 — 렌더 · 메모리는 비어 있다

5. 측정 방법이 흔들림을 키운 때

• 9-5~9-9 — 같은 호스트 앱에서 번들만 바꿔 번갈아 쟀다. 측정 순서와 캐시의 영향을 떼어 내지 못해, 메신저 · 전화 기록 여섯 편 모두 「방향 판정 불가」로 끝났다.
• 빌드 직후 첫 회차가 크게 느린 경우가 있었다(64.7 ~ 101.6 ms). 첫 회차를 버리고 재는 편이 낫다.
• 이전 캡처 파일을 다시 읽어 버린 회차가 있었다 — 값이 이전 기록과 똑같으면 의심한다.