계약 데이터 추출 프로젝트가
시작도 전에 멈추는 이유

대부분의 프로젝트가 첫날부터 실패하는 이유

계약 데이터 추출 프로젝트의 실패에 관한 일반적인 이야기는 구현 중에 발생하는 문제에 초점을 맞춥니다: 소프트웨어가 너무 복잡하거나, 교육이 부적절하거나, 사람들이 도입하지 않는 것 등입니다. ILTA 2024 기술 설문조사에 따르면, 54%의 법률 사무소가 "사용자의 변화에 대한 저항"을 가장 큰 장애물로 꼽았고, 42%는 "학습 시간 부족"을 지적했습니다.

그러나 이것을 사용자 도입 문제로만 보는 것은 더 깊은 문제를 놓치는 것입니다. 사람들이 새로운 추출 도구를 거부하는 이유는 고집 때문이 아니라, 프로젝트가 아무도 사용할 수 없는 결과물을 만들도록 설정되었기 때문입니다. 법률 비서가 출력된 스프레드시트에서 일치하지 않는 당사자 이름, 세 가지 다른 형식의 날짜, 그리고 절반의 행에 "제14조 참조"라고 적힌 "준거법" 열을 발견했을 때, 수동 검토로 돌아가려는 본능은 변화에 대한 저항이 아닙니다. 그것은 나쁜 데이터에 대한 합리적인 반응입니다.

다음은 경험에서 비롯된, 이론이 아닌 다섯 가지 구체적인 실수입니다. 이러한 실수는 계약 데이터 추출 프로젝트가 본격적으로 시작되기도 전에 실패하게 만듭니다. 각각은 인식 가능한 패턴, 증상보다 더 깊은 근본 원인, 그리고 결과를 바꾸는 실행 가능한 수정 방법을 가지고 있습니다.

추출을 일회성 덤프로 취급하면 데이터가 곧바로 낡아집니다

가장 흔한 출발점이자 가장 위험한 출발점은 "모든 계약을 스프레드시트에 넣기만 하면 돼"라는 생각입니다. 이러한 접근 방식은 계약 데이터 추출을 아카이브 프로젝트, 즉 PDF에서 Excel로의 일회성 마이그레이션으로 간주하여, 한 번 완료되면 끝나는 것으로 봅니다.

문제의 원인은 단순한 조바심보다 더 깊습니다. 대부분의 법무팀은 구조화된 메타데이터 없이 수년간 계약서를 쌓아왔고, 그 backlog가 시급하게 느껴집니다. 2주 후 이사회 회의, 규정 준수 감사, 또는 인수합병이 다가옵니다. 지속 가능한 무언가를 구축하는 절제보다 무언가를 만들어내야 한다는 압박이 우선합니다. 그 결과는 생성된 날 이미 낡은 스프레드시트입니다. 추출과 전달 사이에 세 개의 새 계약이 체결되었지만, 전체 과정을 반복하지 않고 파일을 업데이트하는 방법을 아무도 모르기 때문입니다.

Juro의 설문조사에 따르면, 기업의 11%만이 자사의 계약 관리를 "매우 효과적"이라고 평가합니다. 나머지 89%가 실패하는 이유는 계약이 부족해서가 아니라, 계약 데이터를 '전달물'(건네줄 스프레드시트)이 아닌 '파이프라인'(최신 상태를 유지하는 반복 가능한 프로세스)으로 다루지 않기 때문입니다.

해결책: 단일 필드를 추출하기 전에, 다음 달 데이터가 어떻게 업데이트될지 정의하십시오. "나중에 알아보겠다"는 답변은 시스템이 아닌 아카이브를 구축하는 것입니다. 반복 가능한 추출 파이프라인은 새 계약서에 동일한 프로세스를 다시 실행할 수 있음을 의미합니다. 추출 도구에 배치를 업로드하거나, 프로젝트 막바지에만이 아니라 지속적으로 계약 데이터에 접근할 수 있게 해주는 워크플로우를 설정하는 방식으로 말입니다.

질문에 답하는 것 대신 모든 것을 추출하기

법무팀이 AI 기반 추출 도구를 처음 접하면 모든 것을 캡처하려는 본능이 생깁니다. 50개 필드. 100개. 모든 조항 유형, 모든 날짜, 문서 내 모든 명명된 개체. 철저해 보이지만, 사실 프로젝트를 망치는 가장 빠른 길입니다.

