모든 기업 자동화 프로그램은 같은 벽에 부딪힙니다. ServiceNow 티켓 라우팅, Terraform 드리프트 복구, 인증서 갱신, AD 그룹 프로비저닝, SCCM 패치 배포, CI/CD 파이프라인 오케스트레이션. 처음 열 개에서 스무 개 정도의 워크플로우는 투자를 쉽게 정당화할 수 있고, ROI 계산도 잘 맞습니다. 하지만 워크플로우 수가 수백 개를 넘어서는 순간 IT 팀의 주간 업무 중 상당 부분이 새로운 자동화를 구축하는 것에서 기존 자동화가 무너지지 않게 유지하는 것으로 전환됩니다.

수납자 포털이 인증 흐름을 재설계하면 청구 제출 워크플로우의 인증이 실패합니다. Salesforce가 메타데이터를 업데이트하면 리드-투-오퍼튜니티 파이프라인의 필드 매핑이 null 값을 기록하기 시작합니다. AWS가 API 버전을 폐기하면 1년 동안 정상 작동하던 Terraform plan이 매 apply마다 400 에러를 던지기 시작합니다. 누군가 티켓을 올리고, 다른 누군가가 무엇이 변경되었는지 파악하고, 패치하고, 테스트하고, 수정을 배포합니다. 그 사이에 자동화하려던 프로세스는 수동으로 실행되거나 아예 실행되지 않습니다.

이것이 유지보수의 덫이며, 구현 실패가 아니라 구조적인 문제입니다. 전통적인 자동화는 정확한 경로를 따르고, 정확한 패턴에 일치시키며, 현실이 워크플로우 작성 당시의 상태에서 벗어나는 순간 멈춰 버립니다. 연구 결과는 일관적입니다: 조직들은 자동화 프로그램 총 비용의 70~75퍼센트를 새로운 워크플로우 구축이 아니라 기존 워크플로우를 유지하는 데 사용합니다. 대규모 배포에서는 매주 워크플로우의 45퍼센트가 깨집니다.

Triggerfish의 워크플로우 엔진은 이것을 바꾸기 위해 만들어졌습니다. 자가 복구 워크플로우는 오늘 출시되며, 플랫폼에서 지금까지 가장 중요한 기능입니다.

자가 복구가 실제로 의미하는 것

이 표현이 느슨하게 사용되는 경우가 많으니, 정확히 무엇인지 직접 설명하겠습니다.

Triggerfish 워크플로우에서 자가 복구를 활성화하면, 해당 워크플로우가 실행되는 순간 리드 에이전트가 생성됩니다. 무언가 고장 났을 때 시작되는 것이 아닙니다. 첫 번째 단계부터 지켜보고 있으며, 워크플로우가 진행되는 동안 엔진에서 실시간 이벤트 스트림을 수신하면서 모든 단계를 실시간으로 관찰합니다.

리드는 단 한 단계도 실행되기 전에 전체 워크플로우 정의를 파악합니다. 각 단계의 의도, 각 단계가 이전 단계에서 무엇을 기대하는지, 이후 단계를 위해 무엇을 생성하는지까지 포함합니다. 또한 이전 실행 이력도 알고 있습니다: 무엇이 성공했는지, 무엇이 실패했는지, 어떤 패치가 제안되었고 사람이 승인했는지 거부했는지. 조치할 만한 것을 식별하면, 사후에 재구성하는 것이 아니라 내내 지켜보고 있었기 때문에 그 모든 맥락이 이미 메모리에 있습니다.

문제가 발생하면 리드가 분류합니다. 불안정한 네트워크 호출은 백오프를 적용한 재시도를 받습니다. 우회 가능한 변경된 API 엔드포인트는 이번 실행에서 우회 처리됩니다. 워크플로우 정의의 구조적 문제는 이번 실행을 완료하기 위해 제안된 수정이 적용되고, 그 변경은 영구적으로 반영되기 전에 사용자의 승인을 거칩니다. 깨진 플러그인 통합은 새 플러그인이 작성되거나 업데이트되어 검토를 위해 제출됩니다. 리드가 시도를 소진하고도 문제를 해결할 수 없으면, 무엇을 시도했고 근본 원인이 무엇이라고 판단하는지에 대한 구조화된 진단과 함께 사용자에게 에스컬레이션합니다.

워크플로우는 안전하게 가능할 때마다 계속 실행됩니다. 한 단계가 차단되면, 해당 단계에 의존하는 하위 단계만 일시 중지되고 병렬 브랜치는 계속됩니다. 리드는 종속성 그래프를 알고 있으며 실제로 차단된 것만 일시 중지합니다.

워크플로우에 구축하는 컨텍스트가 중요한 이유

자가 복구가 실제로 작동하게 만드는 핵심은, Triggerfish 워크플로우가 작성 시점부터 풍부한 단계 수준 메타데이터를 요구한다는 것입니다. 이것은 선택 사항이 아니며 형식적인 문서화도 아닙니다. 리드 에이전트가 추론하는 근거입니다.

