영업팀과 법무팀을 위한 계약 승인 워크플로우

영업과 법무가 공유하는 승인 흐름이 필요한 이유

계약은 대부분 영업에서 법무로 이어지는 인수인계 구간에서 멈춥니다. 영업은 고객과의 모멘텀을 유지하려 하고, 법무는 리스크를 줄이고 조건을 일관되게 유지하려 합니다. 공유된 계약 승인 워크플로우가 없으면 인수인계는 누가 다음 단계인지, 무엇이 바뀌었는지, ‘승인’이 정확히 무엇을 의미하는지에 대한 추측 게임이 됩니다.

실제 손해는 협상 자체보다 경로에서 사라지는 것들에 있습니다: 최신 버전, 레드라인의 정확한 문구, 조항을 수용한 이유, 결정을 내린 사람 등이 이메일 스레드나 파일 이름(예: “v7-final-FINAL”)에 흩어지면 팀은 이미 내려진 결정을 다시 읽고, 재전송하고, 다시 논쟁하는 데 시간을 낭비합니다.

몇 가지 증상이 빠르게 나타납니다:

• 약간씩 다른 수정본이 떠다니며 파일이 중복됨
• 법무가 영업을 기다리는 상황(또는 그 반대)에서 소유권이 불분명함
• 사이클 후반부에 나타나는 깜짝 변경으로 오래된 논쟁이 재개됨
• 사람마다 다르게 해석되는 “승인” 의미

좋은 공유 흐름은 최선의 의미로 지루하게 보입니다. 현재 상태, 현재 버전, 다음 필요한 행동을 확인할 수 있는 한 곳이 있습니다. 누구나 10초 내에 세 가지 질문에 답할 수 있어야 합니다: 지금 어떤 단계인가? 누가 현재 책임자인가? 서명을 막는 것은 무엇인가?

고객이 표준 결제 조건의 예외를 요청하면 영업은 새 첨부파일을 전달하고 법무가 한 문장만 바뀐 것을 알아채길 바라면 안 됩니다. 그 요청은 명확한 작업을 만들고, 레드라인을 적절한 검토자에게 라우팅하며, 결정을 기록해야 합니다. 많은 팀은 내부 도구로 이를 처리해 양측이 같은 기록에서 작업하도록 합니다.

사람과 책임(누가 무엇을 하는가)

계약 승인 워크플로우는 모든 사람이 자신이 무엇을 맡고 있고 무엇을 변경할 수 있는지 알 때 가장 잘 작동합니다. 역할이 불명확하면 깜짝 수정, 잃어버린 레드라인, 실질적으로 이루어지지 않은 승인들이 생깁니다.

핵심 역할과 그 과정에서의 ‘권한 수준’을 먼저 정하세요. 편집과 승인은 다르고, 둘 다 서명과는 다릅니다.

전형적인 역할과 명확한 소유권

대부분의 팀은 다음과 같은 소유자를 둡니다:

• 영업 담당자: 요청을 생성하고 상업 조건을 초안하며 비즈니스 문의에 답변함
• 영업 관리자: 법무가 시간 투자를 하기 전에 할인, 비표준 조건, 딜 리스크를 승인함
• 법무 담당자: 계약 문구를 편집하고 레드라인을 처리하며 어떤 조항이 협상 가능한지 결정함
• 재무: 결제 조건, 청구 세부, 세금, 수익 인식 플래그, 신용 리스크를 승인함
• 권한 있는 서명자: 모든 필요한 승인 완료 후에 서명함

한 가지 규칙을 명시하세요: 법률 조항은 오직 법무만 편집한다. 영업은 변경을 제안할 수는 있지만(코멘트나 인테이크 폼으로), 조항을 직접 다시 쓰면 안 됩니다. 마찬가지로 법무는 가격이나 범위를 변경할 때 영업을 다시 끌어들여야 합니다.

영업이 사전에 제공해야 할 것들

영업이 완전한 패키지를 제출하면 법무 검토가 빨라집니다: 고객의 법적 명칭, 거래 금액과 기간, 제품 범위, 가격 및 할인, SLA 기대치, 특별 보안 요구사항, 고객이 반드시 요구하는 조항 등. 기본 정보 누락이 계약이 반려되는 가장 흔한 이유입니다.

