판단을 포함한 크로스 시스템 오케스트레이션

일반적인 구매-지불 워크플로는 수십 개의 시스템을 거칩니다. 구매 요청은 한 플랫폼에서 시작되어 다른 시스템의 승인 체인으로 라우팅되고, 세 번째에서 벤더 조회가 시작되고, 네 번째에서 발주서가 생성되고, 다섯 번째에서 입고 프로세스가 시작되고, 여섯 번째에서 청구서 매칭이 이루어지고, 일곱 번째에서 지불이 스케줄되고, 여덟 번째에 모든 것이 기록됩니다. 각 시스템에는 고유한 API, 고유한 업데이트 스케줄, 고유한 인증 모델, 고유한 장애 모드가 있습니다.

기존 자동화는 경직된 파이프라인으로 이를 처리합니다. 1단계가 API A를 호출하고 응답을 파싱하여 필드를 2단계에 전달하고, 2단계가 API B를 호출합니다. 작동하는 동안에는 작동합니다. 벤더 레코드의 형식이 예상과 약간 다릅니다. 승인이 파이프라인이 설계되지 않은 상태 코드로 돌아옵니다. API 업데이트에서 새로운 필수 필드가 나타납니다. 하나의 깨진 단계가 전체 체인을 망가뜨리고, 며칠 후 다운스트림 프로세스가 실패할 때까지 아무도 모릅니다.

더 깊은 문제는 기술적 취약성이 아닙니다. 실제 비즈니스 프로세스에는 판단이 필요하다는 것입니다. 이 청구서 불일치를 에스컬레이션해야 하는가, 자동 처리해야 하는가? 이 벤더의 납기 지연 패턴이 계약 재검토를 정당화하는가? 이 승인 요청이 표준 라우팅을 건너뛸 만큼 긴급한가? 이러한 결정들은 현재 사람들의 머릿속에 있습니다. 즉, 자동화는 해피 패스만 처리할 수 있습니다.

Triggerfish의 해결 방법

Triggerfish의 워크플로 엔진은 단일 파이프라인에서 결정론적 자동화와 AI 추론을 혼합한 YAML 기반 워크플로 정의를 실행합니다. 워크플로의 모든 단계는 Triggerfish의 모든 작업을 관장하는 동일한 보안 적용 레이어를 통과하므로, 분류 추적과 감사 추적은 관련된 시스템 수에 관계없이 전체 체인에 걸쳐 유지됩니다.

결정론적 작업을 위한 결정론적 단계

워크플로 단계의 입력과 출력이 알려진 경우, 표준 HTTP 호출, 셸 명령, 또는 MCP 도구 호출로 실행됩니다. LLM 개입 없음, 레이턴시 페널티 없음, 추론 비용 없음. 워크플로 엔진은 REST API용 call: http, 연결된 MCP 서버용 call: triggerfish:mcp, 커맨드라인 도구용 run: shell을 지원합니다. 예측 가능한 작업에는 기존 자동화가 올바른 접근 방식이므로, 이 단계들은 기존 자동화처럼 정확하게 실행됩니다.

판단이 필요한 순간의 LLM 서브에이전트

워크플로 단계가 상황적 추론을 필요로 할 때, 엔진은 call: triggerfish:llm을 사용하여 실제 LLM 서브에이전트 세션을 생성합니다. 이는 단일 프롬프트/응답이 아닙니다. 서브에이전트는 Triggerfish에 등록된 모든 도구—웹 검색, 메모리, 브라우저 자동화, 모든 연결된 통합—에 접근할 수 있습니다. 문서를 읽고, 데이터베이스를 쿼리하고, 레코드를 비교하고, 발견한 모든 것을 기반으로 결정을 내릴 수 있습니다.

서브에이전트의 출력은 워크플로의 다음 단계로 직접 피드됩니다. 추론 중에 기밀 데이터에 접근했다면, 세션 taint는 자동으로 에스컬레이션되어 부모 워크플로로 전파됩니다. 워크플로 엔진이 이를 추적합니다. PUBLIC으로 시작했지만 판단 호출 중에 CONFIDENTIAL 데이터를 건드린 워크플로는 전체 실행 이력이 CONFIDENTIAL 레벨로 저장됩니다. 더 낮은 분류의 세션은 그 워크플로가 실행되었다는 사실조차 볼 수 없습니다.

실제 컨텍스트 기반의 조건 분기

워크플로 DSL은 조건 라우팅을 위한 switch 블록, 배치 처리를 위한 for 루프, 워크플로 상태 업데이트를 위한 set 작업을 지원합니다. 복잡한 조건을 평가할 수 있는 LLM 서브에이전트 단계와 결합하면, 워크플로는 단순 필드 값이 아닌 실제 비즈니스 컨텍스트를 기반으로 분기할 수 있습니다.

구매 워크플로는 서브에이전트의 벤더 리스크 평가에 따라 다르게 라우팅할 수 있습니다. 온보딩 워크플로는 특정 역할과 무관한 단계를 건너뛸 수 있습니다. 인시던트 대응 워크플로는 서브에이전트의 근본 원인 분석에 따라 다른 팀에 에스컬레이션할 수 있습니다. 분기 로직은 워크플로 정의에 있지만, 결정 입력은 AI 추론에서 옵니다.

