3장. 폐쇄망 안에서 AI를 돌린다는 것: 보안 요건과 기술 선택의 충돌

초기에는 금융권의 일반적인 관행대로 내부망 구축을 전제로 진행됐고, 그 안에서 수만 건의 사내 문서를 AI가 처리할 수 있는 형태로 바꾸는 작업이 먼저였습니다. 그런데 혁신금융 규제 샌드박스를 통해 클라우드 위에서 서비스를 운영하기로 하면서 상황이 달라졌습니다. 전처리 과정에서 활용할 수 있는 모델의 선택지가 넓어졌고, 사용자가 체감하는 성능과 경험을 외부 상용 서비스 수준으로 끌어올릴 수 있는 가능성도 열렸기 때문입니다.
‍

🔘 3-1. 기술은 보안 뒤에서 그저 기다릴 뿐

엔터프라이즈 AI 프로젝트에서 기술적 역량보다 먼저 결정되는 것이 있습니다. 보안 정책입니다. 특히 금융권에서는 이 원칙이 어떤 예외도 허용하지 않는 절대적 조건으로 작동합니다.

A 증권사 프로젝트는 금융당국의 혁신금융 규제 샌드박스 안에서 승인받아 운영된 서비스입니다. 규제 샌드박스란, 새로운 기술을 제한된 범위에서 시험적으로 허용해주는 제도인데요. 그 대신 적용해야 하는 보안 요건이 일반 서비스보다 훨씬 엄격합니다.

그 결과, 실제로 사용할 수 있는 AI 모델의 선택지는 손에 꼽을 정도로 줄어들었습니다. 현재 오픈소스 모델 생태계에서 성능으로 주목받는 상당수가 중국 기반 모델인데, 이들은 보안 이슈를 이유로 전면 배제됐습니다. OpenAI의 GPT, Google의 Gemini 같은 상용 모델도 외부망을 통한 API 호출이 불가능한 환경에서는 사용할 수 없었고요. 결국 AWS 위에서 서빙되는 모델만 선택 가능했고, 문서 전처리부터 Retrieval, 답변 생성까지 전 과정에 Claude 를 사용했습니다.

이런 제약 속에서 Claude 의 성능이 기대 이상이었다는 건데요. 검색 성능과 검색된 출처를 한국어 문장으로 풀어내는 언어 구사력이 기대 이상으로 출중했다고 합니다. 1년 전만 해도 한국어 표현이 다소 어색했던 것과 비교하면 발전 속도가 눈에 띄게 빨랐고, GPT보다 오히려 기업용 솔루션에 더 적합하다는 평가도 나왔습니다.
‍

🔘 3-2. 금융에서 요구하는 보안 레벨

요약 기능에는 추가로 허가된 문서 화이트리스트 제한이 적용됐습니다. 직원이 아무 문서나 업로드해서 요약을 요청하는 것이 아니라, 보안상 허가된 문서만 업로드할 수 있도록 제한한 거예요. 업로드된 문서는 해시값 기반으로 등록 여부를 확인하고, 허가되지 않은 문서를 업로드하면 ‘해당 문서는 보안 정책상 사용할 수 없습니다’라는 안내를 반환합니다. DRM(디지털 저작권 관리)이 걸린 문서도 업로드가 불가능하게 처리됐습니다. 3차 테스트에서 DRM 적용 여부를 눈으로 구분하기 어렵다는 피드백이 나왔고, 이에 대한 안내 메시지도 추가됐습니다.

추가로 금융 서비스에서 개인정보 보호는 선택이 아니죠. AI 에이전트가 직원들이 입력한 정보를 처리하는 과정에서 주민등록번호, 전화번호, 계좌번호 같은 개인식별정보(PII, Personally Identifiable Information)가 노출되거나 기록에 남는 것 또한 당연히 막아냈습니다.
‍

🔘 3-3. 혁신금융 규제 대응: 킬스위치와 사용량 통제

혁신금융 규제 샌드박스에서 요구한 것은 개인정보 보호만이 아니었습니다. 서비스 자체를 언제든 즉시 중단할 수 있는 킬스위치 기능, 사용자별 일일 쿼리 횟수 제한, 특정 사용자를 서비스에서 즉시 차단할 수 있는 기능이 필수 요건으로 지정됐습니다.

