프로덕션 워크플로로의 AI/ML 추론 통합

대부분의 엔터프라이즈 AI 프로젝트는 데모에서 프로덕션으로의 전환 과정에서 사라집니다. 팀이 지원 티켓 분류, 법적 문서 요약, 마케팅 카피 생성에 GPT-4를 사용하는 개념 증명을 만듭니다. 데모는 작동합니다. 리더십이 흥분합니다. 그런 다음 프로젝트는 데모가 답할 필요가 없었던 질문들로 몇 달간 정체됩니다: 데이터는 어디서 오는가? 출력은 어디로 가는가? AI의 결정을 누가 승인하는가? 모델이 환각을 일으키면 어떻게 되는가? 무엇을 했는지 어떻게 감사하는가? 봐서는 안 되는 데이터에 접근하지 못하게 하려면 어떻게 하는가? 잘못된 곳에 민감한 정보를 보내지 못하게 하려면 어떻게 하는가?

이것들은 가상의 우려가 아닙니다. 엔터프라이즈 생성형 AI 파일럿의 95%가 재무적 성과를 내지 못하며, 그 이유는 기술이 작동하지 않기 때문이 아닙니다. 모델은 유능합니다. 실패는 배관에 있습니다: AI 추론을 프로덕션 시스템이 필요로 하는 보안 통제, 오류 처리, 감사 추적과 함께 실제로 작동해야 하는 비즈니스 워크플로에 안정적으로 통합하는 것.

전형적인 엔터프라이즈의 대응은 커스텀 통합 레이어를 구축하는 것입니다. 엔지니어링 팀이 AI 모델을 데이터 소스에 연결하고, 파이프라인을 구축하고, 인증을 추가하고, 로깅을 구현하고, 승인 워크플로를 만들고, 보안 검사를 추가하는 데 수개월을 보냅니다. 통합이 "프로덕션 준비 완료"가 될 때쯤, 원래 모델은 새로운 모델로 대체되고, 비즈니스 요구 사항은 변했고, 팀은 처음부터 다시 시작해야 합니다.

Triggerfish의 해결 방법

Triggerfish는 AI 추론을 워크플로 엔진의 일급 단계로 만들어 통합 격차를 제거합니다. 이 단계는 시스템의 다른 모든 작업에 적용되는 동일한 보안 적용, 감사 로깅, 분류 통제로 관리됩니다. Triggerfish 워크플로의 LLM 서브에이전트 단계는 후처리가 아닙니다. HTTP 호출이나 데이터베이스 쿼리와 동일한 정책 훅, 계보 추적, 쓰기 다운 방지를 가진 네이티브 작업입니다.

별도 시스템이 아닌 워크플로 단계로서의 AI

워크플로 DSL에서 LLM 추론 단계는 call: triggerfish:llm으로 정의됩니다. 작업 설명은 자연어로 서브에이전트에게 무엇을 해야 하는지 알려줍니다. 서브에이전트는 Triggerfish에 등록된 모든 도구에 접근할 수 있습니다. 웹 검색, MCP 도구를 통한 데이터베이스 쿼리, 문서 읽기, 웹사이트 탐색, 크로스 세션 메모리를 사용할 수 있습니다. 단계가 완료되면 출력이 워크플로의 다음 단계로 직접 피드됩니다.

이는 통합해야 할 별도의 "AI 시스템"이 없다는 것을 의미합니다. 추론은 워크플로 내부에서 이루어지며, 다른 모든 것과 동일한 자격 증명, 동일한 데이터 연결, 동일한 보안 적용을 사용합니다. 통합 레이어가 이미 존재하기 때문에 엔지니어링 팀은 커스텀 통합 레이어를 구축할 필요가 없습니다.

커스텀 엔지니어링이 필요 없는 보안

AI 워크플로를 프로덕션화하는 데 가장 시간이 많이 걸리는 부분은 AI가 아닙니다. 보안 및 규정 준수 작업입니다. 모델이 어떤 데이터를 볼 수 있는가? 출력은 어디로 보낼 수 있는가? 민감한 정보 누출을 어떻게 방지하는가? 감사를 위해 모든 것을 어떻게 기록하는가?

