### 질문



### 답변

> 지금 질문은 구현 범위의 경계선에 관한 것입니다. 즉, “pre-validator + packet generator만 끝났다”고 말하려면 단순히 Python 파일 두 개가 있는 것만으로 충분한지, 아니면 **입력 계약·중간 산출물·테스트·실행기**까지 포함해야 하는지를 정리하겠습니다.



예. `llm_legal_reasoner.py`와 `mechanical_post_validator.py`를 쓰지 않더라도, **“Mechanical Pre-Validator: Python”과 “Issue Packet Generator: Python” 단계만 완성**되었다고 말하려면 추가로 다음 작업들이 필요합니다.



예. `llm_legal_reasoner.py`와 `mechanical_post_validator.py`를 쓰지 않더라도, **“Mechanical Pre-Validator: Python”과 “Issue Packet Generator: Python” 단계만 완성**되었다고 말하려면 추가로 다음 작업들이 필요합니다.

첫째, **입력 정규화(ETL) 계층**이 필요합니다.
현재 Task A의 기본 입력은 `BO.json`, `client_goal.json`, `Fact_Ledger.json`, `적격피고자제외조건.md`, `사해행위취소청구_청구고려사항.md`, 그리고 선택적으로 `evidence_contradictions.json`으로 정해져 있습니다.
따라서 실제 pre-validator가 돌아가려면, 이 파일들에서 **당사자명, 날짜, 금액, claim_id, evidence_ref, 부동산 식별자, 담보권 객체**를 꺼내어 **통일된 내부 형식으로 정규화하는 코드**가 먼저 완성되어야 합니다.

둘째, **`actio_pauliana_calc_worksheet.json` 생성기**가 실제 데이터에 맞게 완성되어야 합니다.
단순히 빈 템플릿을 만드는 수준이 아니라, `Fact_Ledger.json`과 관련 증거에서 **사해행위 당시 담보권, 변론종결시 존속 담보권, 가압류, 금액, 계약일, 피보전채권 구조**를 채워 넣는 매핑 로직이 필요합니다. 예컨대 `Fact_Ledger.json`에는 박수용의 하나은행·최상수·신용보증기금·국민은행 관련 변제 사실이 이미 구조화되어 있으므로, 이를 담보권·비공제채권 객체로 변환하는 로직이 필요합니다.

셋째, **공통 데이터 계약(contract)과 스키마 관리**가 필요합니다.
즉 다음 파일들의 구조를 확정해야 합니다.

- `normalized_case_bundle.json`
- `actio_pauliana_calc_worksheet.json`
- `pre_validation_report.json`
- `issue_packets.json`

이 스키마들이 고정되지 않으면, 뒤의 `Issue Packet Generator`가 앞의 `Mechanical Pre-Validator` 결과를 안정적으로 소비할 수 없습니다.

넷째, **기계적 rule catalog**가 필요합니다.
즉, 어떤 규칙이 pre-validator에서 순수 코드로 검사되는지를 코드 밖에서도 관리할 수 있어야 합니다.
예를 들면:

- 변론종결시 가액 필수 여부
- 사해행위 당시 담보권 공제 기준
- 존속 담보권 추가 공제
- 가압류 비공제
- 복수 원고 분리 표시
- 송달일 템플릿 혼입 금지

이러한 규칙은 `사해행위취소청구_청구고려사항.md`의 내용을 코드 규칙표로 옮기는 작업입니다. 그 문서는 말소되지 않은 저당권도 공제해야 하고, 일부 변제 후에도 원칙적으로 사해행위 당시 피담보채권액을 기준으로 하며, 복수 채권자의 경우 채권액 비율 안분이 아니라 채권자별 피보전채권액 전액 반환 구조를 취해야 한다고 정리하고 있습니다.

다섯째, **issue taxonomy와 packet assembly 규칙**이 필요합니다.
`Issue Packet Generator`는 단순히 오류를 나열하는 것이 아니라, 이를 다음과 같은 **LLM 질의 단위**로 재구성해야 합니다.

