대부분의 계약 분석 (contract-analysis) 도구들은 다음과 같은 동일하고 기본적인 질문에서 시작합니다:

이 문서의 조항들 중 무엇이 잘못되었는가?

이 질문은 유용하지만 불완전합니다. 때로는 가장 큰 리스크는 잘못 작성된 조항이 아니라, 존재하지 않는 조항입니다.

저는 AI 지원 컴플라이언스 분석 (compliance analysis) 도구인 AuditGuard를 구축하면서 이 문제를 경험했습니다. 한 고객이 서명 전 계약서를 검토하기 위해 이 도구를 사용했습니다. 시스템은 위험한 문구를 표시하고, 잠재적으로 관련 있는 요구 사항을 인용하며, 사람이 검토할 수 있도록 초안 교체안을 제안했습니다.

하지만 대화의 흐름을 바꾼 발견은 보고서의 다른 섹션에서 나왔습니다: 누락된 조항 (Missing Clauses).

해당 계약서는 선택된 컴플라이언스 프레임워크 (compliance framework) 하에서 요구될 수 있는 규정을 다루지 않는 것으로 나타났습니다. 관련 문구 자체가 없었기 때문에 검토자가 하이라이트할 만한 의심스러운 문장도 없었습니다.

고객은 그 결과물을 법적 결론으로 받아들이지 않았습니다. 대신 그는 이를 계약 검토 과정에서 제기할 집중적인 질문으로 활용했고, 문제가 해결될 때까지 서명을 연기했습니다.

이 사례는 흥미로운 엔지니어링 문제를 담고 있습니다: 존재하지 않는 텍스트를 어떻게 검색할 것인가?

일반적인 조항 분석이 이를 놓치는 이유

전형적인 계약 분석 파이프라인 (contract-analysis pipeline)은 보통 다음과 같습니다:

1. 문서를 조항별로 분할합니다.
2. 각 조항을 주제별로 분류합니다.
3. 해당 텍스트와 관련된 규정이나 정책을 검색(Retrieve)합니다.
4. 모델에게 해당 조항이 잠재적인 문제를 일으키는지 묻습니다.
5. 설명과 가능한 해결책을 생성합니다.

이 파이프라인은 문제가 되는 문구를 식별할 수 있습니다. 하지만 누락된 요구 사항을 신뢰성 있게 식별할 수는 없습니다. 왜냐하면 검색 (retrieval)이 문서에 이미 존재하는 텍스트를 기반으로 시작되기 때문입니다.

예를 들어, 계약서에 위반 통지 (breach notification)에 관한 내용이 전혀 없다면, 그에 상응하는 요구 사항을 검색할 수 있는 위반 통지 관련 문구 자체가 존재하지 않을 수 있습니다.

누락 조항 탐지 (Missing-clause detection)는 검색의 방향을 반대로 돌려야 합니다:

각 조항이 어떤 요구사항과 일치하는지 묻는 대신, 적용 가능한 모든 필수 조항이 어떤 조항에 의해 다뤄지고 있는지 물어야 합니다.

2단계 접근 방식 (The two-stage approach)

저는 조항 추출 (clause extraction) 이후에 별도의 패스로 간극 분석 (gap analysis)을 구현했습니다. 이는 결정론적 검색 (deterministic retrieval) 단계와 제약 조건이 있는 모델 검토 (constrained model review)를 결합한 방식입니다.

높은 수준에서 프로세스는 다음과 같습니다:

contract
  -> extract clause inventory
  -> load required provisions for selected frameworks
...

이러한 분리가 중요한 이유는, 대규모 모델 (large model)을 사용하여 모든 규정 (regulation)을 모든 조항과 비교하는 것은 느리고 비용이 많이 들며 제어하기 어렵기 때문입니다. 순수 유사도 검색 (similarity search)은 비용은 더 저렴하겠지만, 너무 많은 거짓 양성 (false positives)을 생성할 것입니다.

1단계: 결정론적 후보 선택 (deterministic candidate selection)

첫 번째 단계는 빠른 커버리지 스크리닝 (coverage screen)을 위해 TF-IDF 유사도를 사용합니다.

모든 필수 조항에 대해, 시스템은 추출된 모든 조항에 걸쳐 가장 높은 유사도 점수를 기록합니다:

