티스토리 뷰
손해사정 업무용 보험계약 조회 웹앱을 직접 만들었습니다 — 1인 개발 구현기
배승휴팀장 2026. 5. 25. 15:43손해사정 일을 하다 보면 상담 초기에 늘 막히는 지점이 하나 있습니다. "이분이 어떤 보험에 들어 있는가"를 빠르고 정확하게 파악하는 일입니다.
고객이 증권을 다 챙겨오는 경우는 드물고, 가입 사실 자체를 잊고 있는 계약도 많습니다. 그래서 보험계약 정보를 한 번에 조회하고 정리해주는 웹앱을 직접 만들었습니다. 외주 없이 처음부터 끝까지 혼자 붙였고, 그 과정에서 부딪힌 것들을 정리해둡니다.
무엇을 만들었나
고객이 휴대폰으로 접속해 본인 인증을 하면, 가입한 보험계약이 자동으로 조회되고 정리된 결과가 담당자에게 바로 전달되는 구조입니다. 흐름 자체는 단순합니다.
고객 인증 → 보험계약 조회 → 결과 정리 → 담당자에게 즉시 전달
겉보기엔 단순하지만, 이걸 "실제 상담 현장에서 쓸 수 있는 수준"으로 만드는 데 생각보다 많은 디테일이 필요했습니다.

기술 구성
무겁게 가지 않았습니다. 서버를 따로 두면 1인 운영에 유지보수 부담이 커지기 때문에, 최대한 가벼운 조합으로 갔습니다.
프론트엔드 — 정적 페이지 한 장. 별도 빌드 과정 없이 바로 배포·수정이 가능하게 구성했습니다.
백엔드 — 서버리스 스크립트. 별도 서버 인프라 없이 함수 단위로 동작하게 만들어, 인증·조회·결과 전송을 한 곳에서 처리합니다.
보험계약 데이터 — 마이데이터·스크래핑 기반의 보험계약 조회 API를 연동했습니다. 본인 인증을 거쳐 가입 계약을 가져옵니다.
결과 전달 — 정리된 결과는 즉시 알림으로 받고, 인쇄용 페이지로도 출력할 수 있게 했습니다.
핵심 원칙은 "입력받은 민감정보는 저장하지 않는다"였습니다. 인증 정보는 조회 목적에만 쓰고 흘려보내는 구조로 설계했습니다. 보험 가입 내역은 민감한 금융정보라, 이 부분을 가장 먼저 정했습니다.

