사고접수와 동시에 보험금을 받는다면? | 카카오페이 기술 블로그

시작하며

안녕하세요, 카카오페이손해보험 백엔드 엔지니어 루카스예요! 지금 읽고 계신 글은 if(kakaoAI)2024에서 공유한 내용입니다. 그러면서도 우리가 이 비즈니스를 시작하면서 추구했던 방향에 대한 이야기이기도 해요.

if kakao 세션 주제에 대한 고민이 있었어요. ‘기술적으로 깊게 파고들어 간 이야기도 좋을 텐데, 우리가 만들어간 가치에 대해서 얘기해 볼 수 있을까’하는 생각이었죠. 여러 시도들을 말씀드리는 것도 충분히 좋은 기술세션이 될 수 있다고 느껴졌어요.

우리는 보험을 합니다

우리는 모두 보험을 가지고 있습니다. 가입된 보험에 관심이 많든 적든 어떤 위험에 보장받고 있죠.

재해나 각종 사고 따위가 일어날 경우의 경제적 손해에 대비하여, 공통된 사고의 위협을 피하고자 하는 사람들이 미리 일정한 돈을 함께 적립하여 두었다가 사고를 당한 사람에게 일정 금액을 주어 손해를 보상하는 제도.

이렇게 정의된 보험을 통해서 사고나 문제가 있다면 보험금을 지급하면서 그 손해에 대해 보상하고 있어요.

보험금 청구, 즉 사고접수를 하는 것은 대게 스트레스와 불안을 동반하는 불편한 경험입니다. 사고나 질병으로 인해 육체적, 정신적으로 힘든 상황에서 복잡한 절차와 불확실성이 더해지죠. 이런 고객의 상황에서는 신청을 위한 과정도 익숙하지 않고, 필요한 서류를 준비하는 것도 어렵게 느껴집니다. 그리고 접수 이후에 긴 시간이 소요되는 경우엔 현재 어떤 상황인지 궁금하기도 했습니다.

이렇게 고객이 접할 서비스도 개선해야 했고, 더불어 저희는 상대적으로 작은 팀 규모에서 많은 청구 건들을 효율적으로 빠르게 처리해야 하는 고민도 있었습니다. 그렇게 하지 못하면 고객의 경험은 더 나아지지 않을 것 같다는 걱정이 들었죠.

우리가 설정한 방향

그래서 저희는 정확하고 빠른 보험금 지급이라는 목표를 세우게 되었습니다. 무언가 심플한 표현 같기도 하지만 여기엔 여러 해결해야 할 문제들이 산적해 있었습니다. 그중에서 공유드릴 내용을 적어봤어요.

레거시 분할 정복
빠른 문서 인식
프로세스 자동화

저희는 이 문제들을 해결하여 보험금을 즉시지급하는 프로세스를 마련하고자 했습니다.

첫 번째 해결! “레거시 분할 정복”

개발자라면 레거시를 피할 수 없죠! 저희도 마찬가지였습니다. 하지만 약간 다른 게 있었어요. 레거시는 대게 익숙한 환경일 겁니다. 하지만 우리는 그 레거시 시스템을 잘 이해하지 못하는 상황이었습니다. 여러 이유로 낯선 코드들을 기반으로 운영되고 있었죠. 코드뿐만 아니라 도메인도 어렵게 느껴졌습니다. 하지만 우리는 사업을 시작했고 시간이 없었습니다!

기간계.. 코어..

그때의 막막한 감정을 조금은 더 깊이 공유하고자 한 발짝 더 들어가 보겠습니다. 기간계라고 불리는 코어 시스템은 무려 70,000,000!!😱 칠천만 라인이나 되는 코드로 구성되어 있었어요. 이 코드들은 보험 도메인 모듈이라는 동굴 속에 깊이 잠들어있었고, 모듈들은 파악하기 매우 어려운 기준으로 서로서로 의존하고 있었습니다. 보통 우리는 이러한 상황을 기준이 없다고 합니다.. 이 코드를 한줄한줄 읽고 비즈니스를 파악한다면 아마 은퇴를 해도 되지 않을까 하는 기대도 가졌지만! 그전에 본능적으로 이 시장에서 살아남을 수 없다고 느껴졌습니다.

불도저 프로젝트

