들어가며

AI를 기업 현장에 도입한다는 말은 생각보다 훨씬 구체적인 의미를 담고 있습니다. 

수십 년간 쌓아온 문서들을 AI가 읽을 수 있는 형태로 바꾸고, 외부와 단절된 폐쇄망 안에서 시스템을 연결하고, 실무자들이 실제로 쓸 수 있는 경험을 설계하는 일련의 과정. 그 자체인데요. 여기서 마주치는 문제들은 보통 AI 기술을 소개하는 백서에서도 충분히 다루지 않는 것들입니다.

특히 금융권은 그 어려움이 배가됩니다. 폐쇄망이라는 구조적 제약 안에서 AI를 구축하려 하면, 기술적 난관은 예상보다 훨씬 깊고 넓기 때문인데요. 다만 이 프로젝트를 들여다보면, 기술보다 먼저 결정되어야 할 것이 있었다는 사실도 함께 드러납니다. 보수적인 금융 환경에서 클라우드 기반 AI 도입을 밀어붙인 경영진의 판단, 그리고 그 판단이 내려진 시점이 이 프로젝트의 실질적인 출발점이었습니다.

이 글은 국내 한 대형 증권사(이하 A 증권사)에 RAG(Retrieval-Augmented Generation) 기반 AI 에이전트를 구축하면서 스켈터랩스 팀이 직면한 문제들과 그 해결 과정을 기록한 것입니다. 문서 전처리와 데이터 파이프라인, 검색 아키텍처의 구조적 전환, 금융권 보안 요건 대응, 그리고 실무자 중심 UX 설계까지, 네 개의 축을 중심으로 이 프로젝트의 실체를 최대한 구체적으로 설명합니다. 

‍

1장. 문서를 읽힌다는 것: 전처리 파이프라인의 현실

🔘 1-1. 읽을 수 있는 문서가 없었습니다!

AI가 사내 문서를 기반으로 질문에 답하려면, 먼저 그 문서를 이해해야 합니다. 그런데 이해하기 이전에, AI가 문서를 읽을 수 있는 상태로 만드는 것 자체가 이번 프로젝트에서 가장 많은 시간을 잡아먹은 작업이었습니다.

A 증권사의 사내 문서 시스템은 그룹웨어와 준법경영 시스템, 두 개의 큰 축으로 구성되어 있었습니다. 그 안에 총 39개의 게시판이 존재했고, 규정, 업무 매뉴얼, 컴플라이언스 자료, 애널리스트 리포트, 교육 자료실 등 성격이 완전히 다른 문서들이 수만 건씩 올라와 있었는데요. 파일 형식만 해도 HWP, PPTX, PDF, DOCX, XLS/XLSX 다양했고, JPG, GIF, MP4, ZIP까지 섞여 있었어요. 파일 하나의 용량이 엄청난 경우가 있었습니다.

이 모든 파일을 AI가 검색할 수 있는 텍스트 데이터로 바꾸는 작업이 바로 전처리입니다. 비교하자면, 마치 도서관 서가에 꽂힌 책들을 전부 색인 카드로 만드는 작업과 비슷합니다. 그런데 이 책들이 어떤 건 한글 필기체로, 어떤 건 그림 위에 글자를 적어놓은 형태고, 어떤 건 아예 이미지 파일이었던 셈입니다.

🔘 1-2. HWP: 가장 예상치 못한 복병

그중에서도 가장 큰 골칫거리는 HWP(한글) 파일이었습니다. 한글과컴퓨터가 만든 독자 포맷으로, 국내 공공기관과 금융권에서는 오랫동안 표준처럼 사용되어 왔는데요. 문제는 이 형식을 텍스트로 변환해주는 오픈소스 도구가 사실상 존재하지 않는다는 점입니다. 해외 기반의 AI 생태계에서 HWP는 그야말로 사각지대에 있습니다.

스켈터랩스는 이를 해결하기 위해 파서를 활용했습니다. 클라우드(SaaS) 환경에서는 일정 페이지 이상의 파일도 문제없이 처리됐는데요. 그런데 A 증권사는 금융권 보안 규정상 외부 인터넷을 쓸 수 없는 폐쇄망 환경이었기 때문에, 클라우드 버전을 쓸 수가 없었습니다. AWS 위에서 구동되는 온프레미스 버전을 써야 했는데, 이 버전에는 두 가지 치명적인 제약이 있었어요.

