신뢰할 수 있는 소셜 미디어 스케줄러는 에이전트의 의도(intent)를 승인된 전달 지침으로 변환한 다음, 제출 후 어떤 일이 발생했는지 확인합니다. 이 프로세스는 구체적입니다: 소스 리비전(source revision)을 고정하고, 승인을 기록하며, 목적지의 라이브 스키마(live schema)를 해결하고, 모든 미디어를 업로드하며, 정확한 타임스탬프(timestamp)와 시간대(timezone)를 선택하고, 스케줄을 제출한 다음, 제공업체의 최종 결과를 조정(reconcile)합니다.

"스케줄 수락됨(Schedule accepted)"과 "포스트 게시됨(post published)"은 서로 다른 상태입니다. API는 목적지 제공업체가 이를 처리하기 전에 작업을 수락할 수 있으므로, 에이전트는 각 이벤트에 대한 내구성 있는 증거가 필요합니다. 또한 타임아웃(timeout) 및 기타 모호한 결과에 대한 안전한 경로도 필요합니다. 아래의 아키텍처는 이러한 결정 사항들을 운영자 소유의 레코드(operator-owned records)에 유지합니다. 게시 통합(publishing integration)은 제공업체별 페이로드(payloads)에 대한 책임을 유지합니다.

아키텍처가 분리해야 하는 것들

AI 에이전트는 목표를 콘텐츠로 변환하고 작업을 선택할 수 있지만, 내구성 있는 스케줄링 상태(scheduling state)는 다른 곳에 존재해야 합니다. 프로덕션 설계에는 다섯 가지 관심사(concerns)를 분리해야 합니다:

1. 소스(Source) 및 승인(approval)은 게시가 허가된 정확한 콘텐츠 리비전을 식별합니다.
2. 기능 발견(Capability discovery)은 선택된 통합(integration)과 그 현재 설정 스키마를 식별합니다.
3. 시간 해결(Time resolution)은 운영자가 요청한 규칙을 시스템이 제출할 구체적인 시점과 연결합니다.
4. 제출(Submission)은 미디어 참조(media references), 목적지 설정, 그리고 스케줄링 호출의 결과를 기록합니다.
5. 조정(Reconciliation)은 제공업체가 게시했는지, 실패했는지, 또는 불확실한 상태로 남아 있는지에 대한 사후 증거를 포착합니다.

이러한 분리가 없다면, 에이전트는 콘텐츠를 재생성하고, 대략적인 시간을 기억하며, 요청을 제출한 뒤, 성공적인 응답을 받은 후 작업을 완료했다고 호출할 수 있습니다. 그렇게 되면 워크플로(workflow)는 어떤 리비전이 승인되었는지 또는 어떤 시간대가 적용되었는지 증명할 수 없습니다. 또한 제공업체가 최종적으로 포스트를 게시했는지에 대한 증거도 갖지 못하게 됩니다.

수명 주기의 나머지 부분에 대해서는 AI 에이전트의 초안 작성부터 검증된 전달까지의 소셜 미디어 게시 (AI agent social media publishing from draft to verified delivery)를 참조하십시오. 스케줄링 (Scheduling)은 하나의 단계일 뿐이며, 승인 (Approval)이나 검증 (Verification)을 대체하는 것이 아닙니다.

AI 에이전트를 위한 스케줄링 시퀀스 (A scheduling sequence for AI agents)

아래의 시퀀스는 구현 방식에 중립적입니다. "스케줄 레코드 (Schedule record)"는 운영자의 애플리케이션이 소유한 저장소를 의미합니다. 이 다이어그램은 Groniz 큐 (queue)의 내부 구조나 API 응답 스키마 (schema)를 설명하지 않습니다.

sequenceDiagram
    actor Operator
    participant Agent
...

요청된 스케줄에 따라 API와 제공업체 간의 교환 사이에 몇 분, 몇 시간 또는 그 이상의 시간이 경과할 수 있습니다. 레코드는 에이전트의 재시작 및 컨텍스트 (context) 손실 상황에서도 유지되어야 합니다. 대화 기록 (Conversation history)이 컨텍스트를 제공할 수는 있지만, 그것이 스케줄링 원장 (scheduling ledger)은 아닙니다.

스케줄을 확정하기 전에 수정본을 동결하십시오 (Freeze the revision before resolving the schedule)

승인은 "최신 초안"이 아닌 불변의 콘텐츠 (immutable content)를 가리켜야 합니다. 승인된 목적지 변체 (destination variants)와 함께 소스 수정 식별자 (source revision identifier) 또는 콘텐츠 다이제스트 (content digest)를 저장하십시오. 텍스트, 미디어 선택, 목적지 설정 또는 예정된 시간이 실질적으로 변경되는 경우, 새로운 수정본을 적용 가능한 승인 정책 (approval policy)에 따라 처리해야 합니다.

