Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Terminology

손실과 계약의 역할을 같은 뜻으로 이야기하기 위해 다음 용어를 사용한다.

지급범위와 반복성

  • 지급범위 — 어떤 진단·치료·상태에서 보험금이 지급되는가. 넓어 보이는 상품명보다 약관의 실제 조건을 본다.
  • 반복성 — 최초 한 번, 제한적 재지급, 연 단위 반복처럼 같은 위험이 되풀이될 때 보험금도 다시 지급되는가.
  • 지급형태 — 사고 시 가입금액 전액을 지급하는 정액형과, 후유장해 지급률처럼 판정등급에 비례해 가입금액의 일부만 지급하는 비례형을 구분한다. 비례형을 가입금액 전액으로 읽지 않는다.

보장 간의 관계

  • 독립 역할 — 다른 담보가 대신하지 못하는 위험을 맡는다.
  • 상호보완 — 같은 사건과 관련되어도 목적이나 지급시점이 다르다.
  • 중첩 — 상당 부분 같은 사건과 같은 공백을 메운다.
  • 낮은 한계보호(low Marginal Protection) — 하나를 더 보유해도 Marginal Protection이 거의 늘지 않는다. 이는 경제적 관찰이며, 아래 REDUNDANT(사실상 중복)와는 다른 축이다 — REDUNDANT는 약관상 지급조정 방식에서만 유도하는 계약 속성이고, 이 항목은 실제 위험 감소분에서 유도하는 경제적 관찰이다. 완전지급형 담보 둘은 REDUNDANT가 아니면서도(동시지급) 경제적으로는 낮은 한계보호일 수 있고, 그 반대도 가능하다.

중첩된 보장을 무조건 중복으로 보지 않는다. 하나씩 뺐을 때와 묶음 전체를 뺐을 때의 손실 변화를 함께 본다.

Trigger Set Inclusion: 지급사유의 중첩(OVERLAP)은 등급형 코드가 아니라 약관이 정의한 지급사유의 CoveredSet(carve-out 포함) 사이의 집합관계에서 유도한다 — 질병 코드범위(KCD 등)는 그 CoveredSet을 표현하는 한 가지 방식일 뿐이며, 지급사유가 진단코드가 아닌 방식(예: 사고 유형, 후유장해 등급표)으로 정의된 담보에도 같은 집합관계 판정을 그대로 적용한다. 질병 담보의 예를 들면, 뇌출혈 ⊂ 뇌졸중 ⊂ 뇌혈관질환, 급성심근경색 ⊂ 허혈성심장질환처럼 한 담보의 KCD 코드범위가 다른 담보의 부분집합이면 그 교집합만큼만 OVERLAP이며, 두 코드범위가 전혀 겹치지 않으면 같은 신체부위·질환군이라도 UNIQUE다.

Payout Coordination: 지급사유가 겹치는 담보라도 REDUNDANT(사실상 중복) 여부는 코드범위 교집합이 아니라 약관상 지급조정 방식에서 유도한다 — 동시지급(각자 전액 지급, OVERLAP이 커도 REDUNDANT 아님) / 선지급차감(먼저 지급된 금액만큼 차감, 실질 중복) / 택일(하나만 선택 지급, 실질 중복)로 나눈다. OVERLAP은 코드범위 교집합에서, REDUNDANT는 이 지급조정 속성에서 각각 유도하며 서로 대신하지 않는다.

