신한카드, 온톨로지와 소형언어모델로 고효율 AI 챗봇 구축하기

들어가며: 금융 고객 상담의 새로운 패러다임

신한카드는 대한민국 대표 신용카드사로, 수백만 고객에게 종합 금융 서비스를 제공하고 있습니다. 신한카드는 고객 서비스 품질 향상을 위해 AI 챗봇 레이(Ray)를 지속적으로 발전시켜 왔습니다. 이를 기반으로 보다 진화된 차세대 AI 챗봇을 기획하였고, AWS Generative AI Innovation Center (AWS GenAIIC)와의 협력을 통해 그 토대를 마련하게 되었습니다.

차세대 AI 챗봇이 풀어야 할 문제

금융 고객 상담은 단순한 Q&A가 아닙니다. 고객은 여러 턴에 걸쳐 요청을 구체화하고, 대화 중간에 갑작스럽게 토픽을 전환합니다. 사용 한도를 묻다가 갑자기 “그럼 지난달 이용내역도 보여줘”라고 요청하는 식입니다. 기존 시나리오 기반 챗봇은 사전에 정의된 흐름 안에서는 정확하지만, 고객이 스크립트를 벗어나는 순간 대응이 불가능합니다. 조금 더 고도화된 상담을 위해서는 다음 세 가지 난제를 동시에 해결해야 합니다.

1. 정교한 의도(인텐트) 분석 및 맥락 유지

각 인텐트마다 참조해야 하는 데이터베이스 테이블이 상이하고 실행해야 하는 액션이 다르기 때문에, 정확한 인텐트 분류가 시스템 전체의 성능을 좌우합니다.

방대한 인텐트 분류: 51개의 세분화된 상담 카테고리를 높은 정밀도로 판별해야 합니다.
미세한 의도 변별력: ‘결제 취소/환불’과 ‘결제 실패/거절’처럼 문맥은 유사하나 처리 로직이 완전히 다른 인텐트를 명확히 구분해야 합니다.
동적 대화 대응: 상담 중 발생하는 주제 전환(Topic Switching)에서도 맥락을 놓치지 않는 추론 능력이 요구됩니다.

2. 액션 워크플로우의 복잡성

의도가 파악된 이후에도, 쿼리 유형에 따라 수행해야 할 작업의 난이도가 달라집니다.

쿼리 유형	설명	예시
단순(Simple)	불완전한 쿼리, 추가 정보 요청 필요	“한도를 올려주세요”
명확(Clear)	완전한 문장 형태	“OO카드의 신용 한도를 330만 원으로 올려주세요”
모호(Vague)	단순 단어 조합, 문법적으로 불완전	“방법 한도 증액”
복합(Complex)	여러 필수 정보 포함	“최근 3개월 중 소비가 가장 많았던 달은?”

유형 A (단순/모호, 정형적 정보 수집): 필요한 정보는 고정적이지만 사용자가 정보를 생략하는 경우가 많아, AI가 부족한 정보를 파악하고 능동적으로 추가 질문을 던져야 합니다.
유형 B (복합, 지능적 판단 및 분석): 질문에 따라 필요한 파라미터와 분석 로직이 동적으로 변화하며, 고정 시나리오가 아닌 지능적 판단이 필수적입니다.

3. 모델 선택의 현실적 제약

혁신금융서비스 제도: 고객 데이터를 다루는 AI 시스템에 상용 모델(Claude, ChatGPT 등)을 활용하려면 규제 당국의 별도 승인 절차를 거쳐야 합니다. 자체 호스팅이 가능한 오픈소스 소형 언어모델(sLLM)을 사용할 경우, 해당 승인 절차 없이 빠르게 개발할 수 있습니다.
운영 비용: 대형 모델 대비 비용 효율적인 솔루션이 필수적입니다.
지연 시간(Latency): 고객 체감 응답 지연을 방지하기 위해, 요청당 처리 시간을 5초 이내로 단축해야 합니다.

