기준 사건 흐름
너홀로프로의 모든 화면·기능·시나리오는 이 6단계 흐름을 따른다. 이 문서는 SSoT — 새 기능 추가 시 "어느 단계의 사용자 행동을 도와주는가" 를 먼저 명시.
1. 상담 → 2. 분류 → 3. 서류 정리 → 4. 제출 → 5. 재판 진행 → 6. 결과
├ 의뢰인 받기 ├ 판결
└ 사무소 작성 ├ 회수 (Pack 1)
└ 합의 종결
1. 상담
의뢰인이 사무소에 사건을 설명한다. 변호사는 듣고 사건을 등록한다.
| 주체 | 행동 |
|---|---|
| 의뢰인 | 전화·방문·포털 메시지로 사건 설명 |
| 변호사 | 핵심 정보 (당사자·상대방·사실관계·금액) 정리 후 사건 등록 |
현재 코드:
- 수임 전 상담 (ADR 0049, P0-3):
apps/web/app/(workspace)/consultations/— 상담 기록 (경위 원문·쟁점·예상 청구액·후보 유형) + 상태 (상담중/수임/미수임)- 이해충돌 자동 검사 (P0-4
ConflictCheckPanel) + 수임 전환 → 위저드
- 이해충돌 자동 검사 (P0-4
- 비즈니스:
packages/business-logic/consultations(create · declined/reopen · markConverted) - 사건 등록:
apps/web/app/(workspace)/cases/new/page.tsx(wizard 3 단계) - 비즈니스:
packages/business-logic/cases/create.tscreateCase - 검증:
apps/web/app/(workspace)/cases/_lib/schemas.ts(Zod)
Gap:
- 의뢰인이 직접 사건 정보를 입력하는 경로 없음 (변호사가 듣고 입력)
- 통화·녹취 → 자동 사건 카드 변환 없음
2. 분류
이 사건이 어떤 소송인지 판단한다.
| 주체 | 행동 |
|---|---|
| 변호사 | recoveryType 14종 중 선택 (Pack 1~5: 대여금/이혼/부동산/상속/계약 + 세부) |
현재 코드:
- wizard 의 recoveryType select
packages/business-logic/cases/create.ts의NON_DEBT_RECOVERY_TYPES분기setRecoveryType/setSubrogationSubtype(변경)- Pack 별 도메인 필드:
updateCaseDivorce(Pack 2) ·updateCaseProperty(Pack 3) ·updateCaseInheritance(Pack 4) ·updateCaseContract(Pack 5)
Gap:
- 사건 설명 텍스트 → AI 가 recoveryType 자동 추천 없음 (변호사 수동 선택)
- 복합 사건 (대여금 + 양수금 등) 다중 분류 없음
3. 서류 정리
이 사건에 필요한 서류를 모은다. 두 갈래로 나뉜다.
3-A. 의뢰인에게 받을 서류
| 주체 | 행동 |
|---|---|
| 변호사 | 포털 토큰 발급 + 어떤 서류 필요한지 알림 |
| 의뢰인 | 포털 4자리 코드로 접속 → 메시지·첨부 업로드 |
현재 코드:
- 페이지:
apps/web/app/(portal)/portal/... - 토큰:
createPortalToken/revokePortalToken - 메시지:
sendPortalMessage/markPortalMessagesRead - 첨부:
addEvidence(의뢰인 첨부도 evidence 로 들어감)
Gap:
- "이 recoveryType 에서 의뢰인이 줘야 하는 서류 체크리스트" 없음
- 의뢰인 업로드 서류 자동 분류·OCR 정리 약함 (수동 정리)
3-B. 사무소에서 작성할 서류
| 주체 | 행동 |
|---|---|
| 변호사 | docKind 19종 중 선택 → AI 초안 → 다듬어 finalize |
현재 코드:
- AI 생성:
generateLegalDoc(apps/web/lib/ai/client.ts) - Server Action:
apps/web/app/(workspace)/docs/_actions/generate-docx-action.ts(generateDocxAction) - 편집 문서:
createEditableDocument·saveEditableDocument·createDocumentVersion·rollbackDocumentToVersion - 확정:
finalizeDocument(학습 루프 트리거, ADR 0018) - 사무실 기억 (RAG):
findRelatedMemoriesForDocGenAction· ADR 0021publicDocumentsPlatform RAG
Gap:
- "이 사건에 어떤 docKind 들이 필요한지" 자동 체크리스트 없음 (변호사 수동 docKind 선택)
4. 제출
사무소가 작성한 서류를 법원·관계 기관에 제출한다.
| 주체 | 행동 |
|---|---|
| 변호사 | 법원 e-소송 또는 종이로 제출 → 시스템에 제출 표시 |
현재 코드:
markDocSubmitted— 제출 일자·법원 stamp- 발송 이력:
recordSentDoc(의뢰인 사본 보낼 때) - 제출 브리지 (전자소송 #2,
FilingBridgeCard) — 서류 탭에서 전자소송 접수 체크리스트(본안·지급명령·보전) + 인지/송달료 추정(litigation-cost.tsSSoT) - 사건번호 구조화 (전자소송 #4,
lib/legal/case-number.ts) — 입력한 법원 사건번호를 법원·연도·사건부호·일련로 파싱, 부호에서 분야·심급·재판부 도출 + recoveryType 불일치 가드
Gap:
- 법원 e-소송 시스템 자동 연동 없음 (수동 제출 후 표시만, Chair 지시)
- 전자소송 API 를 통한 사건번호 자동 캡처는 없음 — 수동 입력이나, 입력값은 구조화 파싱·심급 도출됨 (전자소송 #4)
5. 재판 진행
기일이 잡히고, 증거가 오가고, 변론·준비서면이 작성된다.
| 주체 | 행동 |
|---|---|
| 변호사 | 기일 입력 → 기일 결과 기록 → 증거 정리 → 준비서면 작성 (3-B 재호출) |
| 의뢰인 | 진행 상황 포털에서 확인 |
현재 코드:
- 기일:
addHearing·updateHearingResult·apps/web/app/(workspace)/cases/[caseId]의 hearing 탭 - 증거:
addEvidence·deleteEvidence - 다음 조치 AI:
generateHearingNextActions(기일 결과 → 체크리스트) - 사건 메시지:
sendCaseMessage·addCaseComment(사무소 내부)
Gap:
- 변론기일 자동 캘린더 sync 없음
- 의뢰인 포털에 진행 상황 자동 요약 노출 약함
6. 결과
판결·집행·합의로 사건이 종결된다.
6-A. 판결
| 주체 | 행동 |
|---|---|
| 변호사 | 판결문 수령 → 사건에 캡처 → 자동 상태 전이 |
현재 코드:
updateCaseJudgment(판결 캡처 + 자동 상태 전이)- 판결문 추출 AI:
extractJudgmentFromText
6-B. 회수 (Pack 1 채권 등)
| 주체 | 행동 |
|---|---|
| 변호사 | 변제 등록 → 강제집행 → 배당 |
현재 코드:
- 변제:
addRecovery·updateRecovery·deleteRecovery - 집행:
updateCaseExecution(집행 단계 + 자동 종결 전이) - 배당:
distributeExecution(절대 우선권 라운드 분배) - 스냅샷:
createRecoverySnapshot·saveDistributionSnapshot
6-C. 합의 종결
합의 외 종결(기각·취하) 포함: 6-C 는 합의 종결이 대표 경로이나, 합의 데이터 없이 종결된 사건(기각·취하·일반 종결)도 본 단계로 분류한다. 라벨은 구분한다 — 실제 합의(
hasSettlement)면 "6-C 합의 종결", 그 외 종결이면 중립 "6-C 종결" 로 표시 (flow-stage.tsinferCaseFlowStage). 패소(기각)·취하 사건을 "합의로 종결됐습니다" 로 오표시하던 동작을 fix.
| 주체 | 행동 |
|---|---|
| 변호사 | (합의) 합의서 작성 → 변제 입금 확인 → 사건 종결 표시 |
| 변호사 | (기각·취하) 종결 사유 기록 → 사건 기록 정리 |
현재 코드:
- 사건 상태:
updateCaseStatus(→ closed) - 변제 스냅샷:
createSettlementSnapshot - 청구서:
createInvoice·markInvoicePaid·importBankCsvRow - 단계 라벨 분기:
flow-stage.tsinferCaseFlowStage(hasSettlement → 합의 종결 / 그 외 → 중립 종결)
Gap (6 전체):
- 패소 후 후속 조치 (항소·재심·강제집행) 자동 추천 없음
- 항소 사건 자동 연결은
updateCaseRelationship으로 수동 가능
전자소송 진행 상태 대응 (전자소송 #5)
우리 case-flow 는 6단계(1 상담 · 2 분류 · 3 서류 · 4 제출 · 5 재판 · 6 결과[6-A 판결 / 6-B 회수·집행 / 6-C 합의]) 이며, Pack 6 형사 사건은 별도 9 phase (_criminal/criminal-phase.ts) 를 쓴다. 이는 사무소 업무 흐름 관점이라, 법원 절차 관점의 전자소송 진행 상태(접수·송달·변론·선고·확정)와 프레이밍이 다르되 아래처럼 정합 대응한다.
| 우리 case-flow 단계 | 전자소송 진행 상태 | 비고 |
|---|---|---|
| 1 상담 · 2 분류 · 3 서류 | (전자소송 접수 이전) | 수임·서류 준비 — 법원 절차 진입 전 |
| 4 제출 | 접수 | 제출 = 전자소송 접수. 제출 브리지(전자소송 #2)가 체크리스트·인지/송달료로 연결 |
(수신 서류 = incoming-doc) | 송달 | 법원 발송 서류 수신 → 자동 분류 + 송달기한 추천(전자소송 #3, service-deadline.ts) |
| 5 재판 진행 | 변론 | 기일·준비서면·증거 |
| 6-A 판결 | 선고 | 판결 캡처(judgmentResult) |
| 6-B 집행 · 6-C 합의 | 확정 이후 | 확정 → 강제집행·회수·정산 |
설계 원칙 — 상호 대응하되 라벨은 통일하지 않는다. 우리 단계 라벨(제출·재판·결과)은 변호사의 업무 관점을 유지하는 것이 제품 가치("법률 사무소가 관리")이므로, 법원 용어(접수·변론·선고)로 재명명하지 않는다. 대신 사건번호 접수 메타(전자소송 #4, case-number.ts 의 심급·재판부 도출)와 제출 브리지·송달 분류가 각 단계에서 전자소송 화면과의 인지 일관성을 보조한다. 사건번호 부호(가합=1심 합의, 나=항소, 다=상고 등)가 심급을 알려주므로 변호사가 두 화면을 오갈 때 현 단계를 교차 확인할 수 있다.
Gap (전자소송 대응): 전자소송 실시간 상태 API 연동은 없음(Chair 지시 — 법원 API 미연동). 상태 전이는 수동 입력·수신 서류 분류로 추정한다.
UI 매핑 원칙
새 화면·메뉴·시나리오 카드 추가 시:
- 어느 단계인가 명시 (1~6)
- 누구의 행동인가 명시 (의뢰인 / 변호사 / 시스템)
- 이전 단계 출력 + 다음 단계 입력 명시 (예: 5단계 기일 결과 → 6-A 판결 캡처 입력)
기존 화면도 점진적으로 이 흐름에 맞춰 재정렬한다 (다음 PR 들).
진척 현황 (case-flow PR 시리즈)
본 SSoT 합의 후 12 PR ship 완료:
| PR | 영역 | 변경 |
|---|---|---|
| #1204 | SSoT 정의 | 본 문서 |
| #1205 | ops 사이드바 | 21 도메인 → 6단계 + 운영 도구 2 섹션 |
| #1206 | 사건 상세 인디케이터 | inferCaseFlowStage + CaseFlowStageBanner |
| #1207 | 3-A 의뢰인 카탈로그 | Pack 별 정적 카탈로그 |
| #1208 | 3-B 사무소 카탈로그 | DocKind 19종 매핑 |
| #1209 | 6-A 판결 후 추천 | 항소 D-day + outcome 분기 |
| #1210 | 3-A 의뢰인 status | 토글 + Firestore stamp |
| #1211 | 3-B 사무소 status | 4-cycle 수동 토글 |
| #1212 | 3-B 자동 추론 | documents 매칭 → status |
| #1213 | 5 기일 결과 추천 | 결과 enum 별 정적 룰 |
| #1214 | 대시보드 분포 | 9단계 KPI 위젯 |
| #1215 | 9단계 visual stepper | CaseFlowStageBanner 강화 |
단계별 Gap 잔여 (우선순위)
| 단계 | 진척 | 잔여 Gap |
|---|---|---|
| 1 상담 | 사건 등록 wizard | 사건 설명 → recoveryType 자동 추천 AI · 통화 녹취 자동 캡처 |
| 2 분류 | recoveryType 14종 | 사건 설명 → 자동 분류 추천 · 복합 사건 다중 분류 |
| 3-A 의뢰인 받기 | ✅ 카탈로그 + status | portal 의뢰인 측 노출 (의뢰인이 자기 진척 보기) · evidence 자동 매칭 |
| 3-B 사무소 작성 | ✅ 카탈로그 + status + 자동 | docKind 별 default 템플릿 자동 채우기 |
| 4 제출 | markDocSubmitted | 법원 e-소송 자동 연동 · 사건번호 자동 캡처 |
| 5 재판 진행 | ✅ 기일 결과 추천 | 변론기일 캘린더 자동 sync · 의뢰인 포털 진행 요약 |
| 6-A 판결 | ✅ 추천 | 판결문 자동 OCR · judgmentOutcome 자동 분류 |
| 6-B 회수 | (Pack 1 흐름 갖춰짐) | 채무자 재산조사 자동 도구 |
| 6-C 합의 | (현재 흐름) | — |
UI 매핑 원칙
새 화면·메뉴·시나리오 카드 추가 시:
- 어느 단계인가 명시 (1~6)
- 누구의 행동인가 명시 (의뢰인 / 변호사 / 시스템)
- 이전 단계 출력 + 다음 단계 입력 명시 (예: 5단계 기일 결과 → 6-A 판결 캡처 입력)
기존 화면도 점진적으로 이 흐름에 맞춰 재정렬한다.
다음 우선순위 후보
- portal 의뢰인 측 노출 (3-A 짝, Gap 1) — 의뢰인 데이터 모델 추가 필요
- 사건 설명 → recoveryType 자동 분류 AI (1·2 단계) — Firebase AI Logic + 사건 설명 텍스트
- 법원 e-소송 자동 연동 (4) — 외부 시스템 연동 큰 작업
참조
- Pack 1~5 spec —
apps/docs/content/product/pack-{1..5}/spec.md - ADR 0010 (Pack 1 회수 UI 분기), 0022 (Pack 2 이혼), 0023 (Pack 3 부동산), 0026 (Pack 4 상속), 0027 (Pack 5 계약)
- ADR 0018 (학습 루프 = 3-B 사무소 작성 단계 품질 강화)
- ADR 0021 (Platform RAG = 3-B 사무소 작성 시 판례·법령 인용)
- ADR 0033 (일간 법률 뉴스 = 3-B / 5 사이의 외부 동향 인지 보조)