상품과 계약 — 보험료는 계산된다

한 줄 요약

보험 상품은 위험률·이율·사업비 세 가정으로 가격이 정해지고, 계약은 청약·심사·유지·갱신·해지·실효의 생애주기를 돈다 — 보험 시스템의 데이터는 이 두 축의 교차점이다.

왜 이 지식이 필요한가

보험사에 들어간 엔지니어가 처음 듣는 말은 "이 상품은 제3보험이라 생·손보 둘 다 판다", "순보험료와 부가보험료를 나눠 저장해야 한다", "실효된 계약은 해지가 아니다" 같은 것입니다. 상품과 계약의 구조를 모르면 계약 테이블의 상태 컬럼이 왜 열 가지가 넘는지, 보험료 컬럼이 왜 셋으로 쪼개져 있는지 이해할 수 없습니다.

생명보험·손해보험·제3보험

국내 보험업은 세 갈래입니다.

Life          Covers a person's survival or death. Whole life, term, annuity, savings. Fixed-amount benefits.
Non-life      Covers loss to property. Auto, fire, liability, marine. Indemnity: pays the actual loss.
Third sector  Illness, injury, long-term care. Covers people, but can be indemnity or fixed-amount,
              so both life and non-life insurers sell it.

이 구분은 규제와 회계에 그대로 이어집니다. 정액 보상은 얼마를 줄지 계약 때 정해지고, 실손 보상은 사고가 나야 금액이 정해집니다. 시스템에서 전자는 가입금액 컬럼이 핵심이고, 후자는 손해 사정 절차가 핵심입니다.

보험료는 계산된다

보험료는 세 가정에서 나옵니다. 예정위험률(얼마나 죽거나 다치는가 — 생명표·경험률), 예정이율(받은 보험료를 굴려 얼마를 벌 것인가), 예정사업비율(팔고 유지하는 데 얼마가 드는가). 앞의 둘로 계산한 것이 순보험료이고, 사업비를 얹은 것이 고객이 내는 영업보험료입니다. 그 차이가 부가보험료입니다.

gross premium = net premium + loading
net premium   = risk premium (PV of death/accident benefits) + savings premium (PV of maturity/surrender refunds)
loading       = acquisition cost + maintenance cost + collection cost

정기보험처럼 환급이 없는 상품은 저축보험료가 없고, 종신·저축성 상품은 저축보험료 비중이 큽니다. 시스템이 보험료를 셋으로 쪼개 저장하는 이유는 나중에 준비금·해지환급금·사업비 실적을 각각 따로 계산해야 하기 때문입니다.

예정이율이 낮아지면 미래 지급액의 현재가치가 커져 보험료가 오릅니다. 금리가 내려갈 때 보험사가 예정이율을 내리고 보험료를 올리는 이유입니다.

계약의 생애주기

Application    The customer applies and discloses health and occupation.
Underwriting   The insurer assesses the risk: accept, decline, or accept with conditions (rating, exclusion).
In force       The policy takes effect when the first premium arrives; premiums are paid each period.
Renewal        Renewable riders re-price at set intervals using updated risk rates.
Surrender      The customer ends the policy. Any surrender value is paid out.
Lapse          Unpaid premium past the grace period suspends coverage. It can be reinstated within a set period.

실효와 해지는 다릅니다. 해지는 고객의 의사이고 실효는 미납의 결과이며, 실효는 부활이 가능합니다. 언더라이팅 결과는 계약 조건이 됩니다 — 같은 상품이라도 할증된 계약은 보험료가 다르고, 부담보 계약은 특정 부위의 사고를 보상하지 않습니다. 이 조건이 계약 데이터에 남아 있어야 나중에 청구가 왔을 때 지급 여부를 판단할 수 있습니다.

상품이 바뀌는 속도가 시스템 설계를 정한다

보험 시스템에서 가장 자주 바뀌는 것은 코드가 아니라 상품이다. 새 특약이 나오고, 요율이 바뀌고, 판매가 중지된다. 그 변화를 코드로 받으면 배포가 상품 출시 일정에 묶인다.

상품을 데이터로 다룬다. 담보·요율·인수 규칙을 표로 두고, 코드는 그 표를 해석하는 엔진이 된다. 새 상품은 표에 행을 넣는 일이 되고, 배포 없이 나갈 수 있다. 대신 표가 틀렸을 때 잡아 줄 검증이 코드보다 더 중요해진다.

날짜가 붙지 않은 요율은 없다. 계약은 체결 시점의 규칙으로 유지되므로, 오늘의 요율로 어제 계약을 다시 계산하면 안 된다. 모든 규칙 행에 적용 시작일과 종료일을 두고, 조회할 때 기준일을 반드시 함께 넘긴다. 기준일을 기본값으로 오늘로 두는 함수는 언젠가 과거 계약을 오늘 규칙으로 계산한다.

계약은 상태 기계다. 청약, 인수 심사, 성립, 유지, 실효, 부활, 해지, 만기. 이 전이를 코드 곳곳의 if 로 흩어 놓으면 어느 상태에서 무엇이 가능한지 아무도 말할 수 없게 된다. 전이 표를 한곳에 두고 그것만 보게 한다.

정정은 되돌리는 것이 아니라 새 버전이다. 계약 내용이 바뀌면 옛 내용도 남아야 한다. 어느 시점에 어떤 조건이었는지가 곧 지급 여부를 가르기 때문이다. 계약 테이블을 갱신하는 대신 변경 이력을 쌓고 현재 상태를 계산하는 구조가 오래 간다.

개인정보의 무게가 다르다. 병력, 진단명, 수익자 관계는 민감정보다. 조회 로그를 남기고, 화면에서는 마스킹하고, 분석계로 내보낼 때는 비식별 처리를 거친다. "개발할 때만 잠깐" 운영 데이터를 복사하는 관행이 사고로 이어지는 자리다.

실무에서 진짜 중요한 것

첫째, 가정은 상품 정의의 일부입니다. 위험률표·예정이율·사업비율은 상품·판매 시점마다 다르고, 계약은 가입 당시의 가정으로 평생 계산됩니다. 가정을 코드에 박으면 옛 계약을 계산할 수 없게 됩니다.

둘째, 상태는 저장된 값이 아니라 날짜에서 계산되는 값입니다. 실효는 미납일과 유예 규칙에서 나오고, 만기는 만기일에서 나옵니다. 상태 컬럼은 배치가 써 넣은 사본이고, 사본은 틀릴 수 있습니다.

셋째, 보험료는 1원까지 재현되어야 합니다. 어느 가정을 어느 순서로 어떻게 반올림했는지가 상품 정의서에 있고, 시스템은 그 순서를 그대로 따라야 합니다.

다음 실습에서 가상의 생명표와 예정이율로 정기보험 순보험료를 직접 계산하고, 사업비를 얹어 영업보험료를 만듭니다.