개념
결함이 수십 년 뒤에 드러난다
레슨 2 에서 원장 계산 결함이 결산이나 민원으로 늦게 드러난다고 했다. 보험은 그보다 훨씬 늦다.
종신 상품의 해지환급금 계산이 특정 조건에서 틀렸다고 하자. 그 조건에 해당하는 계약자가 해지를 요청하는 것은 가입 후 10년 뒤일 수 있다. 그때 발견하면 이미 같은 계산으로 처리된 건이 수천 건 이고, 전부 재계산해 정산해야 한다. 그리고 그 사이 상품은 판매가 종료되고 담당자는 바뀌었다.
그래서 보험 계산 검증의 성격이 정해진다.
- 지금 쓰이지 않는 경로를 지금 시험해야 한다. 10년 뒤에 처음 실행될 분기가 있다
- 시간을 전진시킬 수 있어야 한다. 실제로 기다릴 수 없다
- 과거 상품이 계속 살아 있다. 판매 종료된 상품의 계약이 수십 년 유지된다
세 번째가 조직에 특히 무겁다. 새 상품을 만들 때마다 시험 대상이 누적 되고, 한 번도 줄어들지 않는다. 그래서 이 레슨의 후반은 시험이 폭발하지 않게 하는 설계 다.
계산의 근거는 코드가 아니라 기초서류에 있다
QA 가 가장 먼저 교정해야 할 태도다. 보험 계산의 기대값은 개발자에게 물어서 얻는 것이 아니다. 상품의 기초서류(산출방법서 등) 와 약관이 계산 방법을 정하고, 시스템은 그것을 구현한 것이다.
그래서 작업 순서가 이렇게 된다.
[기초서류·약관] ──→ [기대값을 독립적으로 계산] ──→ [시스템 결과와 비교]
↑ ↑
QA 가 읽어야 하는 것 엑셀·스크립트로 따로 구현가운데 단계가 핵심 이다. 시스템이 계산한 값을 보고 "맞는 것 같다" 고 판정할 수는 없다. 독립적으로 계산한 값과 비교해야 검증이다. 이것이 모듈 58 레슨 1 의 테스트 오라클 문제이고, 보험에서는 기초서류가 오라클 이다.
실무에서 QA 가 기초서류를 처음 열면 읽기 어렵다. 수식과 기호가 많고, 전제가 문서 여러 곳에 흩어져 있다. 그래도 읽어야 한다. 읽지 않으면 개발자가 구현한 대로 시험하게 되고, 그것은 구현을 확인한 것일 뿐 요구를 확인한 것이 아니다 — 모듈 63 레슨 3 에서 다룬 "커버리지를 채우는 시험" 과 같은 함정이다.
읽을 수 없는 부분은 질문으로 만든다. 계리 담당에게 "이 조건에서는 어느 식이 적용됩니까" 를 묻고 답을 문서로 받는다. 이 질문 목록 자체가 가치 있는 산출물이다 — 답이 갈리는 질문이 나오면 그것이 결함의 씨앗이다.
무엇을 계산하는가 — 네 덩어리
구체적 산출식은 상품마다 다르고 기초서류에 있다. QA 가 알아야 할 것은 무엇을 계산하는 기능인지 와 각각이 어디서 틀리는지 다.
| 계산 | 무엇인가 | QA 관점의 위험 |
|---|---|---|
| 보험료 | 계약자가 내는 금액 | 가입 조건(나이·성별·기간·금액) 조합이 폭발한다 |
| 책임준비금 | 장래 보험금 지급을 위해 적립하는 금액 | 결산·재무제표에 직결. 틀리면 회계가 틀린다 |
| 해지환급금 | 중도 해지 시 돌려주는 금액 | 계약자에게 직접 지급. 틀리면 민원·정산 |
| 보험금·급부 | 사고 발생 시 지급하는 금액 | 조건이 얽혀 결정표가 필요하다 |
산출의 전제가 되는 계리적 가정(예정이율, 위험률, 사업비율 같은 항목) 은 상품별로 정해지고 기초서류에 적혀 있다. 각 가정의 정의·적용 방식·값은 해당 상품의 기초서류와 관련 감독 규정에서 확인한다(원문 확인). QA 가 이 값을 추측하거나 다른 상품에서 가져오면 안 된다 — 상품마다 다르다.
그리고 네 계산은 서로 연결 되어 있다. 보험료 계산의 전제가 바뀌면 준비금과 환급금도 영향을 받는다. 그래서 한 전제를 바꾸는 변경의 영향 범위가 넓다 — 뒤에서 다룬다.
경계를 체계적으로 고른다
보험 계산은 경계값 분석이 가장 강력하게 작동하는 영역이다. 모듈 3 레슨 1 의 기법을 그대로 쓰되, 보험 특유의 경계 축을 알아야 한다.
축 1 — 나이. 가입 나이 하한·상한, 그리고 나이 계산 방식의 경계 가 있다. 생일 당일, 보험 나이 산정 기준일, 윤년 2월 29일생. 나이를 어떻게 세는지가 상품·제도마다 다를 수 있으므로 기초서류에서 확인한다(원문 확인).
축 2 — 기간. 보험 기간 시작일·만료일, 납입 기간 종료일, 그리고 그 전후 1일. 만료일 당일 사고는 보장되는가. 납입 기간 종료 후 보장은 계속되는가.
축 3 — 경과 기간. 경과 월수·년수에 따라 식이 바뀌는 구간이 있다. 예 — 일정 기간 전 해지와 그 후 해지의 환급률이 다르다. 구간 경계의 전후 하루 가 핵심 케이스다.
축 4 — 납입 상태. 정상 납입, 연체, 실효, 부활. 각 상태 전환의 경계에서 계산이 달라진다. 상태 전환 당일 이 경계다.
축 5 — 금액. 최소·최대 가입 금액, 그리고 단수 처리 경계. 레슨 2 에서 다룬 단수 처리가 여기서 반복적으로 적용된다 — 월 보험료를 수백 번 더하면 단수 오차가 누적된다.
축 6 — 특약 조합. 주계약 + 특약의 조합. 조합 수가 폭발하는 지점이고, 조합 기법(모듈 3 레슨 5) 이 필요하다.
축 2·3·4 의 교차가 실무에서 가장 자주 결함을 낸다. 예 — 납입 기간 종료 직후, 연체 상태에서, 구간 경계일에 해지하는 경우. 이런 교차는 의도적으로 설계해야 만들어지고, 일반 시험에서는 만나지 않는다.
시간을 전진시키는 환경이 전제다
위 경계 대부분이 시간 경과 를 요구한다. 10년 경과 해지, 납입 기간 종료 후, 만료일 당일. 실제로 기다릴 수 없으므로 업무일자를 조작할 수 있는 시험 환경 이 필수다.
QA 가 확인하고 요구할 것은 이렇다.
| 확인 | 왜 |
|---|---|
| 업무일자를 바꿀 수 있는가 | 없으면 경과 기간 시험이 불가능하다 |
| 어느 단위로 바꾸는가 | 계약 단위인가 시스템 전체인가 |
| 배치가 그 날짜로 도는가 | 일마감·월마감이 조작된 날짜를 따르는가 |
| 되돌릴 수 있는가 | 전진만 되면 시험마다 환경을 다시 만든다 |
| 실제 날짜와 섞이지 않는가 | 섞이면 결과를 믿을 수 없다 |
세 번째가 자주 빠진다. 조회 화면은 조작된 날짜를 쓰는데 배치는 실제 날짜로 돌면, 경과 기간 시험이 반쪽이 된다. 준비금과 환급금은 배치로 계산되는 경우가 많으므로 이 확인이 중요하다.
환경이 없으면 그것이 설계 지적 이다. "경과 기간 관련 시험을 할 수 없습니다" 를 결함 1건이 아니라 시험 가능성 지적 으로 올린다 — 모듈 9 레슨 9, 모듈 46 레슨 8 과 같은 성격이다.
지급 규칙은 결정표로 푼다
보험금·급부 지급은 조건이 얽힌다. 모듈 3 레슨 3 의 결정표가 여기서 가장 실질적으로 쓰이는 영역이다.
전형적인 조건 축이다.
- 사고 유형(질병·상해·사망 등)
- 사고 시점(보험 기간 내/외, 면책 기간 내/외)
- 납입 상태(정상·연체·실효·부활 후)
- 고지 의무 관련 사항
- 중복 지급·한도 관련 사항
- 특약 가입 여부
조건이 6개면 조합이 수십 개 가 되고, 그중 상당수는 실제로 발생하지 않거나 약관상 의미가 없다. 결정표의 가치는 그 구분이다 — 조합을 전부 적어 보고, 약관이 정하는 결과를 채우고, 비어 있는 칸을 찾아내는 것.
비어 있는 칸이 나오면 세 가지 중 하나다.
- 약관에 적혀 있는데 우리가 못 찾았다 → 찾는다
- 약관에 없다 → 질의한다. 이것이 가장 값진 발견이다
- 발생할 수 없는 조합이다 → 왜 발생할 수 없는지 근거를 적는다
2번이 QA 가 보험 도메인에서 만드는 가장 큰 가치 다. 약관에 규정되지 않은 조합이 실제로 발생하면 분쟁이 되고, 그때는 해석 문제가 된다. 개발 단계에서 발견하면 약관이나 업무 규정으로 정리할 수 있다.
상품이 늘어나면 시험이 폭발한다
이 환경의 구조적 문제다. 상품은 계속 추가되고, 판매 종료된 상품도 계약이 남아 있어 계산이 계속 돌아야 한다. 시험 대상이 누적만 된다.
대응은 세 가지이고, 함께 써야 한다.
1) 계산 엔진과 상품 설정을 분리한다. 계산 로직이 공통이고 상품별 차이가 설정으로 들어가면, 엔진은 한 번 시험하고 상품은 설정을 대조 하면 된다. 이것이 모듈 46 레슨 10 의 AUTOSAR 설정 대조와 같은 구조다 — 설정 값을 기초서류와 기계적으로 비교하는 검사를 만든다.
분리되어 있지 않으면(상품마다 코드를 복사해 수정했으면) 상품 수만큼 시험이 늘어난다. 그것이 구조 문제라는 것을 지적하는 것 도 QA 의 일이다.
2) 기준 결과 집합(골든 데이터) 을 쌓는다. 상품별로 대표 계약 조건과 그에 대한 검증된 계산 결과 를 저장해 둔다. 이후 변경마다 그 결과가 바뀌는지 본다.
주의할 것이 둘 있다. 첫째, 기준 결과가 어떻게 검증되었는지 기록 한다 — 기초서류에서 독립 계산한 것인지, 시스템 출력을 그대로 저장한 것인지. 후자면 그것은 기준이 아니라 현재 동작의 사진 일 뿐이다. 둘째, 의도적으로 바뀌어야 할 때 를 다룬다 — 모듈 39 레슨 11 의 재처리 검증과 같은 문제다. 변경 명세에서 "달라질 곳과 달라지지 않을 곳" 을 가른다.
3) 불변식으로 넓게 덮는다. 개별 금액의 기대값을 전부 계산할 수는 없지만, 항상 성립해야 하는 관계 는 넓게 적용할 수 있다. 레슨 2 의 불변식 발상이다.
| 불변식 성격 | 예 |
|---|---|
| 단조성 | 같은 조건에서 경과 기간이 길어지면 환급금이 줄지 않는다(상품 특성에 따라 확인) |
| 상한·하한 | 환급금이 납입 보험료 총액을 넘지 않는다(상품 특성에 따라 확인) |
| 음수 금지 | 지급액이 음수가 되지 않는다 |
| 합계 일치 | 특약별 지급액 합 = 총 지급액 |
| 재계산 일치 | 같은 입력으로 다시 계산하면 같은 값(모듈 40 레슨 8 의 재현성) |
"상품 특성에 따라 확인" 을 붙인 이유 가 있다. 단조성이나 상한이 모든 상품에 성립하는 것은 아니다. 불변식이 성립하는지부터 기초서류로 확인 하고, 성립하는 상품에만 적용한다. 성립하지 않는 상품에 적용하면 거짓 양성이 쏟아지고, 검사가 신뢰를 잃는다 — 모듈 39 레슨 10 에서 다룬 거짓 양성 문제와 같다.
이 셋을 합치면 상품이 늘어도 시험이 선형보다 느리게 늘어난다. 엔진은 고정, 설정은 자동 대조, 개별 상품은 기준 결과와 불변식으로 덮는다.
변경의 영향이 넓다
계리적 가정 하나를 바꾸면 보험료·준비금·환급금이 함께 바뀐다. 그리고 기존 계약과 신규 계약의 처리가 다를 수 있다. 변경 영향 판정 축이 이렇게 된다.
| 축 | 질문 |
|---|---|
| 적용 범위 | 신규 계약만인가, 기존 계약도인가 |
| 영향 계산 | 네 계산 중 어느 것이 바뀌는가 |
| 시점 | 언제부터 적용되는가. 소급이 있는가 |
| 과거 데이터 | 이미 계산·지급된 건의 보정이 필요한가 |
| 결산 | 준비금이 바뀌면 재무제표에 영향을 주는가 |
| 기준 결과 | 골든 데이터 중 무효가 되는 것은 어느 것인가 |
네 번째가 가장 비싸다. 과거 지급 건을 보정해야 하면 금전 정산과 고객 안내가 따라오고, 그 비용이 개발 비용을 넘는다. 그래서 결함을 출시 전에 잡는 가치가 자릿수로 크다 — 레슨 2 와 모듈 44 레슨 9 의 품질 비용 논지가 여기서 가장 강하게 성립한다.
실무에서 왜 필요한가
보험사 IT 조직에서 QA 가 겪는 어려움은 두 가지다.
첫째, 도메인 문서를 읽는 비용. 기초서류와 약관은 읽기 어렵고, 읽지 않으면 개발자가 구현한 대로 시험하게 된다. 그런데 이 분야에서 구현을 확인한 시험은 거의 쓸모가 없다 — 계산 로직의 결함은 요구와 대조해야만 드러난다.
둘째, 시간과 조합. 10년 경과 해지, 납입 종료 직후, 연체 중 경계일. 이 조건들을 만들 환경이 없거나 조합을 체계적으로 고르지 못하면, 결함은 수년 뒤 민원으로 드러난다.
QA 가 기여하는 가장 큰 지점은 독립 계산 이다. 기초서류에서 식을 읽어 엑셀이나 스크립트로 따로 계산하고 시스템 결과와 비교하는 작업. 이것을 하는 QA 는 계리·개발 양쪽에서 신뢰를 얻는다. 한 건의 불일치를 찾아내면 그 가치가 즉시 보이고, 그 뒤로는 설계 단계부터 불려 간다.
두 번째 기여는 약관에 없는 조합을 찾아내는 것 이다. 결정표를 채우다 비는 칸을 질의로 올리면, 그것은 시스템 결함이 아니라 업무 규정의 공백 이다. 개발 단계에서 정리하면 되고, 운영에서 만나면 분쟁이 된다.
세 번째는 구조 지적 이다. 상품마다 코드가 복사되어 있으면 시험이 상품 수만큼 늘어난다. 엔진과 설정을 분리하라는 지적은 품질 비용으로 설명할 수 있고, 그 설명이 되는 QA 가 설계 논의에 들어간다.
채용시장에서의 위치
이 영역은 보험사 IT 조직, 보험 코어 시스템 구축·운영 기업, 보험 솔루션 기업 의 QA 자리다. 공고에는 "보험 코어", "계약·보상 시스템", "상품 계산", "보험 업무 경험" 같은 말이 적힌다.
특징은 도메인 진입 장벽이 매우 높고, 넘으면 대체하기 어렵다 는 점이다. 기초서류를 읽고 독립 계산을 할 수 있는 QA 는 흔하지 않고, 그 역량은 조직 안에서 빠르게 희소해진다. 그리고 경력이 길게 유지된다 — 상품이 수십 년 살아 있으므로 과거 상품을 아는 사람의 가치가 떨어지지 않는다.
경쟁력이 되는 것은 셋이다. 첫째, 기초서류를 읽고 기대값을 독립적으로 계산하는 능력 이다. 면접에서 "계산 결과가 맞는지 어떻게 확인하십니까" 는 이것을 보는 질문이고, "개발자에게 확인합니다" 로 답하면 약하다. 둘째, 경계를 체계적으로 고르는 능력 이다 — 여섯 축과 그 교차를 들어 답할 수 있으면 다르다. 셋째, 시험이 폭발하지 않게 설계하는 능력 이다. 엔진·설정 분리, 기준 결과, 불변식 세 축을 말할 수 있는 사람은 조직의 구조 문제를 다룰 수 있는 사람으로 읽힌다.