승인은 특정 소셜 미디어 작업(action)에 결합되어야 합니다. 검토자는 자신이 승인하는 콘텐츠, 출처(source), 목적지(destination), 계정(account), 미디어(media), 타이밍(timing), 그리고 수정 사항(revision)을 확인해야 합니다. 만약 주장(claim)이나 계정이 변경된다면, 이전의 승인은 더 이상 유효하지 않습니다. 사전 승인된 자료를 바탕으로 구축된 저위험 변형(low-risk variant)은 고객 사례(customer story)나 보안 공지(security announcement)보다 더 좁은 경로를 택할 수 있습니다. 검토는 결과에 따른 영향(consequences)과 일치해야 하며, 예측 가능한 작업에는 엄격한 제한을 두고 전달(delivery) 후 확인 절차를 거쳐야 합니다.

권한 경계(Authorization Boundary) 정의

에이전트(agent)는 자신의 주장에 대한 충분한 근거 없이도 설득력 있는 카피(copy)를 생성할 수 있습니다. 또한 잘못된 계정에 대해 기술적으로 유효한 게시 요청(publishing request)을 준비할 수도 있습니다. 문장이 완벽하더라도 오래된 이미지나 어색한 게시 시간이 누락될 수 있습니다. 카피 검토(copy review)만으로는 이러한 실패를 놓칠 수 있습니다.

유용한 승인 정책은 쓰기 작업(write action)이 허용되기 전에 다음 여섯 가지 질문에 답해야 합니다:

1. 게시물에 어떤 소스 자료(source material)를 사용하는 것이 허용되는가?
2. 제안된 작업의 위험도는 어느 정도인가?
3. 누가 이를 검토할 자격이 있는가?
4. 승인 후에 무엇이 변경될 수 있는가?
5. 승인은 언제 만료되거나 재검증(revalidation)이 필요한가?
6. 전달된 결과를 누가 확인하며, 결과가 잘못되었을 경우 어떤 일이 발생하는가?

이러한 경계를 워크플로(workflow)와 에이전트의 권한(permissions) 모두에 설정하십시오. Groniz Connectors는 실제 게시 및 스케줄링(scheduling) 작업을 지원하므로, 연결된 에이전트는 쓰기 권한(write capability)을 가집니다. Groniz는 32개 이상의 네트워크에 걸쳐 OAuth, 플랫폼별 포맷팅(formatting), 스케줄링 및 전달을 처리합니다. 이러한 서비스가 게시물을 누가 승인할 수 있는지를 정의하지는 않습니다. 범용적인 Groniz 승인 대기열(approval queue), 역할 시스템(role system), 또는 초안 전용 키(draft-only key)가 귀하의 정책을 강제할 것이라고 가정하지 마십시오.

이 체크포인트를 둘러싼 더 넓은 운영 라이프사이클(operating lifecycle)에 대해서는 AI agent social media publishing from draft to verified delivery를 참조하십시오.

콘텐츠 승인과 게시 승인의 분리

**콘텐츠 승인 (Content approval)**은 최종 문구와 에셋(assets)을 다룹니다. 검토자는 주장(claims)을 출처와 대조하고 이름, 고객 참조, 그리고 톤앤매너(voice)를 확인합니다. 동일한 검토 과정에서 법률, 개인정보 보호, 보안 또는 공개(disclosure) 관련 문제도 포착되어야 합니다.

**게시 승인 (Publication approval)**은 해당 패키지를 특정 목적지로 전송할 수 있는 권한을 다룹니다. 검토자는 플랫폼, 계정, 통합(integration), 미디어, 설정, 날짜, 시간, 시간대(timezone) 및 범위(scope)를 확인합니다. LinkedIn 기업 페이지와 창업자의 LinkedIn 프로필은 동일한 카피(copy)를 사용하더라도 서로 다른 목적지입니다.

일상적인 게시물의 경우 한 사람이 두 가지 결정을 모두 내릴 수 있습니다. 위험도가 높은 작업은 정확성을 확인할 수 있는 주제 소유자(subject owner)나 권한을 확인할 수 있는 고객 소유자(customer owner)를 필요로 할 수 있습니다. 법률 및 보안 검토자는 각자의 영역에 있는 주장(claims)을 처리해야 합니다. 각 위험 클래스(risk class)별로 검토자를 지정하십시오. "승인을 받으세요"와 같은 지침은 책임 소재를 불분명하게 만듭니다.