타이틀을 보고 느껴지시나요? “그래, 어제는 잊고 싹 다 밀어버려요!!!🥹“라고 하기엔 기존 코어 시스템도 굴러가고 있던 상황이었습니다. 아무리 급진적인 변화를 위해 접근해도 과정은 섬세해야 했어요.

생각해 보면 수많은 코드가 모두 잘 사용되고 있지 않을 수도 있어요. 실행되더라도 애플리케이션 동작에 영향을 미치지 않을 수 있고, 아예 실행되지 않는 코드들도 있을 거예요. 우선 압도적인 코드량에 맨몸으로 맞설 수는 없습니다. 사람은 도구를 써야죠. 그래서 런타임 데드 코드 분석 도구 ‘Scavenger’를 눈여겨보고 적용해 보았습니다.

디버깅이나 로그를 추가하지 않아도 메서드 호출을 시각화하여 볼 수 있었습니다. 워크스페이스를 구성하고 스냅샷을 통해 패키지 단위로 들어가 메서드 호출 범위를 알 수 있게 되는 거죠. 브라우저에서 UI를 통해 시각화된 결과를 보면서 굉장히 편했고 그만큼 확인을 위한 리소스의 낭비도 줄였습니다. 아마도 다른 곳에서는 대게 개발한 API 미사용 유무, 새로운 코드를 개발한 뒤에 이전 버전 코드 정리하는 등의 목적으로 활용했을 것 같습니다. 하지만 저희는 전체 레거시 시스템에 적용해서 효율화시켜나갔죠.

이러한 과정에서 종종 리뷰하러 PR을 보다가 흠칫 놀랄 때가 있습니다. 수만 라인부터 10만 라인 이상되는 코드들이 삭제되는 경우들이었죠. 하지만 이내 정신을 차리고 리뷰를 하고 또 과감히 merge 할 수 있었습니다.

역할의 분리

앞서 말씀드린 대로 코어 시스템은 매우 거대한 하나의 모노리틱 아키텍처로 동작했습니다. 그게 우릴 힘들게 했죠. 단순히 Monolithic 을 부정하는 것은 아닙니다. 상황에 따라 그것은 여러 이점을 주기도 합니다. 다만 우리의 환경에서는 확장성이 제한되고 유지보수도 어려웠습니다. 하나만 해도 거대한 모듈들이 수십 개나 되었고 그것이 서로 강하게 얽혀있었습니다. 로컬에서 개발하고 빌드하는 시간이 너무나 오래 걸려서 힘겨워했고, 여러 대응 방안 중에 하나가 당시 Apple Silicon이 탑재된 MacBook Pro를 빠르게 공수했던 당시 상황은 그만큼 간절하게 기억되네요. 🙏🏻 그래서 보상 서비스에 대한 역할을 고민하며 분리하기로 했습니다!

claim-channel
- 사고접수, 서류안내, 담당자 배당, 사고조사 등과 같은 역할을 수행해요.
- 주로 채널 서비스와 연관된 기능들을 담고 있어요.
claim-core
- 신뢰성 높은 보험금 계산을 제공해요.
- 점진적으로 보상의 핵심 데이터를 구성하고 처리하기 위한 비즈니스 로직을 갖춰나가고 있어요.
margarine
- 컨슈머 애플리케이션이에요. 알림톡, 서류 인식 요청, 지급 후처리 등을 처리하죠.
- 그 이름은 엉뚱하게도 어느 날 마가린밥을 같이 먹다가 떠올랐어요. “아! Kafka 통해 발행되는 메시지를 마가린처럼 부드럽~게 처리할 수 있는 우리만의 워크로드가 필요해요!“🧈

보상이라는 도메인을 우리만의 시각으로 해석하고 조금씩 만들어간 모습이에요.

Spring Boot, Spring Kafka, Spring Cloud, Corretto, QueryDSL, jOOQ, Sentry…

이렇게 마구 나열할 수 있는 우리에게 익숙한 것들을 적극적으로 적용할 수 있었습니다. 유연하면서 개발 생산성도 높아졌고, 장애가 전파될 수 있는 상황에서도 격리시켰습니다. 배포는 말할 것도 없고, 애플리케이션의 성능도 높아졌습니다. 그간 마음속에 기술부채로 쌓여있던 것들을 해소할 수 있어서 팀 크루들도 더 힘을 얻을 수 있었죠!

두 번째 해결! “빠른 문서 인식”

