AI용 Cloudflare Durable Objects: 상태와 복구

AI용 Cloudflare Durable Objects는 도우미가 세션이나 작업을 조정할 안정적인 장소를 필요로 할 때 유용합니다. 어려운 설계 질문은 그 상태가 무엇을 뜻하느냐입니다. 같은 도우미에 속한다는 이유만으로 대화 기록, 진행 중인 작업, 승인된 업무 변경을 같은 기록으로 만들어서는 안 됩니다.

Durable Objects로 명확히 식별한 앱 상태를 조정하되 대화 이력, 작업 상태, 외부 업무 결과를 구분하세요. 중단 뒤에는 저장 기록으로 작업을 재구성하고 재연결할 때 현재 권한을 확인하며 모델 맥락을 기준 상태와 분리해야 합니다. 영속 저장은 구성 요소이지 완전한 복구 정책이 아닙니다.

유지보수 도우미가 서비스 보고서를 준비한다고 생각해 보세요. 메모를 모으고 권고 초안을 만든 뒤 감독자를 기다립니다. 대기 중 브라우저가 끊길 수 있고 감독자는 다른 곳에서 작업을 열 수 있으며, 승인 전에 장비 원본 기록이 바뀔 수도 있습니다.

이 안내는 이런 상황의 상태 설계를 제안합니다. 모든 대화 메시지를 보관해야 한다거나 객체의 신원이 조직의 접근 경계와 자동으로 맞는다고 주장하지 않습니다.

AI용 Cloudflare Durable Objects에는 신원 모델이 필요합니다

Cloudflare는 Durable Objects 를 상태가 있는 애플리케이션을 조정하는 플랫폼으로 설명합니다. AI 기능에 객체를 할당하기 전에 대화, 수락된 작업, 공유 자원, 다른 제한된 단위 중 무엇을 나타내는지 정의하세요.

대화당 객체는 상호 작용에 편리할 수 있습니다. 하지만 서비스 보고서에는 대화 이후에도 남는 식별자가 필요할 수 있습니다. 여러 동료가 같은 보고서에 협력한다면 보고서를 첫 브라우저 세션에만 묶는 것은 나중의 접근과 인계를 혼란스럽게 만듭니다.

라우팅 식별자는 신뢰하는 애플리케이션 맥락으로 결정하세요. 다른 작업 번호를 추측한 호출자가 그 내용에 접근할 수 있어서는 안 됩니다. 객체 라우팅과 앱 인가는 서로 다른 책임입니다.

기준 사실을 대화 요약 밖에 유지하기

모델이 만든 요약은 도우미가 대화를 계속하는 데 도움이 됩니다. 그러나 감독자가 권고를 승인했다는 유일한 증거가 돼서는 안 됩니다. 승인 이벤트를 보고서 버전과 인증된 검토자에 연결해 저장하세요.

현재 작업 단계도 명시적으로 유지하세요. 검토 대기는 도우미가 예전 대화에서 기억하는 문장이 아니라 기록된 앱 상태여야 합니다. 대화록에 작업이 아마 끝났을 것처럼 보인다는 이유로 이후 모델 응답이 상태 전환을 만들어 내면 안 됩니다.

Cloudflare의 대화 상태와 메모리 안내 는 저장된 대화 이력과 모델에 제공하는 맥락을 구분합니다. 중요한 구현 차이입니다. 저장한 정보가 모두 다음 프롬프트에 들어갈 필요는 없습니다.

보고서의 경우 도우미는 간결한 작업 요약과 선택한 허용 증거를 받을 수 있습니다. 앱은 기준 원본과 이벤트 기록을 자체 접근 및 보관 규칙에 따라 별도로 유지할 수 있습니다.

오래된 결정을 거부하는 전환 설계하기

검토 가능한 보고서마다 버전을 부여하세요. 감독자의 승인은 그 버전을 식별해야 합니다. 검토 페이지를 연 뒤 새 메모가 들어오면 앱은 제안을 무효로 하는지 별도로 처리할 수 있는지 결정해야 합니다.

