네번째 프로젝트 [AI기반 카드 추천 모델]

개인적으로 최신기술에 대한 이해가 가장 늘어난 프로젝트가 아닐까싶다. 
크롤링, 데이터 정제, RAG, LLM API, 마케팅 퍼널 설계까지 다 진행했던 프로젝트라 좀 뜻깊다.
 
0. 문제 설정
새로운 프로젝트를 시작하면서 어떤 문제를 풀어볼까 고민이 많았다. 그러던 중 최근 카드를 바꾸려다 복잡한 로직때문에 그냥 기존에 쓰던 카드에 좋아보이는 카드를 하나 더 발급받은 경험이 생각나서 이 문제를 해결해보고 싶었다. 
 
0-1. 기존 카드추천 모델 점검

카드고릴라

카드고릴라

뱅크샐러드

보시다싶이 대부분의 카드추천 모델들은 데이터를 통한 랭킹이나 마케팅적인 인기순위를 기반으로 한다. 커뮤니티의 카드 추천 역시 이런이런 카드가 더 좋더라~ 의 틀을 크게 벗어나지 못한다. 
 
이는 카드의 혜택 로직이 고도화됨에 따라 하나의 카드에 하나의 계산 로직이 필요한 수준이기에 그렇다. 하나의 카드가 추가될 때 혜택의 컬럼을 추가하고, 해당 카드에 적합한 계산 로직을 만들어 추가하는것은 리소스가 매우 많이 드는 작업이다.
 
기존 시장에 풀린 카드의 수가 수천종이라는 것을 감안한다면 수천개의 혜택별 컬럼(쇼핑, 밤, 낮, 몇시부터 몇시까지 5% 추가 혜택 등)과 조건부 계산로직이 필요하다. 이런 문제를 AI를 통해 해결할 수 있지 않을까 하는 생각으로 진행하였다. 
 
1. 데이터셋 
 
AIHUB 금융 합성 데이터셋
1200컬럼, 60GB
네이버 카드 데이터 346개
 
2. 데이터 수집
네이버 카드의 카드를 크롤링해서 사용하였다
금융 데이터셋의 경우 aihub의 금융합성 데이터셋을 사용하였는데 캐글이나 여러 경로로 구할 수 있는 데이터셋 중에 가장 품질이 좋다고 판단하여 사용하였다. 
 
3. 데이터 정제
 
3-1.. AIHUB 데이터 정제 
 
1차적으로 AIHUB의 데이터를 DuckDB로 변환하여 DBeaver로 연결하여 SQL을 통해 조회하였다. 데이터 카탈로그와 SQL을 통해 조회한 데이터를 통해 추출할 데이터를 선별하였고 추출 후 파케로 변환하여 용량부터 줄였다. 
 
3-2. 네이버 카드 데이터 정제

수집된 데이터의 예시

위에서 말하였듯 하나의 카드에 포함되는 계산 로직이 이렇게 많다. 또한 반정형 형태로 이루어져 있기에 이것을 정형 데이터로 변환하는 과정을 먼저 진행하여야 하였다. 변환에는 제미나이 2.5 flash 모델을 사용하였고 System Instruction에 추출할 데이터의 구조와 예시를 주고 json형태로 받았다.(아마 다시한다면 pydantic 라이브러리를 사용할 것이다... pydantic 라이브러리를 나중에 알게되어 적용하였다. )
 

정제한 데이터의 예시

기초적인 계산을 위한 데이터셋이 완성되었다.
 
4. 모델 설계 및 서비스 전략 
신용카드 교체나 신규 발급은 보통 수년 단위로 일어나는 단발성 이벤트이다. 따라서 일반적인 금융 앱이 겪는 낮은 MAU(월간 활성 사용자) 문제를 해결하기 위해 사용자의 일상적인 소비 접점을 선점하여 DAU( 일간 활성 사용자)를 확보하는 마케팅 퍼널을 설계하였다. 
 
일상에서 전자제품을 사거나, 어떤 음식을 사기 전에 서비스에 들어와서 어느 카드로 사는게 더 효율적인지 검색하는 습관을 형성하고, 지속적으로 더 효율적인 카드에 노출되면서 자신이 쓰는 카드가 소비패턴과 알맞는지 확인하고자 하는 욕구를 형성하게끔 설계하였다. 
 
