계약의 상태는 컬럼에 적혀 있지 않다

한 줄 요약

보험 계약의 상태는 어딘가에 저장된 값이 아니라 납입 이력과 기준일에서 매번 다시 계산되는 값이고, 그래서 상태 컬럼과 사실은 늘 갈라진다.

왜 이게 필요했나

보험사 현장에 들어간 첫 주에 이런 요청을 받습니다. "이 계약, 실효 처리가 안 된 것 같은데 좀 봐 주세요."

로그를 봅니다. 에러가 없습니다. 야간 배치도 성공으로 끝났습니다. 테이블을 열어 보면 status 컬럼에 정상 이 들어 있습니다. 시스템은 자기가 시킨 대로 다 했다고 말하고 있는데 담당자는 틀렸다고 합니다.

여기서 막히는 이유는 기술이 아닙니다. '실효' 가 무슨 뜻인지 모르기 때문입니다. 그 말의 뜻을 알면 어디를 봐야 하는지가 5초 만에 정해지고, 모르면 하루를 로그에 씁니다.

어떻게 동작하나

보험 계약은 이 순서로 흘러갑니다.

청약 → 인수(언더라이팅) → 성립 → 유지(납입) → 실효 → 부활 → 해지 / 만기

앞의 셋은 사람이 결정하는 사건이고, 뒤의 것들은 대부분 시간이 결정합니다. 이 차이가 데이터 모양을 가릅니다.

청약은 고객이 가입을 신청한 상태입니다. 아직 계약이 아닙니다. 여기서 고객은 알릴의무(고지의무)를 집니다 — 지금까지 앓은 병, 복용 중인 약, 직업 같은 것들입니다.

인수(언더라이팅) 는 회사가 그 위험을 받을지 결정하는 절차입니다. 결과는 넷 중 하나입니다. 표준체 인수, 보험료 할증 인수, 특정 부위·질병을 뺀 부담보 인수, 거절. "청약 인수에서 반려됐다" 는 말은 이 단계에서 거절됐다는 뜻입니다.

성립은 첫 회 보험료가 들어오고 회사가 승낙한 시점입니다. 이때부터 보장이 시작됩니다.

유지는 매 회차 보험료를 내는 구간이고, 여기서 두 날짜가 중요합니다. 납입기일과 유예 기간입니다. 기일에 못 내도 곧바로 계약이 끊기지 않고 일정 기간 기다려 줍니다.

실효가 이 코스의 첫 함정입니다. 실효는 일어나는 사건이 아닙니다. 어느 표에도 "이 계약이 실효했다" 는 기록이 없습니다. 있는 것은 미납 회차 하나와 유예 규칙뿐이고, 실효일은 거기서 계산되어 나옵니다.

납입기일        2026-02-10유예 만료일     2026-03-31   ← 납입 해당월의 다음 달 말일실효일          2026-04-01   ← 유예 만료일 다음 날

유예 만료일 당일까지는 아직 유효합니다. 이 하루가 실제로 분쟁을 만듭니다. 3월 31일에 사고가 나면 보험금이 나가고 4월 1일에 나면 안 나갑니다.

부활도 오해가 많습니다. 실효된 계약에 밀린 보험료를 입금하면 자동으로 살아난다고 생각하기 쉬운데, 그렇지 않습니다. 부활은 부활 청약 + 알릴의무 재이행 + 심사를 다시 거칩니다. 그 사이에 병이 생겼다면 부담보가 붙거나 거절될 수 있습니다. 그래서 실효 이후에 들어온 입금은 부활 이벤트가 없는 한 계약을 되살리지 않습니다.

그러면 왜 테이블에 status 컬럼이 있을까요. 매번 계산하면 느리기 때문입니다. 그래서 야간 배치가 계산해서 컬럼에 써 넣습니다. 그 순간 이렇게 갈립니다.

status 컬럼   어젯밤 배치가 계산한 '의견'납입 이력      지금 다시 계산할 수 있는 '사실'

배치가 실패하거나, 부활 처리를 반영하지 못하거나, 나중에 들어온 정정을 못 따라가면 의견과 사실이 갈라집니다. 그리고 배치는 조용히 실패합니다. 에러 로그가 안 남는 것이 아니라, 남아도 아무도 그 로그를 이 계약과 연결하지 않습니다.

현장에서 만나는 모습

첫째, 실효로 잘못 잡힌 계약에는 보험금이 나가지 않습니다. 창구에서는 "실효된 계약이라 지급이 안 됩니다" 라고 답하고, 고객은 몇 달을 다투다 금융감독원에 민원을 넣습니다. 조사해 보면 원인은 부활 처리 배치가 3월에 한 번 실패한 것입니다. 부당 부지급은 지급액에 지연이자가 붙고, 건수 자체가 검사 지적 사항이 됩니다.

둘째, 정상으로 잘못 남아 있는 실효 계약이 더 위험합니다. 고객은 보장이 끊긴 줄 모르고 있습니다. 안내장도 안 갑니다. 그 상태로 사고가 나면 그때 처음 알게 되고, 그 자리에서 회사와 고객 둘 다 손해를 봅니다.

셋째, 부활 때 알릴의무를 다시 받지 않고 처리한 계약은 몇 년 뒤 청구 시점에 터집니다. 심사에서 "계약전 알릴의무 위반" 으로 부지급이 나가고, 고객은 "그때 아무도 안 물어봤다" 고 합니다. 기록이 없으면 회사가 집니다.

그다음 실습에서 할 것

먼저 다음 이론에서 기준일과 소급 정정을 보고, 그 뒤 실습으로 갑니다.

계약 40건과 납입 이력 480회차, 계약 이벤트, 그리고 나중에 들어온 수납 정정을 직접 만듭니다. 그 데이터로 특정 기준일의 계약 상태를 납입 이력에서 계산하고, 시스템의 status 컬럼과 대조해 어긋난 계약 9건을 찾아냅니다. 어긋난 방향이 셋으로 갈리는데, 방향마다 고객이 겪는 피해가 다릅니다.