# 계약서를 검색 가능한 재무 데이터로 바꾼 OpenAI Contract Data Agent / DocuGPT
개요
OpenAI는 2025년 9월 29일, 자사 finance와 engineering 팀이 계약 검토 병목을 줄이기 위해 만든 Contract Data Agent 사례를 공개했습니다.[1] 공개 사례의 핵심은 계약서를 요약하는 챗봇이 아니라, PDF·스캔본·휴대폰 사진·손글씨 수정본을 인입해 구조화 데이터와 원문 근거를 만들고, finance 전문가가 승인한 결과를 data warehouse에서 조회할 수 있게 만든 운영 흐름입니다.[1] 공개 자료에 따르면 리뷰 시간은 절반으로 줄었고, 수천 건의 계약을 headcount 증가와 선형으로 묶지 않고 처리할 수 있게 됐습니다.[1] 이 글은 OpenAI가 공개한 사실과, 유사 기업이 구현할 때 검토할 수 있는 레퍼런스 아키텍처·운영 통제를 분리해 정리합니다.
1. 사례의 핵심: 계약 검토에서 계약 데이터 운영으로
OpenAI 사례는 계약량 증가에서 출발합니다. 공개 글은 finance team이 수개월 안에 매월 수백 건에서 1,000건 이상의 계약을 검토해야 하는 상황이 됐고, 새로 채용한 인원은 한 명뿐이었다고 설명합니다.[1] 이 문제는 “계약서를 더 빨리 읽습니다”만으로 해결되지 않습니다. 시작일, billing terms, renewal clauses, non-standard terms, ASC 606 classification처럼 재무 판단에 영향을 주는 필드를 반복적으로 찾고, 그 판단 근거를 다시 설명할 수 있어야 합니다.
공개 사례에서 확인되는 agent 흐름은 세 단계입니다.[1]
| 단계 | 공개 사례에서 확인되는 내용 | 운영 설계상의 의미 | | --- | --- | --- | | Ingest data | PDFs, scanned copies, phone photos, handwritten edits가 하나의 pipeline으로 들어옵니다. | 계약 원본, OCR 결과, 문서 버전, 인입 출처를 분리해 보관해야 합니다. | | Inference with prompting | Retrieval-augmented prompting으로 관련 부분만 가져와 구조화합니다. | 전체 계약을 무작정 context에 넣기보다 필드별 관련 조항을 찾아야 합니다. | | Review | Finance expert가 annotations, references, non-standard terms를 보고 검토합니다. | AI output은 승인 전 초안이며, 승인된 값만 downstream system으로 이동해야 합니다. |
따라서 Contract Data Agent의 본질은 “계약서 질의응답”보다 “계약 파일을 검증 가능한 재무 데이터로 바꾸는 업무 시스템”에 가깝습니다. AI는 계약 조건을 최종 결정하지 않습니다. 사람이 판단해야 할 비표준 조항과 수익 인식 분류를 더 빨리 찾고, 그 판단 근거를 함께 제시합니다.
2. 사용된 AI 기술과 데이터 경계
OpenAI 공개 자료는 내부에서 사용한 모든 API와 모델명을 공개하지 않습니다. 다만 공개 사례와 현재 OpenAI API 문서를 기준으로, 유사 시스템의 기술 구성은 다음처럼 해석할 수 있습니다.
| 기술 요소 | 공개 또는 공식 문서상 근거 | Contract Data Agent에서의 역할 | | --- | --- | --- | | Retrieval-augmented prompting | OpenAI 사례는 agent가 필요한 부분만 가져와 reasoning한다고 설명합니다.[1] OpenAI File Search 문서는 업로드한 파일의 knowledge base에서 semantic/keyword search로 관련 정보를 가져오는 도구를 설명합니다.[2] | billing, renewal, termination, ASC 606, non-standard terms처럼 필드별 관련 조항 후보를 좁힙니다. | | Structured extraction | OpenAI 사례는 tabular output과 structured data를 언급합니다.[1] | 값, confidence, 판단 근거, page 또는 clause reference를 같은 schema로 저장합니다. | | Function/tool boundary | OpenAI Function Calling 문서는 모델을 애플리케이션 데이터와 action에 연결하는 방식을 설명합니다.[3] | warehouse sync, ticket creation, reviewer task 생성 같은 action은 schema와 권한 정책으로 제한합니다. | | Human-in-the-loop | OpenAI 사례는 finance expert가 검토하고 확정하는 구조를 설명합니다.[1] | 승인 전 데이터와 승인 후 데이터를 분리하고, reviewer correction을 eval item으로 되돌립니다. | | Cost and model routing | OpenAI 가격표는 모델별 input/output token 단가를 제공합니다.[4] | 문서 길이, retrieval 폭, field 수, 모델 조합에 따라 비용이 달라지므로 파일럿부터 token budget을 기록합니다. |
중요한 경계는 공개 사실과 구현 추론을 구분하는 것입니다. OpenAI가 공개한 것은 내부 사례의 업무 흐름과 결과입니다. 아래에서 제시하는 AWS 서비스명, queue, index, warehouse 구성은 유사 기업이 구축할 때 검토할 수 있는 레퍼런스 아키텍처이며, OpenAI 내부 인프라를 묘사한 것이 아닙니다.
3. 공개 사례에서 확인되는 업무 흐름
유사한 계약 데이터 agent는 다음 순서로 설계할 수 있습니다.
| 단계 | 입력과 처리 | 통제 지점 | | --- | --- | --- | | 계약 인입 | CLM, e-signature, CRM, 이메일, object storage에서 계약 원본을 받습니다. | contract ID, customer ID, document version, source system을 기록합니다. | | 문서 정규화 | OCR과 text extraction으로 PDF, scan, photo, handwritten edit를 텍스트와 page span으로 바꿉니다. | OCR 실패, 낮은 해상도, 표 구조 손실, 중복 문서를 별도 상태로 분리합니다. | | 조항별 retrieval | billing, renewal, discount, termination, non-standard terms, ASC 606 관련 후보 조항을 검색합니다.[1][2] | 검색 근거와 누락 가능성을 reviewer에게 보입니다. | | 구조화 추출 | 모델이 field value, reasoning, confidence, citation을 schema로 반환합니다. | JSON schema validation, confidence threshold, citation 존재 여부를 검사합니다. | | 전문가 검토 | Finance reviewer가 근거 조항을 보고 승인·수정·거절합니다.[1] | 승인 전 값은 warehouse나 BI의 정본으로 쓰지 않습니다. | | 승인 데이터 적재 | 승인된 필드만 data warehouse와 BI에 동기화합니다.[1] | load job, idempotency key, rollback 또는 correction workflow를 둡니다. | | 품질 환류 | reviewer correction을 eval set, prompt, retrieval rule 개선에 반영합니다. | field별 error taxonomy와 regression test를 유지합니다. |
이 구조에서 가장 중요한 데이터는 최종 field value 하나가 아닙니다. 원문 문서 버전, source page, 근거 조항, reviewer decision, model/prompt version, warehouse load timestamp가 함께 남아야 합니다. 그래야 감사, revenue operation, 계약 예외 분석에서 “왜 이 값이 이렇게 분류됐는지”를 설명할 수 있습니다.
4. 구현 가능한 시스템 아키텍처
아래 아키텍처는 OpenAI 내부 구성이 아닙니다. 공개 사례의 논리 흐름을 AWS 관리형 서비스 위에 올린다면 검토할 수 있는 예시입니다. Amazon Bedrock 같은 managed AI platform은 production agent와 보안·거버넌스 요구를 묶는 한 가지 선택지이며, 같은 패턴은 OpenAI API, 다른 cloud, 또는 사내 격리 환경으로도 옮길 수 있습니다.[7]
| 논리 단계 | AWS 서비스 예시 | 역할 | | --- | --- | --- | | Contract intake | S3 Landing Bucket, EventBridge, SQS | 원본 계약 파일을 적재하고 비동기 처리 이벤트를 만듭니다. | | Document normalization | Amazon Textract, ECS Fargate | 스캔본·사진·손글씨 수정본을 OCR/text span으로 정규화합니다. | | Orchestration | Step Functions, SQS DLQ | 단계별 retry/catch, 재처리, 실패 상태를 관리합니다. | | Retrieval and extraction | OpenSearch, Bedrock 또는 OpenAI API | 조항 후보 검색, field extraction, citation 생성을 수행합니다.[2][7] | | Extracted data store | DynamoDB, S3 | field value, confidence, citation, document span, review status를 저장합니다. | | Review | CloudFront, S3, ALB, ECS Fargate, Cognito | finance reviewer UI/API와 인증을 제공합니다. | | Warehouse and BI | Redshift, QuickSight | 승인된 계약 필드를 분석 가능한 테이블로 제공합니다. | | Security and audit | IAM, KMS, CloudTrail, CloudWatch | 권한, 암호화, 감사 로그, 모니터링을 전 구간에 적용합니다. |
레퍼런스 아키텍처에서 핵심 경로는 contract → OCR/text span → clause retrieval → structured extraction → reviewer approval → warehouse입니다. Bedrock이나 OpenAI API가 warehouse에 직접 쓰는 구조가 아니라, worker가 model output을 schema와 citation 기준으로 검증한 뒤 승인 흐름에 넘기는 구조가 안전합니다.
5. 프로덕션 설계에서 보완할 점
승인 전 데이터와 승인 후 데이터를 분리합니다
계약 agent가 생성한 값은 초안입니다. 청구 조건, 갱신 조건, 할인 조건, termination clause, revenue classification은 재무 보고와 고객 계약 해석에 영향을 줄 수 있습니다. 승인 전 값은 proposed 상태로 두고, finance reviewer가 근거 조항을 확인한 뒤 approved 상태로 전환해야 합니다. warehouse, BI, revenue workflow에는 승인된 값만 들어가야 합니다.
Citation 없이는 field를 확정하지 않습니다
OpenAI 사례는 non-standard terms에 reasoning과 references를 함께 제시한다고 설명합니다.[1] 이 원칙은 실제 설계에서도 핵심입니다. 값만 맞아 보여도 근거 page, clause span, source document version이 없으면 감사와 correction이 어렵습니다. OCR이 불완전하거나 조항이 여러 문서 amendment에 흩어져 있으면 “확정 불가” 상태를 만드는 편이 안전합니다.
Tool action은 읽기와 쓰기를 나눕니다
Function calling은 모델이 애플리케이션의 데이터와 action에 접근하게 해주는 강력한 패턴입니다.[3] 그러나 계약·재무 workflow에서는 excessive agency가 바로 위험이 됩니다. contract lookup, clause search, field proposal은 read-only 또는 proposal action으로 시작하고, warehouse update, billing workflow update, customer notice, revenue recognition flag 변경은 사람 승인과 별도 policy engine을 통과해야 합니다.
보안·감사·평가를 설계 산출물로 둡니다
NIST AI RMF는 AI 시스템의 신뢰성, 평가, 위험 관리를 설계·개발·운영 전반에 통합하도록 권고합니다.[5] OWASP LLM Top 10도 prompt injection, sensitive information disclosure, excessive agency, unbounded consumption 같은 위험을 명시합니다.[6] 계약 agent에는 최소한 문서 접근 권한, retrieved context logging, prompt/tool versioning, reviewer override reason, idempotency key, rate limit, DLQ, retention policy가 필요합니다.
6. 구축 및 운영 비용
OpenAI 내부 운영비, model routing, 계약당 token 사용량은 공개되지 않았습니다. 따라서 비용은 다음 가정을 명시한 planning estimate로만 다루는 편이 안전합니다.
- 가정: 1,000 contracts/month, 계약당 평균 50-150 pages, OCR 후 계약당 150,000 input tokens와 3,000 output tokens, 1-2회의 extraction/review pass.
- 모델 비용: 2026년 7월 7일 접근 기준 OpenAI 가격표의 short context 단가를 단순 적용하면, 1,000건 × 150,000 input tokens × 3,000 output tokens 규모에서 텍스트 모델 비용은 gpt-5.4-mini 약 $63/month, gpt-5.4 약 $210/month 수준입니다.[4]
- 제외: OCR, vector/search index, object storage, warehouse, logging, 보안 검토, reviewer 인건비, QA, enterprise discount, prompt caching, batch/flex 처리, 데이터 거주성 프리미엄은 제외한 값입니다.
- 운영비의 실제 중심: 계약당 token보다 reviewer 시간, 예외 조항 처리, correction review, 감사 증적 관리, CLM/CRM/warehouse connector 유지보수가 더 커질 수 있습니다.
이 수치는 “이 정도면 충분합니다”라는 견적이 아닙니다. 파일럿에서는 field별 token 사용량, OCR 실패율, reviewer 수정률, low-confidence 비율, warehouse load 실패율을 함께 측정해야 합니다. 특히 계약은 고객명, 가격, 할인, 결제 조건, 비표준 약정이 포함되므로 보안과 감사 비용을 모델 비용과 분리해 추적하는 편이 좋습니다.
7. 비즈니스 이익과 KPI
OpenAI 사례가 보여주는 직접 효과는 리뷰 시간 단축, 처리 용량 확대, queryable warehouse output입니다.[1] 그러나 기업이 이 모델을 도입할 때는 자동화율만 보지 않는 편이 좋습니다.
| KPI 묶음 | 예시 지표 | 해석 | | --- | --- | --- | | 처리 속도 | Contract turnaround time, overnight ready rate | 계약 데이터가 얼마나 빨리 reviewer에게 도착하는지 봅니다. | | 품질 | Field accuracy, reviewer correction rate, citation missing rate | AI가 제안한 값과 근거가 검증 가능한지 봅니다. | | 운영 | Low-confidence queue, OCR failure rate, duplicate contract rate | 병목이 모델인지 문서 품질인지 workflow인지 분리합니다. | | 재무 활용 | Warehouse query adoption, billing/revenue workflow usage | 승인 데이터가 실제 분석과 업무에 쓰이는지 봅니다. | | 감사성 | Approval trail coverage, model/prompt version coverage | 사후 감사에서 판단 과정을 재구성할 수 있는지 봅니다. |
가장 큰 이익은 계약 파일을 “찾아 읽어야 하는 문서”에서 “근거를 따라갈 수 있는 데이터 자산”으로 바꾸는 점입니다. 이 전환이 일어나야 finance team은 단순 입력보다 예외 조항 판단, revenue policy, 고객 계약 분석에 시간을 더 쓸 수 있습니다.
8. 제조·B2B 기업에 주는 시사점
제조·B2B 기업도 비슷한 문서 병목을 갖고 있습니다. 고객별 공급 계약, 품질 보증 조건, penalty clause, 설비 유지보수 계약, 구매 단가 변경 합의서, 장기 공급 계약, 수출입 문서와 Incoterms 조건은 모두 형식이 제각각이고 중요한 값이 일부 조항에 숨어 있습니다.
적용 가능한 영역은 다음과 같습니다.
- 공급 계약에서 가격, 납기, 갱신, termination, liability 조항을 추출합니다.
- 품질 협약서에서 defect definition, corrective action, penalty, reporting deadline을 구조화합니다.
- 설비 유지보수 계약에서 SLA, spare parts, response time, warranty exclusion을 찾습니다.
- 장기 구매 계약에서 volume commitment, index-linked pricing, rebate 조건을 추적합니다.
- 수출입 문서에서 Incoterms, 원산지, 통관 책임, 보험 조건을 검증합니다.
도입 순서는 보수적으로 잡는 편이 현실적입니다. 먼저 read-only extraction과 reviewer UI를 붙입니다. 다음으로 승인 데이터의 warehouse 적재와 BI 조회를 연결합니다. 마지막으로 billing, procurement, contract lifecycle management 같은 업무 시스템 action은 충분한 승인, 감사, rollback 절차를 갖춘 뒤 연결하는 것이 안전합니다.
9. 도입 체크리스트
| 점검 항목 | 완료 기준 | | --- | --- | | 필드 정의 | 추출할 계약 필드, 허용 값, 판단 기준, 예외 상태가 문서화돼 있습니다. | | 원문 근거 | 모든 제안 값에 page, clause span, document version이 연결됩니다. | | 승인 경계 | Reviewer 승인 전 값은 재무 시스템과 warehouse 정본으로 쓰지 않습니다. | | 권한 | 계약 원본, 추출 값, reviewer UI, warehouse table 접근 권한이 분리됩니다. | | Tool action | Read-only, proposal, approval-required, forbidden action이 구분됩니다.[3] | | 재처리 | OCR 실패, schema validation 실패, duplicate ingest, low confidence, load failure의 재처리 절차가 있습니다. | | 감사 로그 | contract ID, prompt/model version, retrieved context, reviewer ID, approval timestamp가 남습니다. | | 보안 방어 | Prompt injection, data leakage, excessive agency, unbounded consumption 통제가 있습니다.[6] | | 평가 루프 | Reviewer correction이 field별 eval set과 regression test로 축적됩니다. | | 비용 관리 | Model token, OCR, search, storage, warehouse, human review, 보안 검토 비용을 분리해 봅니다.[4] |
결론
OpenAI Contract Data Agent / DocuGPT 사례의 본질은 계약 검토를 “AI가 대신 읽는 작업”으로 바꾼 것이 아니라, 계약 원문과 재무 판단을 연결하는 운영 시스템으로 바꾼 점입니다. 공개 사례에서 확인되는 핵심은 다양한 계약 파일 인입, retrieval-augmented prompting, 구조화 추출, 원문 근거, finance expert review, data warehouse 적재입니다.[1] 유사 기업이 이 패턴을 도입하려면 모델 성능보다 필드 정의, citation, 승인 상태, 권한, 감사 로그, 재처리, eval loop를 먼저 설계해야 합니다.[5][6] 제조·B2B 기업에서는 계약서 자동 요약보다 “승인 가능한 필드 데이터”를 만드는 좁은 문제부터 시작하는 편이 효과와 리스크를 함께 관리하기 좋습니다.
출처
- Turning contracts into searchable data at OpenAI. OpenAI. 2025-09-29. https://openai.com/index/openai-contract-data-agent/. 접근일: 2026-07-07.
- File search. OpenAI API Docs. 2026 access 기준. https://developers.openai.com/api/docs/guides/tools-file-search. 접근일: 2026-07-07.
- Function calling. OpenAI API Docs. 2026 access 기준. https://developers.openai.com/api/docs/guides/function-calling. 접근일: 2026-07-07.
- Pricing. OpenAI API Docs. 2026 access 기준. https://developers.openai.com/api/docs/pricing. 접근일: 2026-07-07.
- AI Risk Management Framework. National Institute of Standards and Technology. 2023/2024/2026 access 기준. https://www.nist.gov/itl/ai-risk-management-framework. 접근일: 2026-07-07.
- OWASP Top 10 for LLM Applications 2025. OWASP Foundation. 2025. https://genai.owasp.org/llm-top-10/. 접근일: 2026-07-07.
- Amazon Bedrock. AWS. 2026 access 기준. https://aws.amazon.com/bedrock/. 접근일: 2026-07-07.