티스토리 뷰
손사가 직접 만든 추가청구 검토 도구 — 자동화의 경계를 어디에 그을 것인가
배승휴팀장 2026. 5. 29. 16:18어제 글에서 잠깐 말한 그 도구
어제 글에서, 사고 하나로 의뢰가 들어와도 의뢰인의 과거 5년 진료내역까지 확인한다는 이야기를 했습니다. 그 검토 작업을 빠짐없이 하기 위해 만든 웹앱이 있다고도 했습니다.
오늘은 그 도구를 어떤 원칙으로 만들었는지를 정리하려고 합니다. 구체적인 분류 로직이나 매칭 규칙은 다루지 않고, 만들면서 가장 먼저 정한 원칙들에 대한 이야기입니다. 손해사정사가 직접 자동화 도구를 짜는 일이 어떤 작업인지를 보여주는 글에 가깝습니다.

정확도가 아니라 "무엇을 하지 않을 것인가"
만들기 전에 제일 먼저 정한 것은 "정확도를 어디까지 끌어올릴 것인가"가 아니었습니다. "이 시스템이 무엇을 해서는 안 되는가"였습니다.
자동화 도구를 짤 때 흔한 욕심은 모든 결과를 시스템이 내주게 만드는 것입니다. 그런데 보험금 인정 여부는 약관 + 의무기록 + 사정사 판단이 함께 작동하는 영역입니다. 약관 한 줄에 따라 같은 진단이라도 보장 여부가 갈리고, 의무기록 전체 맥락이 결과를 좌우합니다. 진료 코드와 처치 기록만 보고 결론을 단정하는 순간, 도구는 도움이 아니라 위험이 됩니다.
그래서 출력 방식을 이렇게 잡았습니다. 시스템은 "이런 패턴이 보인다, ○○ 담보 검토 대상으로 보인다, 신뢰도는 ○○이다"까지만 짚어줍니다. 청구가 되는지를 말하는 것이 아니라, 검토할 가치가 있는지를 말하는 것입니다. 최종 판단은 사람이 합니다.

신뢰도를 단일 라벨로 두지 않은 이유
"검토 대상" 하나로 모두 묶어버리면 그것대로 문제가 생깁니다. 거의 분명한 건과 가능성만 있는 건이 같은 무게로 표시되면, 검토할 때 우선순위가 보이지 않습니다. 결과적으로 사정사가 시간 분배를 잘못하게 됩니다.
그래서 신뢰도를 다섯 등급으로 나눴습니다.
- 확정 — 진단·처치만으로도 거의 분명한 청구 대상
- 유력 — 패턴이 강하지만 약관 확인이 필요한 영역
- 후보 — 가능성이 있어 검토할 가치가 있는 영역
- 확인필요 — 추가 정보 없이는 판단을 미루는 영역
- 관찰 — 가능성이 있지만 실제 분쟁 경험이 적어 일단 띄워두는 영역
각 등급은 색으로 구분되어 한눈에 강약이 보입니다. 어디부터 깊게 파야 할지가 정렬돼서 나옵니다.

처음부터 완벽하게 짜지 않는 방식
처음엔 욕심이 있었습니다. 가능한 모든 패턴을 다 잡아내는 시스템. 그런데 그 방향으로는 가지 않았습니다.
규칙을 넓게 깔면 오탐이 폭증합니다. 별것 아닌 진료가 청구 대상으로 떠서 노이즈가 잔뜩 끼고, 정작 중요한 신호가 묻힙니다. 반대로 규칙을 좁히면 누락이 생깁니다. 둘 다 위험합니다.
그래서 방식을 바꿨습니다. 처음엔 핵심 패턴만 깔고, 실전에 돌리면서 오탐이 나오면 그 케이스에 맞춰 규칙을 좁힙니다. 누락이 보이면 그 케이스를 보고 규칙을 추가합니다. 점진적으로 정밀화하는 방식입니다.
이게 가능한 이유는 제가 손사라는 점에 있습니다. 어떤 케이스가 진짜 청구 대상이고 어떤 게 노이즈인지, 코드를 짜는 사람이 알고 있어야 규칙을 정밀화할 수 있습니다. 개발자 혼자 짰다면 "이게 맞는 분류인가"를 손사에게 매번 물어봐야 했을 것이고, 그 사이 컨텍스트가 끊기면서 정밀도가 떨어졌을 것입니다.

