회사에서 일을 하다 보면 업무 요청이 정말 다양한 곳에서 들어옵니다.
어떤 사람은 이메일로 요청하고, 어떤 사람은 Teams 같은 메신저로 이야기합니다. 회의 중에 갑자기 요청이 나오기도 하고, 전화로 이야기한 뒤 나중에 처리해야 하는 경우도 있습니다.
문제는 요청 자체보다 요청이 여러 곳에 흩어져 있다는 것입니다.
“지난번에 요청드린 건 어떻게 됐나요?”라는 연락을 받고 나서야 예전 이메일이나 메시지를 다시 찾아본 경험도 직장인이라면 한 번쯤 있을 것입니다.
바이브코딩으로 업무 자동화를 생각하면서 저는 이런 업무도 좋은 자동화 아이디어가 될 수 있다고 생각했습니다.
이메일, 메신저, 회의 등으로 들어오는 업무 요청을 한곳에서 관리하면 어떨까?
거창한 프로젝트 관리 시스템이 아니라 누가, 언제, 무엇을 요청했고 현재 어디까지 처리됐는지만 한눈에 확인할 수 있는 간단한 프로그램부터 시작하는 것입니다.
이번 글에서는 바이브코딩을 활용해 이런 업무 요청 관리 프로그램을 만든다면 어떤 구조와 기능이 필요한지 정리해보겠습니다.
이메일과 메신저로 업무를 관리하면 생기는 문제
업무 요청을 이메일로 받는 것 자체가 문제는 아닙니다.
Teams나 Slack 같은 메신저로 간단하게 요청을 받는 것도 편리합니다.
문제는 시간이 지나면서 발생합니다.
월요일에는 이메일로 A 업무를 요청받고, 화요일에는 메신저로 B 업무를 요청받습니다. 수요일 회의에서는 C 기능을 검토해달라는 이야기가 나옵니다.
며칠 뒤에는 새로운 요청이 계속 들어옵니다.
그러다 보면 머릿속으로 모든 요청을 기억하기 어려워집니다.
결국 이메일에서 키워드를 검색하고, 메신저 기록을 찾아보고, 개인 메모까지 확인하게 됩니다.
이때 필요한 것은 또 하나의 복잡한 시스템이 아니라 흩어진 요청을 한곳에서 볼 수 있는 공간일 수 있습니다.
1. 가장 먼저 만들 기능은 ‘요청 등록’
처음부터 이메일이나 메신저와 자동으로 연결할 필요는 없습니다.
오히려 바이브코딩으로 처음 만든다면 아주 단순하게 시작할 수 있습니다.
+ New Request
버튼을 누르면 업무 요청을 등록하는 화면이 나타나는 것입니다.
예를 들어 다음과 같은 정보를 입력합니다.
Request Title / Requester / Request Date / Request Channel / Description / Priority / Due Date / Status
Request Channel에는 Email, Teams, Meeting, Phone, Request Form 등을 선택할 수 있게 합니다.
그러면 요청이 어디에서 들어왔든 결국 하나의 목록에 저장됩니다.
이것만으로도 첫 번째 목표인 업무 요청을 한곳에서 관리하기가 가능해집니다.
2. 요청 상태를 관리한다
업무 요청을 등록하는 것보다 중요한 것은 그다음입니다.
현재 어디까지 처리됐는지를 알아야 합니다.
처음에는 복잡한 Workflow를 만들 필요가 없습니다.
예를 들어,
New → In Progress → Pending → Completed
정도만 있어도 충분합니다.
새로운 요청이 들어오면 New, 작업을 시작하면 In Progress, 다른 사람의 답변이나 자료를 기다리고 있다면 Pending, 모든 작업이 끝났다면 Completed로 변경하는 것입니다.
이렇게 하면 이메일을 다시 열어보지 않아도 Dashboard에서 현재 진행 중인 요청을 확인할 수 있습니다.
3. 담당자를 지정한다
혼자 사용하는 프로그램이라면 담당자가 필요하지 않을 수도 있습니다.
하지만 여러 사람이 요청을 처리한다면 Owner가 중요해집니다.
예를 들어 요청 하나에,
Requester: Marketing Team
Owner: John
Status: In Progress
Due Date: Sep 30
처럼 담당자를 지정하는 것입니다.
그러면 Dashboard에서 My Requests를 선택했을 때 내가 처리해야 하는 요청만 볼 수 있습니다.
관리자 입장에서는 특정 사람에게 업무가 너무 많이 몰려 있는지도 확인할 수 있습니다.
단순한 Request List가 조금씩 업무 관리 프로그램으로 발전하기 시작합니다.
4. Priority와 Due Date를 추가한다
모든 요청이 똑같이 중요한 것은 아닙니다.
어떤 요청은 오늘 처리해야 하고 어떤 요청은 다음 주까지 처리해도 됩니다.
그래서 High / Medium / Low 같은 Priority를 추가할 수 있습니다.
Due Date도 함께 관리합니다.
예를 들어 Dashboard 상단에,
Overdue 3 / Due Today 5 / High Priority 4
처럼 보여주면 프로그램을 열었을 때 무엇부터 처리해야 하는지 바로 알 수 있습니다.
제가 생각하는 좋은 업무 자동화는 모든 업무를 대신 처리하는 프로그램만을 의미하지 않습니다.
“오늘 내가 무엇을 먼저 해야 하는지 알려주는 것”
역시 충분히 좋은 자동화입니다.
5. 오래된 요청을 자동으로 찾아준다
업무 요청이 많아지면 가장 위험한 것은 오래된 요청이 목록 아래로 밀려나는 것입니다.
예를 들어 New 상태로 7일 이상 남아 있는 요청이나 In Progress 상태로 14일 이상 변화가 없는 요청을 자동으로 찾아볼 수 있습니다.
이런 요청에는,
Needs Attention
같은 표시를 붙일 수 있습니다.
그러면 사람이 매일 목록을 위에서 아래까지 확인할 필요가 없습니다.
프로그램이 먼저 확인이 필요한 요청만 골라주는 것입니다.
이런 기능은 로직이 비교적 명확하기 때문에 바이브코딩으로 기능을 구상하기에도 좋습니다.
6. 이메일이나 메신저 원문을 연결한다
업무 요청을 관리하다 보면 결국 원래 요청 내용을 다시 확인해야 할 때가 있습니다.
그럴 때 Request에 원본 이메일이나 관련 자료의 링크를 저장할 수 있습니다.
예를 들어 요청 상세 화면에,
Original Request / Related Email / Related Document / Attachment
같은 영역을 두는 것입니다.
그러면 “이 요청이 왜 들어왔지?”라는 생각이 들었을 때 이메일을 처음부터 검색할 필요가 없습니다.
요청을 열고 관련 자료로 바로 이동할 수 있습니다.
이 기능은 특히 몇 달 동안 이어지는 업무에서 유용할 수 있습니다.
7. Comment와 History를 남긴다
업무 요청은 한 번 등록하고 끝나는 경우보다 중간에 내용이 바뀌는 경우가 많습니다.
처음에는 A 기능을 요청했는데 검토 과정에서 B 조건이 추가될 수도 있습니다.
그래서 Request마다 Comment를 남길 수 있도록 만들 수 있습니다.
또 중요한 것은 History입니다.
예를 들어,
Sep 20 – Request Created
Sep 21 – Status changed to In Progress
Sep 23 – Due Date changed
Sep 25 – Comment added
Sep 27 – Completed
처럼 변경 내역을 확인할 수 있도록 하는 것입니다.
단순히 현재 상태만 보여주는 것보다 어떤 과정을 거쳐 현재 상태가 되었는지 확인할 수 있게 됩니다.
8. Dashboard에서 전체 업무를 확인한다
데이터가 쌓이기 시작하면 Dashboard가 유용해집니다.
예를 들어 프로그램을 열었을 때,
Total Requests / New / In Progress / Pending / Completed / Overdue
숫자를 보여줄 수 있습니다.
그 아래에는 Priority나 담당자별 요청 현황을 보여줄 수도 있습니다.
여기서 중요한 것은 Dashboard를 화려하게 만드는 것이 아닙니다.
업무를 판단하는 데 필요한 정보를 빠르게 보여주는 것이 목적입니다.
전체 요청이 100건이라는 것보다 High Priority + Overdue 요청이 3건이라는 정보가 더 중요할 수 있습니다.
9. 검색과 필터 기능을 만든다
요청이 10건일 때는 목록만 있어도 충분합니다.
100건이 되면 달라집니다.
그래서 Status, Owner, Requester, Priority, Request Date 등의 조건으로 필터링할 수 있어야 합니다.
예를 들어,
Status = In Progress
Owner = Me
Priority = High
조건을 적용하면 지금 내가 우선적으로 처리해야 하는 요청만 볼 수 있습니다.
키워드 검색도 유용합니다.
예전에 받았던 Invoice, Contract, Excel 관련 요청을 검색하면 해당 요청만 보여주는 방식입니다.
단순해 보이지만 실제 업무 프로그램에서는 이런 기본 기능이 사용성을 크게 좌우합니다.
10. 나중에는 Reminder까지 자동화할 수 있다
Request 관리 프로그램이 안정적으로 작동한다면 마지막으로 알림 기능을 생각해볼 수 있습니다.
예를 들어 Due Date가 하루 남았다면 담당자에게 알려주거나, 일정 기간 업데이트가 없는 요청을 알려주는 것입니다.
다만 저는 처음부터 자동 이메일 발송까지 만드는 것보다 단계적으로 접근하는 것이 좋다고 생각합니다.
처음에는 Dashboard에,
Due Soon / Overdue / No Update
를 보여주는 정도로 시작합니다.
그다음 알림이 실제로 필요한지 확인하고 이메일이나 메신저 Notification으로 확장하는 것입니다.
자동화는 기능이 많다고 좋은 것이 아니라 실제로 사람이 반복하던 행동을 줄여줄 때 의미가 있기 때문입니다.
바이브코딩으로 만든다면 어디서부터 시작할까?
처음부터 위의 기능을 모두 만들어달라고 AI에게 요청하면 프로그램이 지나치게 복잡해질 수 있습니다.
그래서 가장 작은 버전부터 시작하는 것이 좋습니다.
첫 번째 버전은 딱 세 가지면 충분합니다.
Request 등록 → Request 목록 → Status 변경
이 세 가지가 제대로 작동하면 다음으로 Search와 Filter를 추가합니다.
그다음 Priority와 Due Date를 추가합니다.
이후 Dashboard, History, Reminder 등을 하나씩 붙이는 것입니다.
이렇게 만들면 문제가 생겼을 때 어느 기능에서 발생했는지도 찾기 쉽습니다.
AI에게는 이렇게 요청할 수 있다
바이브코딩을 시작할 때 단순히,
업무 관리 프로그램 만들어줘.
라고 요청하는 것보다 필요한 기능과 범위를 설명하는 것이 좋습니다.
예를 들어 이렇게 시작할 수 있습니다.
회사에서 이메일, 메신저, 회의 등 다양한 경로로 들어오는 업무 요청을 한곳에서 관리할 수 있는 간단한 웹 프로그램을 만들고 싶어.
첫 번째 버전에서는 Request Title, Requester, Request Channel, Request Date, Description, Priority, Due Date, Status를 입력할 수 있게 해줘.
Status는 New, In Progress, Pending, Completed로 구성해줘.
메인 화면에서는 전체 Request를 목록으로 보여주고 Status와 Priority로 필터링할 수 있게 해줘.
처음부터 복잡한 기능을 추가하지 말고 먼저 필요한 화면과 데이터 구조를 설명해줘. 내가 확인한 다음 코드를 작성해줘.
저는 마지막 부분이 특히 중요하다고 생각합니다.
바로 코드를 만들어달라고 하기보다 먼저 AI가 이해한 요구사항과 프로그램 구조를 확인하는 것입니다.
그러면 내가 생각한 프로그램과 AI가 이해한 프로그램이 다른 문제를 줄일 수 있습니다.
이메일과 메신저를 처음부터 자동 연결할 필요는 없다
제목이 ‘이메일·메신저 요청을 한곳에서 관리하기’라고 해서 처음부터 이메일과 Teams 같은 서비스의 API를 모두 연결할 필요는 없습니다.
오히려 첫 번째 버전에서는 사람이 직접 요청을 등록해도 됩니다.
중요한 것은 업무 요청을 한곳에 모으는 구조가 실제로 도움이 되는지 확인하는 것입니다.
실제로 사용해보고 유용하다면 다음 단계에서 이메일이나 메신저와의 연동을 검토할 수 있습니다.
이런 방식이 바이브코딩에서 특히 중요합니다.
아이디어 → 작은 Prototype → 직접 확인 → 필요한 기능 추가
처음부터 완벽한 시스템을 만드는 것이 아니라 실제로 필요한지를 확인하면서 프로그램을 키워가는 것입니다.
직접 만들어보면 ‘기능’보다 ‘업무 규칙’이 어렵다
이런 프로그램을 생각하다 보면 처음에는 화면이나 버튼에 관심이 갑니다.
하지만 실제 업무에서는 더 어려운 질문이 생깁니다.
Request를 누가 Close할 수 있는지,
Completed된 Request를 다시 Open할 수 있는지,
Due Date가 없는 요청은 어떻게 할지,
Owner가 변경되면 History를 남길지,
한 Request에 여러 명을 담당자로 지정할 수 있는지 등입니다.
이런 것은 AI가 마음대로 결정해서는 안 됩니다.
회사의 업무 방식에 따라 사람이 결정해야 하는 Business Rule이기 때문입니다.
그래서 AI에게도 이렇게 요청하는 것이 좋습니다.
내가 설명하지 않은 Business Rule은 임의로 결정하지 말고
[확인 필요]로 표시해줘.
바이브코딩을 하다 보면 결국 좋은 프로그램을 만드는 데 필요한 것은 코딩 지식만이 아니라 업무를 얼마나 정확하게 이해하고 있는가라는 점을 알게 됩니다.
업무 요청 관리 프로그램을 만들면서 기대할 수 있는 변화
이 프로그램의 가장 큰 목적은 요청을 받지 않는 것이 아닙니다.
이메일도 계속 사용할 것이고 메신저도 계속 사용할 것입니다.
달라지는 것은 요청을 받은 이후의 관리 방식입니다.
예전에는 이메일을 다시 검색하고, 메시지를 찾아보고, 개인 메모를 확인했다면 이제는 하나의 Request List에서 확인할 수 있습니다.
그리고 프로그램을 열었을 때,
무엇이 새로 들어왔는지, 무엇을 처리하고 있는지, 무엇이 늦어지고 있는지, 무엇을 오늘 확인해야 하는지
알 수 있게 만드는 것입니다.
저는 이런 작은 변화가 업무 자동화에서 상당히 중요하다고 생각합니다.
마무리｜바이브코딩은 업무의 ‘틈’을 프로그램으로 바꿀 수 있다
회사에는 이미 이메일, 메신저, Excel, ERP, 여러 업무 시스템이 있습니다.
그런데도 사람들이 개인 Excel이나 메모장을 따로 사용하는 이유가 있습니다.
기존 시스템 사이에 작은 업무의 틈이 있기 때문입니다.
업무 요청 관리도 그중 하나일 수 있습니다.
이메일로 요청은 받지만 전체 현황을 보기 어렵고,
메신저에서는 빠르게 이야기할 수 있지만 오래된 요청을 찾기 어렵고,
회의에서는 업무가 결정되지만 이후 진행 상황을 추적하기 어렵습니다.
바이브코딩을 활용하면 이런 작은 불편을 발견했을 때,
“이 문제만 해결하는 작은 프로그램을 만들어보면 어떨까?”
라는 접근을 해볼 수 있습니다.
처음에는 Request 등록, 목록, Status 변경만 있어도 됩니다.
그다음 실제로 사용하면서 Search, Priority, Due Date, Dashboard, History, Reminder를 하나씩 추가하면 됩니다.
결국 바이브코딩으로 업무를 자동화한다는 것은 거대한 시스템을 만드는 것만을 의미하지 않습니다.
매일 조금씩 불편했던 업무를 찾아 작은 프로그램으로 해결해보는 것.
그런 작은 프로그램 하나가 생각보다 많은 이메일 검색과 메신저 확인 시간을 줄여줄 수도 있습니다.
0 Comments