준비서면 작성 표준 절차 (Brief Protocol)

준비서면 작성 표준 절차 (Brief Protocol)

먼저 공통 실행 규칙을 읽고 현재 호스트에서 사용 가능한 기능으로 수행한다.

실행 계약

• 시작할 때 ~/.jurisupport/playbook.md(Windows %USERPROFILE%\.jurisupport\playbook.md)를 읽는다. 없으면 공통 실행 규칙에 따라 필요한 설정만 확인하거나 cold-start-interview를 수행한다.
• 인테이크 → MD 초안 → 인용 검증 → 정본 등록(JuriSupport 또는 MD) → PDF 추출 순서와 공통 실행 규칙의 승인 범위를 지킨다.
• 진행 보고는 결정, 누락 자료, 검증 실패만 짧게 알리고 반복적인 계획·자체 점검 설명은 생략한다.
• 법원 전자제출(ecfs 등)은 범위 밖이며 사용자가 직접 수행한다.

Workflow

Phase 1: 인테이크 (Intake)

사용자로부터 다음을 수집:

• 사건번호 또는 사건명
• 서면 유형: 준비서면 / 답변서 / 의견서 / 소장 / 항소이유서 / 상고이유서 / 보정서 / 소송비용액확정신청서 / 검찰 기록열람등사 신청서 / 기타
• 제출 기한 (선택)
• 특별 지시사항 (선택)

의뢰인 서류 요청 시: 변호사가 직접 발급 가능한 공적 서류(등기사항증명서, 주민등록등본 등)는 의뢰인에게 요청하지 말고 주소/식별정보만 요청. 사실관계 미확인 항목은 의뢰인 확인 후 추가.

사건 메타데이터 조회 (다음 순서)

1. JuriSupport MCP 연동 시: get_case / list_cases 로 사건 정보 확보
2. 미연동 또는 못 찾으면: case-index 스킬 로 CSV 인덱스 조회 — case_index.py --csv <CSV 사건 인덱스 경로> get <사건번호>
3. 두 곳 모두 없으면 사용자에게 직접 묻고, 사용자가 등록을 요청한 경우 확인된 정보만 CSV에 add 하거나 JuriSupport create_case로 등록한다

신규 사건이면: JuriSupport 연동 사용자는 먼저 https://jurisupport.com/cases 에서 사건을 등록한 뒤 작업을 진행하시면 좋습니다. 전자소송 사건목록을 엑셀로 저장하여 업로드하면 사건이 자동으로 일괄 등록됩니다. 또는 사건번호만 있으면 create_case (현재 호스트의 실제 도구명·스키마 확인) 로 즉시 등록 가능.

임박 기일 확인 (JuriSupport 연동 시 list_cases/기일 조회, 또는 case-index의 list --upcoming-days 14):

• 2주 이내 기일이 있으면 알림
• 기한 역산 (제출 기한이 없으면 기일 5일 전 권장)

Phase 2: 사건기록 분석 + 초안 (Draft)

이 단계는 brief-protocol이 직접 수행한다 (외부 글로벌 스킬에 의존하지 않는다). 경로·탐색 순서는 플레이북 §5를 그대로 따른다.

2-1. 사건기록 탐색 (§5 우선순위 순)

1. JuriSupport MCP 연동 시: 사건 문서·증거 조회
2. CSV 사건 인덱스(case-index 스킬): 사건번호로 의뢰인·메타 확인 (인덱스가 채워져 있으면)
3. 사건기록 디렉토리에서 해당 사건 폴더 매칭:
   • 클라우드(rclone, 예: OneDrive) 사용 시: rclone lsf <사건기록 경로> | grep <사건번호>로 폴더를 찾고, rclone cat/copy로 본문 확보
   • 로컬 디렉토리 사용 시: 사건번호로 폴더 매칭
4. 작성서류(작업본) 디렉토리에서 기존 초안·증거자료 확인

