어려운 용어가 있으신가요? ‘금.용.사.’가 알려드립니다!

요약: 금융 용어 사전 서비스 ‘금.용.사‘는 어려운 금융 용어를 AI가 쉽게 설명해 주는 것을 목표로 하며, 단순히 용어만 해설하는 게 아니라 관련 금융 상품도 추천합니다. ‘금.용.사’는 보험뿐만 아니라 향후 대출, 카드, 투자 등 다른 금융 영역으로도 확장 가능하도록 설계했습니다. 개발 과정에서는 API 응답 지연 이슈를 해결하기 위해 캐싱 솔루션을 도입하고, 팀에서 원하는 방향으로 AI가 응답하도록 프롬프트를 구체적으로 작성했습니다.

💡 리뷰어 한줄평

ellie.sys 사용자에게 친숙한 서비스를 제공하기 위한 고민과 열정을 가득 느낄 수 있었습니다. 보험과 비슷한 환경으로 고민이 있는 서비스가 있다면 유용한 인사이트를 얻어 가실 수 있을 거예요!

시작하며

안녕하세요, 저희는 금.용.사(금융용어사전) 서비스를 만든 아 팀이름 안정했따 팀입니다. 카카오페이에서는 최근 AWS와 함께 AI를 활용하는 해커톤, 카페톤을 진행했는데요. 저희는 어려운 금융용어를 사용자가 이해하기 쉽게 설명해 준다는 콘셉트를 가지고 서비스를 만들었습니다. 팀원 구성이 보험(인슈어런스클랜) 크루들이다 보니, 저희가 처음 보험이라는 도메인을 접했을 때 느꼈던 용어의 어려움이 사용자들에게도 분명 해석이 필요할 것이라고 생각했습니다.

아이디어 선정 과정

저희는 아래 내용을 중심으로 아이디어를 선정했습니다.

• 저희가 잘 아는 보험 도메인
• 사용자가 저희 서비스를 이용하는데 도움이 되는 아이디어
• 실현 가능성

저희 팀 모두 인슈어런스 클랜의 크루들이다 보니, 아무래도 보험이라는 도메인에 대해 많이 익숙합니다. 그만큼 사용자들이 어떤 어려움을 겪고 있는지, 또는 어떤 부분이 허들이 되는지 기존에도 많이 고민하고 있었는데요. AI, 그리고 카페톤이라는 평소와는 다른 제약조건 하에 저희가 기존에 해결하고 싶었던 문제들을 어떻게 풀 수 있는지 고려하여 아이디어를 선정했습니다.

또, 사용자의 실제 어려움을 해소해 줄 수 있는 아이디어를 원했습니다. 저희는 복잡한 금융을 쉽게 풀어 제공하는 서비스를 만들고 있습니다. AI를 활용한 서비스가 무궁무진하게 쏟아져 나오고 있는 상황에서, 저희는 AI 역시 기존과 같은 목적으로 사용하고자 하였고, 이에 따라 사용자가 경험할 수 있는 서비스 내 허들을 AI를 이용해 해소하고 싶었습니다.

마지막으로, 실현 가능성을 고려하여 아이디어를 선정했습니다. 카페톤은 사전에 자료 및 기술 조사가 허용되었고, 실제 구현은 당일에 이루어져야 했습니다. 네 명의 팀원들 모두 AWS의 AI 서비스들을 처음 접하는 상황이었고, 실제로 구현 가능한 시간은 한정되어 있었기 때문에, 이를 감안하여 아이디어를 선정했습니다.

이를 바탕으로 저희가 선정한 아이디어는 ‘금융 용어 사전’, 줄여서 ‘금.용.사.‘입니다. 금융 서비스를 이용할 때, 어려운 용어 때문에 이해하지 못하고 넘어가는 사용자들이 많은 점에 착안하여, 이러한 허들을 AI를 활용하여 해소하고자 하였습니다.