규제, 비용, 속도라는 제약은 우리에게 근본적인 질문을 던졌습니다. 과연 ‘지능’의 수준은 반드시 모델의 크기에 비례하는 것일까요? 모델의 크기를 획기적으로 줄이면서도 상담에 필요한 정교한 지능을 유지할 순 없을까요?

신한카드와 AWS GenAIIC는 위 질문에 대한 깊은 고민을 통해 상충하는 두 목표 – “작은 모델”과 “정교한 지능” – 을 동시에 달성할 수 있는 솔루션을 구축했습니다. 본 블로그에서는 이를 가능하게 한 세 가지 기술 혁신에 대해 하나씩 풀어 보도록 하겠습니다.

솔루션 개요

세 가지 혁신

온톨로지 기반 인텐트 분류 (Ontology-based Intent Classifier): 온톨로지 지식 체계를 활용하여 51개의 복잡한 인텐트를 정밀하게 분류하고, 미세한 의도 차이까지 정확하게 판별합니다.
분산형 Agentic AI (Decentralized Agentic AI): 단일 LLM 중심의 중앙 집중식 구조에서 벗어나, 역할별로 특화된 sLLM 기반 에이전트들의 협력을 통해 복잡하고 동적인 워크플로우를 효율적으로 처리합니다.
자율적 시스템 업데이트 (AI-to-AI Dialogue for Autonomous System Updates): AI 에이전트 간의 상호 대화와 피드백으로 상담 지식과 로직을 스스로 검증하며, 시스템을 자율적으로 고도화하는 선순환 체계를 구현합니다.

혁신 1. 온톨로지 기반 인텐트 분류 (Ontology-based Intent Classifier)

기존 방식의 한계: 정보 과부하와 추론 효율성 저하

초기 설계 단계에서 검토했던 베이스라인(Baseline) 방식은 51개에 달하는 인텐트 전체 명세와 상세 설명을 프롬프트에 포함하여 모델이 직접 분류하도록 하는 구조였습니다. 그러나 이 방식에는 두 가지 한계가 있었습니다.

첫째, 운영 비용 및 리소스 효율성 문제입니다. 매 요청마다 방대한 인텐트 설명을 모델에 전달해야 하므로 토큰 소모량이 굉장히 컸습니다. 둘째, 추론 정확도의 한계입니다. 상대적으로 파라미터 수가 적은 소형 언어 모델(sLLM) 환경에서는 방대한 선택지 속에서 발생하는 ‘정보 과부하’로 인해 인텐트 간의 미세한 차이를 식별하지 못하고 분류 오류를 범하는 현상이 빈번하게 발생했습니다.

해결책: 인텐트 온톨로지를 통한 구조적 분해

이러한 난관을 해결하기 위해 모든 인텐트를 도메인(Domain), 액션(Action), 태그(Tag)라는 세 가지 하위 구성 요소로 구조화하는 ‘인텐트 온톨로지(Intent Ontology)’를 설계했습니다. 인텐트를 구성 요소 단위로 분해하여 정의하면, 겉보기에 유사한 인텐트라도 그 이면에 숨겨진 구조적 차이를 명확히 식별할 수 있습니다.

예를 들어, ‘결제 취소’와 ‘결제 실패’는 동일한 ‘거래(TRANSACTION)’ 도메인을 공유하지만, 하위 계층에서의 Action과 Tag가 명확히 구분됩니다.

구성 요소	결제 취소 및 환불	결제 실패 및 거절
Domain	TRANSACTION	TRANSACTION
Action	CANCEL	RESOLVE
Tag	–	ERROR
설명	승인된 카드 결제의 취소를 요청하고 진행 중인 환불 상태를 확인	카드 결제 승인이 거절되거나 오류가 발생했을 때 원인 파악 및 해결 안내

