계약 검토 업무의 대부분은 검토가 아닙니다.
특정 조항을 찾는 일입니다.

실제로 시간이 사라지는 곳

사내 변호사에게 가장 큰 시간 낭비 요인을 꼽으라면 계약 검토가 상위권에 오를 것이다. 하지만 '검토'라는 표현은 적절하지 않다. 그 시간의 대부분은 위험 평가나 조건 협상이 아니라, '찾는 일'에 소비된다.

CLOC 조사(다양한 규모의 조직 소속 계약 전문가 응답 기반)는 이 과정을 두 가지 측정 가능한 단계로 나눈다: 계약서 찾기(45분), 관련 조항이나 문구 찾기(84분). 실제 분석이 시작되기 전에 이미 2시간이 넘게 소요되며, 이는 단일 계약 기준이다. 월 500건의 계약을 처리하는 조직은 연간 6,000건 이상을 처리한다. 계산 결과는 냉혹하다.

이 패턴은 개인 수준에서도 동일하다. 사내 변호사들은 업무 시간의 60~80%를 일상적인 문서 검토에 사용하며, 그중 대부분은 법적 판단이 아닌 자료 검색과 데이터 입력에 해당한다. LegalOn과 In-House Connect의 2025년 조사에 따르면, 계약 검토 분야의 AI 도입률이 전년 대비 75% 증가했으며, 이는 바로 이 문제에서 시간을 되찾으려는 팀들의 노력에 기인한다.

좌절감은 추상적인 수준에 머물지 않는다. Reddit의 r/legaltechAI에서 한 사내 법무 운영 전문가는 상황을 이렇게 직설적으로 표현했다: "조항 추출과 이상 징후 탐지는 기본 중의 기본이다. 더 어려운 문제는 포트폴리오 수준의 인텔리전스다: 수천 건의 계약에 걸친 의무 추출, 갱신 노출도, M&A 전 경영권 변동 조항, 규제 스윕 분석 등. 이는 수정 작업보다는 계약을 비즈니스가 질의할 수 있는 구조화된 데이터로 전환하는 문제에 가깝다." (출처)

r/paralegal의 한 파라리걸은 더 실용적으로 말했다: "조항 추출은 1차 분류 도구로 신뢰할 수 있지만, 직접 읽기를 대체할 수는 없다. 핵심은 '이게 무슨 뜻인지 알려줘'가 아니라 '올바른 페이지/섹션으로 빨리 데려다 줘'다." (출처)

Ctrl+F가 50개 계약에 통하지 않는 이유

가장 먼저 떠오르는 해결책은 키워드 검색이다. 각 PDF를 열고 Ctrl+F를 눌러 "준거법"이나 "발효일"을 입력하고, 결과를 복사해 스프레드시트에 붙여넣는다. 계약이 두세 개라면 통한다. 하지만 50개라면, 곧바로 한계가 드러난다.

계약 언어는 정확히 일치하는 검색을 어렵게 만든다. 같은 개념도 계약서마다 다른 이름으로 등장한다. 한 계약서의 "발효일"은 다른 계약서에서 "계약시작일"이 되고, 또 다른 곳에서는 "본 계약은 다음 날짜부터 효력을 발생한다"로 표현된다. "면책"을 검색하면 "손해배상 면제"라는 제목의 조항은 놓친다. "해지"를 검색하면 80페이지에 걸친 모든 언급이 반환되어, 실제 해지 조항과 단순 언급, 정의된 용어, 상호 참조를 수동으로 분리해야 한다.

여기에 형식 문제도 있다. 어떤 계약은 깔끔한 Word 문서다. 다른 계약은 스캔된 PDF다. 프린터와 스캐너, 그리고 텍스트를 거의 읽기 어렵게 만드는 압축 아티팩트의 산물이다. 키워드 검색은 이미지 기반 PDF에서는 OCR을 먼저 실행하지 않으면 완전히 실패하며, OCR을 실행해도 품질이 일정하지 않다.

CLOC 조사에 따르면, 65%의 팀이 여전히 스프레드시트와 이메일로 계약을 관리한다. 통합 도구도, 중앙 저장소도, 자동 추출도 없다. 46%는 때때로 올바른 계약을 아예 찾지 못한다. 찾은 문서가 최신 버전이라고 확신하는 팀은 절반 미만이다. 이는 기술 도입의 실패라기보다 업무 흐름 설계의 실패에 가깝다. 사람들이 사용하는 도구는 원래 이런 작업을 위해 만들어진 것이 아니다.

계약 CLM이 하는 일 (그리고 데이터 추출에 관해 하지 않는 일)

