보험 설계사 AI 교육 플랫폼, MySQL HeatWave로 어떻게 만들었나요?
핵심 요약: HeatWave Vector Store로 보험 문서 RAG, 교육 이력, 평가 데이터를 단일 플랫폼에서 처리한 구축 사례예요. 벡터 DB 분리 없이 보안과 운영 복잡도를 줄이는 설계 방식을 다뤄요.
보험 설계사 교육에는 구조적인 어려움이 있어요. 다양한 고객 유형을 상대하는 실전 감각은 실제 상담 경험을 통해서만 쌓이는데, 신입 설계사에게 처음부터 실제 고객을 맡기기는 어렵죠. 그렇다고 강의실 교육만으로는 "까다로운 고객", "보험 지식이 전혀 없는 고객", "이미 여러 상품을 비교해본 고객" 같은 다양한 상황에 대응하는 능력을 키우기 힘들어요.
삼성화재에서 이 문제를 AI로 풀어보자는 아이디어가 나왔을 때, 저희 에이핀이 아키텍처 설계부터 구현까지 함께했어요. 핵심은 MySQL HeatWave의 Vector Store를 활용한 RAG 파이프라인이었어요. 보험 상품 문서, 상담 매뉴얼, FAQ를 벡터화해서 AI가 실시간으로 참조하면서 고객 역할을 시뮬레이션하는 구조예요.
이 글에서는 그 아키텍처와 구현 방식, 그리고 실제 운영에서 발견한 트레이드오프를 공유할게요.
왜 HeatWave Vector Store를 선택했나요?
처음 아키텍처를 설계할 때 벡터 DB 선택지는 여러 개였어요. Pinecone, Weaviate, pgvector 같은 전용 벡터 DB도 검토했어요. 하지만 실제 프로젝트에서 요구사항을 분석하면서 HeatWave Vector Store가 가장 적합하다는 결론에 도달했어요.
핵심 이유는 데이터 통합이에요. 보험 플랫폼에서는 벡터 검색만 필요한 게 아니에요. 설계사별 교육 이력, 시뮬레이션 결과, 평가 점수 같은 트랜잭션 데이터도 함께 관리해야 해요. 전용 벡터 DB를 쓰면 OLTP 데이터는 MySQL에, 벡터 데이터는 별도 시스템에 분산되고, 두 시스템을 연결하는 레이어가 추가로 필요해요.
HeatWave는 이 문제를 단일 플랫폼으로 해결해요. 트랜잭션 처리, 벡터 저장과 검색, ML 추론이 모두 MySQL HeatWave 안에서 이루어져요. 마치 하나의 도서관에서 책 검색, 대출 기록 관리, 독서 이력 분석을 모두 처리하는 것과 비슷해요. 별도 시스템을 오가는 복잡성이 사라지는 거예요.
보안 요건도 중요한 이유였어요. 보험 상품 정보와 상담 데이터는 민감한 정보예요. HeatWave는 MySQL Enterprise Edition 기반이라 Data Masking, 감사 로그, 접근 제어가 기본 포함돼 있어요. 별도 보안 솔루션을 추가하지 않아도 ISMS-P 요건을 충족할 수 있는 구조예요.
| 항목 | 전용 벡터 DB (Pinecone 등) | HeatWave Vector Store |
|---|---|---|
| 벡터 검색 | 전용 최적화 | 인메모리 MPP 기반 |
| OLTP 통합 | 별도 DB 필요 | 단일 플랫폼 |
| 보안 기능 | 별도 구성 필요 | Enterprise Edition 내장 |
| 운영 시스템 수 | 2개 이상 | 1개 |
| SQL 인터페이스 | 미지원 | 지원 |
| 비용 구조 | 벡터 DB + OLTP DB 이중 과금 | 단일 과금 |
전체 아키텍처, 어떻게 구성했나요?
시스템은 크게 세 흐름으로 나뉘어요. 문서 수집과 벡터화, 실시간 시뮬레이션, 그리고 평가와 피드백이에요.
문서 수집 단계에서는 보험 상품 설명서, 약관 요약, 상담 매뉴얼, FAQ를 LangChain의 Document Loader로 읽어요. PDF, DOCX, HTML 형식을 모두 지원해요. 청킹(Chunking) 후 OpenAI Embedding API로 벡터를 생성하고, HeatWave Vector Store에 저장해요.
시뮬레이션 단계에서는 설계사가 교육 시나리오를 선택하면 LangChain RAG 파이프라인이 동작해요. HeatWave에서 관련 문서를 벡터 유사도 검색으로 찾고, 그 컨텍스트를 바탕으로 Gemini가 고객 페르소나를 연기해요. 설계사의 응답은 OpenAI GPT가 평가하고 피드백을 생성해요.
HeatWave Vector Store 구현, 핵심 코드
실제 구현에서 가장 중요한 부분은 문서 벡터화와 저장, 그리고 LangChain 연동이에요.
먼저 HeatWave에 벡터 테이블을 생성하고 문서를 로드하는 과정이에요.
-- 보험 문서 벡터 테이블 생성
CREATE TABLE insurance_docs (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
doc_id VARCHAR(255) NOT NULL,
chunk_text LONGTEXT NOT NULL,
metadata JSON,
embedding VECTOR(1536) NOT NULL COMMENT 'OpenAI text-embedding-3-small',
created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
INDEX idx_doc_id (doc_id)
);
-- HeatWave Vector Store에 테이블 등록
ALTER TABLE insurance_docs SECONDARY_ENGINE=RAPID;
ALTER TABLE insurance_docs SECONDARY_LOAD;
-- 벡터 유사도 검색 (코사인 유사도)
SELECT
doc_id,
chunk_text,
metadata,
DISTANCE(embedding, :query_vector, 'COSINE') AS similarity
FROM insurance_docs
ORDER BY similarity ASC
LIMIT 5;LangChain에서 HeatWave Vector Store를 연결하는 코드예요. MySQLVectorStore 커넥터를 사용해요.
from langchain_community.vectorstores import MySQLVectorStore
from langchain_openai import OpenAIEmbeddings
from langchain.chains import RetrievalQA
from langchain_google_genai import ChatGoogleGenerativeAI
# HeatWave Vector Store 연결
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vector_store = MySQLVectorStore(
connection_string="mysql+pymysql://user:pass@heatwave-host:3306/insurance_db",
embedding_function=embeddings,
table_name="insurance_docs",
)
# RAG 파이프라인 구성
retriever = vector_store.as_retriever(
search_type="similarity",
search_kwargs={"k": 5},
)
# Gemini로 고객 페르소나 시뮬레이션
gemini = ChatGoogleGenerativeAI(model="gemini-1.5-pro")
simulation_chain = RetrievalQA.from_chain_type(
llm=gemini,
chain_type="stuff",
retriever=retriever,
return_source_documents=True,
)
# 시뮬레이션 실행
result = simulation_chain.invoke({
"query": "종신보험 상담을 받으러 온 40대 직장인 고객 역할을 해줘. "
"보험료가 비싸다고 느끼고 있고, 필요성에 대해 반신반의하는 상태야."
})운영하면서 느낀 건, 청킹 전략이 검색 품질에 생각보다 큰 영향을 준다는 거예요. 보험 약관처럼 구조화된 문서는 섹션 단위로 청킹하는 게 효과적이었어요. 반면 FAQ는 Q&A 쌍을 하나의 청크로 유지하는 게 검색 정확도를 높였어요.
고객 페르소나 시뮬레이션, 어떻게 설계했나요?
시뮬레이션의 품질은 페르소나 설계에 달려 있어요. 단순히 "고객 역할을 해줘"라고 프롬프트를 주면 AI가 너무 협조적인 고객을 연기해서 교육 효과가 떨어져요.
실제 프로젝트에서 만든 페르소나 유형은 크게 네 가지예요. 보험에 무관심한 고객, 가격에 민감한 고객, 이미 여러 상품을 비교해본 고객, 과거에 보험 관련 불만 경험이 있는 고객이에요. 각 유형마다 HeatWave에서 관련 상담 사례와 대응 매뉴얼을 검색해서 컨텍스트로 제공해요.
-- 페르소나 유형별 관련 상담 사례 검색
SELECT
s.case_summary,
s.resolution_approach,
DISTANCE(s.embedding, :persona_vector, 'COSINE') AS relevance
FROM consultation_cases s
WHERE s.persona_type = :persona_type
ORDER BY relevance ASC
LIMIT 3;Gemini가 이 컨텍스트를 바탕으로 고객을 연기하면, 설계사의 응답을 OpenAI GPT가 평가해요. 평가 기준은 상품 설명의 정확성, 고객 니즈 파악 여부, 적절한 공감 표현, 규정 준수 여부예요.
원인을 추적한 끝에 발견한 건, 평가 프롬프트에 구체적인 루브릭(채점 기준)을 넣었을 때 평가 일관성이 크게 올라간다는 거예요. "좋은 응답인지 평가해줘"보다 "다음 4가지 기준으로 각각 1–5점을 매겨줘"가 훨씬 안정적인 결과를 냈어요.
실제 운영 결과, 수치로 보면
삼성화재 내부 파일럿 운영 결과(출처: A-FIN 내부 프로젝트)를 정리했어요.
| 지표 | 도입 전 | 도입 후 | 변화 |
|---|---|---|---|
| 설계사 1인당 교육 완료 시간 | 기준 | 50% 단축 | 2배 효율 향상 |
| 상담 준비 시간 (신규 상품 출시 시) | 기준 | 40% 단축 | 준비 부담 감소 |
| 시뮬레이션 시나리오 수 | 수십 개 (강사 의존) | 수백 개 (자동 생성) | 다양성 대폭 확대 |
| 벡터 검색 응답 시간 | N/A | 평균 120ms | HeatWave 인메모리 처리 |
교육 효율이 2배 향상됐다는 수치의 의미를 조금 더 설명하면, 같은 시간 안에 더 많은 시나리오를 경험할 수 있게 됐다는 거예요. 기존 강사 주도 롤플레이는 한 세션에 2–3개 시나리오가 한계였는데, AI 시뮬레이션은 설계사가 원하는 만큼 반복할 수 있어요.
벡터 검색 응답 시간 120ms는 HeatWave의 인메모리 처리 덕분이에요. 보험 문서 수만 건을 벡터화해서 저장해도 실시간 대화 흐름을 끊지 않는 속도예요. 처음에는 이 정도 속도가 나올지 확신이 없었는데, 실제로 운영해보니 사용자 경험에 충분한 수준이었어요.
운영에서 발견한 한계와 트레이드오프
좋은 결과만 있었던 건 아니에요. 실제 운영에서 만난 문제들도 공유할게요.
임베딩 비용이 예상보다 컸어요. 보험 문서는 분량이 많고 주기적으로 업데이트돼요. 상품 개정이 있을 때마다 관련 문서를 재임베딩해야 하는데, OpenAI Embedding API 비용이 누적되면 무시할 수 없는 수준이에요. 변경된 섹션만 선택적으로 재임베딩하는 로직을 별도로 구현했어요.
청킹 전략 튜닝도 생각보다 공수가 많이 들었어요. 보험 약관은 법적 문서라 문장 구조가 복잡하고, 단순 토큰 기반 청킹으로는 의미 단위가 잘려나가는 경우가 많았어요. 섹션 헤더를 기준으로 청킹하는 방식으로 전환하면서 검색 품질이 올라갔지만, 이 과정에서 여러 번의 시행착오가 있었어요.
멀티모달 처리는 아직 제한적이에요. 보험 상품 설명서에는 표와 그래프가 많은데, 현재 구조에서는 텍스트 추출 후 임베딩하는 방식이라 시각적 정보가 손실돼요. Gemini의 멀티모달 기능을 활용해서 이미지 포함 문서를 처리하는 방향을 검토 중이에요.
LLM 응답의 일관성도 과제예요. 같은 시나리오라도 LLM이 매번 다른 방식으로 고객을 연기하면 교육 효과를 측정하기 어려워요. 시드(seed) 값 고정과 온도(temperature) 조정으로 어느 정도 제어하고 있지만, 완전한 재현성은 아직 달성하지 못했어요.
HeatWave GenAI 기능, 어디까지 활용할 수 있나요?
이번 프로젝트에서는 HeatWave Vector Store를 외부 임베딩(OpenAI)과 함께 사용했어요. 하지만 HeatWave 자체에도 GenAI 기능이 내장돼 있어요.
sys.ML_GENERATE() 프로시저를 사용하면 SQL 안에서 직접 LLM을 호출할 수 있어요. 외부 오케스트레이션 레이어 없이 데이터베이스 안에서 AI 추론을 처리하는 방식이에요.
-- HeatWave 내장 GenAI로 문서 요약 생성
CALL sys.ML_MODEL_LOAD('mistral-7b-instruct-v1', NULL);
SELECT sys.ML_GENERATE(
CONCAT(
'다음 보험 약관 내용을 설계사가 고객에게 쉽게 설명할 수 있도록 3줄로 요약해줘:\n\n',
chunk_text
),
JSON_OBJECT('task', 'generation', 'model_id', 'mistral-7b-instruct-v1')
) AS summary
FROM insurance_docs
WHERE doc_id = 'product_001'
LIMIT 1;이 방식의 장점은 데이터가 외부로 나가지 않는다는 거예요. 보험사 입장에서 민감한 상품 정보나 고객 데이터를 외부 LLM API로 보내는 것에 대한 우려가 있을 수 있어요. HeatWave 내장 GenAI를 활용하면 데이터가 DB 밖으로 나가지 않아요.
다만 내장 모델의 성능은 GPT-4나 Gemini 1.5 Pro 대비 제한적이에요. 복잡한 추론이나 고품질 생성이 필요한 작업에는 외부 LLM을 사용하고, 단순 요약이나 분류 작업에는 내장 모델을 활용하는 하이브리드 전략이 현실적이에요.
핵심 요약
- MySQL HeatWave Vector Store는 벡터 검색, OLTP, ML 추론을 단일 플랫폼에서 처리해요. 전용 벡터 DB와 OLTP DB를 분리 운영하는 복잡성을 줄일 수 있어요.
- LangChain
MySQLVectorStore커넥터로 RAG 파이프라인을 구성하면, HeatWave의 인메모리 벡터 검색을 LangChain 생태계와 자연스럽게 연결할 수 있어요. - 삼성화재 파일럿에서 설계사 교육 효율 2배 향상, 상담 준비 시간 40% 단축을 달성했어요. 벡터 검색 응답 시간은 평균 120ms예요.
- 청킹 전략과 임베딩 비용 관리가 실제 운영의 핵심 과제예요. 문서 구조에 맞는 청킹 방식을 초기에 충분히 실험해야 해요.
- HeatWave 내장 GenAI(
sys.ML_GENERATE())는 데이터 외부 유출 우려가 있는 환경에서 유용해요. 단순 작업에는 내장 모델, 복잡한 추론에는 외부 LLM을 조합하는 전략이 현실적이에요.
FAQ
Q. HeatWave Vector Store와 Pinecone 같은 전용 벡터 DB의 성능 차이는 어느 정도인가요?
단순 벡터 검색 속도만 비교하면 전용 벡터 DB가 더 최적화된 경우도 있어요. 하지만 실제 엔터프라이즈 환경에서는 벡터 검색만 필요한 게 아니에요. OLTP 데이터와 벡터 데이터를 함께 조회하거나, 트랜잭션 처리와 AI 추론을 같은 플랫폼에서 처리해야 하는 경우가 많아요. 이런 통합 시나리오에서는 HeatWave가 시스템 복잡도와 운영 비용 면에서 유리해요.
Q. OpenAI Embedding 대신 HeatWave 내장 임베딩을 사용할 수 있나요?
사용할 수 있어요. CALL sys.VECTOR_STORE_LOAD() 프로시저를 사용하면 HeatWave가 자체적으로 문서를 청킹하고 임베딩해요. 외부 API 호출 없이 DB 안에서 전체 파이프라인이 완결돼요. 다만 임베딩 품질은 OpenAI text-embedding-3-small 대비 낮을 수 있어요. 검색 정확도가 중요한 도메인이라면 외부 임베딩 모델을 사용하고, 비용과 데이터 보안이 우선이라면 내장 임베딩을 선택하는 게 합리적이에요.
Q. 보험 문서처럼 주기적으로 업데이트되는 문서는 어떻게 관리하나요?
변경된 문서만 선택적으로 재임베딩하는 방식을 권장해요. doc_id와 updated_at 컬럼을 관리하면서, 문서 해시값을 비교해 변경된 청크만 삭제하고 재삽입하는 로직을 구현했어요. 전체 재임베딩은 비용과 시간이 많이 들기 때문에, 증분 업데이트 전략을 초기 설계 단계에서 반드시 고려해야 해요.
Q. LangChain 없이 HeatWave Vector Store만으로 RAG를 구현할 수 있나요?
가능해요. HeatWave의 sys.ML_GENERATE() 프로시저를 사용하면 SQL 안에서 벡터 검색과 LLM 호출을 모두 처리할 수 있어요. 외부 오케스트레이션 레이어가 필요 없는 In-Database RAG 방식이에요. 다만 LangChain을 사용하면 프롬프트 관리, 메모리, 에이전트 같은 고급 기능을 더 쉽게 구현할 수 있어요. 단순한 Q&A 시스템이라면 In-Database RAG로 충분하고, 복잡한 대화 흐름이 필요하다면 LangChain 조합을 권장해요.
Q. 이 아키텍처를 보험 외 다른 금융 도메인에도 적용할 수 있나요?
적용할 수 있어요. 핵심 패턴은 "대규모 전문 문서를 벡터화해서 AI가 실시간으로 참조하게 하는 것"이에요. 은행의 여신 심사 교육, 증권사의 상품 설명 시뮬레이션, 카드사의 고객 상담 훈련 등에도 같은 구조를 적용할 수 있어요. 도메인마다 청킹 전략과 페르소나 설계가 달라지지만, HeatWave Vector Store + LangChain + LLM 조합의 기본 아키텍처는 동일하게 가져갈 수 있어요.
운영하면서 계속 느낀 건, AI 교육 플랫폼의 품질은 결국 데이터 파이프라인의 품질에 달려 있다는 거예요. 어떤 LLM을 쓰느냐보다, 어떤 문서를 어떻게 청킹해서 어떤 컨텍스트를 제공하느냐가 시뮬레이션 품질을 결정해요.
다음 글에서는 HeatWave Autopilot을 활용한 벡터 인덱스 자동 최적화와 대규모 문서 환경에서의 검색 성능 튜닝을 다룰게요. HeatWave의 GenAI 기능 전반이 궁금하다면, HeatWave GenAI와 Vector Store로 무엇을 할 수 있나요?도 함께 읽어보세요.