AI 자동화가 같은 일을 두 번 하지 않게 만드는 법: 재시도, 중복 방지, 실행 장부

1. 개요: 자동화의 진짜 위험은 "중간에 멈춘 뒤 다시 실행될 때" 생긴다

대부분의 AI 자동화 데모는 첫 실행만 보여줍니다. 버튼을 누르고, AI가 일을 하고, 결과가 나오면 데모는 끝납니다. 하지만 실제 회사에서는 그 다음 상황이 더 중요합니다. 고객 이메일은 이미 나갔는데 화면은 오류로 끝났다면 어떻게 할까요? 결제 확인은 됐는데 AI가 응답을 못 받았다면 다시 확인 메시지를 보내도 될까요? 블로그 발행 버튼은 눌렸는데 배포가 늦어지면 같은 글을 다시 발행해도 될까요?

공식 클라우드 문서들이 반복해서 말하는 핵심도 같습니다. 네트워크 문제나 일시적인 서버 오류처럼 잠깐 생긴 실패는 다시 시도하면 해결될 수 있습니다. 하지만 이미 어떤 행동이 일어났는지 모르는 상태에서 다시 실행하면, 이메일 두 번, 결제 두 번, 게시글 두 번 같은 문제가 생깁니다.

그래서 AI 자동화는 "더 똑똑한 프롬프트"만으로 신뢰할 수 있게 되지 않습니다. 같은 일을 두 번 하지 않게 막는 규칙, 실패할수록 천천히 다시 시도하는 규칙, 사람이 이어받을 수 있는 기록이 필요합니다. 개발팀은 이런 장치를 idempotency, backoff, run ledger 같은 말로 부르지만, 운영자 입장에서는 중복 방지, 천천히 재시도, 실행 장부라고 이해하면 충분합니다.

2. 기술어를 업무 언어로 바꾸면 이렇게 보인다

먼저 다시 시도, 즉 retry입니다. 인터넷 연결이 잠깐 끊겼거나 외부 서비스가 잠시 바빴다면 다시 시도하는 것이 맞을 수 있습니다. 다만 모든 실패를 다시 시도하면 안 됩니다. 고객에게 보이는 행동, 돈이 움직이는 행동, 공개 발행처럼 한 번만 일어나야 하는 일은 먼저 중복 방지 규칙이 있어야 합니다.

중복 방지, 즉 idempotency는 같은 요청이 두 번 들어와도 결과는 한 번만 만들게 하는 성질입니다. 쉽게 말해 행동마다 주문번호를 붙이는 것입니다. 같은 주문번호가 다시 오면 시스템은 "이미 처리한 일"이라고 알아봐야 합니다.

실패할수록 천천히 다시 시도하는 방식을 backoff라고 부릅니다. 여러 자동화가 동시에 몰리지 않게 시점을 살짝 흩뿌리는 것은 jitter입니다. 계속 실패하는 도구를 잠시 쉬게 하는 것은 cooldown입니다. 계속 실패한 일을 따로 빼서 사람이 보게 하는 것은 dead-letter queue입니다. 그리고 이 모든 실행 흔적을 남기는 업무 일지가 run ledger입니다.

• 다시 시도: 잠깐 실패한 일을 한 번 더 해보는 것.
• 중복 방지: 같은 이메일, 같은 결제, 같은 게시글이 두 번 생기지 않게 막는 것.
• 천천히 재시도: 실패할수록 잠시 기다렸다가 다시 해보는 것.
• 실패 보관함: 계속 실패한 일을 무한 반복하지 않고 검토 대상으로 옮기는 것.
• 실행 장부: 무엇이 왜 실행됐고, 어디서 멈췄고, 누가 이어받아야 하는지 남기는 것.

3. 근본적인 이유: AI는 불확실한 상태에서도 실제 행동을 한다

채팅 답변은 틀려도 외부 세계를 직접 바꾸지는 않습니다. 자동화는 다릅니다. 이메일을 보내고, 파일을 고치고, API를 호출하고, 레코드를 수정하고, 비용을 쓰고, 게시글을 발행하고, 후속 작업을 예약합니다. 에이전트가 세상을 만지는 순간 핵심 위험은 환각만이 아닙니다. 중복 실행, 부분 완료, 오래된 상태, 숨은 실패, 비용 폭증이 함께 생깁니다.

이것이 다시 시도와 중복 방지가 필요한 근본적인 이유입니다. 실패 응답은 항상 행동 실패를 뜻하지 않습니다. 외부 서비스는 이미 처리했지만 확인 응답만 유실됐을 수 있습니다. 브라우저 자동화는 제출 버튼을 눌렀지만 스크린샷 저장 전에 죽었을 수 있습니다. 예약 작업은 재부팅 전 이미 시작됐고, 재부팅 후 다시 시작됐을 수 있습니다. 장부가 없으면 시스템은 기억상실 상태가 됩니다.