이처럼 모든 인텐트에 대해 체계적인 속성값을 정의함으로써 인텐트 간의 변별력을 확보했으며, 이를 기반으로 ‘인텐트 온톨로지 맵’을 구축할 수 있었습니다. 인텐트 온톨로지 맵은 아래와 같은 JSON 형태로 저장되며 Figure 1 및 Figure 2은 이를 시각화한 그래프를 보여줍니다.

[
  {
    "id": 21,
    "name": "결제 취소 및 환불",
    "domain": "TRANSACTION",
    "action": "CANCEL",
    "tags": [],
    "desc": "승인된 카드 결제의 취소 요청, 취소 처리 상태, 환불 일정 및 입금 여부를 확인하려는 문의입니다."
  },
  {
    "id": 22,
    "name": "결제 실패 및 거절",
    "domain": "TRANSACTION",
    "action": "NONE",
    "tags": ["ERROR"],
    "desc": "승인된 카드 결제의 취소 요청, 취소 처리 상태, 환불 일정 및 입금 여부를 확인하려는 문의입니다."
  },
  ...
]

Figure 1. 전체 온톨로지 맵

Figure 2. 온톨로지 맵 확대

사용자 질문이 입력되면 시스템은 Qwen3 32B와 같은 sLLM을 활용하여 핵심 속성인 Domain, Action, Tag를 추출합니다. 구체적으로, 각 속성별로 사전 정의된 용어 정의(Term Definitions)를 프롬프트에 포함시켜 sLLM에게 “이 대화는 어떤 Domain에 해당하는가?”, “어떤 Action인가?”, “어떤 Tag가 해당되는가?”를 각각 독립적으로 질의합니다. sLLM은 제공된 정의 목록 중에서 가장 적합한 값을 선택하여 반환합니다.

이후 추출된 속성은 규칙 기반의 그래프 매칭(Graph Matching) 로직을 통해 온톨로지 지식 체계와 매칭됩니다. 매칭은 다음과 같은 우선순위로 진행됩니다:

Tag 우선 매칭: 추출된 Tag와 온톨로지 내 인텐트의 Tag 간 교집합이 존재하는 후보를 먼저 필터링합니다.
Domain/Action 교차 검증: Tag 후보군 내에서 Domain 또는 Action이 일치하는 인텐트를 최종 후보로 좁힙니다.
단일 후보 확정 또는 LLM 중재: 후보가 1개이면 즉시 확정하고, 복수 후보가 남을 경우 사용자 원문 질의와 각 후보의 설명을 비교하여 LLM이 최적 인텐트를 선택합니다.

즉, sLLM은 속성 추출 단계에서 “분류기”로 활용되며, 최종 인텐트 확정은 구조화된 규칙 기반 매칭이 담당합니다. 모델이 직접 51개 인텐트 중 하나를 고르는 것이 아니라, 추출된 속성 조합으로 후보를 좁힌 뒤 결정론적(deterministic)으로 매칭하기 때문에 일관성과 설명 가능성이 높아집니다.

결과: 정확도 향상과 지연 시간(Latency)의 혁신적 단축

이러한 온톨로지 맵에 기반한 인텐트 분류는 특히 난도가 높았던 ‘카드 한도 관리’ 시나리오에서 매우 의미 있는 성능 향상을 보였습니다.

지표	베이스라인 (Baseline)	온톨로지 기반	개선 폭
Qwen3 235B A22B (LLM)	77.4%	88.7%	+11.3%
Qwen3 32B (sLLM)	84.2%	91.0%	+6.8%

