Devlery
Blog/AI

Docusign Agent Studio, 계약서가 실행 계층이 되는 순간

Docusign이 Iris 기반 AI assistant, agents, Agent Studio, MCP beta를 공개했습니다. 전자서명 이후 계약서가 업무 시스템을 움직이는 실행 계층으로 바뀌고 있습니다.

Docusign Agent Studio, 계약서가 실행 계층이 되는 순간
AI 요약
  • 무슨 일: Docusign이 Iris 기반 AI assistant, agents, Agent Studio, MCP beta를 공개했습니다.
    • 2026년 5월 21일 Momentum 발표 기준, assistant·agents·Agent Studio는 미국 early access이고 7월 미국 롤아웃을 예고했습니다.
  • 의미: 계약서가 서명 후 보관되는 PDF에서, 승인·리스크·갱신·CRM 업데이트를 움직이는 업무 실행 계층으로 이동합니다.
  • 개발자 포인트: Docusign MCP는 Claude, Gemini, ChatGPT 같은 frontier model이 계약 데이터를 도구처럼 다루는 경로를 엽니다.
  • 주의점: 계약 agent는 편리한 자동화인 동시에 권한, 감사 로그, human oversight, 비용 단위가 같이 설계돼야 하는 고위험 업무입니다.

전자서명의 상징처럼 여겨졌던 Docusign이 이제 "서명"보다 그 앞뒤의 업무를 더 크게 말하기 시작했습니다. 회사는 2026년 5월 21일 Momentum 컨퍼런스에서 Iris 기반 AI assistant, 계약 agent, Agent Studio, 그리고 MCP beta를 공개했습니다. 공식 발표의 표현을 빌리면, 목표는 계약을 "정적 기록"에서 "비즈니스 결정을 안내하고 일을 앞으로 움직이는 시스템"으로 바꾸는 것입니다.

이 문장은 마케팅처럼 들릴 수 있습니다. 하지만 이번 발표가 흥미로운 이유는 구체적인 제품 경계가 함께 제시됐기 때문입니다. Docusign agent는 계약서를 회사 표준과 대조해 검토하고, 수정안을 제안하며, 승인 요청을 보내고, 계약 의무와 리스크를 백그라운드에서 추적합니다. Agent Studio는 조직마다 다른 deal, renewal, approval 흐름에 맞춰 custom agent를 만드는 공간입니다. MCP는 Anthropic Claude, Google Gemini, OpenAI ChatGPT 같은 외부 모델이 Docusign의 계약 데이터와 작업을 다루는 연결 계층입니다.

결국 질문은 "계약서를 AI가 요약할 수 있는가"가 아닙니다. 그 질문은 이미 낡았습니다. 더 중요한 질문은 이것입니다. 계약서가 회사의 영업, HR, 법무, 구매, 재무 시스템을 실제로 움직이는 도구가 될 수 있는가. 그리고 그 도구를 외부 agent와 내부 workflow가 함께 안전하게 호출할 수 있는가.

Docusign AI assistant and agents 공식 이미지

전자서명의 다음 시장은 어디인가

Docusign은 전자서명을 대중화한 회사입니다. 하지만 전자서명 자체는 점점 독립 제품이 아니라 기능이 되고 있습니다. PDF 도구, 문서 관리 도구, CRM, HR 플랫폼, 협업 도구가 모두 서명 기능을 품습니다. 사용자는 "서명하러 Docusign에 간다"기보다, 이미 쓰는 Salesforce, Microsoft, Workday, SAP, Slack 안에서 문서와 승인을 처리하고 싶어 합니다.

그래서 Docusign이 Intelligent Agreement Management, 줄여서 IAM을 밀어 온 흐름은 자연스럽습니다. 서명 버튼만으로는 계약 업무의 병목을 충분히 설명할 수 없습니다. 계약은 작성, 검토, 승인, 협상, 서명, 보관, 갱신, 의무 이행, 감사까지 이어지는 긴 흐름입니다. 많은 회사에서 이 흐름은 이메일, PDF, CRM 필드, 스프레드시트, 법무 시스템, HR 시스템 사이에 흩어져 있습니다.

