Building an AI-powered contract intelligence platform with Amazon Quick and Amazon Bedrock AgentCore

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

AWS의 계약 인텔리전스 플랫폼은 Amazon Bedrock AgentCore 기반 AI 에이전트로 계약 PDF를 구조화·검증하고, Amazon Quick으로 포트폴리오 전체 집계와 개별 계약 질의를 하나의 웹 애플리케이션에서 제공한다.

📌 핵심 요약

• 250개의 계약이 각각 10~20쪽이면 최대 5,000쪽을 분석해야 하며, 수작업으로 초기 적체를 처리하는 데 일주일 이상이 걸린다. 상위 k개 텍스트 조각만 검색하는 RAG는 개별 조항 조회에는 적합하지만 전체 계약의 합계·개수·비교에는 한계가 있다.
• 계약 PDF를 Amazon S3에 저장하면 자동 처리 파이프라인이 실행된다. 추출 에이전트는 신뢰도 점수와 함께 8개 핵심 필드를 추출하고, 별도 검증 에이전트가 확인한 결과를 Amazon Aurora PostgreSQL에 저장한다.
• 추출에는 Claude Sonnet 4.6, 검증에는 Claude Haiku 4.5를 사용한다. 두 모델이 is_signed 필드에서 불일치하면 Amazon Textract가 서명 탐지의 판정 기준을 제공하며, 시험 중 검증 모델이 빈 서명란을 실제 서명으로 오인하면서 95~100% 신뢰도를 제시한 사례가 있었다.
• Strands Agent SDK로 구축한 에이전트는 Amazon Bedrock AgentCore 런타임에서 실행되며, 서버리스 호스팅·자동 확장·세션 격리를 지원한다. AgentCore Policy로 계약 접근 권한을 통제할 수 있고, React 애플리케이션은 WebSocket으로 처리 상태를 실시간 제공하며 일반적인 조건에서 계약 한 건을 수초 안에 처리할 수 있다.
• 20개 계약의 8개 필드, 총 160개 값을 수작업으로 표시한 소규모 평가에서는 추출 모델의 역량이 정확도에 더 큰 영향을 미쳤고, 더 강력한 검증 모델의 추가 이점은 뚜렷하지 않았다. Amazon Quick은 구조화 데이터의 집계와 원문 지식베이스의 개별 조회를 연결하고 Amazon Quick Sight 대시보드를 내장하며, 모델 가용성과 계약 특성에 맞춘 재평가가 권고된다.

🧩 주요 포인트

1. RAG의 검색 범위 제한 → 전체 계약 집계는 구조화 데이터와 데이터베이스에 맡기고, 개별 조항 조회는 원문 지식베이스로 처리하는 역할 분담이 핵심이다.
2. Claude Sonnet 4.6·Claude Haiku 4.5의 교차 검증과 Amazon Textract의 서명 판정 → 높은 신뢰도만으로 오류를 배제할 수 없으며, 불일치는 추가 검토의 신호가 된다.
3. 개 계약 평가와 Amazon Bedrock AgentCore·Amazon Quick의 결합 → 추출 정확도와 비용을 실제 계약으로 검증하면서 처리·접근 통제·분석을 하나의 애플리케이션으로 연결한다.

🧠 상세 정리

1. 계약 포트폴리오에서 반복되는 수작업의 부담

계약 담당자는 수백 또는 수천 개 공급업체 계약에 담긴 계약 금액, 만료일, 서명 상태, 주요 연락처를 관리하지만, 정보가 PDF에 묶여 있어 추출과 스프레드시트 유지에 많은 시간을 쓴다. 원문은 250개 계약이 각각 10~20쪽인 상황을 제시하며, 분석 대상이 최대 5,000쪽에 이를 수 있다고 설명한다. 경영진이 묻는 전체 계약 금액, 이미 만료된 계약, 가장 비싼 계약, 가장 최근 서명된 계약에 답하려면 분석가는 각 PDF를 열어 필요한 값을 옮기는 작업을 250번 반복해야 한다. 초기 적체를 해소하는 데만 일주일 이상이 걸리고, 후속 질문마다 다시 필터링하고 분석하면서 오래된 데이터나 새 데이터에 맞지 않는 고정 수식에 의존할 위험이 생긴다. AI 채팅 도구는 한두 문서에서는 유용하지만, 전체 포트폴리오의 총액을 물으면 빠르고 자신 있게 잘못된 답을 반환할 수 있다는 것이 글의 출발점이다.

2. RAG가 잘하는 조회와 전체 집계의 차이

