제미나이 4를 금융 업무에 연결하기 전에 정할 AI-Ready Data 기준

구글이 9월 30일 발표한 Gemini 4 Argon(제미나이 4 아르곤)이 10월 13일 Gemini API에 정식 출시됐습니다. 발표 당시에는 일부 사이버 방어 담당자에게만 제공됐는데, 이제는 개발자가 API로 사내 시스템에 바로 연결해 볼 수 있습니다. 구글은 발표 글에서 이 모델이 법률과 금융처럼 전문 지식이 필요한 업무에서 높은 성능을 낸다고 밝혔습니다. 금융, 법률, 세무, 코딩 업무를 함께 평가하는 Vals Index에서는 1위를 기록했다고 소개했습니다.

모델을 시험 화면에서 써 볼 때는 답이 좋은지가 관심사인데요. 사내 시스템에 연결하는 순간 질문이 바뀝니다. 고객 기록을 그대로 넣어도 되는지, 넣는다면 무엇을 바꾸고 무엇을 남겨야 하는지, 돌아온 결과를 어느 고객과 어느 기록에 붙여야 하는지를 정해야 합니다.

이 질문은 여러 사람이 함께 확인해야 합니다. 정보보호 담당은 어떤 값이 모델로 전달되는지 보고, 업무 담당은 결과가 실제 심사에 쓸 만한지 보며, 시스템 담당은 결과를 어느 기록에 연결할지 정합니다. 금융위원회(Financial Services Commission)가 2026년 6월에 개정 발표한 「금융분야 인공지능 가이드라인」도 현 단계의 AI를 업무의 보조수단으로 봅니다. 최종 의사결정과 책임은 임직원에게 있다고 정리했습니다. 담당자가 판단하려면 AI 결과가 원래 고객과 근거 기록에 연결된 채로 돌아와야 합니다.

이 글은 한 차입자의 기록 여러 건을 다루는 기업여신 검토를 예로 들어, 제미나이 4 같은 외부 모델을 사내 업무에 연결하기 전에 정할 데이터 기준을 순서대로 짚습니다. 모델은 바뀌어도 이 기준은 계속 쓰입니다. 그러니 데이터를 AI 업무에 활용할 수 있는 AI-Ready Data 상태로 만들어 두고, 모델이 바뀔 때마다 다시 확인하는 편이 이후 운영에도 유리합니다.

핵심 요약

• 사내 시스템에 연결하면 모델에는 질문 한 줄이 아니라 시스템이 불러온 여러 기록이 함께 들어갑니다.
• 보호할 값에는 개인정보뿐 아니라 내부 고객 코드, 계약 참조번호 같은 기업 고유 정보도 들어가며, 목록은 기관이 정합니다.
• 같은 차입자는 기록이 달라도 같은 표식으로 이어져야 하고, 판단에 쓰는 금액과 날짜를 어떻게 다룰지는 업무 기준으로 먼저 정해야 합니다.
• AI 결과는 원래 차입자와 근거 기록으로 돌아와야 담당자가 검토하고 다음 절차로 넘길 수 있습니다.
• 값을 바꾸는 것만으로 보호와 활용을 함께 챙기기 어려운 데이터는 필요한 특성을 반영해 재구성하는 방법도 검토합니다.

AI를 사내 시스템에 붙이면 고객 기록도 함께 전달됩니다

한 은행의 기업여신 담당자가 여신 시스템에 붙은 AI 검토 기능으로 “이 차입자의 최근 상담 내용과 약정 조건을 요약하고, 심사 전에 확인할 항목을 정리해 줘”라고 요청한다고 가정해 보겠습니다. 이때 모델에는 요청 한 줄만 들어가지 않습니다. 시스템이 관련 기록을 찾아 함께 넘기기 때문에 상담 메모 여러 건, 이전 심사 의견, 약정 기록이 한꺼번에 전달됩니다.

이 기록들에는 차입자 회사명과 대표자 이름, 연락처, 계좌번호뿐 아니라 내부 고객 코드와 계약 참조번호, 대출 금액과 만기일이 그대로 적혀 있습니다. 구글은 Argon을 오래 걸리는 복잡한 작업을 위한 모델로 소개했습니다. 맡기는 작업이 복잡할수록 시스템이 판단 근거로 함께 넘기는 기록도 늘어나기 쉽습니다.

그래서 연결 전에 챙길 것은 모델 성능보다 데이터입니다. 어떤 값을 보호할지, 보호한 뒤에도 기록 사이의 관계가 남는지, 결과를 어디로 되돌릴지를 먼저 정해야 업무에 믿고 쓸 수 있습니다.

이름과 연락처 외에 사내 코드와 계약번호도 가려야 합니다