- `lease_deposit_deductibility`
- `undersecured_portion_interpretation`
- `multi_plaintiff_recovery_structure`
- `pre_close_interest_renderability`
- `conservative_assumption_selection`

즉, validation issue를 어떤 packet type으로 묶을지에 관한 **grouping policy**가 별도로 필요합니다.

여섯째, **우선순위 점수화 로직**이 필요합니다.
issue packet을 만든다고 끝나는 것이 아니라, 어느 쟁점을 먼저 LLM에 넘길지를 정해야 합니다.
예컨대 다음 순서가 합리적입니다.

- remedy mode
- undersecured portion
- lease deductibility
- plaintiff별 recovery structure
- drafting style

이 우선순위 기준이 없으면 packet이 많아질수록 토큰과 추론 흐름이 비효율적으로 됩니다.

일곱째, **파일 입출력·오케스트레이션 계층**이 필요합니다.
즉, 실제 파이프라인에서 다음 순서를 자동 실행하는 runner가 있어야 합니다.

- 입력 읽기
- 정규화
- worksheet 생성
- pre-validation
- report 저장
- issue packet 생성
- packet 저장

단순히 클래스 정의만 있고 실행기(run script, CLI, pipeline task)가 없으면 “과정이 완성되었다”고 보기 어렵습니다.

여덟째, **테스트와 골든 데이터셋**이 필요합니다.
최소한 다음 테스트는 있어야 합니다.

- 정상 입력에서 worksheet 생성 성공
- 핵심 필드 누락 시 blocking issue 생성
- 가압류가 공제 대상으로 잘못 들어가면 오류 검출
- 복수 원고 사건에서 issue packet이 원고별로 분리되는지
- relief_summary에 “소장 부본 송달” 문구가 섞이면 style issue가 생성되는지

이 테스트가 없으면 두 모듈이 “작성되었다”고는 말할 수 있어도, “완성되었다”고는 하기 어렵습니다.

아홉째, **로그·에러처리·상태관리**가 필요합니다.
현재 Task A 자체도 읽기 실패 시 1회 재시도, 그 후 warning 처리, 불명확하면 `null / 불명 / [증거공백]`으로 남기라는 운영 규칙을 갖고 있습니다.
따라서 pre-validator와 packet generator도 같은 철학을 따라야 합니다.

열째, **실제 stage 2 파이프라인과의 연결 수정**이 필요합니다.
현재 Task A는 기본적으로 `evidence_indexed.json`을 읽지 않도록 되어 있습니다.
그런데 pre-validator 설계는 사실상 `evidence_indexed.json` 또는 그에 준하는 구조화 증거 카탈로그를 필요로 합니다. 따라서 다음 둘 중 하나가 추가로 필요합니다.

- Task A의 입력 파일 목록을 수정하여 `evidence_indexed.json`을 포함시키거나,
- 별도의 pre-stage에서 `normalized_case_bundle.json`을 생성하여 Task A에 넘기는 구조로 바꾸는 작업

정리하면, `llm_legal_reasoner.py`와 `mechanical_post_validator.py`를 제외하고도, **pre-LLM 단계 완성**을 위해 필요한 추가 작업은 다음 다섯 묶음입니다.

- **입력 정규화 및 worksheet 생성**
- **공통 JSON contract / schema 확정**
- **deterministic rule catalog 및 issue taxonomy 확정**
- **runner / CLI / 파일 입출력 오케스트레이션**
- **테스트, 로그, 에러처리, pipeline 연결 수정**

즉, Python 파일 두 개를 쓰는 것만으로는 부족하고, **그 두 모듈이 실제 stage 2 입력 구조를 받아 안정적으로 `issue_packets.json`까지 산출하는 운영 가능 상태**까지 갖추어야 “Mechanical Pre-Validator”와 “Issue Packet Generator” 단계가 완성되었다고 평가할 수 있습니다.