응답 시간과 에스컬레이션 경로에 합의하세요. 예를 들어 표준 문서에는 법무가 1 영업일 내 응답하고 비표준 조건에는 3일 내 응답한다고 정합니다. 기한이 지나면 에스컬레이션 경로(법무 책임자 → 영업 관리자 → 서명자)를 명확히 하세요.

계약 승인 워크플로우 도구에서 책임을 권한으로 매핑하면 프로세스가 규칙을 자동으로 강제합니다. 팀은 종종 AppMaster(또는 appmaster.io) 같은 내부 도구로 역할, 권한, 승인을 코딩 없이 설정합니다.

초안부터 서명까지의 간단한 상태 모델 정의

계약 승인 워크플로우는 모두가 “이 계약은 지금 어떤 상태인지, 다음에 무엇이 일어나는지?”를 몇 초 안에 대답할 수 있을 때 가장 잘 작동합니다. 모델을 단순하게 유지하고 각 상태가 한 가지 명확한 의미만 갖게 하세요.

다음은 실무에서 쓸 수 있는 상태 흐름입니다:

진입·종료 규칙을 워크플로우 내에서 가시적으로 제시하세요. 예를 들어 “Approved”는 단순히 ‘법무가 봤다’는 의미가 아니라 가격, 기간, 책임 한도, 데이터 관련 조건이 내부 체크를 통과했다는 뜻이어야 합니다.

또한 지연이 코멘트 속에 숨지 않도록 현실적인 상태를 몇 가지 추가하세요:

• Blocked (내부 정보나 결정 필요)
• Waiting on customer (고객에게 발송했으나 응답 없음)
• Paused (거래 보류)

도구로 구현할 경우 상태를 허용값이 엄격한 단일 필드로 모델링하고 Blocked 또는 Paused로 이동할 때 이유를 요구하세요. 이 작은 가드레일이 ‘미스터리 정체’ 계약을 방지하고 영업과 법무의 정렬을 유지합니다.

“어떤 파일이 최종인가?” 문제를 막는 버전 규칙

사람들이 어떤 문서가 최신인지 구분하지 못하면 승인 흐름은 쉽게 무너집니다. 가장 단순한 해결책은 하나의 진실 소스를 정하고 다른 모든 것을 사본으로 취급하는 것입니다. 그 소스는 최신 파일, 상태, 코멘트가 저장된 계약 레코드일 수 있습니다.

하나의 규칙을 비협상적으로 만드세요: 한 번에 하나의 “Current” 버전만 존재합니다. 새 리비전이 생성되면 이전 버전은 보관되고 잠깁니다. 사람들은 여전히 이전 버전을 볼 수 있지만 편집하거나 재전송할 수 없습니다.

파일이 이메일로 전송되거나 다운로드될 때도 일관된 명명 규칙이 도움이 됩니다. 예측 가능하게 유지하세요:

• 거래 또는 고객명(짧게)
• 계약 유형(MSA, NDA, Order Form)
• 버전 번호(v01, v02, v03)
• 날짜(YYYY-MM-DD)
• 상태 태그(Clean 또는 Redline)

고객 레드라인에서 혼동이 주로 시작됩니다. 각 리비전에 대해 레드라인 사본과 동일한 변경사항을 반영한 클린 사본, 두 파일을 유지하세요. 영업은 클린 사본으로 빠르게 조건을 읽을 수 있고 법무는 어떤 부분이 이동했는지 정확히 볼 수 있습니다.

각 리비전에 한 줄의 변경 요약을 추가하세요. 사람을 위해 쓰인 간단한 문장 한 줄이면 충분합니다: “고객 요청으로 책임 한도를 고객당 12개월 수수료로 업데이트.” 이렇게 하면 반복 논쟁을 막고 누군가 결근했을 때 인수인계가 쉬워집니다.

예시: 영업이 “Acme MSA v01 2026-01-25 Clean”을 보냅니다. 고객은 “Acme MSA v02 2026-01-27 Redline”으로 편집본을 반환하고 법무는 동일 날짜의 “Acme MSA v02 2026-01-27 Clean”과 변경 요약을 작성합니다. 그 다음 v03은 새 변경이 있을 때만 시작됩니다.