⚠️ 사건기록이 0건이면 추측으로 작성하지 말 것. §5 경로가 비어 있거나 사건번호 매칭이 실패한 것일 수 있으니, 경로·사건번호·(필요 시) 의뢰인 폴더명을 사용자에게 확인한 뒤 진행한다. (진행중사건은 사건번호로, 작성서류는 의뢰인명으로 정리된 경우 둘을 잇는 인덱스가 필요할 수 있음 — §5-2 참조.)

2-2. 쟁점 추출

사건기록(소장·답변서·기존 준비서면·서증)에서 다툼 있는 쟁점을 추출한다. (연표·쟁점표 산출물이 있으면 활용.)

2-3. 교과서·문헌 검색

legal-books 스킬(보유 시)로 관련 교과서를 검색하고 출처(저자·서명·페이지)를 확보한다.

2-4. 목차 작성과 쟁점 방향

플레이북 §8(서면 유형별 표준 구조) + 하우스 스타일(목차 단계 체계)을 적용한 목차를 잡는다. 사용자가 목차 승인을 요청했으면 확인받고, 전체 초안 작성을 요청했으면 정한 구조를 짧게 알린 뒤 계속한다.

쟁점 방향이 애매하면 단일 결론으로 밀어붙이지 말고 A~C안 선택지를 먼저 제시한다. 각 안은 핵심 논지 / 유리한 점 / 위험 / 추천 여부만 짧게 적고, 사용자가 고른 안으로 하나의 초안을 작성한다. 불필요하게 A~C 전체 초안을 모두 쓰지 않는다.

2-5. 초안 생성

확정된 작업 범위와 목차로 초안을 작성한다. 문체는 플레이북 §9 격식체. MD 작성 규칙은 플레이북 §4-1A를 따른다. 모든 법령·판결·직접인용은 Phase 3 검증 대상으로 표시한다.

초안 맨 위에는 사람이 읽기 쉬운 선택적 힌트 태그 블록을 둘 수 있다. JS/JSON 문법으로 만들지 않는다.

<!-- jurisupport
문서태그: 소송문서
서면유형: 준비서면
출력형식: Markdown
JuriSupport등록: 요청시
사건번호: 2025가단12345
사건명: 손해배상(기)
당사자방향: 원고
-->

태그가 없어도 작성은 계속한다. 없는 값은 사건 메타데이터·파일명·본문에서 추론하고, 확신이 없을 때만 사용자에게 묻는다.

추가 확장:

• 유사 사건이 있는지 case-records 스킬로 검색 (완료·확정 사건)
• 우리측 과거 서면 패턴 참조

Phase 3: 인용 검증 (Verify)

이 단계는 강제. 절대 스킵하지 않음.

초안에서 다음을 추출하여 자동 검증:

3-1. 법령 인용 검증

초안의 모든 "○○법 제○조" 패턴 추출
→ search_law로 lawId 또는 mst 확보
→ 해당 식별자와 조문으로 get_law_text 호출 (공통 실행 규칙의 스키마 확인)
→ 조문 실존 + 텍스트 일치 확인
→ 불일치 시 사용자에게 보고

korean-law MCP가 없거나 법제처 OC 발급 전인 경우:

• 사용자가 시연·강의·실습 목적이라고 명시하면 /jurisupport:offline-law-fallback을 사용해 플러그인 내장 법령 전문 스냅샷에서 조문을 확인한다.
• 이 폴백은 헌법, 민법, 민사소송법, 형법, 형사소송법, 상법, 주요 특별형법 전문만 대상으로 한다.
• 검증 리포트에는 오프라인 스냅샷(기준일: 2026-06-14)과 실제 제출 전 korean-law MCP 또는 국가법령정보센터 재검증 필요를 표시한다.
• 실제 사건 제출용 문서는 이 상태로 Phase 3 통과 처리하지 않는다. 온라인 재검증이 될 때까지 "실습 검증"으로만 둔다.
• MCP가 없다는 이유만으로 WebSearch/WebFetch 또는 일반 웹사이트 검색으로 우회하지 않는다. 먼저 offline-law-fallback/references/statutes/INDEX.md와 해당 전문 파일을 확인한다.

3-2. 판결 인용 검증

초안의 모든 "대법원 0000. 0. 00. 선고 0000다00000 판결" 패턴 추출