워크플로우의 모든 단계에는 작업 정의 자체 외에 네 가지 필수 필드가 있습니다: 단계가 기계적으로 무엇을 하는지에 대한 설명(description), 이 단계가 왜 존재하며 어떤 비즈니스 목적을 위한 것인지 설명하는 의도 선언(intent), 어떤 데이터를 수신한다고 가정하며 이전 단계가 어떤 상태여야 하는지 기술하는 기대 필드(expects), 그리고 하위 단계가 소비할 수 있도록 컨텍스트에 무엇을 기록하는지 기술하는 산출 필드(produces)입니다.

실제로 어떻게 보이는지 예를 들겠습니다. 직원 접근 권한 프로비저닝을 자동화한다고 가정합니다. 신규 입사자가 월요일에 시작하고, 워크플로우는 Active Directory에 계정을 생성하고, GitHub 조직 멤버십을 프로비저닝하고, Okta 그룹을 할당하고, 완료를 확인하는 Jira 티켓을 열어야 합니다. 한 단계가 HR 시스템에서 직원 레코드를 가져옵니다. 이 단계의 의도 필드는 단순히 "직원 레코드를 가져온다"라고 적혀 있지 않습니다. 다음과 같이 적혀 있습니다: "이 단계는 모든 하위 프로비저닝 결정의 단일 진실 공급원이다. 이 레코드의 역할, 부서, 입사일이 어떤 AD 그룹이 할당되는지, 어떤 GitHub 팀이 프로비저닝되는지, 어떤 Okta 정책이 적용되는지를 결정한다. 이 단계가 오래되었거나 불완전한 데이터를 반환하면, 모든 하위 단계가 잘못된 접근 권한을 프로비저닝하게 된다."

리드는 단계가 실패하면 이 의도 선언을 읽고 무엇이 위험에 처해 있는지 이해합니다. 불완전한 레코드가 의미하는 것은, 접근 권한 프로비저닝 단계가 잘못된 입력으로 실행되어 이틀 후에 시작하는 실제 사람에게 잘못된 권한을 부여할 수 있다는 것입니다. 이 맥락이 복구 시도 방법, 하위 단계를 일시 중지할지 여부, 에스컬레이션 시 사용자에게 무엇을 전달할지를 결정합니다.

같은 워크플로우의 다른 단계는 HR 가져오기 단계의 산출 필드를 확인하고 .employee.role과 .employee.department가 비어있지 않은 문자열로 들어올 것을 기대합니다. HR 시스템이 API를 업데이트하여 해당 필드를 .employee.profile.role 아래에 중첩하여 반환하기 시작하면, 리드는 스키마 드리프트를 감지하고, 이번 실행에 런타임 매핑을 적용하여 신규 입사자가 올바르게 프로비저닝되도록 하고, 단계 정의를 업데이트하는 구조적 수정을 제안합니다. 이 특정 경우를 위한 스키마 마이그레이션 규칙이나 예외 처리를 따로 작성할 필요가 없습니다. 리드가 이미 존재하는 컨텍스트로부터 추론해낸 것입니다.

이것이 워크플로우 작성 품질이 중요한 이유입니다. 메타데이터는 형식적 절차가 아니라, 자가 복구 시스템이 작동하는 연료입니다. 단계 설명이 빈약한 워크플로우는 정작 필요한 순간에 리드가 추론할 수 없는 워크플로우입니다.

실시간 감시로 문제가 장애가 되기 전에 포착

리드가 실시간으로 지켜보고 있기 때문에, 실제로 고장나기 전에 약한 신호에 대응할 수 있습니다. 이전에 2초 만에 완료되던 단계가 현재 40초가 걸리고 있습니다. 이전의 모든 실행에서 데이터를 반환하던 단계가 빈 결과를 반환합니다. 전체 실행 이력에서 한 번도 선택된 적 없는 조건부 브랜치가 선택됩니다. 이 중 어느 것도 하드 에러가 아니며 워크플로우는 계속 실행되지만, 환경에 무언가 변화가 있다는 신호입니다. 다음 단계가 잘못된 데이터를 소비하기 전에 포착하는 것이 낫습니다.

이러한 검사의 민감도는 워크플로우별로 설정할 수 있습니다. 야간 보고서 생성은 느슨한 임계값을 설정할 수 있고, 접근 권한 프로비저닝 파이프라인은 면밀히 감시할 수 있습니다. 어떤 수준의 이탈이 리드의 주의를 보증하는지 사용자가 설정합니다.

여전히 사용자의 워크플로우입니다

리드 에이전트와 그 팀은 사용자의 승인 없이 정식 워크플로우 정의를 변경할 수 없습니다. 리드가 구조적 수정을 제안하면, 현재 실행을 완료하기 위해 수정을 적용하고 변경 사항을 제안으로 제출합니다. 사용자는 큐에서 이를 확인하고, 추론 근거를 보고, 승인 또는 거부합니다. 거부하면 해당 거부 이력이 기록되어 해당 워크플로우를 담당하는 모든 향후 리드가 같은 제안을 다시 하지 않습니다.