Triggerfish에서 이러한 질문들은 프로젝트별 엔지니어링이 아닌 플랫폼 아키텍처로 답변됩니다. 분류 시스템은 모든 경계에서 데이터 감도를 추적합니다. 모델이 분류된 데이터에 접근하면 세션 taint가 에스컬레이션됩니다. 쓰기 다운 방지는 세션의 taint 레벨 이하로 분류된 채널로의 출력 흐름을 차단합니다. 모든 도구 호출, 모든 데이터 접근, 모든 출력 결정이 완전한 계보와 함께 기록됩니다.

고객 레코드(CONFIDENTIAL)를 읽고 요약을 생성하는 AI 워크플로는 해당 요약을 공개 Slack 채널에 보낼 수 없습니다. 이것은 모델이 무시할 수 있는 프롬프트 지시로 적용되지 않습니다. 모델이 볼 수 없고, 수정할 수 없고, 우회할 수 없는 PRE_OUTPUT 훅의 결정론적 코드로 적용됩니다. 정책 훅은 LLM 레이어 아래에서 실행됩니다. LLM은 행동을 요청하고, 정책 레이어가 허용 여부를 결정합니다. 타임아웃은 거부와 같습니다. 모델에서 외부 세계로의 경로 중 적용을 통과하지 않는 것은 없습니다.

처음부터 존재하는 감사 추적

Triggerfish 워크플로의 모든 AI 결정은 자동으로 계보 레코드를 생성합니다. 계보는 모델이 접근한 데이터, 운반한 분류 레벨, 적용된 변환, 출력이 전송된 위치를 추적합니다. 이것은 활성화하거나 구성해야 하는 로깅 기능이 아닙니다. 플랫폼의 구조적 특성입니다. 모든 데이터 요소는 생성에서 모든 변환을 거쳐 최종 목적지까지 출처 메타데이터를 운반합니다.

규제 산업에 있어, 이는 AI 워크플로의 규정 준수 증거가 첫날부터 존재한다는 것을 의미합니다. 감사자는 AI가 생성한 출력을 완전한 체인을 통해 추적할 수 있습니다: 어떤 모델이 생성했는지, 어떤 데이터를 기반으로 했는지, 추론 중에 모델이 사용한 도구, 각 단계에서 적용된 분류 레벨, 정책 적용 행동이 발생했는지 여부. 이 증거 수집은 보고 레이어로 후처리된 것이 아닌 적용 훅에 내장되어 있기 때문에 자동으로 이루어집니다.

재아키텍처 없는 모델 유연성

Triggerfish는 LlmProvider 인터페이스를 통해 여러 LLM 제공업체를 지원합니다: Anthropic, OpenAI, Google, Ollama를 통한 로컬 모델, OpenRouter를 통한 라우팅된 모델. 제공업체 선택은 에이전트별로 구성 가능하며 자동 장애 조치가 있습니다. 더 나은 모델이 사용 가능해지거나 제공업체가 가격을 변경하면, 전환은 워크플로 정의를 건드리지 않고 구성 레벨에서 이루어집니다.

이것은 "프로젝트가 출시되기 전에 구식이 된다" 문제를 직접 해결합니다. 워크플로 정의는 AI가 무엇을 해야 하는지를 설명하며, 어떤 모델이 하는지는 설명하지 않습니다. GPT-4에서 Claude로, 또는 파인튜닝된 로컬 모델로 전환하면 구성 값 하나가 변경됩니다. 워크플로, 보안 통제, 감사 추적, 통합 포인트는 모두 정확히 동일하게 유지됩니다.

Cron, Webhook, 이벤트 기반 실행

일정에 따라 또는 이벤트에 대응하여 실행되는 AI 워크플로는 인간이 프롬프트를 입력할 필요가 없습니다. 스케줄러는 반복 워크플로를 위한 5-필드 cron 표현식과 이벤트 기반 트리거를 위한 webhook 엔드포인트를 지원합니다. 일일 보고서 생성 워크플로는 오전 6시에 실행됩니다. 문서 분류 워크플로는 webhook을 통해 새 파일이 도착하면 실행됩니다. 감성 분석 워크플로는 새로운 지원 티켓마다 트리거됩니다.