보유기간과 자산대체

  • 장기 이전 — 자산이 늘어도 보험으로 계속 넘길 이유가 큰 위험.
  • 전환 가능 — 초기에는 보험이 필요하지만 자산이 충분히 쌓이면 직접 감당할 수 있는 위험.
  • 일시적 필요 — 부채·부양책임처럼 특정 기간에만 큰 위험.
  • Protection Timeline 종료조건 — 해당 위험을 더 이상 보험으로 이전할 필요가 없어지는 시점을 판정하는 명시적 조건(예: Exit Gate 통과, 계약상 종료·전환 시점, Human Capital at Risk의 소멸). 시간에 따른 감쇠함수로 다루지 않는다.
  • Persistent Core Capital(L2-A, 옛 이름 Permanent Floor — household 보호목표의 Minimum Protected Floor와 혼동을 피하려 이름을 바꿨다) — 노년기까지 직접 감당하기 어렵거나 다시 확보하기 어려워 장기 이전을 검토하는 최소 보호자본. 모든 사람에게 양수로 강제하지 않는다.
  • Convertible Excess — 현재의 자산부족·소득·부채·부양책임 때문에 필요하지만 장래 L6가 인수할 수 있는 추가 보호자본.
  • Trigger Durability — 의료기술과 치료환경이 변해도 약관의 지급조건이 맡은 위험을 계속 포착할 가능성.
  • Accidental Coupling — 줄이려는 역할과 계속 필요한 역할이 한 계약의 삭제·감액 조건에 의도치 않게 묶인 상태.
  • Human Capital at Risk — 무사고 경로와 사고 후 경로 사이의 기간별 세후 가계기여 소득 차이. 가용 금융자산으로 합산하지 않는다.
  • Protected Goal — 충격이 와도 지키기로 확인한 가계 기준. Minimum Floor는 최소생활·주거·의무·필수치료처럼 양보할 수 없는 하한이며 Essential 손실의 출처가 된다. 그 위의 희망수준인 Target은 Strategic 목표로 분리한다. 각 목표(goal)는 goal_level(MINIMUM_FLOOR / TARGET)을 가지며, 자산은 그 목표에 귀속(attribution)되는 방식으로 Floor/Target에 배분된다 — goal_level은 목표의 속성이지 자산의 속성이 아니다. 귀속된 목표나 그 목표의 goal_level이 확인되지 않은 자산은 UNVERIFIED로 남기고 전액 Floor로도 전액 가용으로도 가정하지 않는다 — Deployable Reserve의 Strategic View는 이 귀속으로 자산을 Floor/Target에 배치해 보고하지만, Essential 뷰가 빼는 FloorRequirement는 자산 귀속이 아니라 가계 수준의 표현되지 않은 소비 필요로 따로 계산한다.
  • Insurability Option — 현재 건강·계약조건에서 확보한 보장권리를 미래에도 유지할 수 있는 선택권. 아직 남은 중요한 위험과 연결되고 다른 자산·권리로 대체되지 않을 때 의미가 있으며, 근거 없이 원화가치로 환산하지 않는다.
  • Behavioral Persistency — 계약 수, 보험료 변동과 납부·청구·관리 복잡성 아래에서 포트폴리오를 실제로 유지·사용할 수 있는 정도.
  • Recommendation Universe — 비교에 포함한 상품·견적의 범위와 기준일, 포함·제외 및 채널 제약. 후보집합 안의 우열과 시장 전체 우열을 구분한다.
  • Evidence Freshness — 근거의 효력일·관측일·조회일과 재확인 필요상태. 오래됐다는 이유만으로 금액을 0으로 만들지는 않는다.

Longevity-Conditional Consumption Need

고령기 Exit처럼 남은 생존기간의 소비 필요가 유효한 시나리오에서, Deployable Reserve의 FloorRequirement[s,t]가 그 소비만큼 커질 수 있는지를 정하는 값이다 — 항상 존재하는 고정된 가산액이 아니다. 남은 생존기간의 소비를 저량(stock)으로 바꾸는 내부 기간·할인·생존·고갈·연금환산 공식은 두지 않는다(Owner AMEND) — 대신 세 경우로 나누며, 이 경우는 저장된 가계 속성이 아니라 시나리오 s·시점 t마다 다시 정해진다.

