프롬프트가 아닌 상태 기계로 판매 알림을 모델링하기

Tej Pandya (GrowEasy.ai 설립자)

알림 에이전트는 자신이 무엇을 빚지고 있는지 저장할 장소가 필요합니다. 기록이 대화 내용에만 의존한다면, 개발자는 어떤 행동이 계획되었는지, 시도되었는지, 아니면 완료되었는지 신뢰성 있게 알 수 없습니다.

이 예시는 약속 기반의 판매 워크플로우를 위한 디자인 스케치입니다. 배포된 고객 결과나 GrowEasy.ai 기능 주장이 아닙니다.

예약 상태를 메시지 텍스트와 분리하여 유지하기

예약 수정 사항, 확정 시간, 동의 상태, 연락 경로 및 알림 상태를 저장해야 합니다. 예약 변경은 이전 수정 사항에 연결된 보류 중인 작업을 무효화해야 합니다.

모델은 메시지에서 제안된 시간을 추출할 수 있습니다. 애플리케이션 로직이 이를 검증한 후에 기록을 업데이트합니다. 알려지지 않은 동의는 그대로 알려지지 않은 상태로 유지되며, 모델의 신뢰도에 의해 채워지지 않습니다.

예시적인 전환 스케치:

requested -> confirmed -> reminder_eligible -> attempted
attempted -> delivered | retryable_error | permanent_error
retryable_error -> reconciled | retry_pending | needs_human
...

이러한 상태들은 보편적인 표준이 아닙니다. 실제 작업과 제공업체의 실제 영수증을 중심으로 선택해야 합니다. "delivered"를 "attended"로 해석해서는 안 됩니다.

재시도 전에 모호한 도구 결과를 조정하기

요청이 시간 초과되면 이미 성공했을 수 있습니다. 부작용(side effect)을 반복하기 전에 제공업체 결과를 조회하거나 지원되는 idempotency key를 재사용해야 합니다.

키는 예약 수정 사항과 알림 유형을 식별할 수 있어야 합니다. 구매자가 예약을 변경했다고 해서 진정으로 새로운 알림이 발생하는 것을 억제해서는 안 됩니다.

Temporal의 문서는 재시도 동작이 실행을 반복할 수 있기 때문에 idempotent Activities를 권장합니다. Durable state와 안전한 side effects는 서로 다른 문제를 해결하므로, 둘 다 필요합니다.

효과(effect) 직전에 적격성 검사 배치하기

알림을 보내기 전에 현재 예약 상태, 동의 여부, 허용 시간 및 목적지를 재확인해야 합니다. 큐에 들어갔을 때 적격했던 작업이 실행될 때는 더 이상 적격하지 않을 수 있습니다.

거절(refusal)과 철회된 동의(revoked consent)를 중지 조건(stop conditions)으로 간주하세요. 일시적인 전송 오류(temporary transport errors)와 영구적인 장애(permanent failures)를 구분해야 합니다. 재시도 예산(retry budget)은 모델이 무한정 임의로 처리할 영역이 아니라 애플리케이션 레벨의 결정입니다.

인간 개입을 위한 실제 라이프사이클 제공하기

예외 기록(exception record)에는 질문, 현재 증거(current evidence), 요청 시간 및 소유자(owner)가 필요합니다. 할당(Assignment)이 곧 수락(acceptance)을 의미하지는 않습니다. 기한이 지났으나 아직 수락되지 않은 작업은 팀원들에게 계속 보이도록 유지되어야 합니다.

애플리케이션이 단순히 알림(notification)만 발생시켰다고 해서 구매자에게 콜백(callback)이 확정되었다고 말해서는 안 됩니다. 책임 있는 사람이 존재하고 유효한 시간이 있다는 것을 증명하는 상태(state)가 있을 때에만 그 문장을 게이트(gate)해야 합니다.

변경된 상태와 반복 실행 테스트하기

큐잉 후 취소, 중복 웹훅 전송(duplicate webhook delivery), 동일 작업을 주장하는 두 워커(two workers), 제공업체 성공 이후 응답 손실, 사용 불가능한 소유자 및 사람에 대한 명시적 요청 등 다양한 상황을 테스트해야 합니다.

단순히 에이전트의 문구뿐만 아니라 결과 기록과 외부 동작(external actions)도 확인하세요. 이 설계를 더 간단하고 결정론적인 기준선(deterministic baseline)과 비교해 보세요. Anthropic의 워크플로우 가이드라인은 여기서 유용합니다: 모든 예측 가능한 단계를 자율적 결정으로 바꾸기보다는, 필요한 곳에 모델 기반의 유연성(model-driven flexibility)을 추가하는 것이 좋습니다.

깨끗한 상태 기계(state machine)가 나쁜 규칙을 고칠 수는 없습니다. 하지만 그 규칙과 실패를 테스트할 수 있을 만큼 충분히 가시적으로 만들 수는 있습니다.

출처:
https://www.anthropic.com/engineering/building-effective-agents
https://docs.temporal.io/activity-definition
https://temporal.io/blog/idempotency-and-durable-execution