본문으로 건너뛰기

"Decision Log" 태그 — 2개 게시물

의사결정 기록

모든 태그 보기

IBK캐피탈 AI 여신 승인신청서 자동화 시스템 구축기

· 약 3분
Brain Crew RAG Team
AI Research & Engineering

TL;DR

IBK캐피탈의 승인신청서 작성 소요시간을 3.5일에서 1일 이내로 약 70% 단축하고, 반복문서 자동화를 통해 연간 약 4.7억 원 절감 효과를 달성한 AI PoC 프로젝트입니다. 완전폐쇄망(On-Prem) 환경에서 RAG 파이프라인을 구축하며, Table-First 파싱 전략과 HeadingRefiner 기반 청킹으로 금융 문서의 수치 정확성 문제를 해결했습니다.

프로젝트 배경

승인신청서는 IBK캐피탈 영업점이 기업고객과 상담 후 작성하는 비정형 문서입니다. 사업보고서, 감사보고서, 재무제표 등 다양한 문서를 참조하여 9개 섹션을 채워야 하며, 작성과 검토에 많은 시간과 인력이 소요됩니다.

핵심 과제: 생성형 AI 기반 자동화를 통해 문서 작성 효율성과 정확성을 동시에 높이는 것. 특히 완전폐쇄망 환경이라는 제약이 있었습니다.

기술적 도전과 해결

1. 문서 전처리 파이프라인: Table-First 전략

금융 문서에서 가장 중요한 건 수치의 정확성입니다. 단순 PDF 텍스트 추출로는 표 데이터가 깨지는 문제가 있었습니다.

우리가 세운 3가지 원칙:

  • 정확한 수치 보존 — 재무제표의 숫자 하나가 틀리면 전체 신뢰도가 무너짐
  • 문서 내 의미 단락을 정확히 추출 — 섹션별로 올바른 컨텍스트를 전달해야 함
  • 근거 기반 의견 생성 — 출처가 명확한 답변이 필수

이를 위해 Table-First Approach를 채택했습니다:

  1. Table 문서를 우선 처리 — 표 구조가 수치 왜곡이 가장 적음
  2. 일반 PDF 텍스트는 fallback으로 보완
  3. OCR은 최후 수단으로만 사용

Parser & Chunker 아키텍처

전체 종합 처리 플로우는 다음과 같습니다:

종합 처리 플로우

2. HeadingRefiner: 의미 단락 분리의 핵심

청킹(Chunking) 품질은 heading 추출의 정확도에 직결됩니다. 이를 위해 HeadingRefiner 모듈을 설계했습니다:

  • 목차가 있는 문서: 목차 기반으로 계층 구조를 자동 구성 → LLM 호출 최소화
  • 목차가 없는 문서: LLM을 활용하여 heading 계층을 재구성

이 접근법으로 의미 단락을 더 정확하게 분리할 수 있었고, 최종적으로 의견 생성 품질이 크게 향상되었습니다.

3. 비동기 + 병렬처리로 소요시간 54% 단축

초기 파이프라인은 문서 하나를 처리하는 데 12분 41초가 걸렸습니다. 두 가지 최적화를 동시에 적용했습니다:

  • Heading 정제 및 메타데이터 생성 과정을 비동기 처리

비동기 처리 구조

  • 다중 Worker 기반 병렬 처리

병렬 처리 구조

결과: 12분 41초 → 5분 54초 (약 54% 단축)

4. RAG 파이프라인: Tabular 데이터의 정보 손실 최소화

전처리된 PDF에서 추출된 표 데이터는 형태가 가변적입니다. LLM이 이를 해석할 때 정보 손실을 최소화하기 위해, 컨텍스트로 활용되는 데이터 형태를 Markdown KV(Key-Value) 구조로 변환하여 적용했습니다.

Markdown KV 변환 예시

Prompt Engineering을 통해 승인신청서 내부 9개 Section에 대한 개별 응답을 생성하도록 최적화했습니다.

