AI 워크플로우는 폼 제출(Form Submit) 이후에 시작되어야 합니다
요약
효율적인 AI 워크플로우는 빈 프롬프트가 아닌 구조화된 데이터(폼 제출)를 트리거로 시작해야 합니다. AI의 제안과 실제 운영 상태를 분리하고, 상태 머신을 통해 인간의 개입과 거절 경로를 포함하는 안전한 설계가 필요합니다.
핵심 포인트
- 구조화된 폼 데이터는 모델에 풍부한 컨텍스트를 제공함
- AI의 제안(Suggestion)과 운영 상태(State)를 엄격히 분리할 것
- 작은 상태 머신을 도입하여 워크플로우의 흐름을 관리할 것
- 모델의 확신도(Confidence)를 자동 실행의 허가로 간주하지 말 것
많은 AI 워크플로우 데모는 프롬프트(Prompt)로 시작합니다.
저는 많은 프로덕션(Production) AI 워크플로우가 제출된 폼(Form)과 함께 시작되어야 한다고 생각합니다.
폼이 흥미롭기 때문이 아닙니다.
폼은 이미 구조(Structure)를 포함하고 있기 때문입니다.
name
email
company
...
이러한 구조는 모델이 메시지를 읽기 전에 AI 워크플로우에 컨텍스트(Context)를 제공합니다.
실수는 제출 이벤트(Submit event)를 워크플로우 전체로 취급하는 것입니다.
제출 이벤트는 단지 첫 번째 이벤트일 뿐입니다.
폼 제출은 빈 프롬프트보다 더 나은 트리거(Trigger)입니다
빈 프롬프트는 모델에게 모든 것을 추론하도록 요청합니다.
폼 제출은 워크플로우에 레코드(Record)를 제공합니다.
{
"response_id": "res_001",
"source_form": "contact",
...
AI 단계는 요약(Summarize), 분류(Classify) 및 다음 작업(Next action)을 제안할 수 있습니다.
{
"summary": "Pricing and launch-timeline inquiry.",
"priority": "high",
...
이것은 유용합니다.
하지만 이것이 아직 워크플로우는 아닙니다.
워크플로우에는 상태(State)가 필요합니다
레코드는 단순히 모델의 출력값만이 아닌 운영 필드(Operating fields)를 유지해야 합니다.
status
owner
next_action
...
저는 AI의 제안(Suggestions)과 운영 상태(Operational state)를 분리하는 것을 선호합니다:
owner_candidate != owner
suggested_category != final_category
reply_draft != sent_reply
...
AI는 제안할 수 있습니다.
하지만 상태 전환(State transition)은 제품이나 사람 운영자가 여전히 소유해야 합니다.
작은 상태 머신(State Machine)이면 충분합니다
첫 번째 버전부터 거대한 워크플로우 엔진(Workflow engine)이 필요하지는 않습니다.
다음 정도면 대개 충분합니다:
submitted
-> summarized
-> triaged
...
그리고 거절 경로(Rejection path)도 필요합니다:
waiting_human -> rejected -> needs_revision
waiting_human은 실패 상태가 아닙니다.
이는 다른 사람, 다른 시스템, 또는 신뢰할 수 있는 정보원(Source of truth)에 영향을 미치는 작업들을 위한 안전한 경로입니다.
AI가 먼저 안전하게 할 수 있는 일
리스크가 낮은 보조 작업부터 시작하세요:
| 단계 | AI가 도울 수 있는 부분 | 통제된 상태로 유지할 부분 |
|---|---|---|
| 분류 (Classification) | 의도 (Intent), 긴급도 (Urgency), 영업 제안 가능성 (Sales-pitch likelihood) | 최종 라벨 (Final labels) 및 제외 사항 (Exclusions) |
| ... |
가장 안전한 첫 번째 자동화는 대개 내부적인 작업입니다.
진전이 없는 응답들을 찾아내세요.
그것들을 요약하세요.
가능성이 높은 담당자에게 알림을 보냅니다.
사람이 외부 액션(External Action)을 확인하도록 합니다.
확신(Confidence)이 허가(Permission)가 되게 하지 마세요
모델의 확신(Model confidence)은 허가가 아닙니다.
이는 흔히 빠지는 함정입니다:
if confidence > 0.9:
send_reply()
이것은 안전한 워크플로우 경계(Workflow boundary)가 아닙니다.
확신이 높은 모델이라도 계약 조건, 환불, 채용 맥락, 개인정보 보호 규칙 또는 고객별 세부 사항을 놓칠 수 있습니다.
확신(Confidence)은 검토 우선순위(Review priority)를 정하는 데 사용하세요.
승인(Approval) 용도로 사용하지 마세요.
실무적인 패턴
제가 구축할 첫 번째 프로덕션 패턴은 다음과 같습니다:
1. 제출된 응답을 저장합니다.
2. 일반적인 확인 메시지를 보냅니다.
3. AI에게 요약(Summary), 카테고리(Category), 우선순위(Priority), 담당자 후보(Owner_candidate)를 요청합니다.
...
이렇게 하면 AI가 전체 운영을 책임지는 것처럼 가장하지 않으면서도 AI 워크플로우를 구축할 수 있습니다.
FORMLOVA를 구축하면서 제가 계속해서 되새기는 제품의 경계는 다음과 같습니다:
폼 제출(Form submission)은 결승선이 아닙니다. 그것은 운영 워크플로우(Operational workflow)의 첫 번째 이벤트입니다.
더 심도 있는 제출 후 워크플로우(Post-submit workflow) 모델은 여기에서 확인할 수 있습니다:
Post-Submit Workflow: What Should Happen After a Form Submission
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기