공식 발표에서 Docusign은 이 문제를 "계약 데이터가 정적 문서 안에 갇혀 있다"고 설명합니다. 이 표현이 핵심입니다. AI agent에게 문서는 단순한 파일이 아닙니다. 문서 안의 조항, 의무, 예외, 날짜, 가격, 승인 조건, 갱신 조건은 모두 tool call의 입력이 될 수 있습니다. 계약서가 구조화되고, 권한이 붙고, 시스템 이벤트와 연결되면 agent는 "이 계약을 요약해줘"를 넘어 "이 계약이 회사 표준과 충돌하는지 확인하고, 필요한 사람에게 승인 요청을 보내고, CRM의 갱신 단계를 업데이트해줘"까지 갈 수 있습니다.

이것은 Docusign만의 이야기가 아닙니다. Salesforce는 CRM을 Agentforce의 작업장으로 바꾸고 있고, ServiceNow는 업무 티켓을 agent의 실행 표면으로 만들고 있습니다. Notion은 문서와 데이터베이스를 agent workspace로 확장하고, Google과 Microsoft는 검색과 오피스 문서를 agent의 기본 화면으로 바꾸고 있습니다. Docusign의 차별점은 계약이라는 고가치 문서 도메인에 집중한다는 점입니다. 계약은 숫자, 책임, 법적 리스크, 승인 경로가 모두 들어 있는 데이터입니다. 한 번 잘못 움직이면 단순한 UX 문제가 아니라 매출 인식, 컴플라이언스, 고용, 개인정보, 공급망 리스크가 됩니다.

이번 발표의 제품 구성

이번 Docusign 발표는 네 가지 층으로 나눠볼 수 있습니다.

첫째, Iris assistant입니다. Iris는 Docusign의 agreement AI engine으로 소개됩니다. 사용자는 자연어로 계약서에 질문하고, 핵심 조건과 의무를 찾고, 다음 행동을 요청할 수 있습니다. 중요한 점은 assistant가 단순 Q&A에 머물지 않는다는 것입니다. Docusign은 Iris가 계약 저장소, envelope status, approval 생성, 알림, repository 검색 같은 도구를 사용할 수 있도록 설계됐다고 설명합니다.

둘째, 계약 agent입니다. 공식 발표에 따르면 agent는 회사 표준에 맞춰 계약을 검사하고, 수정안을 제안하며, 적절한 승인 요청을 자동으로 보낼 수 있습니다. 또 백그라운드에서 계약을 모니터링해 리스크를 표시하고, obligation을 추적하며, 수동 follow-up 없이 다음 단계를 트리거할 수 있습니다. 5월 11일 법무팀 대상 발표에서는 agent가 과거 협상, 수용된 조항, 회사 정책을 바탕으로 다음 단계를 추천한다고 설명했습니다.

셋째, Agent Studio입니다. 이 부분이 개발자와 AI 제품 팀에게 더 흥미롭습니다. Agent Studio는 Docusign 안에서 custom agreement agent를 만들고 테스트하는 작업 공간입니다. 조직마다 계약 흐름은 다릅니다. 어떤 회사는 할인 승인 기준이 복잡하고, 어떤 회사는 개인정보 처리 부속합의서가 병목이며, 어떤 회사는 HR 계약과 I-9 검증이 반복 작업입니다. Agent Studio는 이런 도메인별 규칙을 "우리 회사 계약 agent"로 묶는 방향입니다.

넷째, MCP와 외부 ecosystem입니다. Docusign은 MCP를 통해 Anthropic Claude, Gemini, OpenAI ChatGPT 같은 frontier model과 연결한다고 밝혔습니다. 또 Coupa, Microsoft Copilot, Salesforce, SAP, Slack 같은 업무 시스템, Harvey, Legora, Thomson Reuters CoCounsel 같은 legal AI 플랫폼과의 통합도 강조했습니다. 즉 Docusign은 자신을 하나의 챗봇 UI로만 팔지 않습니다. 외부 모델, 업무 앱, 법률 특화 도구가 계약 workflow를 호출할 수 있는 agreement platform으로 자리 잡으려 합니다.

계층Docusign 발표 내용실무 의미
AI assistantIris가 계약 질문, 조건 검색, action 요청을 처리계약 저장소가 검색 UI를 넘어 자연어 작업 표면이 됨
Agents리뷰, redline, 승인 요청, obligation 추적, risk flag사람이 하던 follow-up과 정책 대조가 workflow로 이동
Agent Studio조직별 deal, renewal, approval agent를 생성·배포도메인 규칙과 승인 체계가 agent 설계 자산이 됨
MCPClaude, Gemini, ChatGPT 등 외부 모델과 연결계약 데이터가 외부 agent의 tool layer로 노출됨

