Liti-agent-Development/Default_Agent_청구취지기재방법/질문_답변_사취연구_가액배상_validator.md

질문

답변

지금 질문은 구현 범위의 경계선에 관한 것입니다. 즉, “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” 단계가 완성되었다고 평가할 수 있습니다.