계약서가 많아지는 순간 벌어지는 일

계약 협상이 길어질수록 계약서 파일은 빠르게 늘어납니다. 협상 참여자들이 각자의 PC에서 자신만의 파일을 따로 관리하기 때문입니다. 최종_v3.docx, 진짜최종.docx, 수정본_0427.docx 같은 파일이 계속 생성되고, 이 파일들은 메일, 슬랙, 로컬 폴더에 흩어집니다. 그 결과 내부 검토용 파일과 상대방 전달용 파일이 섞이고, 어떤 파일이 최신 버전인지 불명확해집니다. 문제는 이 혼선이 실제 계약 리스크로 이어진다는 점입니다. 최신 버전이 아닌 계약서로 계약이 체결되거나, 이전 협상에서 삭제했던 조항이 다시 포함되는 일이 반복됩니다.

왜 이런 문제가 반복되는가

1. 계약을 파일 단위로 작성하기 때문입니다.

많은 조직은 계약을 하나의 협상 흐름으로 관리하지 않고, 수정이 발생할 때마다 새로운 파일을 생성합니다. 문제는 협상 및 내부검토가 길어질수록 파일 수도 함께 늘어난다는 점입니다. 실제로는 하나의 계약을 협상하고 있지만, 복수의 관계자가 검토하는 방식은 계속 새로운 문서를 추가하는 방향으로 움직입니다. 그 결과 계약의 흐름은 연결되지 않고, 파일만 누적됩니다. 실제로 World Commerce & Contracting(WorldCC) 역시 이러한 상황을 두고 계약의 version control이 “악몽처럼 복잡해진다”고 설명합니다.

2. 파일이 여러 공간에 흩어지기 때문입니다.

계약 참여자들이 동일한 워크스페이스에서 같은 문서를 기준으로 작업하지 않으면, 파일은 자연스럽게 여러 곳으로 분산됩니다. 어떤 파일은 메일에 저장되고, 어떤 파일은 슬랙으로 전달되며, 어떤 파일은 담당자 로컬 폴더에만 남게 됩니다. 계약 상대방과 사용하는 툴이 다를 경우 이런 분산은 더 심해집니다. 이 구조에서는 충돌과 누락이 반복될 수밖에 없습니다. 어떤 사람은 특정 조항을 추가하고, 다른 사람은 같은 부분을 삭제할 수 있습니다. 서로 다른 버전에서 수정한 내용이 충돌하는 경우도 자주 발생합니다.

계약 협상과 redlining이 반복될수록 계약 히스토리는 여러 파일로 분산되고, 조직이 신뢰할 수 있는 단일 기준(single source of truth)을 잃게 됩니다.(출처: Conga) 결국 계약 내용을 안정적으로 관리하려면, 여러 사람이 동일한 문서를 기준으로 작업할 수 있는 구조가 필요합니다.

3. 협상 맥락이 문서에 남지 않기 때문입니다.

계약 검토는 대표적인 high-context 작업입니다. 이전 라운드에서 왜 특정 조항이 수정되었는지, 왜 상대방 요구를 거절했는지, 어떤 리스크 때문에 문구를 변경했는지가 모두 중요합니다. 하지만 대부분의 조직에서는 이런 정보가 문서 자체에 남지 않습니다. 결국 담당자는 이전 버전을 하나씩 열어보거나, 슬랙 메시지를 검색하거나, 메일 히스토리를 다시 확인하면서 맥락을 복기해야 합니다. 협상 라운드가 많아질수록 검토 피로도는 커지고, 중요한 변경 사항을 놓칠 가능성 역시 함께 높아집니다.

계약서를 “파일”이 아니라 “라운드” 기준으로 관리해야 하는 이유

이 문제를 해결하기 위해서는 계약서 검토 프로세스를 문서 파일을 중심에 놓고 관리하는 것이 아니라, 하나의 협상 흐름으로 관리해야 합니다.

즉, 핵심은 계약서를 파일명 기준이 아니라 라운드 기준으로 관리하는 것입니다.

협상 라운드별 문서 관리법

1. 라운드 단위로 관리하기

수정이 발생할 때마다 새로운 파일을 만들기 시작하면, 협상이 길어질수록 어떤 파일이 최신 버전인지 점점 확인하기 어려워집니다. 따라서 계약은 파일이 아니라 협상 라운드 기준으로 관리해야 합니다. 중요한 것은 각 라운드마다 기준이 되는 최종본을 하나만 유지하는 것입니다. 예를 들어 2차 협상 단계에서는 내부 검토·수정·공유가 모두 동일한 “2차 협상안” 안에서 이루어져야 합니다. 수정이 발생했다고 새로운 파일을 계속 복제하는 것이 아니라, 동일한 라운드 안에서 최신 상태를 유지하는 방식입니다. 이 구조가 되면 현재 어느 협상 단계에 있는지, 어떤 버전이 기준인지 훨씬 명확해집니다.