믿을 수 있는 자동화는 불확실성을 정상 상태로 취급합니다. 다시 시도하기 전에 실패를 분류합니다. 행동 전후를 기록합니다. 같은 의도에는 같은 중복 방지 번호를 재사용합니다. 일시적 실패가 아니면 빠르게 멈춥니다. 돈, 고객 신뢰, 법적 판단, 공개 발행, 되돌리기 어려운 상태 변경은 사람에게 넘깁니다.

4. 다시 시도해도 되는 일과 멈춰야 하는 일을 먼저 나눈다

실무에서는 실패를 다섯 가지로 나눠보면 충분합니다. 첫째, 잠깐 기다렸다 다시 해도 되는 실패입니다. 둘째, 입력을 고친 뒤 다시 해야 하는 실패입니다. 셋째, 일정 시간 쉬었다 다시 해야 하는 실패입니다. 넷째, 사람이 봐야 하는 실패입니다. 다섯째, 더 하면 안 되는 실패입니다.

예를 들어 인터넷 연결이 끊긴 것은 다시 시도할 수 있습니다. 고객 이름이 빠진 것은 입력을 고쳐야 합니다. rate limit은 잠시 쉬어야 합니다. 결제가 이미 됐는지 애매한 상황은 사람이 확인해야 합니다. 권한이 없는 파일에 접근하는 것은 계속 시도해도 해결되지 않습니다.

AI는 다음 시도를 그럴싸하게 제안할 수 있습니다. 하지만 그럴싸함이 안전을 보장하지는 않습니다. 그래서 자동화에는 "언제 다시 시도하고, 언제 멈추고, 언제 사람에게 넘길지"를 먼저 적어야 합니다.

• 잠깐 실패: 인터넷 끊김, 임시 서버 오류, 잠깐 바쁜 외부 서비스.
• 고쳐야 하는 실패: 고객명 누락, 필수 항목 누락, 잘못된 파일 형식.
• 기다려야 하는 실패: rate limit, 점검 시간, 임시 잠금.
• 사람에게 넘길 실패: 돈, 고객 신뢰, 법적 판단, 공개 발행, 되돌리기 어려운 수정.
• 멈춰야 하는 실패: 금지된 행동, 권한 없음, 비즈니스 규칙 위반.

5. 중복 방지는 위험한 행동을 막는 브레이크다

중복 방지는 결제에서 가장 이해하기 쉽지만 AI 운영에도 그대로 적용됩니다. 에이전트가 "이 온보딩 이메일을 보내라"고 하면 시스템은 그 행동에 안정적인 번호를 붙여야 합니다. 전송 후 네트워크가 끊겼다면 다시 시도는 새 이메일을 만드는 것이 아니라 같은 행동 번호의 결과를 확인해야 합니다. 결과는 "이미 보냈음" 또는 원래 결과여야지 두 번째 이메일이면 안 됩니다.

Stripe는 같은 결제가 두 번 만들어지지 않도록 중복 방지 번호를 쓰는 방식을 설명합니다. AWS는 비슷한 개념을 다른 이름으로 설명합니다. 말은 다르지만 핵심은 같습니다. "이 요청이 같은 의도인지 알아볼 수 있어야 한다"는 것입니다.

작은 회사라면 이렇게 시작하면 됩니다. 읽기만 하는 작업은 대체로 다시 해도 됩니다. 상태를 바꾸는 작업은 행동 번호가 필요합니다. 비용이 드는 실시간 작업은 예산과 쉬는 시간이 필요합니다. 고객에게 보이거나 공개되는 작업은 승인 또는 되돌리는 경로가 필요합니다. 돈이 움직이는 작업은 중복 방지 번호와 확인 장부가 필요합니다.

6. 실패할수록 천천히 다시 시도해야 작은 장애가 커지지 않는다

다시 시도는 시스템을 더 안정적으로 만들 수 있지만, 잘못 쓰면 장애를 더 크게 만듭니다. 어떤 서비스가 이미 힘든 상태인데 모든 AI 자동화가 즉시 다시 요청을 보내면, 그 서비스는 더 빨리 무너집니다. 실패한 상대를 계속 두드리는 셈입니다.

그래서 실패할수록 천천히 다시 시도해야 합니다. 여러 작업이 동시에 몰리지 않게 시점도 조금씩 흩어야 합니다. 계속 실패하는 도구는 잠시 쉬게 해야 합니다. 일정 횟수 이상 실패하면 자동화가 스스로 멈추고 사람에게 넘겨야 합니다.

예를 들어 리서치 자동화는 검색 제한이 걸리면 멈춰야 합니다. 발행 자동화는 배포가 늦어지는 동안 같은 글을 다시 올리면 안 됩니다. 스크래핑 자동화는 사이트 구조가 바뀌었을 때 계속 요청을 보내지 말고 검토로 넘어가야 합니다.

7. 실행 장부: 자동화가 어디서 멈췄는지 알게 해주는 업무 일지

