본문으로 건너뛰기

ADR 0018 — 플랫폼 내 법률 서류 편집 전환 · AI 학습 루프 닫기

  • 일자: 2026-04-24
  • 상태: Accepted
  • 연관: ADR 0002 (전 사용자 무료), 0012 (docx-first export), 0015 (tenant-isolated AI learning), 0017 (V2 검색 파이프라인)
  • 대체 관계: ADR 0012 는 본 ADR 에서 재정의됨 — "docx-first" 는 export 포맷으로 격하. 편집 자체는 플랫폼 내 에디터.

배경 — 왜 재검토하는가​

Chair 지적 (2026-04-24 새벽 회의): "우리 플랫폼에서 수정이 다 이루어져야 하는 거 아닌가요? 왜 다른 소프트웨어를 사용하죠?"

현재 흐름:

[AI 생성 초안 (.docx)]
    ↓ 다운로드
[변호사 Word/한글에서 편집]   ← 우리 시스템 밖
    ↓ 저장
[PDF/HWP 로 법원 제출]

이 흐름의 본질적 결함:

1. ADR 0015 가치 훼손​

ADR 0015 핵심: "자기 사무소 데이터는 자기 사무소 AI 에 학습". 그런데 변호사가 편집한 최종본은 Word/한글 → 자기 PC → 법원 경로라 플랫폼이 못 봄.

  • AI 가 작성한 초안: 시스템이 본다
  • 변호사가 편집한 최종본: 시스템이 못 본다
  • → AI 는 자기 초안 스타일로 영원히 학습 정체. 변호사는 같은 수정을 매번 반복

"학습하는 사무실 AI" 제품 약속이 반쪽 배송 상태.

2. 플랫폼 가치 포획 제로​

  • 계산 · AI 초안 생성만 우리 플랫폼
  • 실제 완성·제출은 외부 (Word/한글)
  • 이동 비용 낮음 → AI 초안 품질 경쟁만으로는 lock-in 약함

3. 협업 · 감사 · 버전 없음​

  • 파트너 리뷰 = docx 이메일 첨부
  • 변경 이력 = Word track changes (플랫폼 밖)
  • 의뢰인 공유 = PDF 이메일
  • 변호사법상 업무 감사 추적 근거도 플랫폼 밖

4. dogfood 루프 단절​

Chair 나 변호사가 편집 패턴을 데이터로 보고 개선할 수단 없음. 단순 텔레메트리 (shown · clicked) 만으로는 품질 개선 경로 약함.

결정​

법률 서류 편집을 플랫폼 내 리치 텍스트 에디터로 전환한다. docx/PDF/HWP 는 최종 제출용 export 포맷으로 격하.

핵심 원칙​

  1. 편집은 플랫폼에서 — AI 초안 받은 뒤의 모든 수정은 in-app 에디터
  2. export 는 제출 전용 — .docx / PDF / HWP 는 한 번 내보내고 끝
  3. 편집 데이터는 학습 자산 — 모든 diff 가 docEditEvents 에 기록되어 AI 2세대 학습 input
  4. 변호사 검토 완료 이벤트 = 학습 feed — 최종본이 확정된 순간 사무실 기억 RAG 에 embedding 추가

아키텍처​

[AI 초안 생성]
    ↓ (기존 generateDocxAction 대체)
[InPlatformDocEditor (Tiptap)]
    ├── initialState = AI JSON 초안
    ├── 변호사 편집 (키/마우스)
    ├── 각 변경 → docEditEvents Firestore 저장 (throttled)
    ├── 버전 스냅샷 (수동 버튼 · 자동 시간)
    ├── AI 제안 사이드바 (hover · inline commands)
    └── 협업: 인라인 코멘트 · 멘션 · 리뷰 요청
    ↓ [검토 완료] 버튼
[frozen final text]
    ├── PDF export (Puppeteer)
    ├── docx export (html-to-docx)
    └── 📌 이 텍스트가 tenant embedding 에 feed (ADR 0015 loop 완성)

데이터 모델​

새 컬렉션:

  • tenants/{tid}/cases/{caseId}/documents/{docId} — 편집 중인/완료 서류 metadata + 현재 상태
  • tenants/{tid}/cases/{caseId}/documents/{docId}/versions/{versionId} — 버전 snapshot (Tiptap JSON)
  • tenants/{tid}/cases/{caseId}/documents/{docId}/editEvents/{eventId} — diff 이벤트 (학습 feed)
  • tenants/{tid}/cases/{caseId}/documents/{docId}/comments/{commentId} — 협업 코멘트