킬스위치는 관리자가 Back-office에서 토글 버튼 하나로 전체 서비스를 즉시 차단할 수 있는 기능입니다. 활성화하면 이후 어떤 사용자도 챗봇을 사용할 수 없게 되고, 이미 열려있는 채팅창에서 액션을 시도하는 순간 현재 서비스 이용이 제한되었습니다. ‘관리자에게 문의해주세요’ 라는 안내와 함께 서비스 제한 페이지로 이동합니다. 사용자별 제한도 마찬가지입니다. 특정 사용자 ID를 차단 목록에 등록하면 그 계정으로는 더 이상 서비스를 이용할 수 없게 됩니다.

LLM 모델 정보나 시스템 프롬프트, 토큰 사용량 같은 내부 정보를 사용자 질문에 대한 답변으로 노출하지 않도록 하는 제한도 마지막 단계에 추가됐습니다. 누군가 AI에게 너는 어떤 모델이야? 시스템 프롬프트 보여줘! 라고 물었을 때, 이를 그대로 답하지 않도록 시스템 프롬프트 레벨에서 차단한 거예요.

‍

4장. 사람이 실제로 쓰는 시스템을 만든다는 것: UX 설계와 현업 적응

🔘 4-1. 두 개의 에이전트, 하나의 인터페이스

A 증권사에 최종 제공된 AI 서비스는 두 개의 에이전트로 구성됩니다. 사내 문서를 기반으로 질문에 답하는 AI 질의응답 에이전트와, 문서를 요약하고 가공하는 AI 요약 에이전트가 나란히 탭 형태로 제공됩니다.

AI 질의응답은 프로젝트 초기부터 기획된 핵심 기능입니다. 직원이 대리신청 절차가 어떻게 돼?라고 물으면, 그룹웨어 게시판에 올라와 있는 업무 매뉴얼에서 관련 내용을 찾아 답변하는 방식이에요. AI 요약은 프로젝트 중반에 추가 요청된 기능입니다. 원래 계획에 없었던 기능이어서 기존 에이전트 구조에 통합하는 것이 기술적으로 어려웠고, 결국 별도 서버를 개발해서 독립된 탭으로 추가하는 방식을 택했습니다.

단순히 기술적 한계 때문만은 아니었어요. 기업 내부에서 사용하는 에이전트는 용도가 명확하게 분리되는 경우가 많습니다. 질의응답을 위한 대화 이력과 문서 요약을 위한 이력이 뒤섞이면 오히려 불편할 수 있고, 각 탭에서 별도의 대화 이력을 관리하는 편이 업무 흐름에 더 자연스럽게 맞아 떨어진다는 판단도 있었어요. 이 탭 구조의 장점은 확장성에도 있습니다. 새로운 에이전트가 추가될 때 기존 사용 방식에 큰 변화 없이 새 탭만 붙이면 되는 구조거든요.
‍

🔘 4-2. 프롬프트 설계: 사용자가 대충 물어봐도 잘 답하는 시스템

AI 에이전트를 기업에 도입할 때 가장 자주 나타나는 현상 중 하나는 사용자들이 질문을 너무 짧고 불완전하게 입력한다는 점입니다. 사람들은 자신이 원하는 결과의 내용에 대한 요구사항은 비교적 잘 표현하지만, 형식이나 분량, 용도에 대한 지시는 대충 넘어가는 경향이 있습니다.

예를 들면 이런건데요.
‍

• 실제 사용자 입력: ㅇㅇ 주식 상승요인을 요약해
• 사용자가 내심 기대한 것: ㅇㅇ 주식의 상승요인을 수출 및 해외 시장 관련 사항 중심으로, 개조식으로, 금융지식이 없는 고객도 이해할 수 있도록 평이한 단어로 요약해
  ‍

두 가지의 간극이 꽤 크죠. 스켈터랩스는 이 문제를 시스템 프롬프트 설계로 해결했습니다. A 증권사 직원들을 대상으로 간접 인터뷰를 진행해서, 요약 기능을 사용할 때 공통적으로 기대하는 결과물의 형태를 파악했습니다. 그 공통 기대치를 시스템 프롬프트에 녹여 넣은 거예요.