[1차 검증 — korean-law MCP, 플러그인 기본 동작]
→ search_decisions(domain="precedent", query=키워드, options={caseNumber: 판결번호}) 호출
  (사건번호가 없으면 options 생략; 구형 서버는 공통 실행 규칙의 대체 도구 확인)
→ 결과에 동일 판결번호가 있으면 ✅ 일치
→ 검색 결과 ID로 get_decision_text(domain="precedent", id=ID, full=true) 호출 후 인용구 대조

[2차 검증 — 법고을(beopgoeul-search), 무료 공식 인프라]
→ 1차에서 못 찾은 판결만 beopgoeul-search 스킬로 재조회
  (대법원도서관 lx.scourt.go.kr, ~/jurisupport-beopgoeul/ toolkit)
→ 사건번호·법원·선고일·PDF URL을 구조화 데이터로 반환
→ beopgoeul-search 스킬이 없으면 이 단계는 자동 스킵

[최종 처리]
→ 두 경로 모두 실패 → "(미확인)" 표시하고 사용자에게 보고
→ 추가 확인 결과를 알려주면 그 결과를 반영
→ 절대 가짜 판결번호를 그대로 두지 말 것

3-3. 직접인용 정확도 검증

초안의 모든 " " 따옴표 인용구 추출
→ 출처(판결문/법령/교과서) 원문과 글자 단위 비교
→ 불일치 시 간접인용으로 변환 제안

3-4. 검증 리포트 출력

■ 인용 검증 결과
- 법령 인용: 12건 중 12건 일치 ✅
- 판결 인용: 5건 중 4건 일치, 1건 미확인 ⚠️
  - 대법원 2020. 5. 14. 선고 2020다12345 판결 → 검색 결과 없음
- 직접인용: 8건 중 7건 일치, 1건 불일치 ⚠️
  - "고의 또는 중대한 과실" → 원문 "고의 또는 중과실" (간접인용 권장)

검증 실패가 있으면 근거로 바로잡을 수 있는 부분을 수정하고 다시 검증한다. 사용자 판단·추가 자료가 필요한 항목만 묻는다.

3-5. (선택) 모의변론 약점 점검

모의변론을 함께 요청했으면 정본 확정 전에 수행한다. 요청이 없으면 선택 기능으로 안내하되 답을 기다리며 문서 작성을 중단하지 않는다:

"정본 확정 전에 /jurisupport:mock-hearing(모의변론)으로 상대방·재판부 관점의 약점을 점검할까요? 평결이 '보강' 또는 '재구성'이면 Phase 2(초안)로 되돌려 반영합니다."

• 사용자가 원하면 mock-hearing 스킬을 BRIEF 모드로 호출(초안 MD를 검토 대상으로 전달).
• 사건이론 자체에 문제가 확인되면 mock-hearing THEORY 모드로 전환하여 법령·판결·교과서 근거 정리표를 먼저 만들고 청구원인/항변 구성을 보강한다.
• 평결이 제출 가능(PROCEED): 그대로 Phase 4로 진행.
• 평결이 보강(REINFORCE)/재구성(REFRAME): 보강 과제를 Phase 2로 되돌려 반영 후 다시 Phase 3 검증.
• 평결이 출구(EXIT): 정본화·제출을 멈추고 의뢰인 상의를 권고.
• 요청이 없으면 건너뛰고 Phase 4로 진행(강제 아님).

Phase 4: 정본 확정 (MD 유지)

기본 정본은 MD 파일. 사용자가 처음부터 요청한 출력 형식은 Phase 5에서 함께 산출한다. 요청되지 않은 외부 등록·변환을 추가하지 않는다.

4-1. MD 파일 위치 및 명명

저장 위치: <작성문서 디렉토리>/<사건번호>_<당사자>/<서면명>_<YYYYMMDD>.md
  (예: ~/작성문서/2025가단12345_홍길동/준비서면_1차_20260519.md)
버전 관리: 파일명 날짜 변경 또는 git 커밋

4-1A. MD 내용 점검

정본 확정 전 다음을 점검한다:

