금융 AI의 성패는 '맥락'에 있다: LLM 멀티턴 대화 능력의 실체
단순 질의응답을 넘어 복잡한 금융 상담을 수행하기 위해 필수적인 LLM의 멀티턴 대화 유지 능력을 분석하고, 실제 서비스 도입 시 고려해야 할 기술적 트레이드오프를 살펴봅니다.
많은 기업이 챗봇을 도입하며 ‘AI가 고객의 질문에 답한다’는 사실에 만족합니다. 하지만 실제 금융 서비스 현장에서 고객이 던지는 질문은 단발성이 아닙니다. “내 계좌 잔액 알려줘”라는 질문 뒤에 바로 이어지는 “그럼 거기서 10만 원을 적금으로 옮겨줘”라는 요청은 앞선 맥락을 완벽하게 이해해야만 처리가 가능합니다. 바로 여기서 ‘멀티턴(Multi-turn) 대화 능력’이라는 거대한 장벽이 나타납니다.
대부분의 LLM 벤치마크는 단일 질문에 대한 정확도(Zero-shot)에 집중합니다. 하지만 금융 AI의 핵심은 사용자의 의도가 시간에 따라 어떻게 변하는지, 그리고 이전 대화에서 언급된 엔티티(계좌 번호, 금액, 상품명 등)를 얼마나 정확하게 기억하고 유지하는지에 있습니다. 맥락을 놓치는 AI는 단순히 ‘멍청한’ 수준을 넘어, 금융 사고로 이어질 수 있는 치명적인 오류를 범할 수 있기 때문입니다.
멀티턴 대화, 왜 금융 AI에서 유독 어려울까?
금융 도메인의 대화는 일반적인 채팅과 달리 매우 엄격한 제약 조건을 가집니다. 사용자는 대화 도중 갑자기 주제를 바꾸거나, 모호한 지시어(그거, 저번에 말한 것)를 빈번하게 사용합니다. LLM이 이를 처리하기 위해서는 단순히 텍스트를 생성하는 능력이 아니라, 대화의 상태(State)를 관리하는 능력이 필요합니다.
특히 핀테크 서비스에서는 ‘상태 유지(State Management)’와 ‘슬롯 필링(Slot Filling)’이 핵심입니다. 예를 들어 송금 프로세스라면 [수취인, 금액, 계좌번호]라는 세 가지 정보가 모두 채워져야 실행 단계로 넘어갈 수 있습니다. LLM이 멀티턴 대화 중에 이 정보들을 누락 없이 수집하고, 사용자가 중간에 “아니, 금액을 5만 원으로 바꿀게”라고 수정했을 때 즉각적으로 상태를 업데이트하는 능력은 모델의 파라미터 크기만으로는 해결되지 않는 영역입니다.
기술적 구현: 컨텍스트 윈도우와 메모리 전략
LLM의 멀티턴 능력을 구현하는 방식은 크게 세 가지 전략으로 나뉩니다. 첫째는 전체 대화 이력을 프롬프트에 계속 밀어 넣는 ‘Full History’ 방식입니다. 구현은 쉽지만, 대화가 길어질수록 토큰 비용이 기하급수적으로 증가하고 모델이 중간 내용을 잊어버리는 ‘Lost in the Middle’ 현상이 발생합니다.
둘째는 핵심 정보만 요약하여 전달하는 ‘Summarized Memory’ 방식입니다. 이전 대화의 핵심 맥락을 LLM이 스스로 요약하게 하여 컨텍스트 윈도우를 효율적으로 사용하는 방법입니다. 하지만 금융 서비스처럼 정확한 수치가 중요한 분야에서는 요약 과정에서 데이터 왜곡(Hallucination)이 발생할 위험이 큽니다.
셋째는 외부 데이터베이스를 활용한 ‘Structured State Tracking’입니다. 대화 내용 중 중요한 엔티티만 추출하여 별도의 DB나 캐시에 저장하고, 필요할 때마다 이를 프롬프트에 주입하는 방식입니다. 이는 가장 안정적이며 제어 가능성이 높지만, 개발 복잡도가 상승한다는 단점이 있습니다.
모델별 성능 트레이드오프 분석
실제 현업에서 GPT-4, Claude 3, 그리고 Llama 3와 같은 오픈소스 모델을 비교해 보면 뚜렷한 차이가 나타납니다. 최신 폐쇄형 모델들은 기본적으로 긴 컨텍스트 유지 능력이 뛰어나며, 복잡한 지시사항을 멀티턴 상황에서도 잘 준수합니다. 반면 오픈소스 모델들은 특정 도메인에 맞게 파인튜닝(Fine-tuning)했을 때 오히려 더 정교한 상태 관리가 가능해지는 경향이 있습니다.
| 구분 | 폐쇄형 LLM (GPT/Claude) | 오픈소스 LLM (Llama/Mistral) |
|---|---|---|
| 맥락 유지력 | 매우 높음 (기본 성능 우수) | 보통 (튜닝 필요) |
| 추론 비용 | 높음 (토큰당 과금) | 낮음 (인프라 비용 중심) |
| 데이터 보안 | 정책적 신뢰 필요 | 완벽한 온프레미스 제어 가능 |
| 응답 속도 | 네트워크 지연 존재 | 최적화 시 매우 빠름 |
실제 적용 사례: AI 자산관리 비서의 진화
최근 한 핀테크 기업은 단순 FAQ 챗봇을 ‘멀티턴 자산관리 비서’로 업그레이드하며 다음과 같은 워크플로우를 도입했습니다. 사용자가 “내 포트폴리오 분석해줘”라고 요청하면, AI는 먼저 현재 자산 상태를 API로 조회합니다. 이후 “미국 주식 비중이 너무 높은데 어떻게 생각해?”라는 후속 질문이 들어오면, AI는 [현재 포트폴리오 데이터 + 이전 질문의 의도 + 최신 시장 트렌드]를 결합하여 답변을 생성합니다.
이 과정에서 가장 큰 난관은 ‘의도 전환(Intent Switching)’이었습니다. 사용자가 분석 도중 갑자기 “그런데 내일 환율은 어떻게 될 것 같아?”라고 물으면, AI는 자산 분석 모드에서 시장 전망 모드로 전환했다가, 다시 “아까 하던 분석 계속해줘”라고 했을 때 원래의 맥락으로 정확히 돌아와야 합니다. 이를 위해 이들은 ‘인텐트 스택(Intent Stack)’ 구조를 도입하여 사용자의 대화 흐름을 계층적으로 관리함으로써 이탈률을 30% 이상 낮추는 성과를 거두었습니다.
실무자를 위한 단계별 액션 가이드
금융 AI 제품을 설계하는 PM이나 개발자라면 단순히 모델의 성능 지표에 매몰되지 말고, 다음과 같은 실무적 접근법을 취해야 합니다.
- 멀티턴 테스트 셋 구축: 단일 질문 셋이 아니라, 3~5턴으로 구성된 ‘시나리오 기반 테스트 셋’을 만드십시오. 사용자가 중간에 말을 바꾸거나 모호하게 표현하는 케이스를 반드시 포함해야 합니다.
- 상태 관리 레이어 분리: LLM이 모든 것을 기억하게 하지 마십시오. 중요한 금융 데이터(계좌번호, 금액 등)는 별도의 상태 관리 모듈(State Manager)에서 관리하고, LLM은 이를 활용해 답변을 생성하는 ‘도구’로 사용하십시오.
- 가드레일 설정: 멀티턴 대화가 길어질수록 모델이 원래의 목적을 잊고 엉뚱한 답변을 할 확률이 높아집니다. 각 턴마다 현재 대화의 목적을 상기시키는 ‘시스템 프롬프트 리마인드’ 기법을 적용하십시오.
- 샌드박스 테스트 활용: 금융 규제 샌드박스와 같은 제도를 활용해 실제 고객 데이터의 일부를 비식별화하여 소규모 그룹에서 멀티턴 시나리오를 검증하십시오.
결론: 기술보다 중요한 것은 ‘사용자 경험의 설계’
결국 LLM의 멀티턴 능력은 단순한 기술적 스펙의 문제가 아니라, 사용자가 AI와 어떻게 상호작용하는지에 대한 설계의 문제입니다. 아무리 뛰어난 모델이라도 대화의 흐름을 제어하는 프레임워크가 없다면, 금융 서비스에서 요구하는 수준의 신뢰성을 확보할 수 없습니다.
지금 당장 여러분의 AI 서비스에서 가장 빈번하게 발생하는 ‘맥락 단절’ 지점이 어디인지 분석해 보십시오. 그리고 그 지점에 단순한 프롬프트 수정이 아닌, 구조적인 상태 관리 로직을 도입하는 것부터 시작하시기 바랍니다. 금융 AI의 진정한 경쟁력은 화려한 생성 능력이 아니라, 사용자의 의도를 끝까지 놓치지 않는 집요한 맥락 유지 능력에서 나옵니다.
관련 글 추천
- https://infobuza.com/2026/04/29/20260429-jix3iw/
- https://infobuza.com/2026/04/29/20260429-w7xyef/
지금 바로 시작할 수 있는 실무 액션
- 현재 팀의 AI 활용 범위와 검증 절차를 먼저 문서화합니다.
- 작은 파일럿 프로젝트로 KPI를 정하고 2~4주 단위로 검증합니다.
- 보안, 품질, 리뷰 기준을 자동화 도구와 함께 연결합니다.