근본 원인은 완전히 이해할 수 있는 불안감입니다. "나중에 이 필드가 필요할 수도 있는데 추출하지 않으면 어쩌지?" 이 두려움에 기반한 범위 설정은 아무도 검증, 유지, 사용할 수 없는 필드 목록을 만듭니다. 필드가 추가될수록 추출 지연 시간이 늘어나고, 오류 확인 범위가 배가되며, 가장 중요하게는 팀의 주의가 너무 많은 데이터 포인트에 분산되어 중요도가 높은 필드의 품질 검사가 잡음에 묻힙니다. ILTA 조사에서 42%의 법률 사무소가 충분한 학습 시간 부족을 지적한 것은 바로 이와 직접 연결됩니다. 추출 범위가 50개 필드에 달하면 아무도 제대로 검증할 시간이 없습니다.

87개의 임대 계약을 보유한 소규모 부동산 관리 회사를 생각해 보세요. 모든 유지 보수 조항, 모든 전대 제한, 모든 반려동물 정책 세부 사항을 추출하려 할 수 있습니다. 또는 운영 결정의 80%를 좌우하는 5개 필드(임차인 이름, 월세, 임대 종료일, 보증금 금액, 자동 갱신 조항(예/아니오))만 추출할 수도 있습니다. 5개 필드, 87개 계약, 모두 오후 하나면 해결됩니다. 두 번째 접근 방식은 운영 관리자가 월요일 아침에 실제로 사용하는 데이터를 생성합니다. 첫 번째 접근 방식은 열리지도 않고 방치되는 압도적인 스프레드시트를 만듭니다.

수정 방법: 필드를 정의하기 전에, 데이터로 답해야 할 세 가지 비즈니스 질문을 먼저 적으세요. "이 계약서에 어떤 필드가 있나?"가 아니라 "이 데이터가 있다면 무엇을 할 수 있을까?"입니다. 답할 수 있는 질문으로 이어지지 않는 필드는 범위에 포함될 필요가 없습니다. 대부분의 팀에서 잘 선별된 5~10개 필드 — 당사자명, 발효일, 금액, 준거법, 갱신 조건 — 로 실제 질문의 대부분을 해결할 수 있습니다. 여기서 시작하고, 첫 번째 필드 세트가 정확하고 실용적임이 입증된 후에만 추가하세요.

당사자명 표기 불일치, 눈치채기 전에 리포팅을 망친다

계약 데이터 추출 실수 중에서도 이 실수는 가시성은 가장 낮으면서 피해는 가장 큽니다. 계약 포트폴리오 전체에서 동일한 상대방이 여러 이름으로 나타납니다. 한 계약서에는 "Acme Corp.", 다른 계약서에는 "Acme Corporation", 또 다른 계약서에는 "Acme Corporation, LLC", 그리고 상대방 사내 팀이 작성한 네 번째 계약서에는 "Acme Holdings North America"로 표시됩니다. 추출 도구는 각 변형을 있는 그대로 충실히 가져옵니다. 그러면 리포팅 — 상대방 익스포저, 갱신 추적, 벤더 지출 분석 — 은 조용히 망가집니다.

원인은 추출 도구가 아닙니다. 계약 당사자명이 정규화 없이 데이터베이스 키 역할을 할 만큼 일관적이라는 가정 때문입니다. 절대 그렇지 않습니다. 이 문제는 규모가 커질수록 심각해집니다. 계약이 200개라면 사람이 중복을 찾을 수 있습니다. 2,000개라면 불가능합니다. 그리고 누군가 "Johnson & Associates"와 "Johnson & Associates, P.C."가 별도의 위험 프로필을 가진 별도 법인으로 추적되고 있다는 사실을 알아챌 때쯤이면, 이미 몇 달간의 리포팅이 잘못된 상태입니다.

r/legaltech 서브레딧에서 한 실무자가 이 근본적인 차이를 완벽히 설명했습니다: "제가 이야기한 모든 로펌이 같은 문제를 겪고 있지만, 아무도 해결하지 못했습니다." 문제는 추출 도구를 찾는 것이 아니라, 추출된 데이터를 의사 결정의 근거로 삼을 만큼 신뢰할 수 있게 만드는 데 있습니다.