기존의 방식

보상 처리를 위해서는 어떤 사고를 당했는지 알아야 해요. 그래서 사고접수 할 때, 다양한 서류를 첨부해야 해요.

진료비 영수증, 진료비 세부 내역서, 입/퇴원 확인서, 수술확인서
수리 비용 영수증, 사실 확인용 사진, 수리 견적서
교통사고사실확인원, 소송 진행 확인 서류, 벌금 영수증

정말 다양하죠? 그리고 상황에 따라 필요한 서류들이 다를 수 있습니다. 고객의 서류를 검토하는 과정에는 사람이 필요합니다. 눈으로 서류를 확인하고, 필요한 정보들을 손으로 타이핑하여 입력하죠. 이러한 중요한 과정은 필요하지만 그만큼 시간을 많이 쓰는 작업이기도 합니다. 대응하는 담당자들이 더 많다면 N명만큼의 처리량을 기대할 수 있겠죠. 하지만 사람의 개입이 많아지는 것만큼 일관성, 인건비, 확장성, 품질관리, 규제준수 복잡성, 인프라 비용 등 여러 고민도 같이 늘어가게 됩니다. ~~담당자의 퇴근도 중요함~~ 우리는 이런 구조적인 문제들을 조금씩 개선하고 싶었고 싶었고, 그러기 위해서는 자동화하여 문서를 빠르게 인식하는 프로세스가 필요했어요.

Document AI

우리는 이 과정을 Document AI로 접근해 보았습니다. AI를 활용하여 다양한 형태의 문서를 자동으로 처리, 분석, 이해하는 기술을 의미해요. 기계 학습, 자연어 처리 등을 통해서 문서에서 필요한 정보를 빠르고 정확하게 알아낼 수 있죠.

TrOCR

Transformer-based Optical Character Recognition

TrOCR은 Document AI의 한 부분으로 볼 수 있어요. 이미지에서 텍스트를 추출하는 이 기술은 어떤 특징을 가지고 있을까요?

Transformer 기반의 이미지 인코더와 텍스트 디코더를 사용합니다.
사전 학습된 비전 모델과 언어 모델을 활용하여 성능을 향상합니다.
인쇄된 텍스트와 손글씨 모두에 대해 우수한 인식 성능을 보입니다.

위와 같은 특화된 모델을 포함한 여러 태스크들을 통해 첨부된 영수증을 인식할 수 있습니다.

Edge Detection → Layout Analysis → OCR → Parsing

문서에서 텍스트를 효과적으로 추출하기 위해 구성한 체계적인 접근 방식입니다. 각각의 단계가 서로 유기적으로 연결되어 높은 정확성과 효율성을 보장합니다.

세 번째 해결! “프로세스 자동화”

혹시 보상 사고접수를 해보신 경험이 있나요? 그렇다면 대게 그 이후에 시간이 지나 보험금을 수령하셨겠죠. 이런 과정 안에는 상당히 많은 단계가 존재합니다. 여기서도 사람이 많이 개입하게 되지요. 케이스에 따라 사고접수 이후의 단계들을 자동화할 수 있었습니다. 고객에게 가장 빠르게 보험금을 줄 수 있는 방법이었죠.

보험금 계산 자동화를 향한 첫걸음

구현하는 과정 중에서 보험금 계산에 대해서 고민이 있었어요. 정확한 보험금을 드리기 위해서는 보험약관에 명시된 다양한 기준들을 파악해야 합니다. 계산방식을 자동화하기 위해 규칙들을 시트에 기록하고 검토하는 과정이 필요했어요. 처음부터 모든 것을 자동화할 수는 없지만 첫걸음이 중요하다고 생각했죠. 첫걸음을 잘 내딛기 위해 초반에 어떤 방향으로 구축해 나갈지 잘 선택해야 했어요.

문득 떠오른건 BRMS(Business Rule Management System)였습니다. 많은 기업에서 활용하고 있기도 해요. 시각적인 도구를 활용해서 룰을 효율적으로 설정하고, 적용을 위해서 개발자가 만든 코드가 배포될 필요도 없는 경우도 있어요. 여러 장점이 있지만 우리 팀에서 적용하는 게 과연 괜찮을지 걱정되기도 했습니다. 탄력적으로 개발할 수 있는지, 어떤 특정 플랫폼에 종속되는 건 아닌지, 확장성뿐만 아니라 비용도 많이 들 거구요. 개발자는 코드개발이 아닌 특정 도구에 익숙해져야 할 텐데 결국 개발문화에도 영향이 있다고 보였습니다.