법무 검토 시작 전에 수집할 항목

법무 검토는 반쯤 채워진 이메일과 세 개의 ‘최신’ 첨부파일로 시작할 때 느려집니다. 법무에 보내기 전에 매번 동일한 입력을 모으세요. 그러면 되묻는 시간을 줄이고 승인 워크플로우를 예측 가능하게 유지할 수 있습니다.

리스크와 언어에 영향을 주는 거래의 기본부터 시작하세요:

• 고객의 법적 명칭과 서명 주체(국가/주 포함)
• 거래 가치와 과금 형태(일회성 vs 반복, 할인 여부)
• 계약 기간, 갱신/자동갱신, 해지 통지 기간
• 납품일 또는 시작일, 약속한 서비스 수준
• 고객이 요청한 특수 조항(보안, 책임, 데이터, IP, 독점권)

다음으로 실제 문서를 단일 검토 번들로 첨부하세요: 주 계약서와 모든 부속 문서, 전시문서, 주문서, 고객의 레드라인(이미 있는 경우). 이 번들을 상태 및 버전 히스토리와 동일한 계약 레코드에 연결하세요.

그런 다음 법무가 읽기 전에 어떤 승인들이 필요한지 명시하세요. 간단한 트리거를 정의해 영업이 추가 승인이 필요한 상황을 알게 하세요:

• 정해진 임계값을 초과하는 거래 가치
• 비표준 결제 조건(net 60/90, 마일스톤 청구, 환불 조건)
• 책임 한도 변경, 확장된 면책 조항, 특이한 보증
• 표준 입장 밖의 데이터 처리·보안 조건
• “고객 필수”로 표시된 조항 중 사전 승인되지 않은 것

마지막으로 법무가 재사용할 수 있는 검증된 문구 저장소를 제공하세요. 작게라도 승인된 조항 라이브러리가 있으면 매번 같은 단락을 다시 쓰는 일을 줄일 수 있습니다.

예시: 연간 $45k 계약에 자동갱신과 무제한 책임 조항 요청이 포함된 경우, 전체 레드라인 파일, 갱신 세부사항, 재무·리더십 승인이 필요함을 함께 제출하면 법무는 수집 작업이 아닌 의사결정에 집중할 수 있습니다.

단계별: 실무용 계약 승인 워크플로우

좋은 계약 승인 워크플로우는 예측 가능해야 합니다. 누구나 다음에 무슨 일이 일어나는지, 누가 다음 소유자인지, ‘완료’가 무엇을 의미하는지 알아야 합니다.

초안에서 법무 검토까지

영업은 올바른 템플릿으로 초안을 시작하고 필요한 거래 세부(account name, pricing, term, start date, products, requested close date)를 입력합니다. 빠진 항목이 있으면 계약은 다음 단계로 넘어가지 않아야 합니다.

법무가 보기 전에 몇 가지 자동 검사를 실행하세요. 신뢰할 수 있게 단순하게 유지하세요:

• 필수 필드 누락
• 잘못된 템플릿 또는 오래된 조항 사용
• 거래 가치 또는 기간이 추가 승인을 유발하는지
• 비표준 결제 조건
• 데이터 프라이버시 또는 보안 부속서 필요 여부

초안이 검사를 통과하면 “검토만 요청”인지 “레드라인 승인 요청”인지와 함께 명확한 요청을 달아 법무로 라우팅하세요. 고객이 무엇을 요구하는지 짧게 메모를 남기면 도움이 됩니다.

레드라인에서 서명까지

법무가 레드라인을 반환합니다. 영업은 고객과 협상하지만 고객에게 보내는 모든 전송은 새 리비전으로 추적되어야 합니다. 결정을 이메일에 숨기지 않도록 코멘트는 한 곳에 모으세요.

반복 가능한 리비전 패턴은 도움이 됩니다:

• 고객에게 보내는 각 전송마다 새 버전 생성
• 누가 왜 변경했는지 기록
• 해당 버전에 레드라인 첨부
• 전송 후 즉시 상태 업데이트
• 다음 응답에 대한 기한 설정