소형 모델 Qwen3 32B, 대형 모델 Qwen3 235B A22B에 온톨로지 기반 인텐트 분류를 적용한 결과, 기존 방법 (베이스라인) 대비 분류 정확도가 각각 6.8%, 11.3% 향상했습니다. 주목할 점은 Qwen3 32B가 파라미터 수가 8배 많은 Qwen3 235B A22B 모델보다도 2.3%p 높은 정확도를 달성했다는 점입니다. 이는 정교한 지식 체계(Ontology)가 뒷받침된다면, 소형 모델로도 대형 모델을 압도하는 정밀한 추론이 가능하다는 것을 입증합니다. 더불어, 온톨로지 방식은 대화 도중 인텐트가 바뀌는 topic switching 테스트 케이스에서도 98%에 가까운 정확도로 인텐트의 전환을 감지하였습니다.

온톨로지 기반 접근법은 운영 효율성 측면에서도 강점을 보였습니다. 51개 인텐트의 전체 설명을 매번 입력 값으로 전달할 경우 대략 4,800 토큰이 필요한 반면, 각 핵심 속성 (Domain, Action, Tags)에 대한 추론은 약 1,890 토큰 (630토큰 x 3) 수준으로 훨씬 적은 수의 토큰을 소모합니다. 또한 세 핵심 속성을 추출하는 과정은 서로 독립적이기 때문에 병렬처리가 가능하여, 단일 순차 호출 대비 총 지연시간을 약 1/3수준으로 단축할 수 있습니다.

이러한 토큰 효율화와 병렬 처리의 결합은 프로덕션 환경에서 필수적인 응답 지연 시간(Latency)을 획기적으로 단축하여, 고성능과 고효율을 동시에 달성하는 핵심 동력이 되었습니다.

혁신 2. 분산형 (Decentralized) Agentic AI 아키텍처

중앙집중형 (Centralized) Agentic AI의 한계

기존의 중앙 집중형(Centralized) 에이전틱 AI 아키텍처에서는 오케스트레이터(Orchestrator)가 핵심 역할을 수행합니다. 오케스트레이터는 사용자 입력을 분석하고, 적절한 전문 에이전트에 작업을 위임하며, 최종 응답을 생성합니다.

이 구조에서 오케스트레이터(Central Orchestrator)는 높은 지능을 요구합니다. Qwen3 235B A22B, Claude Sonnet 4.5, Claude Opus 4.5 같은 대형 모델에서는 작동하지만, Qwen3 32B나 gpt-oss-20b 같은 sLLM은 오케스트레이터 역할을 수행할 수 없었습니다. 즉, 오케스트레이터가 시스템 전체의 병목이 되는 것입니다. 설령 대형 모델을 사용하더라도, 추론 시간이 길어 5초 이내 응답이라는 요건을 충족하기 어렵습니다. 즉, 중앙 집중형 아키텍처에서는 sLLM으로는 정확도가 부족하고, 대형 모델로는 속도가 부족한 딜레마에 빠집니다.

해결책 : 분산형 (Decentralized) Agentic AI – 아키텍처로 지능을 보완하다

분산형 Agentic AI의 핵심 발상은 단순합니다. 하나의 똑똑한 오케스트레이터가 모든 것을 판단하는 대신, 모든 에이전트가 동시에 하나의 쉬운 질문에만 답하게 하는 것입니다.

각 에이전트는 “이 쿼리가 나와 관련 있는가?”라는 단 하나의 이진 분류(Binary Classification)만 수행합니다. 하나의 모델이 수십 개 에이전트의 역할과 경계를 모두 이해하고 최적의 하나를 선택하는 것은 어려운 작업이지만, 각 에이전트가 “내 것인가 아닌가”를 판단하는 것은 sLLM으로도 충분히 가능한 단순한 작업입니다.

모든 에이전트가 이 판단을 동시에 병렬로 수행하기 때문에, 에이전트가 2개든 51개든 응답 시간은 동일합니다. 관련 있다고 판단한 에이전트만 후속 작업을 수행하고, 최종적으로 결과를 통합하여 사용자에게 전달합니다. 결과적으로 이 아키텍처는:

오케스트레이터의 지능 부족을 아키텍처 설계로 우회
sLLM만으로 모든 에이전트를 실행 – Claude Opus 4.5 대비 ~18배 비용 절감
병렬 실행으로 5초 이내 응답 요건 충족

