오픈AI는 10월 15일 설리번 앤 크롬웰의 계약 분석 도구 Agreement Analyzer 사례를 소개했다. 로펌의 공식 기록에 따르면 이 도구는 9월 17일 뉴욕 행사에서 이미 시연됐고 18일 공동 개발 소식이 발표됐다. 따라서 이번 글을 10월에 처음 출시한 일반 소비자용 서비스로 소개하면 시점과 대상이 어긋난다. 변호사 존 사바가 초기 개념을 만들고 오픈AI 엔지니어와 함께 개선한 내부 업무 도구다. 기존 계약과 고객의 우선순위, 협상 경험을 한 검토 흐름 안에서 활용하는 데 초점을 둔다.
단일 사용자 실험에서 여러 변호사의 도구로
사바는 코덱스로 단일 사용자 개념 검증을 만든 뒤 결과의 품질과 효율을 다듬고 여러 변호사가 동시에 쓸 수 있는 형태로 확장했다고 설명한다. 도구에는 로펌이 선별한 계약 선례와 협상 지침, ChatGPT Enterprise가 연결된다. 사용자가 초안 계약과 추가 선례, 고객·로펌의 협상 입장 등을 넣으면 여러 검토 결과를 종합해 메모와 변경 추적이 가능한 수정 제안을 돌려준다. 최종 결과는 변호사가 읽고 바꾸거나 거절한다. 자료를 넣는 주체와 결과를 채택하는 주체를 남긴다는 점에서 계약을 자동으로 승인하는 시스템과 구분된다.
주장을 만든 근거와 남겨 둔 불확실성
원문은 시장 관행에 관한 주장이라면 그 정보의 출처를 볼 수 있어야 한다는 사바의 입장을 강조한다. 에이전트가 만든 결론에 다른 에이전트가 이의를 제기하는 방식도 설명한다. 시장과의 차이, 조항 상호작용, 모호성 등을 병렬로 살피는 구체 구성은 잠재적 사용 사례로 제시되므로 모든 항목이 이미 전면 운영된다고 확정할 수는 없다. 확인을 거쳐 남은 발견, 기각한 발견, 제한 조건을 붙여 보존한 미검증 사안을 구분하려는 구상이다. 에이전트가 동의했다는 사실만으로 법적 판단이 객관적으로 입증됐다는 의미도 아니다.
줄인 시간보다 주어진 시간의 검토 깊이
로펌의 10월 1일 공식 설명에서 사바는 단기 효과를 단순한 시간 단축보다 주어진 시간 안에서 더 철저하게 분석하도록 돕는 일로 표현했다. 작업마다 적합한 도구가 다르고 모델이 바뀌면 맞춤형 개발이 필요한 범위도 달라질 수 있다는 관점이다. 이번 공식 자료에는 독립적으로 재현할 수 있는 오류율이나 모든 계약 유형의 정확도 비교가 없다. 따라서 변호사 업무가 일정 비율 줄었다거나 모든 선례를 빠짐없이 찾는다는 수치를 붙일 수 없다. 확인 가능한 변화는 로펌의 경험을 도구에 넣고 그 결과를 검토자가 살필 형태로 정리하려는 작업 방식이다.
발견을 남기는 것과 수정안에 채택하는 것
검토 과정에서 나온 주장은 뒷받침되어 남을 수도, 반론 뒤 기각될 수도, 조건을 붙인 미확인 상태로 유지될 수도 있다. 세 상태를 모두 같은 경고 표시로 합치면 검토자는 무엇을 먼저 확인해야 할지 알기 어렵다. 불확실성을 지워 완성된 결론처럼 만드는 것보다 판단의 상태를 남기는 편집이 중요해진다.
변경 추적이 있는 수정안도 최종 계약의 확정과 다르다. 도구는 검토할 제안을 만들고 변호사는 자료와 고객의 우선순위에 맞춰 채택·변경·거절한다. 잠재적 병렬 검토 예시를 모든 계약의 상시 운영으로 넓히지 않고 읽으면, 자동화가 정보를 정리하는 부분과 전문가가 책임지는 결정을 구체적으로 나눌 수 있다.
| 상태 | 다음 검토의 질문 |
|---|---|
| 뒷받침된 발견 | 이 계약과 고객의 조건에도 적용할 것인가 |
| 기각한 발견 | 어떤 근거로 제외했는가 |
| 미확인 사안 | 무엇을 더 확인해야 결론을 낼 수 있는가 |
| 수정 제안 | 최종 문안에 채택·변경·거절할 것인가 |
계약 분석 도구의 역할은 선례와 협상 지침을 검토 가능한 메모·수정안으로 모으는 데 있다. 내부 도구의 개발 단계와 잠재적 활용을 구분하고, 채택과 거절의 판단은 변호사에게 남긴 구조로 읽어야 한다.
ARCH.B 의견
계약 검토 화면을 설계한다면 문장을 매끄럽게 고친 결과와 그 수정이 필요한 이유를 별도로 볼 수 있어야 한다. 어떤 선례를 비교했는지, 그 선례가 현재 거래와 다른 조건을 가졌는지까지 확인할 단서가 필요하다. 선례에 있다는 이유만으로 이번 고객에게 맞는 조항이 되는 것은 아니기 때문이다. 이를 인터페이스로 옮기면 수정 제안 옆에 근거 구간과 판단 상태를 연결하고, 변호사가 거절한 이유를 남기는 방식이 가능하다. 이는 특정 계약의 해석을 제시하는 법률 조언이 아니라 전문 검토자가 AI의 결과를 평가할 수 있게 만드는 제품 설계 관점이다.
다른 에이전트가 결론을 검토해도 같은 자료와 비슷한 가정을 공유하면 동일한 오류를 놓칠 수 있다. 여러 번 읽었다는 횟수보다 실제로 다른 근거와 반론을 살폈는지 확인하는 편이 중요하다. 운영 팀은 전문가가 확인한 오류와 놓친 쟁점을 모아 다음 평가에서 같은 입력으로 다시 살펴볼 수 있다. 검토자가 고친 이유도 남기면 오류가 자료 선택에서 왔는지 추론에서 왔는지 나눠 살필 수 있다. 근거를 찾지 못한 항목을 억지로 정답으로 바꾸지 않고 미확인으로 남기는 상태도 필요하다. 이 사례의 의미는 AI가 전문가 판단을 완성했다고 선언하는 데 있지 않다. 판단에 필요한 자료와 불확실성을 더 잘 드러내도록 검토 과정을 구성한 시도에 있다.