'한 번 설정하면 끝'이라는 자동화는 조용히 실패합니다. 그 방법을 알려드립니다.

요약 (TL;DR): 자동화는 환경이 그 아래에서 변화하기 때문에 조용히 망가집니다. API가 변경되고, OAuth 토큰이 만료되며, 웹훅 (webhook)을 놓치고, 워크플로 (workflow)가 원래 의도한 대로 작동을 멈췄음에도 대시보드에는 초록색 체크 표시가 나타납니다. 신뢰성을 유지하는 설정은 모호한 상황에서 사람이 개입하도록 하여, 문제가 몇 주 뒤가 아닌 아직 작을 때 표면으로 드러나게 합니다.

한 개발자가 얼마 전 자신의 자동화 포트폴리오를 온라인에 게시했습니다: "19개의 워크플로, 4개의 고장난 트리거 (trigger), 3개의 불안정한 토큰 (token), 내가 보지 않을 때만 실행되는 1개의 웹훅 (webhook)." 이는 농담조로 작성된 것이었습니다. 하지만 댓글창은 이것이 자신의 설정 상황을 정확히 묘사하고 있다는 사람들로 가득했습니다.

이것이 바로 자동화가 판매되는 방식과 실제로 변하는 모습 사이의 간극입니다. 홍보 문구는 간단합니다: 워크플로를 한 번 구축하고, 실행되게 두며, 당신의 시간을 되찾으라는 것입니다. 하지만 실제로 일어나는 일은 계속해서 움직이는 표면 위에 무언가를 구축한 다음, 아무것도 움직이지 않기를 바라며 자리를 떠나는 것에 더 가깝습니다.

자동화가 예고 없이 고장 나는 이유

당신의 스택 (stack)에 있는 모든 도구(CRM, 폼 빌더, 이메일 플랫폼, 스프레드시트)는 각자의 일정에 따라 API를 업데이트합니다. Postman의 API 상태 보고서 (State of the API report)에 따르면, API의 파괴적 변경 (breaking changes)은 개발자와 통합 전문가(integrator) 모두에게 가장 큰 불만 사항 중 하나로 지속적으로 나타납니다. Zapier나 Make와 같은 성숙한 플랫폼조차 제3자 개발자가 유지 관리하는 커넥터 (connector)에 의존하는데, 이는 기반이 되는 API가 변경될 때 커넥터가 가장 먼저 고장 나는 경우가 많음을 의미합니다. 엔드포인트 (endpoint)가 변경되거나 필드 (field) 이름이 바뀌면, 이전 구조를 바탕으로 구축된 워크플로는 조용히 실패하거나, 더 나쁜 경우에는 당신이 알아챌 수 있는 오류를 실제로 발생시키지 않은 채 잘못된 데이터를 하류 (downstream)로 전달합니다.

OAuth tokens(OAuth 토큰), 즉 자동화 도구들이 서로 연결하기 위해 사용하는 인증 정보는 각 플랫폼이 독립적으로 설정한 타이머에 따라 만료됩니다. 많은 토큰이 30일에서 90일마다 만료됩니다. 대부분의 자동화 플랫폼은 이러한 일이 발생하기 전에 경고를 보내지 않습니다. 대신 트리거 (trigger)가 실행되는 데 걸리는 시간 동안 워크플로 (workflow)가 이미 중단된 이후에야 실패 알림을 보냅니다. 만약 트리거가 드물게 실행된다면, 이 기간은 며칠이 될 수도 있습니다.

웹훅 (Webhooks)은 또 다른 층위의 문제를 추가합니다. 페이로드 (payload)가 도착했을 때 수신 시스템을 사용할 수 없는 상태라면, 웹훅은 누락되며 대개 자동 재시도 (retry)가 이루어지지 않습니다. 새벽 2시에 CRM의 유지보수 시간 (maintenance window)이 설정되어 있다면, 그 시간 동안 발생하는 모든 이벤트는 사라지게 됩니다.

이 중 그 어느 것도 당신의 로직 (logic)에 있는 버그가 아닙니다. 이것은 당신이 독립적으로 작동하도록 구축한 것 아래에서 환경이 변화하고 있는 것입니다.

침묵의 대가

고장 난 자동화는 극적인 실패를 통해 자신을 알리지 않습니다. 그것은 부재 (absence)를 통해 자신을 알립니다. 후속 조치가 이루어지지 않은 리드 (leads), 라우팅 (route)되지 않은 지원 티켓 (support tickets), 발송되지 않은 인보이스 (invoices) 같은 것들 말입니다. 조사를 시작할 만큼 무언가 고통스러운 상황이 닥쳤을 때, 그 공백은 이미 몇 주 동안 열려 있는 상태가 됩니다.

리드의 사례가 가장 명백합니다. 우리가 1인 기업가를 위한 5가지 필수 워크플로 자동화에서 다루었듯이, 리드 자격 검증 (lead qualification)은 자동화할 수 있는 가장 영향력이 큰 작업 중 하나이며, 이는 곧 작동이 중단되었을 때 가장 큰 피해를 주는 작업 중 하나라는 의미이기도 합니다. Salesforce의 State of Sales 연구에 따르면, 파이프라인 (pipeline) 데이터 품질은 소규모 영업 팀의 가장 큰 운영 과제이며, 고장 난 동기화 워크플로 (sync workflows)가 주요 원인이라는 사실이 지속적으로 밝혀지고 있습니다. 조용히 고장 난 문의 양식 (contact form) 워크플로는 지난 3주 동안 양식을 제출한 모든 잠재 고객이 아무런 응답을 받지 못했음을 의미합니다. 그들 중 일부는 경쟁사로 넘어갔을 것입니다. 하지만 기록 자체가 생성되지 않았기 때문에, 당신은 그들이 누구인지조차 알 수 없습니다.