이름, 연락처, 계좌번호처럼 형식이 정해진 개인정보는 보호 도구의 기본 탐지 대상인 경우가 많지만, 표기 형식에 따라 놓치는 값도 있습니다. 그런데 기본 탐지 대상에 처음부터 들어 있지 않은 값도 있는데요. 차입자 회사명, 내부 고객 코드, 계약 참조번호, 담당 부서 코드처럼 법률상 개인정보는 아니어도 사내 정책상 밖으로 내보내지 않는 값이 기록 곳곳에 있습니다.

이런 값은 기관마다 다르기 때문에 목록을 기관이 직접 정해야 합니다. 여신 업무라면 정보보호 담당과 업무 담당이 함께 앉아, 실제 기록 몇 건을 펼쳐 놓고 모델로 보내면 안 되는 값을 표시해 보는 것이 현실적인 출발점입니다. LLM Capsule 웹 서비스로 확인해 보면 기본 탐지 대상은 이름, 연락처, 계좌번호, 금액, 날짜처럼 형식이 정해진 값이 중심이라, 회사명이나 내부 코드는 기관이 따로 지정해야 하는 값입니다. 이렇게 정한 목록은 기본 탐지 대상에 더해 기관별 목록으로 관리합니다.

목록을 정할 때는 반대쪽도 함께 봐야 합니다. 업무 판단에 꼭 필요한 값까지 바꿔 버리면 결과가 쓸모없어지기 때문입니다.

기록마다 다르게 가리면 같은 고객이 다른 사람으로 보입니다

여러 기록을 함께 넘기면 같은 차입자가 상담 메모에도, 심사 의견에도, 약정 기록에도 나옵니다. 차입자 이름이 기록마다 다른 표식으로 바뀌면 모델 입장에서는 서로 다른 세 회사의 기록으로 보입니다. 그러면 한 차입자의 이력을 묶어 요약하라는 요청 자체가 성립하지 않습니다.

그래서 같은 값은 기록과 요청이 바뀌어도 같은 표식으로 이어져야 합니다. 차입자 대표의 이름이 [성명_A]로 바뀌었다면 상담 메모에서도, 약정 기록에서도, 이어지는 다음 요청에서도 [성명_A]여야 합니다. 실제로 LLM Capsule 웹 서비스에 가상 여신 기록 세 건을 넣어 확인해 보니, 세 기록에 다섯 번 나온 대표자 이름이 모두 [성명_A]로 바뀌었고, 같은 대화에서 이어 요청한 안내 문자 초안에도 같은 표식이 그대로 이어졌습니다. 표식에 값의 종류가 드러나면 사람 이름과 전화번호가 구분된 채로 답이 만들어집니다.

금액과 날짜는 따로 정해야 합니다. 여신 검토에서 대출 금액과 만기일은 판단의 근거입니다. 금액을 표식이나 다른 값으로 바꿔 넘기면 실제 금액이 빠진 채로 결과가 만들어지고, 결과 속 표식을 나중에 원래 금액으로 되돌려도 그 내용이 바로잡히지는 않습니다. 어떤 값을 표식으로 바꾸고 어떤 값을 그대로 둘지는 업무 기준으로 먼저 정하고, 쓰려는 도구에서 그 기준대로 설정할 수 있는지 확인해야 합니다.

가린 채 받은 결과는 실제 고객 이름으로 되돌려야 쓸 수 있습니다

표식이 든 요약은 그대로 업무에 쓸 수 없습니다. “[성명_A] 대표 회사의 약정 만기가 다가오고 있어 상환 계획 확인이 필요합니다”라는 결과를 받았다고 해 보겠습니다. 담당자가 원본 기록을 다시 열어 [성명_A]가 누구인지 찾아야 한다면 AI 검토 기능을 붙인 의미가 줄어듭니다.

결과 속 표식은 원래 값으로 복원돼야 하고, 담당자는 그 결과가 어느 상담 메모와 어느 약정 기록에서 나왔는지 대조할 수 있어야 합니다. 금융위원회 가이드라인은 최종 의사결정과 책임을 임직원에게 두는데, 담당자가 AI 결과를 직접 판단하려면 결과가 원래 고객과 기록으로 돌아와 있어야 합니다.

사내 문서를 검색해 답을 만드는 구성도 마찬가지입니다. 검색 단계마다 원문이 어디로 가는지는 RAG에 반출 불가 문서를 쓰려면?에서 따로 다뤘습니다.

고객 기록을 대량으로 쓸 때는 가리는 것만으로 부족할 수 있습니다

지금까지 본 여신 검토는 차입자 한 명의 기록을 다루는 업무입니다. 반면 연결한 검토 기능이 제대로 답하는지 미리 시험하려고 여러 차입자의 기록을 한꺼번에 써야 할 때는 사정이 다릅니다. 기록이 많이 모이면 이름을 가려도 업종, 금액, 지역 같은 값이 겹쳐 특정 차입자를 짐작할 수 있습니다. 그렇다고 이런 값까지 표식으로 바꾸면 이번에는 시험에 필요한 업종별 분포와 금액 구간, 항목 사이의 관계가 사라집니다.

