Braincrew

Where AI really happens — 기술의 본질을 탐구하고, 실제 프로덕트로 만듭니다.

Braincrew의 엔지니어링·리서치·프로덕트·컬처 이야기를 이곳에 기록합니다.

TL;DR​

금융권 여신 업무에서 반복적으로 작성되는 승인신청서와 심사보고서 초안을 생성형 AI로 보조하는 RAG 기반 PoC를 구축했습니다. 금융 문서의 수치·근거 정확성을 유지하면서도 실무자가 검토 가능한 형태로 문서 초안을 생성하는 데 초점을 맞췄습니다.

프로젝트 개요​

여신 승인신청서와 심사보고서는 다양한 자료를 참고해 작성되는 복합 문서입니다. 사업보고서, 감사보고서, 재무제표, 내부 기준 문서 등 여러 출처를 확인해야 하며, 작성자는 수치와 근거를 놓치지 않으면서 정해진 형식에 맞춰 문서를 구성해야 합니다.

Braincrew는 이 업무를 생성형 AI로 완전히 대체하기보다, 실무자가 검토할 수 있는 초안을 빠르게 만들고 관련 근거를 함께 확인할 수 있는 RAG 기반 업무 보조 시스템을 PoC 형태로 구축했습니다.

주요 수행 내용​

1. 금융 문서 기반 RAG 파이프라인 구축​

금융 문서 자동화에서 가장 중요한 것은 “그럴듯한 문장”이 아니라 “근거가 있는 문장”입니다. 특히 수치, 표, 기준 문구가 많은 문서에서는 원문 근거와 생성 결과가 연결되어야 합니다.

이를 위해 문서 수집, 파싱, 청킹, 검색, 응답 생성을 하나의 파이프라인으로 구성했습니다.

업무 문서 입력
  → 문서 파싱 및 구조화
  → 검색 가능한 단위로 분할
  → 질의 / 섹션별 관련 근거 검색
  → 승인신청서·심사보고서 초안 생성
  → 실무자 검토

2. 표와 수치 정보 보존을 우선한 전처리​

금융 문서에는 표 형태의 정보가 많고, 숫자 하나의 오류가 전체 문서의 신뢰도에 영향을 줄 수 있습니다. 따라서 일반 텍스트 추출만으로 처리하기보다, 표와 수치 정보를 최대한 보존하는 방향으로 전처리 전략을 설계했습니다.

주요 고려사항은 다음과 같습니다.

• 표 구조가 문맥에서 분리되지 않도록 처리
• 수치와 항목명이 함께 검색될 수 있도록 구조화
• 섹션별 근거를 추적할 수 있는 형태로 메타데이터 관리
• 생성 결과에 사용된 근거를 실무자가 확인할 수 있도록 구성

3. 금융 도메인에 맞춘 문서 생성 로직​

승인신청서 작성은 단순 요약과 다릅니다. 정해진 문서 구조가 있고, 섹션마다 요구되는 관점이 다르며, 원문 자료를 바탕으로 판단 근거가 드러나야 합니다.

PoC에서는 문서 섹션별로 필요한 근거를 검색하고, 각 섹션의 작성 목적에 맞게 초안을 생성하는 구조를 적용했습니다. 또한 생성된 문장이 근거와 분리되지 않도록 검색 결과와 응답 생성 흐름을 함께 설계했습니다.

4. 엔터프라이즈 환경을 고려한 시스템 구성​

금융권 프로젝트에서는 기능 구현만큼 운영 환경과 보안 요구사항이 중요합니다. 외부 서비스 연동, 접근 권한, 문서 보관 방식, 배포 환경 제약 등을 고려해 엔터프라이즈 환경에 맞는 구조로 PoC를 설계했습니다.

구체적인 내부 보안 구성과 운영 세부 사항은 공개하지 않지만, 제한된 환경에서도 RAG 기반 문서 자동화가 동작할 수 있도록 백엔드, 검색 파이프라인, 문서 처리 모듈을 분리해 구성했습니다.

기술 스택​

• LangGraph / LangChain
• RAG Pipeline
• LLM API
• FastAPI
• Docker
• 문서 파싱 및 구조화 파이프라인

보안 및 공개 범위​

본 글은 공개 가능한 수준의 문제 정의와 접근 방식만 정리했습니다. 실제 고객사 내부 문서 구조, 업무 기준, 평가 결과, 비용 효과, 화면 이미지, 운영망 구성, 상세 성능 수치는 포함하지 않았습니다.

배운 점​

금융 문서 자동화에서 LLM의 역할은 단순 생성기가 아니라, 근거 기반 문서 작성 보조자에 가깝습니다. 실무자가 신뢰할 수 있으려면 생성 결과보다 먼저 원문 근거, 수치 보존, 검토 흐름이 설계되어야 합니다.

또한 PoC 단계에서는 자동화율 자체보다 “실무자가 어디까지 믿고 검토할 수 있는가”가 중요합니다. AI가 초안을 만들고, 사람은 근거를 확인하며 최종 판단하는 구조가 엔터프라이즈 문서 자동화의 현실적인 출발점입니다.

TL;DR​