서비스 로직은 다음과 같다. 
간편 쇼핑 계산기(모델1) : 일상적 쇼핑 시 즉각적인 혜택 계산을 제공하여 플랫폼 접속 습관 형성.
소비 패턴 분석(모델2): 누적된 소비 이력을 분석하여 놓치고 있는 혜택(더 혜택이 좋은 카드)를 수치로 제시
프롬프트형 카드 추천 (모델 3): LLM 기반의 프롬프트 분석을 통해 카드 분리 및 사용자의 필요(배달, 교통 등)에 해당하는 카드 추천
 
모델 2번과 모델3번은 비슷한것 아닌가? 하는 의문이 있겠지만 용도가 다르다. 모델 2번은 사용자의 소비 데이터(최소 1개월)가 필요하고, 해당 소비패턴을 모두 분석하여 카드를 추천하는 모델이고, 모델 3번은 사용자 욕구에 의한 분리가 가능해진다.
즉, 모델 2와 모델 3은 모두 추천을 목적으로 하지만, 데이터를 다루는 관점과 사용자 경험 (UX)에서 차이가 있다. 

구분	모델 2: 소비 이력 기반 추천	모델 3: 프롬프트형 카드 추천
핵심 키워드	과거의 사실(소비 이력)	현재의 욕구(사용자의 질문)
데이터 소스	최소 1개월 이상의 정형 결제 데이터	사용자의 자연어 입력
분석 목적	고정된 소비 패턴 내에서 발생하는 페인 포인트 발굴	사용자가 직접 정의한 특수 목적에 대한 정밀 대응
사용자 가치	"나는 내 소비에 맞는 카드를 쓰고 있는가?"에 대한 객관적 검증	"내가 원하는 이 혜택을 가장 잘 주는 카드는 무엇인가?"에 대한 맞춤형 컨설팅

 
4-1. 간편 쇼핑 계산기(모델 1)
사용자가 쿠팡, 네이버 쇼핑 등에서 고가의 물건을 구매하기 직전, "지금 내 카드 중 무엇을 써야 가장 이득일까?"라는 질문을 가질 때 우리 플랫폼을 먼저 찾도록 습관을 형성하는 데 목적이 있다. 

• 기술적 설계 (저비용, 고효율)
  •  복잡한 개인화 로직 대신 사용자의 질문 (예: "쿠팡에서 100만원 결제시 최적 카드는?"에 대한 즉각적인 혜택 시뮬레이션)
  • Python 계산 로직을 통한 LLM비용 절감
  • 설계 의도 : 구매 전 검색 단계를 선점함으로써 서비스 체류 시간을 늘리고, 자연스럽게 다음 단계인 소비 패턴 분석(모델 2)이나 프롬프트 분석(모델3)으로 유입시키는 트래픽 게이트 역할 

4-2. 소비 이력 기반 추천(모델 2)
모델 2의 목적은 사용자가 인지하지 못하는 실제 소비 패턴을 정밀하게 분석하여 서비스에 대한 신뢰를 형성하고, 내가 가진 카드로 받는 혜택과 카드 추천을 통해 얻을 수 있는 혜택을 대비적으로 보여줌으로써 혜택의 차이를 기회비용의 손실로 인식하게 함에 있다. 
 
예를 들어 한달에 100만원을 사용하고 월간 혜택 금액이 3만원인 사용자가 있다고 가정하겠다. 피킹률(혜택금액 / 사용금액)이 3%라면 준수하나 카드의 조합이나 사용 패턴에 맞는 카드로 전환한다면 피킹률 4%~4.5%까지는 쉽게 올릴 수 있다. 이때 3%의 기존카드의 피킹률과 추천받는 카드의 피킹률 4%(가정)의 차이는 월 1만원이지만 연으로 환산하면 12만원의 손해를 보고 있다고 할 수 있다. 이를 현재 카드로 놓치고 있는 혜택을 제시함으로써 사용자가 기존 카드를 유지하는 행위를 안전한 선택이 아닌 매년 12만원을 버리는 행위로 치환한다. 
 
그렇기에 소비 이력 기반 추천(모델 2)의 설계는 다음과 같다

