한눈에 보는 답
계리 모델링 시스템 이관에서 AI는 레거시 코드·설명서의 구조를 요약하고, As-Is 변수·규칙을 To-Be 구조에 매핑하며, 미매핑 후보와 테스트 초안을 찾는 데 활용할 수 있습니다. 다만 문서에 없는 수작업 조정, 운영 관행, 모델 간 결과 차이는 담당자 인터뷰와 결과 대사·회귀 테스트로 확인해야 합니다.
- 코드 변환보다 먼저 ‘현재 모델이 실제로 어떻게 운영되는지’를 재구성합니다.
- AI의 매핑 결과에는 원문 근거, 검토 상태, 미결 질문을 함께 남깁니다.
- 이관 완료는 실행 성공이 아니라 허용된 차이와 승인 기록으로 판단합니다.
오래 운영한 계리 모델에는 코드뿐 아니라 파일명 규칙, 담당자의 수작업, 예외 처리, 실행 순서가 함께 쌓여 있습니다. 따라서 AI로 코드를 새 플랫폼 문법으로 바꾸는 일만으로는 이관이 끝나지 않습니다. 먼저 현재 상태를 검토 가능한 구조로 드러내야 합니다.
왜 계리 모델링 시스템 이관이 어려운가
이관의 핵심 난점은 같은 계산을 새 도구에서 다시 만드는 것보다 ‘같다’는 의미를 합의하는 일에 있습니다. 결과가 다를 때 오류인지, 플랫폼의 계산 순서나 반올림 차이인지, 새 가정 반영 때문인지 구분할 기준이 필요합니다.
| 난점 | 자주 생기는 질문 | 필요한 확인 |
|---|---|---|
| 문서와 코드의 불일치 | 어느 버전이 실제 운영 기준인가? | 실행본·변경 이력·승인 기록 |
| 숨은 수작업 | 실행 전후 누가 어떤 값을 보정하는가? | 담당자 인터뷰·운영 화면·체크리스트 |
| 플랫폼 차이 | 반올림·시점·배열 처리 차이를 허용할 것인가? | 항목별 허용 오차와 판단 책임자 |
| 테스트 공백 | 정상 사례 외에 어떤 경계값을 확인했는가? | 기준 사례·예외 사례·회귀 범위 |
AI를 적용할 수 있는 6단계
AI는 탐색과 초안을 넓히는 역할에 적합합니다. 각 출력이 자동으로 다음 단계로 넘어가게 하기보다 담당자가 승인한 항목만 To-Be 설계와 테스트에 반영하는 편이 추적에 유리합니다.
As-Is 인벤토리는 어떻게 만드나
처음부터 모든 파일을 AI에 넣기보다 업무 단위로 범위를 좁힙니다. 상품군이나 결산 프로세스 하나를 정하고 다음 정보를 연결합니다.
- 실제 실행되는 모델·스크립트와 버전
- 입력 파일, 기준일, 데이터 소유자와 생성 경로
- 변수·테이블·가정의 정의와 근거 문서
- 모델 실행 순서, 선행·후행 작업과 실패 처리
- 수작업 조정, 승인 단계와 결과 전달 대상
- 기준 결과와 과거에 발생한 주요 차이 사례
AI가 만든 코드 설명은 출발점입니다. 코드에 표현되지 않은 외부 파일 의존성이나 운영자의 판단은 저장소 분석만으로 알 수 없으므로 인터뷰와 실제 실행 관찰이 필요합니다.
변수·규칙 매핑표는 어떻게 설계하나
다음은 형식을 설명하기 위한 가상 예시입니다. 실제 회사의 변수명이나 이관 규칙이 아닙니다.
| As-Is 항목 | 근거·용도 | To-Be 후보 | 변환 규칙 | 상태 |
|---|---|---|---|---|
RATE_TBL_A | 가정 테이블 참조 | assumption.rate_a | 행·열 키 재구성 | 검토 필요 |
POL_MTH | 경과월 인덱스 | policy_month | 0/1 시작점 확인 | 미결 |
ADJ_MANUAL | 운영자 보정값 가능성 | 대응 없음 | 업무 인터뷰 후 결정 | 미매핑 |
좋은 매핑표에는 대응 필드만 아니라 원문 근거, 변환식, 단위, 결측 처리, 검토자, 승인일을 남깁니다. AI가 제안한 항목은 ‘확정’이 아니라 ‘후보’ 상태로 시작해야 합니다.
미매핑 항목과 수작업 관행은 어떻게 찾나
AI는 이름·사용 위치·설명 문맥이 비슷한 항목을 묶거나 참조되지 않는 변수 후보를 찾을 수 있습니다. 그러나 다음 신호가 곧 삭제 또는 오류를 뜻하지는 않습니다.
- 문서에는 있지만 코드에서 찾지 못한 규칙
- 코드에는 있지만 근거 문서가 연결되지 않은 변수
- To-Be에 바로 대응하지 않는 집계·반올림·보정 단계
- 특정 월 또는 특정 상품에만 쓰이는 분기
- 담당자가 별도 파일에서 적용하는 수작업
이 후보를 담당자에게 질문하고, 실행 로그와 결과 파일을 비교해 실제 사용 여부를 판정합니다. ‘AI가 불필요하다고 판단했다’는 이유만으로 레거시 로직을 제거해서는 안 됩니다.
대사·회귀 테스트는 어떻게 설계하나
FRC의 계리 모델 기술 지침은 모델의 목적 적합성, 데이터·가정·구현, 통제와 테스트, 문서화와 커뮤니케이션을 함께 보도록 안내합니다.[1] 이관 테스트도 한 번의 총액 비교보다 차이의 위치와 이유를 추적할 수 있어야 합니다.
| 테스트 층위 | 질문 | 증거 |
|---|---|---|
| 단위 테스트 | 개별 함수·산식·테이블 조회가 같은가? | 입력·기대값·실행 버전 |
| 경계 테스트 | 시점·연령·기간 경계 전후가 의도와 같은가? | 조건별 비교 결과 |
| 회귀 테스트 | 기존 정상 사례가 To-Be에서도 유지되는가? | 기준 사례 세트와 차이 로그 |
| 포트폴리오 대사 | 총액 차이가 어느 집단·변수에서 시작되는가? | 세분화된 차이 분석 |
| 운영 리허설 | 실제 일정·권한·오류 처리까지 수행 가능한가? | 실행 기록과 승인 결과 |
중요AI를 활용해도 ‘오류 0건’이나 완전 자동 이관을 보장할 수 없습니다. 허용 오차와 예외 처리 기준을 사전에 정하고, 차이를 승인할 책임자와 재검증 조건을 문서화해야 합니다.
이관 전 준비도 체크리스트
- 실제 운영 버전과 소유자를 식별했는가?
- 입력·가정·출력의 데이터 흐름이 연결되어 있는가?
- 문서에 없는 수작업과 예외를 인터뷰했는가?
- As-Is와 To-Be의 단위·시점·반올림 차이를 정의했는가?
- 기준 사례와 경계·오류 사례를 준비했는가?
- 허용 차이, 승인자, 롤백 또는 병행 운영 기준이 있는가?
- AI에 제공할 자료의 보안·접근·보존 기준을 확인했는가?
여러 항목이 비어 있다면 전면 자동 변환보다 작은 모델 하나의 인벤토리와 대사 기준부터 만드는 편이 적절합니다. 그 결과로 데이터 정비와 이관 범위를 다시 산정할 수 있습니다.
자주 묻는 질문
AI로 레거시 계리 코드를 새 언어로 바로 바꿀 수 있나요?
코드 변환 초안은 만들 수 있습니다. 다만 외부 파일, 실행 순서, 수작업, 계산 시점과 반올림 차이는 코드만으로 확인하기 어려워 별도 검증이 필요합니다.
모든 과거 결과가 완전히 같아야 하나요?
업무 목적과 시스템 차이에 따라 판단이 달라집니다. 항목별 허용 오차와 정당한 차이의 범위를 사전에 정하고, 차이 원인과 승인 기록을 남겨야 합니다.
가장 작은 시작 단위는 무엇인가요?
입출력과 기준 결과가 확인되는 단일 상품 또는 단일 계산 모듈이 적합합니다. 전후 비교가 가능하고 담당자가 설명할 수 있는 범위를 고르는 것이 중요합니다.
근거와 참고자료
- Financial Reporting Council, Technical Actuarial Guidance: Models, 2024.
- 보험연구원, 영국 AI 활용 등에 대한 보험계리 지침 개정 — 모형 통제·테스트, 변경 기록과 독립 검증 관련 국내 요약.
본문의 변수명과 매핑표는 설명을 위한 가상 예시입니다. 특정 회사의 시스템, 코드 또는 이관 결과를 나타내지 않습니다.
이관 도구보다 먼저, 현재 모델과 검증 기준을 정리하세요
3시간 자문에서 현재 모델·자료·운영 관행·대사 기준을 살펴보고 작은 검토 범위를 함께 정합니다.
자문 문의