이러한 분리는 에이전트(agent)에게 명확한 순서를 제공합니다:

승인된 소스 (approved source)
  → 채널별 초안 (channel-specific draft)
  → 콘텐츠 검토 (content review)
...

에이전트-채널 게시 체크리스트 (agent-to-channel publishing checklist)에서 주변 사전 점검(preflight) 단계들을 다룹니다.

결과에 따른 작업 분류

소셜 게시물이 모두 동일한 승인을 필요로 하는 것은 아닙니다. 사람들이 일관되게 적용할 수 있는 짧은 위험 클래스(risk classes) 세트를 사용하십시오.

위험은 콘텐츠와 작업 모두에서 발생합니다. 해롭지 않은 문장이라도 10개의 계정으로 전송되면 더 큰 결과(consequence)를 초래할 수 있습니다. 익숙한 제품 관련 주장이라도 서비스 중단(outage) 중에는 민감할 수 있습니다. 수정 사항은 빠르게 처리되어야 할 수도 있으므로, 사전에 에스컬레이션 경로(escalation route)를 정의하고 책임 있는 소유자(accountable owner)를 유지하십시오.

적용 가능한 가장 높은 등급을 사용하십시오. 에이전트(Agent)는 분류를 제안하고 그 근거를 설명할 수 있습니다. 경계선에 있는 사례(borderline cases)는 지정된 담당자가 결정해야 합니다. "일상적인(routine)" 업무가 인지하지 못한 채 생소한 업무로 확장되지 않도록, 특정 게시물이 왜 저위험(low-risk) 경로를 통과했는지 기록하십시오.

승인을 게시 정체성(publication identity)에 결합하십시오

각 승인은 특정 게시 정체성(publication identity)을 가리켜야 합니다. 최소한 다음 사항들을 캡처하십시오:

• 변경 불가능한 리비전(revision) 또는 콘텐츠 해시(content hash);
• 사용된 모든 소스 및 그에 의해 뒷받침되는 주장(claims);
• 네트워크, 연결된 계정 및 통합 식별자(integration identifier);
• 최종 미디어 파일 및 해당 버전;
• 예정된 날짜, 시간 및 시간대(timezone);
• 라이브 통합(live integration)에 필요한 플랫폼 설정;
• 위험 등급(risk class), 검토자, 승인 시간 및 만료 시간;
• 승인 후 허용되는 편집 사항;
• 그리고 전달 확인(delivery check) 및 그 소유자.

위 필드 중 하나라도 변경될 때마다 정책의 재검증(revalidation) 규칙을 적용하십시오. 저위험(low-risk) 정책은 문장 부호 수정 정도는 허용할 수 있습니다. 통계 수치를 추가하거나, 이미지를 교체하거나, 프로필에서 기업 페이지(company Page)로 변경하거나, 게시물을 다른 뉴스 사이클(news cycle)로 이동하는 등의 행위는 일반적으로 해당 승인을 다시 열어야(reopen) 합니다.

이는 멀티 채널(multi-channel) 작업에서 가장 중요합니다. 근본적인 소스는 하나의 승인을 받을 수 있지만, 각 채널 버전은 고유한 컨텍스트(context)를 가집니다. LinkedIn에서의 전문적인 주장은 실명이 명시된 저자나 페이지의 목소리가 필요합니다; AI 에이전트를 위한 LinkedIn 게시 워크플로(LinkedIn posting workflow for AI agents)에서 해당 검토 과정을 설명합니다. Reddit은 현재의 커뮤니티 규칙, 소속(affiliation) 및 중재(moderation) 컨텍스트를 추가합니다; 이러한 확인을 위해 Reddit 게시 자동화 가이드(Reddit posting automation guide)를 사용하십시오. 소스 승인은 재사용할 수 있습니다. 하지만 게시 승인(publication approval)이 자동으로 이전되지는 않습니다.

예약을 하기 전에, 라이브 통합(live integration) 설정과 최종 소스 및 에셋(assets)을 점검하십시오. 기능과 필수 설정은 플랫폼마다 다르므로, 다른 네트워크에서 복사한 페이로드(payload)가 현재 요청이 유효하다는 증거가 될 수는 없습니다.

