심사 계정과 디자인 프리뷰를 같은 원본으로 연결 (2026-09-11)
- 기간: 2026-09-11. 오너 요청: 새 심사 계정 목업 데이터와 화면 픽스처를 함께 만들고, 이메일·비밀번호 진입을 숨긴 뒤 “17.11에 반영”.
- 랜딩: 앱 PR #1571 →
release/v0.17.11,fabf4d3d6932169bc9e662c06a0c6df8c8476624. 마이그레이션·Edge 변경 없음. staging/Production 배포·원격 심사 계정 생성은 미실행. - 설계서: 이슈 #1568의 분석·Phase 계획. 별도 디자인 artifact 없음.
- 정본: 화면 fixture 반입, Design 전달 계약, 심사 제출 안내.
- 도구: 앱
scripts/review-account/CLI,ui/shared/fixtures/원본·관측. 계정 manifest·자격증명·로컬 DB 증거는 Git 밖 private 작업 경로에 보관한다. - 게이트: fixture 포함 type-check, UI 계층·표시 규칙, 상대 날짜·상태·보고서 관측 회귀, 정상 Auth 경로, 로컬 시드 재실행, 필수 precheck 및 Merge Check. Full CI는 실행하지 않았다.
- 버그리포트: 없음(새 시드·프리뷰 기능 도입).
- 계약: 모바일 화면 계약 15개에 fixture 경로 추가. 공용 데이터 타입과 화면의
satisfies를 연결하며 콜백은 소비 측이 주입한다.
Phase 현황
| Phase | 내용 | 상태 |
|---|---|---|
| Phase 1 | 공용 원본·18개 화면 fixture·타입·숨김 로그인 | ✅ #1571 |
| Phase 2 | 새 계정 시드·실제 DB 대조·디자인 반입 문서 | ✅ #1571 및 문서 #71 |
1. 배경
디자인 프리뷰의 샘플이 디자인 로컬에만 있어 화면이 받는 데이터가 바뀌어도 이전 형태를 계속 그릴 수 있었다. 오너는 오늘 보드·공지·출석·알림·완료 세션·종목별 기록이 누락된 그룹 프리뷰 사례를 제시했다. 새 심사 계정도 같은 풍부한 데이터로 앱을 탐색할 수 있어야 했다.
2. 문제 제기
프리뷰와 실제 화면의 계약을 함께 검사할 수 없었다
앱에 화면 fixture가 없고 대부분 화면이 느슨한 MobileProps를 사용했다. 오래된 SQL 시드는 현행 RPC와 다르고 기존 계정을 삭제·덮어쓰는 방식이어서 새 계정 생성 요구에 사용할 수 없었다. 기존 전달 규정도 fixture의 레포 반입을 금지하고 있었다.
3. 해결 방안
원칙
- D1(09-11): 기존 계정이 아닌 새 심사 계정을 만들고 같은 원본으로 DB 시드와 화면 props를 만든다.
- D2(09-11): 심사용 이메일·비밀번호 로그인을 추가하되 일반 화면에 표시하지 않는다. 로고 5회는 구현에서 고른 진입 방법이다.
- D3(09-11): 이번 원격 반영은
release/v0.17.11까지다. 원격 계정 생성과 앱 환경 승격을 포함하지 않는다.
접근
화면별 타입·상대 날짜·레포 이미지를 사용한 데이터 fixture를 앱에 저장했다. RPC 응답을 화면에 직접 주거나 디자인 로컬 샘플을 별도 유지하는 방식은 계약 누락을 검출하지 못하므로 채택하지 않았다. 제품 런타임의 판정·집계는 그대로 유지하며 시연 데이터는 빌드에서 제외한다.
4. 적용한 내용
Phase 1 — 화면 fixture와 숨김 인증
홈·종목 상세·기록·하루 요약·운동·리포트·피드·그룹 3화면·알림 셸·프로필·커스텀 종목·검색·즐겨찾기·수동 PR·훈련 스타일·온보딩을 18개 파일로 제공했다. 필요한 상태는 같은 화면 파일의 named export로 구분한다. 계약은 공용 contracts/ui/와 모바일 계약/타입 재수출에서 검사한다.
로그인 로고 5회 또는 키보드 Enter/Space 5회로 심사 창을 연다. 임시 비영속 Auth client로 이메일·비밀번호를 인증한 뒤 서버가 관리하는 심사 계정 표식을 확인하고 정상 앱 세션에 연결한다. 비밀번호를 URL·fixture·로그·Git에 넣지 않는다.
Phase 2 — 실제 시드와 재조회
현행 API로 새 합성 계정·운동·그룹·피드를 생성하고 입력별 manifest로 재실행을 조정한다. 원본 fingerprint, 보드 메모·좋아요·세트값, 피드 반응과 실제 통계를 재조회했다. 기록·PR 날짜는 생성 기준일 오프셋을 사용한다. OAuth 연결 표시·동기화 실패·진행 중 운동은 프리뷰 변형이며 실제 계정의 기본 상태와 구분한다.
작업 중 드러난 것
첫 로컬 통합 검사에서 UI→service 타입 참조, shared→mobile 타입 역참조, kg 직접 포맷을 검출했다. 공용 계약과 검증된 표시용 원본으로 정리하고 기존 kg 표시 함수를 사용해 2/2 묶음·3/3 케이스를 수리했다.
최초 Merge Check는 확인 이후 release에 #1570이 먼저 들어오면서 종목 상세 함수 서명 한 곳의 충돌로 실패했다. 새 통계 상태·재조회 callback과 fixture 타입을 모두 보존하고, fixture에도 statsStatus: "ready"를 명시했다. 관련 로컬46개와 새 후보 precheck를 통과한 뒤 정상 Merge Check를 다시 요청했다. 타인 브랜치·큐는 조작하지 않았다.
보고서의 복합종목 fan-out 때문에 실제 홈과 리포트 세트 수가 다르다는 점을 확인했다. 실제 RPC에 맞춰 홈681/139세트와 리포트682/140세트를 유지했다. 날짜 변경으로 추가되는 같은 출석 템플릿은 동일 인물·동일 세트 관측만 재사용하며, 원본 변경은 오류로 검출한다.
5. 적용 결과
| 항목 | 결과 |
|---|---|
| 앱 화면 fixture | 없음 → 18개, 타입 검사 포함·제품 번들 제외 |
| 계약 연결 | 별도 로컬 샘플 → 화면 계약15개에 앱 경로와 같은 PR 갱신 규칙 |
| 로컬 심사 계정 기록 | 없음 → 최근3개월 완료59회·PR12건 |
| 소셜·그룹 | 팔로우5·피드 원본12·그룹3·미확인 초대3·오늘 완료2명/3세션 |
| 시드 재적용 | 최초486작업 → 재적용0작업·원본 fingerprint 보존 |
| 숨김 로그인 | 모바일·데스크톱·대체 화면4개 브라우저 검사, 실제 로컬 로그인→그룹 표시 통과 |
| 최종 로컬 precheck | 전체3,475·성공3,440·실패0·조건부 DB skip35, static/unused/build/artifact 성공(4분12초) |
| release 반영 | Merge Check 성공, #1571의 merge commit 포함 확인 |
| 앱 배포·원격 심사 계정 | staging/Production 및 원격 계정 생성 미실행 |
초기 및 재검증 내역은 로컬 수리 보고, 초기 precheck, 통합 충돌 수리에 기록했다. 조건부 DB skip을 성공으로 합산하지 않았으며 부분 검사·Merge Check를 Full 성공으로 보고하지 않는다.
6. 이번 개선으로 향상된 것
디자인은 화면 파일과 같은 시점의 fixture·타입·정적 자산을 verbatim 반입할 수 있다. 새 props가 생길 때 fixture를 함께 고치고 검사하는 경로가 생겼다. 심사 계정 데이터는 기존 사용자 원본을 건드리지 않고 재실행·대조할 수 있으며, 심사관은 일반 사용자의 운동·기록·소셜 흐름으로 들어간다.
남은 것
이번 요청의 반영 범위는 release/v0.17.11이다. 앱의 staging/Production 배포와 실제 심사 환경 계정 생성은 실행하지 않았다. Claude Design의 다음 재싱크·프리뷰 연결은 아직 확인하지 않았다. 현재 제품에 없는 포스트 첨부 사진과 친구 비공개 필드는 추가하지 않았고 지원되는 아바타·접근 오류 변형으로 구분했다.