원문에서 설명하는 RAG는 문서를 작은 텍스트 조각으로 나누고 벡터로 색인한 뒤, 질문과 가장 관련 있는 상위 k개 조각만 검색해 답변의 문맥으로 제공한다. AnyCompany 계약의 지급 조건처럼 답이 특정 조항에 있는 질문에서는 이 방식이 적합하며, 필요한 조각을 찾아 명확한 답을 만들 수 있다. 그러나 250개 계약 전체의 금액을 합산하는 질문에서도 일부 조각만 반환되므로, 모델은 전체 포트폴리오를 보지 못한 채 검색된 값만 더하게 된다. 글은 이러한 합계·개수·비교의 한계를 특정 도구의 우연한 실패가 아니라 해당 검색 구조의 한계로 설명하며, 프롬프트 개선만으로 해결할 수 없다고 주장한다. 대안은 AI로 핵심 필드를 데이터베이스에 구조화하고 수학적 연산은 분석 도구에 맡기는 것이며, 원문 지식베이스는 개별 계약 조회를 위해 계속 유지한다.

3. PDF 업로드에서 검증된 데이터 저장까지

제안된 플랫폼은 AWS에서 실행되는 React 웹 애플리케이션으로, 계약 PDF를 구조화된 질의 가능 데이터로 바꾸고 분석과 자연어 질문을 같은 화면에서 제공한다. 계약 PDF를 Amazon S3 버킷에 저장하면 자동 처리 파이프라인이 시작되고, 추출 에이전트가 각 계약에서 8개 핵심 필드를 필드별 신뢰도 점수와 함께 추출한다. 별도 검증 에이전트는 같은 PDF를 독립적으로 읽어 추출 결과를 확인하며, 서명 탐지에 의견 차이가 있으면 Amazon Textract가 판정 기준을 제공한다. 검증된 결과는 Amazon Aurora PostgreSQL에 저장되고, 사용자는 WebSocket으로 처리 상태를 실시간 확인한 뒤 내장 대시보드와 자연어 채팅 에이전트로 데이터를 질의할 수 있다. 원문은 일반적인 조건에서 계약 한 건을 수초 안에 처리할 수 있고 서버리스 구조가 여러 계약의 병렬 처리를 지원하도록 설계됐다고 설명하지만, 구체적인 처리량이나 보장된 성능 수치는 제시하지 않는다.

4. AgentCore의 실행 환경과 계약 접근 통제

추출과 검증 에이전트는 오픈소스 모델 중심 프레임워크인 Strands Agent SDK로 구축되고, Amazon Bedrock AgentCore의 기능인 AgentCore 런타임에 배포된다. AgentCore는 서버리스 호스팅, 자동 확장, 세션 격리를 처리하므로 AI 구성요소의 인프라를 직접 관리할 필요를 줄인다. 또한 Amazon Bedrock AgentCore의 Policy를 사용하면 에이전트 작업 주변에 보안 경계를 정의하고 적용해 가격 조건, 재무적 약정, 공급업체 관계 같은 민감한 정보를 보호할 수 있다고 설명한다. Cedar 기반 정책은 에이전트 코드 밖에 존재하며, 적용 전에 자동 추론으로 검증할 수 있고 에이전트와 사용자의 계약 접근을 권한 범위로 제한할 수 있다. 이 부분의 핵심은 문서 처리 기능뿐 아니라 관리형 실행 환경과 접근 통제를 함께 구성하는 것이며, 실제 정책 정의나 개별 권한 설정의 상세 내용은 원문에 제시되지 않는다.

5. 서로 다른 모델을 사용하는 추출과 검증

원문은 추출과 검증에 서로 다른 기반 모델을 의도적으로 선택하며, 구체적으로 추출에는 Claude Sonnet 4.6, 검증에는 Claude Haiku 4.5를 사용한다. Claude Sonnet 4.6은 문서 이해 역량을 바탕으로 OCR 전처리 없이 전체 PDF를 직접 읽고, 각 필드의 신뢰도 점수가 포함된 구조화 JSON을 반환한다. Claude Haiku 4.5는 빠르고 비용 효율적인 검증 모델로 설명되며, 다른 모델과 학습에 기반한 관점이 같은 모델을 재실행할 때 놓칠 수 있는 오류를 발견하는 데 도움이 된다는 것이 저자들의 선택 근거다. 한 모델이 높은 신뢰도로 잘못된 값을 만들어 낼 수 있으므로, 두 모델의 불일치는 사람의 검토가 필요하다는 강한 신호로 다뤄진다. 다만 모델 선택지는 빠르게 바뀌고 AWS 리전별 가용성도 다르므로, 원문은 구축 시점에 사용할 수 있는 모델을 선택하고 결과에 의존하기 전에 다시 시험할 것을 권고한다.

6. 빈 서명란 오인을 해결하는 Amazon Textract