• 설계 의도 : 사용자가 자신의 카드에서 이탈하여 새로운 카드를 발급 받을 동인을 만든다. 이를 통해 모델 2, 모델 3을 통한 카드 추천으로 전환률을 올린다.
• 기술적 설계
  • 사용자의 월간 소비 데이터 (최소 1개월, 가능한 3개월 필요)
  • LLM을 통한 카드의 복잡한 로직 대응(파이썬을 통한 계산 로직을 만들기 위해서는 하나의 카드에 하나의 계산 로직 필요, 현재 346개의 카드이므로 346개의 대응 로직을 만들어야 한다)
  • LLM비용 감소를 위한 RAG와 데이터 압축 및 전송 데이터 선별

 
4-3 프롬프트형 카드 추천(모델 3)
모델 3번은 사용자의 최적화 욕구를 위한 서비스이다. 사용자가 직접 사용할 금액과 구체적인 소비 목적을 자연어로 입력하면 이를 기반으로 가장 적합한 카드 후보군을 선별하고 시뮬레이션을 통해 카드를 추천하는 모델이다. 기존의 단순 필터링 검색을 넘어 사용자의 페르소나를 해석하고, 스스로 최적화하여 카드 전환율을 극대화하는 것을 목적으로 한다. 
 

• 설계 의도 : 능동적 참여를 통한 전환 동인 생성
  • 사용자가 직접 카드를 설계하는 경험을 만든다. 스스로 카드의 소비 목적을 설계하고, 시간을 투자하게끔 만들어 소모한 시간 자체를 소비한 비용으로, 그리고 이를 정당화하기 위해 도출된 최적 이득(추천 카드)으로 전환할 심리적 동기를 부여하는 모델이다.
  • 또한 정형화된 데이터(모델2)가 담지 못하는 사용자의 미세한 라이프스타일(특정 가맹점 선호, 특수 고정 지출 등)을 LLM이 해석하여 추천 적합성을 확보한다
• 기술 설계
  • RAG 기반 선별 : 346개의 카드 데이터 중 사용자의 질의와 가장 연관성이 높은 후보군을 DB에서 선별적으로 추출하여 답변의 신뢰도를 높이고 불필요한 연산을 줄인다. 또한 소모되는 자연( 돈, 시간)을 줄여야 한다. 
  • LLM 기반 계산 및 해석 : 선별된 카드를 LLM을 통해 해석, 계산하고 최종 산출물인 리포트의 품질을 일정 수준으로 유지해야 한다.(환각 제거)

5. 모델 구축
 
설계가 끝났으니 이제 실제로 만들어야 할 차례였다. 머릿속에 그린 구조가 실제로 작동하는지 확인하는 단계인데 늘 그렇듯 설계할 때는 깔끔해 보였던 것들이 구현하다 보면 생각치 못했던 지점에서 막혔다. 
 
5-1. 간편 쇼핑 계산기(모델1)
모델 1은 세 모델 중 구조가 가장 단순하다. 그래서 가장 먼저 만들기 시작하였는데 생각보다 오래 붙잡고 있었다. 
 
처음 설계는 직관적으로 사용자의 질문 -> 의도파악 후 카테고리 뽑기 -> RAG->Python 계산 -> llm이 출력하는 로직이였다.
쿠팡에서 100만원을 결제한다고 하면 쿠팡과 쇼핑 카테고리의 카드를 먼저 뽑고, 그 카드들을 python으로 계산하는 로직이였는데 오답률이 40%에서 60%로 품질관리가 전혀되지 않았다. 로직 설계의 오류문제인가 싶어서 데이터를 재구조화 하거나, 계산 로직을 좀 더 고도화했지만 오답률은 여전했다. 천천히 로직을 따라 분석해보니 문제는 RAG의 방식에 있었다. 
 
RAG는 키워드 기반 검색이다. 문제는 카드는 중복 로직이 많다는 것이였다. 예를들어 346개의 카드 중 [주유]혜택이 있는 카드는 106개이다. RAG를 통해 1차적으로 거르는 카드가 15개였으니 106개의 카드 중 랜덤으로 15개가 들어오는 것이였다.
즉 아무리 계산 로직이 정확해도 후보군 자체가 매번 달라지니 정답이 후보에 포함되지 않는 경우가 생기는 구조적인 문제였다. 
 
결국 순서를 뒤집었다. Python으로 전체 카드 혜택을 먼저 계산하고, 그 계산 결과를 기준으로 랭킹을 매기는 방식으로 바꿨다. RAG로 후보를 좁히는게 아니라, 계산이 끝난 결과물 중 키워드를 기반으로 선별해 상위 카드를 추려서 llm에 넘기는 구조다. LLM은 이미 계산이 완료된 결과를 자연어 리포트로 포장하는 역할만 한다. 이렇게 바꾸니 오답률이 2%까지 떨어졌다. 2%의 오답률은 카드 데이터 자체의 오류여서 수정하였다. 
 
