AI 생성 단계 설계로 컨텍스트를 전달하고 실패에 대응하는 방법

창업자는 답변을 통합할 필요가 없어야 한다

저는 Launcherry의 제품 워크플로우를 제품은 알지만 어떻게 홍보해야 할지 결정해야 하는 창업자를 중심으로 설계했습니다. 포지셔닝이 오디언스를 형성하고, 오디언스가 메시지를 형성하며, 채널이 전달 가능한 결과물을 형성합니다. 만약 개별 AI 출력물들이 이러한 의존성을 무시한다면, 창업자는 답변들을 조정(reconcile)해야 합니다. 바로 이 통합 작업이 제가 워크플로우로 해결하고자 하는 문제입니다.

Launcherry는 제품 URL이나 간략한 설명(brief)에서 비즈니스 컨텍스트를 가져와 마케팅 분석 및 캠페인 준비에 활용함으로써 이 문제를 해결합니다. 저는 정의된 입력, 출력, 검사(checks)가 연결된 단계들로 AI 워크플로우 오케스트레이션을 설계했습니다. 목표는 창업자가 검토할 수 있는 캠페인이며, 이전 작업의 추론 과정과 제약 조건이 여전히 정보를 제공하는 형태입니다.

이 프로젝트에는 두 가지 워크플로우가 있습니다. 하나는 Launcherry 내부에서 제품 출력을 생성합니다. 다른 하나는 빌드 주변에서 AI 구현을 지시합니다. 이 글은 제품 워크플로우에 관한 것이며, 개발 하니스에서는 제가 변경하는 작업을 어떻게 구성했는지 설명합니다.

비즈니스 사실과 생성된 추천을 구분하기

저는 URL이나 간략한 설명을 가지고 제품 워크플로우를 시작합니다. 이 입력은 워크플로우에 추론할 비즈니스를 제공합니다. 또한 경계(boundary)를 설정합니다: 비즈니스에 대해 공급되거나 검색된 정보는 창업자가 다음에 무엇을 해야 할지에 대한 AI 추천과는 다른 상태를 가집니다.

저는 이 구분을 아키텍처 요구사항으로 취급합니다. 캠페인 준비에는 제품에 대한 관련 사실이 필요하며, 분석은 포지셔닝, 오디언스 또는 채널을 제안할 수 있습니다. 설득력 있는 초안(draft)은 스스로의 주장의 진실성을 확립할 수 없습니다. 사실 기반화(Fact grounding)는 초안을 생성하는 워크플로우와 그 주변의 검사 단계에 속해야 합니다.

일반적인 예를 들어보겠습니다. 한 분석이 서비스의 빠른 처리 속도를 강조할 것을 권장한다고 가정해 봅시다. 이 권장은 특정 배송 보증을 확립하는 것은 아닙니다. 나중에 작성되는 카피는 자신이 하는 모든 약속에 대한 근거를 필요로 합니다. 이것은 특정 Launcherry 고객이나 캠페인에 대한 주장이기보다는, 설명적인 의사 결정 경계선입니다.

제가 각 단계에서 던지는 질문은 다음 단계가 무엇을 '알고 있는 것'으로 간주할 수 있느냐 하는 것입니다. 이는 리서치와 라이팅 사이의 관계를 더 명확하게 만들고, 검토(review)가 근거 없는 추가 사항을 식별할 기반을 제공합니다.

각 생성 단계에 특정 책임 부여하기

현재 개발 구현에서는 사실 기반(fact grounding)과 제한적 수정(bounded repair)을 통해 생성이 단계적으로 이루어집니다. 비즈니스 분석은 캠페인 준비를 안내하고; 채널 요구사항은 결과물을 형성하며; 검사(checks)는 결과물이 진행될 수 있는지 여부를 결정합니다. 각 단계가 존재하는 이유는 특정한 작업을 수행해야 하기 때문입니다.

저는 이러한 단계별 책임을 활용하여 실패 지점을 찾습니다. 캠페인은 약한 관점, 부적절한 글쓰기 또는 불완전한 에셋 방향을 가질 수 있습니다. 전체 결과물을 하나의 구별되지 않은 답변으로 취급하면, 어디서 안내나 구현이 변경되어야 하는지 이해하기가 더 어려워집니다. 명확한 단계별 책임은 조사를 더욱 집중적으로 만듭니다.

채널 스킬 라이브러리는 이러한 구조에 적합합니다. 이 가이드는 기획, 작성 및 에셋을 다루며, 채널 전반에 걸쳐 공유되는 표준을 가지고 있습니다. 각 단계는 생성 과정의 일부로 관련 전문 지식을 소비합니다. 채널별 자료는 단순히 옆에 문서로 남겨지는 것이 아니라 작업과 연결됩니다.