에이전트가 하나의 소스를 여러 네트워크에 맞게 조정할 때, 스케줄링 레코드는 각 통합 (integration)에 대해 승인된 변체를 식별해야 합니다. 하나의 보편적인 포스트 본문을 가정해서는 안 됩니다. 통합 게시 레이어 (unified publishing layer) 뒤에서도 제공업체의 기능은 여전히 다양합니다. 통합 소셜 미디어 API가 네이티브 API와 다른 점 (Where unified social media APIs differ from native APIs)에서는 왜 공유 경계에 제공업체를 인식하는 검증 (provider-aware validation)이 필요한지 설명합니다.

승인 증거는 간결할 수 있지만, 추적 가능해야 합니다. 누가 또는 무엇이 수정본을 승인했는지, 승인이 언제 발생했는지, 그리고 어떤 정책이나 워크플로 (workflow)가 해당 결정을 내렸는지를 기록하십시오. 전체 검토 대화 내용을 포함할 필요는 없습니다. 동결된 스케줄링 입력값이 권한을 부여받았는지 판단할 수 있을 만큼의 충분한 증거를 유지하십시오.

타이밍 의도를 구체적인 시점으로 변환 (Convert timing intent into a concrete instant)

"내일 아침", "다음 적절한 시간", "출시 이후"와 같은 표현은 실행 가능한 스케줄 값(schedule values)이 아닙니다. 제출하기 전에 타이밍 의도(timing intent)를 구체적인 타임스탬프(timestamp)로 변환하고, 시간대(timezone) 선택을 명시적으로 만드십시오.

기록에는 다음 두 가지 값을 모두 유지하십시오:

• 오프셋(offset)이 포함된 ISO 8601 타임스탬프 또는 그에 상응하는 UTC 값과 같은 절대적인 예약 시점(absolute scheduled instant);
• America/New_York와 같이 운영자의 로컬 의도를 해석하는 데 사용된 IANA 시간대(timezone).

절대적인 시점은 요청을 모호하지 않게 만듭니다. 지정된 시간대는 시스템이 로컬 시간을 어떻게 해석했는지 보여주며, 이는 나중에 일광 절약 시간제(daylight-saving) 전환 시점을 검토할 때 도움이 됩니다. 반복 규칙(recurring rule)의 경우, 한 번에 하나의 발생 건(occurrence)을 계산하고 제출 전에 결과 시점을 영구 저장(persist)하십시오. 발행 호출(publishing call) 단계에서 "매 평일 9시"와 같은 문구를 해석하도록 요청하지 마십시오.