자동화로 풀 수 없는 영역
만들면서 "이건 코드로 못 푼다"가 명확해진 영역들이 있습니다. 향후에도 시도하지 않을 영역으로 정해뒀습니다.
- 데이터 자체의 한계 — 진료 데이터에 구조적으로 빠지는 정보가 있습니다. 어떤 진료 정보는 시스템 단계에서 보이지 않습니다.
- 비급여 항목 — 급여청구 기반 데이터에는 들어오지 않습니다. 어떤 API로도 가져올 수 없습니다.
- 약관 해석 — 같은 진단이라도 가입한 상품의 약관에 따라 보장 여부가 달라집니다. 이건 시스템의 영역이 아닙니다.
- 의무기록의 맥락 — 왜 그 검사를 했고, 의사가 어떤 판단을 했고, 어떤 경위로 그 상병이 잡혔는지는 의무기록 전체를 봐야 알 수 있습니다. 진료 코드만으로는 잡히지 않습니다.
이 영역들은 결국 사람이 봐야 합니다. 시스템은 "여기 봐야 할 게 있다"까지만 말하고, 그 다음은 의무기록을 받고 약관을 읽고 의뢰인의 이야기를 들으며 사정사가 판단합니다.

결국 경계의 문제
도구를 만들면서 가장 분명해진 건, 자동화 작업이 결국 "사람이 할 일과 기계가 할 일의 경계를 어디에 그을 것인가"를 정하는 일이라는 점입니다.
이 도구의 경계는 분명합니다. 시스템은 진단·처치 패턴에서 "검토할 가치가 있는 항목"을 빠짐없이 들춰주는 역할까지. 약관 해석·의무기록 판단·최종 결정은 사람의 영역.
저는 이 경계가 흐려지지 않게 만드는 게 도구의 정확도보다 더 중요하다고 봤습니다. 시스템이 "확정"이라고 말하기 시작하면, 사정사가 그 말에 기대 약관을 덜 보고 의무기록을 덜 보고 의뢰인의 이야기를 덜 듣게 됩니다. 자동화가 사람의 일을 정밀하게 만드는 게 아니라, 사람의 일을 줄이는 방향으로 작동합니다. 그 순간 위험이 시작됩니다.

손사가 직접 코드를 짠다는 것
손해사정 일을 10년 넘게 하면서 가장 시간이 오래 걸리고 누락도 잦았던 작업이 이 추가청구 검토였습니다. 그래서 가장 먼저 자동화 대상으로 잡은 영역입니다.
도구는 계속 다듬는 중입니다. 새 케이스가 보이면 규칙이 늘고, 오탐이 보이면 규칙이 좁혀집니다. 손사가 직접 짜는 도구라서, 이 다듬는 과정이 본업과 분리되지 않습니다. 사건을 보면서 도구가 깊어지고, 도구가 깊어지면서 사건이 더 잘 보입니다.
구체적인 분류 로직과 매칭 규칙은 글에서 다루지 않았습니다. 핵심 노하우에 해당하는 부분이기도 하고, 그보다 먼저 "이 도구를 왜 이런 모양으로 만들었는지"를 정리해두고 싶었습니다. 도구의 모양은 결국 만든 사람의 직업관에서 나오니까요.

오늘은 여기까지 정리해 두겠습니다.
'AI 이야기' 카테고리의 다른 글
| 반복 서류 작성 자동화 — 손해사정 업무에서 정형 서류를 도구로 만들기 (0) | 2026.06.12 |
|---|---|
| 직접 만든 AI 도구를 실무에 써봤습니다 — 과거 진료내역에서 놓친 청구 가능성 찾기 (0) | 2026.06.09 |
| 손해사정 업무용 보험계약 조회 웹앱을 직접 만들었습니다 — 1인 개발 구현기 (0) | 2026.05.25 |
| 비개발자가 AI만으로 직접 만든 소득정보 자동조회 웹앱 — 간편인증 한 번으로 소득 입증 서류 자동 정리 (2) | 2026.05.21 |
| 1인 전문직이 AI 도구 개발에 도전할 때 부딪치는 5가지 벽 — 손사 AX 시도 회고 (2026) (0) | 2026.05.11 |