혁신 3. 자율적 시스템 업데이트 (AI-to-AI Dialogue for Autonomous System Updates)

챗봇 개발의 어려움

Agentic AI 챗봇의 성능을 검증하고 개선하는 과정에는 구조적인 어려움이 있습니다.

실제 고객과 상담원의 대화는 단순한 1~2턴의 질의응답이 아닙니다. 여러 턴에 걸쳐 맥락이 이어지고, 의도가 변경되며, 예상치 못한 분기가 발생합니다. 챗봇이 프로덕션 수준의 품질을 갖추려면 이러한 멀티턴 대화를 현실적으로 시뮬레이션하여 테스트해야 합니다. 그러나 수백 가지 시나리오의 멀티턴 대화를 정적으로 미리 준비해두는 것은 현실적으로 불가능합니다. 고객의 표현 방식, 감정 상태, 대화 흐름은 무한에 가까운 조합을 만들어냅니다.

또한 테스트를 통해 문제점을 발견하더라도, 이를 분석하고 챗봇 로직을 업데이트하는 과정에는 엔지니어의 수동 개입이 필요합니다. 실패 세션 분석 → 원인 파악 → 코드 수정 → 재배포의 사이클은 수일에서 수주가 소요됩니다.

우리는 이 전체 과정 (멀티턴 대화 시뮬레이션, 실패 분석, 시스템 업데이트)를 전부 AI에게 맡기는 시도를 했습니다.

해결책: Tikitaka – AI가 AI를 평가하고 개선하는 자율 시스템

Tikitaka는 AI 에이전트들이 구조화된 대화를 통해 챗봇을 테스트하고, 실패를 분석하며, 시스템 로직을 자율적으로 업데이트하는 자가 치유 시스템입니다.

4단계 AI-to-AI 대화 워크플로우

Stage 1 – 페르소나 기반 멀티턴 대화 시뮬레이션

실제 고객 데이터 분석에서 도출된 페르소나를 활용하여 Test Agent가 챗봇과 현실적인 멀티턴 대화를 수행합니다. 정적 스크립트가 아닌 AI가 동적으로 생성하는 대화이기 때문에, 다양한 표현과 감정 변화를 자연스럽게 재현합니다.

Stage 2 – 실패 감지 및 근본 원인 분석

Analyzer Agent가 대화 흐름을 검토하여 비정상 패턴을 감지하고, 영향을 받는 코드 컴포넌트와 함수까지 특정하여 근본 원인을 식별합니다.

Analyzer Agent 진단:
  Turn 9 | issue: goal_mismatch
         | 영향 컴포넌트: asrada.py → _route_to_agent()
         | 제안: 카드 상태 확인 의도와 사용 내역 조회 의도를 구분하여 적절한 에이전트로 라우팅

  Turn 10 | issue: flow_error
          | 영향 컴포넌트: asrada.py → _on_context_change()
          | 제안: 세션 내 인증된 고객번호를 컨텍스트에 유지하고 재인증 요청 없이 후속 조회 가능하도록 개선

Stage 3 – AI 대화를 통한 솔루션 제안 및 적용

Code Reviewer Agent가 라우팅 로직을 분석하고, Solution Designer Agent가 구체적인 수정안을 제안합니다.

Solution Designer Agent 제안:
  1. '한도 변경' 변형 표현에 대한 인텐트 인식 패턴 강화
  2. _on_context_change()에 세션 상태 영속성 구현
  3. Credit Limit Management Agent로의 라우팅 로직 수정

Stage 4 – 검증 및 자율 배포

수정된 시스템을 동일 페르소나로 재테스트하여 검증한 뒤, Update Agent가 프로덕션에 변경 사항을 적용하고 모니터링을 수행합니다.

Before & After: 실제 개선 사례

