신청서를 받으면 담당자에게 알림을 보내는 자동화는 간단해 보입니다. 하지만 신청 저장은 끝났는데 알림 전송이 실패했다면 무엇을 다시 실행해야 할까요? 자동화의 범위는 정상 흐름보다 이 질문에서 더 분명해집니다.
“처리 완료”를 작은 상태로 나눕니다
고객이 신청 버튼을 누르는 순간부터 담당자가 일을 시작하기까지는 여러 단계가 있습니다. 신청 접수, 내용 확인, 담당자 배정, 알림 전송을 하나의 성공 표시로 묶으면 어느 단계에서 멈췄는지 알기 어렵습니다.
처음부터 복잡한 시스템을 만들 필요는 없습니다. 실제 운영에서 결과를 구분해야 하는 지점만 상태로 남기면 됩니다. 아래는 상담 신청을 예로 든 설계안이며, GROWTHLINE이나 특정 고객사의 실제 운영 구조를 공개한 자료가 아닙니다.
| 상태 | 확인된 사실 | 다음 행동 |
|---|---|---|
| 접수됨 | 신청 내용이 저장됨 | 필수 정보와 담당 범위 확인 |
| 확인 필요 | 자동으로 판단하기 어려운 조건이 있음 | 담당자가 누락·예외 확인 |
| 배정됨 | 책임 담당자가 정해짐 | 고객과 담당자에게 필요한 안내 |
| 알림 실패 | 배정은 완료됐으나 안내 전송 실패 | 알림 결과 확인 후 해당 단계 처리 |
| 처리 종료 | 이번 자동화가 맡은 범위가 끝남 | 상담 결과는 별도 업무로 추적 |
시스템의 처리 종료가 고객 문제의 해결을 뜻하지는 않습니다. 신청 접수 자동화가 끝났더라도 상담이나 계약은 남아 있습니다. 화면에 쓰는 완료 문구도 실제로 끝난 범위와 일치시켜야 합니다.
실패의 종류마다 재시도 여부가 달라집니다
연락처가 빠진 신청은 잠시 기다린다고 정상으로 바뀌지 않습니다. 외부 전송 서비스의 일시 장애는 시간이 지나면 회복될 수 있지만, 요청이 성공했는지 응답만 받지 못한 상황은 먼저 결과 확인이 필요합니다. 이 셋을 같은 오류로 묶어 전부 다시 실행하면 중복 처리나 끝없는 반복이 생길 수 있습니다.
| 예외 | 자동 처리 후보 | 사람에게 넘길 기준 |
|---|---|---|
| 필수 정보 누락 | 누락 항목 표시 | 추가 확인이 필요한 신청 |
| 일시적인 전송 실패 | 제한된 횟수와 간격으로 재시도 | 정한 재시도 한도 초과 |
| 성공 여부가 불명확 | 외부 처리 결과 조회 | 결과를 확인할 수 없음 |
| 정책상 판단이 필요한 요청 | 자동 결정 보류 | 권한 있는 담당자 검토 |
“최대 세 번” 같은 숫자를 먼저 정하기보다 실행의 비용, 중복됐을 때의 영향, 외부 시스템의 제한을 확인해야 합니다. 안내 한 번을 다시 보내는 일과 예약 한 건을 다시 만드는 일의 위험은 다릅니다.
같은 요청과 새로운 요청을 구별합니다
고객이 버튼을 두 번 누르거나 네트워크 연결이 끊겨 요청이 다시 들어올 수 있습니다. 이때 “같은 고객이 보냈으니 중복”이라고 처리하면 고객의 새로운 신청까지 지울 수 있습니다. 같은 실행을 다시 시도하는 것인지, 내용과 목적이 다른 새 요청인지 판단할 기준이 필요합니다.
개발 단계에서는 요청 식별값과 중복 방지 장치를 검토할 수 있습니다. Stripe의 API는 멱등성 키를 이용해 같은 요청의 재시도가 중복 동작으로 이어지지 않도록 하는 사례를 설명합니다. 이것이 모든 자동화 도구에 기본 제공된다는 뜻은 아닙니다. 사용하는 제품에서 키를 받는지, 유효 기간이 있는지, 실패 결과를 어떻게 다루는지 따로 확인해야 합니다.
기획 문서에는 기술 이름보다 “저장은 한 번, 알림만 다시 처리할 수 있어야 한다”처럼 지켜야 할 결과를 먼저 적으세요. 담당 개발자는 이 요구를 실제 API와 저장 구조에 맞는 방식으로 구현할 수 있습니다.
수동 인계에는 오류 메시지 이상의 정보가 필요합니다
담당자에게 “실패했습니다”라는 알림만 보내면 처음부터 다시 조사해야 합니다. 사람이 이어서 처리할 수 있도록 이미 끝난 일, 아직 하지 않은 일, 하면 안 되는 일을 함께 남겨야 합니다.
- 업무 식별 정보: 어떤 신청이나 처리 건인지
- 현재 상태: 마지막으로 성공을 확인한 단계
- 실패 내용: 관찰된 오류와 발생 시각
- 실행 이력: 실제 시도 횟수와 각 결과
- 다음 행동: 재확인·재실행·고객 연락 중 무엇이 필요한지
- 책임과 권한: 누가 판단하고 누가 실행할 수 있는지
가령 “신청 저장 완료, 담당자 배정 완료, 안내 전송 결과 불명확”이라면 첫 행동은 신청을 새로 만드는 일이 아닙니다. 기존 신청과 안내 결과를 확인하고, 필요한 단계만 이어서 처리해야 합니다.
자동화를 멈추고 복구하는 방법도 범위에 넣습니다
예외가 늘어났을 때 새 요청만 잠시 멈출지, 진행 중인 요청도 중단할지 정해둡니다. 일괄 중지라는 버튼 하나로 고객에게 이미 약속한 작업이 사라져서는 안 됩니다. 누가 중지를 결정하고, 대기 건을 어디에서 확인하며, 재개할 때 무엇부터 처리하는지 문서에 남깁니다.
GOV.UK의 서비스 설계 안내는 고객의 전체 문제와 조직 간 연결을 함께 살피도록 설명합니다. 이를 작은 팀에 적용하면 자동화 도구 화면만 그리지 않고 고객 안내, 내부 확인, 수동 복구까지 하나의 업무 흐름으로 검토할 수 있습니다.
출시 전에 정상 경로 밖의 다섯 장면을 재현합니다
- 같은 요청을 두 번 전달해 중복 실행이 생기는지 확인합니다.
- 입력값 일부가 빠졌을 때 자동 처리가 보류되는지 확인합니다.
- 외부 서비스가 실패하면 완료된 앞 단계까지 반복하는지 확인합니다.
- 처리 중 담당자가 바뀌어도 책임과 이력이 유지되는지 확인합니다.
- 수동으로 복구한 건을 자동화가 다시 실행하지 않는지 확인합니다.
테스트 결과는 “정상” 한 단어보다 시작 상태·발생 사건·기대 결과·실제 결과로 남깁니다. 이 표가 있으면 기능이 늘어도 무엇을 보존해야 하는지 설명하기 쉬워집니다.
자동화할 도구보다 업무의 경계를 먼저 정합니다
처음에는 반복량이 많고 판단 기준이 명확한 업무 한 구간을 고르세요. 판단이 복잡한 예외까지 한 번에 자동화하는 대신 보류 상태와 담당자 인계로 운영 범위를 분명히 만들 수 있습니다. 화면·상태·권한·완료 기준을 정리하는 작업은 GROWTHLINE 비즈니스 로직 설계 서비스와 연결됩니다.
고객 화면과 내부 운영이 연결되는 관점은 Domino’s의 디지털 주문 운영 사례에서도 살펴볼 수 있습니다. 사례는 참고 관점이며 같은 도구나 성과를 재현한다는 약속은 아닙니다.
참고 자료와 적용 범위
자료는 요청 중복 방지와 전체 업무 흐름을 설명하는 근거로 사용했습니다. 상태표·예외표·출시 시나리오는 이 글에서 제안하는 설계 예시입니다. 실제 재시도·보관·복구 정책은 사용하는 시스템과 업무에 맞춰 정해야 합니다. 자료 확인일: 2026년 9월 16일.