연금은 분류가 아니라 산식 안의 차감(netting)이다. public_pension과 연금·연금저축처럼 계속 들어오는 TRANSFER 소득은 FloorRequirement의 산식 자체 안에서, 선언된 Minimum-Floor 소비 금액에서 직접 차감되는 항이다 — 아래 세 경우 분류와는 별개의 메커니즘이며, 그 자체로 어느 경우에 해당하는지를 정하지 않는다. 세 경우는 그 차감 이후에도 남는, 아직 정량화되지 않은 소비 필요를 어떻게 확보하는지에만 적용된다:

  • 경우 A — 그 (연금 등으로 차감하고 남는) 소비가 이미 시나리오 LossFlow에 표현되어 있으면 추가 FloorRequirement를 만들지 않는다 — 표현 규칙이 이미 덮는다.
  • 경우 B — LossFlow에 없지만 상위 Wealth Planning 인터페이스가 provenance·scope·as-of·method를 갖춘 저량(stock)을 공급하면, 그 값을 그대로 소비한다. 이 소비 항목에는 산식의 TRANSFER 소득 차감을 적용하지 않는다 — 공급된 저량이 이 소비 항목의 FloorRequirement 기여분 자리를 그대로 차지하며, 산식이 먼저 잔여액을 계산한 뒤 그 값을 대체하는 두 단계가 아니다. netting은 이미 상위 인터페이스 자신의 method 안에서 이뤄진 것이어야 하며(그 저량은 계속소득을 순(net)으로 반영한 값이어야 한다), Insurance OS는 그 netting을 다시 수행하거나 상위 변환 method를 재현·조용히 대체하지 않는다.
  • 경우 C — 그 소비가 경우 A(LossFlow 표현)에도 해당하지 않으면서 위 조건이 둘 다 없으면 정량적으로 미해결이다. scope가 현물(in-kind) 처리에 대해 침묵하는 경우도 마찬가지로 경우 C다 — 나머지 세 필드가 모두 있어도 scope가 현물 지원의 netting 여부를 선언하지 않으면 경우 B로 인정하지 않는다(단, 경우 A가 이미 성립하면 그 우선이다). 0으로 두지 않고, 다리를 만들지도 않는다 — 근거 부재(UNVERIFIED)가 아니라 자기 사유 코드 FLOOR_REQUIREMENT_NOT_QUANTIFIED로 보고하는 model-completeness 상태다.

연금이 소비를 부분적으로만 감당한다는 사실은 그 자체로 경우 A의 조건이 아니다. 감당되지 못한 잔여분은 위 두 조건(LossFlow 표현, 외부 저량 공급) 중 무엇이 성립하는지로 다시 분류해야 하며, 둘 다 아니면 경우 C로 남는다 — 부분 연금 수급자야말로 이 AMEND가 보호하려는 대상이므로, 잔여분을 조용히 경우 A로 흡수하면 안 된다. 연금이 소비를 전부 감당해 FloorRequirement가 0에 이르는 것(위 차감의 결과)과 ‘경우 A로 분류됨’(표현 규칙 때문)은 서로 다른 이유에서 우연히 같은 결과(추가 FloorRequirement 없음)에 이를 뿐, 같은 사실이 아니다.

FloorRequirement가 이미 표현하는 최소생활 소비와 겹치지 않는다 — 같은 최소생활 소비를 이 항목에서 다시 잡으면 이중계산이다.

손실·재원 흐름의 여섯 유형

아래는 서로 다른 계산 취급을 받는 여섯 가지 금전·경제적 흐름이다. 이름이 비슷해 보여도 섞어 쓰지 않는다 — 특히 FundingFlow와 SettlementFlow, LiquidityBackstop과 FinancialResource는 각각 서로 다른 메커니즘이다.

