업무 자동화는 성공 화면보다 실패 뒤의 행동을 먼저 정해야 한다

메일에 온 주문서를 표에 옮기고 담당자에게 알리는 작업을 자동화했다고 해봅시다. 첫 시험에서 한 건이 잘 들어가면 완성된 것처럼 느껴집니다. 하지만 실제 운영에서는 첨부파일이 없거나, 로그인 연결이 만료되거나, 같은 메일이 두 번 도착할 수 있습니다.

자동화는 컨베이어 벨트와 비슷합니다. 정상 크기의 상자만 온다면 빠르게 움직이지만 찌그러진 상자가 끼었을 때 계속 밀어붙이면 뒤의 물건까지 망가집니다. 좋은 자동화는 빨리 도는 것뿐 아니라 이상한 입력을 알아보고 안전하게 멈출 수 있어야 합니다.

한 문장으로 시작과 끝을 정한다

“주문 업무를 자동화한다”는 범위가 너무 넓습니다. “제목에 주문번호가 있는 새 메일에서 PDF 한 개를 저장하고, 주문번호와 금액을 표에 추가한 뒤 담당자에게 링크를 보낸다”처럼 시작 조건과 결과를 적습니다.

이 문장에서 자동화가 확인해야 할 값이 보입니다. 메일 제목, 첨부파일 종류와 개수, 주문번호, 금액, 저장 위치, 표의 중복 여부, 알림 수신자입니다. 무엇을 성공이라고 부를지도 “알림을 보냈다”가 아니라 “표에 한 행이 생겼고 저장된 파일 링크가 열린다”처럼 확인 가능한 상태로 바꿉니다.

입력이 이상하면 실행 전에 멈춘다

빈 주문번호를 표에 넣은 뒤 나중에 고치는 것보다 처음에 사람에게 돌려보내는 편이 안전합니다. 입력 검사는 어렵게 시작할 필요가 없습니다. 필수 값이 있는지, 형식이 맞는지, 허용한 파일인지, 이미 처리한 번호인지부터 봅니다.

예를 들어 금액이 숫자가 아니거나 첨부파일이 두 개라 어느 것을 써야 할지 모르면 추측하지 않습니다. “처리 실패” 한 줄 대신 어떤 값이 부족했는지와 원본 메일 링크를 남깁니다. 비밀번호나 고객의 전체 개인정보는 오류 알림에 복사하지 않습니다.

처리 상태: 사람 확인 필요
이유: PDF 첨부파일이 2개라 주문서를 선택할 수 없음
원본: 메일 고유번호 8f31
자동으로 한 일: 없음

읽기와 변경을 다른 단계로 나눈다

메일을 읽는 일과 주문 표를 수정하는 일은 위험이 다릅니다. 먼저 필요한 값을 읽어 미리보기로 만들고, 금액이나 고객 상태처럼 중요한 변경은 사람이 확인한 뒤 한 건씩 실행합니다. 읽기 단계가 틀려도 원본은 그대로지만 변경 단계가 틀리면 다른 사람이 잘못된 자료를 보게 됩니다.

자동화 도구에 관리자 권한 하나를 주기보다 읽기와 쓰기 권한을 필요한 범위만 나눕니다. 파일을 저장할 폴더와 수정할 표도 정확히 제한합니다. 삭제, 결제, 외부 발송은 처음부터 자동 실행하지 않고 대상과 변경 내용을 다시 보여주는 승인 지점을 둡니다.

재시도는 모든 오류에 쓰는 기능이 아니다

외부 서비스가 잠시 응답하지 않는 오류는 잠깐 기다렸다 다시 시도하면 성공할 수 있습니다. 반면 권한이 없다는 오류나 잘못된 파일 형식은 똑같이 다시 보내도 나아지지 않습니다. Microsoft는 자동화 흐름에서 오류 뒤 실행 조건, 재시도, 종료, 기록과 알림을 함께 설계하도록 안내합니다.