보험금 계산기

여러 고민 끝에 우리는 외부의 선택지를 포기하고 직접 만들기로 결정했어요. 내재화의 모습은 앞에서도 말씀드린 claim-core 애플리케이션이었습니다. 여기서 도메인에 대한 고민과 테스트 코드, Grafana를 통한 모니터링, Spring Cloud 스택과 통합되는 방향으로 개발할 수 있었습니다. 우리에게 익숙한 모습으로 말이죠!

컨셉은 이렇게 되어 있어요. OCR을 통해 서류에서 인식된 ‘입원’이라는 조건이 전달되면 그와 맞는 계산식을 도출합니다. 그리고 피해금액, 보장한도와 같은 추가적인 요소들과 함께 계산되어 고객이 받아야 할 보험금이 나올 수 있게 되는 거죠. 이 과정에서 얼마나 다양하고 복잡한 조건들을 유연하게 구성하는 것이 까다로운 과정이었습니다.

그걸 코드로 구현하면서 다양한 토론이 있었습니다. 당장의 단기적인 구현보다 장기적인 유지보수와 확장성을 고려했습니다. 초기에 시간을 투자하여 좀 더 견고하게 설계를 하면, 장기적으로 개발과 유지보수 비용을 낮출 수 있을 거라 기대했습니다. 그런 관점으로 접근하여 그중 하나로 계산기라는 인터페이스를 만들었고, 그와 연결되는 여러 주제의 계산기 구현체를 구성했습니다. 특히 다음의 관점에서 고민해 보았죠.

public interface Calculator {

    DecimalFormat DECIMAL_FORMAT = new DecimalFormat("#,###");

    // 계산기명
    String name();

    // 산출식 코드명
    String calculatorCodeName();

    // 계산결과 제공
    BigDecimal calculate(CalculatorValue calculatorValue);

    // 계산결과를 계산식으로 제공
    String calculationFormula(CalculatorValue calculatorValue);

    // 통화 스타일로 변경 (000,000,000)
    default String toCurrency(BigDecimal amount) {
        return DECIMAL_FORMAT.format(amount);
    }
}//..

전략 패턴 (Strategy Pattern)
- 알고리즘 군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있게 합니다.
- 유연성, 코드 재사용, 확장성을 고려하여 개발할 수 있었습니다.
- 보험금 계산에서 다양한 계산 방식을 쉽게 추가하고 교체할 수 있었죠.
OCP (Open-Closed Principle, 개방-폐쇄 원칙)
- 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다는 원칙입니다.
- 기존 코드를 수정하지 않고 새로운 기능을 추가할 수 있습니다. 그래서 기존 기능의 오작동을 줄이고, 새로운 요구사항에 쉽게 대응합니다.
- 새로운 보험금 계산 방식을 추가할 때, 기존 코드를 수정하지 않고 새로운 클래스를 추가하는 방식으로 구현할 수 있었습니다.

이런 고민과 실행은 우리만의 코드로 만들어지고, 더 나은 개발문화뿐만 아니라 비즈니스 변화에 더 빠르고 유연하게 대응할 수 있는 토대를 갖추게 되었습니다.

규칙을 바꿀 시간

워크플로

우리는 어떤 워크플로를 구축했을까요? 내부엔 더 복잡한 것들이 있지만 축약해서 표현해 보았습니다.

고객이 사고접수를 하면서, 모바일로 촬영한 서류 이미지를 첨부합니다.
여러 이미지들은 S3 버킷에 업로드됩니다.
동시에 AWS Lambda가 트리거 되면서 악성코드탐지, 다양한 이미지 처리 등을 수행합니다.
OCR 통해서 문서에서 주요한 정보를 추출합니다.
claim 서비스를 통해 여러 자동화 프로세스가 수행됩니다.
그 과정에서 정확한 보험금도 계산되어 고객에게 바로 지급하게 되지요!

이 과정은 매우 순식간에 일어납니다. 기존에 단계별로 사람이 거쳐가야 했던 과정들을 과감히 생략하여 자동화에 의지할 수 있죠.🚀

비용과 효율

