계리와 회계·규제 — 미래의 약속을 지금 얼마로 잡는가

한 줄 요약

보험 회계는 "미래에 줄 돈을 지금 얼마로 잡느냐" 의 문제이고, 책임준비금(원가)·IFRS17 부채(시가)·K-ICS 지급여력(자본) 세 층이 같은 계약을 다른 숫자로 본다 — 여기에 보험업법과 개인정보 규제가 IT 요구를 얹는다.

왜 이 지식이 필요한가

보험사 결산 시스템 요구사항에는 "준비금 산출 배치", "IFRS17 엔진 연동", "K-ICS 산출 데이터 마트", "민감정보 암호화" 같은 말이 나옵니다. 계리팀이 쓰는 이 말들의 뼈대를 모르면 데이터 항목이 왜 그렇게 많은지, 왜 같은 계약의 부채가 화면마다 다른지, 왜 결산 때마다 시스템이 밤새 도는지 이해할 수 없습니다.

책임준비금 — 원가로 잡는 부채

보험사는 오늘 받은 보험료로 수십 년 뒤 약속을 지킵니다. 그 약속을 위해 지금 쌓아 두는 돈이 책임준비금입니다. 정기보험의 보험료적립금은 "앞으로 줄 급부의 현재가치 − 앞으로 받을 순보험료의 현재가치" 입니다. 가입 초기에는 받을 보험료가 많이 남아 작고, 뒤로 갈수록 커집니다. 계산에 쓰는 가정은 가입 당시의 위험률·예정이율입니다. 그래서 원가 기준이라 부릅니다.

준비금에는 다른 조각도 있습니다. 아직 지급하지 않은 청구를 위한 지급준비금(개별추산액과 IBNR), 아직 기간이 안 지난 보험료를 위한 미경과보험료적립금 등입니다. 결산 배치는 이 조각들을 계약·담보 단위로 계산해 합칩니다.

IFRS17 — 시가로 잡는 부채

2023년부터 적용된 IFRS17 은 부채를 지금의 가정으로 평가합니다.

BEL   Best estimate liability. Future cash flows (benefits + expenses − premiums) valued at current discount rates.
RA    Risk adjustment. Compensation for uncertainty in those cash flows. The insurer chooses the method.
CSM   Contractual service margin. Unearned profit left after BEL + RA. Held as a liability, released as profit over the coverage period.

CSM 이 핵심입니다. 계약을 팔자마자 이익을 다 인식하지 못하게 막고, 서비스를 제공한 만큼만 매 기간 풀어 줍니다. 반대로 BEL + RA 가 보험료보다 크면 CSM 은 0 이고 그 차이는 손실요소로 바로 손실이 됩니다. 결산 시스템에는 계약 그룹별로 CSM 잔액을 굴리는 롤포워드가 필요하고, 가정이 바뀔 때마다 CSM 이 조정됩니다.

K-ICS — 자본으로 보는 건전성

지급여력제도는 회사 전체가 극단적 손실을 견딜 수 있는지를 봅니다. 보험·시장·신용·운영 위험을 각각 자본 요구량으로 환산하고, 위험끼리 동시에 터지지는 않는다는 가정으로 상관계수를 적용해 합칩니다. 가용자본 ÷ 요구자본이 지급여력비율이고, 법정 최저는 100% 이며 감독 당국은 그보다 높은 수준을 권고합니다(구체 수치는 시점과 제도에 따라 다릅니다). IT 에는 "자산·부채·계약을 위험 요인별로 쪼갠 데이터 마트" 로 내려옵니다.

보험업법과 개인정보

보험업법은 상품 신고, 기초서류(약관·사업방법서·산출방법서)의 관리, 모집 절차, 자산 운용 한도, 회계 처리 기준을 다룹니다. IT 관점에서 중요한 것은 산출방법서입니다 — 보험료와 준비금을 어떻게 계산하는지가 이 문서에 있고, 시스템은 이 문서를 그대로 구현해야 합니다. 개인정보 쪽은 보험이 다루는 정보가 민감정보(건강·질병)와 고유식별정보(주민등록번호)라는 점이 핵심입니다. 개인정보보호법은 이들의 처리에 별도 동의와 암호화 같은 안전조치를 요구하고, 신용정보법이 겹쳐 적용됩니다. 청구 서류의 진단서·진료 기록은 가장 민감한 축에 속하므로 접근 권한·마스킹·보존 기간이 요구사항에 반드시 들어갑니다.

계리 계산을 시스템으로 옮길 때 생기는 문제

IFRS17 과 K-ICS 는 회계 기준이지만, 실제로는 계산 시스템의 요구사항으로 내려온다. 그 요구가 일반적인 업무 시스템과 다른 점이 셋이다.

계산량이 많고, 그 계산을 반복해야 한다. 계약 하나마다 미래 현금흐름을 수십 년치 만들고, 그것을 여러 시나리오로 돌린다. 계약이 수백만 건이면 배치 시간이 며칠 단위가 될 수 있다. 그래서 어디까지 계산했는지 저장하고 중간부터 다시 시작할 수 있는 구조가 처음부터 필요하다. 다 돌리고 나서 실패하면 처음부터 다시 돌릴 수 없다.

같은 입력이면 같은 답이 나와야 한다. 감사에서 "이 숫자가 어떻게 나왔는지 보여 달라" 는 요구가 온다. 그러려면 계산에 쓴 가정, 요율표 버전, 코드 버전을 결과와 함께 저장해야 한다. 결과만 저장하는 시스템은 몇 달 뒤 그 숫자를 재현하지 못한다.

추정치는 나중에 바뀐다. 회계 마감 뒤에 가정이 바뀌면 그 시점부터 반영할지, 과거를 다시 계산할지가 정해져 있어야 한다. 시스템 쪽에서는 "확정된 기간은 잠근다" 는 규칙으로 나타난다. 잠금이 없으면 마감된 분기의 숫자가 조용히 달라지고, 그 사실을 외부 감사에서 발견하게 된다.

개발자가 계리를 다 알 필요는 없지만, 세 가지는 물어야 한다. 이 숫자의 기준일은 언제인가, 어떤 가정을 썼는가, 다시 계산하면 같은 값이 나오는가. 이 셋이 답이 되면 나머지는 계리 담당자의 몫이다.

성능은 대개 입출력에서 나온다. 계약별 현금흐름은 행이 아니라 열 단위로 저장하고 압축하면 크게 줄어든다. 계산 자체보다 그 결과를 읽고 쓰는 시간이 배치의 대부분을 차지하는 경우가 흔하다.

실무에서 진짜 중요한 것

첫째, 같은 계약이 세 층에서 다른 숫자입니다. 원가 준비금과 IFRS17 부채가 다른 것은 오류가 아니라 가정이 다르기 때문입니다. 대사할 때는 층을 섞지 마세요.

둘째, 가정은 데이터이고 버전이 있습니다. 위험률표·할인율 곡선·사업비 가정은 결산 시점마다 확정되고, 어느 결산에 어느 가정을 썼는지가 재현의 조건입니다.

셋째, 민감정보는 최소로 만지세요. 준비금과 손해율은 진단명 없이도 계산됩니다. 분석 마트에 진단 코드가 꼭 필요한지 먼저 묻고, 필요하면 마스킹과 접근 통제를 설계에 넣습니다.

다음 실습에서 계약 5건의 책임준비금을 계산하고, 현행 할인율로 BEL·RA·CSM 을 뽑고, 회사 숫자로 지급여력비율까지 한 번에 만듭니다.