메인 종목·등급이 함께 나타나도록 준비 후 공개 — #1554 후속 (2026-09-11)
- 기간: 2026-09-11, 기존 #1554 세션 후속. 오너: “나는 차라리 로딩이 걸릴거면 스켈레톤을 띄워놓고 전부 로딩이 끝난다음 보여줬음 좋겠어”.
- 랜딩: 앱 PR #1558, release/v0.17.10 merge
097ae8a9eb9f79b4417727afc6a0130fd5189665. Production 배포·DB migration·Edge 변경 없음. - 설계서: 없음(표시 정책 수리). 이전 점검의 Phase 1·2에 Phase 3를 추가했다.
- 정본: 메인 준비 계약, 앱
appController.tsx·controllers/prController.ts·HomeScreen.tsx. - 도구·게이트: 기존
homeBootLoadingOrder.test.mjs의 부분 공개 단언을 새 사용자 정책으로 갱신했다.initialLoadPath.test.mjs의 조건 변경도 기존 pending-changes 신고에 추가하고 훅 선실행·빈 계정 구분 검증을 보존했다. 수정 전 2건 실패 → 수정 후 통과.homeCompleteReveal.browser.mjs는 실제 PR controller·mapper·Home UI와 제어된 응답으로 공개 순서를 검사한다. 브라우저 12/12 통과(준비 순서 8건·즉시 로딩 표시 4건), npm run check 3,400 통과·35 환경 조건 제외·실패 0. 필수 precheck static·단위 2개 묶음 통과(3,400 통과·35 조건부 제외), 1분 52초. Merge Check 실행 34502111685 성공. - 버그리포트: BUG-115.
Phase 현황
| Phase | 내용 | 상태 |
|---|---|---|
| Phase 1·2 | 공용 표시 지연·편집 복귀·리포트 교체 수리와 7탭/19화면 대조 | 앞선 기록, PR #1556으로 release 반영 |
| Phase 3 | 메인 요약·기록·등급·첫 목록 준비 후 전체 공개 | 앱 PR #1558, 097ae8a9eb9f79b4417727afc6a0130fd5189665 |
1. 배경
오너는 메인 로딩과 하단 프로필의 종목별 등급 뱃지가 늦게 나타나는 이유를 물었다. 일부 내용을 먼저 보이게 하는 것보다 스켈레톤 뒤에 완성된 본문을 한 번에 보여주기를 원했다. 이 요청의 대상은 메인 데이터 공개 시점이며 리포트 갱신 정책을 다시 바꾸는 작업은 아니다.
2. 문제 제기
홈 공개는 HOME_DASHBOARD만 기다렸다. 그 요약의 benchmark_prs와 즐겨찾기 참조로 종목명·기록을 먼저 만들 수 있었지만, 등급 기준표 strength_standards는 별도 PR_OVERVIEW 응답에 있었다. 해당 응답 전에는 rank가 null이고 뱃지 JSX가 없었다가 응답 후 계산과 함께 추가됐다.
PR 준비 신호가 true여도 이미 만든 종목 행은 우선 표시했다. 최초 즐겨찾기 조회도 별도라 응답 순서에 따라 하단 목록이 더 늦게 나타날 수 있었다. 앞선 PR #1556은 공용 표시의 300ms 대기+200ms fade를 제거했지만 이 부분별 공개 정책은 유지했었다. 서버 자체가 느린지, 운영 기기의 실제 대기 시간이 얼마인지는 이번 로컬 분석으로 확정하지 않았다.
3. 해결 방안
| 방안 | 판단 |
|---|---|
| 메인에 필요한 데이터 준비 신호를 합쳐 전체 스켈레톤 유지 | 채택 — 이름·기록·등급이 서로 다른 시점에 공개되지 않도록 한다 |
| 뱃지에 별도 지연이나 fade 추가 | 기각 — 응답 순서가 바뀌면 여전히 부분 공개된다 |
| 앱의 다른 탭 프리로드까지 모두 대기 | 범위 밖 — 현재 메인 데이터 준비와 관계없다 |
4. 적용한 내용
기존 즐겨찾기 저장소의 계정과 hydrated 상태에서 최초 조회 중 여부를 파생했다. 이 값과 PR 개요 준비 신호를 합치고, HomeScreen은 홈 요약 또는 이 데이터가 준비 중이면 전체 HomeBootstrapSkeleton을 반환한다. 기존의 히어로·티커·보드별 스켈레톤 분기는 더 이상 사용하지 않아 제거했다.
준비된 PR 응답과 최초 조회가 완료된 즐겨찾기를 가진 일반 탭 왕복은 다시 로딩하지 않는다. 최초 즐겨찾기 조회가 실패하면 기존 캐시 폴백이 hydration을 마치고 스켈레톤을 해제한다. 신규 회원의 정상 빈 결과도 완료로 처리한다. 요청 순서·등급 계산·서버 쓰기를 바꾸지 않았다.
5. 적용 결과
| 항목 | 전 → 후 |
|---|---|
| 일부 기록이 있고 PR/목록 조회가 끝나지 않은 경우 | 실제 종목 행 우선 표시 → 실제 본문 0, 전체 스켈레톤 유지 |
| 종목별 등급 | 이름/기록 뒤 늦게 붙음 → 기준표 준비 후 행과 함께 표시 |
| 최초 목록 응답 순서 | 별도 신호 없이 화면 갱신 → owner별 hydration 완료까지 공개 대기 |
| 준비 완료 후 일반 탭 왕복 | 기존 데이터 사용 → 유지, 추가 전체 스켈레톤 없음 |
| 검증 | 브라우저 12/12 통과(준비 순서 8건·즉시 로딩 표시 4건), npm run check 3,400 통과·35 환경 조건 제외·실패 0. precheck static·단위 2개 묶음 통과(3,400 통과·35 조건부 제외), 1분 52초. 실행 34502111685 성공 |
| 운영 확인 | 인증 후 실기기 전수 실측·Production 배포는 미실행 |
6. 이번 개선으로 향상된 것
메인 화면의 준비 완료 기준을 명확하게 했다. 스켈레톤은 즉시 보이고, 본문은 필요한 기록·등급·목록이 준비된 뒤 나타난다. 부분 응답이 이 기준을 우회하지 않는 브라우저 회귀와 계약을 남겼다.
남은 것
운영·실기기의 실제 응답 시간은 미실측이다. 이번 변경은 전체 준비까지 걸리는 네트워크 시간을 줄였다는 주장이 아니라, 그 시간 동안의 표시 방식을 정한 것이다. 앱 Production 승격은 수행하지 않았다.