시험 과정에서 검증 모델은 실제 서명이 없는 계약을 서명된 것으로 판정하면서 95~100%의 신뢰도를 제시하는 경우가 있었고, 올바르게 미서명으로 읽은 추출 모델과 충돌했다. 원문은 검증 모델이 'Signature: __________'처럼 비어 있는 서명란의 존재를 실제 서명의 증거로 오인한 것이 원인이라고 설명한다. 저자들은 이 오류를 수용하거나 복잡한 프롬프트로 우회하는 대신, 컴퓨터 비전 기반의 Amazon Textract 서명 탐지를 구조적 판정 수단으로 추가했다. Amazon Textract는 언어적 해석이 아니라 페이지의 시각적 분석으로 실제 필기 또는 디지털 서명을 탐지하며, 두 모델이 is_signed 필드에서 불일치할 때만 실행돼 비용을 최소화하면서 거짓 양성을 잡도록 구성된다. 글은 이를 문서 이해와 문맥 해석에는 LLM을 활용하고, 시각 요소 탐지·정확한 계수·수학적 연산처럼 LLM이 어려워하는 작업에는 결정적 서비스를 배치하는 설계 원칙의 사례로 제시한다.

7. 20개 계약 평가가 보여 준 선택 기준과 한계

저자들은 추출 모델이 전체 정확도에 가장 큰 영향을 미친다고 보고 여러 추출·검증 모델 조합을 시험한 뒤 최종 조합을 선택했다. 평가에는 20개 계약의 표본 데이터셋을 사용했으며, 계약마다 8개 필드를 수작업으로 표시해 총 160개 값의 정답 기준을 만들고 모델 조합의 결과와 비교했다. 역량이 높은 추출 모델은 가벼운 검증 모델과 결합해도 정확도를 유지했지만, 가벼운 추출 모델을 쓰면 검증 모델과 관계없이 정확도가 낮아지는 경향이 나타났다. 반면 가장 강력한 모델들은 이 데이터에서 역량을 갖춘 저비용 검증 모델보다 의미 있게 더 나은 결과를 내지 않아, 추가 역량이 항상 비용을 정당화하지는 않는다는 관찰이 제시됐다. 원문은 이를 20개 계약에 대한 방향성 확인용 소규모 시험으로 한정하고, 계약 형식과 필드 복잡도에 따라 결과가 달라질 수 있으므로 자체 기준과 성공 조건에 맞춘 평가를 강하게 권고한다.

8. Amazon Quick의 통합 질의와 내장 대시보드

추출과 검증 이후에는 사용자가 전체 포트폴리오의 합계와 개별 계약의 세부 내용을 모두 물을 수 있어야 하며, Amazon Quick은 구조화된 레코드와 원문 문서를 하나의 인터페이스로 연결한다. PostgreSQL의 구조화 데이터와 Topics는 전체 계약 금액 같은 집계 질문을 처리하고, 원문은 '20개 계약에 걸쳐 5,000만 달러'라는 답변을 예시로 제시한다. 개별 문서 질문은 지식베이스를 통해 처리하며, AnyCompany 계약의 지급 조건을 물으면 원본 PDF에서 정확한 조항을 가져오는 방식으로 설명된다. Amazon Quick Sight 대시보드는 Amazon Quick Sight Embedding SDK를 통해 React 애플리케이션에 직접 내장되므로, 사용자는 애플리케이션 안에서 별도 내보내기나 다른 BI 도구 없이 계약 분석을 이용할 수 있다. 제공된 원문은 추가 비용을 수반하는 SPICE 캐싱을 피한다는 설명 도중에 끝나므로, 이후에 사용한 데이터 조회 방식이나 나머지 구현 내용은 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 계약 전체를 대상으로 하는 질문의 정확도는 검색 문맥을 늘리는 문제보다, 필요한 필드를 빠짐없이 구조화해 집계할 수 있는 데이터 구조를 만드는 문제와 연결된다.
• 95~100% 신뢰도로 나타난 서명 오인은 모델의 확신이 정확성을 보장하지 않음을 보여 주며, 서로 다른 모델의 불일치와 시각 분석 서비스를 함께 활용할 이유를 제공한다.
• 20개 계약 평가에서는 추출 모델의 역량이 더 큰 영향을 미쳤지만, 표본이 작고 계약 형식에 따라 결과가 달라질 수 있어 특정 모델 조합의 우수성을 일반화하기 어렵다.

✅ 액션 아이템

• RAG 기반 개별 조항 조회와 구조화 데이터 기반 전체 계약 집계를 구분해 질의 처리 방식을 설계한다.
• Claude Sonnet 4.6·Claude Haiku 4.5의 is_signed 불일치에 Amazon Textract를 적용하고, 모델 간 불일치를 추가 검토의 신호로 활용한다.
• 20개 계약·160개 값의 평가 한계를 고려해 실제 계약 특성과 모델 가용성에 맞춰 추출 정확도와 검증 비용을 재평가한다.

❓ 열린 질문

• 전체 계약 집계에 필요한 값이 구조화 데이터에 빠짐없이 반영됐는지는 어떻게 확인할 수 있는가?
• Claude Sonnet 4.6과 Claude Haiku 4.5가 is_signed 외의 필드에서 불일치할 때 추가 검토는 어떻게 진행되는가?
• 20개 계약·160개 값에서 관찰한 추출 정확도와 검증 비용의 관계는 다른 계약 형식에서도 유지되는가?