AI 해커톤: 결승선 앞에서 멈춰 선 고객들

대출 신청을 마치고 승인까지 받았습니다. 그런데 마지막 화면에 서로 다른 세 개의 제안이 뜹니다. 4만 루피 캐시론, 1만 5천 루피 레벨업론, 7만 5천 루피 파트너론. 각각 금리도, 수수료도, 매달 갚는 금액도, 승인까지 걸리는 시간도 다릅니다. 이 모든 게 가로 360픽셀짜리 작은 휴대폰 화면에 펼쳐집니다.

고객들은 분명한 의지를 갖고 이 화면까지 왔습니다. 설문도 끝냈고, 심사도 통과했고, 승인도 받았죠. 그런데도 여기서 그냥 이탈했습니다. 저희는 계속 물었습니다. 왜?

문제는 하나가 아니었습니다. 세 가지였습니다.

첫째, 비교 과부하. 캐시론, 레벨업론, 파트너론 — 세 상품은 장단점이 완전히 다릅니다. 대부분의 고객은 '나에게 가장 잘 맞는' 대출을 고르지 않습니다. 그나마 이해되는 걸 고르거나, 숫자가 가장 큰 걸 고르거나, 아니면 그냥 떠납니다.

둘째, 이해의 간극. 4만 루피를 빌리는데 원금이 4만 2,000루피로 찍히면, 사람 본능은 이렇게 반응합니다. '이거 함정 아니야?' 수수료가 '갚을 돈에서 더해지는' 게 아니라 '받는 돈에 빠지는' 것이고, 이것을 고객에게 설명해주지 않았기 때문입니다. 당연한 방식이지만, 정작 고객에게 그 말을 해준 사람이 없었던 거죠.

셋째, 보이지 않는 유연성. 상환일을 놓친 고객은 일정을 미룰 수 있다는 걸 모릅니다. 여윳돈이 생긴 고객은 미리 갚아 이자를 아낄 수 있다는 걸 모릅니다. 이런 장치는 이미 있습니다. 다만 정작 필요한 그 순간에 한 번도 눈앞에 나타나지 않았을 뿐입니다.

세 문제를 풀 데이터는 저희 손에 다 있었습니다. 그저 쓰지 않고 있었을 뿐입니다.

임무도 둘, 화면도 둘

저희가 내린 가장 큰 결정은, Hambal을 '완전히 다른 두 개의 모드'로 나누는 것이었습니다. 각 모드는 저마다의 시스템 프롬프트(AI에게 주는 기본 지침), 추천 질문 버튼, 답변 세트를 따로 갖습니다.

대출 제안 목록 화면에서 Hambal의 임무는 '비교'입니다. 선택 앞에서 얼어붙지 않도록 부담을 덜어주고, 상품별 장단점을 보여주고, 고객의 실제 소득과 대출 목적을 바탕으로 잘 맞는 쪽을 짚어줍니다. 회사 마진이 가장 큰 상품으로 슬쩍 몰아가는 일 없이요.

대출 상세 화면에서는 임무가 '제대로 이해한 뒤의 수락'으로 바뀝니다. 계산을 하나씩 짚어주고, 왜 갚을 총액이 더 큰지 설명하고, 활용할 수 있는 유연한 장치들을 꺼내 보여줍니다. 질문이 서너 개쯤 오간 뒤에는 '확인 체크리스트'가 떠서 결정을 한 번 걸러줍니다. 진행을 방해하려는 게 아니라, 고객이 '알고 동의하도록' 하기 위해서입니다.

디자인이 로직이 되고, 로직이 AI의 행동 규칙이 되다

추천 질문 시스템 — 답할 때마다 다음에 이어질 내용에 맞춰 추천 질문이 바뀌는 구조 — 이 Hambal의 핵심 장치입니다. "얼마를 받게 되나요?"를 누르면 다음 칩은 "왜 더많이 갚나요?", "이 수수료는 뭔가요?", "제가 감당할 수 있을까요?"로 바뀝니다. 화면을 처음 열었을 때 보이던 그 뻔한 질문들이 아니라요.

그런데 이 '추천 질문 지도'는 동시에 AI 설계도이기도 했습니다. 고객이 입력하는 모든 말은 세 갈래 중 하나로 분류됩니다. (1) 대출 관련 질문 (2) 조언을 구하는 질문 (3) 범위 밖 질문. 답변 틀도, 질문 갱신도, 의도 분류도 전부 코드로 규칙화되어 있습니다 — 제안 목록용과 상세 화면용으로요. 이건 단순한 '대화 설계'가 아닙니다. AI가 각 상황에서 어긋나지 않게 붙잡아주는 규칙기반 레이어입니다.

핵심 원칙: 숫자는 백엔드가 책임지고, AI는 '문장'만 쓴다

저희가 가장 자부하는 부분이자, 해커톤 결과물에서 사람들이 잘 기대하지 않는 부분입니다. Hambal의 AI는 숫자를 지어낼 수 없습니다.

