엑셀·카톡·메일로 도는 업무를 자동화할 때 경계
운영팀이 엑셀 파일을 정리하고, 카톡으로 승인 여부를 묻고, 메일로 결과를 전달하는 흐름은 처음에는 빠르게 보입니다. 담당자가 내용을 알고 있고, 업무량도 감당할 수 있기 때문입니다.
문제는 업무가 조금만 늘어도 시작됩니다. 같은 정보가 여러 파일에 나뉘고, 메시지에 담긴 요청이 누락됩니다. 승인 여부가 개인 대화방에 남으면 나중에 왜 그렇게 처리했는지 찾기 어렵습니다.
이때 바로 AI 업무 자동화를 붙이면 처리 속도는 빨라질 수 있지만, 잘못된 입력이나 애매한 판단도 함께 빨라질 수 있습니다. 업무 자동화의 핵심은 사람을 전부 빼는 데 있지 않습니다. 반복되는 이동과 정리는 자동화하되, 입력 검증과 승인 지점은 의도적으로 남기는 데 있습니다.
자동화 전에 업무 흐름을 한 줄로 적어 보기
첫 단계는 어떤 도구를 쓸지 정하는 일이 아닙니다. 현재 업무가 어떤 입력으로 시작해 어떤 결과로 끝나는지 적어야 합니다.
예를 들어 운영팀이 문의 내용을 엑셀에 옮기고, 담당자가 카톡으로 처리 가능 여부를 묻고, 승인된 내용을 메일로 전달한다고 가정해 보겠습니다. 이 흐름은 다음처럼 나눌 수 있습니다.
- 입력: 폼, 메일, 카톡, 엑셀에 들어오는 요청
- 정리: 이름, 연락처, 요청 유형, 우선순위 추출
- 검증: 필수 정보 누락 여부와 중복 요청 확인
- 판단: 처리 가능 여부와 담당자 배정
- 승인: 비용, 외부 발송, 상태 변경에 대한 책임자 결정
- 실행: 안내 메일 발송이나 관리자 화면의 상태 변경
- 기록: 입력값, 처리 결과, 승인자, 처리 시각 저장
여기서 자동화 후보는 정리와 반복 전달에 가깝습니다. 반면 비용이 발생하거나 외부에 공식 답변을 보내는 단계는 승인 없이 실행하지 않는 편이 안전합니다.
업무 흐름을 이렇게 쪼개면 개발사와 상담할 때도 대화가 달라집니다. “AI로 업무를 자동화해 주세요”가 아니라 “메일 내용을 구조화하고, 누락된 정보는 담당자에게 돌려보내며, 외부 발송 전에는 담당자 승인을 받게 해 주세요”라고 말할 수 있습니다.
입력 소스를 먼저 제한해야 하는 이유
엑셀, 카톡, 메일을 모두 자동화 시스템의 입력으로 연결하는 방식은 편해 보입니다. 하지만 입력 형식과 책임 주체가 제각각이면 시스템이 처리할 수 있는 범위도 불분명해집니다.
먼저 업무에 필요한 최소 입력을 정해야 합니다. 요청 유형, 대상, 처리 기한처럼 필수 항목이 있다면 자동화가 시작되기 전에 값이 들어왔는지 검사해야 합니다. 날짜 형식이 다르거나 같은 요청이 여러 번 들어왔을 때의 처리 방식도 미리 정해야 합니다.
AI를 쓰는 경우에도 AI의 결과를 원본 사실처럼 취급하지 않는 구조가 필요합니다. AI는 메일이나 메시지에서 내용을 추출하고 분류하는 데 활용할 수 있지만, 추출된 값이 업무 규칙에 맞는지는 별도의 검증 단계를 거쳐야 합니다.
자동화의 첫 경계는 AI가 무엇을 잘하느냐가 아니라, 틀린 입력이 다음 단계로 넘어가기 전에 어디서 멈추느냐입니다.
입력 소스가 너무 많다면 처음부터 모두 연결하지 않는 선택도 가능합니다. 가장 자주 쓰고 형식이 비교적 일정한 소스 하나를 기준으로 시작한 뒤, 예외와 누락을 확인하면서 범위를 넓히는 편이 관리하기 쉽습니다.
승인 지점은 판단의 종류로 나누기
승인 단계가 있다는 사실만으로 충분하지 않습니다. 어떤 판단에 누가 책임을 지는지 정해야 합니다.
단순한 형식 검사는 자동 처리할 수 있습니다. 필수값이 있는지, 이미 처리된 요청인지, 같은 식별값이 반복되는지처럼 규칙으로 표현할 수 있는 항목이 여기에 해당합니다. 반면 예외 승인, 비용 발생, 고객에게 전달되는 확정 안내는 담당자의 판단이 필요할 수 있습니다.
승인 설계에서는 다음 질문을 문서로 남기는 것이 좋습니다.
- 승인 없이 실행해도 되는 작업은 어디까지인가
- 자동화가 보류 상태로 보내야 하는 조건은 무엇인가
- 승인자는 특정 개인인가, 역할을 가진 팀인가
- 승인 요청이 오래 멈췄을 때 누구에게 알릴 것인가
- 승인 이후 값이 바뀌면 다시 승인을 받아야 하는가
특히 승인자는 개인 이름보다 역할로 설계하는 편이 운영에 유리합니다. 담당자가 바뀌어도 흐름이 끊기지 않기 때문입니다. 다만 실제 시스템에서는 권한을 가진 사용자를 식별할 수 있어야 하므로, 관리자 웹에서 역할과 접근 범위를 관리하는 구조가 필요합니다.
자동화가 처리한 결과를 바로 외부로 보내기 어렵다면, 관리자 화면에 대기 목록을 두는 방법도 있습니다. 담당자는 원문과 추출 결과를 비교한 뒤 승인하거나 반려할 수 있습니다. 이 방식은 사람의 개입을 없애지는 않지만, 사람이 반복 입력을 하는 대신 중요한 판단에 집중하게 만듭니다.
나중에 추적할 수 있는 기록을 남기기
업무 자동화는 실행 순간보다 문제가 생긴 뒤의 추적성이 중요합니다. 특정 요청이 언제 들어왔고, 어떤 값으로 분류됐으며, 누가 승인했고, 실제로 어떤 작업이 실행됐는지 확인할 수 있어야 합니다.
최소한 다음 기록은 남기는 편이 좋습니다.
- 원본 입력과 입력 시각
- 자동화가 추출하거나 변환한 값
- 검증 결과와 보류 사유
- 승인자와 승인 시각
- 실제 실행 결과와 오류 내용
- 같은 요청의 재처리 여부
여기서 중복 실행을 막는 설계도 빠지기 쉽습니다. 네트워크 오류 때문에 결과를 받지 못한 뒤 같은 요청을 다시 보내면 메일이 두 번 발송되거나 상태가 여러 번 바뀔 수 있습니다. 요청마다 고유한 처리 식별값을 두고, 이미 처리된 요청인지 확인하는 구조가 필요합니다. 이런 방식을 idempotency 설계라고 부릅니다.
기록은 많이 남긴다고 좋은 것만은 아닙니다. 업무에 필요한 정보와 접근 권한을 함께 정해야 합니다. 원본 메시지 전체를 오래 보관할지, 관리자 화면에서 어떤 역할이 어떤 기록을 볼 수 있는지도 범위에 포함해야 합니다.
첫 자동화 범위를 정하는 기준
반대로 초기 범위에서 뒤로 미루는 편이 나은 업무도 있습니다. 입력 형식이 매번 다르고 예외가 대부분인 업무, 자동 실행 한 번의 영향이 큰 업무, 책임자가 불분명한 업무는 먼저 운영 규칙을 정리해야 합니다.
발주 전에는 다음 자료를 준비하면 상담과 범위 산정이 구체적으로 진행됩니다.
- 현재 업무를 시작하는 입력 소스와 예시 자료
- 담당자가 실제로 거치는 처리 단계
- 자동 처리와 수동 승인을 나눈 기준
- 예외 상황과 반려 기준
- 필요한 관리자 역할과 접근 범위
- 외부 발송이나 상태 변경의 대상
- 보관해야 할 기록과 삭제 기준
좋은 자동화는 사람이 사라진 업무가 아닙니다. 사람이 반복해서 옮기던 정보는 줄이고, 입력이 잘못되거나 판단이 필요한 순간에는 멈출 수 있는 업무입니다. 이 경계를 먼저 정하면 AI를 어디에 쓸지, 관리자 웹이 필요한지, API와 데이터베이스를 어떤 순서로 구성할지까지 자연스럽게 좁혀집니다.
엑셀·카톡·메일로 나뉜 업무를 자동화하려면 현재 흐름과 승인 지점을 먼저 함께 정리하는 것이 좋습니다. 자동화 범위와 관리자 운영 구조를 진단받고 싶다면 Universoft에 문의해 주세요. https://www.universoft.kr/contact