AI Tools8분 분량

한 문장으로 Box에서 계약 승인 절차를 만들 수 있을까?

Box Architect는 업무 목표에서 출발합니다. 계약 접수 사례로 도구가 그려 줄 초안과 프로세스 담당자가 결정해야 할 부분을 살펴봅니다.

K
Ken Jo

영업팀에 ‘최종본’이라는 이름의 첨부 파일과 함께 공급업체 계약서가 들어옵니다. 구매 금액은 13페이지 별표에 있고, 관할 지역 항목은 비어 있으며, 지정 검토자는 자리를 비웠습니다. 이런 요청을 받아 본 사람이라면 “계약서 승인 올려 주세요”라는 한마디에 일이 얼마나 많이 숨어 있는지 압니다. 처리 절차는 정책 문서, 팀 관행, 파일을 처음 연 사람의 판단에 흩어져 있습니다.

기업 콘텐츠 관리 플랫폼 Box는 2026년 11월 5일 BoxWorks에서 Box Architect를 발표했습니다. 발표에 따르면 일상 언어로 원하는 결과를 설명하면 Box에 이미 저장된 절차와 콘텐츠를 바탕으로 워크플로를 제안합니다. Box는 Architect가 양식, 메타데이터 템플릿, 에이전트, 앱 같은 구성 요소를 조합하고, 운영 중 병목을 찾아 담당자가 검토할 수 있게 할 것이라고 설명했습니다. Enterprise Advanced 고객 대상 베타는 2026년 4분기부터 순차 제공하겠다고 밝혔습니다. BoxWorks 발표 및 제공 일정

워크플로의 첫 초안은 작성하기 쉬워질 수 있습니다. 업무를 멈추게 만드는 예외를 어떻게 다룰지 정하는 일이 중요합니다. 계약 접수처럼 범위가 좁은 사례를 보면 초안에 어떤 결정이 들어가야 하는지, 배포 전 무엇을 확인해야 하는지, 시범 운영에서 무엇을 측정할지 구체적으로 살펴볼 수 있습니다.

캘리포니아주 레드우드시티에 있는 Box 본사 외관

2017년 3월 Jeanjung212가 촬영한 레드우드시티의 Box 본사. 맥락을 보여 주는 사진이며, 잘라내고 크기를 조정했습니다. CC BY-SA 4.0. 이미지 출처 · 라이선스.

업무 목표가 검토할 수 있는 초안이 된다

Box의 11월 5일 시연은 설계, 구축, 개선의 순서를 보여 줍니다. 원하는 결과와 조직의 기존 절차에서 시작합니다. Architect가 단계, 결정 지점, 인수인계를 제안한 다음 관련 Box 구성 요소를 조합할 수 있습니다. Box는 사용 가능한 기능으로 Box Forms, Extract, Automate, Apps, Doc Gen, Sign 등을 들었습니다. 프로세스 담당자는 초안을 수정하고 예외 사례를 시험하며 배포 전에 검토와 승인 단계를 추가할 수 있습니다. Box는 정보 누락이 반복되는 등의 문제를 발견하면 개선안도 제시할 것이라고 설명했습니다. Box Architect 제품 발표

각 단계가 구체적으로 어떤 동작을 하는지 정해 두면 흐름을 이해하기 쉽습니다. 접수 단계는 파일을 받고, 추출 단계는 항목을 찾습니다. 배정 단계는 검토자를 정하고, 승인 단계는 결정을 기록합니다. 배포 단계는 승인된 결과를 권한 있는 수신자에게 공유합니다. 같은 문서를 쓰더라도 각 단계의 영향은 다릅니다. 계약서에서 구매 금액을 확인할 수 있는 사람도 승인 권한은 없을 수 있습니다. 예를 들어 구매팀에만 승인 권한이 있을 수 있습니다. 구매를 승인한 사람에게도 외부인이 폴더 전체를 보도록 허용할 이유는 없을 수 있습니다.

계약 접수 후 항목을 추출하고 정책을 확인한 뒤 승인 또는 예외 대기열로 분기하는 흐름

계약 승인 사례에서는 접수, 추출, 배정, 결정을 각각 나눕니다. Telli.sh 자체 인포그래픽.

