회사에서 업무를 하다 보면 생각보다 많은 일에 승인(Approval) 과정이 필요합니다.
비용 신청, 구매 요청, 출장 신청, 예산 요청, 계약 검토처럼 업무의 종류는 달라도 기본적인 흐름은 비슷한 경우가 많습니다.
직원이 요청서를 작성하고, 상사가 승인하고, 경우에 따라 그다음 승인자에게 넘어갑니다. 중간에 수정이 필요하면 다시 요청자에게 돌아오기도 합니다.
겉으로 보면 단순합니다.
Request → Submit → Approve → Complete
하지만 실제 업무에서는 그렇게 간단하지 않습니다.
“승인자가 휴가라면 어떻게 하지?”
“금액이 크면 승인자를 한 명 더 추가해야 하나?”
“승인 후 요청 내용을 수정할 수 있나?”
“Reject와 Request for Revision은 어떻게 다르지?”
이런 조건이 하나씩 붙기 시작합니다.
바이브코딩으로 업무 프로그램을 생각하면서 Approval 시스템이 흥미로운 이유도 여기에 있습니다. 화면이나 버튼 자체보다 회사의 업무 규칙을 프로그램으로 표현하는 과정이 중요하기 때문입니다.
이번 글에서는 비개발자 직장인의 관점에서 바이브코딩으로 간단한 Approval 시스템을 만든다면 어디서부터 시작해야 하는지 정리해보겠습니다.
승인 시스템을 만들기 전에 먼저 업무 흐름부터 그려보자
처음부터 AI에게,
“Approval 시스템 만들어줘.”
라고 요청하면 내가 생각한 것과 전혀 다른 프로그램이 나올 수 있습니다.
Approval이라고 해도 회사마다 프로세스가 다르기 때문입니다.
따라서 먼저 가장 기본적인 흐름부터 정리하는 것이 좋습니다.
예를 들어 Expense Approval이라면,
Draft → Submitted → Pending Approval → Approved
이라는 기본 흐름을 생각할 수 있습니다.
승인자가 거절하면,
Pending Approval → Rejected
수정이 필요하다면,
Pending Approval → Revision Requested → Draft → Resubmit
같은 흐름도 필요할 수 있습니다.
이렇게 Status를 먼저 정리하면 프로그램의 전체 구조가 조금씩 보이기 시작합니다.
1. 가장 먼저 Request 작성 화면을 만든다
Approval 프로그램의 시작은 Request입니다.
처음에는 아주 단순하게 만들어도 됩니다.
예를 들어 General Expense Approval이라면 다음과 같은 정보를 입력할 수 있습니다.
Request Title / Requester / Department / Request Date / Amount / Description / Attachment
사용자가 내용을 입력하고 저장하면 상태는 Draft가 됩니다.
여기서 중요한 것이 Save와 Submit을 구분하는 것입니다.
Save는 작성 중인 내용을 저장하는 것이고, Submit은 실제 승인 프로세스를 시작하는 행동입니다.
업무 시스템에서는 이 두 가지를 명확하게 구분하는 것이 중요합니다.
2. Submit 버튼을 누르면 승인 프로세스를 시작한다
사용자가 내용을 모두 작성했다면 Submit 버튼을 누릅니다.
그러면 Status가,
Draft → Submitted
로 변경됩니다.
이때 프로그램은 필수값이 모두 입력되었는지도 확인해야 합니다.
예를 들어 Amount가 비어 있거나 Attachment가 필수인데 파일이 없다면 Submit을 막을 수 있습니다.
“Please complete all required fields before submitting.”
처럼 안내 메시지를 보여주는 것입니다.
단순해 보이지만 이런 Validation이 실제 업무 시스템에서는 상당히 중요합니다.
3. Approval Line을 어떻게 결정할지 정한다
Approval 시스템에서 가장 중요한 부분 중 하나가 누가 승인할 것인가입니다.
간단한 시스템이라면 요청자가 직접 Approver를 선택할 수도 있습니다.
하지만 실제 회사에서는 규칙에 따라 자동으로 정해지는 경우가 많습니다.
예를 들어,
Requester → Manager → Department Head → Finance
처럼 정해진 Approval Line을 사용할 수 있습니다.
금액에 따라 다르게 만들 수도 있습니다.
예를 들어 $1,000 미만은 Manager 승인으로 끝나지만 일정 금액 이상이면 Department Head나 Finance 승인이 추가되는 방식입니다.
여기서부터 프로그램이 복잡해집니다.
그래서 처음부터 모든 경우를 구현하기보다 가장 일반적인 Approval Line 하나부터 만드는 것이 좋습니다.
4. Approve와 Reject 기능을 만든다
승인자 화면에서는 자신에게 배정된 요청을 확인할 수 있어야 합니다.
예를 들어 My Approvals 화면을 만들고,
Request / Requester / Amount / Submitted Date / Status
를 보여줄 수 있습니다.
요청을 선택하면 상세 내용을 확인하고,
Approve / Reject
버튼을 선택합니다.
Approve하면 다음 승인자가 있는지 확인합니다.
다음 승인자가 있다면 그 사람에게 넘어가고, 마지막 승인자라면 Status가 Approved로 변경됩니다.
Reject를 선택하면 Rejected 상태로 변경할 수 있습니다.
여기서 Reject Reason을 필수로 입력하도록 하는 것도 생각해볼 수 있습니다.
요청자는 왜 거절됐는지 알아야 하기 때문입니다.
5. Reject와 Revision Request를 구분한다
실제 업무에서는 단순한 승인과 거절만으로 부족한 경우가 있습니다.
내용 자체를 거절하는 것이 아니라,
“금액을 다시 확인해주세요.”
“Attachment를 추가해주세요.”
처럼 수정해서 다시 제출해달라는 경우도 있습니다.
이럴 때는 Reject보다 Request Revision이라는 별도의 기능을 만드는 것이 더 명확할 수 있습니다.
예를 들어,
Pending Approval → Revision Requested
로 변경하고 요청자가 내용을 수정한 뒤 다시 Submit하도록 합니다.
그러면 시스템에서도 최종 거절된 Request와 수정 중인 Request를 구분할 수 있습니다.
이런 작은 차이가 실제 업무 프로그램에서는 중요합니다.
6. 승인자가 자리를 비우면 어떻게 할까?
Approval 시스템을 생각하다 보면 반드시 등장하는 문제가 있습니다.
“승인자가 휴가라면?”
승인자가 일주일 동안 자리를 비우면 모든 요청이 멈출 수도 있습니다.
이런 경우 Delegation 기능을 생각해볼 수 있습니다.
예를 들어 Manager A가 자리를 비우는 동안,
Sep 21 ~ Sep 27 → Delegate to Manager B
처럼 기간을 지정합니다.
해당 기간에는 A에게 들어갈 Approval을 B가 처리할 수 있도록 하는 것입니다.
하지만 Delegation을 추가하면 또 다른 질문이 생깁니다.
기존에 A에게 들어가 있던 Approval도 B가 처리할 수 있는지, 새로운 요청만 위임되는지, 누가 위임 설정을 할 수 있는지 등을 정해야 합니다.
이것이 Approval 시스템에서 코드보다 Business Rule이 중요한 이유입니다.
7. Approval History를 반드시 남긴다
Approval 시스템에서 현재 상태만 보여주는 것은 충분하지 않습니다.
누가 언제 어떤 행동을 했는지도 확인할 수 있어야 합니다.
예를 들어,
Sep 20 09:15 – Request Created
Sep 20 10:02 – Submitted by Jane
Sep 21 13:30 – Approved by Manager A
Sep 21 15:10 – Revision Requested by Finance
Sep 22 09:20 – Resubmitted by Jane
Sep 22 11:45 – Approved by Finance
같은 History를 남기는 것입니다.
나중에 문제가 생겼을 때,
누가 승인했는지, 언제 상태가 바뀌었는지, 왜 다시 수정됐는지
확인할 수 있습니다.
특히 비용이나 계약처럼 중요한 업무에서는 이런 Audit Trail이 더욱 중요합니다.
8. 승인 요청이 오래 멈춰 있으면 알려준다
승인 시스템을 만들었다고 업무가 자동으로 빨라지는 것은 아닙니다.
승인자가 확인하지 않으면 여전히 요청은 멈춰 있습니다.
그래서 Pending 상태가 일정 기간 지속되면 알려주는 기능을 생각해볼 수 있습니다.
예를 들어,
Pending 1 Day → Normal
Pending 3 Days → Reminder
Pending 7 Days → Needs Attention
같은 규칙입니다.
처음부터 자동 이메일까지 보내지 않아도 됩니다.
Dashboard에서 오래된 Approval만 별도로 보여주는 것부터 시작할 수 있습니다.
그다음 실제 필요성이 확인되면 이메일이나 메신저 Notification으로 확장하면 됩니다.
9. 요청자와 승인자의 화면은 달라야 한다
Approval 프로그램을 만들 때 놓치기 쉬운 부분 중 하나가 **사용자 역할(Role)**입니다.
요청자는 자신이 작성한 Request를 보고 싶습니다.
승인자는 자신이 승인해야 하는 Request를 보고 싶습니다.
관리자는 전체 진행 상황을 보고 싶을 수 있습니다.
따라서 화면을 역할에 따라 나눌 수 있습니다.
Requester → My Requests
Approver → My Approvals
Admin → All Requests / Approval Monitoring
이렇게 하면 같은 데이터를 사용하더라도 각 사용자가 필요한 정보에 집중할 수 있습니다.
여기서부터 Role과 Permission이라는 중요한 개념이 등장합니다.
10. Dashboard로 전체 승인 현황을 보여준다
데이터가 쌓이기 시작하면 Dashboard가 유용해집니다.
예를 들어,
Draft 12
Pending Approval 18
Revision Requested 4
Approved 35
Rejected 2
Overdue 5
처럼 전체 현황을 보여줄 수 있습니다.
그 아래에는 오래된 Approval이나 특정 Approver에게 많이 쌓여 있는 요청을 보여줄 수도 있습니다.
이렇게 하면 단순히 Request를 처리하는 시스템에서 한 단계 발전해 Approval 프로세스 자체를 관리하는 시스템이 됩니다.
바이브코딩으로 처음 만든다면 어디까지 만들까?
처음부터 위 기능을 모두 만들 필요는 없습니다.
오히려 첫 번째 버전은 최대한 작게 만드는 것이 좋습니다.
Request 작성 → Save Draft → Submit → Approver 확인 → Approve/Reject → Status 확인
저라면 이 정도를 첫 번째 Prototype의 범위로 잡을 것 같습니다.
이 흐름이 제대로 작동하는 것을 확인한 뒤,
Revision → Approval History → Multiple Approvers → Reminder → Delegation → Dashboard
순으로 확장할 수 있습니다.
처음부터 10개의 기능을 동시에 요청하는 것보다 하나의 Approval이 처음부터 끝까지 정상적으로 흘러가는지를 확인하는 것이 중요합니다.
AI에게 Approval 시스템을 만들어달라고 할 때 중요한 프롬프트
단순히,
“회사 Approval 시스템 만들어줘.”
라고 하면 AI가 수많은 Business Rule을 스스로 가정하게 됩니다.
대신 요구사항을 구체적으로 설명하는 것이 좋습니다.
예를 들어 다음처럼 요청할 수 있습니다.
회사 내부에서 사용할 간단한 Approval 웹 프로그램을 만들고 싶어.
사용자는 Request를 작성하고 Draft 상태로 저장할 수 있어야 해. Submit 버튼을 누르면 Status를 Submitted로 변경하고 Approver에게 전달해줘.
Approver는 Approve, Reject, Request Revision 중 하나를 선택할 수 있어야 해. Reject와 Request Revision을 선택할 때는 Comment를 필수로 입력하도록 해줘.
모든 Status 변경은 History에 User, Date/Time, Previous Status, New Status를 기록해줘.
내가 설명하지 않은 Approval Rule이나 Permission은 임의로 만들지 말고
[확인 필요]로 표시해줘.바로 코드를 작성하지 말고 먼저 필요한 화면, Status Flow, Data Structure, Business Rule과 확인이 필요한 사항을 정리해줘.
마지막 두 문장이 특히 중요합니다.
AI에게 모르는 업무 규칙을 임의로 결정하지 말라고 하고, 코드를 작성하기 전에 AI가 이해한 프로세스를 먼저 보여달라고 하는 것입니다.
Approval 시스템은 만들수록 예외가 많아진다
처음에는 Approval 시스템이 단순해 보입니다.
Request를 만들고 Approve 버튼만 있으면 될 것 같습니다.
그런데 실제 업무를 적용하면 질문이 계속 생깁니다.
승인자가 두 명이면 순서대로 승인해야 하는지,
두 명 중 한 명만 승인하면 되는지,
이미 승인한 사람이 승인을 취소할 수 있는지,
요청자가 Submit 후 내용을 수정할 수 있는지,
수정하면 기존 승인을 다시 받아야 하는지,
승인자가 퇴사하면 Pending Request는 어떻게 처리할지 등입니다.
여기에 회사가 여러 법인이나 부서를 운영한다면 Approval Line도 달라질 수 있습니다.
이런 문제는 AI가 코드를 얼마나 잘 작성하는가와는 별개의 문제입니다.
회사가 어떤 규칙으로 업무를 처리할 것인지 사람이 결정해야 하는 문제입니다.
Approval에서 가장 조심해야 하는 것은 Permission
Excel 정리 프로그램과 Approval 시스템의 가장 큰 차이 중 하나는 권한입니다.
Approval 시스템에서는 아무나 다른 사람의 요청을 승인해서는 안 됩니다.
다른 부서의 민감한 요청을 볼 수 있어서도 안 될 수 있습니다.
따라서 실제 회사에서 사용할 시스템이라면,
Authentication / Role / Permission / Data Access / Audit Trail
을 함께 고려해야 합니다.
바이브코딩으로 화면이 작동하는 Prototype을 만드는 것과 실제 회사의 Production 시스템으로 운영하는 것은 전혀 다른 단계입니다.
특히 비용, 계약, 인사, 결제처럼 중요한 데이터를 다룬다면 보안과 내부통제 검토가 필요합니다.
바이브코딩으로 Approval 시스템을 만들어보면 보이는 것
Approval 프로그램을 생각해보면 바이브코딩에서 중요한 것이 단순히 코드를 만드는 능력만은 아니라는 점이 잘 드러납니다.
오히려,
누가 요청할 수 있는가?
누가 승인할 수 있는가?
어떤 순서로 승인하는가?
어떤 상태가 존재하는가?
어떤 경우에 이전 단계로 돌아가는가?
누가 어떤 데이터를 볼 수 있는가?
같은 질문에 답하는 것이 먼저입니다.
결국 좋은 프롬프트를 작성하려면 먼저 업무를 잘 이해해야 합니다.
그래서 비개발자라도 실제 업무 프로세스를 잘 알고 있다면 바이브코딩에서 상당한 장점을 가질 수 있다고 생각합니다.
AI에게 코드를 작성시키기 전에 업무 규칙을 AI가 이해할 수 있는 언어로 바꾸는 역할을 할 수 있기 때문입니다.
마무리｜승인 업무 자동화는 Approve 버튼을 만드는 것보다 어렵다
바이브코딩으로 Approval 시스템을 만든다고 하면 처음에는 간단하게 느껴질 수 있습니다.
Request 화면 하나 만들고 Approve 버튼을 추가하면 될 것 같습니다.
하지만 실제 업무에서는 그 뒤에 더 중요한 것들이 있습니다.
Status Flow, Approval Line, Revision, Delegation, Permission, History, Reminder, Exception Rule.
이런 규칙이 모여 실제 Approval 시스템이 됩니다.
그래서 처음부터 완벽한 시스템을 만들려고 하기보다 가장 단순한 흐름부터 시작하는 것이 좋습니다.
Request 작성 → Submit → Approve/Reject → 결과 확인
이 흐름이 제대로 작동하면 Revision을 추가합니다.
그다음 History를 추가하고, 필요하다면 Multiple Approver와 Reminder를 추가합니다.
작게 만들고 → 테스트하고 → 업무 규칙을 확인하고 → 기능을 하나씩 확장하는 것.
저는 이것이 비개발자가 바이브코딩으로 Approval 시스템에 접근하기 가장 현실적인 방법이라고 생각합니다.
결국 바이브코딩으로 승인 업무를 자동화한다는 것은 단순히 Approve 버튼을 만드는 것이 아닙니다.
사람들이 머릿속으로 알고 있던 회사의 승인 규칙을 하나씩 정리해서 프로그램이 이해할 수 있는 구조로 바꾸는 과정에 더 가깝습니다.
0 Comments