보험사 코어 시스템 2026 — Guidewire·Duck Creek·Sapiens·Insurity·EIS·Majesco·FINEOS·Origami·Britecore 심층 비교 (메인프레임에서 클라우드 네이티브까지)

프롤로그 — 30년 된 COBOL이 새벽 4시에 멈춘 날

2026년 초, 한국의 한 대형 손해보험사 IT실 채팅방에 새벽 4시 17분 메시지가 떠올랐다.

"PG 정산 배치가 또 멈췄다. AS-400 위의 RPG 코드가 새로운 결제 코드 길이를 못 받아낸다. 이걸 짠 사람은 2008년에 퇴사했다. 주석이 일본어다."

이 한 줄이 2026년 보험사 코어 시스템 시장의 한 단면을 보여준다. 보험은 가장 보수적인 IT 산업이고, 보험 정책 데이터는 25~30년 동안 살아야 한다(생명보험은 평생). 그래서 1990년대 메인프레임 위에 짠 코어가 2026년까지 살아남았다. 그리고 이제 그걸 짠 사람들이 은퇴했다.

이 글은 2026년 보험사 코어 시스템 시장의 전체 지도를 그린다. 글로벌 P&C(Property & Casualty) 코어의 대표주자 Guidewire가 어떻게 시장을 장악했는지, Duck Creek Technologies가 IPO 이후 SaaS로 전환하며 어떻게 변했는지, Sapiens·Insurity·EIS·Majesco가 각자 어떤 자리를 차지하는지. 클레임 전문의 FINEOS, 리스크 관리의 Origami Risk, MGA·인디 보험사용 Britecore까지. 그리고 한국 삼성SDS의 보험 IT, KB라이프의 CIS 사례, 일본 NTT Data와 NRI ZAITAS의 30년 궤적을 함께 본다.

1장 · 보험사 코어 시스템이란 무엇인가 — 한 문장 정의

먼저 정의. 보험사 코어 시스템(insurance core system)이란, 보험 상품의 생애 주기 전체(정책 발행·언더라이팅·요율 산정·청구 처리·지급·결제)를 다루는 기간계 시스템의 묶음이다.

전통적으로 보험 코어는 세 가지 핵심 모듈로 나뉜다.

PAS (Policy Administration System) — 정책 발행, 갱신, 배서(endorsement), 만기 처리. 보험의 심장.
Claims System — 사고 접수, 조사, 합의, 지급. 손해율을 결정하는 가장 큰 비용 센터.
Billing System — 보험료 청구, 수금, 분납, 환급. 캐시플로우의 중추.

여기에 언더라이팅 워크스테이션, 요율 엔진(rating engine), 재보험(reinsurance) 시스템, 채널(에이전트/브로커) 포털, 고객 셀프서비스가 둘러싼다. 한 보험사가 30년 정책을 발행하면, 그 정책 데이터·청구 이력·지급 기록이 30년 동안 코어 안에 살아 있어야 한다. 이게 보험 코어가 메인프레임에 갇혀 있던 핵심 이유다.

2026년 시장은 두 개의 흐름으로 갈라진다. 글로벌 P&C 코어(Guidewire·Duck Creek·Sapiens·Insurity·EIS)와 Life & Annuity 코어(Sapiens CoreSuite·OIPA·Majesco L&A·Equisoft). 클레임 전문 엔진(FINEOS·Origami Risk)이 별도 자리를 차지하고, MGA/인디 보험사용 차세대(Britecore·Socotra)가 새 layer를 만든다.

2장 · P&C vs Life & Annuity — 코어 구조의 본질적 차이

보험 코어를 이해하려면 P&C와 L&A의 구조 차이부터 잡아야 한다. 두 영역은 비즈니스 모델이 다르고, 따라서 코어의 데이터 모델도 완전히 다르다.

P&C (Property & Casualty) — 손해보험. 자동차, 주택, 상해, 책임. 정책 기간이 짧고(보통 6개월~1년), 갱신 주기가 빠르고, 청구가 빈번하고 다양하다. 요율 산정이 매년 시장 변동을 반영하며, 보험금 지급액이 정해진 한도 내에서 사고 손해에 비례한다.

L&A (Life & Annuity) — 생명보험·연금. 정책 기간이 평생(생명보험)이거나 수십 년(연금). 보험금이 사망·해지·만기 같은 특정 이벤트에 따라 지급되고, 책임준비금(reserve) 계산·예정이율·사망률표(mortality table)가 핵심이다. 30년 후에 지급될 보험금을 미리 적립해야 한다.

항목	P&C	L&A
정책 기간	6개월~1년	평생 ~ 수십 년
핵심 데이터	위험요인·청구 이력	책임준비금·예정이율
청구 빈도	높음	낮음 (사망·만기)
요율 변동	매년	거의 없음
대표 코어	Guidewire·Duck Creek	Sapiens CoreSuite·OIPA
핵심 표	사고 통계표	사망률표·생명표

이 구조 차이가 코어 시스템 시장의 분기를 만든다. Guidewire와 Duck Creek은 P&C에 집중해 시장을 양분했고, Life & Annuity는 더 fragmented된 시장이다(Oracle OIPA·Sapiens CoreSuite·Majesco L&A·Equisoft).

3장 · Guidewire InsuranceSuite — P&C 코어의 사실상 표준

Guidewire(2001년 창업, 2012년 NYSE IPO, 본사 San Mateo)는 2026년 P&C 코어 시장의 사실상 표준이다. 글로벌 상위 P&C 보험사의 50%+가 Guidewire를 코어로 쓴다. Travelers, Nationwide, Liberty Mutual, Zurich, AXA, Allianz 등.

Guidewire InsuranceSuite는 세 가지 메인 제품으로 구성된다.

PolicyCenter — 정책 관리. 상품 카탈로그, 요율 계산, 정책 발행·갱신·배서.
ClaimCenter — 청구 관리. 사고 접수, FNOL(First Notice of Loss), 조사 워크플로우, 지급.
BillingCenter — 청구·수금. 보험료 청구, 결제, 분납, 환급.