유형무엇인가예시
LossFlow[s,t,c]사건이 일으킨 경제손실 그 자체(부호 ≥ 0, 사건원인만)입원비·수술비, 소득감소분, 간병비
NeedAdjustment[s,t]사건으로 소멸한 가계 지출 의무 — 필요측 감소이며 재원이 아니다신용생명 정산 뒤 사라진 대출 원리금(L8), 사망자 본인의 생활비 소멸, 장해 채무면제 — 이 셋은 독립적이다. 납입면제는 독립성 원칙을 통과할 때만 해당하며, 자기참조인 국내 소매 납입면제 특약은 대부분 통과하지 못한다
FundingFlow(FundingEdge)손실을 메우는 실제 재원 유입 — 가계 자유현금이 된다실손·정액 보험금(payee=가계), 공적 현금급여, 회사 지원금
SettlementFlow채권자 등 특정 대상에게 직접 가는 제한된 정산 흐름 — 재원이지만 가계 자유현금이 아니다신용생명보험이 채권자에게 직접 지급되는 정산(L8 경우 3a); 초과분만 FundingFlow가 된다
LiquidityBackstop손실을 상쇄하는 재원이 아니라 시점별 현금 문제를 완충하는 신용한도 — 상환의무를 미래로 이전할 뿐이다CONTINGENT_CREDIT(마이너스통장·보험계약대출 등)
FinancialResource소유주·account_type·인출제약·세제 규칙을 가진 보유자산 그 자체 — 가치·haircut·가용성은 이 자산의 고유값이 아니라 시나리오별로 파생되는 관계다예적금·투자자산 등; Eligible Assets는 그 관계를 적용해 시나리오별로 파생한 집합이다(평가 대상 계약 자신의 해지환급금은 제외한다)

NeedAdjustment ≠ FundingFlow(“지출이 사라지는 것은 재원이 생기는 것이 아니다”) — Peak Liquidity Gap이 이미 이 구분을 확정유입 판정에 쓴다. FundingFlow ≠ SettlementFlow도 섞지 않는다 — Settlement은 클래스가 아니라 관계이므로, 채권자에게 직접 가는 지급은 FundingFlow(FundingEdge)가 아니며 초과분만 excess_rule에 따라 FundingFlow가 된다.

대표적인 지급형태는 이 여섯 유형 중 서로 다른 것을 만든다 — 지급형태 이름만으로 어느 유형인지 짐작하지 않는다:

지급형태만드는 것예시
정액형(fixed benefit)지정된 지출항목이 없는 가계 자유현금(FundingFlow)진단비·수술비 정액특약
실손형(indemnity)실제 지출항목·한도에 결부된 재원(FundingFlow)실손의료보험
신용생명형(credit-life)채권자에게 직접 가는 제한된 정산(SettlementFlow)신용생명보험(L8 경우 3a)
면제형(waiver)재원이 아니라 의무 자체의 해소(NeedAdjustment) — 단, 독립성 원칙을 통과할 때만 NeedAdjustment로 센다장해 채무면제(독립적); 자기참조 납입면제는 대부분 통과하지 못한다

Funding Waterfall

Funding Gap은 어느 재원까지 반영했는지에 따라 뜻이 달라지므로 계산단계를 붙인다. 정확한 식과 배분 규칙은 Residual Loss가 정본이며, 여기서는 각 단계가 뜻하는 바만 설명한다.

  • Gross Economic Loss — 사고가 가계에 만드는 의료비, 돌봄비, 소득감소와 추가 필수지출의 전체 규모.
  • Pre-Insurance Funding Gap — 보험을 적용하기 전, 공적 현금급여와 회사 지원 등 비보험 재원을 반영하고 남는 금액.
  • Pre-Reserve Funding Gap — 공적·회사·보험 재원을 반영한 뒤 자산을 쓰기 전에 남는 금액.
  • Reserve Draw — 위 부족액을 메우기 위해 실제로 투입할 수 있는 자산.
  • Final Unfunded Loss — 가용자산까지 사용한 뒤에도 남는 금액.

공적보장 때문에 애초에 가계가 부담하지 않는 금액은 Gross Economic Loss에 넣지 않는다. 같은 재원을 두 번 빼지 않는다.

Scenario-Eligible Benefit