시스템 변경 시의 자가 치유

API가 응답 형식을 변경하거나 시스템이 예상치 못한 오류를 반환하여 결정론적 단계가 실패하면, 워크플로는 단순히 멈추지 않습니다. 엔진은 실패한 단계를 LLM 서브에이전트에 위임할 수 있습니다. 서브에이전트는 오류를 읽고, 응답을 검사하고, 대안적인 접근 방식을 시도합니다. 새로운 필수 필드가 추가된 API는 오류 메시지를 읽고 요청을 조정하는 서브에이전트가 처리합니다. 인증 흐름이 변경된 시스템은 브라우저 자동화 도구로 탐색됩니다.

모든 실패가 마법처럼 해결된다는 의미는 아닙니다. 하지만 워크플로가 조용히 실패하는 대신 graceful하게 저하된다는 의미입니다. 서브에이전트는 앞으로 나아갈 길을 찾거나, 아무도 확인하지 않는 로그 파일에 묻힌 불가사의한 오류 코드 대신 무엇이 변경되었고 왜 수동 개입이 필요한지를 명확하게 설명합니다.

전체 체인에 걸친 보안

Triggerfish 워크플로의 모든 단계는 직접 도구 호출과 동일한 정책 적용 훅을 통과합니다. PRE_TOOL_CALL은 실행 전에 권한을 검증하고 속도 제한을 확인합니다. POST_TOOL_RESPONSE는 반환된 데이터를 분류하고 세션 taint를 업데이트합니다. PRE_OUTPUT은 분류 레벨이 대상의 허용 수준보다 높은 데이터가 시스템을 떠나지 않도록 보장합니다.

이는 CRM(CONFIDENTIAL)에서 읽고, LLM으로 데이터를 처리하고, Slack에 요약을 보내는 워크플로가 기밀 세부 정보를 공개 채널에 실수로 누출하지 않음을 의미합니다. 쓰기 다운 방지 규칙은 데이터가 통과한 중간 단계 수에 관계없이 PRE_OUTPUT 훅에서 이를 잡아냅니다. 분류는 전체 워크플로를 통해 데이터와 함께 이동합니다.

워크플로 정의 자체에 classification_ceiling을 설정하여 워크플로가 지정된 레벨 이상의 데이터에 절대 접근하지 못하도록 방지할 수 있습니다. INTERNAL로 분류된 주간 요약 워크플로는 자격 증명을 가지고 있더라도 CONFIDENTIAL 데이터에 접근할 수 없습니다. 상한선은 코드로 적용되며, LLM이 프롬프트 지시를 따르기를 바라는 것에 의존하지 않습니다.

Cron 및 Webhook 트리거

워크플로는 누군가가 수동으로 시작할 필요가 없습니다. 스케줄러는 반복 워크플로를 위한 cron 기반 트리거와 이벤트 기반 실행을 위한 webhook 트리거를 지원합니다. 아침 브리핑 워크플로는 오전 7시에 실행됩니다. PR 리뷰 워크플로는 GitHub가 webhook을 보낼 때 실행됩니다. 청구서 처리 워크플로는 공유 드라이브에 새 파일이 나타날 때 트리거됩니다.

Webhook 이벤트에는 고유한 분류 레벨이 있습니다. 프라이빗 리포지토리용 GitHub webhook은 보안 설정의 도메인 분류 매핑에 따라 자동으로 CONFIDENTIAL로 분류됩니다. 워크플로는 그 분류를 상속하며 모든 다운스트림 적용이 적용됩니다.

실제 활용 사례

NetSuite, Coupa, DocuSign, Slack에 걸쳐 구매-지불을 운영하는 중견 기업이 전체 사이클을 처리하는 Triggerfish 워크플로를 정의합니다. 결정론적 단계는 발주서 생성, 승인 라우팅, 청구서 매칭을 위한 API 호출을 처리합니다. LLM 서브에이전트 단계는 예외를 처리합니다: PO 항목과 일치하지 않는 청구서, 예상치 못한 형식으로 문서를 제출한 벤더, 요청자 이력에 대한 컨텍스트가 필요한 승인 요청.

워크플로는 셀프 호스팅 Triggerfish 인스턴스에서 실행됩니다. 데이터는 회사 인프라 외부로 나가지 않습니다. 분류 시스템은 NetSuite의 재무 데이터가 CONFIDENTIAL로 유지되고 INTERNAL로 분류된 Slack 채널에 전송될 수 없음을 보장합니다. 감사 추적은 LLM 서브에이전트가 내린 모든 결정, 호출한 모든 도구, 접근한 모든 데이터를 규정 준수 검토를 위한 완전한 계보 추적과 함께 캡처합니다.

Coupa가 API를 업데이트하고 필드 이름을 변경하면, 워크플로의 결정론적 HTTP 단계가 실패합니다. 엔진은 오류를 읽고, 변경된 필드를 식별하고, 올바른 파라미터로 재시도하는 서브에이전트에 위임합니다. 워크플로는 인간 개입 없이 완료되고, 인시던트는 엔지니어가 새 형식을 처리하도록 워크플로 정의를 업데이트할 수 있도록 기록됩니다.