documents.finalizedAt 이 채워지면 AI 학습 트리거 (Cloud Function onDocumentFinalized):

  1. 최종 텍스트 → redactText (1단) + NER 2단 (#584·#586·#587)
  2. 비식별화 텍스트 → Vertex AI embedding
  3. legacyDocuments 에 sourceType="authored" 로 신규 문서 추가

기술 스택​

에디터: Tiptap (ProseMirror 기반)

근거:

  • React Hook 기반 · 현재 프로젝트와 호환
  • 플러그인 생태계 성숙 (collaboration · history · mentions)
  • 한국어 처리 안정적 (ProseMirror 기본 Unicode)
  • JSON 직렬화 → Firestore 저장 용이
  • docx export: html-to-docx · PDF export: Puppeteer

대안 Lexical (Meta) 는 최신이지만 한국어 커뮤니티 적음 + 플러그인 적음. 대안 Slate 는 자유도 높지만 러닝커브 크고 협업 플러그인 부족.

결정 근거​

기술적​

  • Tiptap JSON 직렬화가 Firestore 와 자연스러움 (Timestamp 등 serialize 안 해도 됨)
  • ProseMirror 의 collab extension 이 나중 실시간 협업 확장 경로 열어줌
  • html-to-docx · Puppeteer PDF 는 검증된 Node.js 라이브러리

제품적​

  • ADR 0015 "tenant-isolated AI 학습" 을 실제로 동작시키는 유일한 경로
  • "계산기 + AI" 에서 "사무실 운영 체계" 로 제품 포지셔닝 격상
  • 파트너 리뷰 · 의뢰인 공유 등 고부가 기능의 기반

경쟁적​

  • 타 법률 SaaS (CaseText · Clio · 등) 는 별도 편집 앱에 의존. 우리가 all-in-one 으로 차별화
  • 한국 시장: 한컴 · MS Word 사이에서 중립적 웹 기반 이라 양쪽 사용자 흡수 가능

대안 검토​

대안 A. 현행 유지 (docx 생성만)​

  • Pros: 이미 구현됨. 추가 비용 0.
  • Cons: ADR 0015 가치 구현 불가. 경쟁 약화. → 거부.

대안 B. Google Docs 임베드​

  • Pros: 편집기 구현 비용 0. 협업 자동.
  • Cons: 데이터 GCP Docs 에 저장 → PII 주권 상실. 한국 법률 실무 표준 아님. 변호사법 비밀유지 위반 우려. → 거부.

대안 C. Tiptap (채택)​

  • Pros: in-platform. 데이터 주권. 한국어 OK. 확장성. AI 통합 가능.
  • Cons: 구현 2~4주. HWP export 직접 지원 없음.

대안 D. 자체 ContentEditable 편집기​

  • Pros: 100% 커스텀.
  • Cons: contentEditable 의 브라우저별 버그 지옥. 한글 IME 안정성 없음. → 거부.

단계적 롤아웃 (Phase A → D)​

Phase A — 에디터 뼈대 (1 주)​

  • Tiptap 설치 + 기본 <InPlatformDocEditor> 컴포넌트
  • DocKind 하나 (추심명령 신청서) 에 먼저 적용
  • 초기 상태: AI 생성 텍스트 → Tiptap JSON 로드
  • Firestore documents 컬렉션 생성 + Zod 스키마
  • 자동 저장 (throttled 2초)

Phase B — 버전 · 이력 (1 주)​

  • 수동 "버전 저장" 버튼
  • 자동 시간 snapshot (매 30분)
  • 버전 간 diff 표시
  • 롤백 UI

Phase C — export (완료, 2026-04-23)​

  • 브라우저 인쇄 경로: Tiptap JSON → HTML (pure renderTiptapDocToHtml) → wrapAsPrintableDocument (A4 print CSS) → window.print() → 사용자가 "PDF 로 저장" 선택. Puppeteer 대신 브라우저 네이티브 활용 (의존성 0).
  • HTML 다운로드: .html 파일로 저장 → Word · 한글 · LibreOffice 에서 열기 가능.
  • 기존 generateDocxAction (템플릿 기반) 경로는 그대로 유지 — AI 초안 생성용. 편집본 export 는 브라우저 인쇄로 대체.
  • HWP 는 후속 (한컴 라이센스 · 변환 라이브러리 제약).
  • 산출물: apps/web/app/(workspace)/cases/[caseId]/_lib/tiptap-to-html.ts (22 테스트) + InPlatformDocEditor 에 "인쇄/PDF" · "HTML" 버튼.

Phase D — AI 학습 루프 (1 주)​

  • 검토 완료 이벤트
  • Cloud Function onDocumentFinalized 트리거
  • 최종본 → NER 2단 → embedding → legacyDocuments 추가
  • ADR 0015 loop 공식 완성

Phase E — 협업 (후속, 별도 ADR 검토)​

  • 인라인 코멘트
  • 멘션
  • 파트너 리뷰 승인
  • 실시간 협업 (Y.js + Tiptap collab)

총 예상: Phase AD = 3.54 주 + Chair 검증.

플래그 · 킬 스위치​

  • features.infraHardening.inPlatformEditor 신규 플래그 (기본 false, Phase A 머지 후 true)
  • 문제 시 false 로 flip → 기존 generateDocxAction 경로로 폴백 유지 (Phase A~B 동안)
  • Phase C 에서 기존 경로 deprecate 시점 별도 ADR 개정

Minority Report​

P1 (10년차 변호사)​

  • "웹 에디터는 Word 만큼 안정적이지 않다" — 한글 IME · 단축키 · 복잡 표 처리 불안. Phase A 파일럿 중 반드시 실측 필요.
  • 대안으로 "초안 AI + 기존 Word 편집 + 최종본만 플랫폼에 업로드" 도 고려 가치. 학습 루프만 닫고 편집 자체는 Word 유지.
    • Chair 반박: 업로드 방식은 변호사가 매번 번거로운 수동 동기화 필요. dogfood 루프 끊어짐. 파일럿 전 A/B 비교는 가능.

P5 (풀스택 개발자)​

  • Tiptap 의 commercial license 확인 필수 (MIT 이나 Pro 기능 별도 요금 있음)
  • Puppeteer · html-to-docx 가 Cloud Functions Gen2 memory 한도 (1GB) 내 동작 여부 실측 필요
  • 편집 이벤트 storm (타이핑마다 Firestore write) 회피 — throttle 설계가 critical

P7 (보안 · 컴플라이언스)​

  • 에디터 JSON 내 PII (의뢰인 · 피고 이름) 가 Firestore 에 저장됨. PII 저장 정책 (ADR 0015 · CLAUDE.md) 과 충돌 가능성. 현재는 redactedText 만 저장 허용.
  • 해결책: documents.rawJson 은 저장하되, tenantEmbedding feed 전에 NER 2단 mask 강제.
  • 별도 정책 문서 (data-editing-pii-policy.md) 필요.

성공 지표 (Phase D 완료 시)​

  • 변호사 1인당 월 평균 편집 세션 ≥ 10 회
  • 편집 세션당 평균 Save events ≥ 20
  • documents.finalizedAt 이 채워진 문서 비율 ≥ 80%
  • 최종본 → embedding 생성 성공률 ≥ 95%
  • 사무실 기억 검색에서 "자가 생성 문서" (sourceType="authored") 매칭 비율 ≥ 30% (Phase D 후 6개월)

관련 후속 과제​

  1. ADR 0012 개정 — "docx-first export" 를 "in-platform editor first, export 부가" 로 재정의
  2. HWP export — 한컴 SDK 검토 또는 hwpx-js 같은 커뮤니티 라이브러리 조사
  3. AI 제안 엔진 — 에디터 안에서 문장/단락 단위 AI 재작성 제안 (inline suggestion)
  4. 협업 프로토콜 — ADR 0019 (예정) "실시간 협업 편집"
  5. 편집 이벤트 → 사무실 기억 학습 — ADR 0020 (예정) "edit pattern → RAG tuning"

본 ADR 과 기존 구현의 관계​

현재 (2026-04-24) 머지된 것들:

  • 계산 엔진 (collection-order · provisional-attachment · recovery 6 유형) — 유지
  • .docx 생성 Server Action (#604) — Phase C 까지 유지, 이후 deprecate
  • DocKind 확장 (#602) — 유지 (export 대상으로 계속 사용)
  • snapshot 저장 (#605 · #606) — 유지 · 확장 (documents 컬렉션이 snapshot 과 병존하거나 통합)
  • NER 2단 (#584 · #586 · #587) — Phase D 의 핵심 입력 (최종본 → NER → embedding)

즉 지금까지의 작업은 Phase C 의 export + Phase D 의 학습 input 으로 전부 재활용됨. 버려지는 것 없음.

변경 이력​

  • 2026-04-24: 초안 작성 (Accepted). docx-first 폐기 + Tiptap 에디터 + 학습 루프 닫기 결정.
  • 2026-05-13 (Amended): Feature Registry STALE drift 분석으로 features.infraHardening.inPlatformEditor flag 가 코드 정의 안 됨이 발견됨 (이 ADR 본문에만 언급). 후속 분석:
    • Tiptap 에디터 (apps/web/app/(workspace)/docs/[docId]/_components/Editor.tsx 등) 는 default 경로로 안정화 완료.
    • 폴백 경로 (generateDocxAction) 는 Phase C 까지 export 용도로 유지중.
    • kill switch 자체가 불필요 — Tiptap 으로의 전환이 점진적 폴백 (기존 docgen export 보존) 으로 이뤄져 일괄 flip 시나리오가 발생하지 않음.
    • 결정: features.infraHardening.inPlatformEditor flag 는 정의하지 않음. 본 ADR 의 flag 언급은 초안 시점 보수적 안전망 이었으며, 실제 ship 흐름에서 불필요해진 deprecated proposal 임을 명시.