고객이 동의하면 내부 승인(재무, 보안, 임원 서명자)을 거래 임계값에 따라 요청하고, 서명자는 복잡한 스레드가 아니라 최종 조건과 승인 히스토리를 검토해야 합니다.

그다음 계약을 서명(전자서명 또는 수기) 단계로 이동시키고, 서명되면 레코드를 잠그고 실행본을 저장한 뒤 보고를 정확히 하기 위해 서명 완료로 표시하세요.

승인 규칙, 임계값, 예외 처리

승인은 누가 더 크게 주장하느냐로 결정되지 않을 때 가장 잘 작동합니다. 영업이 경로를 예측할 수 있고 법무가 리스크에 집중할 수 있도록 간단한 규칙을 문서화하세요.

기억하기 쉬운 소수의 임계값으로 시작하세요. 이를 거래 규모, 리스크, 정책 변경에 연동하고 개인적 선호가 아니라 규칙에 기반하세요. 일반적인 원칙: 법무는 문구를, 재무는 자금 흐름에 영향을 주는 변경을, 보안/IT는 데이터·시스템에 영향을 주는 변경을 승인합니다.

승인이 필요한 트리거 예시:

• 재무 승인: 비표준 결제 조건, 일정 비율 이상의 할인, 환불·크레딧, 새로운 과금 스케줄
• 리더십 승인: 최소 책임 한도 이하, 무제한 면책, 특이한 해지 권리, 공개 참조 조항
• 보안/IT 승인: 새로운 데이터 종류, 신규 서브프로세서, 고객 보안 설문 관련 이슈
• 영업 리더 승인: 정상 역량 범위를 벗어난 납품일 약속
• 법무 승인: 준거법 변경, 기밀유지, IP, 책임 제한 조항 변경

예외 처리는 시간과 노력을 소모합니다. 긴급 거래, 고객이 제공한 계약서, 비표준 조항을 어떻게 처리할지 미리 결정하세요. 신속 경로를 허용할 수 있지만 더 엄격한 에스컬레이션과 서면 리스크 노트를 요구하세요. 속도는 책임을 제거해서는 안 됩니다.

“조건부 승인(Approved with conditions)”이 의미하는 바를 정의하세요. 모호한 엄지 척이 되어서는 안 됩니다. 특정 조건이 충족될 경우에만 계약이 진행될 수 있다는 뜻이어야 하며, 예: “고객이 DPA 부속서에 동의함” 또는 “재무가 선결제 인보이스 일정을 확인함”. 각 조건을 담당자와 기한이 있는 체크리스트 항목으로 저장하세요.

작업이 정체되지 않도록 명확한 에스컬레이션 트리거를 설정하세요:

• 표준 검토에 대해 2영업일 내 응답 없음
• 고위험 조항 발견 시 같은 날 에스컬레이션
• 마감일이 72시간 이내인데 검토가 시작되지 않음
• 진전 없이 레드라인 2회 이상 교환

작동하는 감사 추적, 코멘트, 알림

무슨 일이 왜 일어났는지 볼 수 없으면 계약 승인 워크플로우는 사이드 채팅, 스크린샷, 파일 재전송으로 흐려집니다. 해결책은 간단합니다: 결정이 발생한 곳에 결정을 기록하세요.

감사 추적은 아무도 묻지 않아도 세 가지 질문에 답할 수 있어야 합니다: 무엇이 변경되었나, 누가 했나, 언제 했나. 상태 이동(Draft→In legal review), 승인/거부, “레드라인 업로드됨”, “고객에게 발송됨” 같은 주요 행동을 자동으로 기록하세요. 자동화하면 바쁜 날에 놓치는 일이 줄어듭니다.

코멘트는 결정을 기록할 때만 유용합니다. ‘이유’를 설명하는 데 사용하고 중요한 조항을 숨기는 용도로 쓰지 마세요. 갱신일, 할인, 책임 한도가 중요하면 구조화된 필드(또는 짧은 요약 영역)에 저장해 검색과 보고가 가능하게 하세요.

간단한 코멘트 규칙:

• 결정과 이유를 작성(예: 승인, 거부, 변경 요청)
• 해당 조항이나 섹션 태그 지정(예: “결제 조건, 섹션 3”)
• 코멘트에 계약 전체 텍스트를 붙여넣지 않기
• 협상된 조건은 채팅이 아니라 추적 가능한 필드에 넣기
• 다음 소유자에게 작업을 명확히 알리기(예: “영업으로 반환—고객 답변 필요”)

알림은 행동이 필요할 때만 강하게 보내세요: 계약이 인수인계될 때, 레드라인이 도착했을 때, 승인이 요청되었을 때, 기한이 위험할 때. 그 외는 일일 요약(예: “영업 대기 3건”, “법무 대기 2건”)으로 충분합니다. 알림이 너무 많으면 사람들이 무시하게 됩니다.

마지막으로 관련 항목(주요 이메일, 통화 메모, 협상 요점)을 레코드에 첨부하세요. 누군가 거래 중간에 합류하더라도 5분 안에 역사를 이해할 수 있어야 합니다.

예시: 하나의 계약이 초안에서 서명으로 이동하는 과정

영업 담당자가 연간 $85k 규모의 중간 시장 거래를 마무리하려 합니다. 고객이 12% 할인을 요청하고 책임 한도를 12개월 수수료에서 24개월로 변경하길 원합니다. 이 경우 영업, 법무, 고객이 동일 문서를 여러 번 건드립니다.

팀은 명확한 상태와 현재 파일을 추적하는 단순한 승인 워크플로우를 사용합니다.

이 계약이 이동하는 방식은 다음과 같습니다:

• Draft (영업): 영업이 최신 템플릿으로 시작해 거래 조건을 입력하고 v01로 업로드합니다. 필수 항목이 모두 입력될 때까지 상태는 Draft로 유지됩니다.
• In legal review: 영업이 컨텍스트와 함께 초안을 제출합니다. 법무가 레드라인과 코멘트를 추가한 뒤 v02를 업로드합니다.
• In negotiation: 영업이 v02를 고객에게 보냅니다. 고객이 책임 한도 변경을 요청한 마크업을 반환하면 영업은 이를 v03(고객 레드라인)으로 업로드합니다.
• Approved: 법무는 할인 언어를 수용하지만 24개월 한도는 거부하고 타협안을 제시합니다. 내부적으로 대안에 합의하면 법무는 계약을 Approved로 표시하고 v04를 승인된 클린 사본으로 만듭니다.

이제 까다로운 순간이 옵니다: Approved로 표시된 후 고객이 ‘사소한’ 레드라인(해지 통지 수정)을 보냅니다. 규칙은 간단합니다: 어떤 새 레드라인도 검토를 재개합니다. 영업은 v05(승인 후 고객 레드라인)를 업로드하고 상태는 다시 In legal review로 이동합니다. 이전 승인 기록은 남아 있지만 더 이상 최신이 아닙니다.

최종 서명 버전을 확정하려면 팀은 하나의 파일을 Final for Signature로 잠그고 그 버전 ID(예: v06)를 기록하며 서명 패킷은 정확히 그 파일을 사용해야 합니다. 서명된 사본에 불일치가 있으면 상태는 Blocked(또는 Exception 라벨을 쓰는 경우 예외)로 바뀌어 팀이 반(再)서명 전에 해결할 때까지 보류됩니다.

계약 승인 속도를 늦추는 흔한 실수들

승인 워크플로우를 가장 빨리 멈추게 하는 방법은 작업이 워크플로우 밖으로 도망가게 하는 것입니다. 레드라인이 이메일 스레드에 있으면 누군가는 변경을 놓치고, 잘못된 메시지에 회신하거나 오래된 첨부파일을 전달합니다. 선의의 의도라도 “이메일 전용” 수정은 보이지 않는 작업과 불명확한 결정을 만듭니다.

또 다른 흔한 문제는 법무 검토를 기본 정보 없이 시작하는 것입니다. 핵심 거래 세부가 채팅, CRM 메모, 초안 PDF에 흩어져 있으면 법무는 탐정 작업을 하게 되고, 이로 인해 되묻는 시간이 늘어나 영업은 법무가 ‘느리다’고 느낄 수 있습니다. 실제로는 초안이 단순히 준비되지 않았던 것입니다.