광고상의 가입금액이 아니라, 구체적인 시나리오의 사실과 약관·면책·한도·지급시점을 검증해 지급 적격성을 판정할 수 있을 때 계산한 보험금이다. 제안서나 보장분석표에서 사건과 금액이 연결된 것만으로는 충분하지 않으며, 실제 보험사의 심사나 지급을 보증한다는 뜻도 아니다.

Marginal Protection

특정 담보가 있을 때와 없을 때 가계의 부족액이 얼마나 달라지는지를 본다.

  • Loss Transfer — 보험이 가계부담과 자산소진을 줄인 금액.
  • Solvency Protection — 가용자산으로도 메우지 못할 손실을 보험이 줄인 금액.

담보 하나의 기여와 비슷한 담보 묶음 전체의 기여를 구분한다.

Net Risk Transfer Cost (NRTC)

같은 기간에 앞으로 낼 보험료와 비용에서 보증된 환급·만기금과 남아 있는 계약가치를 뺀 가계 관점의 위험이전 순비용이다.

보험수리적 순보험료나 기대보험금을 뺀 원가가 아니다. 같은 역할의 대안을 비교하고, 그 비용이 실제 손실 감소로 이어지는지 설명하는 데 사용한다.

Underwriting Lock-in

건강 변화로 기존 계약을 없앤 뒤 같거나 더 나은 조건으로 다시 가입하기 어려운 상태다. 현금가치와 별개로 기존 계약이 가진 중요한 권리일 수 있다.

행동과 판단 상태

ADD / KEEP / REDUCE / REPLACE / EXIT는 명령이나 승인이 아니라 검토할 Action Candidate다(계약 라인마다 매긴다). 결정의 진행상태는 하나의 enum이 아니라 서로 다른 세 축으로 본다 — 얼마나 많은 근거가 모였는지는 decision_resolution(D0 < D1 < D2 < D3), 결론을 닫았는지는 decision_disposition(OPEN 검토 중 / RESOLVED 대안이 정해짐 / DEFERRED 이유와 재검토 조건을 가진 채 미룸 / BLOCKED 근거 부족으로 결론 불가), 예산 안에서 지금의 대안 집합이 실행 가능한지는 candidate_set_feasibility(FEASIBLE / FLOOR_INFEASIBLE_UNDER_BUDGET / NOT_DETERMINED)다. 세 축은 서로 덮어쓰지 않는다 — DEFERRED·BLOCKED는 이미 도달한 decision_resolution을 낮추지 않는다. 근거는 충분한데 예산 안에서 Minimum Protected Floor를 채우는 후보가 하나도 없는 상태는 candidate_set_feasibility: FLOOR_INFEASIBLE_UNDER_BUDGET으로 기록하며, decision_disposition을 BLOCKED로 만들지 않는다 — 근거 부족과 예산 부족은 다른 사유이기 때문이다. 부분보호 우선순위와 보험 밖 대안 제시가 이 outcome의 필수 출력이다(보험의 가치를 판단하는 법). 코드만 표시하지 않고 어떤 위험을 얼마나 줄이는지, 비용은 무엇인지, 아직 확인되지 않은 사실이 결론을 바꿀 수 있는지를 함께 설명한다.

분류 코드
개념코드뜻
RepeatabilityR0 / R1 / R2 / R3최초 1회부터 장기간 반복까지의 구조
Coverage RelationshipUNIQUE / COMPLEMENTARY / OVERLAP / REDUNDANT독립·보완·중첩·사실상 중복 관계
Lifecycle TypeP Permanent / C Convertible / T Temporary장기 이전·자산대체 가능·기간 한정 필요

Loss Priority, Coverage Role, Value, Action Candidate, Decision 세 축(decision_resolution/decision_disposition/candidate_set_feasibility), Evidence Confidence 같은 판단 필드는 보험의 가치를 판단하는 법에서 정의한다. 코드는 원문과 계산의 의미를 일관되게 보존하기 위한 것이며, 판단 그 자체를 대신하지 않는다.