보험금을 지급하기까지의 과정에는 담당자가 직접 입력하고 조사하는 비용이 필요하고 상당히 많은 부분을 차지하고 있습니다. 아이디어를 떠올리고 실현하는 과정에서 여러 스텝을 자동화할 수 있었습니다.

보험금 즉시지급 워크플로로 처리된 대상은 기존 방식에 비해 처리비용을 무려 90% 이상 줄일 수 있었습니다. 멋지죠? 그리고 처리속도에 대해서도 살펴볼까요? 1분 내에 벌써 30% 이상 처리했고, 10분 내에도 70% 정도로 대부분의 양을 처리할 수 있었습니다. 낮은 비용, 빠른 처리속도, 더 많은 처리량은 기업뿐만 아니라 고객에게도 더 좋은 경험을 주고 있다고 생각합니다.

One more thing

일반적으로 고객이 사고접수를 위해 직접 모바일을 통해 들어오시죠. 그런데 우리가 먼저 사고를 알려주고 접수를 안내한다면 너무 좋은 경험이겠다고 생각했습니다. 고객의 사고접수를 단순히 비용이라고 생각하지 않으면서, 고객이 잊고 넘어갈 수 있는 부분을 알려드리면 차별화된 모습으로 기억될 것 같았어요. 이런 과감한 시도는 엔지니어를 설레게 한답니다!

해외여행보험에 가입하면서, 비행기 지연 상황을 보장하신 분들에게 알려드리려고 했어요. 저도 슬픈 경험이 있습니다! 공항에서 갑자기 비행기가 지연되었다는 사실을 알게 되어 너무 당황스럽고 슬프더라구요.. 우리는 이때 지연된 사실을 먼저 고객에게 알려주고, 보험금도 빠르게 지급한다면 작은 위안이 될 수 있을 거라고 생각했어요. 이를 위해 공항공사와 소통하면서 우리가 판단할 수 있는 적정한 데이터를 OpenAPI를 통해 제공받았습니다.

먼저 항공운항스케줄 데이터를 주기적으로 적재합니다. (하계/동계 스케줄)
출국 당일 공항에 있을 고객들에게 기본적으로 안내하는 알림톡을 발송합니다.
그러다 비행기가 지연이 발생했다면, 그 항공편을 이용하는 고객들에게 알림톡을 발송합니다. 기다리시는 동안 공항 내에 있는 식당이나 편의점, 라운지 등 편의시설을 이용하면 비용을 지원해 드린다는 내용이에요.
그렇게 접수가 되었다면 보험금 즉시지급 프로세스를 통해 아주 빠르게 지급합니다! 조금이라도 위안이 되신다면… 우리는 합니다!

피드백

보험 시장에서 그동안 주지 못한 것들이 있다고 생각해요. 그리고 고객들도 보장에 대해서 정확히 알지 못하는 상황도 매우 많았죠. 이러한 환경에서 다양한 고민을 했고 엔지니어링을 통해 구현해 나갔습니다.

모든 상품에 대해서 자유롭게 피드백을 받고 있습니다. 고객들의 수만 개나 되는 피드백이 쌓여있는데 기쁘게도 긍정적인 의견들이 많아요. 그중에서 보험금 지급까지의 과정이 매우 빠르게, 1분 만에 처리된 경험을 많이 공유해 주셨습니다. 더불어 항공기 지연 알림 서비스도 위안이 되었다며 글을 남겨주시는 분들도 있었어요. 이런 피드백을 볼 때마다 너무 감사드리고 뿌듯함을 느낍니다. 우리 팀에 함께한 백엔드 엔지니어 분들 뿐만 아니라 같이 만들어갔던 크루들 모두 보람을 느끼는 순간이 아닐까 해요.

마치며

이 주제로 if kakao 2024에서 발표하기도 했답니다. 준비하는 과정은 결코 쉽지 않았지만 그 경험은 무척 즐겁고 소중하게 기억되고 있습니다. 다양한 기술을 연결해 가며 만들어갔던 여정을 공유드렸고 지금 이 순간에도 더 나은 가치를 위해 달리고 있습니다. 보험이라는 주제가 어렵게 느껴질 수도 있어요. 하지만 앞으로도 다양한 세션과 이곳 기술 블로그를 통해 보험과 기술에 대해 더 다양한 이야기를 들려드릴 수 있도록 노력하겠습니다!