개선 전 – 페르소나 기반 AI가 챗봇과 멀티턴 대화를 시뮬레이션합니다. 주목할 점은 Test Agent가 단순히 정해진 스크립트를 따르는 것이 아니라, 실제 고객처럼 반복되는 루프에 점점 짜증을 내고 불만을 표출한다는 것입니다:

턴 1 | 사용자(AI): "한도 왜 갑자기 줄었어요 저번달까지 500이었는데"
     | 봇: "고객번호 10자리를 입력해주세요. (예: 0001234567)"

턴 2 | 사용자(AI): "0001234567"
     | 봇: "입력하신 번호는 어떤 정보를 확인하시려는 것인가요?"

턴 3 | 사용자(AI): "한도 줄어든 이유요"
     | 봇: "고객번호 10자리를 입력해주세요. (예: 0001234567)"

턴 5 | 사용자(AI): "한도요 한도 왜 줄었는지 확인해달라고요"
     | 봇: "고객번호 10자리를 입력해주세요. (예: 0001234567)"

턴 7 | 사용자(AI): "아 진짜 몇번을 말해요 한도요 한도!! 신용카드 한도
     |             왜 줄었는지 확인해달라고요"
     | 봇: "고객번호 10자리를 입력해주세요. (예: 0001234567)"

페르소나 AI는 턴이 반복될수록 실제 고객처럼 감정이 격해집니다. 이는 정적 테스트 스크립트로는 절대 재현할 수 없는 현실적인 대화 패턴입니다.

AI 평가 결과:

"봇이 7턴 동안 고객번호 입력 요청과 의도 확인 질문만 무한 반복하며 사용자의 명확한 한도 조회/상향 요청을 전혀 처리하지 못함. 컨텍스트 유지, 상태 관리, 의도 인식 기능에 심각한 결함이 있으며, 사용자 감정 대응도 전무하여 서비스 품질이 매우 낮음."

개선 후 – AI-to-AI 자율 업데이트 적용. 원래 7턴으로 설계된 테스트였으나, 챗봇이 충분히 잘 응답하여 4턴 만에 목표를 달성합니다:

턴 1 | 사용자(AI): "한도 얼마나 남았어요?"
     | 봇: "고객번호 10자리를 입력해주세요. (예: 0001234567)"

턴 2 | 사용자(AI): "0001234567"
     | 봇: "현재 한도: 1,200,000원, 최대 한도: 5,000,000원입니다.
     |      변경할 금액을 말씀해주세요."

턴 3 | 사용자(AI): "500만원으로 올려줘"
     | 봇: "총 한도 5,000,000원(현금 1,500,000원)으로 상향하시겠습니까? (네/아니오)"

턴 4 | 사용자(AI): "네"
     | 봇: "✅ 한도 변경이 완료되었습니다. 요청하신 금액 5,000,000원이
     |      반영되었습니다. 또 다른 것을 도와드릴까요?"

AI 평가 결과:

"전체적으로 한도 조회 및 상향 변경이라는 사용자 목적을 성공적으로 달성한 대화입니다."

핵심 혁신

Tikitaka는 반응적 유지보수(문제 발생 → 사람이 분석 → 수동 수정)에서 능동적 자가 치유(AI가 시뮬레이션 → AI가 분석 → AI가 수정)로의 패러다임 전환입니다. 멀티턴 대화 테스트의 현실적 어려움을 AI 시뮬레이션으로 해결하고, 발견된 문제의 분석과 수정까지 AI에게 위임함으로써 사람의 개입 없이 시스템이 스스로 진화하는 자율 개선 루프를 구현했습니다.

시스템 아키텍처

아래는 AWS 환경에서 구현된 시스템 아키텍쳐입니다.

Step 1 – 온톨로지 기반 인텐트 분류 (Router Agent)