뿐만 아니라 용어와 관련된 금융 상품 조회 등, 사용자가 필요할 수 있는 정보를 AI가 선정하여 함께 제공하도록 하였습니다. 저희가 보험 도메인에 익숙한 만큼 실제 구현은 보험을 중심으로 진행했지만, 대출, 카드, 투자 등 다른 금융 도메인에도 접목시킬 수 있는 아이디어입니다.

서비스 기획 및 결과물 소개

고생 끝에 완성한 결과물입니다. 우선 영상부터 보시죠!

사용자가 카카오톡 알림톡 등을 통해 진입하는 과정을 가정했습니다.

simple: 한 줄 금융용어 소개

용어설명 OFF	용어설명 ON

우선 화면에서 사용자가 클릭을 하면 용어를 해석해 준다는 것을 인지시키기 위해, 토글 버튼을 활용했습니다. 토글을 클릭하면 화면에 있는 용어들 중 사용자가 어려워할 만한 용어들을 AI가 인식해서 설명이 가능한 영역에 하이라이팅 처리가 됩니다. 하이라이팅 된 용어를 클릭하면, 우선 1차적으로 간단한 설명을 툴팁 형태로 보여줍니다. 툴팁 형태로 보여주다 보니 최대 20자 이내에 설명할 수 있게 프롬프트 자체를 단순하게 작성하였습니다.

detail: 금융용어에 대한 자세한 설명

상세 설명 및 연관 금융 상품 추천	용어에 대해 AI가 생성한 설명

단순 툴팁으로 설명이 부족할 경우, 툴팁을 클릭하면 상세 설명 페이지로 연결됩니다. 이때 상세 설명과 연관 금융 상품 추천 내용을 같이 불러옵니다. 상세 설명 페이지에서는 해당 용어에 대한 자세한 설명을 해주는데, 중요한 건 단순 줄글이 아니라 사용자가 이해할 수 있게 보여주는 것을 우선시했습니다. 먼저, 용어에 대해서 사례를 들어 구체적으로 설명해 주는 것에 더하여, 가독성 좋게 보이기 위해서 • (bullet point)를 사용해서 보여주는 것까지 프롬프트에 입력했습니다.

products: 금융용어와 연관된 금융 상품

금.용.사의 포인트는, 단순 용어 설명에서 끝나는 것이 아니라 사업적인 비즈니스 모델로까지 연결한 것입니다. 사용자가 금융 용어 설명을 확인하고, 관련 상품 리스트를 볼 수 있게 보험 상품 정보를 미리 학습시켜 두었습니다. 이 리스트들을 유저가 보기 좋게 보험사/보험상품/보장명/보장금액 순서대로 표 형태로 구성하였고, UI적으로도 상단 설명과 구분할 수 있게 박스 형태로 보여줬습니다. 다른 금융권(대출, 투자 등)의 정보를 이러한 서비스 형태로 학습하는 경우, 그대로 적용할 수 있게 구성하며 서비스 확장성까지 고려하였습니다.

개발 및 문제해결 과정

전체 아키텍처 소개

금융용어사전은 다음과 같은 아키텍처로 구성했습니다.

서비스 앞단은 CodeDeploy를 통해 배포하였습니다. 사용자의 요청에 따라 Amazon API Gateway를 통해 AWS Lambda를 호출합니다. Lambda는 앞서 소개한 서비스 기획에 맞춰 simple, detail, products로 나뉘어 있습니다. 각 lambda를 통해 Amazon Bedrock을 호출하는데요. 각 lambda는 필요에 따라 bedrock의 agent를 호출합니다. 이 agent들은 지식 기반(knowledge base)로부터 응답을 구성하는데요. 지식 기반은 금융 용어, 약관 등이 담긴 정적인 자료들과 웹 사이트 크롤링 등의 동적인 자료들로 구성되어 있습니다.

Agent

Agent는 Amazon Bedrock의 일부분으로써, 사용자의 요청을 분류하고 관련된 정보를 찾아 주어진 업무를 수행합니다. 저희는 금융 용어에 대한 간단 소개, 자세한 소개, 연관 상품 추천을 담당하는 3개의 agent를 구성하였습니다. Agent는 주어진 키워드에 대해 저마다 정해진 방식으로 응답을 생성했는데, 정해진 방식은 프롬프트 작성을 통해 정의하였습니다.