범위를 명확히 한 시작 지시는 다음과 같이 작성할 수 있습니다.

접수된 공급업체 계약서에서 요청 담당자, 계약 유형, 금액, 관할 지역을 확인한다. 필수 항목이 채워진 요청은 승인된 배정표에 명시된 담당자에게 보낸다. 항목 누락, 금액 불일치, 미등록 관할 지역은 지정 검토자에게 넘긴다. 권한 있는 담당자가 정확한 문서 버전과 수신자를 승인할 때까지 외부 공유를 보류한다.

실제 정책을 가리키면 지시의 활용도가 높아집니다. 버전이 관리되는 배정표를 첨부하고 두 규칙이 동시에 적용될 때의 처리 방식도 정합니다. 어떤 금액을 적용할지, 통화와 계약 기간이 기준 금액에 영향을 주는지 설명합니다. 법무와 구매 부서가 모두 검토한다면 동시에 진행할지 한쪽이 끝나야 다른 쪽이 시작할지도 명시합니다. 워크플로 제안은 이런 선택을 정리하면서 함께 검토할 구체적인 초안을 제공합니다.

Box에 따르면 콘텐츠는 Box에 남아 기존 권한과 정책의 적용을 받습니다. 설계팀은 제출 직원, 검토자, 해당 계약에 접근 권한이 없는 사용자를 대표하는 계정으로 각각 시험해야 합니다. 중요한 결과물은 입력, 인수인계, 예외 경로, 의사결정 담당자가 표시된 승인 완료 워크플로 도식입니다. 도식이 있으면 새 팀원도 어시스턴트와의 대화를 처음부터 되짚지 않고 파일이 어떻게 처리되는지 알 수 있습니다. Box Architect 제품 발표

예외 대기열에서 설계가 실제로 통하는지 드러난다

계약서 사본이 두 개 있다고 가정해 봅시다. 업로드된 파일에는 총액이 4만 9,500달러로 적혀 있지만 서명된 변경 계약에서는 5만 2,000달러로 올랐습니다. 숫자를 추출하기는 쉽습니다. 어떤 파일을 승인 기준으로 삼을지 정하는 건 별개의 일입니다. 이 예에서는 두 금액을 원본 페이지 및 파일명과 함께 예외 보고서에 남기고 자동 배정을 멈춰야 합니다. 차이를 남기지 않은 채 숫자 하나를 고르면 검토자는 두 번째 금액이 있었다는 사실을 모를 수 있습니다.

내용은 맞지만 접근 권한이 맞지 않는 경우도 있습니다. 요청자가 검토를 신청할 권한은 있어도 워크플로에서 허용하지 않는 폴더의 파일을 첨부할 수 있습니다. 요청자는 제한 문서의 미리보기를 받지 않은 상태에서 요청이 차단됐거나 보완이 필요하다는 점을 알 수 있어야 합니다. 문서 소유자가 파일을 옮기면 기존 링크와 승인 작업도 조직의 접근 정책에 따라 작동해야 합니다. 실제 기업에서는 모든 직원이 같은 권한을 가진 단일 폴더만 쓰는 일이 드뭅니다. 시범 운영에서 이 동작을 확인해야 하는 이유입니다.

세 번째 사례는 문서 교체입니다. 승인자는 버전 4를 선택했지만 서명 요청 직전에 버전 5가 들어옵니다. 검토를 다시 열지, 감사 기록에 버전 4를 어떻게 남길지, 누가 요청을 재개할 수 있는지 정합니다. 승인 결정이 특정 버전에 연결돼야 하는 사례입니다. 조항별 요약도 도움이 되지만, 사람의 결정이 정확히 어느 버전의 계약에 적용됐는지 워크플로에서 확인할 수 있어야 합니다.

시험 사례검토자에게 필요한 근거시범 운영에서 기대하는 동작
표준 계약문서 버전, 필수 항목, 배정 규칙지정 검토자에게 배정
금액 불일치페이지 또는 파일 참조가 붙은 두 금액처리를 일시 중단하고 확인 요청
필수 파일의 접근 제한접근 검사 결과와 허용된 시정 방법문서를 노출하지 않고 처리 보류
승인 후 새 버전 도착승인된 버전과 새 버전재검토를 시작하거나 문서화한 개정 규칙 적용
같은 요청이 두 번 접수기존 요청 ID와 접수 시각두 번째 승인 건을 만들지 않고 연결하거나 표시