왜 MCP가 여기서 중요해지는가

MCP는 요즘 거의 모든 agent 발표에 붙는 단어가 됐습니다. 그래서 오히려 피로감을 줍니다. 하지만 계약 관리에서는 MCP의 의미가 비교적 분명합니다. 계약 데이터는 범용 LLM이 그냥 학습해서 알 수 있는 정보가 아닙니다. 회사별로 접근 권한이 다르고, 버전이 바뀌며, 서명 상태와 승인 상태가 업무 시스템에 흩어져 있습니다. 모델이 계약서 내용을 읽는 것만으로는 부족합니다. 어떤 계약이 최신인지, 누가 승인해야 하는지, 어느 시스템에 반영해야 하는지, 어떤 조항이 회사 정책과 충돌하는지를 도구 호출로 확인해야 합니다.

MCP는 이런 도구 호출을 표준화하려는 흐름입니다. Docusign MCP가 충분히 성숙하면, 사용자는 ChatGPT나 Claude에서 "다음 분기 갱신 대상 중 가격 인상 조항이 있는 계약을 찾아 영업 담당자에게 알림을 보내줘"라고 요청할 수 있습니다. 모델은 Docusign에서 계약을 검색하고, 조건을 읽고, 관련 CRM이나 Slack 작업으로 넘길 수 있습니다. 물론 실제 제품이 이 수준을 어디까지 지원하는지는 세부 권한과 integration 범위에 달려 있습니다. 하지만 방향은 분명합니다. 계약 플랫폼이 agent에게 안전한 action surface를 제공하는 것입니다.

이 지점에서 Docusign의 발표는 OpenAI, Anthropic, Google의 agent 전략과 맞닿습니다. 프론티어 모델 회사들은 더 긴 작업을 수행하는 agent를 팔고 싶어 합니다. 하지만 agent가 실제 기업 업무를 하려면 도메인 시스템의 권한 있는 도구가 필요합니다. 계약, 결제, 고객 데이터, HR 데이터, 구매 데이터 같은 곳에는 "스크래핑해서 읽기"가 통하지 않습니다. 명시적 API, 감사 로그, 승인 정책, 권한 모델이 필요합니다. Docusign MCP는 그 중 계약 영역의 후보입니다.

계약 agent는 작지만 위험한 자동화다

TechTarget은 이번 발표를 두고 Docusign이 전자서명 인접 영역으로 더 깊이 들어가며 Salesforce, Oracle, ServiceNow, Adobe, CLM 업체와 경쟁하려는 움직임으로 해석했습니다. 이 보도에서 흥미로운 대목은 전문가 코멘트입니다. Deep Analysis의 Alan Pelz-Sharpe는 일부 vendor가 "SAP를 없애겠다"거나 대규모 인력 감축을 말하는 동안, 실제 고객은 PDF를 채울 수 있는 양식으로 바꾸거나 반복 follow-up을 줄이는 종류의 지루한 업무 자동화를 원한다고 평가했습니다.

이 말은 계약 agent의 현실적인 출발점을 잘 짚습니다. 계약 자동화의 첫 단계는 법무팀 전체를 대체하는 것이 아닙니다. 오히려 작고 반복적이지만 비싼 병목을 줄이는 것입니다. 예를 들어 NDA가 회사 표준과 다른 조항을 포함하는지 확인합니다. 갱신일 90일 전 알림을 보냅니다. 할인 승인 기준을 넘은 계약을 매니저에게 라우팅합니다. HR 입사 서류에서 빠진 필드를 확인합니다. PDF 양식을 interactive web form으로 바꿉니다. 이런 작업은 과장된 AGI 데모보다 지루하지만, 실제 조직 비용에 더 직접적으로 닿습니다.