여기에 InsuranceNow(작은 보험사용 통합 SaaS), DataHub(데이터 웨어하우스), InfoCenter(분석·BI), CustomerEngage(고객 포털), ProducerEngage(에이전트 포털)가 둘러싼다. 2020년 이후 Guidewire Cloud Platform으로 통합 SaaS화 진행 중이고, 2026년 현재 신규 고객의 90%+가 클라우드 옵션을 선택한다.

// Guidewire Gosu — PolicyCenter 요율 산정 룰 (Gosu는 Guidewire 전용 JVM 언어)
// 자동차 보험 — 운전자 나이와 사고 이력에 따른 보험료 조정
package rules.PersonalAuto

uses gw.api.system.PCLoggerCategory
uses entity.PersonalAutoLine
uses entity.PolicyPeriod

class AutoRatingRule {

  function calculateBasePremium(period : PolicyPeriod) : java.math.BigDecimal {
    var line = period.PersonalAutoLine
    var driver = line.PersonalVehicles.first().Drivers.first()
    var basePremium = 1200bd  // 기본 보험료

    // 나이 계수
    var ageFactor = driver.Age < 25 ? 1.5bd
                  : driver.Age < 65 ? 1.0bd
                  : 1.2bd

    // 사고 이력 계수 — 최근 3년 사고 건수
    var claimsCount = driver.PriorClaims.where(
      \c -> c.AccidentDate > java.time.LocalDate.now().minusYears(3)
    ).Count
    var claimsFactor = 1.0bd + (claimsCount * 0.3bd)

    return basePremium * ageFactor * claimsFactor
  }
}

Guidewire의 강점은 상품의 깊이다. 30년간 보험사와 함께 진화해 P&C의 거의 모든 변형(자동차·주택·상업·해상·근로자보상)을 다 지원한다. 단점은 가격이 비싸고(라이선스 + 구현 컨설팅 합해 수천만~~수억 달러), 구현 기간이 길다(보통 2~~4년), 그리고 Gosu라는 독자 언어 학습 곡선이 있다는 점.

4장 · Guidewire Cloud Platform — 2030년 80% 클라우드 목표

Guidewire는 2020년부터 Guidewire Cloud Platform(GWCP) 으로 전면 클라우드 전환을 선언했다. AWS 위에 구축된 멀티 테넌트 SaaS이고, 2026년 현재 신규 매출의 90%+가 클라우드다. CEO Mike Rosenbaum이 2025년 어닝콜에서 "2030년까지 전체 고객의 80%를 클라우드로 옮기는 게 목표"라고 발표했다.

GWCP의 아키텍처는 세 가지 레이어로 구성된다.

InsuranceSuite Cloud Service — PolicyCenter·ClaimCenter·BillingCenter의 SaaS 버전. AWS 멀티 AZ 배포, 자동 백업·DR.
Cloud Console — 보험사 IT가 자기 인스턴스를 관리(배포·모니터링·접근 제어).
Marketplace — 700+ 통합 컴포넌트(타사 인텔리전스·세금 계산·재해 모델링 등).

마이그레이션 패스는 보통 세 단계다. (1) On-prem InsuranceSuite를 lift-and-shift로 AWS에 띄움. (2) Guidewire Cloud Platform으로 재플랫폼화(Cloud API 활용, ContentLib·Studio로 커스터마이징 분리). (3) Guidewire가 제공하는 Cloud Service로 완전 전환(코드와 데이터를 Guidewire 멀티테넌트로 이주).

2026년 시점에서 글로벌 빅3 P&C(Travelers·Nationwide·Liberty Mutual)가 단계 3에 도달했다. 한국은 아직 단계 1~2 사이가 다수이고, 일본은 SOMPO·東京海上(도쿄해상)이 단계 2 마이그레이션 중이다.

5장 · Duck Creek Technologies — IPO 후 SaaS 전환의 분기점

Duck Creek(1990년대 Accenture 내부 부서로 시작, 2016년 분사, 2020년 NYSE IPO, 2023년 Vista Equity Partners에 비공개 인수)은 Guidewire의 가장 직접적 경쟁자다. 2026년 시점에서 글로벌 P&C 시장 점유율 2위.

Duck Creek OnDemand 가 클라우드 네이티브 SaaS 플랫폼의 이름이고, 세 가지 메인 제품으로 구성된다.

Duck Creek Policy — Guidewire PolicyCenter 대응.
Duck Creek Claims — ClaimCenter 대응.
Duck Creek Billing — BillingCenter 대응.

여기에 Duck Creek Rating, Duck Creek Reinsurance, Duck Creek Producer가 둘러싼다.

<!-- Duck Creek Policy — Author 정의 (XML 기반 비주얼 룰) -->
<!-- 주택보험 — 보장 한도 자동 조정 룰 -->
<Manuscript name="HomeInsurance.CoverageAdjustment" version="2026.1">
  <Rule name="ReplacementCostAdjustment">
    <Condition>
      <Equal>
        <Variable name="Coverage.Type" />
        <Constant>DwellingReplacementCost</Constant>
      </Equal>
    </Condition>
    <Action>
      <Calculate target="Coverage.Limit">
        <Multiply>
          <Variable name="Property.MarketValue" />
          <Constant>1.25</Constant>
        </Multiply>
      </Calculate>
    </Action>
  </Rule>
  <Rule name="DeductibleByZipCode">
    <Condition>
      <In>
        <Variable name="Property.ZipCode" />
        <List>33101,33102,33109</List> <!-- 마이애미 — 허리케인 위험 -->
      </In>
    </Condition>
    <Action>
      <Set target="Coverage.Deductible" value="10000" />
    </Action>
  </Rule>
</Manuscript>

Duck Creek의 차별점은 Author 비주얼 개발 도구다. Guidewire가 Gosu 코드로 룰을 쓴다면, Duck Creek은 XML/비주얼 에디터로 룰을 짠다. 따라서 비개발자(보험 상품 매니저·언더라이터)가 룰을 직접 수정하는 자급률이 높다. 단점은 복잡한 분기 로직에서 XML 부피가 폭증한다는 점.