동작이 들어올 때 현재 작업 상태를 확인하세요. 오래된 브라우저 탭이 취소된 보고서를 승인하거나 반복 클릭이 두 번째 업무 작업을 만들면 안 됩니다. 이미 수락한 동작에는 확인된 결과를 반환하세요.

이것은 애플리케이션 규칙입니다. 상태 플랫폼은 구현할 장소를 제공하지만 바뀐 유지보수 메모가 상업적으로 중요한지, 어느 감독자에게 권한이 있는지 결정할 수는 없습니다.

프로세스 메모리 대신 기록으로 복구하기

메모리의 값은 임시 작업 상태로 취급하세요. 작업 재개와 이미 요청한 외부 작업 식별에 필요한 사실을 기록해야 합니다. 재시작 시 전체 대화를 모델에 다시 재생하지 않고 현재 단계를 재구성할 수 있어야 합니다.

유지보수 보고서에는 원본 버전, 초안 버전, 승인 상태, 목적지 작업 번호를 보관하세요. 목적지가 보고서를 수락했지만 응답이 사라졌다면 새로 생성한 설명보다 그 번호가 더 유용합니다.

한 번도 시작하지 않은 작업과 결과를 모르는 작업을 구분하세요. 명백하게 시작해도 안전한 것은 전자입니다. 후자는 다시 제출하기 전에 목적지를 검사하거나 목적지가 지원하는 중복 방지 장치를 사용해야 합니다.

의미 있는 단계 사이에서 앱을 중단해 복구를 시험하세요. 그런 다음 다른 엔지니어에게 저장 증거로 작업을 식별하고 다음 행동을 정하게 하세요. 정상 성공 경로 시연만으로는 드러나지 않는 상태 누락을 찾을 수 있습니다.

현재 권한으로 재연결하기

동료가 다시 연결하면 앱 세션 규칙에 따라 다시 인증하고 현재 작업 권한을 확인하세요. 예전 대화 식별자를 가지고 있다고 접근 권한이 영구히 유지된다고 가정하면 안 됩니다.

기록된 작업 상태와 관찰 시각을 읽으세요. 시스템이 대기 중인지, 처리 중인지, 실패했는지, 대조 대기인지 설명해야 합니다. 진행을 확립할 수 없다면 모델에 안심시키는 답을 만들게 하지 말고 불확실함을 보여 주세요.

유용한 기억과 만료시킬 정보 결정하기

대화 이력, 원본 문서, 운영 증거는 보관 요구가 다를 수 있습니다. 자동 메모리를 넣기 전에 요구를 정의하세요. 모든 입력을 영원히 보관하면 나중의 삭제와 접근 검토가 어려워집니다.

재사용할 선호와 작업 사실을 분리하세요. 선호하는 보고서 형식은 세션을 넘어 유용할 수 있습니다. 임시 접근 토큰이나 철회된 고객 정보는 도우미의 영구 기억이 돼서는 안 됩니다.

원본 기록을 삭제하거나 접근을 철회할 때는 원본뿐 아니라 파생 상태도 고려하세요. 요약에 같은 민감한 사실이 들어 있을 수 있습니다. 저장 초안, 검색 구절, 모델에 제공하는 맥락에 대한 정책이 필요합니다.

검색 중심 메모리는 당사의 RAG 데이터 최신성 안내 를 참고하세요. 인덱스 전체의 업데이트와 제거를 다룹니다. 벡터 검색 결과를 현재 작업 단계의 기준 진술로 취급해서는 안 됩니다.

실제 운영할 수 있는 상태 경계 선택하기

부하가 정당화하기 전에 모든 관심사를 별도 객체로 만들지 마세요. 경계가 너무 많으면 간단한 작업을 추적하기 어려워집니다. 반대로 모든 고객과 작업을 구별 없는 공유 상태에 넣으면 접근과 책임 문제가 생깁니다.