원하는 정보를 응답하는 것뿐만 아니라, 원하는 형태로 가공하여 응답해 주기도 합니다. 예를 들어 simple에서는 한 개의 용어에 대해 응답을 생성하므로, 용어를 key, 응답을 value 형태로 만들었습니다. detail은 2~3 문장으로 해당 용어를 설명한 후, 중요한 요점을 불릿 포인트 형식으로 나열했는데, 이 형태 역시 agent가 구성해 주었습니다. products의 표 형태 응답 역시 마찬가지입니다.

지식 기반

Amazon Knowledge Base는 가지고 있는 정보들로 RAG를 구성할 수 있게 도와줍니다. 금융업계의 다양한 용어들은 여러 금융 업체 또는 협회가 의미를 정리하여 제공하고 있습니다. 보험의 경우, 보험사들의 상품 소개서, 보험 협회의 용어 사전 등이 그 예입니다. 이는 pdf 등의 형태로 정적으로 제공되기도 하고, 온라인에서 검색하는 형태로 제공되기도 합니다.

Knowledge base도 목적에 따라 분류하여 구성했습니다. 보험 용어(정적 자료만), 보험 용어(정적+동적 자료), 질병 용어(정적+동적 자료), 가상 보험 상품 자료(정적 자료)로 총 4가지입니다. RAG를 구성하는 정보의 수가 많을수록 응답에 사용할 정보를 찾는 데 시간이 오래 걸리는 경향이 있어, 용도에 따라 구분해서 사용하도록 하였습니다.

어떤 게 어려운 용어지?

금융 용어 사전을 개발하는 과정에서 명확하고 쉬운 설명만큼이나 중요한 것은 사용자가 어떤 단어를 어렵게 느낄지 판단하는 기준을 설정하는 것이었습니다. 특히 이번 서비스의 대상 업권이 보험 분야였기에, 보험업계에서 자주 사용되는 용어들을 심층적으로 조사했습니다. 조사 결과, 보험 용어는 외래어나 영어 표현보다는 한자 기반의 단어나 질병명과 같은 의료 전문 용어가 대부분을 차지한다는 특징을 발견했습니다. 이러한 분석을 바탕으로, 다음과 같은 기준으로 용어 해설 대상을 선별하는 Agent를 구성했습니다.

• 한자어 기반의 전문 용어
• 질병명 등 의료 관련 용어

즉, 해당 조건에 부합하는 용어에 대해서만 사용자 친화적인 설명을 제공함으로써, 사용자가 실제로 어려움을 느낄 수 있는 지점을 효과적으로 공략하고자 했습니다.

로딩이 너무 오래 걸리네?

1. 30초 이상의 응답 지연: 서비스 사용성을 개선해야 해요
   해커톤에서 조원들과 개발한 프로토타입을 시연하던 도중, API 응답 시간이 30초 이상 소요되는 점을 확인했습니다. 이는 서비스 사용에 있어 개선이 필요한 부분이라고 판단했습니다. 저희는 이 문제를 해결하기 위해 “단어와 설명이 명확히 매핑된다”는 서비스 특성에 착안하여 Key-Value 기반의 캐싱 솔루션 도입이 필수적이라고 생각했습니다.

2. DynamoDB를 활용한 캐싱 구현
   캐싱 솔루션으로 Amazon Web Services(AWS)의 NoSQL 데이터베이스 서비스인 DynamoDB를 선택했습니다. DynamoDB는 빠른 Key-Value 조회 성능과 뛰어난 확장성을 갖추고 있어 저희 서비스의 요구사항에 부합했습니다. AI로 한 번 생성한 ‘용어(Key)-설명(Value)’ 쌍을 DynamoDB에 저장하고, 이후 동일 용어 설명 요청에 대해서는 데이터베이스에서 바로 읽어와 빠른 속도로 응답을 제공합니다. 이 과정에서 최초 진입 시에는 AI 호출로 시간이 소요되지만, 이후의 반복적인 접근에서는 성능(기존 30초 -> 0.5초 미만)이 훨씬 나아졌습니다.