해결책: 추출 후가 아니라 추출 전에 정규화 규칙을 정의하세요. 각 엔티티 이름의 표준 형식을 미리 결정하십시오. 열 이름 추출을 지원하는 도구를 사용한다면 — 즉, 원하는 데이터(예: "계약 상대방 이름")를 지정하면 AI가 각 문서에서 이를 찾아 추출하는 방식 — 수동 정리 과정이 아니라 추출 중에 변형을 표준 형식에 매핑하는 조회 또는 규칙을 구축하세요. 여기서 계산된 열이 유용할 수 있습니다: 추출된 당사자 이름이 알려진 표준 목록과 일치하는지 확인하고, 하위 시스템으로 유입되기 전에 불일치를 표시하는 규칙을 정의할 수 있습니다. 일부 팀은 새로운 변형이 나타날 때마다 업데이트되는 살아있는 계약 상대방 사전을 유지 관리합니다. 핵심은 도구가 아니라, 당사자 이름이 지저분하다는 사실을 인정하고 처음부터 이에 대비하는 규율에 있습니다.

모든 PDF가 기계 판독 가능하다고 가정하기

어느 정도 규모의 계약 포트폴리오에서는 스캔된 PDF를 만나게 됩니다 — 종이에 서명하고, 스캐너에 통과시켜 이미지로 저장된 계약서들입니다. 팩스를 이메일로 변환한 문서도 만나게 됩니다. 텍스트 레이어는 존재하지만 오래된 OCR 엔진의 일반적인 결과물로 인해 깨져 있는 문서도 만나게 됩니다. 이런 문서들은 열어보면 멀쩡해 보입니다. 하지만 추출 결과는 형편없습니다.

이 오류의 원인은 법무팀이 문서를 평가할 때 발생하는 사각지대에 있습니다. 변호사들은 경력 내내 계약서를 읽으며 — 페이지를 시각적으로 처리합니다. 누군가 "모든 계약서를 디지털화했습니다"라고 말할 때, 실제로 의미하는 것은 "화면에서 열 수 있는 PDF가 있습니다"인 경우가 많습니다. 하지만 사람이 읽을 수 있는 PDF와 기계가 추출할 수 있는 PDF 사이에는 엄청난 차이가 있습니다. OCR이 "Term"을 "Tern"으로 잘못 인식한 스캔 문서라도 변호사가 조항을 이해하는 데는 지장이 없습니다. 하지만 추출 도구가 종료일을 올바르게 식별하는 데는 치명적입니다.

바로 여기서 도구 선택이 매우 중요해집니다. 전통적인 템플릿 기반 OCR 도구 — 페이지의 특정 좌표에서 데이터를 찾는 방식 — 는 스캔된 계약서에서 텍스트 위치가 문서마다 다르기 때문에 치명적으로 실패합니다. A업체가 서명한 계약서와 B업체가 서명한 계약서는 동일한 유형의 계약이라도 페이지상 위치가 다릅니다. 반면, VLM(비전 대규모 모델) 기반 추출 — 위치가 아닌 의미론적으로 문서 내용을 이해하는 방식 — 은 형식 변동에 더 탄력적으로 대처합니다. AI는 사람이 문서를 읽는 방식과 동일하게 작동합니다: "발효일"을 픽셀 좌표(x:340, y:210)에서 찾는 것이 아니라, 해당 단어의 의미를 이해하여 위치를 파악합니다.

수정 사항: 추출 도구를 선택하기 전에 계약서 형식을 감사하세요. 포트폴리오에서 무작위로 20개의 계약서를 뽑아 각각을 분류하세요: 기본 PDF(텍스트 선택 가능), 스캔된 이미지 PDF(텍스트 레이어 없음), 혼합(일부 페이지 검색 가능, 일부 불가). 20% 이상이 스캔된 문서라면 VLM 기반 접근 방식이 필수이며, 가장 깨끗한 문서가 아닌 가장 형편없는 형식의 문서부터 테스트해야 합니다. 계약서에 손으로 쓴 주석, 여백 메모 또는 날인이 있는 수정 사항이 포함된 경우 이를 고려하세요. 가장 깨끗한 10개 계약서는 완벽하게 처리하지만 지저분한 10개는 실패하는 도구는 50%의 적용 범위만 제공하는 도구입니다.