기술 스택

항목상세
Web ClientNext.js
Backend ServerFastAPI
DatabaseElasticsearch, Redis
환경On-Prem (완전폐쇄망)

성과

  • 작성 소요시간 약 70% 단축: 기존 3.5일 → 1일 이내
  • 자동작성으로 생산성 23%p 향상

생산성 향상 지표

  • 연간 약 4.7억 원 인건비 절감 효과

인건비 절감 효과

  • 내부 실무자 만족도 약 80% 달성
    • 정성점수: 79.41/100
    • 평균 만족도: 4/5

만족도 평가 결과

만족도 상세 결과

만족도 항목별 결과

회고

잘한 점

  • Table-First 전략: 금융 도메인의 핵심인 수치 정확성을 최우선으로 놓은 것이 프로젝트 성공의 열쇠였습니다.
  • HeadingRefiner의 이중 전략: 목차 유무에 따라 분기하는 설계가 다양한 문서 유형에 대한 범용성을 확보해줬습니다.
  • On-Prem 환경 대응: 클라우드 서비스 의존 없이 완전폐쇄망에서 동작하는 아키텍처를 구축한 경험은 향후 프로젝트에도 큰 자산이 됩니다.

배운 점

  • 금융 문서에서 LLM의 역할은 "생성"보다 "정확한 정보 추출과 구조화"에 더 가깝습니다. Prompt Engineering의 방향도 이에 맞춰야 합니다.
  • 비동기/병렬 처리는 초기부터 설계에 반영해야 합니다. 나중에 추가하면 아키텍처 변경 비용이 큽니다.
  • 실무자 피드백 기반의 정성 평가는 PoC 단계에서 본사업 전환을 위한 중요한 근거가 됩니다.

LG Electronics 라이프로그 AI 어시스턴트 구축기: 그래프 검색으로 일상을 탐색하다

· 약 3분
Brain Crew RAG Team
AI Research & Engineering

TL;DR

L사 고객의 라이프로그 데이터를 기반으로, "저번주에 커피 몇 번 마셨더라?" 같은 일상적 질문에 정확히 답변하는 AI 어시스턴트를 구축했습니다. 벡터 검색 + 그래프 탐색의 하이브리드 구조로 Context를 20,000개에서 3,000개로 85% 감소시키면서도, 사용자 요구사항 기반 평가셋에서 92%(74/80개) 정확도를 달성했습니다.

프로젝트 배경

사용자가 "캠핑 갔을 때 쓴 버너 뭐였지?"라고 물으면, AI가 복잡한 활동 기록을 연결해서 정확한 답을 찾아줘야 합니다.

단순 키워드 검색으로는 불가능합니다. 시간·장소·활동·브랜드·음식·상황 사이의 복잡한 연결 구조를 AI가 스스로 이해하고 탐색할 수 있어야 합니다.

핵심 과제 4가지:

  1. 데이터 양이 많아져도 느려지지 않는 검색
  2. 구어체·줄임말·외래어도 정확히 이해
  3. 통계/패턴 관련 질문에도 정확히 답변
  4. Context 최적화로 효율성과 일관성 동시 달성

기술적 도전과 해결

1. 그래프 기반 검색: 맥락 단위로 찾는 능력

"캠핑에서 썼던 버너 브랜드"라는 질문을 분해하면:

  • 활동: 캠핑 → 장소: 캠핑장 → 행동: 요리 → 물건: 버너 → 브랜드: ?

전통적인 벡터 검색만으로는 이 관계 추론이 불가능합니다. 우리는 모든 활동 데이터를 그래프 형태로 재구성했습니다:

  • 14개 메타데이터 키: 시간, 위치, 활동, 소비, 개체명 등
  • 242개 엣지: 메타데이터 간 연결 관계
  • 에이전트가 질문을 분석해 어떤 경로를 따라 탐색해야 하는지 스스로 결정

2. 하이브리드 검색 + 자동 시간 필터링

