리서치: Style DNA write 경로 실태 — 온보딩 pick·onboarding_pick 이벤트·prod populated

[thxforall]

Part of #789

Question

Style DNA가 "지금 온보딩하면 실제로 생기는가"를 검증:

1. 온보딩(taste onboarding/StyleDnaPicker)의 9무드/포스트 pick이 어디에 write되나(users.style_dna? StyleDnaEvents?).
2. passive mood recompute가 의존하는 onboarding_pick StyleDnaEvent 방출이 실제로 되는지(미추적).
3. prod users.style_dna가 실제 populated인지 + build 의존(≥5 pick + posts.cody_analysis 커버리지, GEMINI_API_KEY).

산출

• Style DNA 기본 동작 실태 → D-STYLEDNA·D-BACKEND 근거. (심층검증에서 read/display는 배선 확인됨, write/데이터 실태만 미검증.)

[thxforall]

🔬 조사 결과 (PARTIAL-OK · high · 17앵커 MATCH)

결론: 지금 온보딩을 완주해도 Style DNA는 부분/조건부로만 생긴다. persona 절반은 성공 시 항상 저장(step5 ? 전파)되나 mood 절반(primary_mood)은 best-effort(에러 삼킴)라 조건이 안 맞으면 조용히 누락된다. 라이브 온보딩 = spec의 9무드 풀-픽이 아니라 임베딩 StyleDnaPicker(/style-dna)(9무드 풀은 홈 StyleMoods 표시용으로만 소비, computeLocalDna 익명경로는 prod dead).

• write는 양쪽: onboarding_pick → style_dna_events, 계산 DNA → users.style_dna jsonb.
• onboarding_pick의 유일 prod writer = build step4 → post_mood_vectors가 없으면 0행. passive recompute(일배치 06:00 + 10분 드레인)는 onboarding_pick 없으면 None이라 전적 의존.
• build hard 의존: cody_analysis 보유 룩 ≥5(부족 시 422) + GEMINI_API_KEY(없으면 build 전량 실패).
• get_user_style_dna는 primary_mood 없으면 404 → mood 누락 유저는 마이페이지 카드 404 + 온보딩 재유도.

근거: best-effort 삼킴 handlers.rs:202 · 유일 writer service.rs:997 · recompute 의존 onboarding/scoring.rs:203 · 404 users/service.rs:1039 · cody≥5 게이트 handlers.rs:141 · 라이브 온보딩 픽커 StyleDnaAnalyzing.tsx:59+styleDnaBuilderStore.ts:7(MIN_PICKS=5).

