OpenAI와 Ironclad, 기업 법무 계약 검토에 Computer Use 에이전트 도입

발표 내용

OpenAI와 계약 수명주기 관리(CLM) 플랫폼 Ironclad는 최신 AI 에이전트와 Computer Use 기술을 기업 법무팀에 직접 제공하는 파트너십을 발표했다. Ironclad는 계약서의 작성부터 갱신까지를 관리하는 소프트웨어를 만드는 회사다. 발표에 따르면 Ironclad는 OpenAI의 에이전트 모델을 통합해, 에이전트가 브라우저 기반 법무 저장소를 탐색하고, 계약 조항을 조직의 플레이북과 대조하며, 레드라이닝과 컴플라이언스 확인 같은 복잡한 작업을 스스로 수행할 수 있게 한다.

발표는 몇 가지 주장을 더 담고 있다. 시스템은 Computer Use의 기본 기능과 깊은 API 연동을 결합한다. 자율적 추론으로 기존 ERP와 CRM 소프트웨어를 연결한다. 일상적인 계약 검토 주기를 70% 이상 줄인다. 그리고 결정론적인 사람 참여형 감사 가능성을 유지한다. 이 내용은 모두 발표 자체의 서술이며, 이 글은 수치를 독립적으로 검증하지 않았다.

작동 방식: 화면 계층과 API 계층의 병행

Computer Use의 기본 발상은 단순하다. 모델이 화면 스크린샷을 보고 클릭, 입력, 스크롤 같은 동작을 출력해, 직원처럼 소프트웨어를 쓴다. 장점은 상대 시스템이 인터페이스를 공개하지 않아도 쓸 수 있다는 점이다. 기업의 많은 시스템은 오래전에 만들어져 API가 불완전하거나 없고, 법무 담당자는 그 사이를 오가며 손으로 복사한다. Computer Use는 이 마지막 구간을 채운다.

다만 화면 기반 작업에는 알려진 약점이 있다. 속도가 느리고, 페이지 개편에 민감하며, 실패했을 때 재현하기 어렵다. 발표가 강조하는 것은 Computer Use와 깊은 API 연동을 나란히 쓰는 혼합 경로다. API가 있는 단계는 API로 처리해 계약 읽기나 상태 기록을 더 빠르고 안정적이며 기록하기 쉽게 하고, API가 닿지 않는 단계만 에이전트가 화면을 조작한다고 읽는 것이 합리적이다. 이런 계층화는 불확실한 부분을 소수의 단계로 모으고, 문제가 생겼을 때 책임 소재를 가리기 쉽게 한다.

추론 측면에서 에이전트가 하는 일은 단발성 질의응답이 아니라 여러 단계의 연쇄다. 계약을 찾고, 전문을 읽고, 조항 유형을 식별하고, 플레이북과 대조해 이탈 여부를 판단하고, 수정안을 만들고, 그 근거를 기록한다. 플레이북은 법무팀이 오랜 협상으로 쌓은 경험의 집약으로, 어떤 조건은 수용 가능하고 어떤 조건은 상위 승인이 필요하며 어떤 조건은 고쳐 써야 하는지를 정해 둔다. 이를 판단 기준으로 삼으면 결과물은 모델의 자유로운 창작이 아니라 기업이 정한 규칙 안에서의 실행이 된다. 어떤 모델을 쓰는지, 단계를 어떻게 구성하는지는 발표에 나오지 않으며, 세부 사항은 추가 설명을 기다려야 한다.

사람 참여와 감사 가능성

법무는 오류를 용납하기 어려운 분야다. 놓친 책임 제한 조항 하나가 수년 뒤 큰 손실로 이어질 수 있다. 그래서 발표는 결정론적인 사람 참여형 감사 가능성을 특히 강조한다. 이런 설계는 보통 세 가지 뜻을 담는다. 첫째, 에이전트의 제안은 변호사를 거치지 않고 효력을 갖지 않으며 핵심 단계에는 사람의 승인이 필요하다. 둘째, 각 동작과 인용된 플레이북 항목이 기록되어 사후에 검토할 수 있다. 셋째, 같은 입력에 같은 규칙을 적용하면 매번 다른 결과가 아니라 예측 가능한 결과가 나와야 한다.