• H1 제목이 서면 제목과 일치하는가.
• 힌트 태그 블록이 있으면 서면유형·출력형식·JuriSupport등록 값이 사용자 지시와 충돌하지 않는가.
• 소송서류 본문이 ~합니다 / ~입니다 격식체인가.
• ## 입증방법과 ## 첨부서류가 구분되어 있는가.
• 서증 인용은 (갑 제N호증, 제목) 형식으로 제목을 병기했는가.
• 서증·첨부서류 원본을 MD 본문에 붙여넣지 않았는가.

4-2. 문서 전달 (Delivery)

사용자가 "이 서면 보여줘", "내용 줘봐" 등 문서 본문을 요청하면:

• 파일 첨부·외부 도구 변환이 아니라 MD 본문을 채팅에 출력
• 사용자가 복사·붙여넣기 할 수 있도록 그대로 노출
• 양식(빈칸·서명란 등)이 필요한 경우에도 텍스트로 출력

4-3. 공통 원칙

• 점(•) 글머리 기호 사용 금지 (들여쓰기+텍스트 prefix로 처리)
• HWP 변환 경로는 사용하지 않는다 (한글 변환 품질 신뢰 어려움)

Phase 5: 출력 형식 옵션 (사용자 명시 요청 시에만)

기본은 MD까지로 종료. 사용자가 "PDF로 뽑아줘", "docx로 출력해줘", "JuriSupport에 올려줘" 등 명시 요청한 경우에만 다음 옵션 중 선택:

요청 형식이 모호하면 위 세 옵션을 사용자에게 제시하고 선택받기.

5-A. PDF 출력

pandoc <md경로> --pdf-engine=typst \
  -V mainfont="<설치된 한글 글꼴>" -V monofont="<설치된 한글 글꼴>" \
  -o <md경로>.pdf

권장 파일명: <사건번호>_<일자>_<서면명>_원고 대리인_<변호사명>.pdf

서증 첨부 시:

• list_case_evidence(caseId) (JuriSupport 연동 시) 또는 사용자 직접 지정
• 신규 서증 외 재인용은 호증 번호만 본문 인용
• 신규 서증 PDF는 별도 파일로 함께 전달

5-B. DOCX 출력

pandoc <md경로> -o <md경로>.docx

점(•) 글머리 기호 변환 시 들여쓰기+텍스트 prefix로 후처리.

5-C. JuriSupport 등록 (소송서류 한정)

create_legal_document(
  title: <서면 제목>,
  documentType: complaint | brief | answer | appeal,
  content: <MD 본문>,
  caseId: <사건 UUID>,
  status: "draft"
)
→ 반환된 문서 ID 보관

MD에 힌트 태그 블록이 있으면 다음처럼 해석한다:

• 서면유형 → documentType 후보로 매핑
  • 소장: complaint
  • 답변서: answer
  • 준비서면: brief
  • 항소이유서·상고이유서: appeal
• 출력형식: JuriSupport 또는 JuriSupport등록: 등록 → 사용자의 명시적 등록 요청·승인이 있는지 확인. 태그만 있으면 실제 내용을 보여 주고 승인받는다
• 출력형식: Markdown/PDF/DOCX 또는 JuriSupport등록: 요청시/미등록 → 자동 등록하지 않음

태그는 힌트일 뿐이다. JuriSupport MCP 도구 명세가 요구하는 값과 충돌하면 도구 명세를 우선하고, 불확실한 값은 사용자에게 묻는다.

등록 후 수정 사이클:

• 작은 수정: inline_edit_legal_document(documentId, ...)
• 대화형 수정: chat_legal_document(documentId, ...)
• 섹션 단위 교체: update_legal_document(documentId, content: ...)

⚠️ JuriSupport 등록 후에는 MD에서 다시 편집해 재업로드하지 말 것. 두 곳 동시 수정 시 정본 충돌. 증거 반복 인용은 isReference 방식 사용 (중복 등록 금지).

5-D. 법원 전자제출 (자동화 안 함)

⚠️ 본 단계 이후 법원 전자제출(로그인·서명·제출)은 본 플러그인 책임 범위 외. 사용자가 ecfs.scourt.go.kr 등에 직접 접속하여 처리.