중견 또는 대규모 조직에서 일한다면, 이미 계약 라이프사이클 관리 시스템(DocuSign CLM, Ironclad, LinkSquares, Juro 등)을 사용하고 있을 수 있다. 이 플랫폼들은 계약의 전체 라이프사이클, 즉 초안 작성, 협상, 승인 라우팅, 전자서명, 보관, 서명 후 의무 추적을 처리한다.

CLM은 그 역할을 훌륭히 수행한다. Ironclad는 승인 워크플로를 자동화하고 협상된 계약의 중앙 저장소를 유지한다. LinkSquares는 AI를 적용해 메타데이터를 추출하고 포트폴리오 전반의 갱신 위험을 표면화한다. DocuSign CLM은 계약 생성과 전자서명 및 실행 후 분석을 통합한다. Juro는 브라우저 기반 작업 공간에서 협업적 계약 작성과 서명을 지원한다.

하지만 데이터 추출과 관련해 중요한 차이점이 있다. CLM은 계약을 하나의 단위로 본다. 문서, 상태, 서명자, 마감일을 관리한다. 50개 계약에서 동일한 다섯 가지 데이터 포인트를 뽑아 스프레드시트에 넣어야 할 때 — 형식에 관계없이, 계약이 CLM에 있었는지 여부에 관계없이 — 이것은 완전히 다른 작업이다.

CLM 플랫폼은 훈련된 메타데이터(당사자 이름, 발효일, 계약 금액)를 추출할 수 있다. 하지만 비표준 필드, 예를 들어 공급업체 계약서에 숨겨진 보험 요구 조항의 특정 건당 공제액을 요청하면, 맞춤형 추출 모델을 구축하거나 수동으로 처리해야 한다. CLM의 추출 범위는 훈련 데이터에 묶여 있다. 사전 훈련된 분류 체계에 없는 필드는 추출되지 않는다.

이는 CLM의 실패가 아닙니다. 이는 CLM이 설계된 목적을 반영한 것입니다. 계약 라이프사이클 관리와 필드 수준 데이터 추출은 서로 다른 문제를 해결합니다. CLM은 계약의 여정을 관리합니다. 추출 도구는 계약 페이지에서 특정 데이터를 가져옵니다. 형식에 구애받지 않고, 템플릿이 필요 없으며, 도구가 사전 학습된 내용이 아닌 사용자가 요청하는 내용에 따라 작동합니다.

계약서에서 특정 필드를 추출하는 단계별 방법

계약서 더미에서 특정 데이터 포인트(당사자, 발효일, 준거법, 책임 한도, 갱신 조건, 지급 일정)를 추출해야 한다면, 템플릿이나 맞춤 모델 없이, 모든 문서를 처음부터 끝까지 읽지 않고도 다양한 계약 형식에서 작동하는 워크플로우가 있습니다.

이 워크플로우는 샘플 계약서로 모델을 훈련시켜 일반화를 기대하는 전통적인 계약 데이터 추출과 반대입니다. 여기서 사용되는 메커니즘은 사용자 정의 열 추출입니다. 도구가 페이지에서 데이터가 어디에 있는지 인식하도록 훈련시키는(템플릿/영역 OCR 방식) 대신, "당사자 A", "발효일", "준거법", "책임 한도액"과 같은 열 이름을 입력하여 AI에 무엇을 원하는지 알려줍니다. AI는 각 계약서를 읽고, 페이지의 미리 정해진 위치를 일치시키는 것이 아니라 용어의 의미를 이해하여 해당 값을 찾습니다. 이것이 위치 기반 추출과 의미 기반 추출의 차이점입니다. AI가 좌표를 보는 것이 아니라 의미를 보기 때문에 계약서 형식은 중요하지 않습니다.

일괄 병합은 이 방식을 각 파일을 개별적으로 여는 것과 차별화합니다. 50개의 계약서, 한 번의 업로드, 하나의 출력 테이블. 모든 PDF를 열고, 필드를 찾고, 값을 복사하고, 붙여넣고, 정확성을 확인하는 지루한 작업을 도구가 대신합니다.

추출이 효과적인 경우와 변호사가 필요한 경우

필드 수준 추출은 실질적인 문제를 해결하지만, 정직한 평가를 위해서는 처리 가능한 범위와 그렇지 않은 범위를 명확히 구분해야 합니다.

추출이 잘 처리하는 것: 계약서에서 당사자, 날짜, 금액, 준거법, 갱신 조건, 조항 존재 여부(해당 계약에 면책 조항이 있는가? 예/아니오) 등 구조화된 데이터 포인트를 추출하는 것입니다. 이들은 명시적이거나 추론 가능한 형태로 문서 내에 존재하는 값들입니다. AI는 위치 기반이 아닌 의미 기반 이해를 통해 이를 찾아내므로, 계약서 간 레이아웃, 조항 순서, 심지어 필기 주석 등의 형식 차이가 추출을 방해하지 않습니다.