2023년 Vista Equity Partners 비공개 인수 이후 Duck Creek은 SaaS 매출 비중을 빠르게 늘렸고, 2026년 현재 80%+가 OnDemand SaaS다. 단순한 상품·중소 보험사에서 Duck Creek이 강하다는 평이 있다.

6장 · Sapiens IDIT & CoreSuite — 글로벌 멀티 라인의 정수

Sapiens(이스라엘 본사, 1982년 창업, NASDAQ 상장)는 P&C와 Life & Annuity를 모두 다루는 multi-line 보험 코어의 대표 주자다. 글로벌 600+ 보험사에 배포돼 있고, 특히 유럽·아시아·아프리카 시장에서 강하다.

Sapiens의 두 메인 제품을 구분해야 한다.

Sapiens IDIT — P&C 코어. 동남아·남미 신흥 시장에서 강한 P&C 풀스택 솔루션.
Sapiens CoreSuite for L&P — Life & Pensions 코어. 영국·유럽 시장에서 거대 보험사 도입.

여기에 Sapiens DigitalSuite(고객 포털·에이전트 채널), Sapiens Decision(룰 엔진), Sapiens Reinsurance가 둘러싼다.

# Sapiens IDIT — 제품 설정 YAML (low-code 구성)
# 자동차 보험 상품 정의 — 신규 시장 출시
product:
  name: AutoComprehensive2026
  line_of_business: PersonalAuto
  effective_date: 2026-01-01
  base_premium:
    method: TerritoryBasedRating
    factors:
      - territory_code  # 시·도별 사고율
      - vehicle_class   # 승용·SUV·트럭
      - driver_age_band # 21-25, 26-65, 65+

coverages:
  - code: BI  # Bodily Injury
    limits: [100000, 300000, 500000]
    default_limit: 300000
  - code: PD  # Property Damage
    limits: [50000, 100000, 250000]
    default_limit: 100000
  - code: COMP  # Comprehensive
    deductibles: [500, 1000, 2500]
    optional: true

underwriting_rules:
  - rule_id: AGE_LIMIT
    condition: "driver.age < 21 OR driver.age > 75"
    action: REFER_TO_UNDERWRITER
  - rule_id: PRIOR_LOSSES
    condition: "driver.prior_claims_3yr >= 3"
    action: DECLINE

Sapiens의 강점은 글로벌 다국가 지원이다. 한 코어 위에서 50+ 국가의 규제·통화·언어를 다루도록 설계됐다. Allianz·Generali 같은 유럽 다국적 보험사가 Sapiens로 코어를 통합한 사례가 많다. 단점은 Guidewire만큼 미국 P&C 깊이가 아니고, UI/UX가 상대적으로 구식이라는 평.

7장 · Insurity — 미국 중소 보험사 전문

Insurity(2000년대 합병으로 형성, GTCR 사모펀드 소유)는 미국 중소 P&C 보험사 시장의 강자다. 매출 규모는 Guidewire·Duck Creek보다 작지만, 200+ 보험사 고객 기반이 있고, 특히 specialty 라인(상업보험·해상·작물보험)에서 강하다.

Insurity의 주요 제품군은 세 가지다.

Insurity Policy Decisions Suite — 정책·요율 통합 플랫폼.
Insurity Claims Decisions Suite — 청구 워크플로우.
Insurity SpatialKey — 지리공간 분석(허리케인·홍수 위험 평가).

2022~2024년 사이 Insurity가 SpatialKey, Tropics, ISCS 같은 specialty 회사를 연쇄 인수해 specialty 보험 코어의 거의 모든 layer를 보유한다. 미국 농작물 보험(crop insurance)에서는 Insurity가 사실상 표준에 가깝다.

Insurity의 클라우드 버전은 Insurity Cloud Platform이고, AWS 기반 멀티테넌트 SaaS다. 2026년 기준 신규 매출의 70%+가 클라우드.

8장 · EIS Suite — 디지털 보험사를 위한 코어

EIS Group(1996년 창업, 본사 샌프란시스코)은 후발 주자지만 빠르게 성장 중이다. 핵심 메시지는 "디지털 네이티브 보험사를 위한 코어" — 처음부터 API-first, microservices, event-driven으로 설계됐다.

EIS Suite는 P&C와 L&A를 모두 다루는 통합 플랫폼이고, 다섯 가지 핵심 컴포넌트로 구성된다.

PolicyCore — 정책 관리.
ClaimCore — 청구 관리.
BillingCore — 청구·수금.
CustomerCore — 360도 고객 뷰.
EngageCore — 옴니채널 고객 인터랙션.

EIS의 차별점은 이벤트 기반 아키텍처다. 모든 비즈니스 이벤트(정책 발행·청구 등록·보험료 수납)가 Kafka 토픽으로 발행되고, 다른 모듈이 구독해 반응한다. 따라서 보험사가 자신의 분석·CRM·외부 시스템과 코어를 결합하기 쉽다.

{
  "event_type": "policy.bound",
  "event_id": "evt_2026_05_25_a7f9e",
  "occurred_at": "2026-05-25T14:32:18.420Z",
  "actor": {"user_id": "agent_445", "role": "agent"},
  "tenant_id": "carrier_acme_insurance",
  "payload": {
    "policy_id": "POL-2026-009834",
    "product": "AutoPersonal",
    "policyholder_id": "cust_8723",
    "effective_date": "2026-06-01",
    "expiration_date": "2027-06-01",
    "annual_premium": 1487.50,
    "currency": "USD",
    "coverages": [
      {"code": "BI", "limit": 300000},
      {"code": "PD", "limit": 100000},
      {"code": "COMP", "deductible": 1000}
    ]
  },
  "schema_version": "2.3.0"
}

