모델은 준비됐다. 그런데 그 모델이 올라갈 환경이 없었다.
생성형 AI를 도입하려는 기업은 많지만, 실제로 프로덕션까지 도달하는 경우는 드뭅니다. 대부분의 병목은 AI 모델에서 발생하지 않습니다. 모델은 API 하나로 호출할 수 있는 시대가 됐으니까요. 진짜 문제는 그 모델이 올라갈 인프라, 모델이 참조할 데이터, 그리고 이 전체를 안정적으로 운영하는 체계입니다.
국내 증권사 H사는 사내에 축적된 방대한 문서와 자료를 빠르게 검색하고, 요약·추론해주는 AI 챗봇 서비스를 기획했습니다. 그런데 H사는 AWS를 처음 도입하는 고객이었고, 서비스를 올릴 클라우드 인프라 환경이 아직 구성되어 있지 않은 상태였습니다. AI 솔루션은 구상이 끝났지만, 그것을 실제로 동작시킬 기반이 없었던 겁니다.
여기에 금융권 특유의 제약이 더해졌습니다. 혁신금융 규제 샌드박스 안에서 운영해야 했기 때문에, 보안 요건은 일반 서비스보다 훨씬 엄격했습니다. 39개 게시판에 흩어진 수만 건의 사내 문서는 HWP, PPT, PDF, XLS 등 형식도 천차만별이었고, AI가 읽을 수 있는 상태와는 거리가 먼 것들이 대부분이었습니다.
이 글은 메타넷엑스가 H 증권사 AI 에이전트 프로젝트를 수행하면서 마주한 문제들과 그 해결 과정을 기록한 것입니다. 클라우드 인프라 구축부터 AI 솔루션 구현, 보안 규제 대응, 그리고 현업이 실제로 쓸 수 있는 UX 설계까지. AI 프로젝트의 성패를 가르는 "모델 아래의 모든 것"에 대한 이야기입니다.
인프라와 AI, 하나의 의사결정 체계 안에서 움직이다
이 프로젝트의 구조는 처음부터 달랐습니다. 글로벌 컨설팅펌이 전략 수립을 맡고, 메타넷엑스가 AI 솔루션과 클라우드 인프라를 함께 담당하는 협업 구조로 시작됐습니다. 여기서 "함께 담당"이라는 표현이 핵심입니다. 메타넷엑스는 클라우드 구축·운영 역량을 가진 인프라 조직과, 자체 개발 LLM 플랫폼을 보유한 AI 자회사 스켈터랩스가 하나의 그룹 안에 있습니다. 이 프로젝트에서 그 구조가 그대로 작동했습니다.
AI 솔루션 측이 필요로 하는 환경을 인프라 조직이 즉시 설계하고, 양쪽의 요구사항을 하나의 의사결정 체계 안에서 조율하며 실행했습니다. 외부 AI 벤더와 별도의 클라우드 파트너가 각각 다른 방향으로 프로젝트를 끌어가는 구조가 아니라, 인프라 설계 단계부터 AI 솔루션의 요구사항이 반영되고, AI 아키텍처 결정이 인프라 제약을 실시간으로 고려하는 구조였습니다.
기술적으로는 EKS 기반 컨테이너 환경 위에 AI 솔루션을 Pod 형태로 배포하는 구조로 설계됐습니다. 메타넷엑스의 자체 LLM 플랫폼이 서비스의 중심축을 담당하면서, 문서 전처리부터 검색, 답변 생성까지의 전 과정에서는 AWS Bedrock 위의 Claude를 유연하게 조합하는 하이브리드 구조를 택했습니다. 자체 기술로 핵심을 잡되, 필요에 따라 최적의 외부 서비스를 선택적으로 결합할 수 있다는 점이 이 구조의 강점이었습니다.
H사가 AWS 최초 도입 고객이었기 때문에, 단순히 인프라를 구성하는 것으로는 부족했습니다. 메타넷엑스는 프로젝트 전체의 추진 체계를 정리하고, R&R을 정의하고, WBS를 수립하는 것부터 시작했습니다. 고객의 기존 온프레미스 운영 체계를 먼저 파악한 뒤, 각 업무 담당자별로 클라우드 전환 시 무엇이 달라지는지를 현행 업무에 맞춰 설명하면서 도입의 전 과정을 리드했습니다. 클라우드가 처음인 조직이 실제로 이해하고 따라올 수 있는 속도와 방식으로 프로젝트를 설계한 것입니다.
AI가 읽을 수 있는 문서가 없었다: 전처리 파이프라인의 현실
인프라가 준비된 다음, AI 에이전트가 가장 먼저 해야 할 일은 사내 문서를 이해하는 것이었습니다. 그런데 이해하기 이전에, AI가 문서를 읽을 수 있는 상태로 만드는 것 자체가 이 프로젝트에서 가장 많은 시간을 잡아먹은 작업이었습니다.
H 증권사의 사내 문서 시스템은 그룹웨어와 준법경영 시스템 두 개의 축으로 구성되어 있었습니다. 그 안에 총 39개의 게시판이 존재했고, 규정, 업무 매뉴얼, 컴플라이언스 자료, 애널리스트 리포트, 교육 자료 등 성격이 완전히 다른 문서들이 수만 건씩 올라와 있었습니다. 파일 형식만 해도 HWP, PPTX, PDF, DOCX, XLS/XLSX에 이미지와 동영상까지 섞여 있었고요. 이 모든 파일을 AI가 검색할 수 있는 텍스트 데이터로 바꾸는 작업이 바로 전처리입니다.
가장 큰 골칫거리는 HWP 파일이었습니다. 국내 공공기관과 금융권에서 오랫동안 표준처럼 사용되어 온 형식이지만, 이 파일을 텍스트로 변환해주는 오픈소스 도구가 사실상 존재하지 않습니다. 해외 기반의 AI 생태계에서 HWP는 그야말로 사각지대에 놓여 있는 겁니다. 클라우드(SaaS) 환경에서는 파서를 활용해 처리할 수 있었지만, 금융권 보안 규정상 외부 인터넷을 사용할 수 없는 폐쇄망 환경에서는 온프레미스 버전을 써야 했습니다. 이 버전에는 페이지 초과 파일의 파싱 거부, 타임아웃에 의한 강제 종료라는 두 가지 치명적 제약이 있었습니다. 분량이 많은 업무 매뉴얼이나 규정 문서들은 대부분 이 제약에 걸렸습니다.
스켈터랩스 팀은 일정 페이지를 초과하는 HWP 파일을 먼저 PDF로 변환하고, 이를 다시 단위별로 분할한 다음 파싱하는 우회 방식을 적용했습니다. 그런데 이마저도 안 되는 파일들은 결국 엔지니어가 직접 수동으로 변환해서 적재할 수밖에 없었습니다. AI를 도입하기 위해 사람이 파일을 한 장 한 장 손으로 처리해야 했다는 사실은 AI 도입의 현실을 단적으로 보여줍니다.
PPT 파일도 만만치 않았습니다. 프레젠테이션에는 플로우차트, 도형 객체, 조직도처럼 시각적으로 정보를 표현하는 요소가 많은데, 어떤 파서로도 의미 있는 텍스트를 추출할 수 없었습니다. 스켈터랩스는 VLM(Vision Language Model)으로 이 문제를 해결했습니다. 슬라이드 전체를 이미지로 변환한 뒤, AI에게 "이 화면에 무엇이 있는지 설명해줘"라고 요청해서 텍스트 설명을 생성하는 방식입니다. PDF 역시 단순하지 않았습니다. 텍스트 중심인지, 슬라이드 형식인지, 스캔 이미지인지를 파일 형식만으로는 알 수 없기 때문에, 먼저 1차 파싱을 수행하고 이미지나 도식이 확인되면 VLM으로 후처리를 추가하는 2단계 전처리를 적용했습니다.
전처리 과정에서 Claude 모델을 광범위하게 활용하면서 예상치 못한 문제도 발생했습니다. 이미지 캡셔닝, 표 안의 기호를 문맥 기반으로 텍스트 보정하는 작업 등에 LLM이 투입되면서, API 호출 횟수 제한(Rate Limit)에 반복적으로 걸리기 시작한 겁니다. 역설적으로 LLM이 너무 빠르게 작동하면 안 되는 상황이 생긴 셈입니다. 인위적인 속도 제한 로직을 작성하고, 적절한 호출 간격 값을 실험을 통해 튜닝하는 데 상당한 시간을 쏟아야 했습니다.
검색 구조 자체를 바꾸다: Reranker 도입과 RAG 아키텍처의 전환
문서를 읽힐 수 있는 형태로 만든 다음 과제는 검색의 정확도와 속도를 동시에 확보하는 것이었습니다. RAG(Retrieval-Augmented Generation), 즉 "찾아서 읽고 답하는 방식"의 AI는 검색 품질이 곧 답변 품질을 결정합니다.
기존 RAG 파이프라인은 두 단계로 구성되어 있었습니다. 1단계에서 문서 후보를 넓게 가져오고, 2단계에서 LLM이 후보 문서를 하나하나 읽어가며 가장 적절한 내용을 골라내는 방식이었는데요. 문제는 2단계에서 LLM이 문서를 읽는 데 시간이 오래 걸린다는 점이었습니다. 정확도를 올리려면 더 많은 후보를 넘겨야 하고, 그러면 응답 속도가 느려지는 트레이드오프가 발생합니다.
이 프로젝트에서 스켈터랩스 팀은 기존 두 단계 사이에 Reranker 모델을 삽입하는 방식으로 이 딜레마를 해결했습니다. Reranker는 인코더(Encoder) 기반 모델로, 입력된 모든 토큰을 동시에 병렬 처리할 수 있습니다. LLM처럼 앞 토큰의 결과를 기다려야 하는 순차적 구조가 아닌 거죠. 서울 전체 교통 상황을 한 명이 골목골목 걸어 다니며 파악하던 것을, 위성 사진으로 한 번에 내려다보는 것으로 바꾼 셈입니다.
Reranker 도입이 중요한 이유는 속도만이 아니었습니다. 기존 벡터 기반 검색에는 의미는 통하는데 형태가 달라서 엉뚱한 문서가 더 높은 유사도를 받는 구조적 취약점이 있었습니다. 예를 들어 "한글은 누가 만들었어?"라고 물었을 때, "한글로 만든 모던 타이포"라는 문서가 "세종대왕이 한글을 창제하셨다"는 문서보다 형태적으로 더 높은 점수를 받을 수 있습니다. Reranker는 이런 의미론적 맥락을 다시 평가해서 적절한 문서를 상위로 끌어올립니다. H 증권사에서도 직원이 줄여서 입력한 질문이 엉뚱한 문서와 매칭될 가능성이 있었는데, 기업 고유의 약어와 내부 용어를 정확히 처리하는 것이 얼마나 까다로운 문제인지를 보여주는 사례였습니다.
기술은 보안 뒤에서 기다린다: 금융권 보안과 규제 대응
엔터프라이즈 AI 프로젝트에서 기술적 역량보다 먼저 결정되는 것이 있습니다. 보안 정책입니다. 특히 금융권에서는 이 원칙이 어떤 예외도 허용하지 않는 절대적 조건으로 작동합니다.
H 증권사 프로젝트는 금융당국의 혁신금융 규제 샌드박스 안에서 승인받아 운영된 서비스입니다. 그 결과, 실제로 사용할 수 있는 AI 모델의 선택지는 극도로 좁아졌습니다. 오픈소스 모델 생태계에서 성능으로 주목받는 상당수 중국 기반 모델은 보안 이슈로 전면 배제됐고, OpenAI GPT나 Google Gemini 같은 상용 모델도 외부망 API 호출이 불가능한 환경에서는 사용할 수 없었습니다. 결국 AWS 위에서 서빙되는 모델만 선택 가능했고, 문서 전처리부터 검색, 답변 생성까지 전 과정에 Claude를 사용하게 됐습니다.
제약 속에서 Claude의 성능은 기대 이상이었습니다. 검색 성능과 한국어 구사력이 뛰어났고, 1년 전만 해도 다소 어색했던 한국어 표현이 눈에 띄게 개선되어, 오히려 기업용 솔루션에 더 적합하다는 평가까지 나왔습니다.
보안 요건은 기능 단위까지 영향을 미쳤습니다. 요약 기능에는 허가된 문서 화이트리스트 제한이 적용돼, 직원이 아무 문서나 업로드하는 것이 아니라 보안상 허가된 문서만 처리할 수 있도록 했습니다. 업로드된 문서는 해시값 기반으로 등록 여부를 확인하고, 허가되지 않은 문서나 DRM이 걸린 문서는 안내 메시지와 함께 차단됩니다. 주민등록번호, 전화번호, 계좌번호 같은 개인식별정보(PII)가 노출되거나 기록에 남는 것도 차단했습니다.
혁신금융 규제 샌드박스가 요구한 것은 여기서 끝나지 않았습니다. 서비스 전체를 언제든 즉시 중단할 수 있는 킬스위치, 사용자별 일일 쿼리 횟수 제한, 특정 사용자 즉시 차단 기능이 필수 요건으로 지정됐습니다. LLM 모델 정보나 시스템 프롬프트, 토큰 사용량 같은 내부 정보가 사용자 질문에 대한 답변으로 노출되지 않도록 하는 보호 장치도 마지막 단계에서 추가됐습니다. 이 모든 보안·규제 요건을 충족하는 인프라 환경을 설계하고 구현하는 과정에서 메타넷엑스의 금융권 클라우드 구축 경험이 결정적인 역할을 했습니다.
대충 물어봐도 잘 답하는 시스템: UX 설계와 현업 적응
최종 제공된 AI 서비스는 두 개의 에이전트로 구성됩니다. 사내 문서를 기반으로 질문에 답하는 AI 질의응답 에이전트와, 문서를 요약하고 가공하는 AI 요약 에이전트가 나란히 탭 형태로 제공되는 구조입니다. 원래 요약 기능은 프로젝트 중반에 추가 요청된 것이어서 기존 에이전트에 통합하기 어려웠고, 별도 서버를 개발해 독립된 탭으로 추가하는 방식을 택했습니다. 이 탭 구조는 확장성 면에서도 장점이 있습니다. 새로운 에이전트가 추가될 때 기존 사용 방식에 변화 없이 새 탭만 붙이면 되니까요.
기업에 AI 에이전트를 도입할 때 가장 자주 나타나는 현상은 사용자들이 질문을 너무 짧고 불완전하게 입력한다는 것입니다. "ㅇㅇ 주식 상승요인을 요약해"라고 입력하지만, 내심 기대하는 것은 "수출 및 해외 시장 관련 사항 중심으로, 개조식으로, 금융지식이 없는 고객도 이해할 수 있도록 평이한 단어로 요약해"입니다. 이 간극은 꽤 큽니다.
스켈터랩스 팀은 H 증권사 직원들을 대상으로 간접 인터뷰를 진행해서, 요약 기능 사용 시 공통적으로 기대하는 결과물의 형태를 파악했습니다. 장황하지 않을 것, 리스트나 표 같은 구조화 포맷을 적극 활용할 것, 근거가 되는 수치 정보를 반드시 포함할 것, 데이터와 현상 사이의 인과관계가 드러날 것. 이 공통 기대치가 시스템 프롬프트에 녹아들면서, 사용자가 완결성 있는 질문을 입력하지 않아도 일정 수준 이상의 결과물이 보장되는 구조가 만들어졌습니다.
요약 에이전트 UI에 제공된 프리셋 프롬프트 카드도 주목할 만합니다. 가장 빈번하게 요약 대상이 되는 데일리 모닝 미팅 노트와 애널리스트 리포트에 최적화된 요약 요청 문구를 카드 형태로 미리 준비해두고, 클릭 한 번으로 입력창에 불러올 수 있게 한 기능입니다. 이 프롬프트는 임의로 만든 것이 아니라, 인터뷰에서 도출된 현업의 실제 기대치를 직접 반영한 것입니다. AI를 잘 다루는 직원이든 그렇지 않은 직원이든, 카드 한 번 클릭으로 전문적인 수준의 결과를 얻을 수 있습니다. 사용자 간 역량 차이를 평준화한다는 점에서 기업용 AI의 핵심 가치를 잘 보여주는 설계입니다.
UX 관점에서 가장 인상적인 기능은 문서 작성자 정보 링크입니다. AI가 답변을 생성할 때 출처 문서의 링크뿐 아니라, 해당 문서를 작성하고 사내 게시판에 올린 담당자의 이름, 소속 부서, 직원 프로필 페이지 링크까지 함께 제공합니다. 현업 인터뷰에서 "AI가 찾아준 답변이 실무와 다르거나 문서만으로 맥락이 부족할 때 담당자에게 확인해야 하는데, 그 사람을 찾는 데 시간이 너무 많이 걸린다"는 고충에서 출발한 기능입니다. AI가 지식 검색에서 멈추지 않고, 사람이 사람을 찾는 실무 흐름 전체를 지원하는 도구로 기능한다는 점에서 업무 통합형 AI의 방향성을 보여줍니다.
AI 도입이 DX의 촉진제가 되다: 성과와 성공 요인
프로젝트 전체를 돌아보면 반복적으로 등장하는 하나의 주제가 있습니다. AI 성능보다 AI가 작동할 수 있는 환경의 조건이 먼저라는 것입니다.
H 증권사의 경우, 게시판마다 DB 구조가 달랐고 외부에서 접근할 수 있는 API가 아예 없었습니다. 이번 프로젝트를 계기로 게시글 추출 API를 새로 만들었는데, AI 도입이 결과적으로 DX의 촉진제가 된 셈입니다. AI 챗봇을 위해 구성한 클라우드 환경 역시 이 하나의 서비스를 위한 인프라에 그치지 않습니다. 향후 다른 신규 서비스를 올리거나, 기존 온프레미스 서비스를 마이그레이션할 수 있는 기반이 됐습니다. 하나의 서비스를 위한 인프라가 아니라, 기업 전체의 클라우드 전환을 위한 토대가 만들어진 것입니다.
이 프로젝트가 성공할 수 있었던 요인을 정리하면 세 가지로 압축됩니다. 첫째, AI 솔루션과 클라우드 인프라 양쪽을 하나의 그룹이 통합적으로 관리하면서, 환경 구성부터 배포, 보안 적용까지 일관된 흐름으로 진행할 수 있었다는 점입니다. AI 자회사 스켈터랩스의 기술적 깊이와 메타넷엑스의 금융권 인프라 경험이 동일한 의사결정 체계 안에서 맞물렸기 때문에 가능한 실행력이었습니다.
둘째, 클라우드가 처음인 고객의 눈높이에 맞춰 도입 전 과정을 함께 설계한 점입니다. 각 담당자가 스스로 이해하고 운영할 수 있는 수준까지 리드한 것이 고객의 신뢰로 이어졌고, 이 경험을 바탕으로 메타넷엑스는 H사의 통합 MSP로 선정됐습니다.
셋째, "모든 것을 다 할 수 있는 에이전트보다, 하나를 아주 잘 하는 에이전트가 현장에서 더 많이 쓰인다"는 설계 철학입니다. 생성형 AI는 대부분의 실무자들에게 직관적이지 않은 기술입니다. 멀티턴 대화를 이어가며 원하는 결과를 끌어내는 사용 방식을 이해하기 전에 불만이 먼저 쌓이고, 사용을 포기하는 경우가 많습니다. 그렇기 때문에 기업용 에이전트는 목적과 용도를 좁고 뾰족하게 정의하고, 대표적인 사용 방법과 기대 결과물을 지속적으로 교육해야 실효가 있습니다.
Applied AI, 현장에 적용된 AI는 연구실의 AI와 다르다
AI를 현장에 적용한다는 것은 기술을 만드는 일이 아닙니다. 기술이 현실 속에서 작동하도록 만드는 일입니다. 그 과정은 언제나 예상보다 훨씬 구체적이고, 훨씬 지난합니다.
수만 건의 문서를 읽힐 수 있는 형태로 바꾸고, 검색 아키텍처를 재설계하고, 보안 정책 안에서 가능한 최선의 기술 조합을 찾고, 실무자가 실제로 쓸 수 있도록 경험을 설계하는 것. 이 네 가지는 순서대로 해결할 수 있는 과제가 아니라, 동시에 맞물려 돌아가는 구조적 조건들이었습니다. 그리고 이 조건들을 하나의 체계 안에서 통합적으로 풀어낼 수 있었던 것이, 메타넷엑스 그룹이 이 프로젝트에서 발휘한 가장 핵심적인 역량이었습니다.
현재 보안취약점 점검(ISMS) 적용 과정을 거치고 있으며, 정식 오픈을 앞두고 있습니다. AI 챗봇을 위해 구축한 인프라는 이미 H 증권사의 다음 서비스를 위한 기반으로 확장되고 있습니다.
H 증권사의 프로젝트가 보여주는 것은 명확합니다. 생성형 AI의 성패는 모델이 아니라 인프라에서 결정됩니다. 그리고 그 인프라는 단순한 서버 환경이 아니라, 데이터 파이프라인과 보안 체계와 사용자 경험을 아우르는 총체적인 기반을 의미합니다. 이 기반을 만들 수 있는 역량 — AI 기술과 클라우드 인프라를 하나의 조직 안에서 결합하고, 고객이 AI를 실제로 동작시킬 수 있는 환경을 함께 만드는 것. 그것이 메타넷엑스가 이 프로젝트에서 증명한 가치입니다.
아래의 스켈터랩스 블로그 두 편을 통해, 현장의 더욱 생생한 메시지를 확인하실 수 있습니다.