Groniz의 공개 API는 다음 슬롯(next slot)을 찾는 작업을 문서화하고 있습니다. 이는 스케줄링 작업이지, 최적의 또는 가장 성과가 좋은 게시 시간을 찾아내겠다는 약속이 아닙니다. 만약 귀하의 정책이 다음 사용 가능한 슬롯을 사용한다면, 해당 작업의 구체적인 시간으로 작업 결과(operation's result)를 저장하십시오. 만약 정책이 캠페인 마감일이나 운영자가 선택한 시간을 사용한다면, 대신 그 선택을 보존하십시오.

라이브 통합(live integration)에 대한 검증

통합(integration) 단계에서는 연결된 대상 계정(destination account)을 식별합니다. 현재 설정 스키마(settings schema)는 스케줄링 호출에 필요한 구성을 정의합니다. 요청을 확정(freezing)하기 전에 이 두 가지를 모두 확인하십시오. 캐시된 범용 페이로드(universal payload)는 제공업체의 요구 사항과 달라질 수 있거나 계정 유형 간의 차이를 숨길 수 있기 때문입니다.

대상 변형(destination variant)을 선택한 후, 제출하기 전에 기능을 검증하십시오. 콘텐츠, 미디어 조합 및 대상별 설정을 라이브 스키마(live schema)와 대조하여 확인하십시오. 스케줄링(scheduling)을 지원하는 제공업체라 하더라도 서로 다른 필드를 요구하거나 서로 다른 미디어 규칙을 적용할 수 있습니다. Groniz는 32개 이상의 네트워크에 걸쳐 OAuth, 플랫폼별 포맷팅(formatting), 스케줄링 및 전송을 처리하지만, 이러한 공유 계층이 존재한다고 해서 제공업체의 기능이 동일해지는 것은 아닙니다.

미디어는 별도의 핸드오프(handoff)가 필요합니다. 각 에셋(asset)을 먼저 업로드한 다음, 업로드 단계에서 반환된 미디어 참조(media reference)를 저장하십시오. 로컬 파일 시스템 경로나 임의의 외부 URL은 업로드된 Groniz 참조를 대체할 수 없습니다. 멀티 플랫폼 미디어 업로드 워크플로우 (multi-platform media upload workflow)에서 프리플라이트(preflight) 및 참조 처리 방법을 자세히 다룹니다.

운영자 소유 스케줄 레코드 템플릿 (Operator-owned schedule record template)

이 YAML은 운영자 소유의 레코드 템플릿이며, Groniz API 요청 또는 응답 규약(contract)이 아닙니다. 필드 이름과 상태는 귀하의 애플리케이션에 속합니다. 현재의 공개 API 및 라이브 통합 스키마에 대한 제출 단계만 번역하십시오.

schedule_record:
  record_id: "sched_internal_..."

...

내부 record_id는 귀하의 시스템 내에서 레코드를 상호 참조합니다. 이를 제공업체의 멱등성 키(idempotency key)로 제시하지 마십시오. 여기에 문서화된 Groniz의 사실들은 멱등성 키, 정확히 한 번 전송(exactly-once delivery), 웹훅(webhooks), 자동 재시도(automatic retries) 또는 특정 데이터베이스 설계에 대한 지원을 확립하지 않습니다.

별개의 상태로서의 모델 제출 및 게시

모든 결과를 success 또는 failed로 축소하는 대신, 증거를 보존하는 운영자 상태 모델(operator state model)을 사용하십시오:

이것들은 애플리케이션 상태(application states)이며, Groniz의 상태 값(status values)을 주장하는 것이 아닙니다. 운영자가 문서화된 계약(contract)에 따라 통합(integration)이 반환한 내용을 검사할 수 있도록, 정규화된 상태와 함께 원래의 결과(original result)를 유지하십시오.

재시도 전 모호성 해소하기

제출 후 응답을 분실하거나 불완전하게 받는 것보다 명확한 거절(rejection)을 처리하는 것이 더 쉽습니다. 호출자(caller) 측에서 타임아웃이 발생했더라도 서버는 스케줄을 수락했을 수 있습니다. 즉각적인 반복 시도는 중복을 생성할 수 있습니다.

결과가 모호할 때:

1. 시도(attempt)를 동결하고 타임스탬프, 통합(integration), 소스 수정본(source revision), 예약 시간 및 미디어 참조를 유지합니다.
2. 지원되는 목록 조회(listing) 또는 검사(inspection) 작업을 사용하여 예약된 게시물의 증거를 찾습니다.
3. 강력한 식별자(strong identifiers) 또는 목적지, 수정본 유래 콘텐츠, 미디어 및 예약 시간의 충분히 엄격한 조합만을 비교합니다.
4. 조사를 통해 수락이 확인되었는지, 정책에 따라 부재가 확인되었는지, 또는 여전히 결론을 내릴 수 없는지 기록합니다.
5. 명시적인 재시도 정책(retry policy)이나 운영자가 새로운 제출이 정당한지 결정하도록 합니다.

이 프로세스는 정확히 한 번(exactly-once)의 발행을 보장하지는 않습니다. 대신 불확실성을 가시화하고, 에이전트가 모든 타임아웃을 재제출 권한으로 오해하는 것을 방지합니다. 더 광범위한 장애 모델(incident model)에 대해서는 실패한 소셜 미디어 게시물 복구 가이드를 참조하십시오.

예약된 시점이 지난 후 재조정(reconciliation)을 다시 실행하십시오. 지원되는 워크플로에서 사용 가능한 상태 증거를 통해, 그리고 실행 가능한 경우 공개된 목적지에서 제공업체의 발행 여부를 확인하십시오. 결과가 여전히 불확실하다면, 불확실한 상태로 유지하십시오. 경과된 시간만으로는 발행의 증거가 될 수 없습니다.

스케줄링을 더 넓은 배포 파이프라인에 맞추기

스케줄러는 시스템의 나머지 부분에 대해 좁은 계약 (narrow contract)을 노출해야 합니다. 스케줄러는 승인된 수정본 (revision)과 목적지를 전달받은 후, 구체적인 시간과 조정된 결과 (reconciled outcome)가 포함된 내구성이 있는 기록 (durable record)을 반환합니다. 초안 생성 (Draft generation)은 상류 (upstream)에 머물고, 보고 및 복구는 하류 (downstream)의 증거를 사용합니다. 에이전트 추론 (Agent reasoning)은 결정 지점 (decision points)에 유지됩니다. 결정론적 애플리케이션 코드 (Deterministic application code)가 타임스탬프, 검증, 영속성 (persistence), 그리고 상태 전이 (state transitions)를 담당합니다.

스케줄러의 내부 소스, 승인, 타이밍 및 조정 기록이 추측된 제공자 필드 (provider fields)에 의존하지 않기 때문에 스케줄러는 교체 가능한 상태로 유지됩니다. 어댑터 (Adapters)는 고정된 작업 (frozen job)을 현재의 통합 계약 (integration contract)으로 변환할 수 있습니다. AI 콘텐츠 배포 파이프라인 (AI content distribution pipeline)은 에이전트 대화를 시스템 기록 (system of record)으로 만들지 않고도 각 단계가 어떻게 연결되는지 보여줍니다.

Groniz 커넥터 (Connectors)와 공개 API (public API)는 이 설계를 위한 발행 계층 (publishing layer)을 제공할 수 있습니다. 이를 통해 통합 목록을 나열하고, 실시간 요구 사항을 검사하며, 정책에 부합하는 다음 슬롯을 찾고, 미디어를 업로드하고, 게시물을 스케줄링하며, 나중에 이를 나열하거나 관리할 수 있습니다. 이러한 호출을 둘러싼 아키텍처는 귀하의 소유로 남습니다.

Groniz 공개 API 소개를 검토하고 현재의 스케줄링 작업을 귀하의 운영자 소유 기록 (operator-owned record)에 매핑하십시오.