더 미묘한 문제는 데이터 드리프트 (Data Drift)입니다. 동기화 워크플로 (Sync Workflow)가 깨지면 수동 프로세스가 그 자리를 채우게 되는데, 이는 종종 일관성 없이 이루어집니다. 어떤 리드 (Leads)는 CRM에 들어가고, 어떤 것은 들어가지 않습니다. 3개월 후, 기초 데이터가 신뢰할 수 없기 때문에 파이프라인 수치는 아무런 의미가 없게 됩니다.

발견하기 더 어려운 버전은 워크플로가 계속 실행되고는 있지만 유용한 결과를 만들어내지 못하는 경우입니다. 세그멘테이션 필터 (Segmentation Filter)를 잃어버린 이메일 시퀀스 (Email Sequence)는 몇 주 동안 모든 사람에게 잘못된 메시지를 보내거나, 아예 아무에게도 보내지 않을 수 있습니다. 대시보드에는 초록색 체크 표시가 나타납니다. 기술적으로는 워크플로가 실행된 것입니다. 하지만 당신이 의도한 대로 작동하지는 않았습니다.

이를 망가뜨리는 설계상의 가정

이 문제가 어려운 이유 중 하나는 도구 자체가 "설정 후 방치 (Set and Forget)"라는 사고 모델을 조장하기 때문입니다. 대시보드는 당신이 의도한 바를 달성했는지 여부가 아니라, 작업이 실행되었는지 여부를 보여주는 데 최적화되어 있습니다. 오류 알림은 일주일에 한 번 확인하는 이메일 주소로 전송됩니다. 성공률 지표는 올바른 결과가 아닌 완료 횟수를 집계합니다.

자동화 플랫폼은 시작을 쉽게 하도록 설계되었습니다. 당신이 처리해야 할 다른 일이 15가지나 있을 때, 성능 저하를 긴급하게 느껴지도록 드러내도록 설계되지 않았습니다. 정보를 계속 파악해야 하는 부담은 다시 당신에게 돌아오며, 이는 자동화가 원래 해야 했던 역할과 정반대되는 것입니다.

실제로 유지되는 것들

시간이 지나도 신뢰성을 유지하는 워크플로들은 어떻게 구축되었는지와는 상관없는 하나의 공통된 특성을 공유합니다. 그것은 바로 최소한 부분적으로라도 여전히 인간이 루프 안에 존재한다는 것 (Human in the loop)입니다. 모든 단계를 검토하거나 모든 작업을 수동으로 승인하라는 뜻이 아닙니다. 워크플로가 무엇을 했고 무엇을 하지 않았는지 인지하고 있으며, 무언가 변했을 때 알아차릴 수 있을 만큼 연결되어 있어야 한다는 뜻입니다. 이는 개방형 에이전트 루프 (Open-ended Agent Loops)보다는 결정론적 워크플로 아키텍처 (Deterministic Workflow Architecture)를 기반으로 구축할 때 AI 에이전트가 더 안전해지는 것과 동일한 원리입니다.

실제로 이는 행동에 옮기기 전에 모호함을 드러내는 워크플로우 (workflows)를 구축하는 것을 의미합니다. 낮은 신뢰도 (low confidence)를 반환하는 분류는 이메일을 보내서는 안 됩니다. 대신 일시 중지하고 질문을 던져야 합니다. 설계되지 않은 데이터 충돌 (data conflict)에 직면한 단계는 잘못된 레코드를 작성하고 그냥 넘어가서는 안 됩니다. 기다려야 합니다.

그 결과, 문제는 아직 작을 때 나타납니다. 토큰 만료 (token expiry)를 3주 뒤가 아니라 발생한 당일에 잡아낼 수 있습니다. 라우팅 오류 (routing error)를 수백 명의 연락처에 조용히 영향을 미친 후가 아니라, 두 번째 실행 단계에서 잡아낼 수 있습니다. 시간 절약 효과는 여전히 존재합니다. 다만 '조용한 공백'이 사라지는 것입니다.

"설정하고 잊어버리세요 (Set it and forget it)"는 언제나 마케팅 문구였을 뿐, 운영 모델 (operating model)이 아니었습니다. 실제로 작동하는 방식은 "잘 설정하고, 중요한 지점에서는 연결 상태를 유지하며, 시간이 지남에 따라 자율성 (autonomy)을 얻도록 하는 것"에 더 가깝습니다. 우리는 인간의 감독 (human oversight)을 제거할 때 발생하는 숨겨진 비용과 왜 신뢰 경사 (trust gradient) 접근 방식이 실제 상황에서 더 효과적인지에 대해 글을 썼습니다.

원문은 Rills 블로그에 게시되었습니다. Rills는 1인 기업가와 마이크로 팀을 위한 자율적 의사결정 레이어 (autonomous decision layer)입니다. AI가 제안하면 인간이 모바일 스와이프 큐 (mobile swipe queue)를 통해 승인하며, 워크플로우는 자율성을 획득함에 따라 감독 단계에서 자율 단계로 졸업합니다. 승인은 항상 무료이며, AI가 실제 행동을 취할 때만 비용을 지불합니다.