EIS는 디지털 인디 보험사(insurtech)와 잘 맞고, 전통 대형 보험사보다는 새로 진입하는 보험사·기존 보험사의 신규 디지털 브랜드에서 채택 사례가 많다. Allstate North Light(디지털 D2C 브랜드)가 EIS 도입 사례로 유명하다.

9장 · Majesco — 클라우드 네이티브 멀티 라인

Majesco(2014년 Mastek Insurance에서 분사, 2020년 Thoma Bravo 비공개 인수)는 P&C와 L&A 양쪽에서 입지를 갖춘 미들마켓 코어 공급자다. 인도·미국에 R&D 거점이 있고, 글로벌 200+ 보험사 고객.

Majesco의 주요 제품군은 세 가지다.

Majesco P&C Core Suite — P&C 정책·청구·청구계산.
Majesco L&A Core Suite — Life & Annuity 정책 관리.
Majesco Distribution Management — 에이전트·브로커 채널.

차별점은 Microsoft Azure 깊이 통합이다. AWS 기반 Guidewire·Duck Creek과 달리 Majesco는 Azure 위에 깊이 통합돼 있고, Power BI·Dynamics 365와 함께 쓰는 시나리오가 많다. Microsoft 기반 IT 인프라를 가진 보험사에 적합.

가격대가 Guidewire·Duck Creek보다 저렴해서 미들마켓 보험사(매출 $1B~$ 5B 정도)에 적합하다는 평가가 많다.

10장 · FINEOS Claims — 청구 전문 엔진의 자리

FINEOS(1993년 아일랜드 더블린 창업, 2019년 ASX 상장)는 청구 관리 전문 엔진이다. 풀스택 코어가 아니라 클레임·근로자보상·장애보험에 특화돼 있다.

FINEOS의 주요 제품은 세 가지다.

FINEOS Claims — 단체보험·근로자보상 청구.
FINEOS AdminSuite — 정책 관리(L&A 보조).
FINEOS Engage — 고객 셀프서비스 포털.