돌이켜보면 당연한 이야기지만 처음에는 RAG로 카드 수를 먼저 줄이는게 더 효율적일 것이라 생각했다. 정작 문제는 후보군이 많을 때 일정 갯수만 랜덤하게 선별하는 후보군이였다. 계산은 Python이 하면 틀리지 않는다 그러면 전체를 다 계산하고 상위만 추리는게 맞다. 이걸 직접 부딪혀서 알게되니 언제 RAG를 쓰고, 언제 쓰지 말아야 하는지에 대한 감이 생겼다. 
 
5-2 이력 기반 추천 모델 및 프롬프트 기반 추천 모델(모델2, 모델3)
모델 2와 모델3은 구조적으로 많은 부분을 공유한다. 둘 다 RAG로 카드를 선별하고, LLM이 혜택을 계산해 추천 리포트를 생성하는 흐름이다. 입력되는 데이터가 사용자의 소비 데이터냐, 사용자의 자연어 질문이냐가 다를뿐이다. 
 
모델1을 만들때는 RAG를 계산 이후에 적용하였으나 모델 2, 3은 선별 후 계산으로 바꿨다. 모델 1의 경우 346개의 카드 전체를 Python으로 계산하는 것은 입력 후 출력되는 데이터가 쇼핑, 쿠팡 처럼 단일 가맹점이나 단일 컬럼이였으니 계산을 먼저하는 것이 효율적이였으나 모델 2, 3은 다양한 컬럼(혜택)에 대응해야 했다. 그렇기에 위에서 말했듯 python을 통해 계산하려면 한개의 카드당 한개의 계산 로직을 만들어야 한다. 그렇기에 카드 혜택의 계산은 LLM에게 맡기되, RAG로 후보군을 충분히 좁혀서 환각과 비용을 동시에 잡는 방향으로 설계하였다.
 
문제는 비용이였다. 전체 카드 데이터를 그대로 LLM에게 던지면 입력 토큰이 387,911개, 건당 비용이 286원이였다. 서비스로 만든다고 가정하면 1만회당 286만원이 나오게 되며 감당할 수 없는 구조였다. 또한 소요되는 시간이 제미나이 3.0 FLASH기준으로 60초가량이 걸렸다. 아무리 인내심이 많은 이용자라도  60초는 서비스에서 이탈하기에 충분한 시간이였다. 
 
그렇기에 최우선 과제는 토큰의 소모를 줄이고 소요되는 시간을 줄이는 것이였다. 
 
최우선적으로 적용한 건 payload 최적화였다. json형태기에 중복되어 사용되는 컬럼들의 컬럼명을 압축하고 System Instruction에 해석 범례를 제공하여 해석하여 계산할 수 있게 하고, 
카드의 혜택을 계산할때 필요하지 않은 url이나 카드명을 제거하여 LLM에게 보내고 이를 후처리 로직에서 복구하는 방식으로 바꿨다. 
또한 json에서 줄바꿈, 공백, 들여쓰기 등은 인간이 데이터를 볼 때 필요하지만 LLM이 데이터를 파악할 때는 불필요한 정보이고, 토큰을 소모하기에 해당 부분도 삭제하였다. 

최적화 전	최적화 후
"title ": "신한카드 Mr.Life Deep Dream",	"t": "new1",
"benefit_detail": "편의점 10% 할인..."	"b": "편의점 10%..."
"url": "https://www.shinhancard ..."}	(삭제 - 별도 매핑)}

 
이것만으로 입력 토큰이 387,911개에서 243,367개로 줄었다. 비용은 286원에서 181원으로 약 37% 감소하였다.
두번째로 RAG를 붙였다. BM25와 RRF를 조합해 사용자의 질의와 연관성이 높은 카드만 추려 LLM에 전달하는 방식이다. payload 최적화와 RAG를 함께 적용하니 입력 토큰이 24,116개까지 떨어졌다. 최초 387,911개 대비 93.78%감소, 비용은 22.37원이였다. 응답 시간도 35초 수준으로 내려왔다. 
 
