금융권 RAG 구조에서 권한 없는 데이터 접근을 막으려면 벡터 DB 쿼리 시 사용자의 권한 메타데이터를 동적으로 삽입하는 사전 필터링(Pre-filtering)과 ABAC/ReBAC 모델을 활용해야 한다. 또한 프롬프트 인젝션은 중앙 게이트웨이를 통한 외부 호출의 결정론적 승인 체계를 구축해 방어한다.
RAG의 기본 개념과 금융권 도입 배경
검색 증강 생성(RAG, Retrieval-Augmented Generation)은 대규모 언어 모델(LLM)이 학습하지 않은 최신 데이터나 기업 내부 비공개 문서를 검색해 답변의 근거로 삼는 기술이다. 금융사는 방대한 내부 규정, 상품 약관, 고객 상담 이력 등을 보유하고 있으며, 이를 효율적으로 쓰기 위해 RAG 도입을 서두르고 있다. 최근에는 단순 텍스트 검색을 넘어 지식 그래프를 결합한 GraphRAG, 자율적으로 도구를 선택하는 Agentic RAG, 이미지와 표를 동시에 처리하는 Multimodal RAG로 기술이 나아가고 있다.
금융권은 보안상의 이유로 퍼블릭 클라우드 기반 LLM 서비스보다 내부 인프라에 직접 구축하는 온프레미스 RAG 스택을 많이 선택한다. 데이터가 외부망으로 빠져나가는 것을 원천 차단하고 금융감독원 등의 보안 가이드라인을 지키기 위해서다. 하지만 RAG를 도입하면 사용자 권한에 따라 접근할 수 있는 문서의 범위를 다르게 설정하는 권한 제어 문제가 핵심 쟁점으로 떠오른다. 적절한 권한 제어가 없다면 일반 직원이 임원급 기밀 문서나 타 부서의 민감한 고객 정보가 담긴 데이터를 AI를 통해 조회하는 심각한 보안 사고로 이어질 수 있다.
금융 AI 데이터 유출 방지 및 RAG 보안을 위한 데이터 접근 제어 설계
금융 AI 데이터 유출을 막으려면 RAG 아키텍처 전 과정에 정교한 권한 제어 메커니즘을 설계해야 한다. 가장 중요한 기술적 방안은 사전 필터링(Pre-filtering) 적용이다. 사용자가 질문하면 시스템이 벡터 DB에 쿼리를 보내기 전 사용자 ID와 권한 정보를 확인하고, 쿼리 파라미터에 해당 사용자가 접근 가능한 문서 ID나 그룹 태그를 필터 조건으로 동적으로 넣는 방식이다. 이렇게 하면 모델이 답변을 생성할 때 참조하는 컨텍스트 자체를 인가된 데이터로만 제한해 정보 유출을 원천 차단한다.
기존의 단순한 역할 기반 접근 통제(RBAC)만으로는 금융사의 복잡한 조직 구조와 프로젝트별 권한 체계를 관리하기 어렵다. 속성 기반 접근 통제(ABAC)와 관계 기반 접근 통제(ReBAC) 도입이 필수적이다. ABAC는 사용자의 직급, 부서, 접속 IP, 시간대 등 다양한 속성을 조합해 접근 여부를 판단하고, ReBAC는 데이터와 사용자 간의 관계(예: 담당 고객, 소속 팀원)를 정의해 권한을 동적으로 처리한다. 이러한 고도화된 권한 모델은 데이터의 유연한 활용과 엄격한 보안 두 마리 토끼를 잡는다.
데이터 수집 단계의 보안 조치도 중요하다. 문서가 청크(Chunk) 단위로 분할돼 벡터 DB에 저장되기 전 식별 가능한 개인 정보(PII)를 탐지해 비식별화 처리하는 과정이 먼저다. 동시에 각 문서 청크에는 해당 데이터에 접근할 수 있는 권한 메타데이터를 명시적으로 태깅해야 한다. 이 태깅 정보는 앞서 언급한 사전 필터링 단계에서 결정적인 기준점이 되며, 데이터의 생명주기 전반에 걸쳐 일관된 보안 정책을 적용하는 기반이 된다.
| 구분 | RBAC (역할 기반) | ABAC (속성 기반) | ReBAC (관계 기반) |
|---|---|---|---|
| 제어 기준 | 사용자에게 부여된 역할(Role) | 사용자, 자원, 환경의 속성(Attribute) | 사용자와 자원 간의 관계(Relation) |
| 유연성 | 낮음 (역할 추가 시 복잡도 증가) | 높음 (다양한 조건 조합 가능) | 매우 높음 (동적 관계 정의 가능) |
| 금융권 적용 사례 | 부서별 기본 문서 접근 권한 부여 | 특정 시간/장소 내 민감 문서 접근 제한 | 담당 고객의 계좌 정보 및 상담 이력 조회 |
프롬프트 인젝션 방어 및 보안 가드레일 구현
에이전틱 RAG(Agentic RAG) 시스템으로 발전하면서 AI 에이전트가 스스로 API를 호출하거나 외부 도구를 사용하는 기능이 생겼다. 이 과정에서 가장 큰 위협은 ‘과도한 에이전시(Excessive Agency)’다. 에이전트가 설계된 범위를 벗어나 권한이 없는 시스템 명령을 실행하거나, 악의적인 프롬프트 인젝션 공격으로 내부 데이터를 외부로 빼내는 현상을 말한다. 프롬프트 인젝션은 사용자가 교묘하게 작성한 입력값으로 AI의 시스템 프롬프트를 무력화하고, 원래 설정된 보안 지침을 무시하게 유도하는 공격 기법이다.
이를 막으려면 외부화된 정책 결정 구조를 도입해야 한다. 에이전트가 수행하는 모든 외부 호출(API 호출, DB 쿼리, 툴 실행)을 AI가 직접 하게 두지 않고, 중앙 보안 게이트웨이가 이를 가로채 판단하는 구조를 만드는 것이다. 게이트웨이는 미리 정의된 결정론적 승인 리스트(Allow-list)와 정책을 바탕으로 요청이 적절한지 검증하며, 비정상적인 요청이 감지되면 즉시 차단하고 관리자에게 알린다.
입력과 출력 단계 모두에 보안 가드레일을 배치해야 한다. 입력 가드레일은 사용자의 질문에서 인젝션 패턴이나 금지어를 걸러내고, 출력 가드레일은 생성된 답변에 민감 정보가 포함됐는지 다시 검사해 마스킹 처리한다. 이러한 다층 방어 체계는 LLM의 확률적 특성 때문에 발생할 수 있는 보안 허점을 보완하고 금융 서비스의 신뢰성을 확보하는 핵심 장치다.
금융 RAG 시스템 감사 및 규제 준수 전략
EU AI Act를 비롯해 전 세계적으로 AI 규제가 강화됨에 따라, 금융권 RAG 시스템도 투명한 감사 기록과 추적 가능성을 확보해야 한다. AI가 특정 답변을 내놓은 이유, 어떤 데이터에 접근했으며, 어떤 판단 과정을 거쳐 도구를 호출했는지 증명할 수 있어야 한다. 사용자 입력부터 최종 응답까지 전체 실행 트레이스(Execution Trace)를 정형화된 JSON 로그 형태로 기록하는 체계가 필요하다.
구체적인 감사 및 관찰 가능성 확보 방안은 다음과 같다.
- OpenTelemetry(OTel) 표준 채택: 분산 추적 표준인 OpenTelemetry를 도입해 서로 다른 마이크로서비스 간 호출 흐름을 통합 관찰하고, 지연 시간 및 오류 발생 지점을 정확히 파악한다.
- 에이전트 사고 과정(Chain-of-Thought) 기록: 에이전트가 계획을 세우고, 도구를 선택하고, 결과를 해석하는 모든 중간 단계의 텍스트 로그를 저장해 사후 분석이 가능하게 한다.
- 접근 제어 로그의 실시간 통합: 벡터 DB 쿼리 로그와 중앙 게이트웨이 승인/거부 로그를 통합 관리해 권한 없는 접근 시도를 실시간 모니터링한다.
- 정기적인 레드팀 테스트 수행: 가상의 공격 시나리오를 설정해 프롬프트 인젝션 및 권한 우회 가능성을 주기적으로 점검하고, 발견된 취약점을 기반으로 보안 정책을 지속적으로 업데이트한다.
이러한 통합 관찰 가능성(Observability) 체계는 단순한 보안 사고 예방을 넘어 규제 기관의 감사 요구에 즉각 대응할 수 있는 증거 자료로 쓰인다. 특히 금융 보안 심사 항목에서 요구하는 데이터 흐름도와 접근 제어 매트릭스를 실시간 로그 기반으로 증명해 심사 대응 효율성을 극대화한다.
결론 및 제언
금융권에서 RAG를 성공적으로 도입하려면 단순한 성능 향상보다 철저한 보안 아키텍처 설계가 먼저다. 사전 필터링을 통한 데이터 접근 제어, ABAC/ReBAC 모델 도입, 중앙 게이트웨이를 통한 프롬프트 인젝션 방어, 그리고 OpenTelemetry 기반의 감사 체계 구축은 금융 AI 데이터 유출 방지를 위한 필수 전략이다. 특히 에이전틱 RAG로 전환하는 시기에 발생하는 과도한 에이전시 위협에 대응하려면 동적 거버넌스 체계로의 전환이 시급하다.
보안과 효율성 사이의 균형을 맞추려면 초기 설계 단계부터 보안 팀과 AI 개발 팀이 협력해 보안 가드레일을 내재화해야 한다. 지금 운영 중인 RAG 파이프라인의 권한 제어 지점을 점검하고, 데이터 유출 가능성이 있는 취약 구간을 식별해 단계적인 보안 고도화를 추진해야 한다.