다만 작다고 안전한 것은 아닙니다. 계약 agent는 권한 경계를 잘못 잡으면 위험합니다. 계약 조항을 잘못 해석해 승인 요청을 건너뛰거나, 갱신 조건을 놓치거나, 잘못된 사람에게 민감한 계약을 노출할 수 있습니다. MCP 연결은 편리하지만, 외부 모델과 외부 도구가 계약 데이터에 접근하는 경로이기도 합니다. 따라서 실무 도입에서는 "agent가 무엇을 할 수 있는가"보다 "무엇을 혼자 하면 안 되는가"를 먼저 정해야 합니다.

특히 계약 workflow에는 human oversight가 형식이 아니라 설계 핵심이 됩니다. Docusign도 법무팀 대상 발표에서 필요한 곳에 human oversight와 control을 유지한다고 설명했습니다. 중요한 계약 변경, 법적 리스크가 있는 redline, 가격과 liability가 걸린 조항, 개인정보 처리 관련 조건은 agent가 제안하더라도 사람이 승인해야 합니다. 좋은 계약 agent 플랫폼은 자동화율만 높이는 것이 아니라, 어떤 작업을 자동 승인하고 어떤 작업을 검토 큐로 보내는지 정책화할 수 있어야 합니다.

30% ROI 주장은 어떻게 봐야 하나

Docusign은 Deloitte의 2026년 보고서를 인용해 AI-driven workflow와 end-to-end agreement platform을 쓰는 조직이 그렇지 않은 조직보다 ROI가 약 30% 높다고 주장했습니다. 이런 수치는 발표 자료에서 자주 보이는 문장이라 곧장 결론으로 받아들이면 위험합니다. 어떤 산업, 어떤 조직 규모, 어떤 maturity 기준인지에 따라 ROI는 크게 달라집니다. 또 Docusign의 고객과 prospective customer를 대상으로 한 research가 제품 도입 효과를 어느 정도 과대 반영할 가능성도 봐야 합니다.

그럼에도 이 숫자가 완전히 무의미한 것은 아닙니다. 계약 업무는 병목이 명확합니다. 반복 검토, 승인 대기, 데이터 재입력, 갱신 누락, 의무 추적 실패, 계약 상태 확인, 법무와 영업 사이의 핑퐁이 비용을 만듭니다. 계약이 매출, 고용, 공급망, 파트너십의 관문이라면, 여기에 agent를 붙이는 ROI 논리는 비교적 단순합니다. 처리 시간이 줄고, 누락이 줄고, 사람이 더 비싼 판단에 집중할 수 있으면 가치가 생깁니다.

다만 자동화의 비용도 함께 계산해야 합니다. Agent Studio에서 agent를 만들고 유지하는 사람, 회사 정책을 정리하는 사람, 승인 매트릭스를 관리하는 사람, 실패 사례를 리뷰하는 사람, prompt와 tool permission을 업데이트하는 사람이 필요합니다. MCP와 외부 모델 연결에는 토큰 비용, 로그 보관, 데이터 residency, vendor risk도 붙습니다. 계약 agent의 경제성은 "AI가 몇 분을 아껴줬다"가 아니라 "정책 관리와 감사 비용까지 포함해 workflow 전체가 단순해졌는가"로 봐야 합니다.

SaaS는 자기 도메인 문서를 실행 가능한 데이터로 바꾸고 있다

이번 발표를 Docusign 단독 뉴스로만 보면 규모가 작아 보일 수 있습니다. 하지만 더 넓게 보면 2026년 SaaS agent 경쟁의 공통 패턴이 보입니다. 각 SaaS는 자기 도메인의 핵심 객체를 agent가 실행할 수 있는 형태로 바꾸고 있습니다.

Salesforce의 핵심 객체는 customer와 opportunity입니다. ServiceNow의 핵심 객체는 ticket과 workflow입니다. Notion의 핵심 객체는 document와 database입니다. GitHub의 핵심 객체는 issue, PR, codebase입니다. Docusign의 핵심 객체는 agreement입니다. agent 시대의 플랫폼 경쟁은 "우리 챗봇이 더 똑똑하다"가 아니라 "우리 도메인 객체를 안전하게 읽고, 판단하고, 바꾸고, 기록할 수 있다"로 이동합니다.

Docusign에게 이 흐름은 방어이자 공격입니다. 방어적으로는 전자서명 commoditization을 피해야 합니다. 공격적으로는 계약 데이터를 중심으로 sales, HR, legal, procurement, finance workflow를 묶을 수 있습니다. 만약 계약서가 회사의 합의 상태를 가장 정확하게 담은 원장이라면, 그 원장을 agent가 다룰 수 있게 만드는 회사가 workflow의 중심을 차지할 수 있습니다.