복사 가능한 승인 정책 템플릿 (Copyable approval policy template)

이 정책을 게시물을 준비하는 워크플로 (workflow) 옆에 두십시오. 이름과 임계값 (thresholds)을 귀사의 조직에 맞게 조정하십시오. 에이전트 (agent)가 각 게시 요청 시 완료된 레코드 (record)를 반환하도록 요구하십시오.

policy:
  name: "AI social publication approval"
  owner: "이 정책에 책임을 지는 이름 또는 역할"
...

예시로 제공된 TTL (Time-to-live) 값은 시작점일 뿐입니다. 사실 관계가 빠르게 변할 때는 이 값을 단축하고, 소스 (source), 목적지 (destination), 그리고 컨텍스트 (context)가 안정적일 때만 길게 설정하십시오. YAML은 결정을 기록하는 것이지, 정책을 강제하는 것이 아닙니다.

승인 후 발생하는 사항 제어하기

"경미한 수정 허용"이라는 표현은 너무 모호합니다. 정확한 변환 (transformations) 내용을 나열하십시오. 저위험 (low-risk) 정책이라면 공백 정규화 (whitespace normalization)나 중복된 빈 줄 제거 정도를 허용할 수 있습니다. 새로운 통계, 더 강한 형용사, 다른 링크, 변경된 고지 사항 (disclosure), 또는 재생성된 이미지는 실질적인 변경 (material change)으로 취급하십시오.

플랫폼의 제약 사항으로 인해 실질적인 변경이 불가피한 경우, 새로운 개정판 (revision)을 생성하고 다시 검증하십시오. 에이전트가 변형된 버전 (variants)을 준비할 때도 동일한 규칙을 적용하십시오. 하나의 초안에 대한 승인이 이후의 의역 (paraphrases)까지 확장되려면, 저위험 정책에서 소스, 허용 가능한 변형, 계정, 그리고 유효 기간을 명시적으로 정의해야만 합니다.

스케줄링 권한 (scheduling authority)은 좁게 유지하십시오. 화요일 오전 승인은 해당 시간대에만 유효합니다. 즉시 게시, 인시던트 윈도우 (incident window)로의 이동, 또는 추가적인 목적지 설정은 새로운 권한 부여가 필요합니다. 승인이 만료되면, 갱신하기 전에 무엇이 변경되었는지 확인하십시오.

검증을 통한 승인 루프 완성

누군가가 전달된 결과물 (artifact)을 확인하기 전까지 승인은 열려 있는 상태입니다. 반환된 게시물 식별자 (identifier), 목적지, 예약된 시간, 상태, 그리고 가능한 경우 플랫폼 URL을 캡처하십시오. 게시물이 라이브 (live) 상태가 되면, 해당 네이티브 플랫폼에서 게시물을 검사하십시오. 계정과 문구 (copy)를 확인한 다음, 미디어, 링크, 고지 사항, 그리고 렌더링 (rendering) 상태를 점검하십시오.

요청이 시간 초과(timeout)되거나 모호한 결과를 반환하는 경우, 재시도하기 전에 예약되었거나 게시된 기록을 확인하십시오. 무분별한 재시도는 중복을 생성할 수 있습니다. 전달에 실패하거나 잘못된 콘텐츠가 나타나면, 증거를 기록하고 문제를 격리하십시오. 모든 자료 수정 사항은 검토(review) 과정을 통해 다시 전달해야 합니다. 실패한 소셜 미디어 게시물 복구 가이드에서 재시도 및 복구에 대해 다룹니다.

인간 검토(Human review)가 안전을 보장할 수는 없습니다. 인간 검토의 역할은 권한과 증거를 가시화하고 명확한 복구 경로(recovery trail)를 남기는 것입니다. 에이전트(agent)는 자신이 준비할 수 있는 것의 한계를 알고 있는 반면, 검토자(reviewer)는 승인되는 정확한 동작을 확인합니다. 전달 후, 운영자(operator)는 결과와 해당 승인 내용을 비교할 수 있습니다.

승인 경계(approval boundary)가 준비되었다면, AI 에이전트를 Groniz에 연결하여 지원되는 네트워크 전반에 걸쳐 게시 및 스케줄링을 수행하십시오.