증권사 RAG 데이터 파이프라인 운영 & 고도화

TL;DR

KB증권에 들어갔을 땐 RAG 파이프라인이 이미 돌고 있었습니다. 미션은 처음부터 만들기가 아니라 운영하면서 파이프라인 자체를 고도화하는 것 — 이미 돌아가는 시스템의 병목을 식별하고, 운영 안정성을 끌어올리고, 수동 작업을 자동화하는 작업입니다.

세 갈래로 흐릅니다:

• 사내 운영지원 KMS — 내부 임직원이 업무 매뉴얼·정책을 빠르게 찾을 수 있게
• 펀드 / ELS 상품 임베딩 — 고객에게 상품을 설명하기 위한 RAG 코퍼스
• 법령 / 판례 (법무검토 에이전트) — 주기적으로 개정되는 규제 데이터를 자동으로 추적·재임베딩

각 갈래마다 데이터 특성·갱신 주기·정확도 요구가 다르고, 증권 도메인이라 컴플라이언스 기준이 일반 RAG와 다릅니다.

Problem — "이미 돌고 있는 파이프라인"을 다시 보는 일

처음부터 만드는 시스템보다 운영 중인 시스템을 고도화하는 일이 더 어려울 때가 있어요. 이유:

• 이미 사용자가 있다 — 배포 한 번 잘못하면 다운타임이 곧 비즈니스 영향
• 기존 의사결정의 흔적 — 왜 지금 구조인지 맥락부터 파악해야 함
• 개선의 우선순위 — 모든 걸 다 뜯어고칠 수 없으니 어디부터 손댈지가 첫 번째 결정

들어가서 가장 먼저 한 일은 현재 파이프라인의 신호를 읽는 것 — 배치 처리 시간, 실패율, 로그 패턴, 알람 빈도. 그 신호들 안에서 고도화가 가장 효과적인 지점을 골랐습니다.

Approach — 세 갈래의 임베딩 파이프라인

1) 사내 운영지원 KMS

내부 임직원용. 업무 매뉴얼·정책 문서가 주 데이터. 갱신 주기는 상시 — 정책이 바뀌면 즉시 반영돼야 합니다.

2) 펀드 / ELS 상품 임베딩

고객 대상 상품 설명용. 펀드 약관, ELS 상품설명서 등 PDF로 내려오는 정형/반정형 문서가 대부분. 표·각주·면책조항이 많아 일반 텍스트 추출보다 문서 구조 보존이 중요합니다.

3) 법령 / 판례 — 법무검토 에이전트용

신규 use case. 법무검토 에이전트의 backbone이 되는 법령·판례 RAG 코퍼스를 주기적으로 갱신하는 파이프라인. 기존 시스템과 가장 다른 두 가지:

• 수동 PDF 다운로드 → Open API 자동 적재 — 누군가 매번 사이트에서 PDF를 받아와 인덱싱하던 흐름을 Open API 호출로 대체. 사람의 시간을 반복 작업에서 예외 처리로만 좁힘
• 개정감지 (revision detection) — 법령은 자주 바뀝니다. 변경된 조항만 골라 incremental update 하는 로직으로 전체 재처리 비용을 ↓
• 인덱스 표준화 — 기존 법령 인덱스가 표준 스키마와 어긋나 검색·유지보수가 어려웠던 부분을, 다른 코퍼스와 동일한 구조로 통합

이걸 푸는 도구들

• OCR/Parser: marker, Surya — PDF 레이아웃·표·수식을 보존하는 오픈소스 파이프라인
• Chunking: LangChain의 Splitter + Token-based chunking — 문서 종류별로 청크 크기·overlap 조정
• Embedding: Titan Embeddings v2 (Bedrock) — AWS 인프라 안에서 임베딩까지 닫힘, 데이터 외부 유출 위험 ↓
• Vector store: OpenSearch — 메타데이터 필터링이 강력해 상품 유형·갱신 일자 같은 차원으로 후필터 가능
• Metadata DB: PostgreSQL / Teradata — 정형 데이터와 임베딩 메타 연결

Engineering Highlights

OpenSearch Bulk Insert로의 마이그레이션

운영 중 인지한 첫 번째 병목: 임베딩 배치가 점점 길어지고 있었습니다. 데이터가 늘면서 기존 인서트 방식의 한계가 보이는 신호였어요.

대응으로 OpenSearch Bulk API로 마이그레이션. 단순한 API 교체가 아니라:

• 배치 사이즈 튜닝 (너무 크면 메모리 압박, 너무 작으면 효과 없음)
• 실패 시 partial retry 로직 (Bulk가 일부 실패해도 전체 롤백되지 않게)
• CloudWatch 메트릭으로 배치 단위 throughput 가시화

결과는 배치 처리 시간 단축과 운영 중 자정-새벽 윈도우 안에서 안전하게 끝나는 안정성.

로그 표준화로 운영 안정성 향상

운영을 받아보니 로그 패턴이 모듈마다 제각각이었습니다. 장애가 생기면 어디부터 봐야 할지 매번 다시 찾아야 했어요.

로그 포맷을 표준화하고 추적 가능한 trace_id를 파이프라인 전체에 흘려보내는 구조로 정리. 결과적으로:

• 장애 대응 시 원인 모듈 식별 시간 축소
• CloudWatch Insights 쿼리로 배치 실패 케이스 일괄 추출 가능

"기능을 추가하는 것보다 운영을 안정시키는 게 더 큰 임팩트일 때가 있다"

수동 작업 → API 자동화 + 개정감지

법령·판례 파이프라인을 받았을 때 제일 먼저 보인 신호: 사람이 매번 PDF를 받아오고 있었다. 자동화의 가치가 가장 큰 지점이었습니다.

세 가지를 한 번에 풀었어요:

• Open API 어댑터: 사이트 다운로드 → API 호출. 인증/Rate limit/에러 처리/스키마 매핑까지 어댑터 레이어로 격리
• 개정감지 (Revision Detection): 해시·버전 기반 변경 비교 → 바뀐 조항만 골라 incremental embedding. 매번 전체 재인덱싱하지 않음
• 표준 인덱스로 통합: 기존 비표준 인덱스를 다른 RAG 코퍼스(KMS, 펀드/ELS)와 동일한 스키마로 정렬 → 검색 레이어가 단일 경로로 동작

RDS PostgreSQL 기반 파이프라인 State 관리

법령·판례처럼 주기적·다단계 파이프라인은 어디까지 처리됐는지가 곧 운영의 본질입니다. 단순 로그가 아니라 재실행 가능한 state가 필요했어요.

RDS PostgreSQL 스키마를 직접 설계해 각 데이터 항목의 라이프사이클을 단계별로 추적:

단계	추적 항목
개정감지	변경/신규/삭제 플래그, 이전/현재 해시, 감지 시각
데이터 수집	Open API fetch 성공·실패, 응답 메타
파싱	PDF/HTML 파싱 결과, 실패 사유
청킹	청크 개수, 분할 전략 메타
임베딩 적재	OpenSearch 적재 상태, 청크별 doc_id

운영 효과:

• 장애 후 어느 단계부터 재실행할지 즉시 파악
• 단계별 처리 시간·실패율을 지표화 → 병목 가시화
• 재실행 안전성 — 같은 항목을 여러 번 처리해도 idempotent

What's Next

현재 진행 중. 앞으로의 방향은:

• 법무검토 에이전트 파이프라인 안정화 — 현재 개발 중인 법령·판례 자동화 파이프라인의 운영 단계 진입
• 개정감지 → 다른 코퍼스로 확장 — 펀드/ELS 약관에도 동일한 incremental update 패턴 적용 (지금은 전체 재처리)
• 평가 파이프라인 정착 — 펀드/ELS·법령 응답의 정확도를 도메인 전문가가 검수하는 사이클을 자동화 데이터셋과 결합 (NeuroCore에서 배운 LLM-as-Judge 하이브리드 패턴 적용 가능)
• 컴플라이언스 추적 — RAG 응답에 어떤 문서의 어떤 청크가 인용됐는지 감사 추적 강화

Role

페르소나에이아이 소속 프리랜서로 KB증권에 파견. 데이터팀 대리로 RAG 데이터 파이프라인의 운영 + 고도화를 담당. 이미 배포된 시스템을 깨뜨리지 않으면서 성능과 안정성을 끌어올리는 게 본질.

"안 돌고 있는 시스템을 만드는 것보다, 돌고 있는 시스템을 더 잘 돌게 만드는 것이 어려울 때가 있다."

Note

본 케이스 스터디는 NDA 범위 안에서 작성됨. 회사명·다루는 데이터 종류까지는 공개 가능하나 구체적인 아키텍처·정량 수치·코드 디테일은 비공개. 인터뷰 자리에서 적절한 범위 안에서 추가 공유 가능합니다.