FINEOS의 강점은 장기 장애·근로자보상(disability and workers' comp) 의 깊이다. 이 영역은 한 번 사고가 나면 청구가 5~30년을 갈 수도 있어서, 일반 P&C 코어로는 다루기 어렵다. FINEOS는 이걸 처음부터 데이터 모델로 다룬다.

FINEOS Claims의 전형적인 청구 라이프사이클은 FNOL(First Notice of Loss) → Intake Validation → Claim Type 분기(Disability·Workers Comp·Group Life)로 시작한다. Disability 청구라면 의료 증거 수집이 따라오고, Workers Comp면 고용주 검증이, Group Life면 수익자 확인이 진행된다. 그 다음 adjudication(판정) → 승인 시 지급 개시 + 정기 재검토, 거절 시 항소 절차로 이어진다. 장기 청구는 정기 재검토를 거치면서 5~30년 동안 시스템 안에서 살아 있다.

FINEOS의 2026년 시점 주요 고객은 글로벌 단체보험사 — Unum, MetLife, Sun Life, Aflac. 한국·일본 시장 점유율은 낮지만, 글로벌 단체보험 시장의 사실상 표준 중 하나로 자리잡았다.

11장 · Origami Risk — 리스크 관리와 자가보험 시장

Origami Risk(2009년 시카고 창업)는 전통 코어 시스템과 결이 다르다. 리스크 관리 정보 시스템(RMIS, Risk Management Information System) 의 영역이고, 주 고객은 자가보험을 운영하는 대기업·정부·병원 같은 조직이다.

Origami의 차별점은 대형 자가보험자(self-insured) 의 워크플로우를 깊이 다룬다는 점이다. 글로벌 대기업이 자체 보험을 운영하면 — 직원 산재·재산 손해·일반 책임을 외부 보험사 대신 자가로 처리한다 — 그 클레임을 추적·관리·분석하는 시스템이 필요하다. 그 영역에서 Origami가 점유율이 높다.

2024~2025년 Origami가 ClearRisk·Catalyst 같은 GRC 회사를 인수해 청구 관리에서 GRC(Governance, Risk, Compliance)까지 확장했다.

12장 · Britecore & Socotra — MGA·인디 보험사용 차세대 코어

Britecore(2008년 창업, Intellect Design Arena 자회사로 합병)와 Socotra(2014년 Y Combinator 출신, 2024년 EIS Group 인수)는 차세대 P&C 코어의 새 layer다. 핵심 메시지는 "클라우드 네이티브, API-first, 30일 안에 보험 상품 출시".

Britecore의 강점은 MGA(Managing General Agent)와 작은 보험사의 빠른 출시 사이클이다. 전통 코어는 신규 상품 출시에 6~~12개월 걸리지만, Britecore는 4~~8주를 약속한다.

Socotra는 Web2/Web3 인디 보험·임베디드 보험(체크아웃 시 자동 보험 추가) 같은 신흥 시장에서 강하다. Lemonade 같은 디지털 D2C 보험사도 자체 코어 대신 Socotra 기반으로 출시한 사례가 있다.

코어	적합 보험사 규모	가격대	출시 속도	주 강점
Guidewire	매출 $5B+	매우 높음	2~4년 구현	P&C 깊이
Duck Creek	매출 $1B+	높음	1~3년	비주얼 룰
Sapiens	글로벌 다국적	높음	1~3년	다국가
Insurity	미국 specialty	중간	6개월~1년	Specialty 라인
EIS	디지털 인디	중간~높음	6개월~1년	API-first
Majesco	미들마켓	중간	1~2년	Azure 통합
Britecore/Socotra	MGA·인디	낮음	4~8주	빠른 출시

13장 · API-First 설계와 Guidewire APIs

2020년대 보험 코어의 가장 큰 변화는 API-first 설계다. 과거 모놀리식 코어가 자체 UI를 통해서만 접근 가능했다면, 2026년 코어는 REST/GraphQL API를 통해 모든 기능에 접근 가능해야 한다. 이게 디지털 채널·모바일·임베디드 보험을 가능하게 한다.

Guidewire는 2019년부터 Cloud APIs를 본격 출시했고, 2026년 기준 300+ 엔드포인트가 공개돼 있다. PolicyCenter·ClaimCenter·BillingCenter의 거의 모든 동작이 API로 가능하다.

POST /policy/v1/jobs/submission HTTP/1.1
Host: pc.acme.guidewire.cloud
Authorization: Bearer eyJhbGciOiJSUzI1NiI...
Content-Type: application/json

{
  "data": {
    "attributes": {
      "productCode": "PersonalAuto",
      "effectiveDate": "2026-06-01",
      "primaryNamedInsured": {
        "firstName": "Jane",
        "lastName": "Smith",
        "dateOfBirth": "1985-04-12",
        "primaryAddress": {
          "addressLine1": "123 Main St",
          "city": "Boston",
          "state": "MA",
          "postalCode": "02101"
        }
      },
      "personalVehicles": [
        {
          "vin": "1HGBH41JXMN109186",
          "year": 2023,
          "make": "Honda",
          "model": "Accord"
        }
      ]
    }
  }
}

이 API 호출 한 번으로 PolicyCenter에 새 견적이 생성되고, 요율 엔진이 보험료를 계산해서 응답한다. 이전이라면 PolicyCenter UI를 열고 30번 클릭해야 했던 일이다. 모바일 앱, 비교 사이트, 자체 D2C 사이트가 이 API를 호출해서 즉시 견적을 보여줄 수 있게 됐다.

API-first 설계의 또 다른 이점은 마이크로서비스 분해다. 모놀리식 PolicyCenter를 한꺼번에 갈아엎는 대신, 새 기능을 API 위에 마이크로서비스로 짜고 점진적으로 코어를 비워나가는 패턴이 가능해진다.

14장 · Salesforce Financial Services Cloud 통합

2020년대 후반의 새로운 흐름은 Salesforce Financial Services Cloud(FSC) 통합이다. 보험사가 코어 시스템과 별개로 Salesforce를 영업·고객 관리 layer로 도입하는 사례가 급증했다.

Salesforce FSC가 다루는 영역.

에이전트·브로커 CRM — 영업 파이프라인, 갱신 캠페인.
고객 셀프서비스 — Experience Cloud 위의 포털.
클레임 협업 — Service Cloud 위의 청구 어드저스터 워크스페이스.
분석 — Tableau CRM (Einstein Analytics) 기반.

Guidewire·Duck Creek·Sapiens 모두 Salesforce FSC와 양방향 통합 커넥터를 공식 지원한다. 정책·청구 데이터가 Salesforce에 실시간 동기화되고, 에이전트가 Salesforce에서 견적을 시작하면 그게 PolicyCenter로 전달된다.

이 구도는 보험 IT를 두 개의 layer로 분리한다 — System of Record(Guidewire 등 코어)와 System of Engagement(Salesforce). 코어는 데이터의 진실 원천이고, Salesforce는 사용자 경험과 외부 채널을 책임진다. 두 시스템이 어떻게 데이터를 동기화하는가가 2020년대 후반 보험 IT 아키텍처의 핵심 질문이 됐다.

15장 · 메인프레임 모더나이제이션 — COBOL/AS-400의 그림자

글로벌 P&C 시장이 클라우드로 옮기는 동안, 한국·일본의 많은 보험사는 여전히 COBOL/AS-400 위의 자체 개발 코어를 돌린다. 30년을 버틴 시스템들이다.

전형적인 메인프레임 보험 코어 스택.

하드웨어 — IBM zSeries 메인프레임 또는 IBM AS-400(현재는 IBM i).
언어 — COBOL, RPG, PL/I.
데이터베이스 — DB2, VSAM, IMS DB.
트랜잭션 처리 — CICS, IMS TM.
배치 — JCL (Job Control Language).

이 스택의 강점은 검증된 안정성이다. 30년 동안 24x7 무중단으로 보험 정책을 처리해 왔다. 단점은 인력 부족이다. COBOL 개발자가 2020년대에 평균 연령 55세를 넘어섰고, AS-400 RPG 개발자는 더 적다. 한국·일본 보험사 IT 부서가 가장 큰 위기로 인식하는 문제다.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CALC-PREMIUM.
       *> 30년된 자동차 보험료 계산 모듈 — 1995년 작성
       *> 단순화한 예시 (실제 코드는 수천 줄)
       
       ENVIRONMENT DIVISION.
       
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  WS-DRIVER-AGE      PIC 9(03).
       01  WS-PRIOR-CLAIMS    PIC 9(02).
       01  WS-BASE-PREMIUM    PIC 9(07)V99 VALUE 120000.00.
       01  WS-AGE-FACTOR      PIC 9(03)V999.
       01  WS-CLAIMS-FACTOR   PIC 9(03)V999.
       01  WS-FINAL-PREMIUM   PIC 9(09)V99.
       
       PROCEDURE DIVISION.
       MAIN-LOGIC.
           IF WS-DRIVER-AGE < 25
              MOVE 1.500 TO WS-AGE-FACTOR
           ELSE IF WS-DRIVER-AGE < 65
              MOVE 1.000 TO WS-AGE-FACTOR
           ELSE
              MOVE 1.200 TO WS-AGE-FACTOR
           END-IF.
           
           COMPUTE WS-CLAIMS-FACTOR = 1.000 + (WS-PRIOR-CLAIMS * 0.300).
           COMPUTE WS-FINAL-PREMIUM = WS-BASE-PREMIUM * WS-AGE-FACTOR
                                    * WS-CLAIMS-FACTOR.
           DISPLAY "FINAL PREMIUM: " WS-FINAL-PREMIUM.
           STOP RUN.

이 30년 된 COBOL을 어떻게 모더나이즈하는가가 2026년 한국·일본 보험사 IT의 핵심 의제다. 옵션은 세 가지. (1) 메인프레임을 그대로 유지하고 그 위에 API 게이트웨이만 얹는다. (2) Guidewire·Duck Creek 같은 상용 패키지로 코어를 통째로 리플레이스한다($100M+ 프로젝트, 3~5년). (3) COBOL을 자동으로 Java/C#으로 변환하는 도구(Heirloom·TmaxSoft·Micro Focus)를 쓴다.

16장 · 한국 삼성SDS 보험 IT — 30년의 사관학교

삼성SDS는 삼성생명·삼성화재·삼성카드의 IT 시스템을 만들어 온 30년의 사관학교다. 한국 보험 IT의 거의 모든 핵심 아키텍트가 한 번은 거쳐 간 곳.

삼성SDS의 보험 IT 핵심 자산.

Brity 보험 코어 — 자체 개발 P&C·생명 통합 코어. 삼성화재·삼성생명에 깊이 통합.
SCAS (Samsung Claims Administration System) — 청구 처리 자체 시스템.
Nexledger — 블록체인 기반 보험금 지급·재보험 정산 솔루션.
Brity AI — 챗봇·문서 처리·보험금 지급 자동화 AI 솔루션.

2020년대 중반 이후 삼성SDS는 자체 코어를 클라우드 네이티브로 재설계하기 시작했다. 핵심은 마이크로서비스 분해와 이벤트 기반 통합이고, AWS·Azure 멀티클라우드를 가정한 아키텍처다.

삼성생명·삼성화재가 이 자체 코어를 계속 쓸지, 아니면 Guidewire·Sapiens 같은 글로벌 패키지로 리플레이스할지가 2020년대 후반 한국 보험 IT의 큰 관전 포인트다. 자체 개발의 강점은 삼성 그룹 통합의 깊이, 단점은 글로벌 확장성과 인력 채용.

17장 · KB 보험 모더나이제이션 — KB라이프 CIS 클라우드 사례

KB금융그룹은 2022년 KB생명·푸르덴셜생명 합병 후 KB라이프생명을 출범시켰고, 이 합병의 가장 큰 IT 과제가 두 회사의 코어 시스템 통합이었다.

KB라이프의 차세대 코어 시스템 CIS(Core Insurance System) 은 2023~2025년에 걸쳐 구축됐다. 핵심 특징.

마이크로서비스 아키텍처 — 정책·청구·수금을 독립 서비스로 분리.
Kubernetes 기반 컨테이너 오케스트레이션 — 온프레미스 + KB 클라우드 하이브리드.
이벤트 기반 통합 — Kafka로 모듈 간 비동기 통신.
API 게이트웨이 — 외부 채널 통합을 위한 표준 인터페이스.

이 프로젝트는 한국 보험 IT의 모더나이제이션 사례 중 가장 야심찬 것 중 하나로 꼽힌다. 기존 두 회사의 메인프레임 코어를 클라우드 네이티브로 재구축하면서 30년 정책 데이터를 마이그레이션한 사례.

KB 외에도 신한라이프·교보생명·현대해상이 비슷한 모더나이제이션 프로젝트를 진행 중이다. 현대해상은 자체 개발 코어를 유지하면서 점진적으로 클라우드 네이티브 모듈로 분해하는 패턴이고, 교보생명은 Sapiens 도입을 검토했던 사례로 알려져 있다.

18장 · 일본 NTT Data 保険 코어 — 클라우드 마이그레이션의 거대 파도

일본의 보험 IT 시장은 NTT Data, NRI(Nomura Research Institute), TIS, NEC가 사실상 4분점한다. 그중 NTT Data가 가장 큰 보험 IT SI 사업자.

NTT Data의 보험 코어 자산.

NTT Data 保険 코어 (자체 패키지) — 일본 P&C·생명사용 자체 개발 코어.
OpenCanvas — NTT Data가 만든 보험 API 플랫폼.
TopVision Insurance — 차세대 보험 관리 패키지.

2020년대 중반 일본 보험사의 가장 큰 흐름은 클라우드 마이그레이션이다. 東京海上日動(도쿄해상일동)이 2023년부터 Guidewire Cloud로 일부 라인을 이주했고, SOMPO도 비슷한 시기에 클라우드 전환을 발표했다. 이 작업의 SI 파트너가 주로 NTT Data·NRI다.

일본 보험 IT의 특징은 30년 이상 운영된 메인프레임의 비중이 한국보다 훨씬 크다는 점이다. 1980~1990년대에 구축된 메인프레임이 2020년대까지 살아 있고, 그 위의 COBOL 코드가 수천만 줄에 달한다. 이걸 어떻게 모더나이즈하는가가 일본 보험 IT의 가장 큰 과제.

19장 · NRI ZAITAS — 30년의 보험 코어 패키지

NRI(노무라종합연구소)의 ZAITAS는 일본 보험 코어 시장에서 가장 오래된 패키지 중 하나다. 1990년대 초 출시해 30년을 살아남았고, 일본 중견·소형 보험사에 깊이 침투해 있다.

ZAITAS의 강점은 일본 보험 규제·제도와의 깊은 정합성이다. 일본 금융청(FSA, 金融庁)의 규제 변화, 일본 세제, 일본 회계기준(IFRS 17 도입 등)에 가장 빠르게 대응해 온 패키지. 일본 보험사가 글로벌 패키지(Guidewire·Sapiens)를 도입할 때 가장 큰 마찰점이 한국과 마찬가지로 로컬 규제 적합성인데, ZAITAS는 그 부분이 기본 탑재돼 있다.

2020년대 중반 NRI는 ZAITAS의 클라우드 네이티브 재구축을 진행 중이다. 기존 ZAITAS의 비즈니스 로직을 유지하면서 인프라 layer를 AWS·Azure 멀티클라우드 + Kubernetes로 갈아엎는 작업. 2030년 완료를 목표로 한다.

NRI 외에 일본의 또 다른 보험 IT 강자는 TIS이고, TIS의 eX-Tide 패키지가 일본 손해보험 시장에 깊이 침투해 있다.

20장 · SOMPO·東京海上 코어 마이그레이션 — 일본 빅2의 선택

일본 손해보험 시장의 빅2는 SOMPO 홀딩스와 東京海上 홀딩스(Tokio Marine)다. 두 회사 모두 2020년대 중반에 코어 시스템 모더나이제이션을 발표했고, 그 선택의 차이가 일본 보험 IT의 미래를 보여준다.

東京海上日動 — 2023년 Guidewire Cloud 도입 발표. 자동차 보험 라인부터 단계적 마이그레이션. SI 파트너는 NTT Data + Accenture. 5년 일정.

SOMPO 일본흥아손해보험 — 2024년 자체 개발 차세대 코어 + 마이크로서비스 분해 발표. 외부 패키지 대신 자체 IT 자회사인 SOMPO Systems가 구축. 클라우드는 AWS Tokyo 리전 기반.

이 두 선택의 차이가 의미하는 것. 東京海上는 글로벌 표준 패키지로 미국·아시아·유럽 일관성 확보를 우선시했고, SOMPO는 일본 특화 + IT 자급률을 우선시했다. 어느 쪽이 옳은지는 2030년쯤 평가가 나올 것이다.

이 두 마이그레이션 프로젝트는 각각 $500M 이상의 IT 투자다. 한국 KB라이프 CIS 프로젝트의 10배 규모. 일본 보험 IT의 규모와 보수성이 이 숫자에 담겨 있다.

21장 · Low-Code/No-Code의 보험 코어 적용

2020년대 후반 보험 코어의 또 다른 큰 변화는 low-code/no-code 도입이다. Guidewire Studio, Sapiens DigitalSuite, Duck Creek Author 모두 보험 상품 매니저·언더라이터·청구 어드저스터가 코드 없이 룰을 수정할 수 있는 도구를 제공한다.

이 흐름의 배경.

보험 상품 출시 속도 압박 — 디지털 D2C 보험사가 신상품을 4주 만에 출시하는데, 전통 보험사는 12개월 걸린다. 격차를 줄이려면 비개발자가 직접 룰을 수정할 수 있어야 한다.
IT 인력 부족 — Gosu·RPG·COBOL 인력 부족이 심각하다. 비개발자가 자급할 수 있는 도구가 필요하다.
규제 대응 속도 — 보험 규제가 빈번하게 바뀌고, IT 개발 사이클을 기다리면 지연 패널티를 받는다.

Guidewire Studio는 Gosu 코드를 비주얼 IDE로 편집할 수 있게 해주고, 일부 룰은 폼 기반 GUI로 작성한다. Duck Creek Author는 그 자체가 비주얼 룰 에디터다. Sapiens DigitalSuite는 채널·UI 자체를 노코드로 구성한다.

단점도 분명하다. 복잡한 비즈니스 로직은 low-code로 표현이 어렵다. 여전히 코드와 GUI를 섞어 쓰는 하이브리드 모델이 현실이다.

22장 · 마이크로서비스 분해 패턴 — 모놀리식 코어를 어떻게 쪼개나

10년 된 모놀리식 PolicyCenter를 마이크로서비스로 분해하려면 어디서부터 시작해야 하나. 2026년 시점의 베스트 프랙티스는 Strangler Fig 패턴이다.

1단계 — 기존 모놀리스 위에 API 게이트웨이를 얹는다. 모든 외부 호출이 이 게이트웨이를 통과한다.
2단계 — 신규 기능을 마이크로서비스로 짠다. 게이트웨이가 신규 기능 요청을 새 서비스로 라우팅하고, 나머지는 기존 모놀리스로 보낸다.
3단계 — 기존 기능을 점진적으로 신규 서비스로 옮긴다. 모놀리스에서 한 모듈씩 떼어 내고, 게이트웨이의 라우팅 규칙을 업데이트한다.
4단계 — 모든 기능이 신규 서비스로 옮겨지면 모놀리스를 셧다운한다.

이 패턴의 우아함은 거대한 빅뱅 리플레이스를 피한다는 점이다. 10년+의 보험 코어를 한꺼번에 갈아엎는 건 거의 항상 실패한다(IBM이 만든 "거대 IT 프로젝트는 65%가 실패한다"는 통계가 있다). Strangler Fig는 6~24개월 단위로 점진적으로 옮기면서 risk를 분산한다.

마이크로서비스 분해의 첫 번째 후보는 보통 상대적으로 독립적인 도메인 — 청구 접수(FNOL), 결제 수납, 고객 셀프서비스. 코어 도메인(정책 발행·요율 산정)은 가장 마지막에 옮긴다.

23장 · 데이터 마이그레이션 — 30년 정책 데이터의 무게

코어 시스템을 갈아엎을 때 가장 어려운 부분이 데이터 마이그레이션이다. 30년치 정책·청구·결제 데이터를 새 시스템으로 옮기면서 한 건도 잃어버리지 않아야 한다.

전형적인 마이그레이션 워크플로우.

데이터 프로파일링 — 기존 시스템의 데이터를 분석. 정확한 스키마, 데이터 품질 이슈, 누락·중복 식별.
데이터 정제 — 더러운 데이터를 정제. 예: 정책 번호 형식 통일, 날짜 형식 통일, 누락 필드 보완.
매핑 설계 — 기존 스키마 → 새 시스템 스키마 매핑. 어떤 필드가 어떻게 변환되는가.
변환 스크립트 개발 — ETL 도구(Informatica·Talend·dbt) 또는 자체 스크립트.
테스트 마이그레이션 — 일부 데이터(10~20%)를 테스트 환경으로 마이그레이션. 결과 검증.
풀 마이그레이션 — 전체 데이터를 옮긴다. 보통 주말 다운타임 또는 점진적 컷오버.
사후 검증 — 정책 건수, 보험금 지급 누적 합계, 청구 건수 등 핵심 지표가 일치하는지 확인.

이 작업이 어려운 이유. 기존 시스템의 데이터가 깨끗하지 않다. 30년 동안 형식이 여러 번 바뀌었고, 일부 정책은 마이그레이션마다 누락됐고, 결제 이력은 메인프레임의 별도 시스템에 있다. 이 모든 걸 정합성 있게 옮기는 작업이 보통 코어 마이그레이션 전체 예산의 30~40%를 차지한다.

-- 마이그레이션 검증 — 한국 보험사 사례
-- 기존 메인프레임 vs 신규 Guidewire의 정책 건수·총 보험금 비교
WITH legacy_summary AS (
  SELECT
    line_of_business,
    COUNT(*) AS policy_count,
    SUM(annual_premium) AS total_premium,
    COUNT(DISTINCT policyholder_id) AS unique_customers
  FROM legacy_policies
  WHERE effective_date >= '1995-01-01'
    AND status IN ('active', 'lapsed', 'expired')
  GROUP BY line_of_business
),
new_summary AS (
  SELECT
    product_code AS line_of_business,
    COUNT(*) AS policy_count,
    SUM(annual_premium) AS total_premium,
    COUNT(DISTINCT primary_named_insured_id) AS unique_customers
  FROM guidewire_pc.policies
  WHERE migration_batch_id IS NOT NULL
  GROUP BY product_code
)
SELECT
  COALESCE(l.line_of_business, n.line_of_business) AS lob,
  l.policy_count AS legacy_count,
  n.policy_count AS new_count,
  (n.policy_count - l.policy_count) AS count_diff,
  l.total_premium AS legacy_premium,
  n.total_premium AS new_premium,
  ROUND((n.total_premium - l.total_premium) / l.total_premium * 100, 4) AS premium_diff_pct
FROM legacy_summary l
FULL OUTER JOIN new_summary n USING (line_of_business)
ORDER BY ABS(count_diff) DESC;

이 쿼리 같은 검증을 마이그레이션 전후에 수십 번 돌려서 모든 숫자가 0.01% 이내로 일치해야 컷오버가 끝난다.

24장 · 재해 복구와 BCP — 24시간 멈출 수 없는 시스템

보험 코어는 24x7 무중단이 거의 절대적 요건이다. 청구 접수가 새벽 3시에도 들어오고, 결제 수납이 24시간 돌고, 자동차 사고는 시간을 가리지 않는다.

전통 보험사의 BCP(Business Continuity Plan) 설계.

이중화 데이터센터 — 메인 + DR 사이트. 동기·비동기 복제.
RPO (Recovery Point Objective) — 데이터 손실 허용 시간. 보통 0~5분.
RTO (Recovery Time Objective) — 복구 시간. 보통 1~4시간.
정기 DR 훈련 — 분기마다 메인 → DR 페일오버 테스트.

클라우드 시대에는 이게 더 단순해진다. AWS·Azure의 멀티 AZ·멀티 리전이 기본 탑재돼 있고, RPO·RTO가 분 단위로 줄어든다. Guidewire Cloud Platform은 AWS 멀티 AZ 배포가 기본이고, 자동 백업·자동 페일오버가 따라온다.

대신 클라우드 마이그레이션의 가장 큰 우려가 클라우드 자체의 장애다. 2024년 AWS us-east-1 장애로 미국 동부의 여러 보험사 코어가 한꺼번에 멈춘 사건이 있었다. 이후 보험사들은 멀티 클라우드(AWS + Azure)나 멀티 리전 분산을 더 진지하게 고려하기 시작했다.

25장 · 2026~2030년 보험 코어의 미래 — 5가지 전망

마지막으로 2030년을 향한 5가지 전망.

Guidewire Cloud가 80%+를 차지한다 — Guidewire의 2030년 80% 클라우드 목표가 달성될 가능성이 높다. 새 P&C 신규 구축의 90% 이상이 Guidewire Cloud + Duck Creek OnDemand로 양분.
AI 에이전트가 청구 처리를 바꾼다 — Claude·GPT 기반 청구 어드저스터 자동화가 단순 청구의 80%를 처리. 복잡 청구는 사람이.
임베디드 보험이 폭증한다 — 자동차 구매, 항공편 예약, 가전 구입 시 자동 보험 추가. Britecore·Socotra 같은 API-first 코어가 이걸 가능하게 한다.
메인프레임의 마지막 10년 — 한국·일본의 메인프레임 보험 코어가 2030년경 대규모로 은퇴. COBOL 인력이 60대 후반에 진입하면서 더 이상 유지 불가능.
재보험·블록체인·기후 보험 — 블록체인 기반 재보험 정산(Nexledger·B3i), 기후 변화 대응 신상품(parametric insurance), 사이버 보험의 폭발적 성장.

"보험 코어는 30년을 살아야 한다. 그러나 30년 된 코어는 30년 더 살 수 없다. 그 사이의 모더나이제이션이 2020년대 후반 보험 IT의 전부다."

26장 · 에필로그 — COBOL 개발자가 떠난 후

이 글의 첫 장면으로 돌아간다. 새벽 4시 17분의 채팅방. 2008년에 퇴사한 COBOL 개발자. 일본어 주석.

2026년 한국·일본의 모든 대형 보험사 IT실에는 이런 시스템이 하나씩 있다. 30년을 버틴 코어. 그걸 짠 사람들은 떠났다. 새 인력은 COBOL을 배우려 하지 않는다. 그리고 그 시스템은 매일 수십억 원의 보험금을 처리한다.

이게 보험 코어 모더나이제이션의 진짜 무게다. 단순한 IT 프로젝트가 아니라 보험사 전체의 기업 연속성의 문제다. 한 번 실수하면 회사가 무너질 수 있다. 그래서 보험사는 가장 보수적인 IT 산업이고, 동시에 가장 절박하게 모더나이제이션을 필요로 한다.

Guidewire가 P&C 시장의 80%를 가져갈지, Duck Creek이 SaaS 전환으로 추격할지, Sapiens가 글로벌 다국적 시장을 장악할지, 한국 삼성SDS·일본 NTT Data가 자체 코어로 버틸지 — 이 모든 질문이 2030년에 답을 얻을 것이다.

마지막으로 한 마디. 보험은 약속이다. 30년 후의 약속을 IT가 지켜야 한다. 그게 보험 코어 시스템의 존재 이유다.

— 보험사 코어 시스템 2026, 끝.