첫째, 일정 페이지를 초과하는 파일은 파싱을 아예 거부했습니다. 둘째, AWS 의 기본 연결 제한 시간이 짧게 설정되어 있어서, 처리 시간이 넘는 파일은 타임아웃으로 강제 종료됐습니다. 분량이 많은 업무 매뉴얼이나 규정 문서들은 대부분 이 두 가지 제약에 걸렸어요.

해서, 일정 페이지를 초과하는 HWP 파일은 먼저 오픈소스 도구를 이용해 PDF로 변환하고, 이를 다시 단위로 분할한 다음 파싱하는 방식을 적용했습니다. 그런데 이마저도 안 되는 파일들은 결국 엔지니어가 직접 PDF로 변환해서 수동으로 적재할 수밖에 없었어요. AI를 도입하기 위해 사람이 파일을 한 장 한 장 손으로 처리(최첨단 수동…ㅎㅎ)해야 했다는 사실은, AI 도입의 현실을 단적으로 보여줍니다.

🔘 1-3. PPT와 이미지: 텍스트가 없는 문서들

PPTX 파일은 또 다른 복병이었습니다. 프레젠테이션 파일에는 텍스트 외에도 플로우차트, 도형 객체, 조직도, 화살표 다이어그램처럼 시각적으로 정보를 표현하는 요소들이 많습니다. 이런 요소들은 어떤 파서로도 의미 있는 텍스트를 추출할 수 없었습니다.

스켈터랩스는 VLM(Vision Language Model)로 문제를 해결했습니다. VLM이란 이미지를 이해하는 AI 모델인데요. PPT 슬라이드 전체를 이미지로 변환한 뒤, AI에게 이 화면에 무엇이 있는지 설명해줘라고 요청해서 텍스트 설명을 생성하는 방식입니다. 예를 들어 영업팀 보고서에 플로우차트가 있다면, VLM은 고객 접촉 → 상품 안내 → 계약 체결 → 사후 관리와 같이 구조를 텍스트로 서술해 줍니다. 이 텍스트가 이후 RAG 검색의 대상이 되는 거예요.

PDF 파일도 단순하지 않았습니다. PDF는 파일 형식만 봐서는 그 안에 텍스트 중심의 내용이 담겨 있는지, 슬라이드 형식인지, 스캔 이미지인지를 알 수 없거든요. 그래서 스켈터랩스는 PDF에 대해 2단계 전처리를 적용했습니다. 먼저 Parser로 1차 파싱을 수행하고, 파싱 결과에 이미지나 도식이 포함된 요소가 확인되면 VLM으로 후처리를 추가하는 구조입니다. 문서 유형에 따라 도구를 다르게 적용하고, 경우에 따라 두 가지를 겹쳐 사용하는 이 다층적 전처리 파이프라인은 이번 프로젝트에서 공수가 가장 많이 투입된 영역이었습니다.

🔘 1-4. 역설: LLM이 너무 빠르면 안 되는 상황!?

전처리 과정에서 Claude 모델을 광범위하게 활용하면서 예상치 못한 문제가 생겼습니다. 이미지 캡셔닝, 표 안에 기호로 표시된 정보를 주변 문맥을 참고해서 텍스트로 보정하는 작업, 문서 품질 정제 등 LLM이 투입되는 작업이 늘어나자, API 호출 횟수 제한(Rate Limit)에 반복적으로 걸리기 시작한 거예요.

예를 들어, ▲▼■● 같은 기호가 표에 가득한 문서를 AI에게 넘기면 주변 문맥을 읽고 전분기 대비 상승, 목표치 미달 같은 의미 있는 텍스트로 바꿔줘야 하는데요. 이런 작업을 수천 건의 문서에 동시에 돌리다 보니, 초당 API 호출 한도를 넘어서는 상황이 반복됐습니다. 역설적으로 LLM이 너무 빠르게 작동하면 안 되는 상황이 생긴 거예요.