실행 장부는 AI 자동화에서 가장 과소평가되는 부분입니다. 화려하지 않지만 "AI가 뭔가 했다"와 "우리는 무슨 일이 있었는지 안다"의 차이를 만듭니다. 비개발자에게는 자동화 업무 일지라고 생각하면 됩니다.

장부에는 최소한 이것만 있으면 됩니다. 언제 실행됐는지, 왜 실행됐는지, 무엇을 하려 했는지, 몇 번 시도했는지, 성공했는지, 실패했다면 어디서 멈췄는지, 누가 이어받아야 하는지입니다. 개발팀은 여기에 run id, input hash, idempotency key 같은 값을 더 붙이면 됩니다.

이 장부가 있어야 같은 실패가 반복될 때 시스템을 고칠 수 있습니다. 답은 "AI가 또 실수했다"가 아니라 "체크리스트를 고치자", "승인 단계를 추가하자", "SOP를 더 명확히 하자", "이 작업은 자동화 범위를 줄이자"가 되어야 합니다.

• 언제 실행됐나?
• 무엇을 하려 했나?
• 몇 번 시도했나?
• 성공했나, 실패했나, 애매한가?
• 결과물이나 증거는 어디에 있나?
• 누가 이어받아야 하나?
• 같은 실패를 막기 위해 무엇을 바꿀 것인가?

8. 실제 프로젝트에서는 이렇게 보인다

블로그 발행 자동화를 예로 들면 쉽습니다. 글 파일이 만들어졌다고 끝이 아닙니다. 이미지가 있는지, 세 언어 페이지가 열리는지, 목록에 보이는지, sitemap에 들어갔는지, 실제 사이트에서 200으로 응답하는지 확인해야 합니다. 이것이 발행 자동화의 실행 장부입니다.

시장 조사 자동화도 같습니다. 가격을 읽기만 하는 작업은 다시 해도 비교적 안전합니다. 하지만 실제 주문, 결제, 고객 알림, 공개 발행처럼 외부에 영향을 주는 작업은 다릅니다. 같은 일을 두 번 하면 비용이나 신뢰 문제가 생기기 때문에 먼저 중복 방지 규칙이 있어야 합니다.

GUILDEX에도 같은 사고방식이 필요합니다. 고객에게 보이는 자동화는 좋은 초안을 만드는 것에서 끝나면 안 됩니다. 어떤 자료를 썼는지, 고객 정보에 어떤 영향을 줬는지, 사람 승인이 필요한지, 중복 실행을 어떻게 막는지, 결과를 어디에 남기는지 설명할 수 있어야 합니다.

9. AI가 발전할수록 사람도 함께 발전해야 하는 이유

AI가 좋아질수록 사람의 역할은 사라지지 않습니다. 역할이 위로 이동합니다. 사람이 반복 업무를 모두 타이핑하지 않아도 되지만, 어떤 일을 맡길지, 어디서 멈추게 할지, 어떤 증거를 남기게 할지, 어떤 일은 반드시 사람이 승인할지 정하는 능력은 더 중요해집니다.

약한 AI 도입은 "에이전트에게 맡기자"에서 끝납니다. 강한 AI 도입은 "목표는 이것이고, 믿을 자료는 이것이고, 중복 방지 규칙은 이것이고, 사람 승인 경계는 여기이고, 실행 장부는 여기에 남기고, 실패하면 이렇게 배운다"까지 말합니다. 이것은 사람의 일이 줄어든다는 뜻이 아닙니다. 더 가치 있는 사람이 된다는 뜻입니다.

다음 실천은 단순합니다. 반복되는 업무 하나를 고르고, 더 많은 자율성을 주기 전에 실행 장부부터 붙이세요. 그다음 한 번만 일어나야 하는 행동에 중복 방지 번호를 붙이세요. 그다음 언제 다시 시도하고 언제 멈출지 정하세요. 이 흐름이 보이면 AI 자동화는 운 좋은 프롬프트가 아니라 개선되는 업무 시스템이 됩니다.

10. 우리 회사 자동화에 바로 물어볼 7가지 질문

이 글의 모든 기술어를 외울 필요는 없습니다. 자동화를 만들거나 검토할 때 아래 질문에 답할 수 있으면 됩니다. 답을 못 하는 항목이 있다면, 그 자동화는 아직 완전 자동 실행보다 사람 검토가 먼저입니다.

• 이 자동화가 같은 일을 두 번 하면 어떤 문제가 생기나?
• 성공했는지 실패했는지 애매할 때 어떻게 확인하나?
• 다시 시도해도 안전한 일과 위험한 일은 무엇인가?
• 몇 번 실패하면 멈추고 사람에게 넘기나?
• 실행 기록은 어디에 남나?
• 고객, 돈, 계약, 공개 발행에 닿기 전 승인 단계가 있나?
• 같은 실패가 반복되면 SOP나 체크리스트가 바뀌나?