3. TTL 도입으로 최신 정보 확보
   여기서 그치지 않고, 캐시 데이터에 유효기간(TTL: Time To Live)을 설정하는 기능을 추가로 개발했습니다. DynamoDB의 TTL 기능은 설정된 시간이 지나면 캐시 된 항목을 자동으로 삭제하여, 이후 해당 용어 요청 시 AI가 새로운 설명을 생성하도록 유도했습니다. 이로써 서비스에서 빠른 응답 속도를 유지하면서도 사용자에게 더욱 풍부하고 최신 정보를 제공했으며, 다양한 관점으로 설명하여 서비스 가치를 한층 높였습니다.

4. 미래를 위한 비동기적 캐시 업데이트 구상
   비록 해커톤 기간 내에는 개발하지 못했지만, 저희는 향후 AWS Batch나 CloudWatch와 Lambda를 활용한 비동기적 업데이트를 구현하고자 했습니다. 이는 현재 남아있는 이슈인 첫 방문 시 지연을 없애기 위한 선제적인 캐시 구축 및 관리를 목표로 합니다. 또한, TTL 만료 시에만 업데이트되는 것이 아니라, 운영자가 원할 때(업그레이드된 Agent 적용) 혹은 서비스 사용이 적은 새벽 시간에 업데이트를 진행하여 최신 정보를 유지하고 용어 설명 품질을 지속적으로 향상하고자 했습니다. 이러한 방법으로 핵심 용어 설명 검토 및 갱신 과정을 자동화할 수 있을 것입니다.

화면에서 용어를 전달하고 변경하기

금융 용어 사전 서비스의 핵심은 사용자가 이해하기 어려운 용어를 AI가 인식하고, 그에 따른 적절한 설명을 제공하는 것입니다. 용어를 어떻게 AI에게 전달할지에 대한 고민이 필요했습니다. 다양한 카카오페이 서비스 내에 손쉽게 적용할 수 있는 목표를 가지고 있었기에, 손쉽게 적용할 수 있는 방향으로 고민했습니다.

개발자가 어려운 용어라고 생각하는 부분을 하나하나 찾아서 보낼 수도 있지만, 이는 서비스가 커질수록 관리하기 어려워집니다. 그래서 저희는 컴포넌트 내부에 있는 텍스트를 모두 전달하는 방식을 선택했습니다. 고정적으로 들어가는 텍스트뿐만 아니라 페이어텐션과 같은 CMS로 처리되는 상황도 고려하였습니다.

어려운 용어는 서비스 설명 문단에 주로 추가합니다.

내 보험 상세 보험용어 설명 영역	신용관리 용어 설명 영역

현재 서비스되고 있는 카카오페이 서비스를 분석해 보았을 때, 사용자들이 어려워하는 용어들은 별도의 영역에 설명이 추가하는 경우가 많았습니다. 예를 들어, 내 보험 상세의 “갱신형”과 “비갱신형”의 설명을 위해 별도의 페이지를 추가하고, 신용관리 서비스의 “신용점수”와 “신용등급” 등의 용어 설명을 위해 별도의 영역을 추가하는 경우가 많았습니다. 이러한 영역에 있는 텍스트를 모두 컴포넌트로 감싸고, 해당 컴포넌트 내부의 텍스트를 모두 전달하는 방식으로 구현하였습니다.

// 요청 Json
{
  "translate": "갱신형과 비갱신형의 차이를 알고 보험료를 아껴보세요."
}

// 응답 Json
{
  "갱신형": "갱신형은 보험 계약 기간이 끝난 후에도 보험료를 갱신하여 계속 보장받을 수 있는 형태입니다. 예를 들어, 10년 동안 보험료를 납부한 후, 10년이 지나면 다시 보험료를 갱신하여 추가로 보장받을 수 있습니다.",
  "비갱신형": "비갱신형은 보험 계약 기간이 끝나면 더 이상 보험료를 납부하지 않고, 보장도 종료되는 형태입니다. 예를 들어, 10년 동안 보험료를 납부한 후, 10년이 지나면 보장이 종료되고 추가로 갱신할 수 없습니다."
}