리드가 설정에 관계없이 절대 변경할 수 없는 것이 하나 있습니다: 자기 자신의 권한입니다. 워크플로우 정의에 있는 자가 복구 정책, 즉 일시 중지 여부, 재시도 기간, 승인 필요 여부는 소유자가 작성한 정책입니다. 리드는 작업 정의를 패치하고, API 호출을 업데이트하고, 파라미터를 조정하고, 새 플러그인을 작성할 수 있습니다. 하지만 자신의 행동을 관장하는 규칙은 변경할 수 없습니다. 이 경계는 하드코딩되어 있습니다. 자기 자신의 제안에 적용되는 승인 요건을 비활성화할 수 있는 에이전트는 전체 신뢰 모델을 무의미하게 만들 것입니다.

플러그인 변경은 Triggerfish에서 에이전트가 작성한 다른 모든 플러그인과 동일한 승인 경로를 따릅니다. 해당 플러그인이 깨진 워크플로우를 수정하기 위해 작성되었다는 사실이 특별한 신뢰를 부여하지 않습니다. 처음부터 새 통합을 구축해달라고 요청한 것과 동일한 검토 과정을 거칩니다.

이미 사용 중인 모든 채널에서 관리

워크플로우가 무엇을 하고 있는지 알기 위해 별도의 대시보드에 로그인할 필요가 없습니다. 자가 복구 알림은 Triggerfish가 사용자에게 도달하도록 설정한 모든 곳으로 전달됩니다: Slack의 개입 요약, Telegram의 승인 요청, 이메일의 에스컬레이션 보고서. 시스템이 모니터링 콘솔을 새로고침하지 않아도 긴급도에 맞는 채널로 사용자에게 찾아옵니다.

워크플로우 상태 모델은 이를 위해 설계되었습니다. 상태는 단순한 문자열이 아니라, 알림이 의미 있으려면 필요한 모든 것을 담은 구조화된 객체입니다: 현재 상태, 건강 신호, 승인 큐에 패치가 있는지 여부, 마지막 실행 결과, 리드가 현재 무엇을 하고 있는지. Slack 메시지 하나로 "접근 권한 프로비저닝 워크플로우가 일시 중지됨, 리드가 플러그인 수정을 작성 중, 승인이 필요함"이라고 전달할 수 있으며, 맥락을 찾아 헤맬 필요가 없습니다.

전체 그림을 보고 싶을 때는 같은 구조화된 상태가 실시간 Tidepool 인터페이스에도 제공됩니다. 같은 데이터, 다른 표면입니다.

IT 팀에 실질적으로 달라지는 것

조직에서 매주 깨진 워크플로우를 수정하는 데 시간을 쏟는 사람들은 저숙련 업무를 하는 것이 아닙니다. 분산 시스템을 디버깅하고, API 변경 이력을 읽고, 어제까지 잘 돌아가던 워크플로우가 왜 오늘 실패하는지 역추적하고 있습니다. 그것은 가치 있는 판단력이며, 현재 그 판단력은 새로운 자동화를 구축하거나 더 어려운 문제를 해결하는 대신, 거의 전부 기존 자동화를 살려두는 데 소모되고 있습니다.

자가 복구 워크플로우는 그 판단력을 없애는 것이 아니라, 적용되는 시점을 전환합니다. 한밤중에 깨진 워크플로우를 급히 수리하는 대신, 아침에 제안된 수정을 검토하고 리드의 진단이 맞는지 판단합니다. 압박 속에서 패치를 작성하는 것이 아니라, 제안된 변경의 승인자가 됩니다.

이것이 Triggerfish가 기반으로 하는 노동 모델입니다: 에이전트가 처리할 수 있는 작업을 실행하는 것이 아니라, 에이전트의 작업을 검토하고 승인하는 사람. 자동화 적용 범위는 넓어지면서 유지보수 부담은 줄어들고, 시간의 75퍼센트를 유지보수에 쓰던 팀은 그 대부분을 실제로 인간의 판단이 필요한 일에 돌릴 수 있습니다.

오늘 출시

자가 복구 워크플로우는 오늘 Triggerfish 워크플로우 엔진의 선택적 기능으로 출시됩니다. 워크플로우별로 옵트인이며, 워크플로우 메타데이터 블록에서 설정합니다. 활성화하지 않으면 워크플로우 실행 방식에 아무런 변화가 없습니다.

이것이 중요한 이유는 어려운 기술적 문제이기 때문만이 아닙니다(물론 어렵지만). 기업 자동화를 필요 이상으로 비싸고 고통스럽게 만들어온 근본 원인에 직접 대응하기 때문입니다. 워크플로우 유지보수 팀이야말로 AI 자동화가 대체해야 할 첫 번째 업무입니다. 이것이 이 기술의 올바른 용도이며, Triggerfish가 구축한 것입니다.

작동 방식을 자세히 알고 싶다면 전체 스펙이 저장소에 있습니다. 직접 시도해보고 싶다면 workflow-builder 스킬이 첫 번째 자가 복구 워크플로우 작성을 안내해 줄 것입니다.