저는 단지 단계를 추가하는 것이 워크플로우를 개선한다고 가정하지 않습니다. 모든 핸드오프(handoff)는 컨텍스트가 이탈할 수 있는 가능한 지점을 추가하며, 모든 모델 호출은 운영 비용과 대기 시간에 기여합니다. 한 단계는 명확한 책임과 결과에 대한 증거를 통해 스스로 정당화되어야 합니다.

성공 경로와 함께 실패 경로 설계하기

워크플로우는 또한 출력이 요구사항을 충족하지 못할 때에 대한 응답이 필요합니다. Launcherry의 생성 구현에는 검사(checks)와 경계가 설정된 복구(bounded repair)가 포함되어 있습니다. 그 목적은 제품 요구사항을 온전히 유지하면서 제어된 프로세스 내에서 특정 실패를 수정하는 것입니다.

광고 문안 길이(Ad-copy length)는 유용한 예시를 제공합니다. 저는 플랫폼 제한을 충족시키기 위해 생성된 텍스트를 자르는 것을 거부했습니다. 그것은 완전한 생각을 기술적으로 허용 가능한 단편으로 바꿀 수 있습니다. 그래서 저는 워크플로우가 요구사항을 보존하면서 너무 긴 문안(overlong copy)을 처리할 수 있도록 생성 및 검증에 변경 사항을 지시했습니다.

저는 제약 조건과 의미 모두를 고려하여 복구를 평가합니다. 유용한 메시지를 잃어버린 더 짧은 응답은 제품 문제를 해결하지 못했습니다. 필드 제한을 여전히 초과하는 유창한 응답 역시 해결하지 못했습니다. 수용 결정은 이 두 가지에 대한 증거가 필요합니다.

다른 제품의 경우, 저는 초기 단계에서 중단 조건(stopping condition)을 설정할 것입니다. 어떤 실패를 복구할 수 있는지, 결과를 어떻게 평가할지, 그리고 복구가 허용 가능한 출력을 확립하지 못했을 때 무슨 일이 발생하는지를 말입니다. 이것이 설계 권장 사항입니다. 정확한 경로는 제품의 위험과 그 구현이 지원할 수 있는 동작에 맞아야 합니다.

창업자가 결정적인 결정을 내리게 하라

구현된 Launcherry 여정은 제품 입력, 분석, 캠페인 검토 및 내보내기(export)를 연결합니다. 승인은 캠페인을 내보내기 준비 상태로 만듭니다. 다운로드와 지원되는 플랫폼 배포는 별개의 선택 사항이며, Launcherry가 자동으로 유료 미디어(paid media)를 활성화할 수는 없습니다.

저는 생성 워크플로우에 명확한 목적지를 부여합니다: 창업자가 평가할 작업을 준비하는 것입니다. 성공적인 모델 응답이 배포를 승인하지는 않습니다. 기술적 검사를 통과한 캠페인이라도 그 메시지, 잠재 고객(audience), 의도가 비즈니스에 적합한지에 대한 결정이 여전히 필요합니다.

또한 가용성 조건도 고려합니다. 코드 내의 배송 모듈은 모든 창립자가 해당 공급자를 사용할 수 있다는 것을 확립하지 않습니다. 인터페이스와 서버 조건이 어떤 옵션이 사용 가능한지를 결정합니다. 사용자 여정과 이러한 차이점들은 배송 전 인간 승인 설계하기에서 설명합니다.

전체 워크플로우 측정 및 증거 범위 보존

저는 회귀 커버리지(regression coverage)와 실제 모델 평가를 사용하여 생성된 출력을 제품 요구 사항과 비교하여 평가합니다. 생산 비용, 지연 시간(latency), 캐싱은 별도의 관찰이 필요합니다. 평가 브릿지(evaluation bridge)는 프로덕션 공급자의 경제성이나 타이밍을 재현하지 않으면서도 실제 생성 파이프라인에 대한 반복 작업을 지원할 수 있습니다.

이 프로젝트의 경우, 새로운 기술과 워크플로우 개선은 로컬 개발에서 계속 진행되고 있습니다. 공개 제품과 현재 로컬 구현체는 관련되어 있지만, 상호 교환 가능한 증거는 아닙니다. 저는 워크플로우를 설명하고 무엇을 출시할 준비가 되었는지 결정할 때 이러한 구분을 유지합니다.

AI 워크플로우 아키텍처에 대한 저의 실질적인 출발점은 단일 사용자 결과입니다. 필요한 정보, 관련된 변환 과정, 핸드오프(handoff) 시점의 검사, 그리고 행동을 허가하는 결정을 추적합니다. 이것이 아키텍처에 단순히 도구를 연결하는 것 이상의 목적을 부여합니다. Launcherry 사례 연구는 제가 이 접근 방식을 작동하는 제품으로 어떻게 가져왔는지 보여줍니다.

원래 ivanped.ai에서 게시됨: AI 워크플로우 오케스트레이션: 분석부터 캠페인까지. 더 많은 작업 보기: [ivanped.ai]