이전 메시지 불러오는 중…
변우석의 요청:
변우석입니다. LAX 제품 관련 두 가지 현황 확인 부탁합니다.
1) 고객관리(CRM) 기능이 지금 실제로 존재하나요? 존재한다면 의뢰인/고객 데이터가 '로컬 폴더에 고객별 폴더' 형태로 저장·관리되는 구조인지, 아니면 DB 기반인지 알려주세요. 워크플로우상 '의뢰인 상담→고객관리 등록→계약완료→소장 작성' 순서를 태우려는데, 소장 작성 전 단계인 고객관리가 어떻게 굳어져 있는지 알아야 합니다. (예: 그랜드비스타 같은 고객이 등록되는 위치/스키마)
2) 현재 '소장 작업대'의 좌측 대화/우측 라이브 미리보기 2단 UX가 공통 컴포넌트로 추상화돼 있나요? Jason이 "소장뿐 아니라 기능 안의 모든 서류작성을 이 미리보기 방식으로 통일하고 싶다"고 합니다. 새 서류종류(예: 준비서면, 내용증명)를 추가할 때 그 우측 미리보기 작업대를 재사용할 수 있는 구조인지, 아니면 소장 전용으로 하드코딩돼 있는지 알려주세요.
각 항목 현황 + 확장 시 작업 난이도만 간단히 주시면 됩니다.
변우석님, 손석구입니다. 코드베이스(C:\Users\user\LAX-site, Hono + Cloudflare D1) 직접 조사해서 두 항목 확인했습니다. 코드 기준 사실 확인이며, 라이브 데이터 1건 검증은 아닙니다(필요하면 추가로 돌리겠습니다).
1) CRM(고객관리) — 존재함, DB 기반 (로컬 폴더 아님)
| 항목 | 현황 |
|---|---|
| 기능 존재 | ✅ 완전 구현. /clients 목록·상세·등록·소프트삭제 |
| 저장 구조 | ✅ Cloudflare D1(SQLite) DB. clients 테이블 |
| 폴더 기반 여부 | ❌ 아님. mkdir/fs.mkdir 등 파일시스템 코드 0건 |
| 관련 파일 | src/app/clients/routes.tsx, src/shared/crm.tsx |
clients 스키마 핵심: id, name, phone, email, case_type, source, status, memo, created_by, created_at, updated_at, deleted_at (마이그레이션 0036~0040).
워크플로우 단계는 이미 코드에 박혀 있습니다. src/shared/crm.tsx:
STAGES = ['접수', '계약 대기', '계약 완료', '착수', '종결']
- 단계 상태는
clients.status가 아니라matters(사건) 테이블의status가 들고 있습니다. 즉 고객 1명에 사건 N건이 붙고, 사건별로접수→계약완료→착수→종결단계가 흐릅니다. 변경 엔드포인트는POST /matters/:id/status. - 변우석님이 태우려는 "상담→고객관리 등록→계약완료→소장작성" 흐름은 이 구조와 그대로 맞습니다. 소장 작성은
matters(사건)에 종속되며, 고객(clients)이 먼저 등록돼야 사건이 붙습니다.
⚠️ "그랜드비스타" 같은 시드/예시 고객명은 코드·마이그레이션에 없습니다. 샘플 프리로드 없이 사용자가 직접 등록하는 방식입니다. 그랜드비스타가 실제 등록돼 있는지는 운영 D1 데이터 조회가 필요한 별개 문제입니다(원하시면 조회해 드립니다).
2) 소장 작업대 2단 UX — 렌더 파이프라인은 범용, UI 텍스트만 소장 하드코딩
| 항목 | 현황 |
|---|---|
| 2단 레이아웃 위치 | src/app/draft/routes.tsx (dw-left 대화 / dw-right 미리보기) |
| 미리보기 렌더러 | ✅ 범용. src/shared/draft_doc.ts의 renderDraftDocument()는 문서 타입 정보 없이 문자열만 받음 |
| 문서 분리 방식 | ✅ 마커 기반(SOJANG:start/end, 증거표 마커) — 소장/답변서/준비서면이 동일 파이프라인 공유 |
| 소장 강결합 | ❌ 거의 없음. 단, UI 라벨/안내문구가 "소장"으로 하드코딩(탭명 "소장", "소장을 작성하는 중" 등) |
핵심: 이미 답변서, 준비서면은 부분적으로 들어와 있습니다. 타입 분기점이 명확합니다.
- 타입 정의:
src/shared/evidence.ts→type BriefKind = '답변서' | '준비서면' - 라우팅:
/complaint-draft?type=답변서&matter=:id - DB:
matter_documents.doc_type컬럼에 타입 자동 저장(제약 없음)
새 서류(내용증명 등) 추가 시 손볼 곳:
BriefKind타입에 추가 (1줄)draft/routes.tsx입력 분기 1줄- 프롬프트 빌더에 해당 서류 형식 정의 추가 — 여기가 실질 작업(법적 정확성, 변우석님 영역)
- UI 하드코딩 "소장" 텍스트 동적화(선택)
- 진입 버튼 추가
확장 난이도: MEDIUM-LOW. 미리보기 렌더러는 그대로 재사용됩니다. UI/배관은 가볍고, 무게중심은 각 서류의 작성 프롬프트(법적 형식) 설계에 있습니다.
한 줄 결론
- CRM: DB 기반으로 굳어져 있고(폴더 아님), 의뢰인→사건→단계 구조가 변우석님 워크플로우와 일치. 소장은 사건에 종속.
- 작업대: "소장 전용 하드코딩"은 UI 텍스트 수준뿐, 2단 미리보기 자체는 이미 범용 재사용 구조. Jason의 "모든 서류 통일" 방향에 구조적 장벽 거의 없음.
운영 DB에서 그랜드비스타 실등록 여부 확인이 필요하면 말씀 주세요. 바로 조회하겠습니다.