컴포넌트 내부에는 자식요소들을 상속받아 텍스트를 추출하여 API로 전달합니다. 이때, 컴포넌트 내부에 있는 텍스트는 모두 전달되며, AI가 어려운 단어라고 판단한다면 Json 형태로 key-value로 전달됩니다. 예를 들어, “갱신형”이라는 단어가 어려운 단어라고 판단되면, “갱신형”이라는 key와 그에 대한 설명이 value로 전달됩니다.

전달받은 데이터는 전역상태저장소(ex. Zustand, Jotai 등)에 저장하고, 컴포넌트 내부에서 꺼내서 보여줍니다. 이때, 컴포넌트 내부의 텍스트 인덱싱을 통해 알맞은 키워드를 찾아 교체합니다. 예를 들어, “갱신형”이라는 단어가 어려운 단어라고 판단되면, 컴포넌트 내부의 “갱신형”이라는 단어를 치환합니다.

const text = '갱신형과 비갱신형의 차이를 알고 보험료를 아껴보세요.';

text.replace(/갱신형/g, `<span class='translated'>$1</span>`);

텍스트 치환을 통해 변역된 텍스트는 사용자가 쉽게 이해할 수 있도록 하이라이팅 처리하여 보여줍니다. 이벤트 핸들러를 추가하여 사용자가 하이라이팅 된 텍스트를 클릭하면, 번역 된 텍스트를 보여줄 수 있도록 처리합니다.

최적화하기

AI 서비스는 많은 번거로움을 없애주지만, 그만큼 비용이 많이 들어가게 됩니다. 한 서비스 화면에서 이미 번역된 용어를 다시 번역하는 것은 비용 낭비라고 판단하였습니다. 그래서, 번역된 용어는 전역 상태 저장소에 저장하고, 이미 번역된 용어는 다시 번역하지 않도록 API 요청에 단어들을 같이 전달하여 무시하도록 했습니다.

결과적으로 비용에 대한 최적화와 약간의 응답속도 개선을 이룰 수 있었습니다.

AI가 말을 안 들어요

기본적인 서비스 형태를 만든 후, 서비스에 사용된 AI가 저희가 기대한 대로 응답하는지 몇 차례 테스트를 진행했습니다. 아쉽게도 한 번에 마법처럼 잘 되지는 않았습니다. 정의한 글자 수를 초과해서 응답을 하거나, 지정했던 말투와 다른 문구로 응답하기도 했습니다. 무엇이 원인이었을까요?

Agent 기능은 최소한으로

Agent는 명령한 대로 응답을 잘 만들어 주기는 하지만, 명령이 원하는 바가 복잡할수록 기대한 대로 응답하지 못하는 경향이 있습니다. simple agent는 처음에는 용어들 목록을 한 번에 전달하고 응답을 기대했지만, 용어 수가 많아지니 응답 내용이나 형태가 점점 기대에서 벗어났습니다. 명령을 조금 단순화하고자, 용어를 한 개만 처리하는 방식으로 agent를 변경했습니다. 다행히 용어 하나에 대해서는 기대대로 잘 응답해 주었고, 이를 활용하기 위해 클라이언트에서 병렬로 agent에 요청을 보내도록 구현했습니다.

프롬프트는 최대한 구체적으로

우리가 사람에게 무언가 부탁할 때도 오해가 생기는 경우가 있죠? 대부분 시키는 쪽이 두루뭉술하게 말하거나, 듣는 쪽이 융통성이 없어서 생기는 일인데요. AI는 후자에 속합니다. AI가 기대한 대로 답을 못 할수록 아쉬운 건 사람이니, 요청을 최대한 구체적으로 해야 합니다.