부딪힌 것들 — 여기가 진짜 작업이었습니다
1. 인증 흐름은 한 번에 끝나지 않는다
본인 인증은 요청을 보내고, 고객이 휴대폰에서 승인하고, 그 결과를 다시 받아오는 여러 단계로 나뉩니다. 화면 하나에서 끝나는 게 아니라 단계별로 상태를 들고 다녀야 했습니다. 인증 요청 단계와 승인 확인 단계를 분리하고, 그 사이의 세션 값을 안전하게 이어 붙이는 게 첫 관문이었습니다.
2. "에러처럼 보이는 정상"과 "정상처럼 보이는 에러"
가장 까다로운 부분이었습니다. 외부 API는 여러 이유로 응답이 흔들립니다. 그런데 일시적인 서버 지연과 진짜 자격증명 오류를 같은 메시지로 뭉뚱그리면, 멀쩡한 고객에게 "비밀번호가 틀렸다"고 잘못 안내하게 됩니다. 반대로 진짜 오류를 지연으로 착각하면 고객을 끝없이 기다리게 만듭니다.
그래서 에러를 성격별로 갈랐습니다. 지연·네트워크 문제로 보이는 신호는 잠깐 기다렸다 재시도하고, 자격증명 불일치로 명확히 판별되는 경우에만 "다시 확인해 주세요"를 띄웁니다. 이 분기 하나가 실사용 만족도를 크게 갈랐습니다.
3. 모바일에서 응답이 길어지면 끊긴다
조회량이 많은 고객은 응답이 1~2분 걸리기도 합니다. 그동안 모바일 브라우저가 연결을 끊으면, 서버는 정상 처리했는데 화면은 실패로 보이는 상황이 생깁니다. 그래서 일정 시간 이상 지연되거나 연결이 끊겨도 서버가 백그라운드로 처리를 끝내고 결과를 보내는 구조로 분리했습니다. 화면은 진짜 서버 오류일 때만 되돌아가게 했고, 무한 로딩 문제가 이걸로 풀렸습니다.
4. 결과는 현장에서 바로 쓸 수 있게
조회만 되고 끝이면 의미가 없습니다. 정상 계약을 먼저 정렬해 한눈에 들어오게 하고, 만기·실효된 계약은 따로 접어뒀습니다. 인쇄 페이지를 별도로 만들어 계약별로 출력할 수 있게 했고, 정리 결과는 알림으로 즉시 받아 상담에 바로 활용합니다.
5. 작은 UX들 — 의외로 체감이 큽니다
고령 고객을 고려해 글씨를 키우고 입력 단계를 단순화했습니다.
주민번호 앞자리 입력이 끝나면 자동으로 뒷자리로 포커스가 넘어가게 했습니다.
모바일에서 인증 도중 뒤로가기를 누르면 첫 화면으로 튕기던 문제를, 직전 화면으로 돌아가도록 브라우저 히스토리를 직접 관리해 보완했습니다.
1인 개발에서 지킨 원칙
검증 없이 배포하지 않는다 — 수정할 때마다 문법 검사와 가상 테스트로 화면 전환·예외 흐름을 먼저 돌려보고 반영했습니다. 혼자 하니 "돌려보고 나서"가 더더욱 필수였습니다.
민감정보는 외부로 절대 흘리지 않는다 — 인증 자격증명·토큰류는 백엔드 안에서만 다루고, 화면이나 결과물에 노출되지 않게 했습니다.
부분 수정 우선 — 잘 돌아가는 코드를 통째로 갈아엎지 않고 필요한 곳만 외과적으로 고쳤습니다. 회귀 버그를 줄이는 가장 확실한 방법이었습니다.
결과
상담 초기에 "어떤 보험에 들어 있는지" 파악하는 시간이 크게 줄었습니다. 고객이 잊고 있던 계약, 놓치고 있던 담보를 초기에 잡아내면서 누락 청구를 줄이는 데도 도움이 됐습니다. 외부에 맡기지 않고 직접 만들었기에, 현장에서 불편한 점이 보이면 그날 바로 고칠 수 있다는 게 가장 큰 장점입니다.
다음 단계로는 진료내역 기반의 "숨은 보험금 찾기"를 붙여, 과거 사고·치료 이력과 가입 담보를 교차해 추가 청구 가능성을 자동으로 짚어주는 기능을 준비하고 있습니다.

참고로 저는 비개발자이며 오로지 AI의 도움으로만 코딩작업을 하고있습니다. 거창한 기술이 아닐뿐더러 매번 막히던 업무 한 지점을 직접 풀어낸 기록입니다. 손해사정 상담이 필요하시면 아래 명함으로 연락 주세요.

오늘은 여기까지 정리해두겠습니다.
※ 본 글은 업무 자동화 도구 개발 경험을 정리한 것으로, 실제 인증 정보·고객 데이터·내부 연동 정보는 포함하지 않았습니다.
'AI 이야기' 카테고리의 다른 글
| 직접 만든 AI 도구를 실무에 써봤습니다 — 과거 진료내역에서 놓친 청구 가능성 찾기 (0) | 2026.06.09 |
|---|---|
| 손사가 직접 만든 추가청구 검토 도구 — 자동화의 경계를 어디에 그을 것인가 (0) | 2026.05.29 |
| 비개발자가 AI만으로 직접 만든 소득정보 자동조회 웹앱 — 간편인증 한 번으로 소득 입증 서류 자동 정리 (2) | 2026.05.21 |
| 1인 전문직이 AI 도구 개발에 도전할 때 부딪치는 5가지 벽 — 손사 AX 시도 회고 (2026) (0) | 2026.05.11 |
| Hermes Agent 입문 가이드 — 텔레그램으로 조작하는 오픈소스 AI 에이전트 (2026) (1) | 2026.04.19 |
