AI 워크플로우를 설계할 때, 가장 먼저 결정해야 할 것은 "AI에게 무엇을 시킬 것인가"가 아니라, "AI에게 무엇을 시키지 않을 것인가"입니다.

이 부분을 모호하게 둔 채 진행하면, 편리한 데모는 만들 수 있습니다.

하지만 운영 단계에 들어가는 순간 두려워집니다.

AI가 분류했다면, 자동으로 담당자를 변경해도 되는가
AI가 답장 문구를 작성했다면, 그대로 전송해도 되는가
AI가 불필요하다고 판단한 문의를, 제외해도 되는가
...

이 질문에 답하지 않은 채 "AI 워크플로우"라고 부른다면, 구현은 진행될지언정 책임 경계는 남지 않습니다.

AI 워크플로우는 AI가 전부 실행하는 메커니즘이 아닙니다.

AI가 읽고, 분류하고, 후보를 내고, 상태에 연결한다. 그 바탕 위에서, 인간이 확정해야 할 조작을 명시하는 설계입니다.

조작을 4단계로 나누기

먼저, AI가 관여하는 조작을 하나로 묶어서 다루지 않는 것이 좋습니다.

같은 "자동화"라도 리스크는 완전히 다릅니다.

Level	조작	기본 방침
L0	읽기, 요약하기, 분류 후보 내기	자동 실행해도 됨
...	...	...

예를 들어 문의 대응이라면, 본문의 요약은 L0입니다.

담당자 후보 제시(candidate presentation)는 L1입니다.

담당자를 실제로 확정하는 것은 L2입니다.

고객에게 답장을 보내거나, CRM에 동기화하거나, 대상 외로 제외하는 것은 L3에 가깝습니다.

이렇게 분류를 먼저 설정해 두면, AI의 성능과는 별개로 안전한 구현 경계를 논의할 수 있습니다.

AI의 출력은 승인이 아니다

AI 워크플로우에서 혼동하기 쉬운 것이 제안과 승인입니다.

{
"summary": "요금 플랜 및 도입 시기에 관한 문의",
"priority": "high",
...
}

이 출력은 편리합니다.

하지만 이것은 승인이 아닙니다.

confidence가 높더라도, 외부로 전송해도 좋다는 허가는 되지 않습니다.

owner_candidate가 들어있더라도, 담당자가 확정된 것은 아닙니다.

reply_draft가 자연스럽더라도, 고객에게 전송된 상태는 아닙니다.

내부 데이터에서는 AI의 후보와 인간의 확정을 구분합니다.

owner_candidate
owner_final
suggested_category
...

후보와 확정을 같은 열(column)에 넣으면, 나중에 "AI가 말했을 뿐"인지 "사람이 결정한 것"인지 알 수 없게 됩니다.

상태 전이(State Transition)로 대기 상태를 표현하기

인간의 확인을 넣는다면, 상태(state)로 표현합니다.

단순한 플래그(flag)가 아니라, 워크플로우의 상태로 만듭니다.

received
-> summarized
-> triaged
...

되돌리기(rollback)도 필요합니다.

waiting_human
-> rejected
-> needs_revision
...

포인트는 waiting_human을 실패 상태로 만들지 않는 것입니다.

AI 워크플로우에서의 인간 확인은 속도를 늦추기 위한 예외가 아닙니다.

중요한 조작을 안전하게 진행하기 위한 정규 루트입니다.

알림은 상태가 아니다

Slack 알림이나 이메일 알림을 넣으면 자동화된 느낌이 납니다.

하지만 알림이 나간 것과 업무가 진행된 것은 별개입니다.

notification_state = sent
workflow_status = waiting_human

이 두 가지는 분리하는 것이 좋습니다.

알림이 전송되었더라도, 인간이 승인하지 않았다면 외부 전송은 하지 않습니다.

알림이 실패하더라도, AI의 요약 결과나 분류 후보는 남겨둡니다.

이렇게 해두면 알림의 성패와 업무 상태를 혼동하지 않습니다.

설정은 allow가 아니라 deny부터 시작하기

AI 워크플로우 설정을 만든다면, 허용 리스트(allow list)뿐만 아니라 금지 조작(deny list)을 명시합니다.

{
"ai_allowed_actions": [
"summarize",
...

처음부터 대량의 자동화를 허용할 필요는 없습니다.

작게 시작한다면 AI는 후보 생성까지만 하고, 인간이 확정하는 흐름으로도 충분합니다.

운영 로그가 쌓이면, 리스크가 낮은 내부 업데이트만 조건부로 자동화합니다.

폼(Form) 기점의 워크플로우로 생각하기

폼이나 문의를 기점으로 삼으면 AI 워크플로우의 경계를 생각하기 쉬워집니다.

입력 항목이 있기 때문입니다.

문의 유형
회사명
도입 시기
...

AI는 자유 기술(free text)뿐만 아니라 주변 항목도 보고 후보를 낼 수 있습니다.

도입 시기가 이번 달이므로 우선순위를 높임
문의 유형이 요금 관련이므로 영업 후보로 지정
동의가 없으므로 외부 공유를 중단
...

여기서 중요한 것은 AI가 판단 근거를 갖추도록 하는 것입니다.

판단 그 자체를 모두 확정 지을 필요는 없습니다.

최소 체크리스트

AI 워크플로우 (AI workflow)를 구현하기 전에 다음 항목을 확인합니다.

[ ] AI의 후보와 인간의 확정을 별도 필드로 분리했다
[ ] 외부 전송, 삭제, 공개, CRM 동기화를 인간 확인 단계로 설정했다
[ ] waiting_human 을 정규 상태 (regular state)로 보유했다
...

AI 워크플로우는 자동화를 늘린다고 해서 무조건 좋은 것은 아닙니다.

자동화하지 않을 작업을 먼저 결정할수록, 더 오래 사용할 수 있는 워크플로우가 됩니다.

폼 제출, 문의, 설문 응답과 같은 입력으로부터 AI 워크플로우를 구성하는 사고방식은 이곳에 정리해 두었습니다.

Discussion