법률 문서 RAG의 병목과 시맨틱 검색의 한계

엔터테인먼트 및 미디어 산업의 기업들은 수천 건의 계약서를 통해 권리, 갱신 옵션, 지리적 제한 및 컴플라이언스 의무를 결정하는 복잡한 업무를 수행한다. 기존의 계약 분석 작업은 대부분 수동으로 이루어져 시간과 비용이 많이 소요되며 확장성이 낮다는 한계가 있다. AWS 기반의 AIDA(AI-Driven Annotation) 솔루션은 비정형 계약서를 검색 가능한 지능형 정보로 변환하여 이 문제를 해결한다.

Amazon Bedrock의 시맨틱 검색은 최대 100개의 후보 청크(Candidate Chunks)만을 반환하는 제약을 가진다. 법률 문서는 문맥 의존성이 매우 높기 때문에, 단순한 시맨틱 검색만으로는 방대한 계약서 저장소에서 중요한 조항을 누락하거나 오해할 위험이 크다. 특히 벡터 공간에서의 유사도가 실제 법적 효력이나 문서의 정체성을 완전히 보장하지 못하므로, 검색 단계에서 확보한 컨텍스트의 질이 낮으면 LLM은 제공된 제한적인 정보 내에서만 그럴듯한 답변을 생성하는 경향을 보인다.

검색 정확도를 높이는 2단계 필터링 아키텍처

AIDA 솔루션은 벡터 검색을 수행하기 전 메타데이터 기반의 암시적(Implicit) 및 명시적(Explicit) 필터링을 선행하는 2단계 검색 아키텍처를 적용한다. 이 방식은 단순 시맨틱 검색에 의존하지 않고 메타데이터 제약 조건을 통해 검색 공간을 먼저 좁힌 뒤, 필터링된 서브셋 내에서만 유사도 매칭을 수행하여 검색 정밀도를 극대화한다.

암시적 필터링은 시스템이 자동으로 효력 발생일 범위나 특정 계약 당사자와 같은 메타데이터 조건을 적용하여 무관한 문서를 배제한다. 명시적 필터링은 사용자가 쿼리에 직접 지정한 특정 연도나 업체명 등의 조건을 반영하여 검색 경계를 정교하게 제어한다. AIDA는 이 두 가지 필터링을 순차적으로 적용함으로써 LLM이 처리해야 할 컨텍스트 윈도우의 낭비를 줄이고, 실제 정답이 포함된 텍스트 조각만을 효율적으로 추출한다.

AIDA의 9단계 RAG 워크플로우 상세 공정

AIDA는 문서 인제스천부터 최종 응답 전달까지 총 9단계의 체계적인 RAG 워크플로우를 통해 계약서 분석을 수행한다. 1단계에서는 계약 당사자, 효력 발생일, 종료일, 관할권 등의 구조화된 메타데이터 파일을 Amazon Bedrock Knowledge Bases로 동기화한다. 2단계에서는 검색에 최적화된 의미론적 세그먼트로 문서를 나누는 청킹 메커니즘을 구현하며, 3단계에서는 청킹된 데이터를 Amazon OpenSearch Service 또는 Amazon S3 Vectors에 벡터 임베딩 형태로 저장한다.

4단계에서는 Amazon Bedrock Guardrails를 통해 프롬프트 인젝션을 방지하고 사용자 쿼리를 임베딩으로 변환한다. 5단계에서 앞서 설명한 암시적·명시적 필터링을 적용해 검색 범위를 축소하며, 6단계에서는 코사인 유사도(Cosine Similarity) 메트릭을 사용하여 필터링된 서브셋 내에서 가장 관련성이 높은 청크를 검색한다. 7단계에서는 검색된 청크와 메타데이터 컨텍스트를 결합해 프롬프트를 증강하고, 8단계에서는 Amazon Bedrock LLM이 실제 계약서 문서에만 근거하여 답변을 생성한다. 마지막 9단계에서는 Retrieve API를 통해 답변의 근거가 된 소스 문서의 출처를 표기하여 환각 현상을 줄이고 검증 가능성을 확보한다.

엔터프라이즈 보안 및 컴플라이언스 제어 체계

AIDA는 데이터 전송 전 과정에 HTTPS/TLS 1.2+ 암호화 표준을 적용하여 문서 업로드, API 호출, 벡터 DB 쿼리 및 응답 전달 경로의 보안을 강제한다. Amazon Bedrock에 저장되는 데이터는 AWS 공동 책임 모델을 따르며, 벡터 데이터베이스 저장 시에는 at-rest 암호화 설정을 적용하여 데이터 유출 위험을 차단한다.

접근 제어는 AWS IAM(Identity and Access Management) 정책을 통해 관리하며, 특히 애플리케이션 계층에 프로젝트 범위의 역할(Project Scoped Roles)을 도입한 RBAC(역할 기반 액세스 제어)를 구현하여 사용자별 데이터 격리를 실현한다. 모든 API 호출과 접근 이력은 Amazon CloudWatch 로그로 기록되어 법률 데이터 처리에 필수적인 감사 추적(Audit Trails) 기능을 제공한다. 또한 Amazon Bedrock Guardrails를 통해 PII(개인식별정보) 마스킹과 콘텐츠 필터링을 수행함으로써 기업의 보안 표준과 법적 가이드라인을 준수한다.

법률 AI 설계를 위한 판단 기준 및 산출물

법률 문서 분석 시스템을 설계할 때, 단순 시맨틱 검색만으로 정답률이 낮다면 '메타데이터 필터링 $\rightarrow$ 시맨틱 검색' 순의 2단계 프로세스 도입을 검토해야 한다. 특히 관할법, 계약 유형, 갱신 주기와 같이 명확한 속성값이 존재하는 데이터셋일수록 벡터 유사도보다 메타데이터 필터링의 효용이 크다. 설계자는 어떤 속성을 메타데이터 필드로 분리할 것인지 정의하는 인제스천 설계 단계에 가장 많은 리소스를 투입해야 한다.

실무자가 가져갈 수 있는 설계 기준은 다음과 같다. 첫째, 검색 공간을 좁히기 위해 관할권 및 날짜 범위를 암시적 필터로 설정하고, 사용자 지정 조건을 명시적 필터로 처리하는 구조를 갖춘다. 둘째, 보안을 위해 IAM 프로젝트 역할 기반의 접근 제어와 Bedrock Guardrails의 PII 보호 설정을 결합한다. 셋째, LLM의 응답 신뢰도를 확보하기 위해 Retrieve API를 통한 소스 출처 표기를 필수 구현 사항으로 정의한다. 이러한 설계 기준은 LLM이 엉뚱한 문맥을 참조할 가능성을 차단하고 법적 증거로 활용 가능한 수준의 추적 가능성을 제공한다.