재시도 사이의 간격을 점점 늘리는 방식을 백오프라고 합니다. 좁은 문에 사람들이 동시에 계속 밀려드는 대신 잠시 물러났다가 차례로 들어오는 것과 비슷합니다. AWS는 재시도의 횟수를 제한하고, 중복되어도 안전한 요청인지 확인하라고 설명합니다.

• 네트워크 끊김과 일시적 서버 오류만 재시도 후보로 둡니다.
• 첫 재시도 전에 이미 성공했는지 결과를 조회합니다.
• 같은 요청이 두 번 실행돼도 중복 주문이 생기지 않게 고유번호를 씁니다.
• 기다리는 시간을 늘리고 전체 재시도 횟수에 상한을 둡니다.
• 상한에 닿으면 실패를 숨기지 않고 사람에게 넘깁니다.

로그는 원인을 찾을 만큼만 남긴다

로그는 자동화가 언제 어느 단계에서 무엇을 했는지 남기는 기록입니다. 성공과 실패 모두 작업 고유번호, 시작·종료 시각, 단계 이름, 결과 상태를 남기면 중복과 누락을 찾기 쉽습니다. 고객 정보 전체나 비밀키를 그대로 적는 것은 피합니다.

알림은 모든 실행마다 보내지 않습니다. 사람이 행동해야 하는 상황만 보냅니다. 연결 재인증이 필요하거나, 재시도 상한을 넘었거나, 변경 뒤 조회한 값이 예상과 다를 때 담당자가 볼 수 있게 합니다. 같은 오류가 수백 번 생길 때 알림도 수백 번 보내면 중요한 신호가 묻힙니다.

성공 표시 뒤에 한 번 더 조회한다

“저장 요청 성공”은 실제 파일이 열리고 표에 올바른 값이 생겼다는 뜻과 다를 수 있습니다. 변경 작업이 성공 응답을 돌려준 뒤 대상 시스템을 다시 읽어 주문번호, 금액, 파일 링크가 기대한 값과 같은지 확인합니다.

메일 발송이라면 전송 요청과 실제 배달을 구분하고, 결제라면 버튼 클릭과 결제사의 최종 상태를 구분합니다. 재조회가 실패했을 때 같은 변경을 즉시 반복하면 중복이 생길 수 있으므로 작업 고유번호로 기존 결과부터 찾습니다.

사람이 처리할 우회로를 남겨 둔다

자동화가 멈췄을 때 원래 업무까지 멈추면 복구 압박이 커집니다. 수동으로 주문을 표에 넣는 최소 절차, 자동화가 마지막으로 성공한 시각, 보류 중인 목록을 한 곳에 남깁니다. 자동화를 끄는 방법과 연결을 다시 인증할 담당자도 정합니다.

다음 상황은 자동으로 계속하지 않는 편이 좋습니다.

1. 입력의 대상이나 금액을 한 가지로 결정할 수 없을 때
2. 쓰기 권한이 예상보다 넓거나 다른 계정으로 연결됐을 때
3. 같은 작업 고유번호가 이미 처리된 것으로 보일 때
4. 변경 뒤 재조회 값이 요청과 다를 때
5. 재시도 상한을 넘었을 때
6. 삭제나 결제처럼 되돌리기 어려운 작업에 승인이 없을 때

종이 한 장으로 실패 대응표 만들기

현재 반복하는 업무 하나를 골라 시작 조건, 필요한 입력, 성공 상태를 한 문장씩 씁니다. 그 아래에 “비어 있음”, “권한 없음”, “응답 늦음”, “중복 가능”, “결과 다름” 다섯 줄을 만들고 각 줄에 멈춤, 재시도, 사람 확인 중 하나를 고릅니다.

처음 시험은 복사한 자료 한 건과 읽기 전용 권한으로 합니다. 정상 결과뿐 아니라 첨부파일을 빼거나 잘못된 금액을 넣어 실패 경로도 직접 실행합니다. 자동화가 정확히 멈추고 이유를 남긴다는 것을 확인한 뒤에만 실제 변경 권한과 실행 범위를 조금씩 넓히는 것이 안전합니다.