2. 내부에서는 단일 워크스페이스에서 작업하기

외부 상대방의 툴까지 통제할 수는 없습니다. 하지만 내부만큼은 동일한 공간에서 작업해야 합니다. 파일이 메일, 슬랙, 로컬 폴더에 각각 흩어지기 시작하면, 누가 어떤 버전을 기준으로 작업 중인지 확인하는 커뮤니케이션이 반복됩니다. 결국 계약 검토보다 버전 확인에 더 많은 시간이 쓰이게 됩니다.

따라서 동일 계약 건은 하나의 워크스페이스 안에서 관리되어야 합니다. 검토 코멘트, 수정 이력, 협상 맥락 역시 문서 기준으로 함께 축적되어야 합니다. 그래야 계약 히스토리가 파일 밖으로 분산되지 않고, 이후에도 동일한 맥락을 이어서 검토할 수 있습니다.

3. redline과 clean을 명확히 분리하기

실무에서 자주 발생하는 문제 중 하나가 redline 버전과 clean 버전의 혼용입니다. clean 버전은 상대방 공유용이고, redline 버전은 내부 검토용입니다. 두 문서는 목적 자체가 다릅니다. 하지만 파일 단위로 계약을 관리하다 보면 redline 파일을 그대로 외부에 전달하거나, clean 파일을 내부 검토 기준으로 사용하는 일이 반복됩니다. 파일이 여러 개로 늘어날수록 어떤 버전이 어떤 용도인지 구분하기 어려워지기 때문입니다. 따라서 두 버전은 반드시 명확하게 구분되어야 합니다. 파일명이나 저장 위치만 봐도 어떤 용도의 문서인지 즉시 식별 가능해야 합니다.

4. “무엇이 바뀌었는지”보다 “왜 바뀌었는지”를 남기기

계약 관리에서 가장 중요한 정보는 단순 수정 내역이 아닙니다. 왜 수정되었는지입니다.

예를 들어 아래 두 정보는 완전히 다릅니다.

• 손해배상 한도 조항 수정

• 거래처가 경쟁사 대비 동일 조건 요구하여 한도 상향 수용

후자의 정보가 남아 있어야 이후 재협상이나 재계약에서도 이전 협상 맥락을 이어갈 수 있습니다. 이런 정보가 축적되면 계약서는 조직의 협상 지식 자산이 됩니다.

프릭스로 구현하는 라운드 기반 문서 관리

계약을 라운드 기준으로 관리하고, 협상 히스토리를 하나의 흐름 안에서 유지하는 것은 매우 중요합니다. 다만 실무에서는 이를 사람의 기억과 파일 관리만으로 유지하는 데 한계가 있습니다. 결국 라운드 기반 문서 관리를 뒷받침할 수 있는 시스템이 필요합니다.

프릭스에서는 팀 단위, 기업 단위 등 조직 구조에 맞춰 워크스페이스를 구성할 수 있어, 동일 계약 건을 하나의 공간 안에서 일관되게 관리할 수 있습니다. 검토 코멘트, 협상 맥락, 수정 이력 역시 문서 기준으로 함께 축적되기 때문에 계약 히스토리가 메일이나 메신저 밖으로 흩어지지 않습니다.

또한 계약서를 단일 문서 기준으로 운영하면서 수정 이력을 계속 누적할 수 있습니다. 별도 파일을 반복 생성하지 않아도 되기 때문에, 협상 라운드가 늘어나더라도 자연스럽게 기준 문서가 유지됩니다. 현재 어떤 버전을 기준으로 작업 중인지 반복해서 확인할 필요도 줄어듭니다.

이전 라운드 대비 변경된 내용은 redline 형태로 자동 표시됩니다. 검토자는 계약서 전체를 다시 읽지 않아도 어떤 조항이 수정되었는지 바로 확인할 수 있어, 검토 효율을 높이면서도 변경 사항을 놓치는 문제를 줄일 수 있습니다.

이후 전자서명을 요청할 때는 계약 상대방에게 clean 버전이 자동 전달되기 때문에, 내부 검토용 redline 파일이 외부로 전달되거나 두 버전이 혼용되는 문제 역시 줄일 수 있습니다.

앞으로는 프릭스를 통해 효율적으로 계약의 법적 리스크를 관리해보세요. 어떤 상황에서도 동일한 기준으로 계약이 작성되고 검토되는 환경을 만들 수 있습니다.

👉 프릭스 리걸 더 알아보기