DearMate의 캐릭터가 대화 밖에서도 콘텐츠를 만들고 활동하려면, 기획과 생성 결과를 검토하고 게시하는 운영 흐름이 필요했습니다. 초기 제품 요구사항에는 기획과 생성 도구가 흩어지고, 재생성한 결과와 승인 상태를 추적하기 어렵고, 승인 내용과 실제 게시 결과가 어긋날 수 있다는 문제가 적혀 있습니다.
저는 이 운영 과정을 Social Automation으로 구성했습니다. 운영자와 기획을 정리하는 대화, 확정된 작업을 수행하는 생성 실행, 승인 결과를 외부로 보내는 게시 처리에 각각 책임을 부여했습니다.
1. 운영자의 대화와 생성 작업의 실행을 나눴습니다
Main Agent는 관리 콘솔에서 운영자가 기획을 정리하는 대화 상대입니다. Google ADK가 실행을 담당하고 CopilotKit은 대화 스트림, 프론트엔드 도구와 상태를 연결합니다. 프론트엔드 도구 연결과 명시적으로 주입한 서버 도구만 등록하며, Management Agent의 생성 실행 도구를 같은 목록에 섞지 않습니다.
Management Agent는 제출된 Content Task를 받아 실제 생성 작업을 조정합니다. 필요한 텍스트·이미지·영상 산출물을 요청하고, 실행 이벤트와 결과를 남긴 뒤 구조화된 결정을 반환합니다. 사람이 기획을 수정하는 대화와, 특정 작업의 결과를 완성해야 하는 실행은 필요한 맥락과 종료 조건이 다르기 때문에 별도 경계로 구성했습니다.
Main Agent의 장기 상담 세션은 영속화와 맥락 압축의 대상입니다. 현재 개인 저장소의 Management runtime은 작업 실행이 끝나면 임시 검토 미디어와 실행 세션을 정리하고, 작업·결과는 별도의 영속 상태로 보존합니다. 두 에이전트의 기억을 동일한 수명으로 관리하지 않는 선택입니다.
2. 제출한 작업이 요청 수명과 함께 사라지지 않도록 했습니다
Content Task 제출 전에 설명·브리프와 요청한 매체별 문서가 갖춰져 있는지 검사합니다. 이후 DRAFT에서 QUEUED로의 상태 변경, Management run 생성, PGMQ 메시지 추가를 PostgreSQL 트랜잭션으로 처리합니다. HTTP 요청 안에서 긴 생성을 끝낼 때까지 기다리지 않습니다.
Worker는 저장된 작업을 claim하고, claim token을 결과 갱신 때 다시 확인합니다. 실행에 실패해 메시지를 완료 처리하지 못하면 visibility timeout 이후 다시 읽힐 수 있습니다. task ID, management run ID, queue message ID를 연결해 제출부터 실행까지 추적합니다.
생성 시작 시각과 외부 게시 시각도 구분합니다. 콘텐츠를 만드는 예약과 승인된 콘텐츠를 공개하는 예약은 서로 다른 결정이기 때문입니다.
3. 생성 완료와 사람의 승인을 구분했습니다
생성 결과가 준비됐다는 상태와 사람이 사용할 결과로 승인했다는 상태는 별도로 다룹니다. 검토 API는 승인·수정 요청·거절을 기록하고, 수정 요청에는 추가 지시가 있어야 합니다. 게시 예약은 승인 결정에만 붙일 수 있습니다.
이 구조는 재생성 과정에서도 무엇을 검토했고 어떤 결과를 승인했는지 구분하기 위한 것입니다. 외부 게시에는 승인 시점의 콘텐츠와 대상 계정을 사용합니다. 생성 모델의 최종 응답만으로 게시가 허용되는 흐름으로 두지 않았습니다.
초기 PRD의 Posting·PlotVersion 용어와 Instagram 중심 범위는 설계 당시의 기록입니다. 현재 코드에는 Content Task와 X publisher가 있으므로, 포트폴리오에서는 초기 요구사항과 실제 구현을 구분합니다. 초기 PRD의 모든 매체·채널 기능이 완성됐다고 서술하지 않습니다.
4. 게시 결과를 모를 때는 자동 재게시하지 않도록 했습니다
게시 worker는 성공, 재시도 가능한 오류, 영구 실패, 결과 불명을 구분합니다. Rate limit이나 외부 전송 전의 일시적 장애는 다시 시도할 수 있지만, 전송 후 타임아웃은 이미 게시됐을 가능성이 있습니다. 이 경우 OUTCOME_UNKNOWN으로 남기고 자동 재게시를 막습니다.
여러 worker가 동시에 같은 게시를 가져가지 않도록 데이터베이스 claim과 token으로 처리 권한을 확인합니다. 다만 데이터베이스와 외부 SNS를 하나의 트랜잭션으로 묶을 수는 없으므로, 모든 상황에서 정확히 한 번 게시된다는 보장을 주장하지 않습니다.
Sand 정산에서는 저장된 발화를 조회해 남은 처리를 마칠 수 있습니다. 외부 게시에서는 결과를 확정할 수 없는 경우가 있으므로 자동 재시도를 멈추도록 했습니다. 두 작업이 남기는 증거와 외부 효과를 기준으로 재시도 정책을 정한 사례입니다.
5. 승인된 활동을 이후 대화의 기억으로 연결했습니다
개인 저장소의 최신 stage에는 승인된 콘텐츠를 Activity Memory로 만드는 흐름이 추가되어 있습니다. 승인 당시의 기획·콘텐츠·파일 정보를 고정하고, 별도 worker가 텍스트와 이미지·영상을 VLM에 전달해 캐릭터가 회상할 수 있는 한국어 서술과 구조화된 정보를 생성합니다.
이 기억은 숫자 임베딩을 벡터 검색하는 방식과 구분됩니다. 현재 파이프라인은 승인된 활동의 설명을 저장하고 이후 A2A 생성과 캐릭터 대화의 참고 맥락으로 사용합니다. Agent Backend는 이 활동 기억을 현재 검색 결과와 함께 모델 입력에 넣으며, 기본 정책에서는 주입된 참고 내용을 새 대화 이력에 반복 저장하지 않습니다.
또한 콘텐츠 승인과 실제 게시 성공을 혼동하지 않도록, 기억 생성 지침은 근거에 없는 게시 결과나 사용자 반응을 추측하지 않게 요구합니다. 이 연결은 Social Automation의 결과가 이후 캐릭터의 대화와 활동에 이어지도록 구성한 사례입니다. 대화의 자연스러움이나 기억 정확도 향상 수치는 별도 평가가 필요합니다.
6. 확인한 테스트와 기여 근거
테스트에서는 요청한 매체의 기획 문서가 없으면 생성 큐에 넣지 않는지, Main Agent에 허용한 도구만 등록하는지, 같은 thread ID를 사용하더라도 인증 사용자가 다르면 대화와 목록이 분리되는지 확인합니다. 게시 worker 테스트는 성공·rate limit·전송 전 장애·영구 거절·결과 불명을 각각 다른 상태로 기록하는지 검사합니다.
관련 구현은 Main Agent 런타임·세션·권한·콘솔을 통합한 PR #43과 PGMQ 실행 연결, X 게시 worker, 활동 기억 연결 커밋에서 확인됩니다. 이 테스트 코드의 존재와 실제 외부 SNS 통합 실행의 성공 여부는 별도로 구분하며, 이번 조사에서는 외부 게시나 모델 호출을 실행하지 않았습니다.