문서 저장소와 계약 인텔리전스 혼동하기

이 실수는 법률 업계가 정상화한 언어에 묻혀 있기 때문에 발견하기 가장 어렵습니다. "iManage에서 계약서를 관리합니다." "모든 것이 NetDocuments에 있습니다." "계약 저장소는 SharePoint입니다." 이러한 각 진술은 파일이 있는 위치인 문서 저장소를 설명하는 것이지, 해당 파일에 포함된 내용인 계약 인텔리전스를 설명하는 것이 아닙니다. 이 둘 사이의 간격은 추출 프로젝트가 실패하는 지점입니다.

근본 원인은 역량 문제를 가리는 용어 문제입니다. iManage나 NetDocuments 같은 문서 관리 시스템(DMS)은 버전 관리, 접근 권한, 전체 텍스트 검색을 제공합니다. 하지만 계약 포트폴리오의 전체 텍스트 검색은 "이 단어가 포함된 문서는 무엇인가?"라는 질문 하나에만 답할 수 있습니다. "향후 90일 내에 만료되는 계약은 무엇인가?" 또는 "이 공급업체에 대한 총 약정 지출액은 얼마인가?" 또는 "재협상해야 할 자동 갱신 조항이 포함된 계약은 몇 개인가?"와 같은 질문에는 답할 수 없습니다. 이러한 질문에는 각각 파일이 아닌 필드에 저장되는 정형 데이터가 필요합니다.

법무팀이 "우리는 이미 계약을 디지털로 관리하고 있습니다"라고 말하고, 경영진이 "계약 데이터에 접근 가능하다"고 이해하는 순간, 프로젝트는 이미 실패한 것입니다. 디지털화가 데이터 접근과 동일하다는 가정이 잘못되었습니다. DMS는 모든 계약의 위치를 알고 있지만, 어떤 계약이 무엇을 말하는지는 전혀 알지 못합니다.

해결책: 모든 프로젝트 논의에서 이 두 개념을 명확히 구분하십시오. 문서 저장소는 기본 조건일 뿐이며, 필요하지만 충분하지는 않습니다. 계약 데이터 추출은 그 위에 있는 계층으로, 저장된 파일을 질의 가능한 정보로 전환합니다. 둘은 상호 보완적이지 상호 교환 가능하지 않습니다. 귀사가 DMS에 투자했다면 좋습니다. 해당 인프라는 파일이 중앙화되어 있으므로 추출을 더 쉽게 만듭니다. 하지만 "우리에게는 이미 계약 시스템이 있습니다"라는 말로 논의를 중단하지 마십시오. 현재 가지고 있는 것은 파일링 시스템입니다. 필요한 것은 하나도 열어보지 않고도 어떤 계약에 주의가 필요한지 알려주는 시스템입니다.

실제로 효과가 있는 것: 결과를 바꾸는 다섯 가지 결정

위의 모든 실수에는 그에 상응하는 해결책이 있습니다. 이는 사전 프로젝트 체크리스트를 형성하며, 비용은 들지 않지만 Gartner와 ContractWorks가 대규모로 문서화한 다운스트림 실패를 방지합니다.

1. 업무 질문부터 시작하라, 필드 목록부터가 아니다. 이 데이터가 어떤 의사 결정을 지원할 것인가? 갱신 협상? 규정 준수 감사? 지출 분석? 질문이 범위를 결정한다. 질문을 명명할 수 없다면, 데이터를 공허 속으로 추출하는 것이다.

2. 첫 번째 패스에서는 5~10개 필드로 범위를 제한하라. 좁은 범위에서 정확성과 사용성을 입증한 후 확장하라. 검증되고 신뢰할 수 있는 5개 필드 추출이 아무도 확인하지 않는 50개 필드 추출보다 무한히 가치 있다.

3. 정리는 추출 단계에서, 사후 정리가 아닌 방식으로 수행하라. 당사자명과 날짜 형식에 대한 표준화 규칙을 추출 단계에 내장하라. 추출 후 데이터 정리에 소비하는 모든 시간은 반복 실행 시 누적되는 회피 가능한 비용이다.

