목차
MiRi의 핵심 흐름
판단(Judge) → 행동(Act) → 검증(Verify) → 개선(Improve)
공모전이 끝난 뒤 가장 오래 남은 건 최우수상이라는 결과보다 화면 사이에 끼어 있던 질문이었다.
AI가 위험을 맞히는 것만으로 사장님과 은행 직원의 행동이 실제로 바뀔까?
위험확률이 68%라고 알려줘도 사장님은 무엇부터 해야 할지 모를 수 있다. 직원에게 SHAP 그래프를 보여줘도 누구에게 먼저 연락하고 어떤 지원을 제안할지는 여전히 사람의 몫이다. 예측과 행동 사이에는 생각보다 큰 간격이 있었다.
나는 MiRi에서 서비스 기획과 UI/UX 디자인을 맡았다. 그래서 이 글은 모델 자체보다 고객 앱과 직원 콘솔이 같은 판단 흐름을 공유하도록 어떻게 설계했는지에 초점을 맞춘다.
첫 목업에서 먼저 확인하고 싶었던 것
초기 목업은 완성 화면을 만들려는 작업이 아니었다. 짧은 시간 안에 다음 세 가지 가설을 확인하려는 도구였다.
- 사장님이 위험 신호를 이해하고 다음 행동을 선택할 수 있는가?
- 직원이 개입이 필요한 고객을 골라 근거와 지원안을 함께 검토할 수 있는가?
- AI 추천 뒤에 사람의 승인과 사후 검증을 남길 수 있는가?
그래서 처음부터 고객 앱과 직원 대시보드를 따로 만들었다. 두 화면은 생김새는 달라도 같은 질문을 공유해야 했다.
- 지금 무슨 신호가 보이는가?
- 왜 이 신호가 중요하다고 판단했는가?
- 다음으로 무엇을 할 수 있는가?
- 실제 행동 뒤에 무엇이 달라졌는가?
사장님 앱: 위험을 숫자가 아니라 다음 행동으로 보여주기
초기 사장님 앱은 C0부터 C4까지 다섯 단계로 이어졌다.
- C0: 정보 활용 동의와 데이터 연결
- C1: 사업 현황 확인
- C2: 위험 신호와 예상 시점 확인
- C3: 지원 정책과 대응 방법 탐색
- C4: 상담 신청
처음에는 C2 화면에 위험확률과 예상 시점을 비교적 직접적으로 보여줬다. 판단 근거를 숨기지 않으려는 의도였다. 하지만 숫자를 정확히 보여주는 것과 사용자가 그 숫자를 올바르게 받아들이는 것은 다른 문제였다.
사장님에게 중요한 건 모델의 확신도보다 지금 어떤 변화가 있었고 무엇을 먼저 확인해야 하는지였다. 그래서 최종 고객 흐름에서는 원시 확률을 앞세우기보다 매출·고정비·상권 변화와 AI 진단을 읽기 쉬운 언어로 정리하고, 확인 가능한 지원과 상담으로 이어지게 했다.
여기서 바뀐 건 표현 방식이었고, 유지한 건 행동 구조였다.
신호를 확인한다 → 원인을 이해한다 → 가능한 지원을 살핀다 → 상담을 요청한다
직원 대시보드: 분석 화면이 아니라 업무 흐름으로 만들기
직원 화면은 초기 목업 단계에서 이미 네 가지 업무로 나뉘어 있었다.
- E2 주목 차주: 오늘 먼저 살펴볼 고객의 우선순위 큐
- E3 고객 상세: 위험 시점과 판단 근거, 고객 상황 확인
- E4 개입 관리: AI 추천안을 직원이 검토·수정·승인
- E6 검증: 개입 전후 변화와 후속 조치 확인
이 구분은 최종 기능명세에서도 유지됐다. 모델 결과를 보여주는 대시보드가 아니라 직원의 실제 판단 순서에 화면을 맞춘 것이다.
특히 E2가 중요했다. 위험 모델이 많은 고객에게 점수를 붙이더라도 직원이 모든 고객을 동시에 상담할 수는 없다. 결국 제품이 답해야 할 질문은 “누가 위험한가?”만이 아니었다.
오늘 누구를 먼저 보고, 왜 먼저 봐야 하는가?
그래서 주목 차주 화면에는 위험등급만 두지 않고 위기유형, 변화 신호, 담당자, 상담 상태를 함께 배치했다. 숫자는 정렬 기준이고, 직원이 실제로 확인할 맥락은 그 옆에 있어야 했다.
고객과 직원을 하나의 루프로 연결하기
기능명세 단계에서 두 제품은 하나의 폐쇄형 흐름으로 정리됐다.
1. 판단 — Judge
LightGBM 멀티호라이즌 모델이 3개월·6개월·12개월 위험을 각각 계산한다. 입력에는 매출과 자금, 금융 상태, 상권, 리뷰와 운영 정보 등 28개 피처가 사용된다.
SHAP은 점수에 영향을 준 신호를 설명한다. 직원은 단순히 등급만 보는 대신 매출 하락, 자금 경색, 상권 변화처럼 어떤 요인이 판단에 영향을 줬는지 함께 확인한다.
2. 행동 — Act
판단 결과는 고객과 직원에게 서로 다른 방식으로 전달된다.
- 고객에게는 이해하기 쉬운 위험 설명과 가능한 지원 행동을 보여준다.
- 직원에게는 우선순위, 상세 근거, 지원 후보와 상담 문구를 제공한다.
LLM은 지원안을 마음대로 결정하지 않는다. 모델과 규칙 엔진이 위험유형과 지원 후보를 정하고, LLM은 그 결과를 고객 설명이나 상담 스크립트로 바꾼다.
3. 검토와 승인 — Human in the loop
AI가 만든 추천안을 바로 고객에게 보내지 않도록 했다. 직원이 지원 항목을 선택하고, 상담 문구를 수정하고, 최종 실행을 승인한다.
금융 맥락에서는 이것이 단순한 UX 선택이 아니었다. 누가 판단했고 누가 승인했는지 남기는 책임 경계였다.
AI가 잘하는 일은 많은 신호를 빠르게 정리하고 초안을 만드는 것이다. 직원이 해야 하는 일은 고객의 실제 상황을 고려해 적용 여부를 결정하는 것이다. 두 역할을 섞지 않는 것이 중요했다.
4. 검증 — Verify
개입 뒤에는 위험점수와 주요 지표가 어떻게 달라지는지 추적하도록 설계했다. 직원은 30일·60일·90일 단위 변화와 상담 결과를 보고 후속 조치를 판단한다.
다만 여기에는 중요한 경계가 있다.
최종 화면에 나온 위험점수 하락과 개선율은 프로토타입 시나리오를 보여주기 위한 예시 값이다. 실제 고객을 장기간 운영해 개입 효과를 입증한 수치가 아니다.
따라서 이 프로젝트가 실제 금융 효과를 검증했다고 말할 수는 없다. 우리가 만든 것은 효과를 검증할 수 있도록 전후 기록과 후속 판단 지점을 제품 안에 배치한 구조였다.
5. 개선 — Improve
검증 결과는 다음 상담과 모델 개선으로 돌아간다. 어떤 지원이 선택됐는지, 직원이 무엇을 수정했는지, 이후 신호가 어떻게 변했는지가 다음 판단의 근거가 된다.
이 단계까지 연결하면서 MiRi는 단순 위험예측 화면에서 다음 루프로 바뀌었다.
판단 → 행동 → 검토·승인 → 검증 → 개선
결정적 코어와 LLM 가장자리
기술 구조에서도 같은 원칙을 적용했다.
위험점수, 등급, 위기유형, 정책 매칭처럼 재현 가능해야 하는 판단은 LightGBM·SHAP·규칙 엔진이 맡는다. LLM은 그 결정을 직원과 고객이 읽을 수 있는 설명, 상담 문구, 질의응답으로 바꾼다.
이 역할 분리를 팀에서는 결정적 코어 + LLM 가장자리라고 불렀다.
- 같은 입력에는 같은 판단이 나와야 하는 영역은 결정적으로 유지한다.
- 자연어 표현과 탐색이 필요한 영역에만 LLM을 사용한다.
- 추천안을 실제로 적용하기 전에는 직원이 검토한다.
- 동의, 마스킹, 감사기록 같은 운영 경계를 별도로 둔다.
LLM이 모든 것을 결정하게 하는 것보다 덜 화려해 보일 수 있다. 하지만 금융처럼 설명과 책임이 중요한 영역에서는 이 구조가 더 현실적이었다.
초기 목업에서 최종안까지 달라진 것
초기 목업과 최종 프로토타입을 비교하면 모든 기능이 새로 생긴 것은 아니다. 핵심 흐름은 초기에 이미 있었고, 최종 단계에서 표현과 책임 경계가 구체화됐다.
| 초기 가설 | 최종 프로토타입에서의 변화 |
|---|---|
| 고객에게 위험확률과 예상 시점을 직접 표시 | 원시 확률보다 변화 신호와 다음 행동을 앞에 배치 |
| 지원정책을 목록으로 제시 | 고객 상황과 위기유형에 맞는 지원 후보로 연결 |
| 직원에게 위험고객 목록 제공 | 우선순위·담당자·상담 상태가 있는 업무 큐로 구체화 |
| AI가 개입안과 상담문구 추천 | 직원 선택·수정·승인 단계를 명확히 분리 |
| 개입 전후 점수 비교 | 30·60·90일 추적과 후속 판단 구조로 확장 |
| 화면별 기능을 각각 설계 | Judge → Act → Verify → Improve의 공통 루프로 통합 |
가장 큰 변화는 화면의 완성도가 아니었다. 예측 결과를 누가 읽고, 누가 결정하고, 그 뒤 무엇을 확인할지가 더 명확해진 것이었다.
모델 수치가 증명하는 것과 증명하지 않는 것
최종 발표자료의 모델 비교에서는 5-fold OOF AUC가 다음과 같이 정리됐다.
- 3개월: 0.757
- 6개월: 0.760
- 12개월: 0.747
이 수치는 합성 5,000건을 사용한 해커톤 프로토타입 평가 결과다. 실제 은행 고객을 대상으로 장기간 운영한 상용 모델 성능이 아니다.
그래서 이 글에서 수치를 사용하는 목적은 “실서비스 성과를 입증했다”가 아니다. 제한된 조건 안에서도 세 시점의 위험을 분리해 판단하는 모델을 만들고, 그 결과를 제품 흐름에 연결했다는 범위까지만 설명하기 위해서다.
이 프로젝트에서 내가 배운 것
처음에는 좋은 화면을 만들면 모델 결과가 자연스럽게 행동으로 이어질 거라고 생각했다. 하지만 실제로 어려운 건 화면을 그리는 일이 아니라 판단의 책임을 나누는 일이었다.
- 고객에게 어디까지 보여줄 것인가?
- 직원이 확인해야 할 근거는 무엇인가?
- AI가 추천할 수 있는 범위는 어디까지인가?
- 실제 실행은 누가 승인할 것인가?
- 결과를 어떻게 기록해야 다음 판단이 나아지는가?
이 질문에 답하면서 UI는 정보를 담는 그릇이 아니라 AI와 사람 사이의 책임 경계를 만드는 장치가 됐다.
MiRi는 상용 금융 서비스가 아니라 19일 동안 만든 해커톤 프로토타입이다. 하지만 초기 가설을 고객과 직원의 연결된 흐름으로 구체화하면서 한 가지는 분명하게 배웠다.
좋은 예측은 숫자에서 끝나지 않는다. 누군가 이해하고, 행동하고, 다시 확인할 수 있을 때 비로소 제품이 된다.
다음 글에서는 이 제품을 만드는 동안 다섯 명과 여러 AI가 같은 맥락을 어떻게 공유했는지, Context Hippo 협업 방식을 정리한다.