마지막으로 출력 규격화 문제가 남아 있었다. LLM이 출력할 구조를 미리 System Instruction에 입력한다고 하여도 내부의 글자 수에 따라 규격이 매번 달라지는 문제가 있었다. LLM이 아무리 추천을 잘해도 출력 형식이 매번 달라지면 서비스로 쓸 수 없다. 그렇기에 Pydantic으로 출력 스키마를 고정해서 리포트가 항상 같은 구조로 나오게 했다. 데이터 정제 단계에서도 썼으면 좋았을 도구인데 뒤늦게 알게 되어 여기에 적용하였다. 
 
모델 2,3을 만들면서 모델 1때와 반대의 결론에 도달했다는게 흥미로웠다. 모델 1에서는 RAG가 문제였고, 여기서는 RAG가 해결책이였다. 같은 도구도 문제의 성격에 따라 다르게 써야한다는 걸 다시끔 배웠다. 
 
6. 스트림릿 제작
 
모델을 만들었으면 혼자만 쓰는 것으로 끝내기엔 아쉬웠다. 약간의 인정욕구와 처음으로 만든 서비스에 대한 애착, 그리고 실사용자의 피드백을 직접 들어보고 싶다는 마음이 컸다. 내가 카드 상담사처럼 항상 옆에서 사용자의 소비패턴을 듣고 대신 입력해주는 방식은 윤리적인 문제도 있고 사용자 입장에서도 불편한 일이다. 서비스가 스스로 굴러가야 진짜 테스트가 되는 것이기도 했다. 
 
 
 모델 1. 간편 쇼핑 계산기

모델 2. 소비 이력 기반 추천 모델

모델 3. 프롬프트형 카드 추천 모델

모델 3의 프롬프트는 친구에게 블라인드 테스트를 부탁해서 프롬프트를 받아와 테스트에 이용하였다. 
 
7. 회고
개인적으로 최신 기술에 대한 이해가 가장 많이 늘어난 프로젝트였다. 크롤링부터 시작해서 데이터 정제, RAG, LLM, 마케팅 퍼널 설계까지 혼자 전 과정을 다 짚어본 경험은 처음이였고, 그만큼 배운것도 많았다. 
 
배포 후 총 15건의 피드백을 받았다. 실용적이다. 추천이 자세하다는 긍정적인 반응도 있었지만 개선 요청이 더 눈에 들어왔다. 체크카드가 없다는 점, 속도 개선, UX와 온보딩이 불친절하다는 의견이 주를 이뤘다. 만들면서 기능 구현에 집중하느라 미처 챙기지 못했던 부분들이었다. 특히 UX와 온보딩 피드백이 4건으로 가장 많았는데, 기능이 아무리 좋아도 처음 진입하는 사용자가 사용법을 모르면 의미가 없다는 것을 새삼 느꼈다. 서비스를 만드는 것과 사용자가 쓸 수 있게 만드는 것은 다른 문제였다. 
 
기술적으로 아쉬운 점도 있다. Pydantic을 처음부터 알았더라면 데이터 정제 단계에서 훨씬 깔끔하게 작업했을 것이고, RAG의 작동 방식을 제대로 이해하고 시작했다면 모델 1에서 해맸던 시간을 줄일 수 있었을 것이다. 다만 직접 부딪혀서 틀리고 고치면서 익힌 것들이라 머릿속에 더 오래 남아있을 것 같다. 
 
응답 속도는 여전히 숙제다. 최적화를 거쳐 35초까지 줄였지만 서비스로서 만족스러운 수준은 아니다. 서비스의 이용 대기 시간이 길어질수록 신뢰도가 상승한다는 연구결과도 있지만 나는 서비스의 대기 시간을 의도적으로 늘린게 아니기에 해당 사항은 아닌 것 같다.  피드백에서도 속도 개선 요청이 나온 만큼 다음 과제로 남겨뒀다.
 
5주짜리 1인 프로젝트치고는 꽤 많은 걸 담았다고 생각한다. 동시에 실제 서비스로 키우려면 아직 손봐야 할 게 많다는 것도 안다. 피드백 기반 개선은 현 시점에선 인턴 생활로 바쁘기에 조금씩 만지고 있다. 
 
마지막으로 혹시라도 이용해보고 싶은 사람들을 위해 링크를 남겨두겠습니다. 이용하고 나면 후기를 댓글로 작성해주시길 부탁드립니다. 입력되는 모든 데이터는 제 컴퓨터와 로직상에 저장되지 않습니다.
 
AI 프롬프트형 카드 추천