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

대부분의 프로젝트가 시작 전에 실패하는 이유

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

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

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

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

가장 흔한 시작점이 가장 위험합니다. "계약서를 모두 스프레드시트에 넣기만 하면 돼." 이렇게 접근하면 계약 데이터 추출을 아카이브 프로젝트, 즉 PDF에서 Excel로의 일회성 마이그레이션으로 취급하게 되며, 일단 완료되면 끝난 것으로 간주합니다.

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

Juro 설문조사에 따르면 비즈니스의 11%만이 자사의 계약 관리를 "매우 효과적"이라고 평가합니다. 그렇지 않은 89%는 계약이 부족해서 실패하는 것이 아닙니다. 계약 데이터를 파이프라인(최신 상태를 유지하는 반복 가능한 프로세스)이 아닌 산출물(전달할 스프레드시트)로 취급하기 때문에 실패하는 것입니다.

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

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

법무팀이 AI 기반 추출 도구를 처음 접할 때, 자연스러운 본능은 모든 것을 캡처하려는 것입니다. 50개 필드. 100개. 모든 조항 유형, 모든 날짜, 문서에 나타나는 모든 명명된 개체. 철저해 보입니다. 하지만 실제로는 프로젝트를 망치는 가장 빠른 방법입니다.

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

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

해결책: 필드를 정의하기 전에 데이터로 답해야 할 세 가지 비즈니스 질문을 적어 보세요. "이 계약서에 어떤 필드가 있지?"가 아니라 "이 데이터가 있다면 무엇을 할 수 있을까?" 필드가 답 가능한 질문에 매핑되지 않으면 범위에 포함되지 않아야 합니다. 대부분의 팀에게 5–10개의 잘 선택된 필드 — 당사자 이름, 발효일, 금액, 준거법, 갱신 조건 — 는 실제 질문의 대부분을 충족합니다. 거기서 시작하세요. 첫 번째 배치가 정확하고 유용하다는 것이 입증된 후에만 필드를 추가하세요.

당사자 이름 표기 불일치(Party Name Drift)는 아무도 알아차리기 전에 보고를 망가뜨립니다

계약 데이터 추출에서 발생하는 모든 오류 중에서, 이 오류는 가시성은 가장 낮으면서 피해는 가장 큽니다. 계약 포트폴리오 전반에 걸쳐 동일한 거래 상대방이 여러 이름으로 나타납니다. 한 계약서에는 "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 도구는 스캔된 계약서에서 텍스트 위치가 문서마다 다르기 때문에 치명적으로 실패합니다. Vendor A가 서명한 계약서와 Vendor B가 서명한 계약서는 동일한 유형의 계약이라도 페이지에서 위치가 다릅니다. 반면, 문서 내용을 위치가 아닌 의미론적으로 이해하는 VLM 기반 추출은 형식 변동에 더 탄력적으로 대응합니다. AI는 사람처럼 문서를 읽습니다. "Effective Date"를 픽셀 좌표(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)으로 계약 데이터 추출이 가능한가요?

문서 관리 시스템은 파일을 저장합니다. 파일에서 구조화된 데이터를 추출하지는 않습니다. 문서 관리 시스템의 전문 검색은 어떤 문서에 특정 단어가 포함되어 있는지 찾을 수 있지만, "이 40개 공급업체 계약의 총 확정 지출액은 얼마인가?" 또는 "3분기에 만료되는 임대차 계약은 무엇인가?" 같은 질문에는 답할 수 없습니다. 계약 데이터 추출은 문서 관리 시스템 위에 위치하는 별도의 계층입니다 — 문서 관리 시스템이 저장한 문서를 읽고 구조화된 쿼리 가능한 출력을 생성합니다. 두 도구는 서로 다른 목적을 가지며 대체재가 아니라 함께 사용할 때 최상의 효과를 발휘합니다.

계약 데이터 추출 프로젝트는 일반적으로 얼마나 걸리나요?

50~200개 계약 포트폴리오에 5~10개 필드 범위로 초점을 맞춘 경우, 필드 정의와 정규화 규칙이 설정되면 추출 자체는 몇 시간 안에 완료할 수 있습니다. 실제 시간 투자가 필요한 부분은 사전 결정 단계입니다: 비즈니스 질문 정의, 문서 형식 감사, 정규화 규칙 구축입니다. 이러한 사전 추출 단계는 일반적으로 집중 작업 1~3일이 소요되며, 이 단계를 건너뛰는 것이 Gartner와 ContractWorks 데이터가 문서화한 다개월 구현 실패의 원인입니다.