Router Agent가 사용자 쿼리를 수신하고, 온톨로지 기반 병렬 분류를 수행하여 어떤 전문 에이전트가 요청을 처리할지 결정합니다. Amazon Bedrock을 통해 Domain, Action, Tags 세 차원이 동시에 추론됩니다. Router Agent를 포함하여 해당 솔루션에서의 에이전트들은 Amazon Bedrock AgentCore를 통해 배포/관리됩니다.

Step 2 – 전문 에이전트 처리 (sLLM 기반)

라우팅된 전문 에이전트가 Qwen3 32B 기반의 병렬 자기 라우팅으로 작업을 수행합니다. 예를 들어 “고객번호 0001234567, 330만 원으로 올려줘”라는 쿼리가 들어오면, InformationExtractor가 고객번호와 금액을 동시에 추출하고, LimitCheckAgent → ValidationAgent → ConfirmAgent가 자동으로 체이닝됩니다.

Step 3 – 백엔드 데이터 접근 (MCP)

전문 에이전트는 AgentCore Gateway(MCP)를 통해 백엔드 데이터에 접근합니다. MCP가 REST API를 MCP 호환 도구로 변환하고, Lambda 함수가 비즈니스 로직을 실행하여 DynamoDB에서 고객 데이터(한도 정보, 거래 내역 등)를 조회합니다.

Step 4 – AI 추론 (Amazon Bedrock)

에이전트들은 Amazon Bedrock을 통해 Qwen3 32B에 접근합니다. 자연어 이해, 인텐트 검증, 응답 생성, 맥락 추론 등을 수행하며, AWS PrivateLink를 통해 퍼블릭 인터넷을 경유하지 않는 안전하고 저지연 연결을 보장합니다.

Step 5 – 응답 전달

최종 결과가 사용자에게 전달됩니다.

맺음말 및 향후 계획

본 프로젝트를 통해 온톨로지 기반 인텐트 분류, 분산형 Agentic AI, AI-to-AI 대화라는 세 가지 혁신이 소형 언어모델의 한계를 극복하고 프로덕션 수준의 금융 AI 챗봇을 구현할 수 있음을 검증했습니다. 핵심 성과를 요약하면 다음과 같습니다.

인텐트 분류 정확도의 비약적 향상 (예: 카드 한도 관리 시나리오, 84.2% → 91%)
인텐트 전환(Topic Switching) 정확도 98% – 대화 중 갑작스러운 주제 전환에도 완벽 대응
비용 ~18배 절감 – Claude Opus 4.5 대비 Qwen3 32B 기반 분산형 아키텍처로 달성
5초 이내 응답 – 분산형 Agentic AI의 병렬 호출로 레이턴시 요건 충족

현재 신용 한도 관리와 카드 이용내역 조회 2개 유즈 케이스로 검증을 완료했으며, 상용 배포를 위해 다음 단계를 진행합니다.

온톨로지 확장 및 에이전트 수평 확장

현재 2개 에이전트에서 신한카드 전체 서비스 포트폴리오를 커버하는 51개 에이전트로 확장합니다. 온톨로지 역시 신규 도메인(보험, 대출 등)과 액션 타입(이체, 정지 등)을 추가하여 51개 인텐트를 완전히 수용할 수 있도록 확장합니다.

보안 가드레일 적용

프로덕션 환경에서는 프롬프트 인젝션 방어, 강화된 PII 마스킹, 부적절한 콘텐츠 필터링, 비정상 쿼리 패턴 탐지 등 종합적인 보안 가드레일을 적용합니다. 금융 규제(개인정보보호법) 준수를 위한 감사 로깅과 암호화도 함께 구현합니다.

신한카드 Chatbot 0.3은 2026년 6월 상용 배포를 목표로 개발을 진행하고 있습니다. “작은 모델로도 큰 지능을 구현할 수 있는가?”라는 질문에 대해, 올바른 아키텍처 설계가 모델 크기의 한계를 넘어설 수 있음을 보여주는 사례가 되길 기대합니다.

AWS 기술 블로그