대부분 팀에서 반복되는 문제들:

• 합의된 도구나 프로세스 외부에서 변경이 이루어져 누가 무엇을 왜 바꿨는지 보이지 않음
• 필수 세부가 비어 있어(고객 법인, 기간, 과금 모델, 데이터 처리 등) 법무가 이를 쫓아야 함
• 어떤 파일/버전에 대해 ‘승인’되었는지 확인 없이 거래가 ‘승인’ 처리됨
• 상태 라벨이 늘어나 신뢰를 잃음(예: “Legal Review”, “Legal Reviewing”, “Review - Legal”, “Pending” 등)
• 다음 행동의 명확한 소유자가 지정되지 않아 계약이 정체됨

과도하게 복잡한 상태는 특히 교묘합니다. 상태 목록이 실제로 사람들이 하는 단계보다 길면 추측 게임이 됩니다. 라벨을 단순하고 행동 중심으로 유지하고 각 상태마다 다음 할 일이 명확하도록 하세요.

마지막으로 소유자가 없는 인수인계에 주의하세요. 예: 영업이 오후 6시에 수정 초안을 보내고 “업데이트됨”으로 표시한 뒤 법무가 이를 확인할 것이라고 가정합니다. 법무는 영업이 아직 누락 정보를 수집 중이라고 생각합니다. 고객이 업데이트를 요구할 때까지 아무 일도 일어나지 않습니다.

도구는 기본을 강제할 때만 도움이 됩니다: 한 개의 현재 버전, 제출 전 필수 필드, 가시적인 다음 소유자.

빠른 체크리스트 및 흐름 구현을 위한 다음 단계

계약 승인 워크플로우는 누구나 몇 초 안에 네 가지 질문에 답할 수 있을 때 작동합니다: 어떤 버전이 현재인가, 누가 소유자인가, 다음에 무슨 일이 일어나는가, 무엇이 ‘완료’로 간주되는가.

언제나 계약을 열 때 하는 빠른 확인사항

• 현재 버전이 명확히 라벨링되어 있고 최신 레드라인과 일치하는가
• 현재 소유자가 이름으로 지정되어 있는가(팀이 아니라 한 사람)
• 다음 단계가 명확한가(법무 검토, 재무 승인, 고객 서명 등)
• 요구되는 승인들이 보이는가(거래 규모, 기간, 리스크에 따른)
• 서명 방식(전자서명, 수기 또는 둘 다)이 확인되었는가

고객에게 보내기 전에 빠른 진실성 검사(truth check)를 하세요. 가격, 할인, 결제 조건이 견적과 일치하는지 확인하고 날짜(시작일, 갱신, 통지 기간)와 비표준 조건을 재확인하세요. 양 당사자의 법적 명칭과 주소를 확인하고 참조된 모든 첨부파일(주문서, DPA, SOW, 보안 부속서)이 포함되었는지 확인하세요.

계약을 ‘서명됨’으로 표시하기 전에 최종 실행된 PDF(초안 스크린샷이 아님)를 확보했는지 확인하세요. 서명 페이지가 완전한지, 서명자 이름이 일치하는지, 필요한 이니셜이 있는지 확인하세요. 합의된 기록 저장소에 보관하고 저장 위치를 거래 레코드에 캡처해 나중에 찾기 쉽게 하세요.

흐름 구현을 위한 다음 단계

상태 이름과 종료 기준을 정의하고, 영업이 완전한 패키지를 제출하도록 하나의 인테이크 폼을 만들고, 승인 임계값(기간, 할인 비율, 책임 한도)을 문서화하세요. 그런 다음 계약 테이블, 상태 필드, “현재 소유자” 할당, 제출 체크리스트를 포함한 경량 내부 워크플로우 앱을 구축하세요.

코드 없이도 운영 가능한 앱을 원하면 AppMaster(appmaster.io) 같은 툴을 사용해 데이터를 모델링하고 승인 흐름을 설정하며 영업·법무·재무 간 작업을 라우팅할 수 있습니다.