저희는 '카드 우선(card-first) 지시 엔진'을 만들었습니다. 고객이 무언가를 물으면, 생각은 백엔드가 합니다. 의도를 분류하고, 제안들의 순위를 매기고, 모든금액·수수료·월 상환액을 정해진 규칙대로 계산하죠. 그리고 여섯 가지 응답 유형(single_best, ranked, compare, clarify, explain, fallback) 중 하나를 정한 뒤, 이미 정렬이 끝난 제안 목록을 정확한 숫자와 함께 AI에게 넘깁니다. AI가 하는 일은 딱 하나 — 열 단어가 안 되는 짧은 한 줄 문구와, 이어질 예상 추천 질문 세 개를 쓰는 것뿐입니다. 순위를 매기지도, 상품을 고르지도, 넘겨받지 않은 숫자를 말하지도 않습니다.

[고객 질문] ➔ [백엔드: 의도 분류 · 제안 정렬 · 금액 계산] ➔ [응답 유형 결정] ➔ [AI: 한 줄 문구 + 예상 추천 질문만 작성]

바로 이 설계 하나가 Hambal을 실제 대출 상품에 넣어도 안전하게 만들어줍니다. AI가 4,950루피와 5,850루피의 순위를 잘못 매길 일이 없습니다. 애초에 순위를 안 매기니까요. 수수료를 틀리게 말할 일도 없습니다. 그 수수료는 AI가 호출되기도 전에 이미 계산돼 있으니까요. 숫자 하나만 잘못 지어내도 신뢰와 규제 준수가무너지는 분야에서, 저희는 계산 자체를 AI 바깥으로 완전히 빼냈습니다.

'되묻기(clarify) 루프'도 같은 발상을 애매함에 적용한 것입니다. "어떤 대출을 받아야 하죠?"라고 물으면 백엔드는 넘겨짚지 않습니다. 대신 제안들이 실제로 가장 크게갈리는 지점을 찾아, 딱 그 하나만 되묻죠. 답이 하나 들어올 때마다 후보가 걸러지고, 제안이 하나만 남는 순간 곧바로 단 하나의 추천으로 이어집니다. 되묻는 횟수는 최대 두세 번, 절대 취조하듯 캐묻지 않습니다.

그리고 AI가 보는 데이터는 고객이 고를 수 있는 게 아닙니다. 앱은 자기 세션 토큰만 보냅니다. 백엔드가 그 토큰을 두 개의 분리된 데이터베이스에 걸쳐 고객 ID로 풀어내고, 그 ID를 모든 데이터 호출에 묶습니다. 누구의 금융 데이터를 불러올지에 AI는 관여할 수 없습니다 — 다른 고객의 정보가 새어 나갈 틈 자체를 없앤 것이죠.모든 DB 조회는 정해진 형식으로만, 읽기 전용으로 이뤄집니다. 규제 관련 데이터는 서버 밖으로 절대 나가지 않습니다.

이 모든 과정은 실시간 스트리밍 방식으로 흐릅니다. '생각 중' 표시가 뜨고, 문구가 한 글자씩 살아 있는 것처럼 흘러나온 뒤, 정리된 결정은 통째로 전달됩니다 — 카드가 절반만 그려지다 마는 일이 없도록요.

디자이너에서 개발의 영역으로

저희는 디자이너로 시작했지만, 끝날 무렵엔 상용 수준의 백엔드를 직접 설계하고 만들어 배포한 팀이 되어 있었습니다. 이 부분은 굳이 겸손 떨지 않겠습니다.

두 가지 결정이 전부를 갈랐습니다.

첫째, AI는 절대 앱 안에 두지 않는다. 프롬프트 구성, AI 호출, 데이터 연결, 스트리밍 등 모든 지능은 백엔드 서비스에서 돕니다. 안드로이드 앱은 화면을 그리고 메시지를 보내는 일만 하죠. 이건 타협 대상이 아니었습니다. 규제 데이터는 반드시 서버에 있어야 하고, 시스템 프롬프트는 앱을 새로 배포하지 않고도 언제든 고칠 수 있어야 하니까요.

둘째, '격리 보장'. Hambal이 기존 앱에 손대는 곳은 딱 두 군데 뿐입니다 — 제안 목록 화면의 버튼 하나, 상세 화면의 버튼 하나. 둘 다 '더하기만' 했습니다. 기존 코드는 하나도 건드리지 않았죠. 이게 왜 중요한지를 이해하고 처음부터 그렇게 설계했다는 점 — 그게 Hambal을 '데모용'이 아니라 '실제 운영 중인 앱에 바로 넣을 수 있는' 물건으로 만들어줍니다.

What's Next? 앞으로의 계획

음성은 이미 설계에 반영해뒀습니다. 저희 고객들은 타이핑보다 말하는 걸 편해하고, 힌디어나 힝글리시(힌디+영어)에 더 익숙합니다. 같은 /chat 엔드포인트를 그대로 쓰되, 앞단에 음성 → 텍스트 변환을, 응답에 텍스트 → 음성 변환을 붙이면 됩니다. 말로 나가는 건 결국 그 '한 줄 문구'뿐이라, 정리된 카드는 지금 모습 그대로 유지됩니다.

더 멀리 보는 그림은, Hambal을 True Balance의 모든 금융 상품이 함께 쓰는 공용 서비스로 키우는 것입니다. 어려운 일은 이미 다 해냈습니다. 남은 건, 더 넓게 닿는 일뿐입니다.