스켈터랩스는 코드 내부에 인위적인 속도 제한 로직을 직접 작성했고, 적절한 호출 간격 값을 실험을 통해 튜닝하는 데 상당한 시간을 쏟았습니다. 전처리 파이프라인은 단순히 파일을 변환하는 도구가 아니라, 수많은 예외 케이스와 제약 조건 속에서 정교하게 조율된 시스템이었습니다.

‍

2장. 검색의 정확도와 속도를 동시에: Reranker 도입과 RAG 아키텍처의 전환

🔘 2-1. RAG가 뭔지부터 짚고 넘어가겠습니다

RAG는 Retrieval-Augmented Generation의 약자로, 쉽게 말하면 찾아서 읽고 답하는 방식의 AI입니다. AI 모델이 이미 학습한 일반 지식만으로 답하는 것이 아니라, 실제 회사 내부 문서를 실시간으로 검색해서 그것을 근거로 답변을 생성하는 거예요.

택배 회사로 비유하면 이렇습니다. AI는 창고 직원인데요. 고객이 작년 3월에 들어온 파란 박스 어디 있어요?라고 물으면, 창고 전체를 뒤져서 가장 관련 있는 박스를 찾아 내용을 읽고, 그것을 바탕으로 답변하는 방식입니다. 창고에 있는 문서의 양이 많을수록, 검색이 정확할수록 더 좋은 답을 줄 수 있어요.

🔘 2-2. 기존 구조의 한계: 속도와 정확도의 트레이드오프

스켈터랩스의 기존 RAG 검색 파이프라인은 두 단계로 구성되어 있었습니다.

‍

🔘 2-3. Reranker 도입: 구조 자체를 바꾸다

A 증권사 프로젝트에서 스켈터랩스는 기존 두 단계 사이에 Reranker 모델을 삽입하는 방식으로 이 딜레마를 해결했습니다. 새로운 파이프라인은 다음과 같습니다.
‍

• 1단계 Retrieval: 문서 후보를 가져옵니다.
• 1.5단계 Reranker: 문서 후보를 질문과의 관련성 점수로 재평가해서 순위를 다시 매깁니다.
• 2단계 Context-selection: 생략. Reranker가 그 역할을 대신합니다.

Reranker가 LLM보다 빠른 이유는 모델의 구조적 차이에 있습니다. LLM은 디코더(Decoder) 기반 모델입니다. 문장을 생성할 때 앞 토큰의 결과가 나와야 다음 토큰을 계산할 수 있는 순차적 구조예요. 반면 Reranker는 인코더(Encoder) 기반 모델로, 입력된 모든 토큰을 동시에 병렬로 처리할 수 있습니다. 파라미터 수도 LLM에 비해 훨씬 작고요. 서울 전체 교통 상황을 한 명이 골목골목 걷아다니며 파악하던 것을, 위성 사진으로 한 번에 내려다보는 것으로 바꾼 셈입니다.

🔘 2-4. 형태적 매칭의 함정

Reranker 도입이 중요한 이유는 속도만이 아닙니다. 기존 벡터 기반 검색에는 구조적인 취약점이 있었거든요. 의미는 통하는데 형태가 달라서 관련 없는 문서가 더 높은 유사도를 받는 경우가 생기는 거예요.

예를 들어볼게요. 사용자가 한글은 누가 만들었어?라고 물었을 때, DB에 두 개의 문서가 있다고 가정합시다. 하나는 한글로 만든 모던 타이포, 다른 하나는 세종대왕이 한글을 창제하셨다… 입니다. 형태적 매칭만으로 보면 첫 번째 문서가 한글과 만들다를 모두 포함해서 더 높은 점수를 받을 수 있어요. 하지만 실제 질문의 의도에 부합하는 문서는 두 번째입니다. Reranker는 이러한 의미론적 맥락을 다시 평가해서 적절한 문서를 상위로 끌어올립니다.

A 증권사에서도 유사한 사례가 있었는데요. 직원이 줄여서 입력한 질문이 정답이 아닌 엉뚱한 문서와 매칭될 가능성이 있었습니다. 이런 기업 고유의 약어와 내부 용어를 AI가 정확히 처리하는 것이 얼마나 중요한지, 그리고 얼마나 까다로운 문제인지를 잘 보여주는 사례입니다.

‍

‍

2편에 계속됩니다!

‍

‍