확인 끝났다. 결론부터.

요약

1) 계정/설정 스키마

• 계정 정본: user_identities(email PK, display_name, title, …) — migrations/0005.
• 인증: src/shared/auth.ts → Cloudflare Access JWT의 email이 곧 사용자 식별자. dev에선 jungwkim15@gmail.com으로 바이패스. 세션/유저 PK = email 로 일관됨.
• 사용자별 설정 테이블은 전무(전체 마이그레이션 0001~0049 확인). 개인화는 신규 테이블로 붙여야 하고, FK는 user_identities.email 로 잡는 게 기존 컨벤션과 일치.

2) 사이드바 렌더링 방식

• 완전 하드코딩. shell.tsx:22 NAV_ITEMS 트리 상수 → NavNodes가 <details> 아코디언으로 서버 렌더. DB·API 미경유.
• 구조상 '기능'(=서류작성) 그룹(라인 2673)과 운영도구(고객관리/AR/브레인/보고서 7479, 설정=ADMIN_NAV_ITEMS)가 이미 분리돼 있음 → 요청한 "서류작성만 개인화, 운영도구 공통고정"에 구조가 잘 맞음.
• 개인화 구현 핵심: NAV_ITEMS에서 '기능' children을 상수에서 떼어내, 렌더 시점에 (legal_doc_catalog ⨝ user_doc_selections by email)로 동적 생성. 나머지 노드는 상수 유지. WorkspaceShell에 이미 userEmail이 들어오므로, 시그니처에 docNav 같은 인자 하나 추가하는 최소 변경으로 가능.

3) 권장 매핑 스키마

-- migrations/0050_user_doc_selections.sql
CREATE TABLE IF NOT EXISTS user_doc_selections (
  email      TEXT NOT NULL REFERENCES user_identities(email),
  doc_id     INTEGER NOT NULL REFERENCES legal_doc_catalog(id),
  pinned     INTEGER NOT NULL DEFAULT 1,   -- 사이드바 노출 여부
  sort_order INTEGER NOT NULL DEFAULT 0,   -- 사용자별 정렬
  created_at INTEGER NOT NULL DEFAULT (strftime('%s','now')),
  PRIMARY KEY (email, doc_id)
);
CREATE INDEX IF NOT EXISTS idx_uds_email ON user_doc_selections(email, pinned, sort_order);

설계 포인트:

• doc_id(=catalog.id) 참조가 정답. doc_name 직접 저장은 카탈로그 개편 시 깨짐 — id 외래키로 묶는다.
• 복합 PK(email, doc_id) 로 중복 방지 + 사용자별 정렬/핀 메타를 같은 행에 둔다.
• 빈 선택 = 기본값 처리: 행이 없으면 legal_doc_catalog.in_scope='core'(P0 핵심) 기본 세트를 보여주는 fallback을 렌더 로직에 둘 것. (안 그러면 신규 변호사 사이드바가 빈 화면)
• 운영도구는 이 테이블과 무관하게 상수 고정.

추가 검토 필요(미확정): '기능' 트리의 6단계 그룹 구조(보전/소제기/심리…) 를 개인화에서도 유지할지, 평면 목록으로 바꿀지는 제품 결정 사항. 현재 카탈로그는 tab/feature_group로 그룹핑 메타를 갖고 있어 그룹 구조 유지가 자연스럽다.

이번 응답은 조사만 했고 코드 변경·마이그레이션은 아직 없음(롤백 대상 없음). 실제 구현 착수 시엔 daemon 무관 영역(shell.tsx + 신규 마이그레이션)이라 비가역성은 낮으나, 0050 마이그레이션은 추가 전 커밋 고정하고 진행하겠다.