표의 요청은 설명용 사례입니다. 정답을 알고 있는 샘플 문서와 실제 팀에서 접하는 다양한 레이아웃으로 시험을 구성합니다. 깔끔한 한 페이지 계약서는 정상 경로를 확인하는 데 유용합니다. 회전된 PDF 스캔, 다국어 첨부 파일, 서명 항목 누락은 추출 신뢰도가 떨어질 때도 처리 과정이 이해하기 쉬운지 보여 줍니다.

같은 방법이 다른 팀에서도 통하는지 두 번째 워크플로로 확인할 수 있습니다. 매입 채무팀은 청구서 식별자를 추출하고 발주서와 금액을 비교한 뒤 불일치 건을 검토에 넘길 수 있습니다. 계약 승인과 같은 접수 구조를 쓰더라도 근거가 달라집니다. 청구서 검토자에게 필요한 것은 계약 조건보다 발주 번호, 품목별 내역, 허용 오차 규칙입니다. 첫 시험은 두 흐름 중 하나에 집중합니다. 다른 팀이 같은 설계 방법을 쓸 때는 각자의 관리 대상 자료와 승인 절차를 적용하면서 접수와 예외 구조를 재사용할 수 있는지 봅니다. 겉보기에 비슷한 도식보다 실제 재사용 가능성을 잘 보여 주는 기준입니다.

Architect 베타와 이미 제공되는 통제 기능은 일정이 다르다

Box는 11월 5일 발표에서 여러 제품을 에이전트형 워크플로 자동화와 보안으로 묶어 소개했습니다. Architect는 Enterprise Advanced 고객 대상 베타 출시를 예고했습니다. 새 위협 방지 기능은 대상 요금제에 2027년 초 제공할 예정이라고 밝혔습니다. 에이전트 보안 통제는 Shield와 Enterprise Advanced 고객에게 이미 정식 제공된다고도 설명했습니다. 이 기능에는 분류 기반 정책, Box의 Model Context Protocol 서버를 통한 동작 제한, 임계값 기반 알림이 포함됩니다. 한 기능의 시연을 보고 다른 기능의 제공 범위를 판단하기 전에 요금제와 조직 계정의 접근 권한을 확인해야 합니다. Box 출시 발표 및 제공 일정

기록을 생성하거나 파일을 공유할 수 있는 워크플로라면 이런 구분이 중요합니다. 예를 들어 Box 문서는 외부 AI 에이전트가 호출하는 쓰기 작업에 적용할 MCP 관리자 규칙을 설명합니다. 관리자는 그 경로에서 지원되는 동작을 제한할 수 있습니다. Box 내부 승인 흐름은 실제로 사용하는 구성 요소를 통해 따로 시험해야 합니다. 쓰기 작업마다 어떤 구성 요소와 정책이 적용되는지 연결해 두고, 실제 실행 역할로 결과를 확인합니다. MCP 보호 규칙에 관한 Box 지원 문서

워크플로 설계와 실행 통제에는 서로 다른 비용이 듭니다. 검토자가 양식과 메타데이터를 연결하는 데 쓰는 시간은 줄어도 규칙을 정리하고 시험용 문서를 만드는 시간은 늘 수 있습니다. 정책이 옛 버전, 공유 드라이브, 이메일에 흩어져 있다면 최신 배정표 하나를 마련하는 일이 첫 개선일 수 있습니다. 반복해서 실행하는 워크플로는 예외가 갈 곳을 정해 두므로 절차가 어긋나는 지점이 보입니다. 담당자 변경이 열두 건의 개별 인수인계 대신 작은 규칙 하나에만 영향을 주면 승인된 프로세스도 더 빨리 개정할 수 있습니다.

워크플로 담당자에게 연습할 정책 변경을 하나 줍니다. 12월 1일부로 구매 규칙이 개정돼 법무 검토 기준 금액이 낮아진다고 가정합니다. 이미 검토 중인 계약에는 이전 규칙이 적용될 수 있고, 새 요청은 새 규칙을 따라야 할 수 있습니다. 어느 시점을 기준으로 판단할지, 누가 변경을 승인할 수 있을지 적어 둡니다. 적용일 전후의 시험용 계약을 하나씩 보관합니다. 초안 개정으로 추출 지시도 바뀌었다면 금액과 통화를 따로 재검사합니다. 새 배정 결과가 정책 변경에서 왔는지, 문서를 다르게 읽은 데서 왔는지 구별할 수 있습니다.