수천~수만 건의 활동 데이터에서 매번 전체 스캔은 비효율적입니다. 벡터 검색(ChromaDB)과 그래프 탐색을 결합한 하이브리드 구조를 설계했습니다.

특히 자연어 시간 표현 자동 해석이 핵심이었습니다:

  • "지난주" → 날짜 범위 자동 계산
  • "올해 초" → 1~3월 필터
  • "저녁에" → 시간대 필터

LLM이 이런 표현을 해석하여 검색 범위를 자동으로 좁혀줍니다.

3. Context 최적화: 85% 감소, 성능은 유지

초기에는 검색 결과로 20,000개의 Context를 LLM에 전달하고 있었습니다. 비용도 높고, 오히려 불필요한 정보가 답변 품질을 떨어뜨리는 문제가 있었습니다.

그래프 탐색을 통해 관련성 높은 Context만 선별하여 3,000개로 85% 감소시켰고, 오히려 답변 일관성이 향상되었습니다. 적은 정보를 정확히 주는 것이 많은 정보를 던지는 것보다 낫다는 교훈을 얻었습니다.

4. 한국어 자연어 처리 최적화

한국어의 다양한 표현 방식이 검색 정확도의 병목이었습니다:

  • 스벅 / 스타벅스 / Starbucks
  • 넷플 / 넷플릭스
  • 베라 / 베스킨라빈스

이를 해결하기 위해:

  • 도메인 특화 동의어·줄임말 사전 구축
  • LLM 기반 질의 정규화 (사용자 표현 → 데이터 표현 자동 변환)
  • Query Expansion으로 의미 단위 검색 확장

아키텍처

사용자 질문

에이전트 (LangGraph ReAct)
├── Tool 호출 필요 여부 판단
├── query_extraction (활동·시간 관련 내용 추출)
├── GraphRetriever
│ ├── 벡터 검색 (ChromaDB)
│ └── 그래프 탐색 (메타데이터 엣지)
└── 검색 결과 종합

최종 답변 반환

기술 스택:

  • 에이전트: LangGraph ReAct Agent
  • 벡터 저장소: ChromaDB
  • 검색: 벡터 검색 + 그래프 탐색 하이브리드
  • 프론트엔드: LangGraph Studio 연동

서비스 화면

메인 페이지 - 챗 오프너 및 대화 입력창

사이드바 - 이전 대화 내역 불러오기

대화 페이지 - 검색 결과 및 AI 응답 표시

성과

  • 정확도 92%: 사용자 요구사항 기반 평가셋 80개 중 74개 정답
  • Context 85% 감소: 20,000개 → 3,000개
  • 복합 질의 검색 가능: "캠핑에서 사용한 버너 브랜드" 같은 관계 추론
  • 맥락 의존적 검색: 단순 유사도 기반 검색 대비 품질 향상

회고

잘한 점

  • 그래프 구조 도입 결정: 초기에 "벡터 검색만으로 충분하지 않을까?"라는 의견이 있었지만, 복합 질의 테스트 결과를 근거로 그래프 도입을 결정한 것이 프로젝트 성공의 핵심이었습니다.
  • Context 최적화: "더 많은 정보 = 더 좋은 답변"이라는 직관을 데이터로 반증하고, 과감하게 85% 줄인 결정이 옳았습니다.
  • 평가셋 기반 개발: 사용자 요구사항에서 직접 평가셋을 만들어 개발 방향을 잡은 것이 효과적이었습니다.

배운 점

  • 라이프로그 데이터는 "관계"가 핵심입니다. 개별 이벤트의 유사도보다 이벤트 간 연결 구조가 검색 품질을 결정합니다.
  • 한국어 NLP는 여전히 도전적입니다. 줄임말/외래어 처리는 사전 구축만으로는 한계가 있으며, LLM 기반 정규화가 필수적입니다.
  • Context 양과 답변 품질은 비례하지 않습니다. 노이즈 제거가 곧 성능 향상입니다.