4. 가장 열악한 문서로 먼저 테스트하라. 커피 얼룩과 수기 수정 사항이 있는 2013년 스캔 계약서가 최상의 평가 사례다. 도구가 이를 처리한다면, 적용 범위를 확보한 것이다. 처리하지 못한다면, 계약 체결 전에 격차를 알게 된다.

5. 반복 실행을 염두에 두고 설계하라. 첫 번째 추출은 이정표이지 종착점이 아니다. 필드 정의, 정규화 규칙, 출력 형식을 포함한 워크플로가 다음 달 15개의 새 계약이 도착했을 때 재현 가능하도록 하라. 일괄 추출을 통해 여러 계약을 한 번에 업로드하고 단일 병합 스프레드시트를 얻는 방식으로, 이를 일회성 영웅적 노력이 아닌 지속 가능한 프로세스로 만드는 것이다.

자주 묻는 질문

스캔된 PDF에서도 계약 데이터 추출이 가능한가요?

네, 하지만 품질은 기반 기술에 크게 의존합니다. VLM(비전 대규모 언어 모델) 기반 추출은 스캔된 문서를 의미적으로 읽어 고정된 좌표에서 텍스트를 찾는 대신 내용을 이해합니다. 이는 전통적인 좌표 기반 OCR보다 스캔된 계약서의 형식 변동을 훨씬 잘 처리합니다. 그러나 심하게 손상된 스캔(심한 기울어짐, 어두운 배경 노이즈, 매우 낮은 해상도)은 기술에 관계없이 정확도를 떨어뜨립니다. 도구를 확정하기 전에 항상 실제 문서 품질로 테스트하세요.

계약서에서 몇 개의 필드를 추출해야 하나요?

가장 시급한 비즈니스 질문에 답할 수 있는 5~10개 필드로 시작하세요. 당사자명, 발효일, 만료일, 금액, 준거법, 주요 조항(중재, 자동 갱신, 면책)에 대한 예/아니오 플래그가 대부분의 실제 요구를 충족합니다. 모든 것을 추출하려는 욕구를 참으세요. 필드가 추가될수록 검증 작업이 배가되고 데이터셋에 대한 전반적인 신뢰도가 떨어집니다.

계약서마다 다른 당사자명은 어떻게 처리하나요?

추출 전에 정규화 계획을 수립하세요. 표준 상대방명 목록을 유지하고 변형을 매핑하세요. 추출 도구가 계산된 열이나 규칙 기반 처리를 지원하면 추출 시점에 이름 불일치를 플래그 지정할 수 있습니다. 일부 팀은 새 변형이 나타날 때마다 업데이트되는 공유 상대방 사전을 스프레드시트나 데이터베이스로 관리합니다. 이는 초기 수동 작업이지만, 신뢰할 수 있는 보고와 조용히 깨진 보고의 차이를 만듭니다.

기존 문서 관리 시스템(iManage, NetDocuments, SharePoint)을 계약 데이터 추출에 사용할 수 있나요?

DMS는 파일을 저장할 뿐, 파일에서 구조화된 데이터를 추출하지는 않습니다. DMS의 전문 검색은 특정 단어가 포함된 문서를 찾을 수 있지만, "40개 공급업체 계약의 총 확정 지출액은 얼마인가?" 또는 "3분기에 만료되는 임대차 계약은 무엇인가?"와 같은 질문에는 답할 수 없습니다. 계약 데이터 추출은 DMS 위에 별도로 구축되는 계층으로, DMS에 저장된 문서를 읽고 구조화된 질의 가능한 결과물을 생성합니다. 두 도구는 서로 다른 목적을 가지며, 대체재가 아닌 상호 보완적으로 사용될 때 가장 효과적입니다.

계약 데이터 추출 프로젝트는 보통 얼마나 걸리나요?

50~200개 계약으로 구성된 포트폴리오에서 5~10개 필드로 범위를 좁히면, 필드 정의와 정규화 규칙만 설정되면 추출 자체는 몇 시간 안에 완료됩니다. 실제 시간이 많이 소요되는 부분은 사전 결정 단계, 즉 업무 질문 정의, 문서 형식 감사, 정규화 규칙 구축입니다. 이러한 사전 추출 단계는 보통 1~3일의 집중 작업이 필요하며, 이를 생략하는 것이 Gartner와 ContractWorks 데이터 문서에서 언급된 수개월 간의 구현 실패를 초래하는 원인입니다.