회사에서 계약 업무를 생각하면 가장 먼저 계약서를 작성하거나 검토하는 일이 떠오릅니다.
하지만 실제 업무 흐름을 자세히 들여다보면 계약서를 검토하는 것 외에도 상당히 많은 관리 업무가 따라옵니다.
계약 요청을 받고, 담당자를 지정하고, 계약서를 주고받고, 수정본을 관리하고, 현재 어떤 버전이 최신인지 확인하고, 승인을 받은 뒤 최종본을 보관해야 합니다.
계약 하나만 처리할 때는 크게 복잡해 보이지 않을 수 있습니다. 하지만 여러 계약이 동시에 진행되기 시작하면 이야기가 달라집니다.
특히 이메일과 메신저를 통해 계약서가 계속 오가다 보면 이런 문제가 생깁니다.
“이 파일이 최신 버전이 맞나?”
“Legal에서 검토한 파일은 어떤 거였지?”
“이 계약은 지금 누구한테 가 있지?”
바이브코딩으로 업무 자동화를 생각하면서 저는 계약 업무도 좋은 주제가 될 수 있다고 생각했습니다.
계약 내용을 AI에게 판단하게 하는 것이 아니라 계약 요청부터 검토, 버전 관리, 승인, 보관까지 반복되는 관리 업무를 프로그램으로 정리하는 것입니다.
이번 글에서는 바이브코딩으로 계약 관리 프로그램을 만든다고 가정하고 어떤 기능이 필요한지 단계별로 정리해보겠습니다.
계약 업무는 왜 관리하기 어려울까?
계약 업무가 복잡해지는 이유 중 하나는 하나의 계약이 여러 단계를 거치기 때문입니다.
예를 들어 새로운 거래처와 계약을 진행한다고 생각해보겠습니다.
현업 부서에서 계약 검토를 요청하고, 계약서를 첨부합니다.
Legal 담당자가 내용을 검토합니다.
수정이 필요하면 새로운 Version이 만들어집니다.
상대방이 다시 수정해서 보내면 또 다른 Version이 생깁니다.
최종 내용이 확정되면 내부 승인을 받고 서명한 뒤 계약서를 보관합니다.
이를 단순하게 표현하면 다음과 같습니다.
Request → Review → Revision → Approval → Signature → Completed → Archive
문제는 이런 과정이 이메일과 파일로만 관리되면 현재 상태와 최신 문서를 한눈에 확인하기 어렵다는 것입니다.
그래서 계약 자동화의 첫 번째 목표는 AI가 계약서를 작성하는 것이 아니라 계약 한 건의 전체 진행 상황을 한곳에서 관리하는 것으로 잡는 것이 좋습니다.
1. 계약 요청부터 하나의 Request로 만든다
가장 먼저 만들 수 있는 것은 Contract Request 화면입니다.
기존에는 담당자에게 이메일을 보내면서 계약서를 첨부했다면, 프로그램에서는 하나의 Request를 생성하는 것입니다.
예를 들어 다음과 같은 정보를 입력할 수 있습니다.
Contract Title / Requester / Department / Counterparty / Contract Type / Effective Date / Expiration Date / Description / Attachment
요청을 저장하면 고유한 Contract Request Number를 생성할 수도 있습니다.
예를 들어,
CON-2026-00125
같은 번호입니다.
그러면 이메일 제목이나 파일명에 의존하지 않고 계약 건별로 관리할 수 있습니다.
2. 계약 진행 상태를 Status로 관리한다
다음으로 필요한 것은 Status입니다.
계약 요청이 들어왔다고 해서 모두 같은 단계에 있는 것은 아닙니다.
예를 들어,
Draft → Submitted → Under Review → Revision → Approval → Signature → Completed
같은 흐름을 생각해볼 수 있습니다.
사용자는 계약 상세 화면을 열었을 때 현재 어디까지 진행됐는지 바로 확인할 수 있습니다.
이 기능만 있어도,
“제 계약 검토 어디까지 됐나요?”
라는 반복적인 확인을 줄이는 데 도움이 될 수 있습니다.
Dashboard에서 Under Review, Revision, Approval 상태인 계약을 각각 보여주는 것도 가능합니다.
3. 담당자를 지정한다
계약 요청이 많아지면 누가 어떤 계약을 검토하고 있는지 관리해야 합니다.
그래서 Request마다 담당자를 지정할 수 있습니다.
예를 들어,
Requester / Legal Owner / Business Owner / Approver
같은 역할을 둘 수 있습니다.
그러면 Legal 담당자는 My Contracts에서 자신이 담당하는 계약만 확인할 수 있습니다.
관리자는 전체 계약 중 담당자가 지정되지 않은 Request를 찾아볼 수도 있습니다.
특히 Submitted 상태인데 Legal Owner가 없는 계약처럼 확인이 필요한 건을 자동으로 표시할 수도 있습니다.
4. 계약서 Version을 관리한다
계약 관리 프로그램에서 제가 가장 중요하다고 생각하는 기능 중 하나가 Version Management입니다.
계약서는 검토 과정에서 계속 바뀝니다.
Contract_Final.docx
Contract_Final_v2.docx
Contract_Final_v2_REVISED.docx
Contract_Final_v2_REVISED_FINAL.docx
같은 파일이 생기기 시작하면 어떤 파일이 진짜 최종본인지 헷갈리기 쉽습니다.
프로그램에서는 파일을 업로드할 때마다 자동으로 Version을 관리하도록 만들 수 있습니다.
예를 들어,
Version 1 – Initial Draft
Version 2 – Legal Review
Version 3 – Counterparty Revision
Version 4 – Final
처럼 관리하는 것입니다.
그리고 현재 공식적으로 사용해야 하는 문서에는 Current Version 표시를 할 수 있습니다.
이렇게 하면 사용자는 파일 이름을 보고 최신본을 판단할 필요가 없습니다.
5. 누가 어떤 Version을 올렸는지도 기록한다
Version Number만으로는 충분하지 않을 수 있습니다.
누가 언제 파일을 업로드했는지도 중요합니다.
예를 들어,
Version 3
Uploaded by: Jane
Uploaded Date: Sep 25, 2026
Revision Note: Counterparty updated payment terms.
처럼 기록할 수 있습니다.
Revision Note를 필수로 입력하도록 만들 수도 있습니다.
그러면 새로운 파일이 올라왔을 때 이전 Version과 무엇이 달라졌는지 대략적으로 확인할 수 있습니다.
이런 정보가 쌓이면 이메일을 다시 찾아보지 않아도 계약의 수정 과정을 확인하기 쉬워집니다.
6. 이전 계약서와 새로운 계약서를 비교한다
Version 관리와 함께 생각해볼 수 있는 것이 Document Comparison입니다.
Version 2와 Version 3가 있다면 두 문서를 비교해서 무엇이 바뀌었는지 확인하는 것입니다.
예를 들어,
Added / Deleted / Modified
항목으로 변경 내용을 정리할 수 있습니다.
AI를 활용해 주요 변경 내용을 요약하는 기능도 생각해볼 수 있습니다.
다만 여기에는 중요한 원칙이 있습니다.
AI의 비교 결과가 법률 검토 자체를 대신해서는 안 됩니다.
계약서의 문구 하나가 법적으로 중요한 의미를 가질 수 있기 때문에 AI가 만든 Summary는 검토를 돕는 참고자료로 사용하고 실제 계약서는 담당자가 직접 확인하는 구조가 필요합니다.
7. Comment를 계약 Request 안에 모은다
계약 검토 과정에서는 질문과 의견도 많이 발생합니다.
이런 내용이 이메일이나 메신저에 흩어지면 나중에 왜 특정 문구가 변경됐는지 찾기 어렵습니다.
그래서 Contract Request 안에 Comment 기능을 둘 수 있습니다.
예를 들어 Legal 담당자가,
“Please confirm the payment term with Finance.”
라는 Comment를 남기면 Requester가 해당 Request 안에서 답변하는 방식입니다.
필요하다면 특정 사용자에게 Mention을 보내는 기능도 추가할 수 있습니다.
이렇게 하면 계약 파일과 관련된 대화를 같은 공간에서 확인할 수 있습니다.
8. 원계약과 Amendment를 연결한다
계약 관리가 복잡해지는 또 하나의 이유는 계약이 한 번 체결되고 끝나지 않기 때문입니다.
기존 계약의 기간이나 금액, 조건을 변경하기 위해 Amendment가 만들어질 수 있습니다.
이때 Amendment를 별도의 Contract로만 저장하면 나중에 원계약과의 관계를 찾기 어려워집니다.
그래서 프로그램에 Related Contract 기능을 추가할 수 있습니다.
예를 들어,
Original Contract: CON-2026-00125
Amendment 1: CON-2026-00341
처럼 연결하는 것입니다.
그러면 원계약 화면에서 관련 Amendment를 바로 확인할 수 있습니다.
다만 여기서 중요한 Business Rule이 생깁니다.
Original Contract와 Amendment의 관계를 어떻게 정의할 것인지, 하나의 Amendment가 여러 계약과 연결될 수 있는지, 연결된 계약을 사용자가 자유롭게 변경할 수 있는지 등을 먼저 정해야 합니다.
바이브코딩에서는 이런 업무 규칙을 AI가 임의로 결정하지 않도록 하는 것이 중요합니다.
9. Approval과 Signature 단계까지 연결한다
Legal Review가 끝났다고 계약 업무가 끝나는 것은 아닙니다.
회사 정책에 따라 내부 승인이 필요할 수도 있고, 이후 계약 당사자의 서명이 필요할 수도 있습니다.
따라서 계약 관리 프로그램 안에서,
Legal Review Complete → Internal Approval → Signature → Completed
같은 흐름을 만들 수 있습니다.
Approval 단계에서는 누가 승인했는지 기록합니다.
Signature가 완료되면 최종 서명본을 업로드하고 Status를 Completed로 변경합니다.
이렇게 하면 계약 요청부터 완료까지 하나의 History 안에서 확인할 수 있습니다.
10. 완료된 계약은 Archive한다
계약이 완료되었다고 해서 데이터를 삭제하는 것은 아닙니다.
오히려 나중에 다시 찾아야 할 가능성이 높습니다.
그래서 Completed된 계약을 별도의 Archive 영역으로 이동시키는 기능을 생각해볼 수 있습니다.
Archive에서는,
Counterparty / Contract Type / Effective Date / Expiration Date / Contract Number
등으로 검색할 수 있도록 합니다.
그러면 몇 년 전 계약서를 찾기 위해 여러 폴더를 돌아다니는 일을 줄일 수 있습니다.
특히 계약 만료일을 함께 관리하면 앞으로 만료될 계약을 미리 확인하는 기능으로도 확장할 수 있습니다.
Dashboard를 만들면 계약 현황도 한눈에 볼 수 있다
계약 데이터가 쌓이면 Dashboard도 만들 수 있습니다.
예를 들어 상단에,
Total Contracts / Under Review / Waiting for Revision / Pending Approval / Completed
등을 보여줄 수 있습니다.
그 아래에는 오래 진행 중인 계약이나 Expiration Date가 가까운 계약을 보여주는 것입니다.
예를 들어,
Under Review상태로 일정 기간 이상 머물러 있는 Contract
만 별도로 보여줄 수도 있습니다.
이렇게 하면 모든 계약을 하나씩 열어보지 않고 확인이 필요한 계약부터 볼 수 있습니다.
처음부터 계약 관리 시스템 전체를 만들 필요는 없다
바이브코딩을 시작하면 욕심이 생길 수 있습니다.
Contract Request도 만들고,
Version Control도 만들고,
AI Compare도 만들고,
Approval도 넣고,
전자서명도 연결하고 싶어집니다.
하지만 기능이 많아질수록 프로그램은 급격하게 복잡해집니다.
처음에는 다음 정도로 시작해도 충분합니다.
Contract Request 생성 → 파일 Upload → Status 관리 → Version 관리
이 네 가지가 제대로 작동하는지 먼저 확인하는 것입니다.
그다음 Comment를 추가하고, Document Compare를 추가하고, Approval과 Archive를 붙이는 방식으로 확장할 수 있습니다.
작은 Prototype → 실제 업무 흐름 확인 → 필요한 기능 추가
이 방식이 비개발자가 바이브코딩으로 업무 프로그램을 만들 때 훨씬 현실적입니다.
AI에게는 이렇게 요청할 수 있다
바이브코딩으로 Contract Management 프로그램을 만든다면 처음부터 코드를 요청하기보다 업무 구조를 먼저 정리하도록 하는 것이 좋습니다.
예를 들어 이런 프롬프트를 사용할 수 있습니다.
회사 내부에서 사용할 Contract Management 프로그램을 만들고 싶어.
사용자가 Contract Request를 생성하고 계약서를 첨부할 수 있어야 해.
기본 Status는 Draft, Submitted, Under Review, Revision, Approval, Signature, Completed로 구성하고 싶어.
계약서를 새로 Upload할 때마다 Version History를 남기고, 현재 공식적으로 사용되는 파일은 Current Version으로 표시하고 싶어.
Original Contract와 Amendment를 Related Contract로 연결할 수 있도록 해줘.
모든 Status 변경과 Version 변경은 History에 남겨야 해.
내가 설명하지 않은 Contract Rule이나 Permission은 임의로 결정하지 말고
[확인 필요]로 표시해줘.아직 코드를 작성하지 말고 필요한 화면, 데이터 구조, Status Flow, Version 관리 방식, Permission과 확인이 필요한 Business Rule부터 정리해줘.
이렇게 요청하면 AI가 바로 프로그램을 만들기 전에 내가 원하는 업무 흐름을 제대로 이해했는지 먼저 확인할 수 있습니다.
계약 관리 프로그램에서 특히 중요한 것은 권한이다
계약 업무 자동화에서는 Permission을 가볍게 생각해서는 안 됩니다.
모든 직원이 모든 계약서를 볼 수 있어서는 안 될 수도 있습니다.
특정 계약은 Legal과 일부 담당자만 볼 수 있어야 할 수도 있고, 일반 사용자는 새로운 Version을 Upload할 수 있지만 Current Version을 결정하는 권한은 제한할 수도 있습니다.
또 Completed된 계약을 누가 수정할 수 있는지도 정해야 합니다.
결국,
누가 볼 수 있는가?
누가 수정할 수 있는가?
누가 Version을 변경할 수 있는가?
누가 승인할 수 있는가?
누가 완료된 계약을 다시 열 수 있는가?
를 정의해야 합니다.
이런 부분은 단순한 UI보다 훨씬 중요한 계약 관리 시스템의 핵심입니다.
바이브코딩을 해보면 코드보다 Business Rule이 어렵다
계약 프로그램을 생각하다 보면 처음에는 Upload 버튼이나 Dashboard 같은 화면 기능이 눈에 들어옵니다.
하지만 기능을 구체화할수록 더 어려운 질문들이 나타납니다.
Amendment가 여러 개라면 어떤 것이 현재 유효한 계약인지,
Original Contract가 종료되면 Amendment는 어떻게 표시할지,
Completed된 계약에 새로운 파일을 올릴 수 있는지,
일반 사용자가 Current Version을 변경할 수 있는지,
잘못 연결한 Related Contract를 누가 해제할 수 있는지 등입니다.
이런 질문에는 정답이 하나 있는 것이 아닙니다.
회사의 업무 방식과 정책에 따라 결정해야 합니다.
그래서 바이브코딩에서는 AI에게 코드를 얼마나 잘 작성시키느냐 못지않게 업무 규칙을 얼마나 명확하게 설명하느냐가 중요합니다.
계약 업무에서 AI를 어디까지 사용해야 할까?
AI를 활용하면 계약서를 요약하거나 Version 간 변경 내용을 찾는 데 도움을 받을 수 있습니다.
하지만 계약서는 일반적인 업무 데이터와 다릅니다.
작은 문구 변경 하나가 중요한 의미를 가질 수도 있습니다.
따라서 AI가,
문서 비교 → 변경 가능성이 있는 부분 표시 → 요약
까지 도와주고,
법률적 의미 판단 → 계약 조건 승인 → 최종 의사결정
은 적절한 담당자가 검토하는 구조가 필요합니다.
회사 계약서를 외부 AI 서비스에 업로드하는 경우에도 회사의 보안정책과 승인된 환경을 먼저 확인해야 합니다.
마무리｜계약 자동화의 핵심은 계약서를 AI가 쓰는 것이 아니다
‘AI로 계약 업무 자동화’라고 하면 계약서를 AI가 작성하거나 검토하는 모습을 먼저 떠올리기 쉽습니다.
하지만 실제 업무에서는 그보다 훨씬 많은 반복 작업이 존재합니다.
계약 요청을 받고,
담당자를 지정하고,
파일을 주고받고,
Version을 관리하고,
수정 내용을 확인하고,
승인을 받고,
최종본을 보관합니다.
그래서 제가 생각하는 현실적인 계약 업무 자동화는,
Request → Review → Version Management → Approval → Signature → Archive
라는 전체 흐름을 한곳에서 관리하는 것입니다.
바이브코딩으로 처음부터 거대한 Contract Management System을 만들 필요는 없습니다.
Contract Request 하나를 만들고, 파일을 올리고, Status와 Version을 관리하는 작은 프로그램부터 시작할 수 있습니다.
실제로 사용하면서 필요한 기능이 보이면 Comment, Document Compare, Related Contract, Approval, Archive를 하나씩 추가하면 됩니다.
결국 바이브코딩의 장점은 개발자가 아닌 직장인도 업무 중 느꼈던 불편을,
“이런 기능이 있으면 좋겠다”에서 “그럼 이런 구조로 한번 만들어볼까?”
라는 단계까지 가져갈 수 있다는 점이라고 생각합니다.
그리고 계약 업무처럼 복잡한 프로세스일수록 AI에게 모든 판단을 맡기는 것보다 사람은 Business Rule과 판단을 담당하고, 프로그램은 반복되는 관리 업무를 줄이는 방향으로 활용하는 것이 더 현실적입니다.
0 Comments