🥚

Recent Notes

See 630 more →

Built Technologies가 부동산 금융 문서를 지능화한 방식

씀9 min read

부동산 금융에서 AI가 읽어야 하는 건 깔끔한 표 하나가 아니야. 대출 계약서, 공사비 청구 묶음, 보험 증명서, 감정평가서가 서로 다른 형식으로 쌓이고, 한 거래에 수백~수천 쪽이 붙기도 해. Built Technologies는 2026년 7월 15일 AWS 블로그에서 이런 문서를 처리하는 엔진을 만들었다고 소개했어. 회사가 처리하는 부동산 프로젝트 규모는 5,000억 달러가 넘는다고 밝혔고.1

핵심은 문서에서 글자를 뽑는 데서 멈추지 않는다는 거야. Built는 250종이 넘는 문서 유형과 수백 쪽짜리 파일을 다루기 위해, 문서를 분류하고 나누고, 필요한 값을 뽑고, 결과를 평가하고, 근거와 함께 검토하는 재사용 기반을 만들었어. 이전에는 OCR과 전통적인 머신러닝으로 26개의 처리기를 운영했지만, 명시적인 필드와 일정한 레이아웃을 벗어나면 한계가 있었지.2

단어를 찾는 것과 뜻을 읽는 것은 다르다

대출 계약서에서 대출 금액이나 만료일을 찾는 일은 비교적 단순해. 보통 이름 붙은 필드 근처에 값이 있으니까. 반면 covenant는 문서에 Covenants라는 표제로 모여 있지 않을 수 있어. 차주의 의무, 재무 보고, 제한, 채무불이행 조건처럼 여러 조항에 흩어져 있고, 다른 조항을 참조하며 의미가 완성되기도 해.3

그래서 Built가 말하는 에이전트형 문서 흐름은 키워드 검색보다 한 단계 더 들어가. 문서 구조를 파악하고 관련 조항을 찾아, 어떤 의무인지·기준값은 무엇인지·얼마나 자주 지켜야 하는지·어기면 어떤 결과가 생기는지를 구조화해. 결과에는 원문 근거를 붙이고, 확신이 낮거나 애매한 경우에는 전문가에게 넘기며, 사람이 고친 내용은 스키마와 평가 과정에 다시 반영해.4 이 구조는 agentic workflow가 말하는 도구 사용·검증·사람 개입의 결합과 닮아 있어.

한 제품이 아니라 공통 기반으로 만들었다

첫 번째 실제 적용처는 상업용 건설 대출의 draw package였어. 한 PDF 안에 청구서, lien waiver, 보험 증명서, 표지 문서가 순서 없이 섞여 들어오는 상황이지. Built는 이 묶음을 문서별로 나눈 뒤, 각각에 맞는 추출 규칙을 적용하는 방식으로 시작했어.5

하지만 목표는 건설 대출 하나가 아니야. 같은 기반을 대출 계약서의 의무 조항 확인, 보험 보장 범위 검증, 투자심사 자료 요약, 자산관리 보고서의 변화 감지, 규제 서류 검사에도 재사용하려고 해. 문서 종류마다 별도 처리기를 처음부터 다시 만드는 대신, 입력·분류·스키마·추출·평가·사람 검토를 공유하는 거지.6

이렇게 보면 이 사례의 중심은 “문서를 읽는 AI”보다 문서 이해를 여러 업무에 공급하는 공통 계층에 있어. 회사가 새 에이전트를 추가할 때마다 문서 처리의 바닥부터 다시 짓지 않아도 된다는 뜻이야. 다만 AWS 블로그는 Built가 이 기반으로 실제 각 업무의 정확도나 비용을 얼마나 개선했는지까지는 공개하지 않아. 기능을 만들었다는 사실과 제품 성과는 구분해서 봐야 해.

AWS 위에서 문서가 흘러가는 순서

Built는 AWS Intelligent Document Processing Accelerator를 바탕으로 Amazon Bedrock과 여러 AWS 서비스를 묶었어. 전체 흐름은 OCR, 문서 분류·분할, 추출, 평가, 선택적 규칙 검증 순서로 AWS Step Functions가 조정하고, 각 단계는 AWS Lambda가 맡아.7

예시로 든 150쪽짜리 건설 대출 묶음은 Amazon S3에 올라온 뒤 이벤트와 큐를 거쳐 처리돼. 문서가 여러 조각으로 나뉘면 Step Functions의 Map 상태에서 각 조각을 병렬로 추출해. 그래서 전체 처리 시간은 모든 문서를 순서대로 더한 값보다 가장 오래 걸리는 조각에 가까워지고, AWS 글은 과거 며칠 걸리던 작업이 몇 분으로 줄었다고 설명해.8

여기서 중요한 건 모델 하나의 성능만이 아니야. 새 문서 유형의 예시를 올리면 Bedrock이 추출 스키마 초안을 만들고, 업계 전문가는 필드 설명과 예시를 다듬어 새 처리기 버전을 만들 수 있어. 문서를 가장 잘 아는 사람이 엔지니어링 팀 밖에 있을 수 있다는 현실을 화면과 검토 흐름에 넣은 셈이지.9

아직 남은 질문은 분명해. 95%가 넘는 분류·추출 신뢰도를 생산 환경의 요구 조건으로 삼았다고 했지만, 그 수치가 어떤 문서 표본과 평가 방식에서 나온 것인지는 이 글에서 확인할 수 없어. 또 “며칠에서 몇 분”이라는 시간 개선이 모든 문서 유형에 해당하는지도 알 수 없지. 다음에는 실제 고객 환경에서 어떤 유형의 문서가 사람 검토 없이 통과하는지, 애매한 결과가 얼마나 자주 전문가에게 돌아오는지를 봐야 해.

각주

  1. AWS, 「Built Technologies builds an AI-powered document intelligence solution on AWS to power agents across real estate finance」(2026-07-15) 원문. ↩︎

  2. 같은 글에서 Built의 기존 26개 처리기, 250종이 넘는 문서 유형, 500쪽을 넘을 수 있는 개별 문서, 95% 초과 신뢰도 요구를 설명해. ↩︎

  3. AWS, 「Built Technologies builds an AI-powered document intelligence solution on AWS to power agents across real estate finance」의 ‘From OCR-based extraction to agentic document understanding’ 절. ↩︎

  4. 같은 글의 대출 계약서 문서 이해 흐름 설명. ↩︎

  5. 같은 글의 ‘A horizontal solution for the Built Technologies agentic AI roadmap’ 절. ↩︎

  6. 같은 글의 draw review·loan agreement·insurance·underwriting·asset management·compliance agent 설명. ↩︎

  7. 같은 글의 ‘Architecture deep dive: Intelligent Document Processing Accelerator and Amazon Bedrock’ 절. ↩︎

  8. 같은 글의 Step Functions Map 상태와 150쪽 draw package 처리 예시. ↩︎

  9. 같은 글의 dynamic schema generation 및 문서 검토 화면 설명. ↩︎

Graph

Backlinks

댓글