for clause in clauses:
    for provision, score in search(clause.text):
        coverage[provision.id] = max(
...

필수적이고 영향력이 큰 조항이 설정된 커버리지 임계값 (coverage threshold)에 도달하는 조항이 없을 때, 해당 조항은 간극 후보 (gap candidate)가 됩니다.

candidates = [
    provision
    for provision in required_provisions
...

이 단계는 의도적으로 스크리닝 단계로만 설계되었습니다. 낮은 어휘적 유사도 (lexical similarity)가 반드시 조항의 누락을 의미하는 것은 아닙니다. 계약서는 종종 서로 다른 어휘를 사용하여 동일한 의무를 표현하기 때문입니다.

다음 단계를 제한된 범위 내로 유지하기 위해, 후보들은 심각도 (severity)와 낮은 커버리지 순으로 우선순위가 지정되며, 프레임워크 (framework)별로 상한선이 설정됩니다.

2단계: 보수적인 모델 검증 (conservative model verification)

두 번째 단계에서는 모델에 다음 두 가지를 제공합니다:

• 계약 조항의 인벤토리 (inventory)
• 선별된 필수 조항 목록 (shortlisted required provisions)

각 조항에 대해 모델은 반드시 구조화된 데이터 (structured data)를 반환해야 합니다:

{
  "regulation_ref": "...",
  "addressed": false,
...

프롬프트는 의도적으로 보수적으로 설계되었습니다. 어떤 조항이든 그 주제를 부분적으로라도, 혹은 다른 표현을 사용하더라도 다루고 있다면 해당 조항은 처리된(addressed) 것으로 간주합니다. 또한 모델은 최종적인 법적 충분성(legal sufficiency)이 아니라, 커버리지(coverage) 여부를 판단하도록 지시받습니다.

시스템은 모델이 '처리되지 않음(unaddressed)'이라고 판단하고, 그 신뢰도(confidence)가 최소 임계값을 넘었을 때만 후보를 보고합니다.

이 두 번째 패스(pass)는 TF-IDF가 의미론적 일치(semantic match)를 놓친 사례들을 필터링합니다. 또한 인간 검토자가 확인할 수 있는 짧은 근거(rationale)를 생성합니다.

이것이 법적 결론이 아닌 이유

제품 홍보 문구에서 놓치기 쉬운 중요한 차이점이 있습니다:

“시스템이 커버리지를 찾지 못했다”는 것이 “계약서가 법을 위반했다”는 것과 동일한 의미는 아닙니다.

특정 조항이 실제로 필요한지 여부는 관할권, 당사자의 역할, 관련 데이터, 계약의 목적 등 텍스트 외부의 사실 관계에 따라 달라집니다. 모델은 간접적인 커버리지를 놓치거나 상호 참조(cross-reference)를 오해할 수도 있습니다.

그렇기 때문에 출력 결과는 판결(verdict)이 아닌 검토 대기열(review queue)로 제시되어야 합니다. AuditGuard에서 탐지 결과에는 출처 참조(source reference), 근거(rationale), 신뢰도(confidence), 그리고 제안된 초안 문구(suggested draft language)가 포함됩니다. 사용자는 여전히 적용 가능성과 문구를 확인해야 하며, 결정에 법적 리스크가 따르는 경우 자격을 갖춘 법률 고문(qualified counsel)을 참여시켜야 합니다.

배운 점

세 가지 설계 결정이 이 기능을 더욱 유용하게 만들었습니다.

1. 부재 탐지(absence detection)를 별도의 검색 문제로 취급하기

조항별 분석(clause-by-clause analysis)과 격차 분석(gap analysis)은 서로 반대되는 질문에 답합니다. 이 두 가지를 하나의 프롬프트에서 모두 처리하려고 하면 로직을 검사하고 테스트하기가 더 어려워집니다.

2. 전수 조사(exhaustive search)가 아닌 검증(verification)을 위해 모델 사용하기

결정론적 검색(Deterministic retrieval)은 탐색 공간을 줄여줍니다. 그런 다음 모델은 유사도 점수(similarity scoring)가 신뢰성 있게 답할 수 없는, 더 좁은 범위의 의미론적 질문을 처리합니다.

3. 검토 가능성(reviewability) 최적화하기

인용(citation)이나 근거(rationale)가 없는 누락 조항 경고는 신뢰하기 어렵습니다. 각 탐지 결과는 검토자에게 무엇이 누락되었을 수 있는지, 왜 그것이 선택되었는지, 그리고 어떤 출처 요구 사항이 이를 트리거했는지를 알려주어야 합니다.

더 넓은 패턴

이 접근 방식은 계약서에만 국한되지 않습니다. 동일한 패턴을 보안 정책(security policies)에서의 누락된 통제 항목(missing controls), 기술 사양서(technical specifications)에서의 누락된 섹션, 또는 조달 응답(procurement responses)에서의 다뤄지지 않은 요구 사항을 찾는 데에도 활용할 수 있습니다.

1. 존재하는 것들의 인벤토리(inventory)를 구축합니다.
2. 충족되어야 할 요구 사항 세트를 정의합니다.
3. 충족 수준이 낮은 요구 사항들을 저비용으로 선별(shortlist)합니다.
4. 해당 후보들을 의미론적으로 검증(semantically verify)합니다.
5. 불확실한 결과는 사람에게 전달합니다.

문제가 있는 텍스트를 찾는 것은 분류(classification)입니다. 누락된 텍스트를 찾는 것은 커버리지 분석(coverage analysis)입니다. 이 둘을 별개의 문제로 취급하면 검색 로직(retrieval logic)을 테스트하기가 더 쉬워지고, 모델 사용 범위를 제한하며, 출력 결과의 검토 가능성을 유지할 수 있습니다.

공개 사항: 저는 이 글에서 논의된 제품인 AuditGuard를 개발했습니다. AuditGuard는 정보 제공 목적으로 AI 지원 컴플라이언스 분석(compliance analysis)을 제공하며, 법률적 조언을 제공하지 않습니다. 저는 이 글을 편집하는 데 AI를 사용하였으며, 출판 전 구현 사항과 대조하여 기술적 주장을 검토하였습니다.