결정 영향 (#793 · #799): "온보딩하면 Style DNA가 생긴다" 전제 금지. #799: mood 단계 best-effort→hard-fail 승격 여부 + cody/vector 백필을 온보딩 성공 선행조건으로 보장할지가 결정 포인트.

남은 갭 (라이브 규모 실측, NOT-IN-CODE): prod DB에서 순서대로 —

• persona vs mood 격차: psql "$OPERATION_DATABASE_URL" -c "SELECT count(*) FILTER (WHERE style_dna->>'persona' IS NOT NULL) has_persona, count(*) FILTER (WHERE style_dna->>'primary_mood' IS NOT NULL) has_mood, count(*) FILTER (WHERE style_dna IS NOT NULL) has_any FROM public.users;"
• onboarding_pick 실적 / 활성포스트 cody 커버리지 / post_mood_vectors 커버리지 (전문 스크래치패드) · ai-server GEMINI_API_KEY 세팅 여부.

_{울트라코드 리서치 fan-out (지도 #789) · 적대적 검증 통과.}

[thxforall]

🔁 재검증 (2026-07-22, 현재 dev 트리) — CONFIRMED + 앵커 1개 OVERTURNED

17개 앵커 중 16개 재확인(전부 줄 이동, 현재 file:line 자산에 표로 기록). "온보딩하면 Style DNA가 생긴다" 전제는 계속 금지 — 정확한 표현: persona=조건부, mood=best-effort.

1. cody 의존이 하나가 아니라 둘. persona = posts.cody_analysis 동기 읽기(≥5 아니면 422 — users/handlers.rs:169-175). mood = 사전계산된 post_mood_vectors 행(users/service.rs:922-932). 픽한 포스트가 persona는 만족시키면서 mood 벡터가 없을 수 있음 → persona는 저장(? 전파, handlers.rs:246), mood는 조용히 누락(handlers.rs:241-243, tracing::info!만). 요청은 200을 반환.

2. onboarding_pick writer는 여전히 정확히 한 곳. Rust/Python/TS/SQL 전수 문자열 검색: users/service.rs:938-956뿐, 도달 경로는 handlers.rs:241 단독. 별도 commit 엔드포인트 없음. (behaviorStore.ts:32의 onboarding_picks_done은 무관한 분석 이벤트.)

3. persona-only 유저를 치유할 배치가 없다 — #799의 load-bearing 입력. compute_style_dna는 onboarding_pick 없으면 None(scoring.rs:279-283), 일배치 06:00은 이미 pick 있는 유저만 select(style_dna_recompute.rs:15-22), like/save 백필은 onboarding_pick을 안 씀(style_dna_backfill.rs:12-25). ⇒ post_mood_vectors 백필은 필요조건이지 충분조건이 아님. 항상 기록되는 style_dna.source_post_ids를 씨앗으로 한 소급 onboarding_pick 방출 잡이 별도로 필요.

4. OVERTURNED — primary_mood 404는 latent. 엔드포인트에선 확인(users/service.rs:976-982)되나 웹에서 호출하는 곳이 없음. 마이페이지 카드는 /users/me 페이로드의 raw jsonb를 쓰고 persona로 게이트(ProfileClient.tsx:198 → ProfileStyleDnaPanel.tsx:22-25). persona-only의 실제 활성 증상은 TasteOnboardingPrompt.tsx:26-28(영구 재유도)와 StyleMoods.tsx:34의 parseStyleDnaV1(홈 무드 개인화 dead).

5. GEMINI_API_KEY는 코드/설정만으로 확인 — style_dna_synthesizer.py:175-178이 빈 값이면 raise, 선언 _environment.py:66(기본 ""), 템플릿 .env.backend.example:148. .env 미열람.

6. #793 참고: REDESIGN_FLAGS.styleDna: false는 ProfileRightRail.tsx:72만 게이트하는데 마이페이지 탭·홈 개인화는 style_dna를 직접 읽음 → flag↔실제 불일치.

리스크 하향: style_mood_mappings 시드는 마이그에 존재(20260610120000_taste_onboarding_tables.sql:119) → "미시드" 우려는 낮음.

자산: docs/research/2026-07-22-803-style-dna-write-path.md (PR #1053)
남은 갭: prod psql 4종(persona vs mood 격차 · onboarding_pick 실적 · post_mood_vectors 커버리지 · 배치 로그) — 명령만 기재, 미실행.

[thxforall]

⚠️ 위 재검증 코멘트 정정 — writer는 셋, 소급 잡은 "유일 선택지"가 아니다

위 코멘트 항목 3에서 소급 onboarding_pick 방출 잡을 필요로 단언했는데, 이후 리뷰에서 users.style_dna writer가 둘이 아니라 셋임이 확인됐다:

writer	경로
merge_style_dna (persona, build step5)	users/service.rs:111
recompute_user_dna (mood merge-patch)	onboarding/service.rs:177
update_style_dna — 전체 교체, caller가 준 jsonb	users/service.rs:80 — PATCH /api/v1/users/me/style-dna, UpdateStyleDnaDto에 #[validate] 없음

세 번째는 JWT user.id로 스코프된 자기 쓰기라 교차 사용자 문제는 아니지만, onboarding_pick 없이 primary_mood를 세울 수 있다. 웹에 호출부가 없어 현재는 latent이지만, 복구 설계 관점에서는 소급 onboarding_pick 방출 잡이 유일한 선택지가 아니라는 뜻이다 — mood 키만 담은 patch를 직접 쓰는 잡이 더 싼 대안일 수 있다. #799 티어링을 이 위에서 사이징하고 있으므로 해법 공간을 하나로 못 박지 말 것.

그대로 유효: "기존 배치로는 치유 불가"(배치 4경로 전수 확인) · "post_mood_vectors 백필은 필요조건이지 충분조건 아님" · mood best-effort 삼킴 · onboarding_pick writer 단일.

추가 정정 2건: G1 게이트 상태코드는 400이 아니라 422(error.rs:81-84가 ValidationErrors→UNPROCESSABLE_ENTITY). §5의 "피드 개인화 신호 없음"은 더 정확히는 DNA 재랭킹이 무증상 no-op이다 — blend_with_dna가 유저/포스트 벡터 중 하나라도 없으면 _ => base로 원점수를 반환하고 로그·플래그가 없다(단 가중치 feed_dna_mix 실측값 미확인이라 손실 크기는 미측정).