실제 계약을 보내기 전에 두 초안을 비교한다

사람이 배포를 승인하기 전 같은 시험 자료로 수작업 기준과 Architect 초안을 비교하는 시범 운영

수작업 절차와 Architect 초안에 동일한 시험 자료와 평가 기준을 사용합니다. Telli.sh 자체 인포그래픽.

  1. 범위가 좁은 워크플로를 고릅니다. 사업 부서 하나와 계약 유형 하나로 시작합니다. 현재 절차를 기록하고 배정과 상위 검토 요청에 답할 수 있는 프로세스 담당자를 정합니다.
  2. 승인된 자료를 모읍니다. 워크플로가 사용할 수 있는 정책 버전과 권한을 기록합니다. 이미 알려진 예외 사례와 접근 거부 시험용 계정을 포함하고, 가상 문서나 적절히 비식별화한 문서를 준비합니다.
  3. 대상 조직 계정에서 흐름을 작성합니다. 베타 접근이 가능해지면 Architect에 목표와 관련 절차를 줍니다. 담당자와 함께 제안된 양식, 메타데이터, 배정, 결정을 검토합니다. 예외 대기열을 명시합니다.
  4. 같은 사례를 수작업과 초안으로 각각 실행합니다. 필수 값이 맞는 버전에서 왔는지, 요청이 올바른 역할로 전달됐는지, 제한 정보가 계속 보호됐는지 평가합니다.
  5. 활성화 전에 변경 사항을 검토합니다. 최초 초안, 수동 변경, 지정 승인자, 되돌리는 절차를 기록합니다. 실제 공유나 서명에는 필요한 승인을 먼저 받도록 설정합니다. 실행을 반복하거나 규칙이 바뀔 때의 동작도 확인합니다.

구축 시간과 운영 시간은 나눠 측정합니다. 처음 쓸 만한 초안을 만드는 데 걸린 시간과 첫 검토 후 고치는 데 걸린 시간을 각각 기록합니다. 사례 재실행 중에는 정상 요청이 올바르게 배정된 비율, 예외를 포착한 비율, 사람이 되돌려야 한 결정 수를 기록합니다. 드물더라도 권한이 없는 시험 사례는 포함합니다. 간단한 사례 20개를 처리하고 제한 계약 한 건을 노출했다면 출시 전에 해결해야 할 문제가 드러난 것입니다.

첫 운영 분량을 처리할 때는 수동 접수 경로를 남겨 두고 누가 새 실행을 중지할 수 있는지 정합니다. 담당 팀이 보는 기록과 제출자가 보는 기록을 비교합니다. 양쪽 모두 요청이 정보 보완 대기인지, 승인 대기인지, 반환됐는지 알 수 있어야 하며 세부 정보는 각 역할의 접근 범위 안에서만 보여야 합니다. 절차는 쉽게 만들었지만 직원이 계약서가 어디로 갔는지 알아내야 한다면, 일이 설정 단계에서 지원 단계로 옮겨 간 셈입니다.

멈췄을 때 이유를 설명할 수 있어야 쓸 만하다

Architect의 제안에서 눈에 띄는 부분은 업무 목표와 실제 작동하는 절차 사이에 수정 가능한 설계안을 둔다는 점입니다. 프로세스 담당자는 실제 계약이 움직이기 전에 이 설계안을 두고 법무, 구매, IT와 논의할 수 있습니다. 시범 운영은 시연이 끝난 뒤에도 중요한 질문에 답할 수 있어야 합니다. 문서 처리가 멈췄을 때 담당자는 어떤 규칙이 멈추게 했고, 어떤 버전을 확인했으며, 누가 다음 조치를 할 수 있는지 알아낼 수 있을까요?

출처


업무에 관한 대화와 결정의 배경을 검색 가능한 기록으로 남기려면 Telli.sh 계정을 만들어 보세요.


← 블로그로 돌아가기