각 예약된 또는 이벤트 트리거된 실행은 새로운 taint로 격리된 세션을 생성합니다. 워크플로는 인터랙티브 세션과 독립된 고유한 보안 컨텍스트에서 실행됩니다. cron 트리거 워크플로가 CONFIDENTIAL 데이터에 접근하면, 그 실행의 이력만 CONFIDENTIAL로 분류됩니다. PUBLIC 분류로 실행되는 다른 예약 워크플로는 영향을 받지 않습니다.

오류 처리 및 Human-in-the-Loop

프로덕션 AI 워크플로는 실패를 gracefully하게 처리해야 합니다. 워크플로 DSL은 명시적 오류 조건을 위한 raise와 태스크 정의에서의 오류 처리를 통한 try/catch 의미론을 지원합니다. LLM 서브에이전트가 낮은 신뢰도의 출력을 생성하거나 처리할 수 없는 상황을 만나면, 워크플로는 인간 승인 대기열로 라우팅하고, 알림 서비스를 통해 알림을 보내고, 대안 행동을 취할 수 있습니다.

알림 서비스는 우선순위와 중복 제거를 통해 연결된 모든 채널에 알림을 전달합니다. AI가 생성한 계약 수정이 전송되기 전에 인간 승인이 필요하면, 승인 요청이 승인자가 있는 Slack, WhatsApp, 이메일, 어디든지에 도착할 수 있습니다. 워크플로는 승인이 올 때까지 일시 중지했다가 중단한 곳에서 계속합니다.

실제 활용 사례

법무 부서가 계약 검토를 자동화하려 합니다. 전통적인 접근 방식: 업로드된 계약에서 조항을 추출하고, 위험 수준을 분류하고, 비표준 조항에 플래그를 달고, 검토 변호사를 위한 요약을 생성하는 파이프라인을 구축하는 6개월의 커스텀 개발. 프로젝트는 전담 엔지니어링 팀, 커스텀 보안 검토, 규정 준수 승인, 지속적인 유지보수가 필요합니다.

Triggerfish로 워크플로 정의 작성에 하루가 걸립니다. 업로드가 webhook을 트리거합니다. LLM 서브에이전트가 계약을 읽고, 핵심 조항을 추출하고, 위험 수준을 분류하고, 비표준 조항을 식별합니다. 검증 단계가 메모리에 저장된 사무소의 조항 라이브러리와 추출을 대조합니다. 요약은 담당 변호사의 알림 채널로 라우팅됩니다. 계약에는 고객 특권 정보가 포함되어 있어 전체 파이프라인이 RESTRICTED 분류로 실행되고, 쓰기 다운 방지는 계약 데이터가 RESTRICTED 이하의 채널로 누출되지 않도록 보장합니다.

사무소가 LLM 제공업체를 전환할 때(새 모델이 법률 언어를 더 잘 처리하기 때문에, 또는 현재 제공업체가 가격을 올렸기 때문에), 변경은 구성의 한 줄입니다. 워크플로 정의, 보안 통제, 감사 추적, 알림 라우팅은 모두 수정 없이 계속 작동합니다. 사무소가 리스크 프레임워크에 새로운 조항 유형을 추가하면, LLM 서브에이전트는 패턴이 아닌 의미를 읽기 때문에 추출 규칙을 다시 작성하지 않고도 처리합니다.

규정 준수 팀은 첫날부터 완전한 감사 추적을 얻습니다. 처리된 모든 계약, 추출된 모든 조항, 할당된 모든 위험 분류, 전송된 모든 알림, 기록된 모든 변호사 승인이 소스 문서로의 완전한 계보와 함께 기록됩니다. 수 주의 커스텀 보고 작업이 필요했던 증거 수집이 플랫폼의 구조적 특성으로 자동으로 존재합니다.