큐빅은 이런 데이터를 DTS로 다룹니다. DTS는 원본 기록을 그대로 복사하지 않고, AI 업무에 필요한 특성과 분포, 관계를 반영한 대체 데이터로 재구성하는 큐빅의 기술입니다. 다만 재구성한 데이터라고 해서 개별 기록이 드러날 위험이 자동으로 사라지지는 않으므로, 그 위험은 따로 평가해야 합니다. 어떤 업무에 치환이 맞고 어떤 업무에 재구성이 맞는지는 데이터와 목적을 함께 보고 정합니다.

AI를 연결하기 전에 확인할 8가지

외부 모델을 사내 업무에 연결하기 전에 아래 질문에 답할 수 있는지 확인해 보세요.

• 모델로 전달되는 기록의 종류와 범위를 업무별로 정했나요?
• 개인정보 외에 사내 정책상 내보내지 않는 값(내부 고객 코드, 계약 참조번호 등)까지 보호 대상 목록에 넣었나요?
• 같은 고객이나 같은 계약이 여러 기록에 나올 때 같은 표식으로 이어지나요?
• 판단에 쓰는 금액과 날짜를 그대로 둘지, 어떻게 다룰지 업무 기준으로 정했나요?
• 결과 속 표식을 원래 값으로 복원하고, 담당자가 근거 기록과 대조할 수 있나요?
• 원본 값과 매핑 정보가 어디에 남고, 누가 볼 수 있는지 정했나요?
• 보호 대상이 빠지지 않고 처리되는지 실제 기록으로 확인해 봤나요?
• 모델을 바꾸거나 보호 기준이 바뀔 때 다시 확인할 사람과 절차를 정했나요?

이 목록은 규제 준수 여부를 판정하는 체크리스트가 아닙니다. 외부 AI 이용 여부와 범위는 각 금융회사의 내부 기준과 승인 절차에 따라 정해지며, 법무, 정보보호, 업무 담당이 함께 검토해야 합니다.

고객 한 명, 검토 한 건으로 작게 시작하세요

전체 여신 업무를 한 번에 연결하려 하면 정할 것이 너무 많아 검토가 길어집니다. 차입자 한 명, 기록 세 종류, 요청 하나로 범위를 좁히면 보호 대상과 결과를 연결할 곳이 구체적으로 정해집니다.

이 범위에서 지금 쓰는 방식과 나란히 비교해 보세요. 보호 대상이 빠짐없이 처리되는지, 같은 차입자가 기록 사이에서 이어지는지, 결과가 원래 기록으로 돌아와 담당자가 바로 검토할 수 있는지를 함께 확인합니다. 실제 업무 기록으로 이 흐름을 점검하려면 아래에서 도입 검토를 신청할 수 있습니다.

LLM Capsule이 맡는 일

LLM Capsule은 기존 제품과 AI 업무 안에서 민감한 기업 정보를 활용하게 하고, AI 결과를 원래 업무 대상에 다시 연결하는 큐빅의 데이터 레이어입니다. 이를 위해 민감한 값을 [성명_A], [전화번호_A]처럼 종류와 구분이 남는 표식으로 치환해 모델에 전달합니다. 같은 대화 안에서는 같은 값을 같은 표식으로 유지하고, 결과가 돌아오면 원래 값으로 복원합니다. 요약 항목을 어느 기록과 이어 보여 줄지는 기관 시스템의 화면 설계와 함께 정합니다. 단순 치환으로 보호와 활용을 함께 챙기기 어려운 데이터는 큐빅의 DTS로 필요한 특성을 반영해 재구성하는 방법을 함께 검토합니다.

기관 내부에 설치하는 구성에서는 원본 값과 매핑 정보가 기관 환경 안에 남고, 모델에는 표식으로 치환된 데이터만 전달됩니다. 이 구성에서는 기본 탐지 대상에 없는 차입자 회사명이나 계약 식별번호처럼 기관이 정한 값을 커스텀 필터로 추가할 수 있습니다. 웹 서비스는 큐빅 운영 환경에서 치환과 복원을 처리하므로, 제공 형태에 따라 처리 위치를 도입 전에 함께 확인합니다. 구성 방식은 LLM Capsule 아키텍처에서 볼 수 있습니다.

다만 LLM Capsule이 모든 민감한 값을 빠짐없이 찾아낸다고 보장하지는 않으며, 외부 AI 이용을 기관 대신 승인하지도 않습니다. 답을 만드는 모델로는 기관이 승인한 외부 모델이나 내부 모델을 따로 연결하며, 특정 모델과 연결되는지, 그 모델에서 표식이 그대로 유지되는지는 도입 검토 때 실제 기록으로 확인합니다. 이미 마스킹 도구를 쓰고 있다면 두 방식의 차이를 LLM Capsule vs 마스킹 도구에서 먼저 비교해 볼 수 있습니다.