AWS는 대규모 임대차 자료에서 규정 준수 관련 질문을 하기 위한 Amazon Quick 참조 설계를 공개했다. 핵심은 엄격한 역할 분담이다. 채팅 모델은 고정된 도구를 선택하고 응답을 설명하며, 별도의 규칙 엔진이 대상 집단을 정의하고 각 건을 판정한다. 10월 2일 게시물과 샘플 저장소는 교육용 개념 증명이며, 검증된 법률 준수 서비스가 아니다.

엔지니어나 규정 준수 책임자에게 중요한 질문은 검토 대상 결정에 이 역할 경계가 적합한지 여부다. 샘플은 합성 임대차 계약과 만들어 낸 규칙 및 인용을 사용한다. 예시 합계는 의도된 출력 형식을 보여 줄 뿐, 실제 계약이나 법률에 대한 정확도는 말해 주지 않는다.

큰 변화

  • 무엇이 달라졌나: AWS 샘플은 AI를 고정된 검토 도구를 위한 통제된 인터페이스로 둔다. 규칙 엔진은 열거된 임대차 대상 전체에 대해 결과를 판정한다.
  • 왜 중요한가: 버전이 관리되는 규칙과 근거 기록은 검토자가 채팅 바깥에서 선택된 기록이 어떻게 평가됐는지 확인할 수 있게 한다.
  • 앞으로 볼 점: 집계 기록만으로는 목록, 정보 추출, 법률 규칙이 타당한지 검증할 수 없다. 도입자는 자체 데이터에서 이러한 입력, 사용자 식별, 성능을 확인해야 한다.

프롬프트보다 대상 집단이 먼저다

사용자는 Quick에 특정 날짜의 연체료 규칙을 위반하는 텍사스 임대차 계약이 무엇인지 물을 수 있다. Quick은 이 요청을 sweep_compliance로 전달한다. 이 작업은 이름이 정해진 여섯 개 MCP 작업 중 하나다. 지정된 관할권과 날짜를 사용해 대상 집단 및 적용할 버전별 규칙을 선택한다. 모델은 SQL을 작성하거나 조항의 통과 여부를 판정하지 않는다. 규칙 엔진은 고정된 비교 연산자를 적용하며, 규칙 값은 매개변수로 전달된다. AWS는 공식 일괄 검토 과정에서 모델을 호출하지 않는다고 말한다. AWS는 여기에서 작업 계약을 설명한다. 저장소에는 구현 방식이 설명되어 있다.

다른 도구들은 더 좁은 의미를 가진다. simulate_rule_change는 제안된 값에 대한 탐색용 건수를 계산하지만 판정 결과는 기록하지 않는다. explore_clauses는 필터링된 표본을 의미 유사도로 순위화하며 “몇 건인가?”라는 질문에는 답할 수 없다. get_finding은 하나의 증거 사슬을 가져오고, list_rules는 특정 날짜에 유효한 규칙을 보여 주며, check_connection은 연결 상태를 확인한다. 관련 조항의 표본은 전체 조사와 다르므로 이 구분이 중요하다.

일괄 검토는 검색된 모든 기록을 준수, 위반, 모호, 판독 불가 중 하나로 분류해 집계 기록을 남긴다. 규칙 엔진은 저장 전에 네 범주의 합계가 검색된 전체 건수와 일치하는지 확인한다. Quick은 건수와 작은 표본을 보여 주고, Quick Sight 대시보드는 같은 Aurora 데이터 저장소에서 전체 판정 결과를 읽는다. 각 판정에는 조항 문구, 추출된 값과 예상 값, 규칙 버전, 인용이 포함된다. 이는 AWS 샘플 설계의 속성이지, BIG CHANGE가 실행했거나 결과를 독립 검증했다는 뜻은 아니다.

집계 기록은 선택된 대상 집단의 결과를 담는다. 하지만 원본 목록에 모든 임대차 계약이 들어 있는지, 추출 과정에서 관련 조항을 빠짐없이 정확히 포착했는지, 규칙이 현행법을 반영하는지는 보여 주지 않는다. 이를 확인하려면 별도의 대조, 추출 검토, 법률 승인이 필요하다. “모든 텍사스 임대차 계약”의 분모가 불확실하다면 정확한 건수도 잘못된 집합을 설명할 수 있다.

직접 구축해야 하는 것

샘플 아키텍처에서는 AWS Lambda의 MCP 서버 앞에 Quick 채팅 에이전트를 둔다. Amazon Cognito가 서비스 토큰을 발급하고 API Gateway가 이를 검사한다. Lambda는 RDS Data API를 통해 Aurora Serverless v2에서 데이터를 읽고 쓴다. Quick Sight는 VPC 연결을 통해 같은 데이터베이스에 접근한다. AWS는 탐색용 조항 검색 도구에만 Bedrock 임베딩과 언어 모델을 사용하고, 공식 일괄 검토는 결정론적으로 처리한다.

공개된 예시에는 임대차 계약 5만 건의 합성 자료, 버전이 관리되는 규칙집, 배포된 스택에 대해 28개 검사를 실행한다고 AWS가 설명한 승인 스크립트가 있다. 저장소는 코드가 프로덕션용이 아니며, 법률 내용은 만들어 낸 것이고, 실제 임차인 데이터에는 추가 보안 시험과 독립적인 법률 검증이 필요하다고 명시적으로 경고한다. 문서와 저장소 설명을 살펴봤지만 스택을 배포하거나 검사를 실행하지 않았고, 채팅 에이전트의 도구 라우팅도 시험하지 않았다.