여기서 결정론이라는 말은 한 번 더 생각해 볼 만하다. 대규모 언어 모델은 본질적으로 확률적이다. 전체 흐름을 결정론적으로 움직이게 하려면 보통 설계로 보완한다. 판단 근거를 기업의 플레이북에 고정하고, 동작을 미리 정한 범위로 제한하고, 출력을 구조화하고, 규칙 기반 검증을 안전망으로 더한다. Ironclad가 이 중 무엇을 쓰는지는 발표 요약에 나와 있지 않다. 도입하는 쪽에서 물어봐야 한다.

발표가 말하지 않은 것

이런 발표를 읽을 때는 말한 것과 말하지 않은 것을 구분해야 한다. 현재도 몇 가지 빈틈이 보인다. 70% 단축에는 표본 규모, 계약 유형, 기준선 정의가 없고, 사람의 검토 시간이 포함되는지도 불분명하다. 정확도나 누락률 같은 품질 지표는 제시되지 않았다. 가격, 제공 형태, 데이터 처리 조건도 공개되지 않았다. 인터페이스가 바뀌거나 로그인에 문제가 생겼을 때 시스템이 어떻게 대응하는지도 설명이 없다. 이런 빈틈이 메워지기 전까지 70%는 예산에 넣을 숫자가 아니라 방향을 보여 주는 신호로 보는 것이 맞다.

개발자, 기업, 업계에 주는 의미

개발자에게 이 사례는 에이전트 응용이 범용 시연에서 개별 업무 영역으로 옮겨 가고 있음을 보여 준다. 진짜 어려움은 모델이 버튼을 누를 수 있느냐가 아니라, 기업이 이미 갖춘 권한, 로그, 승인 체계에 모델을 어떻게 연결하느냐에 있다. API 계층, 화면 계층, 사람 검토 계층을 함께 설계하는 팀이 단일 기능만 만드는 팀보다 유리하다.

법무 부서에게 가장 현실적인 가치는 변호사를 반복 업무에서 해방하는 것이다. 표준 비밀유지계약, 구매 계약, 갱신 조항은 에이전트가 먼저 1차 검토와 표시를 하고, 변호사는 예외와 협상에 집중할 수 있다. 다만 기업이 자사 플레이북을 명확하고 실행 가능한 규칙으로 정리해 두었다는 전제가 필요하다. 플레이북이 모호하면 에이전트는 모호함을 키울 뿐이다.

업계에게는 Computer Use를 규제가 엄격한 분야로 가져가는 공개적인 시도다. 법무는 정확해야 하고 기록도 남겨야 한다. 이 방식이 성립하면 금융, 의료, 보험처럼 규제가 엄격하고 시스템이 복잡한 분야도 비슷한 방식을 채택할 근거가 커진다.

전망과 과제

앞으로 지켜볼 질문이 몇 가지 있다. 첫째는 독립적인 검증이다. 제3자나 고객이 비슷한 효과를 재현할 수 있는가. 둘째는 책임 분담이다. 에이전트의 제안이 틀렸는데 변호사도 놓쳤다면 누가 책임을 지는지, 계약과 보험이 이를 따라가고 있는지가 문제다. 셋째는 데이터 보안이다. 계약서에는 영업 비밀이 많아 데이터 분리와 학습 사용 여부에 대한 분명한 약속이 필요하다. 넷째는 안정성이다. 화면 자동화는 페이지 변경에 민감하므로 장기 유지 비용이 어떨지 봐야 한다. 다섯째는 규제다. 법률 서비스에서의 자동화 규정은 지역마다 달라 각 기업이 자체 한계를 가늠해야 한다.

전체적으로 방향은 분명하고 접근은 실용적이다. 하나의 기술에 걸지 않고 화면 자동화, API 연동, 사람의 검토를 결합한다. 약속을 지킬 수 있을지는 앞으로 공개될 데이터와 고객 반응에 달려 있다.