Agentic Due Diligence: Ropes & Gray가 OpenAI와 실사 검토 절차를 에이전트로 옮긴 사례
미국 로펌 Ropes & Gray가 OpenAI와 함께 M&A 실사 도구를 만들고 있습니다. 변호사가 데이터룸을 검토하는 순서를 에이전트 워크플로로 옮기고 모든 단계에 변호사 감독을 둡니다. 며칠~몇 주 걸리던 쟁점별 보고서를 몇 시간 안에 내는 것이 목표입니다. 쟁점 JSON 필드와 6주 파일럿안을 붙였습니다.
Ropes & Gray는 법률 AI를 범용 도구로 사서 쓰지 않았습니다. 자기 변호사들이 데이터룸을 읽는 순서를 그대로 에이전트 워크플로로 옮기고 판단은 변호사 손에 남겼습니다. 따라 하려면 먼저 우리 팀의 검토 체크리스트를 문서로 꺼내 놓아야 하고 과거 딜 하나를 다시 돌려 사람의 쟁점 목록과 맞춰 봐야 합니다.
요약
미국 대형 로펌 Ropes & Gray는 2026년 9월 OpenAI와 함께 거래 실사(transactional due diligence, 인수 전에 대상 회사의 계약·부채·규제 문제를 확인하는 일)용 전용 도구를 개발하고 있다고 밝혔습니다. 도구의 중심은 맞춤형 agentic AI workflow(에이전트가 여러 단계를 차례로 수행하는 작업 흐름)입니다. 변호사가 가상 데이터룸(virtual data room, 매도 측이 실사용 문서를 올려 두는 온라인 저장소)을 검토할 때 밟는 단계를 따라가면서 리스크와 예외를 표시하고 핵심 쟁점을 앞당겨 드러냅니다. 로펌의 검토 방법론을 워크플로에 넣어 1차 검토를 딜마다 같은 방식으로 반복하게 만든 것이 설계의 뼈대입니다.
목표는 쟁점별 보고서(issue-level report)를 몇 시간 안에 내는 것입니다. 지금은 변호사 여러 명이 며칠에서 몇 주 동안 문서를 나눠 읽어야 나오는 결과물입니다. 도구는 1차 검토와 결과 취합을 맡고 최종 법률 판단은 맡지 않습니다. 변호사 감독은 모든 단계에 들어가고 결과물에는 기존 업무와 같은 보안·비밀 유지 통제가 적용됩니다. 로펌이 내세운 효과는 두 가지입니다. 변호사가 취합 작업에서 풀려나 리스크 분석과 거래 구조 검토, 고객 자문에 시간을 더 쓰게 됩니다. 입찰 마감이 빠듯한 경쟁 인수에서는 쟁점을 일찍 찾은 만큼 가격과 구조를 조정할 여유가 생깁니다. 아래에서는 이 구조를 다섯 가지 메커니즘으로 나누고 실제로 돌릴 때 필요한 기술·현업 디테일을 덧붙입니다.
핵심 메커니즘
Methodology-encoded workflow: 로펌의 검토 순서를 그대로 옮긴 작업 흐름
에이전트에게 “문서를 읽고 리스크를 찾아라”라고 시키지 않습니다. 로펌이 이미 쓰는 검토 방법론을 단계로 나눠 워크플로에 넣습니다. 입력은 방법론과 쟁점 체크리스트이고 처리는 단계별 에이전트 작업, 출력은 딜마다 같은 형식의 1차 검토 결과입니다. 보도는 이 점을 반복 가능성(repeatable)으로 설명합니다. 같은 데이터룸을 누가 맡든 같은 순서로 읽히니, 검토 품질이 담당 변호사의 경험에 덜 좌우됩니다. 방법론이 문서로 정리된 조직에 맞고 검토 기준이 사람마다 다른 조직에서는 먼저 기준부터 합의해야 합니다.
Issue-level report: 문서 단위가 아니라 쟁점 단위로 묶은 보고서
이 도구는 결과를 문서별 요약으로 쌓지 않고 쟁점 단위로 묶습니다. 보도에 나온 쟁점 유형은 계약상 의무, change of control(지배권 변경 시 계약 상대방에게 해지·재협상 권리가 생기는 조항), 동의 요건, 부채, 예외 사항, 규제 문제, 소송 리스크입니다. 주니어와 시니어 변호사가 이런 항목을 병렬로 확인하느라 손이 많이 드는 부분을 겨냥했습니다. 쟁점 단위로 묶어야 딜 팀이 “이 거래를 바꿀 문제가 무엇인가”에 바로 답할 수 있습니다. 가상 예시로, 대상 회사의 공급 계약 40건 중 지배권 변경 조항이 있는 계약만 한 표에 모아 근거 페이지와 함께 보여 주는 식입니다.
Lawyer-in-the-loop: 모든 단계에 변호사 감독을 넣는 구조
도구는 1차 검토와 결과 취합까지 하고 최종 판단은 하지 않습니다. 발표는 변호사 감독이 과정 전체에 들어간다고 밝혔고 산출물은 기존 업무와 같은 일관성·비밀 유지·보안 통제를 받는다고 했습니다. 실사 문서에는 기밀 회사 정보와 미공개 중요 정보(MNPI, 공개 전 주가에 영향을 줄 수 있는 정보)가 섞여 있습니다. 그래서 로펌은 엔터프라이즈급 보안 통제를 함께 내세웠습니다. 에이전트가 쟁점을 표시하면 변호사가 근거를 대조해 오탐과 누락을 고치고 중요도를 정한 뒤 보고서를 승인하는 흐름으로 이해하면 됩니다.
Earlier surfacing: 쟁점을 앞당겨 거래 수단으로 바꾸기
속도의 가치는 시간 절약에만 있지 않습니다. 로펌은 쟁점을 일찍 찾으면 고객이 입찰 마감 전에 가격 조정, 거래 구조 변경, 보호 조항 협상, 특정 리스크 추가 조사를 할 수 있다고 설명합니다. 실사 결과가 마감 직전에 나오면 이런 선택지는 대부분 닫힙니다. 경쟁 입찰처럼 일정이 빠듯한 거래에서 효과가 크고 일정 여유가 있는 내부 구조조정에서는 효과가 작습니다.
Multi-tool architecture: 한 업체에 묶이지 않는 도구 구성
Ropes & Gray는 이 도구를 회사 AI 전략의 일부로 소개하면서 단일 업체가 아니라 여러 도구를 조합하는 구조를 쓴다고 밝혔습니다. AI 활용 교육을 받은 변호사와 도구를 짝지운다는 점도 함께 강조했습니다. OpenAI는 같은 달 법률용 제품 Astra for Law를 발표하면서 Ropes & Gray를 포함한 네 로펌이 자체 도구를 함께 만들고 있다고 소개했습니다. 범용 법률 제품이 나와도 실사처럼 로펌 고유의 방법론이 담긴 업무는 따로 짓는다는 선택입니다.
통념과 다른 주장
흔히 이렇게 봅니다법률 AI는 시장에 나온 범용 플랫폼을 도입해 쓰면 된다고 봅니다.
저자는 이렇게 봅니다Ropes & Gray는 실사처럼 시간이 가장 많이 드는 업무는 자기 검토 방법론을 담은 전용 워크플로로 만들고 전체는 여러 도구를 조합합니다.
근거OpenAI가 법률용 제품을 내놓은 같은 시기에 이 로펌은 OpenAI와 별도로 실사 도구를 공동 개발했습니다. 회장 Julie Jones는 이를 "bringing frontier AI to the most time-intensive legal work"라고 설명했습니다.
흔히 이렇게 봅니다AI 실사 도구의 가치는 변호사를 대신해 판단까지 내리는 데 있다고 봅니다.
저자는 이렇게 봅니다도구는 1차 검토와 취합까지만 하고 판단은 변호사가 합니다. 가치는 변호사의 통찰이 거래 과정에 더 일찍 들어가는 데 있습니다.
근거발표는 최종 법률 판단을 도구의 범위에서 빼고 모든 단계에 변호사 감독을 둔다고 밝혔습니다.
저자가 든 사례
Ropes & Gray와 OpenAI의 딜 실사 도구
| 구분 | 내용 |
|---|---|
| 상황 | 실사는 변호사 여러 명이 데이터룸 문서를 며칠~몇 주 나눠 읽는 일. 문서량이 많고 큰 데이터 세트 전반에서 판단을 일관되게 유지해야 함 |
| 한 일 | OpenAI와 맞춤형 에이전트 워크플로를 공동 개발. 변호사의 데이터룸 검토 단계를 따라 리스크·예외를 표시하고 쟁점별로 취합. 모든 단계에 변호사 감독 |
| 결과 | 목표는 쟁점별 보고서를 몇 시간 안에 내는 것. 개발 단계로 발표됐고 정확도·처리 시간 실측치, 쓰인 모델, 배포 일정은 원문에서 밝히지 않음 |
| 연결 | Methodology-encoded workflow, Issue-level report, Lawyer-in-the-loop |
OpenAI의 Astra for Law와 함께 소개된 네 로펌
| 구분 | 내용 |
|---|---|
| 상황 | OpenAI가 2026년 9월 GPT-6 Astra 기반 법률용 제품 Astra for Law를 발표 |
| 한 일 | Ropes & Gray, Latham & Watkins, Sullivan & Cromwell, Cooley가 OpenAI와 자체 도구를 개발. Latham과는 정보 권한, 윤리 장벽, 고객 지시, 로펌 감독을 함께 설계 |
| 결과 | 선정된 로펌은 ChatGPT와 Codex로 먼저 쓰고 API 제공은 나중에 열릴 예정 |
| 연결 | Multi-tool architecture. 범용 제품과 로펌 전용 워크플로가 함께 가는 구도 |
기술 디테일: 실사 에이전트를 실제로 돌리려면
Methodology-encoded workflow를 돌리려면 체크리스트를 먼저 기계가 읽는 형태로 바꿔야 합니다. 로펌의 실사 체크리스트는 대개 워드 문서나 엑셀입니다. 쟁점마다 issue_type, 찾을 조항의 정의, 해당 문서 유형, “있으면 표시”와 “없으면 표시” 규칙을 한 행으로 정리합니다. 이 표가 에이전트의 단계 목록이 됩니다. 단계는 문서 분류, 쟁점별 조항 찾기, 예외 판정, 쟁점별 취합의 네 개 안팎으로 나누고 한 번의 호출에 문서 하나와 쟁점 하나만 넣어 결과를 비교하기 쉽게 만듭니다.
Issue-level report를 만들려면 출력 형식을 JSON으로 고정합니다. 아래는 실제로 돌릴 때 쓸 수 있는 필드 예시입니다(가상 예시).
{
"issue_type": "change_of_control",
"doc_id": "VDR-03-0142",
"doc_title": "공급 기본계약",
"page": 7,
"clause_span": "제12조 2항",
"finding": "지배권 변경 시 상대방 해지권",
"exception_flag": true,
"consent_required": true,
"severity_draft": "high",
"confidence": 0.82,
"reviewer": null,
"reviewer_status": "pending"
}
page와 clause_span은 비워 둘 수 없게 합니다. 근거 페이지가 없는 표시는 변호사가 확인할 수 없으니 자동으로 버립니다. severity_draft는 에이전트의 초안일 뿐이고 최종 중요도는 reviewer_status가 approved일 때 변호사가 정한 값만 보고서에 올립니다. temperature는 0~0.2로 낮게 두고 같은 문서·쟁점을 2회 돌려 exception_flag가 엇갈리면 사람 검토 대기열로 보냅니다. 발표는 쓰인 모델을 밝히지 않았습니다. 직접 만든다면 긴 계약서를 한 번에 넣을 수 있는 모델로 추출하고 high로 표시된 건만 다른 모델로 한 번 더 판정해 엇갈리는 건을 따로 모으는 방법을 쓸 수 있습니다.
Lawyer-in-the-loop를 기록으로 남기려면 감사 로그가 필요합니다. 표시마다 누가 언제 확인했고 무엇을 고쳤는지 남깁니다. 오탐과 누락을 쟁점 유형별로 모으면 다음 딜에서 체크리스트 규칙을 고칠 근거가 됩니다. MNPI가 섞인 문서를 다루므로 딜별 작업 공간을 분리하고 같은 로펌 안에서도 윤리 장벽이 걸린 팀은 접근을 막습니다. 모델 제공자 쪽 데이터 보관·학습 사용 조건도 계약 단계에서 확인합니다.
실패하는 경우와 대응. 스캔 상태가 나쁜 문서는 OCR 품질 점수가 기준 아래면 에이전트 검토에서 빼고 사람에게 넘깁니다. 본계약과 변경계약이 따로 올라온 경우는 조항이 뒤에서 바뀌므로, 같은 계약 묶음을 하나로 엮는 contract_family_id를 둡니다. 영어 외 언어 문서는 번역 결과가 아니라 원문 페이지를 근거로 남깁니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 하는 일 |
|---|---|---|
| 스폰서 | M&A 담당 파트너 또는 법무 책임자 | 파일럿 딜 선정, 6주차 확대 결정 |
| 방법론 오너 | 시니어 어소시에이트 1명 | 체크리스트를 쟁점 표로 정리, 판정 기준 확정 |
| 검토 변호사 | 어소시에이트 2~3명 | 에이전트 표시 확인·수정, 누락 기록 |
| 리걸 엔지니어 | 법률 기술팀 또는 외부 파트너 | 워크플로·JSON 스키마·검토 화면 구성 |
| 보안 담당 | IT·정보보호 | 딜별 작업 공간 분리, 접근 권한, 로그 보관 |
준비물은 세 가지입니다. 문서로 정리된 실사 체크리스트, 이미 종결된 과거 딜 하나의 데이터룸 사본과 그때 변호사가 쓴 실사 메모, 그리고 고객 동의와 보안 검토를 거친 작업 환경입니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 체크리스트를 쟁점 표로 변환, 과거 딜 선정, 보안 검토 | 쟁점 정의표, 작업 공간 |
| 3~4주 | 과거 딜을 에이전트로 다시 실사하고 당시 실사 메모와 대조 | 쟁점별 일치·누락 표 |
| 5~6주 | 진행 중인 딜 하나에 사람 검토와 병행 투입 | 병행 결과, 확대 여부 판정 |
검토 변호사에게는 매주 같은 질문을 던집니다. 에이전트가 놓친 쟁점이 있었나, 그 쟁점은 체크리스트에 있었나, 근거 페이지만 보고 판단할 수 있었나, 표시를 고치는 데 문서를 처음부터 읽는 것보다 시간이 덜 들었나. 진행 판정 기준(예시)은 이렇게 잡습니다. 과거 딜에서 당시 메모의 high 쟁점을 하나도 놓치지 않을 것, 쟁점 목록 초안이 데이터룸 개방 후 하루 안에 나올 것, 변호사가 고친 표시가 전체의 30% 이하일 것. 첫 기준을 못 맞추면 범위를 쟁점 유형 두세 개로 좁혀 다시 돌립니다.
로펌이 아니어도 같은 구조를 쓸 수 있습니다. 기업 법무팀의 인수 실사, 구매팀의 협력사 계약 일괄 점검, 규제 변경 때 기존 계약 전수 확인이 같은 모양입니다. 순서는 Ropes & Gray와 같습니다. 범용 도구로 시작하더라도 자기 팀의 검토 기준을 쟁점 표로 꺼내는 일이 먼저이고 결과물은 쟁점 단위로 묶고 판단은 사람에게 남깁니다. 스폰서는 속도보다 “마감 전에 협상 카드가 몇 개 더 생겼나”로 성과를 재야 합니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 출처 | Pulse 2.0(2026.9.21), IT Brief(2026.9.25)의 Ropes & Gray 발표 보도. Legal Cheek(2026.9.18)의 Astra for Law 보도 |
| 주체 | Ropes & Gray와 OpenAI, 공동 개발 중인 전용 도구 |
| 대상 업무 | 거래 실사, 가상 데이터룸 문서 검토 |
| 방식 | 맞춤형 agentic AI workflow, 변호사 검토 단계를 따라 리스크·예외 표시, 로펌 방법론 반영 |
| 범위 | 1차 검토와 결과 취합. 최종 법률 판단은 제외 |
| 찾는 쟁점 | 계약상 의무, change of control, 동의 요건, 부채, 예외, 규제, 소송 리스크 |
| 감독·보안 | 모든 단계에 변호사 감독, 기존 업무와 같은 보안·비밀 유지 통제, 엔터프라이즈급 보안 |
| 목표 | 쟁점별 보고서를 며칠~몇 주에서 몇 시간으로 |
| 전략 | 여러 도구를 조합하는 구조, AI 교육을 받은 변호사 |
| 발언 | 회장 Julie Jones |
| 공개 안 됨 | 쓰인 모델, 정확도·처리 시간 실측치, 배포 일정, 계약 조건 |
| 같은 시기 | OpenAI Astra for Law(GPT-6 Astra 기반) 발표, 네 로펌이 자체 도구 공동 개발 |
핵심 개념
- Virtual data room
- 매도 측이 실사용 문서를 올려 두고 매수 측 자문단만 열람하게 하는 온라인 저장소.
- Change of control
- 회사 지배권이 바뀌면 계약 상대방이 해지하거나 조건을 다시 협상할 수 있게 하는 조항. 인수 실사의 단골 쟁점.
- MNPI
- Material nonpublic information. 공개되면 주가에 영향을 줄 수 있는 미공개 정보로, 다루는 사람과 시스템을 엄격히 제한해야 함.
- Ethical wall
- 같은 로펌 안에서 이해가 충돌하는 팀끼리 정보가 오가지 않게 막는 장치.
- Astra for Law
- OpenAI가 2026년 9월 발표한 법률용 제품. GPT-6 Astra에 법률 검색과 법률 업무용 설정을 붙임.
내 메모
TODO: 내 생각 추가
이 노트는 Ropes & Gray의 2026년 9월 발표를 다룬 Pulse 2.0 「Ropes & Gray And OpenAI Develop AI Deal Diligence Tool To Produce Issue-Level Reports In Hours」(Amit Chowdhry, 2026.9.21)를 중심으로 IT Brief(2026.9.25)와 Legal Cheek(2026.9.18) 보도를 함께 읽고 정리했습니다. OpenAI가 같은 사례를 고객 사례로 정리한 글(openai.com/index/ropes-gray-ai-diligence)은 이번에 열어 보지 못해 반영하지 않았습니다. 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 사례는 보도에 나온 사실을 AX Partners가 다시 정리했습니다. 기술·현업 실행 디테일, JSON 예시, 일정과 판정 기준, 인포그래픽은 실제로 돌릴 때 필요한 내용을 새로 작성한 것입니다. 전체 내용은 원문 보도에서 볼 수 있습니다.