이를 적용하려면 먼저 기준이 되는 기록 목록과 정확한 포함 규칙을 정한다. 그런 다음 어떤 필드를 안정적으로 추출할 수 있는지, 어떤 규칙 비교가 실제로 기계적으로 처리 가능한지, 각 규칙 버전을 누가 승인할지 결정한다. 검토자가 결과를 재구성할 수 있도록 원문, 추출 상태, 규칙 버전, 작업자, 비교 값, 날짜, 판정 ID를 보존한다. 집계 기록은 채팅 응답과 별도로 기준 목록과 대조한다. 이는 샘플이 명시한 보장과 한계에서 도출한 설계 점검 항목이며, 우리가 시험한 단계는 아니다.

AWS에 따르면 Cognito의 클라이언트 자격 증명 토큰은 채팅에서 질문하는 개인이 아니라 Quick 애플리케이션을 식별한다. 샘플은 일괄 검토 ID와 시간을 Quick의 감사 계층과 대조해 사용자를 식별한다. 규정 준수 저장소 자체에 사용자 식별 정보를 기록해야 하는 경우 AWS는 최종 사용자의 ID를 전달해 저장하는 방법을 제안한다. 각 판정 자체를 독립된 감사 기록으로 남겨야 하는 팀은 배포 전에 이 설계를 확정해야 한다.

접근, 한계, 비용

AWS 안내서는 AWS 계정, 설정된 AWS CLI v2 자격 증명, CDK용 Python과 Node 24, us-east-1의 모델 접근 권한, MCP 커넥터와 Quick Sight를 갖춘 Amazon Quick 환경을 전제로 한다. 게시물은 Python 3.12를 안내하지만 링크된 README는 Python 3.9 이상이라고 적는다. 로컬 환경을 선택할 때 저장소의 최신 요구 사항을 확인해야 한다. 샘플 지침은 CDK CLI 2.261.0을 고정하지만, 이는 샘플의 의존성 버전이지 일반적인 AWS 요구 사항은 아니다.

현재 Quick MCP 가이드에 따르면 각 작업의 시간 제한은 60초이며 서버 연결 하나에 도구를 최대 100개까지 둘 수 있고 사용자 지정 HTTP 헤더는 전송되지 않는다. 대규모 일괄 검토에는 이 시간 제한을 고려한 부하 시험이 필요하다. 데이터베이스 작업이 정확하더라도 커넥터 한도를 넘으면 동기식 Quick 작업으로 완료할 수 없다. 가이드에는 사용자 지정 커넥터의 도구 목록을 Sync로 업데이트할 수 있다고 나와 있다. 반면 AWS 블로그와 샘플 README는 도구를 변경한 뒤 통합을 삭제하고 다시 만들라고 안내한다. 현재 커넥터에 적용되는 최신 Quick 문서를 따르고, 자체 환경에서 등록된 도구 목록과 라우팅을 확인해야 한다.

여러 서비스를 함께 구축하므로 공개 자료만으로 방어 가능한 단일 “일괄 검토당 가격”을 산정할 수 없다. AWS의 Quick 요금 페이지는 구독 및 에이전트 시간 요금을 구분하며, 일부 기능에는 Quick Sight 추가 요금이 있다고 안내한다. Aurora 요금은 용량, 저장 공간, I/O 구성에 따라 달라진다. 샘플은 최소 0.5 ACU를 활성 상태로 유지하며 0으로 일시 중지하지 않는다. API Gateway, Lambda, 탐색을 위한 Bedrock 호출에도 작업량 추산이 필요하다. 저장소는 지속적인 요금을 피하려면 평가 후 스택을 삭제하라고 권고한다. 이 기사를 위해 AWS 리소스를 생성하지 않았다.

의사결정 점검표

이 방식을 쓰기 전에 팀은 자체 데이터와 통제 방식을 바탕으로 다음 질문에 답할 수 있어야 한다.

  • 검토를 거친 안정적인 조건으로 전체 대상 집단을 열거하고 기준이 되는 목록과 대조할 수 있는가?
  • 규칙은 승인된 버전, 시행일, 인용을 갖춘 기계적 비교인가? 사람이 검토하도록 어떤 사례를 모호한 상태로 남겨야 하는가?
  • 추출 실패와 읽을 수 없는 문서를 조용히 제외하지 않고 건수로 집계할 수 있는가?
  • 각 판정에 원본 조항, 비교 값, 규칙 버전이 남으며, 채팅 바깥에서 전체 증거 묶음을 가져올 수 있는가?
  • 일괄 검토가 Quick의 작업 시간 제한 내에 끝날 수 있는가? 결과를 요청한 사람까지 어떻게 추적할 것인가?
  • 예상 사용량에 대한 구독료, 데이터베이스 및 서비스 요금을 추산하고 허가된 데이터로 성능과 결과 품질을 시험했는가?

작업에 법률 해석이나 개방형 기준에 대한 판단이 필요하다면 결정론적 통과/실패 표시가 오히려 사람의 판단이 필요한 지점을 가릴 수 있다. 대표적인 사례를 찾으려는 목적이라면 의미 기반 검색이 더 간단하다. 검토된 규칙 엔진과 대시보드가 이미 책임 있는 사용자에게 제공되고 있다면 대화형 계층은 선택 사항이다. 이러한 대안은 AWS 게시물 자체의 “잘못된 선택” 논의와 합성 샘플의 한계에서 나온다.

출처 및 추가 읽을거리