자동화 플레이북: 신뢰할 수 있는 브라우저 콘텐츠 워크플로 만들기¶
빠른 답변: 신뢰할 수 있는 브라우저 콘텐츠 운영은 계획, 초안, 사람의 검토, 게시, 측정을 관찰 가능한 단계로 분리합니다. 보이는 CDP 브라우저와 명시적인 MCP 동작을 사용하고, 인증 정보는 브라우저 프로필에 두며, 결과는 검색 가능한 프로젝트 컨텍스트에 기록합니다. 자동화의 목적은 반복 작업을 줄이는 것이지 책임을 없애는 것이 아닙니다.
브라우저 자동화를 페이지 열기, 버튼 클릭, 문구 붙여넣기의 반복으로만 설계하면 승인된 콘텐츠인지, 어떤 계정이 선택되었는지, 게시가 성공했는지, 장애 후 어디서 재개할지가 불분명해집니다.
이 글에서는 그 매크로를 일시 중지, 검토, 재개할 수 있는 작은 운영 시스템으로 나눕니다.
한눈에 보는 워크플로¶
| 단계 | 시스템 책임 | 사람의 책임 |
|---|---|---|
| 계획 | 아이디어 큐와 상태 필드 관리 | 목표, 대상, 게시 조건 결정 |
| 초안 | 초안, 변형, 출처 준비 | 사실, 어조, 독창성 검토 |
| 검토 | 승인되지 않은 항목의 게시 차단 | 최종 문구와 미디어 승인 |
| 게시 | 보이는 브라우저를 조작하고 결과 보고 | 인증 화면과 민감한 외부 전송 처리 |
| 측정 | 타임스탬프와 결과 지표 기록 | 결과 해석과 다음 실험 결정 |
상태는 idea -> draft -> review -> approved -> published -> measured처럼 명시적으로 관리합니다. 브라우저 동작 실패와 콘텐츠 거절은 같은 상태가 아니므로 분리해서 기록해야 합니다.
1. 프롬프트보다 먼저 콘텐츠 큐를 만든다¶
콘텐츠 하나를 하나의 안정적인 레코드로 저장하고 다음 항목을 포함합니다.
- 콘텐츠 ID, 대상 플랫폼, 계정 라벨
- 주제, 대상 사용자, 기대하는 다음 행동
- 초안, 미디어 참조, 출처
- 검토 상태, 검토자, 검토 시각
- 예정 게시 시각과 실제 게시 시각
- 결과 지표, 관찰 기간, 후속 메모
큐가 있으면 브라우저가 12번째 항목에서 닫혀도 다음 실행에서 approved 항목을 조회해 이어갈 수 있습니다. 대화 기록만 보고 진행 상황을 추측할 필요가 없습니다.
2. 보이고 범위가 분명한 브라우저 루프를 사용한다¶
브라우저 작업에는 저장소가 권장하는 browser-use CDP 경로를 사용합니다.
- 대상 프로필로 보이는 브라우저를 실행합니다.
- CDP로 연결합니다.
- semantic snapshot 또는 필요한 페이지 텍스트를 읽습니다.
- 보이는 동작을 한 번 수행합니다.
- 예상한 상태 전환을 기다립니다.
- 페이지를 다시 읽고 결과를 기록합니다.
인증 화면, 계정 전환, 최종 게시와 같은 민감한 외부 전송은 사람이 확인해야 합니다. 자동화를 숨기거나 신원을 바꾸거나 플랫폼 통제를 피하는 설계를 만들지 마세요. 작업 간격 조정을 규정 준수의 보장처럼 설명해서도 안 됩니다. 공식 API나 플랫폼이 승인한 자동화 방법이 있으면 해당 규칙을 우선합니다.
3. 검토를 실제 게이트로 만든다¶
게시 단계가 무시하기 쉬운 체크박스 하나에만 의존하지 않도록 합니다. 최소 조건의 예시는 다음과 같습니다.
status == approved
reviewer != empty
media references resolve
target account matches the selected profile
하나라도 충족하지 않으면 blocked로 멈추고 안전한 다음 동작을 보고합니다. 검사를 단순한 경고로 낮추지 않는 것이 중요합니다. Harness CLI의 최소 올바른 변경 게이트와 같은 원칙입니다.
4. ContextDB에는 유용한 컨텍스트만 저장한다¶
ContextDB에는 오래 유지할 사실, 콘텐츠 큐 상태, 출처, 인수인계 메모를 저장할 수 있습니다. pull-based 흐름에서는 다음 동작에 필요한 증거만 가져오므로 매번 전체 대화 기록을 주입하지 않습니다.
ContextDB 문서에서 프로젝트 메모리와 검색을 확인하고, 검색 구현은 ContextDB FTS5/BM25 글을 참고하세요. 개인정보, 인증 정보, 쿠키, 비식별화되지 않은 인증 로그를 공개 산출물에 넣지 마세요.
5. 같은 정의로 결과를 측정한다¶
노출, 조회, 좋아요, 저장, 댓글, 팔로우, 클릭, 승인부터 게시까지의 시간 등을 플랫폼과 콘텐츠마다 같은 형식으로 기록합니다. 관찰 기간도 함께 저장해야 하며 게시 후 2시간 데이터와 7일 데이터를 바로 비교하면 안 됩니다.
Perception은 결과 요약을 도울 수 있지만 무엇이 사실인지 결정하거나 다음 변형을 자동 게시하지는 않습니다. 다음 실험에는 하나의 가설, 하나의 변경 변수, 하나의 관찰 기간을 명시하세요.
중단 후 복구 체크리스트¶
재시도하기 전에 결과를 분류합니다.
blocked: 사람의 승인, 로그인, 정책 판단이 필요함failed: 콘텐츠나 요청 자체가 유효하지 않음infra-retry: 브라우저, 도구, 네트워크가 회복될 수 있음published: 게시 성공을 확인함measured: 관찰 결과를 기록함
마지막 페이지 상태, 계정 라벨, 콘텐츠 ID, 안전한 다음 동작을 인수인계 메모에 남깁니다.
자주 묻는 질문¶
사람의 검토 없이 게시할 수 있나요?¶
플랫폼 규정, 계정 소유자의 권한, 프로젝트 정책이 그 수준의 자동화를 명확히 허용할 때만 검토할 수 있습니다. 기본 플레이북은 검토와 민감한 외부 전송을 사람의 책임으로 둡니다.
처음부터 여러 계정을 운영해야 하나요?¶
먼저 한 계정으로 큐, 검토, 복구 흐름을 검증하세요. 상태가 관찰 가능하고 프로필이 분리되며 규정에 맞는지 확인한 뒤 계정을 늘리는 편이 안전합니다.
최소 구성은 무엇인가요?¶
콘텐츠 큐, 보이는 CDP 브라우저 프로필 하나, 검토 게이트, 결과 레코드가 있으면 시작할 수 있습니다. 규모가 커지면 ContextDB 검색과 Perception 요약을 추가하세요.
브라우저 자동화로 공식 API를 대체할 수 있나요?¶
일괄적으로 대체할 수는 없습니다. 공식 API나 승인된 자동화 방법을 우선하고, 브라우저 작업은 허용된 범위에서 실행하세요. 인증 화면과 민감한 동작에는 사람의 확인을 남겨야 합니다.
공식 문서¶
Getting Started, ContextDB, Use Cases, Troubleshooting부터 시작하세요.