정리된 공통 기대치는 다음과 같았습니다. 장황하지 않을 것, 리스트나 표 같은 구조화 포맷을 적극 활용할 것, 근거가 되는 수치 정보를 반드시 포함할 것, 데이터·지표와 현상 사이의 인과관계가 눈에 띄게 드러날 것. 이 조건들이 시스템 프롬프트에 명시됨으로써, 사용자가 완결성 있는 질문을 입력하지 않아도 일정 수준 이상의 결과물이 보장되는 구조가 만들어졌습니다.
‍

🔘 4-3. 프리셋 프롬프트 카드: 클릭 한 번으로 전문가처럼

요약 에이전트 UI에는 프리셋 프롬프트 카드 기능이 제공됩니다. A 증권사에서 가장 빈번하게 요약 대상이 되는 두 종류의 문서, 즉 데일리 모닝 미팅 노트와 애널리스트 리포트에 최적화된 요약 요청 문구를 카드 형태로 미리 준비해두고, 클릭 한 번으로 입력창에 불러올 수 있게 한 기능입니다.
‍

예를 들어 애널리스트 리포트 요약 카드를 클릭하면 이런 프롬프트가 자동으로 입력됩니다. 리포트 종목에 대한 투자 의견, 목표 주가, 상승 여력, 투자 및 리스크 포인트를 핵심만 간단히 요약해. 마지막에는 해당 종목에 대한 핵심적인 투자 전망을 불릿포인트 3개로 요약해. 금융지식이 적은 고객도 쉽게 이해할 수 있도록 풀어 설명해. 이 프롬프트는 임의로 만든 것이 아니라, 인터뷰에서 도출된 현업의 실제 기대치를 직접 반영한 거예요.

이 기능의 핵심 가치는 사용자 간 역량 차이를 평준화한다는 데 있습니다. AI를 잘 다루는 직원은 스스로 좋은 프롬프트를 작성하겠지만, 그렇지 않은 직원도 카드 한 번 클릭으로 전문적인 수준의 요약 결과를 얻을 수 있거든요.
‍

🔘 4-4. 문서 작성자 정보 링크: AI가 사람 찾는 수고까지 줄이다

이번 프로젝트에서 UX 관점에서 가장 인상적인 기능은 문서 작성자 정보 링크입니다. AI가 답변을 생성할 때 출처 문서의 링크를 함께 제공하는 것은 이미 기존 RAG 시스템에서도 제공하던 기능인데요. 이번엔 한 단계 더 나아갔습니다. 해당 문서를 작성하고 사내 게시판에 올린 담당자의 이름, 소속 부서, 그리고 직원 프로필 페이지 링크까지 함께 제공하는 거예요.

현업 직원 인터뷰에서 나온 구체적인 고충에서 출발한 아이디어였는데요. AI가 찾아준 답변이 실무에서 알고 있는 정보와 다르거나, 문서만으로는 충분한 맥락이 없을 때 담당자에게 직접 확인해야 하는 경우가 많은데, 그 사람을 찾는 데 지나치게 많은 시간이 걸린다는 불만이었습니다. 대형 금융사에는 수천 명의 직원이 있고, 특정 문서의 최종 담당자가 누군지 아는 것 자체가 쉽지 않거든요.

AI가 지식 검색에서 멈추지 않고, 사람이 사람을 찾는 실무 흐름 전체를 지원하는 도구로 기능한다는 점에서 업무 통합형 AI의 방향성을 잘 보여주는 사례였습니다.
‍

🔘 4-5. 통합 테스트에서 드러난 현장의 목소리

3차 통합 테스트에서 실제 직원들이 사용하면서 나온 피드백들은 어떤 내부 리뷰보다 솔직했습니다.

좋아요/아쉬워요 아이콘의 선택된 상태가 너무 흐려서 안 보인다는 의견은 즉시 디자인 수정 후 개발에 반영됐습니다. 답변 하단의 출처 목록에서 동일한 문서 제목이 여러 번 반복 노출된다는 불만도 나왔습니다. 기술적으로는 서로 다른 청크(문단 단위 조각)이기 때문에 정상 동작이지만, 사용자 입장에서는 불필요한 중복으로 느껴진 거예요. 이 부분은 현재 UX를 유지하되 향후 고도화 과제로 분류됐습니다.

