폼 답변을 AI에게 전달하기 전에 status와 owner를 가져야 하는 이유

폼(Form) 답변을 AI에게 전달하면 요약이나 분류를 할 수 있습니다.

하지만 답변 본문만 전달하면 업무로 복귀시키기 어렵습니다.

이 답변은 미대응 상태인가
누가 확인해야 하는가
답장이 필요한가
...

AI는 본문을 읽을 수 있습니다.

하지만 현재의 업무 상태는 본문만으로는 알 수 없습니다.

폼 답변을 AI로 다룬다면, 본문을 전달하기 전에 status와 owner를 갖추는 것이 좋습니다.

message만으로는 부족하다

흔히 볼 수 있는 최소 데이터는 다음과 같습니다.

{
"id": "res_001",
"submitted_at": "2026-06-23T10:15:00+09:00",
...

AI에게 전달하면 요약 결과가 돌아옵니다.

{
"summary": "요금 플랜 및 이번 달 내 도입 가능 여부에 대한 상담",
"category": "pricing",
...

이것은 편리합니다.

하지만 이것만으로는 다음 할 일을 알 수 없습니다.

누가 대응하는가.

지금은 미대응 상태인가, 대응 중인가.

답장을 해도 되는가.

이미 누군가 확인했는가.

AI의 출력은 업무 상태를 대신할 수 없습니다.

AI에게 전달하기 전의 최소 컬럼

최소한 다음 컬럼들을 가지면 다루기 쉬워집니다.

response_id
submitted_at
source_form
...

status는 현재 상태입니다.

owner는 담당자 또는 담당 팀입니다.

source_form은 문의, 설문조사, 예약, 채용 응모 등의 입력원입니다.

followup_permission은 개별 연락을 해도 되는지에 대한 판단 재료입니다.

이 컬럼들이 있으면 AI에게 던지는 질문이 달라집니다.

미대응 문의만 요약해줘
owner가 설정되지 않은 고우선순위 답변을 추출해줘
저평가되었으면서 followup_permission이 true인 답변을 출력해줘
...

AI가 똑똑해진다기보다, AI에게 물어볼 수 있는 내용이 실무에 가까워집니다.

status는 AI 출력으로 덮어쓰지 않는다

AI에게 분류를 시키면 다음과 같은 출력을 만들고 싶어집니다.

{
"status": "done",
"reason": "답장이 불필요하다고 판단됨"
...

이것은 위험합니다.

AI가 "답장 불필요"라고 판단하더라도, 그것이 대응 완료를 의미하지는 않습니다.

status는 업무의 정본(正本)입니다.

AI의 판단 후보와는 분리해야 합니다.

status
ai_suggested_status
human_review_status

예를 들어, AI는 ai_suggested_status = excluded_candidate 정도까지만 수행합니다.

사람이 확인하고, 필요하다면 status = excluded로 변경합니다.

이러한 분리가 없으면 AI의 제안과 업무의 확정이 뒤섞이게 됩니다.

owner_candidate와 owner를 구분한다

담당자도 마찬가지입니다.

AI가 담당자 후보를 제시할 수는 있습니다.

{
"owner_candidate": "sales",
"reason": "요금 플랜 및 도입 시기에 관한 상담이기 때문"
...

하지만 이것은 owner가 아닙니다.

담당자 확정에는 휴가, 담당 범위, 고객 등급, 기존 상담, 사내 규칙 등이 얽혀 있습니다.

따라서 후보와 확정을 구분합니다.

owner_candidate
owner
owner_assigned_by
...

AI는 후보를 제시합니다.

사람 또는 명확한 규칙이 확정합니다.

이렇게 역할을 분담하면 AI의 출력을 안전하게 업무로 연결할 수 있습니다.

답변 데이터와 채팅하기 위한 전처리

답변 데이터와 채팅하는 가치는 AI에게 전부 읽히는 것이 아닙니다.

업무 상태를 가진 데이터에 대해 필요한 질문을 할 수 있다는 점에 있습니다.

이번 주, 미대응 상태로 남아 있는 문의는?
저평가되었으면서 아직 owner가 없는 답변은?
영업 메일을 제외한 문의 중 늘어나고 있는 테마는?
...

이러한 질문에는 본문뿐만 아니라 상태가 필요합니다.

AI 이전에 데이터 모델을 정비합니다.

최소 상태 전이

처음부터 상태를 너무 늘릴 필요는 없습니다.

new
triaged
assigned
...

이것만으로도 충분한 경우가 많습니다.

중요한 것은 알림(Notification)이나 AI 분류를 상태와 섞지 않는 것입니다.

notification_state = sent
ai_classification_status = done
status = new

Slack 알림(Notification)이 전송되었더라도, 아직 대응 전이라면 status = new입니다.

AI 분류가 완료되었더라도, 사람이 확인하지 않았다면 status = triaged나 assigned로 변경하지 않습니다.

체크리스트

[ ] response_id 가 있음
[ ] source_form 이 있음
[ ] status 가 있음
...

AI에게 전달하는 데이터는 깨끗한 본문만으로는 부족합니다.

상태(Status)와 담당자(Owner)가 있어야 AI의 요약이나 분류가 다음 작업으로 이어질 수 있습니다.

폼 답변을 AI로 요약 및 분류하여 문의, 예약, 채용, 이벤트, 설문조사의 다음 액션(Next Action)으로 전환하는 사고방식은 이곳에 정리되어 있습니다.

Discussion