원하시면 다음 단계로, 제가 이 결론을 바로 실무 문안으로 바꾸어 **“소장용 청구취지/청구원인 표현 템플릿”**과 **“준비서면에서의 금액 보정 템플릿”**을 각각 사해행위취소+가액배상형, 사해행위취소+등기말소형으로 나누어 작성하겠습니다. 4. 정리된 결론 대한민국 법조실무와 공식 법원을 통해 확인되는 기준을 종합하면, “변론종결시”는 소장 작성 시점에 미리 적어 넣어야 하는 날짜가 아니라, 법원이 최종적으로 적용하는 평가기준시점입니다. 그러므로 소장이나 초기 준비서면에서 그 날짜를 억지로 확정하려 하지 말고, 청구취지는 현재 입증 가능한 범위에서 특정하되, 감정과 보강증거에 따라 변론종결 전까지 수정하는 것이 가장 합리적입니다. 따라서 실무상 권고는 다음 두 줄로 요약됩니다. 가액배상형은 “잠정 특정액으로 제기 → 감정 신청 → 변론종결 전 청구취지 변경으로 최종화”가 가장 안전합니다. 원물반환형은 “처음부터 취소 대상 행위와 등기를 정밀하게 특정 → 필요 시에만 예비적 가액배상 추가”가 가장 안전합니다. ------------------------------------------------------------------------ # 사해행위취소 가액배상 계산식 missing item - 변론종결시 시가 입력 - C-005, C-006에만 market_value_at_close: 500,000,000원이라는 숫자가 있을 뿐, - 그 값이 어느 날짜의 평가인지, 그것이 정말 변론종결시인지, 어떤 증거에서 왔는지 식별 불가 - 게다가 JSON 내부에서는 runtime_inputs.close_of_arguments_date.required가 true인데, 하단 validation.required_runtime_inputs.close_of_arguments_date는 false로 기재되어 있어, 스키마 내부의 required 판단 자체도 서로 충돌 - beneficiary_gain_support도 아직 충분히 정제되지 않았습니다. C-005, C-006은 명목이전가액 4억 3천만 원과 인수채무 3억 3천만 원을 제시하지만, 같은 파일의 consideration_breakdown은 “임대보증금 인수 1억, 근저당채무 인수”라고 되어 있고, 별도의 선순위 담보권 피담보채권액 합계는 3억 5천만 원으로 보입니다. 즉, 4억 3천만 원 매매, 임차보증금 1억, 선순위 담보 3억 5천, 인수채무 3억 3천이라는 숫자들이 하나의 정합적인 산식으로 곧바로 맞물리지 않습니다. 이것은 계산 엔진의 문제라기보다, C-### 파일이 수익자 이익의 각 구성요소를 충분히 분해하지 않은 탓입니다. assumed_debt_amount가 무엇을 포함하고 무엇을 제외하는지, beneficiary_preexisting_claim_amount나 released_encumbrance_amount가 없는 이유가 무엇인지 명시되어야만 안정적인 가액배상 계산이 가능합니다. - 원고별 피보전채권 측면에서도 입력 부족이 있습니다. 계산 엔진은 plaintiff_claim_snapshots 또는 원고별 preserved_claim_principal / preserved_claim_interest_until_close / preserved_claim_total을 산정하려면, 최소한 사해행위 당시 원금, 담보포섭분, 무담보분, 이율, 지연손해금 기산점 같은 스냅샷이 필요하다고 전제합니다. 우방캐피탈 청구들(C-003, C-005, C-007, C-009)은 대출원금 10억, 사해행위 당시 총채권 12억 6천만 원, 월 0.5% 약정이자, 월 1% 지연손해금률이 어느 정도 드러나 있어 그나마 계산 가능성이 있습니다. 그러나 우방신용 계열(C-004, C-006, C-008, C-010)은 대위변제 2억 2천만 원 사실 자체에 증거 링크가 비어 있고, 이율이나 지연손해금 구조도 충분히 구조화되어 있지 않습니다. 따라서 이 네 청구에 대해서는 가액배상 계산 이전에 피보전채권 총액 자체의 구조화가 부족합니다. ## 항목별 개선사항 첫째, 입력 경로를 C-###_claim_information.json 기준으로 재정의해야 합니다. 현재 엔진은 Fact_Ledger와 evidence_indexed를 기준 입력으로 상정하지만, 사용자가 실제로 운용하려는 파일은 C-###_claim_information.json입니다. 따라서 공식 입력층에 최소한 facts[].legal_calculation_object, facts[].evidence_links[].actio_pauliana_support, facts[].fact_actio_support.actio_pauliana_support를 추가해야 합니다. 그렇게 하지 않으면 엔진은 현재 파일들에서 필요한 actio support를 직접 읽지 못합니다. 둘째, claim-level canonical field를 신설해야 합니다. 특히 fraudulent_act_date, asset_id, property_label_for_schedule, target_registry_office, target_receipt_no, support_target_fact_id, support_applies_to_asset 같은 필드를 claim 상위 레벨에 두어, 파일 내부의 복수 fact 중 어느 항목이 목적물 관련 핵심 사실인지 엔진이 확정적으로 알 수 있어야 합니다. 지금처럼 fact별로 후보를 흩뿌리면, C-003처럼 서로 다른 날짜가 동시에 들어온 사건에서 오작동이 발생합니다. 셋째, 자산별 스코핑이 강제되는 구조로 바꿔야 합니다. 임차보증금, 가압류, 담보권, 시가 후보는 반드시 asset_id 또는 등기목적물 식별자와 연결되어야 합니다. 그렇지 않으면 우방캐피탈 계열 사건에 반복적으로 등장하는 임차보증금 1억 원 후보가 장미아파트, 주공아파트, 김포 토지 중 어느 자산에 귀속되는지 판별할 수 없습니다. 계산 엔진의 candidate table에는 asset_id가 이미 설계되어 있으므로, Task_D 출력에도 같은 식별자를 강제해야 합니다. 넷째, 가액배상 전환 요건을 직접 판정하는 필드가 필요합니다. 규칙상 담보권 사후 소멸, 전득자 선의, 법률상 불능, 사실상 불능, 목적물 회복 불가 여부가 있어야 가액배상을 검토할 수 있으므로, is_value_compensation_exception_triggered, exception_type, reason_fact_ids, encumbrance_released_after_transfer, transferee_good_faith, restoration_legal_impossibility, restoration_factual_impossibility 같은 필드를 claim-level metadata로 둬야 합니다. 현재 legal_meta_fields에는 is_value_compensation_exception_triggered가 있지만 전부 null인 상태이고, 이를 채울 실제 입력 구조가 없습니다. 다섯째, 변론종결시 시가 입력을 날짜·출처와 함께 분해해야 합니다. market_value_at_close라는 단일 문자열만으로는 부족합니다. candidate_amount, valuation_date, basis_type, evidence_refs, distance_to_close_days를 채울 수 있도록, claim 파일 자체가 여러 valuation candidate를 저장해야 합니다. 최소한 C-005, C-006의 5억 원 값이 언제의 평가인지, 어떤 증거에서 나온 것인지가 추가되어야 합니다. 여섯째, 수익자 이익 구성요소를 숫자 단위로 완전히 분해해야 합니다. beneficiary_gain_support에는 nominal_transfer_value, assumed_debt_amount, beneficiary_preexisting_claim_amount, released_encumbrance_amount, other_positive_component, other_negative_component, 그리고 각 항목의 포함/제외 근거가 별도로 들어가야 합니다. 특히 C-005, C-006의 박수용 사건처럼 인수보증금, 인수채무, 선순위 담보, 매매대금이 서로 엇갈릴 때는, assumed_debt_amount 하나로는 계산 논리를 재현할 수 없습니다. 일곱째, 원고별 피보전채권 snapshot을 명시적으로 생성해야 합니다. 지금은 일부 fact의 legal_calculation_object에 흩어져 있는 원금·이자율·만기일 정보를 계산 엔진이 재조립해야 하는데, 이는 불안정합니다. plaintiff_claim_snapshots를 claim 파일 안에서 직접 채워 넣고, principal_existing_at_fraudulent_act, secured_portion_at_fraudulent_act, unsecured_portion_at_fraudulent_act, contractual_interest_rate, default_interest_rate, interest_start_date, amount_as_of_close_of_arguments를 명시해야 합니다. 우방신용 계열 사건은 특히 이 부분을 보강하지 않으면 가액배상 상한 계산 자체가 흔들립니다. 여덟째, 전득자·근저당권설정형 사건을 위한 별도 서브엔진 또는 분기 로직이 필요합니다. C-009, C-010처럼 전득자 또는 담보권설정이 문제되는 경우는 단순 소유권이전형 가액배상 엔진으로 처리하기 어렵습니다. 최소한 downstream_right_type, secured_cap_amount, actual_secured_debt_at_act, registration_kind, transferee_bad_faith, beneficiary_vs_transferee_liability_mode 같은 필드를 추가하고, 경우에 따라서는 actio_pauliana_calc_v2를 그대로 확장하기보다 “근저당권설정 사해행위용 계산·문안 모듈”을 분리하는 것이 더 안전합니다. 아홉째, validation 스키마의 required 판정을 정합화해야 합니다. 현재 runtime_inputs.close_of_arguments_date.required는 true인데, validation.required_runtime_inputs.close_of_arguments_date는 false입니다. 이것은 템플릿 내부의 규범 충돌입니다. 최소한 “실계산에 필수인 값”과 “초기 템플릿 상태에서 아직 미입력인 값”을 같은 boolean으로 쓰지 말고, is_required_by_design, is_present_at_runtime, is_blocking_if_missing처럼 역할을 분리해야 합니다. 열째, Task_D 단계에서 claim 파일을 더 풍부하게 생성하도록 수정해야 합니다. 현재 Task_D는 단순히 claim_id, parties, source_fact_ids, facts[] 아래 원자료를 묶어둘 뿐, 가액배상 계산에 필요한 claim-level 정규화 결과를 생성하지 않습니다. 즉, 계산 엔진이 가장 어려운 정규화 업무를 모두 후단에서 떠안고 있습니다. Task_D에서 이미 canonical_asset, canonical_fraudulent_act, remedy_mode_candidate, value_compensation_candidate, plaintiff_claim_snapshot, beneficiary_gain_components, encumbrance_timeline, valuation_candidates를 함께 생성하면 전체 파이프라인이 훨씬 안정됩니다. 따라서 최종 판정은 다음과 같습니다. actio_pauliana_calc_v2.json은 가액배상 계산을 위한 일반 계산식의 설계로서는 우수하고, 사해행위취소청구 작성규칙과도 큰 방향에서 합치한다. 그러나 현재의 C-003~C-010 개별 claim 파일들에 대해, 그것만으로 곧바로 적용 가능한 필요충분한 계산엔진이라고 보기는 어렵다. 현재 상태에서 실무적으로 계산 가능한 범위는 C-005, C-006의 일부 시나리오에 한정되며, 그마저도 최종 확정에는 필수 입력이 빠져 있다. 나머지 청구들은 아예 가액배상 사안이 아닐 가능성이 크거나, 다른 유형의 사해행위취소 구조이므로, v2 엔진을 직접 적용하는 것은 구조상 부적절합니다. ----------------------------------------------------------------------- # 가액배상 선택 자체를 위한 전제 항목 1. 사건 식별 항목 2. 당사자 구조 항목 3. 사해행위 유형 항목 4. 목적물 특정 항목 5. 가액배상 전환 여부 판단 항목 6. 소송운용 항목 ------------------------------------------------------------------------- 대한민국 법조실무와 공식 법원을 통해 확인되는 기준을 종합하면, “변론종결시”는 소장 작성 시점에 미리 적어 넣어야 하는 날짜가 아니라, 법원이 최종적으로 적용하는 평가기준시점입니다. 그러므로 소장이나 초기 준비서면에서 그 날짜를 억지로 확정하려 하지 말고, 청구취지는 현재 입증 가능한 범위에서 특정하되, 감정과 보강증거에 따라 변론종결 전까지 수정하는 것이 가장 합리적입니다. 따라서 실무상 권고는 다음 두 줄로 요약됩니다. 가액배상형은 “잠정 특정액으로 제기 → 감정 신청 → 변론종결 전 청구취지 변경으로 최종화”가 가장 안전합니다. 원물반환형은 “처음부터 취소 대상 행위와 등기를 정밀하게 특정 → 필요 시에만 예비적 가액배상 추가”가 가장 안전합니다. 원하시면 다음 단계로, 제가 이 결론을 바로 실무 문안으로 바꾸어 **“소장용 청구취지/청구원인 표현 템플릿”**과 **“준비서면에서의 금액 보정 템플릿”**을 각각 사해행위취소+가액배상형, 사해행위취소+등기말소형으로 나누어 작성하겠습니다. ------------------------------------------------------------------------- 제1안 — 가장 안전한 기본형 부동산 사해행위 사건이라면, 특별한 예외사유가 명백하지 않은 한 주위적으로 취소 + 말소등기, 예비적으로 가액배상을 둡니다. 가액배상 금액은 소장 제출 당시 확보 가능한 보수적 산정액으로 특정하고, 청구원인에서는 감정 및 증거조사를 통해 금액을 정정·확장할 수 있음을 구조적으로 열어 둡니다. 이것이 원상회복 원칙과 청구취지 특정 원칙을 함께 만족시키는 방식 제2안 — 처음부터 가액배상형이 불가피한 경우 전득자 선의, 담보권 사후 소멸, 경매·배당으로 인한 현물회복 불능 등으로 가액배상형이 사실상 불가피하다면, 소장에는 현재 증거로 지지 가능한 금액을 일단 특정하여 적고, 동시에 감정신청을 하여 변론종결 전에 최종 금액으로 수정 -------------------------------------------------------------------------- ---------- | 사용 | ---------- <반영해야할_정보> 가액배상형이 불가피한 경우에는 전득자 선의, 담보권 사후 소멸, 경매·배당으로 인한 현물회복 불능 등으로 가액배상형이 사실상 불가피하다면, 소장에는 현재 증거로 지지 가능한 금액을 일단 특정하여 적고, 동시에 감정신청을 하여 변론종결 전에 최종 금액으로 수정하는 것이 합리적이다. 소장 단계의 가액배상 금액은 ‘잠정 특정액’으로 제시하는 것이 가장 실무적입니다. 그 잠정액은 통상 (a) 최근 감정가, (b) 공시가격·시가표준액·실거래자료 등 현재 확보 가능한 객관자료, (c) 선순위 담보권과 공제항목을 반영한 보수적 금액에 기초하여 산정하고, 청구원인에서는 “정확한 가액은 감정결과와 변론종결시 권리상태를 반영하여 보정한다”는 취지로 정리하는 방식이 합리적. 가액배상 금액은 소장 제출 당시 확보 가능한 보수적 산정액으로 특정하고, 청구원인에서는 감정 및 증거조사를 통해 금액을 정정·확장할 수 있음을 구조적으로 열어 둡니다. 이것이 원상회복 원칙과 청구취지 특정 원칙을 함께 만족시키는 방식이다. 변론종결시 시가 입력을 날짜·출처와 함께 분해해야 합니다. market_value_at_close라는 단일 문자열만으로는 부족합니다. candidate_amount, valuation_date, basis_type, evidence_refs, distance_to_close_days를 채울 수 있도록, claim 파일 자체가 여러 valuation candidate를 저장해야 합니다. 지금까지 네가 제시한 답변을 바탕으로 actio_pauliana_calc_v3.json과 mortgage_fraudulent_act_module_v1.json의 실제 JSON 초안을 작성하라. 단, 아래에 초안 작성 시 반드시 반영해야 할 정보(<반영해야할_정보>)들을 정리하였다. 이 요구사항들은 위에서 네가 제시한 답변들 중 일부를 발췌한 것이다. 변론종결 시 시가 입력을 위한 현실적 조건을 반드시 반영하여 초안을 작성하라. ----------------------------------------------------------------- ------------ | 사용 정보 | ------------ 샘플 인스턴스 JSON 4개를 생성했습니다. 파일: * [C-005_actio_pauliana_calc_v3_instance.json](sandbox:/mnt/data/C-005_actio_pauliana_calc_v3_instance.json) * [C-006_actio_pauliana_calc_v3_instance.json](sandbox:/mnt/data/C-006_actio_pauliana_calc_v3_instance.json) * [C-009_mortgage_fraudulent_act_module_v1_instance.json](sandbox:/mnt/data/C-009_mortgage_fraudulent_act_module_v1_instance.json) * [C-010_mortgage_fraudulent_act_module_v1_instance.json](sandbox:/mnt/data/C-010_mortgage_fraudulent_act_module_v1_instance.json) 반영 방식은 다음과 같습니다. * `C-005`, `C-006`은 `filing_provisional` 단계의 **잠정 특정액 구조**로 채웠습니다. * `변론종결시`는 아직 특정할 수 없다는 전제를 유지하여 `close_of_arguments_date.value`와 `final_close_selected`는 비워 두었습니다. * 대신 `market_value_close_candidates`에는 **소장 단계 placeholder 후보**를 두고, `valuation_date`, `basis_type`, `evidence_refs`, `inference_note`를 분해하여 넣었습니다. * `C-009`, `C-010`은 현재 자료상 **근저당권설정계약 취소 + 근저당권설정등기 말소**가 기본 remedy라는 점을 반영했습니다. * 4개 파일 모두 `manual_review_required: true`로 두었고, 누락 입력과 다음 보강조치를 `output_blocks.internal_reasoning_notes` 및 `validation.validation_warnings`에 넣었습니다. 유의하실 점은 다음과 같습니다. * `C-005`, `C-006`의 5천만 원은 **소장 단계 잠정 특정액**입니다. 최종 확정액이 아닙니다. * `C-006`은 source 자체의 증거 공백 때문에 이자 부분을 보수적으로 처리했습니다. * `C-009`, `C-010`은 금전구제 블록도 틀은 채워 두었지만, 현재 자료상 주된 출력은 말소형입니다. * 일부 값은 source가 직접 주지 않아 **보수적 추정 또는 placeholder**로 넣었고, 그 부분은 JSON 내부 `basis`, `inference_note`, `validation_warnings`에 명시했습니다. 다음 단계로는 이 4개 인스턴스를 다시 입력으로 삼아, 각 파일별 **실제 청구취지(relief_summary)와 청구원인(cause_summary)의 완성형 문안**까지 생성하는 작업이 가장 자연스럽습니다. --------------------------------------------------------------------- ----------- | 평가 의견 | ----------- 사해행위취소 청구 시 `원물반환(말소등기 혹은 등기말소) vs. 가액배상` 구분하여 - actio_pauliana_calc_v3.json - mortgage_fraudulent_act_module_v1.json 중 1개를 골라서 사용해야 한다. 즉, C-###별로 사해행위취소 청구 유형을 특정한 후 두 템플릿 중 1개만 골라서 사용할 수 있도록 해야 함 ------------ | 추가적 작업 | ------------ 사해행위취소 청구 청구취지/청구원인 작성 작업 구상 C-###별로 1. 원물반환 vs 가액배상 결정 2. 1번 결과에 따라 어떤 정보를 사용해서 템플릿을 채워넣을 것인가를 결정 3. 어떤 정보 후보(evidence_actio_support.json, fact_actio_support.json, evidence_indexed.json, Fact_Ledger_base.json) 3.1 evidence_indexed.json의 필수성 여부 판단 -> 불필요 시 사용하지 말 것 4. -------------------- Stage 2 - Task_B 업데이트 입력 - client_goal.json - claim_identification_view.json 추가입력: - client_meeting.md 소스 중요도 client_meeting.md > client_goal.json > claim_identification_view.json Task_B 프롬프트 업데이트 -> common prefix 바꾸지 마라 모범답안 예시: claims_identified_ex.json Legal_Agent_V4_v6.yaml의 `stage1_사건개요파악`을 실행하여 아래 결과물들을 얻었다: - client_goal.json - evidence_indexed.json - evidence_event_candidates.json - BO.json - actio_case_signals.json - evidence_actio_support.json - Fact_Ledger_base.json - fact_actio_support.json 이제 `stage 2`를 실행하려고 한다. Stage 2 작업은 Legal_Agent_V4_v6.yaml의 `stage2_청구개요서작성` 프롬프트를 실행하지 않고, 대신 `stage_1_claim_identification_text_v1.yml`을 실행한다. 현재, `stage_1_claim_identification_text_v1.yml`에는 총 3개의 작업(Task_A, Task_B, Task_C)이 존재한다. yml을 실행시켜 얻은 결과물들은 - claim_identification_view.json - claims_identified.json - claims_identified_case_type.json 이다. Task_B와 Task_C의 프롬프트는 GPT-5.4의 caching을 공유하는 형태로 작성되어 있다. Task_B의 목표는 입력파일들로부터 원고가 주장할 수 있는 청구권들을 식별하는 것이다. 입력파일 정보로 Task_A의 결과물인 `claim_identification_view.json`과 stage 1의 결과물인 client_goal.json이다. `stage_1_claim_identification_text_v1.yml`를 실행하여 얻은 결과물 파일인 `claims_identified.json`에는 부족한 점이 존재한다. 모범답안이라고 할 수 있는 `claims_identified_ex.json`은 2개의 추가적인 청구권들(C-009, C-010)을 식별하였다. 그런데, 현재의 결과에는 그 청구권들이 식별되지 않았다. 따라서, Task_B의 실행 결과물이 `claims_identified_ex.json`이 제시하는 것처럼 도출될 수 있도록, 좀 더 많은 정보를 주입하기 위해서 Task_B의 입력파일을 확장한다. 구체적으로는 client_meeting.md (stage 1 시작 시 입력하는 최초 고객 상담 문서)을 추가하고자 한다. 그리고 Task_B 작업 시, 소스 파일 우선 순위는 client_meeting.md > client_goal.json > claim_identification_view.json 이다. Task_B의 는 그대로 두고, 나머지 내용을 변화시켜 client_meeting.md를 입력 파일로 받아서 `claims_identified_ex.json`처럼 결과가 도출될 수 있도록 프롬프트를 새로 작성하라. 작성한 프롬프트를 `stage_1_claim_identification_text_v1.yml`의 Task_B block을 대체하여 `stage_1_claim_identification_text_v2.yml`로 생성하라. 단, `stage_1_claim_identification_text_v1.yml`은 삭제하면 안된다.