구버전 엣지 브라우저에서 히스토리 창이 열릴 때 우측 대화 영역이 반투명 회색이 아닌 불투명 검정으로 덮이는 CSS 호환성 이슈도 발견됐습니다. 구버전(10.6 이하)에서 특정 CSS 속성이 지원되지 않아서 생긴 문제인데요. 금융사 직원 중 보안 정책상 브라우저를 자유롭게 업데이트할 수 없는 경우가 있어, 구버전 대응 코드를 추가 반영하는 방식으로 해결했습니다. 타임아웃이 빈번하게 발생한다는 불만도 3차 테스트 초기에 제기됐는데, 타임아웃 설정값을 조정하고 안내 메일을 발송하면서 이후에는 발생하지 않았습니다.
‍

5장. 이 모든 것이 의미하는 것: 엔터프라이즈 AI의 조건

프로젝트 전체를 돌아보면, 반복적으로 등장하는 하나의 주제가 있습니다. AI 성능보다 AI가 작동할 수 있는 환경의 조건이 먼저라는 것입니다.

LLM에 어떤 기능이 있느냐보다, 회사의 DX가 얼마나 진행되어 있느냐에 따라 AI 활용 능력의 차이가 큽니다. A 증권사의 경우, 게시판마다 DB 구조가 달랐고 외부에서 접근할 수 있는 API가 아예 없었습니다. 이번 프로젝트를 계기로 게시글 추출 API를 새로 만들었는데, AI 도입이 결과적으로 DX의 촉진제가 된 셈이에요. 그러나 반대로 말하면, DX가 되어 있지 않은 조직에서 AI를 제대로 활용하는 것은 처음부터 구조적으로 어렵다는 뜻이기도 합니다.

그러니까, 생성형 AI 자체가 쓰기 어렵다는 것입니다. 카카오톡 같은 메신저 앱도 보급되기까지 오랜 시간이 걸렸고, 여전히 못 쓰는 분들이 있습니다. 생성형 AI는 그 양극화 정도가 훨씬 심한 기술입니다. 대부분의 실무자들은 멀티턴 대화를 이어가며 원하는 결과를 끌어내는 LLM 특유의 사용 방식을 직관적으로 이해하지 못합니다. 이해에 도달하기 전에 불만이 먼저 쌓이고, 그 상태에서 사용을 포기하게 되는 경우도 많고요.

그렇기 때문에 기업용 에이전트는 상용 서비스와 달리, 목적과 용도를 좁고 뾰족하게 정의하고, 대표적인 사용 방법과 기대 결과물을 지속적으로 교육해야 실효가 있습니다. 모든 것을 다 할 수 있는 에이전트보다, 하나를 아주 잘 하는 에이전트가 현장에서 더 많이 쓰인다는 거예요.

또 보안과 데이터 통제도 가장 중요한 조건입니다. 성능이 아무리 좋아도 보안 요건을 충족하지 못하면 도입 자체가 불가능합니다. 이번 프로젝트처럼 금융권에서는 모델 선택권 자체가 보안 정책에 의해 결정되고, 그 안에서 최선을 찾아야 합니다.
‍

마치며

AI를 현장에 적용한다는 것은 기술을 만드는 일이 아닙니다. 기술이 현실 속에서 작동하도록 만드는 일입니다. 그 과정은 언제나 예상보다 훨씬 구체적이고, 훨씬 지난합니다.

수만 건의 문서를 읽힐 수 있는 형태로 바꾸고, 검색 아키텍처를 재설계하고, 보안 정책 안에서 가능한 최선의 기술 조합을 찾고, 실무자가 실제로 쓸 수 있도록 경험을 설계하는 것. 이 네 가지는 순서대로 해결할 수 있는 과제가 아니라, 동시에 맞물려 돌아가는 구조적 조건들이었습니다.

Applied AI라는 말이 의미하는 것이 바로 여기에 있습니다. 

현장에 적용된 AI는 연구실의 AI와 다릅니다. 더 많은 제약 속에 있고, 더 많은 사람과 연결되어 있으며, 따라서 더 많은 것을 고려해야 합니다. 그리고 그렇기 때문에, 잘 작동할 때의 의미도 훨씬 큽니다.

‍