추출이 대체하지 않는 것: 조항 문언에 대한 법적 해석입니다. AI는 계약서에 면책 조항이 포함되어 있고 그 텍스트를 추출할 수는 있지만, 해당 조항이 비정상적으로 광범위한지, 다른 조항과 충돌하는지, 특정 관할권의 판례법 아래에서 조직에 허용할 수 없는 위험을 초래하는지 여부는 판단할 수 없습니다. 이는 법적 판단입니다. 마찬가지로, 추출 도구는 CLM 플랫폼을 대체하지 않습니다. 협상 워크플로를 관리하거나, 승인을 라우팅하거나, 서명을 추적하거나, 체결 후 의무를 모니터링하지 않습니다.

적합한 사고 모델은 다음과 같습니다: 추출 도구가 계약 데이터에 대해 하는 역할은, 법률 비서의 1차 검토가 사건 파일에 대해 하는 역할과 같습니다. 필요한 정보를 찾아 정리하여 판단할 준비를 해주지만, 그 판단을 대신하지는 않습니다.

자주 묻는 질문

스캔된 계약서도 되나요, 아니면 디지털 PDF만 되나요?

둘 다 가능합니다. AI는 각 페이지의 시각적 콘텐츠를 읽습니다. 스캔 문서, 서명된 계약서의 휴대폰 사진, 깨끗한 디지털 PDF, Word 파일 모두 동일한 시각적 이해 경로를 통해 처리됩니다. 별도의 OCR 단계가 없으며, 스캔 문서에 따른 형식별 정확도 저하도 없습니다. 다만, 해상도가 매우 낮은 스캔(약 150 DPI 미만 또는 심한 압축 아티팩트)은 정확도가 떨어질 수 있습니다.

전체 조항을 추출할 수 있나요, 아니면 단일 데이터 포인트만 가능한가요?

둘 다 가능합니다. 열 이름을 "면책 조항"으로 지정하면 AI가 해당 조항의 전체 텍스트를 셀에 추출합니다. 또한 "발효일"이나 "계약 금액"과 같은 단일 값도 추출할 수 있습니다. 긴 조항의 경우 추출된 텍스트는 여러 단락의 법률 언어가 될 수 있습니다.

이 기능을 사용하려면 CLM이 필요한가요?

아니요. 추출 도구는 CLM 시스템과 독립적으로 작동합니다. 공유 드라이브, 이메일 첨부 파일, SharePoint 폴더 등 어디에 저장된 계약서든 사용할 수 있습니다. 이미 CLM이 있는 경우, 추출 도구는 CLM의 사전 훈련된 추출 분류 체계에 속하지 않는 임시 또는 비표준 필드 요청을 처리하여 이를 보완합니다.

한 번에 몇 개의 계약서를 처리할 수 있나요?

배치당 계약서 수에 엄격한 제한은 없지만, 실제 처리량은 구독 요금제의 동시 실행 제한에 따라 달라집니다. 워크플로우는 배치 우선으로 설계되었습니다. 모든 계약서를 함께 업로드하면 결과가 하나의 병합된 스프레드시트에 제공됩니다.

추출 정확도는 어느 정도인가요?

명확하게 명시된 데이터 포인트(날짜, 당사자 이름, 금액)의 경우 정확도가 높습니다. 일반적으로 깨끗한 문서의 경우 95% 이상입니다. 매우 조밀하거나 특이한 계약서 형식, 손으로 쓴 주석, 또는 품질이 낮은 스캔의 경우 정확도가 떨어질 수 있습니다. 시스템은 각 추출 결과와 함께 원본 이미지를 출력하므로, 검증이 간편합니다. 몇 초 만에 특정 셀을 원본 문서와 대조 확인할 수 있습니다. 추출 품질에 영향을 미치는 요소에 대한 자세한 내용은 계약 추출 정확도 가이드를 참조하세요.

검색에서 구조로

CLOC 조사에서 확인된 두 시간 — 계약서 찾는 데 45분, 올바른 조항 찾는 데 84분 — 은 법률 업무를 수행하는 시간이 아닙니다. 문서를 탐색하는 시간입니다. 이 차이가 중요한 이유는 개선이 가능하기 때문입니다.

원하는 필드를 지정하고 50개의 계약서, 스캔된 PDF, Word 파일, 휴대폰 사진에서 구조화된 표로 결과를 받을 수 있다면, 검토 자체가 작업이 되고 작업을 위한 준비가 아닙니다. 필요한 데이터 포인트가 이미 포함된 스프레드시트와 함께 앉아서 데이터가 의미하는 바에 시간을 쏟고, 데이터가 어디에 있는지 찾는 데 시간을 낭비하지 않습니다.

계약서 배치로 시도해보세요. 중요한 필드를 지정하고 결과를 확인하세요.