개발자에게도 이 변화는 중요합니다. 앞으로 기업 agent를 만들 때 "모델이 똑똑한가"만큼 "어떤 SaaS가 어떤 MCP 서버와 어떤 permission model을 제공하는가"가 중요해집니다. 계약 agent를 사내 시스템에 붙이려면 단순 API key가 아니라 역할 기반 접근, 문서 단위 권한, 조항 단위 redaction, action approval, rollback, audit trail이 필요합니다. 이런 기능은 모델 API 문서가 아니라 도메인 SaaS의 platform design에서 나옵니다.

남은 질문

첫 번째 질문은 Agent Studio의 실제 추상화 수준입니다. 비개발자가 자연어로 agent를 만들 수 있다고 해도, 계약 workflow는 예외가 많습니다. 할인율, 지역별 법규, 고객 등급, 표준 조항 버전, 협상 history, 내부 승인 정책이 모두 조건으로 들어갑니다. Agent Studio가 단순 workflow builder에 가까운지, 정책 엔진과 테스트 환경을 갖춘 agent development platform에 가까운지는 실제 제품을 봐야 합니다.

두 번째 질문은 MCP beta의 권한 모델입니다. 외부 Claude, Gemini, ChatGPT가 계약 정보를 읽고 action을 요청할 때, Docusign은 어떤 범위의 tool을 노출하고 어떤 승인 절차를 요구할까요. 사용자의 Docusign 권한을 그대로 위임하는지, agent 전용 service account를 쓰는지, 민감 조항을 마스킹할 수 있는지, tool call 로그를 얼마나 세밀하게 남기는지가 관건입니다.

세 번째 질문은 legal AI 파트너와의 경계입니다. Harvey, Legora, CoCounsel은 법률 리서치와 문서 분석에 강합니다. Docusign은 계약 lifecycle과 서명, workflow, repository에 강합니다. 두 영역이 연결되면 강력하지만, 책임 경계도 복잡해집니다. 조항 해석 오류가 legal AI에서 나왔는지, Docusign workflow에서 나왔는지, 사용자의 승인 정책에서 나왔는지 분리해야 합니다.

네 번째 질문은 비용입니다. Docusign은 이번 발표에서 Agent Studio와 MCP beta의 장기 과금 구조를 자세히 설명하지 않았습니다. 하지만 agent workflow가 백그라운드에서 계약을 모니터링하고 외부 모델을 호출한다면, 비용은 좌석 수만으로 설명하기 어려워집니다. 계약 수, tool call 수, 모델 호출량, workflow 실행량, audit 보관량이 모두 과금 단위가 될 수 있습니다.

전자서명 이후의 Docusign

Docusign의 이번 발표는 화려한 모델 출시가 아닙니다. 새 LLM benchmark도 없습니다. 그러나 AI agent가 실제 회사 업무로 들어갈 때 필요한 현실적인 층을 보여줍니다. 계약은 기업의 가장 중요한 문서 중 하나입니다. 동시에 가장 느리고, 가장 많이 복사되고, 가장 많이 기다리는 업무 객체이기도 합니다. 이 객체가 agent의 tool layer로 올라오면, 자동화의 체감 효과는 꽤 클 수 있습니다.

다만 성공 조건은 AI assistant의 말솜씨가 아닙니다. 계약 데이터의 구조화, 시스템 통합, 권한 모델, 승인 정책, 감사 가능성, 예외 처리, 비용 예측이 모두 맞아야 합니다. Docusign이 말하는 "system of action"은 멋진 슬로건이지만, 계약 영역에서는 무거운 약속입니다. 정적 PDF를 실행 계층으로 바꾸는 순간, 편리함과 책임이 함께 이동하기 때문입니다.

그래서 이번 뉴스의 핵심은 Docusign이 AI agent를 붙였다는 사실보다, 전자서명 회사가 자기 생존 전략을 agent runtime 쪽으로 다시 정의했다는 점에 있습니다. 계약서는 더 이상 서명하고 보관하는 파일로만 남지 않습니다. 다음 단계는 누가 계약서를 가장 안전하고 유용한 agent 도구로 바꿀 수 있는가입니다.