일상 활동 데이터를 기반으로 사용자의 맥락을 이해하고 자연어 질문에 답변하는 개인화 AI Agent PoC를 구축했습니다. 단순 키워드 검색이 아니라, 시간·장소·활동·개체 사이의 관계를 함께 활용하는 그래프 기반 하이브리드 검색 구조를 설계해 라이프로그 데이터 탐색 경험을 고도화했습니다.

프로젝트 개요​

라이프로그 데이터는 단순한 문서 검색과 다릅니다. 사용자의 하루, 장소, 활동, 소비, 대화, 기록이 시간 순서대로 쌓이고, 질문은 대부분 그중 일부 관계를 추론해야 답할 수 있는 형태로 들어옵니다.

예를 들어 사용자는 특정 날짜나 활동명을 정확히 기억하지 못한 채 “지난번 외출했을 때 들렀던 곳”, “캠핑 때 사용한 물건”, “최근 반복된 생활 패턴”처럼 맥락 중심으로 질문할 수 있습니다. 이런 질문에 대응하려면 개별 이벤트의 유사도만 보는 검색으로는 한계가 있습니다.

Braincrew는 이 문제를 해결하기 위해 라이프로그 데이터를 Agent가 탐색 가능한 구조로 재구성하고, 자연어 질문을 기반으로 관련 맥락을 찾아 답변하는 AI Agent PoC를 개발했습니다.

주요 수행 내용​

1. 라이프로그 데이터 구조화​

라이프로그 원천 데이터는 시간, 장소, 활동, 개체, 상황 정보가 복합적으로 섞여 있습니다. 이를 Agent가 활용할 수 있도록 검색 가능한 단위로 정리하고, 각 정보 간의 관계를 표현할 수 있는 구조를 설계했습니다.

중점은 원본 데이터를 그대로 나열하는 것이 아니라, 질문에 필요한 맥락을 빠르게 찾을 수 있도록 의미 단위와 연결 관계를 함께 보존하는 것이었습니다.

2. 그래프 기반 하이브리드 검색 설계​

라이프로그 질의는 대체로 “무엇과 무엇이 연결되어 있었는가”를 묻습니다. 따라서 벡터 검색만으로는 부족하고, 이벤트 사이의 관계를 함께 탐색할 수 있어야 합니다.

이를 위해 다음 요소를 결합했습니다.

• 자연어 질의 기반 후보 검색
• 시간·장소·활동 등 메타데이터 필터링
• 이벤트 간 관계를 활용한 그래프 탐색
• 검색 결과를 Agent 응답에 적합한 컨텍스트로 정리하는 후처리

이 구조를 통해 단순히 비슷한 문장을 찾는 수준을 넘어, 사용자의 질문 의도에 맞는 관련 활동과 주변 맥락을 함께 찾을 수 있게 했습니다.

3. 개인화 응답을 위한 Agent 파이프라인 구현​

사용자 질문은 정형화되어 있지 않습니다. “지난주”, “저녁에”, “그때”, “자주 갔던 곳”처럼 상대적이고 모호한 표현이 자주 등장합니다.

Agent 파이프라인은 이런 자연어 표현을 해석하고, 필요한 검색 조건을 구성한 뒤, 검색 결과를 종합해 답변하도록 설계했습니다.

핵심 흐름은 다음과 같습니다.

사용자 질문
  → 질문 의도와 조건 추출
  → 라이프로그 검색 / 관계 탐색
  → 관련 맥락 정리
  → 최종 답변 생성

4. 검색·응답 품질 최적화​

라이프로그 데이터에서는 “많이 찾는 것”보다 “질문에 필요한 맥락만 정확히 찾는 것”이 중요합니다. 불필요한 기록이 많이 들어가면 답변이 길어지고, 오히려 사용자가 기대한 맥락에서 벗어날 수 있습니다.

따라서 검색 결과를 그대로 LLM에 전달하지 않고, 질문과의 관련도, 시간 범위, 연결 관계를 기준으로 컨텍스트를 압축·정리하는 과정을 두었습니다. 이를 통해 응답의 일관성과 사용자 경험을 개선했습니다.

기술 스택​

• AI Agent / LangGraph
• Hybrid Search
• Graph 기반 맥락 탐색
• Python / FastAPI
• LLM API

보안 및 공개 범위​

본 글은 공개 가능한 수준의 아키텍처와 접근 방식만 정리했습니다. 실제 프로젝트의 원천 데이터 구조, 평가셋, 상세 성능 수치, 내부 화면, 운영 환경 세부 정보는 포함하지 않았습니다.

배운 점​

라이프로그 기반 AI Agent에서 중요한 것은 모델 성능만이 아닙니다. 사용자의 활동 기록을 어떤 단위로 나누고, 어떤 관계로 연결하며, 질문에 필요한 맥락만 어떻게 선별할지가 전체 경험을 좌우합니다.

특히 개인화 AI에서는 검색 결과의 양보다 맥락의 정확도가 더 중요합니다. Agent가 잘 답하게 하려면, Agent에게 필요한 작업 공간과 검색 구조를 먼저 잘 만들어야 합니다.