보험 상품을 추천하는 agent를 예로 들어 보겠습니다. 가장 간단히 프롬프트를 작성한다면, ‘키워드와 연관된 상품들을 보여 주세요.’라고 하면 됩니다. 하지만 이러면 응답 형식은 어떤지, 같은 회사의 상품을 중복 노출해도 되는지, 키워드와 연관성을 어떻게 표현해야 할지 알 수 없습니다. 또, 응답을 단순히 줄글 형식으로 출력할지 등도 모호하죠. 저희는 ‘역할’, ‘응답 조건’, ‘출력 형식’ 세 가지를 정의하고, 이를 잘 구조화하여 응답에 사용했습니다. 특히 용어에 대해 자세히 설명하는 detail의 경우 이러한 구조화를 적극 활용하였습니다. 프롬프트는 아래와 같이 작성했습니다.

<Base>
*  당신은 대한민국에서 활동하는 보험 전문가입니다.
*  보험 용어와 관련 제도에 대해 깊이 있는 지식을 갖추고 있습니다.
*  당신은 제시된 키워드와 연관된 보험 상품을 추천해 주는 전문가입니다.
</Base>

< Condition>
*  각 보험 상품에 대한 형식은 [보험사명]: [보험상품명] - [보장명] [보장금액] 형태로 표현해 주세요.
*  보장금액이 큰 순서로 정렬해서 보여주세요.
*  같은 보험사 상품은 2개 이상 보여주면 안 됩니다.
*  같은 용어에 대해 연관된 다른 보험사의 상품이 더 있는지 꼭 확인해 주세요.
*  타이틀은 용어가 포함되게 '소액암'이 예시라면 '소액암을 보장하는 상품'을 타이틀로 만들어 주세요.
</Condition>

< Result>
*  목록을 나열하는 방식은 4열을 기준으로 아래로 리스트 행을 추가해 주세요.
*  첫 번째 행에는 4가지 행으로 보험사명, 보장상품명, 보장명, 보장금액으로 구분해서 만들어주세요.
*  행 추가는 보장금액이 높은 순이 1번으로 보이도록 정렬해야 합니다.
*  응답 형태는 Html 형태로 보내주세요.
*  타이틀은 h2 태그로 사용하세요.
</Result>

당신은 <Base>의 역할을 수행하며, 질문에 대한 응답은 <Condition> 조건에 맞추고, 출력은 <Result> 포맷으로 작성하세요.

내용이 뒤섞이지 않도록 구분한 내용을 tag 형식으로 감싸고, 각 tag에서 기대하는 역할을 작성했습니다.

마치며

이번 카페톤을 통해, 평소에 AI를 실제 서비스에 적용해 보고 싶다는 갈증을 해소할 수 있었습니다. 서비스 기획부터 실제 구현까지 전 과정을 밀도 있게 경험하면서, 사용자의 어려움을 되돌아볼 수 있었습니다. 해결하고 싶은 사용자의 어려움과 고충을, AI를 활용한 엔지니어링을 통해 해소해 가며 성취감과 뿌듯함을 느꼈습니다.

가장 큰 교훈은 아이디어를 구체화하고 실제 서비스로 만들어가는 과정에서 기술적 제약과 현실적인 사용자 경험 사이의 균형점을 찾는 게 중요하다는 점이었습니다. AI agent의 응답 형태가 기대와는 다르거나, 응답 시간이 너무 오래 걸리는 등, 제한된 시간 내에 반드시 해결해야 하는 문제들이 발생했습니다. 사용자 경험을 최대한 보존하고 싶었기에, 응답 시간을 캐싱을 통해 우회하여 풀거나, agent의 역할을 재정의하여 원하는 형태의 결과를 얻는 등, 기술적 제약을 해소하기 위해 노력했습니다.

‘금.용.사’를 구현하며, 금융 환경에서 AI를 접목시킨 서비스가 생각보다 어려운 일은 아니라는 것을 느꼈습니다. ‘금융 용어가 어렵다’는 사용자의 고충을 AI를 활용하여 해소할 수 있었습니다. 실제 서비스화한다면 아이디어를 더욱 구체화하고, 기술적으로 보다 보완하여 사용자들에게 친숙한 서비스를 만드는 데 활용하려고 합니다. 저희의 개발 과정과 고민이 여러분에게 조금이나마 영감이 되기를 바랍니다.