인증된 요청이 작업에 도달하는 방법, 어떤 기록이 기준인지, 어디서 외부 업무 효과가 발생하는지 보여 주는 다이어그램부터 시작하세요. 각 실패를 설명할 수 있는 구성 요소를 식별해야 합니다.

Cloudflare의 Agents 개요 는 더 넓은 런타임 맥락을 제공합니다. 선택한 버전에 맞는 문서화된 API를 사용하고, 실험적 인터페이스를 지원 약속에 포함하기 전에 시험하세요.

인수 집합에는 동시 검토자, 반복 동작, 원본 버전 변경, 재연결, 목적지 이용 불가가 포함돼야 합니다. 유용한 결과는 상태가 단순히 남는 것이 아니라 앱이 올바른 권한으로 올바른 일을 재개하는 것입니다.

상태 설계와 인계 작업 추정하기

구현 비용은 작업 전환, 협업, 원본 관계, 복구 요구에 달려 있습니다. 대화 저장소는 승인과 목적지 대조가 있는 작업 조정 시스템보다 훨씬 작은 범위입니다.

상태 책임, 접근 규칙, 보관 동작, 복구 시험을 명시한 GBP 제안을 요청하세요. 앱 코드가 달라질 때 저장 기록을 발전시키는 계획도 포함해야 합니다. 기존 작업이 배포 뒤 읽을 수 없게 되면 안 됩니다.

범위가 명확한 AI 통합 파일럿 으로 유용한 단일 작업에 이런 계약을 세울 수 있습니다. 작업 생명주기, 검토자, 연결 시스템을 포함해 상태형 도우미 제안 요청 을 보내 주세요. 대화록이 우연히 설계를 결정하게 하지 않고 실제 업무를 따라 저장 구조를 만들 수 있습니다.

자주 묻는 질문

AI 메모리는 영속 저장과 같은가요? 아닙니다. 영속 저장은 앱 정보를 보관하고 모델 맥락은 특정 추론에 제공하는 정보입니다. 어떤 저장 사실이 기준인지, 무엇을 선택하거나 요약해 도우미에게 줄지 결정하세요.

모든 대화에 별도 작업이 있어야 하나요? 업무 과정에 맞는 경우에만 그렇습니다. 한 대화가 여러 가능한 작업을 논의할 수 있고, 수락된 작업은 여러 대화에 걸쳐 계속될 수 있습니다. 수락된 일에는 시작한 화면을 넘어 유지되는 식별자를 주세요.

객체 식별자가 호출자의 데이터 소유를 증명하나요? 아닙니다. 상태를 반환하거나 동작을 수락하기 전에 인증된 신원과 현재 권한을 확인하세요. 추측하거나 재사용한 라우팅 번호가 접근을 넓혀서는 안 됩니다.

재시작 뒤 무엇을 남겨야 하나요? 작업 단계, 원본과 초안 버전, 승인, 외부 작업 번호를 확립하는 사실을 저장하세요. 임시 프로세스 메모리가 수락된 일의 유일한 증거여서는 안 됩니다.

대화 요약에 승인을 기록해도 되나요? 설명할 수는 있지만 기준 승인은 정확한 제안 버전에 연결된 인증된 앱 이벤트로 유지하세요. 모델이 만든 문장이 업무 변경 권한을 부여해서는 안 됩니다.

오래된 브라우저 동작은 어떻게 처리하나요? 현재 상태와 버전에 맞춰 검사하세요. 오래된 결정을 거부하거나 새로 보여 주고, 적절한 경우 이미 수락된 동작에는 기록된 결과를 반환하세요. 다시 클릭했다는 이유만으로 새 효과를 만들면 안 됩니다.

유용한 상태형 도우미 파일럿의 조건은 무엇인가요? 신원 경계, 동시 동작, 중단, 재연결, 목적지 결과 불확실을 보여 줘야 합니다. 다른 엔지니어가 모델에 과거를 재구성하라고 묻지 않고 저장 증거로 작업을 복구할 수 있어야 합니다.