Phase 6: 사용자 최종 확인

✅ 산출 완료 — 법원 제출은 사용자가 직접 수행
- 사건: <사건번호> <법원명>
- 서면: <서면 유형>, <분량>
- 정본(MD): <작성문서 디렉토리 경로>
- 선택한 출력 형식 산출물 (있는 경우만):
  · PDF: <경로>
  · DOCX: <경로>
  · JuriSupport: <document_id> (status: draft) — 소송서류만
- 신규 서증 (제출용 별도 파일이 있는 경우): <파일 목록>
- 재인용 서증: <갑X호증 등 번호 목록>

다음 단계는 사용자가 직접 수행:
1. 법원 전자제출 시스템(ecfs.scourt.go.kr 등)에 직접 접속
2. 사건 선택 → 서면(PDF 또는 직접 작성) + 서증 업로드 → 전자서명 → 제출
3. 제출 완료 후 알려주시면 사후 상태 갱신

Phase 7: 제출 후 상태 갱신

사용자가 "제출 완료"를 알리고 상태 갱신을 요청하면 다음 중 승인된 항목만 수행:

• MD 파일명에 _submitted_<YYYYMMDD> suffix 추가 (rename)
• JuriSupport에 등록한 서면이 있다면: update_legal_document(documentId, status: "submitted")
• 관련 할일 완료 처리 (update_task_status — JuriSupport 연동 시)
• 사건 진행 메모 갱신: "<날짜> <서면 유형> 제출"
• 차회 기일·후속 할일 확인 (JuriSupport list_cases/기일 조회 또는 case-index list --upcoming-days 14)
• CSV 사건 인덱스 사용 시: 진행단계 갱신

진행·완료 조건

• 사용자가 승인한 범위에서는 목차 → 초안 → 검증 → 요청한 출력 형식 산출까지 진행한다. 단계별 승인 요청이 따로 있으면 그 지점만 기다린다.
• 인용 검증은 생략하지 않는다. 미확인 근거를 검증 완료로 처리하지 않으며, 필요한 사용자 판단·자료를 구체적으로 묻는다.
• 외부 등록·발송은 실제 대상과 내용에 대한 명시적 요청·승인이 있어야 한다. 기존 승인이 있으면 반복 확인하지 않되 호스트가 요구하는 승인 절차는 따른다.
• Phase 6에서 산출물을 전달하면 작성 작업은 완료다. 법원 제출 완료를 기다리며 세션을 붙잡지 않는다.
• Phase 7은 사용자가 나중에 실제 제출 사실을 알려주고 해당 상태 갱신을 요청했을 때 수행한다.

서면 유형별 분기

각 유형에 맞는 표준 구조는 플레이북 §8 참조.

• 준비서면: ~합니다 / ~입니다 경어체
• 소장: ~합니다 / ~입니다 경어체
• 답변서·의견서·신청서·보정서: ~합니다 / ~입니다 경어체
• 항소·상고이유서: ~합니다 / ~입니다 경어체, 항소·상고 이유 명확히 항목화

모든 소송서류는 ~합니다 / ~입니다 격식체로 통일한다 (플레이북 §9 참조).

Notes

• 이 스킬은 오케스트레이션 스킬이다. 실제 작업은 글로벌 스킬·MCP에 위임한다.
• 검증 단계는 절대 스킵하지 말 것. OCR/hallucination 위험이 가장 큰 단계.
• 보정서는 갑호증 없이 **첨부서류(소명자료)**로만 구성. 서면 유형이 보정서일 때 갑호증 관련 로직을 건너뛴다.
• 증거조사 방법 제안 시: 사실조회보다 공적 기관 문서제출명령 우선 (확정일자, 매매계약서, 금융거래내역, 부동산 소유내역 등 공적 기관이 보유한 기록은 문서제출명령이 더 확실).
• JuriSupport 연동 시: 당사자 확인/등록 → 사건 확인/등록 → 본 업무(서면 작성) 순서 준수. 누락 시 직접 등록 후 진행.