안녕하세요 — 같은 메시지에서 두 가지를 물어보셨네요. 세 도메인의 동기화가 설정한 시간보다 한 시간 늦게 실행된 이유, 그리고 이왕 확인하는 김에 최적화 팀을 자율 모드로 전환해야 할지. 알고 보니 두 질문은 같은 맥락이라서, 따로 답하는 대신 함께 다뤄보겠습니다.
시스템의 구조부터 시작하겠습니다. 그러면 두 문제가 모두 설명되니까요. 여기서 모든 팀은 한 번 실행, 수동, 자율 세 가지 모드 중 하나로 동작하는데, "자율"은 별도로 존재하는 더 똑똑한 상위 등급이 아닙니다. 스케줄이 붙고 루프가 닫힌 채로 유지되는 수동 실행일 뿐입니다. 같은 에이전트, 같은 가드레일, 모든 게 동일하고, 단지 버튼을 누를 시점을 사람 대신 스케줄러가 결정할 뿐이죠. 이 점만 명확히 하면 나머지는 자연스럽게 이해됩니다.
동기화와 일정이 서로 다른 곳에 위치하는 이유
| 예약 | 무엇을 구동하는가 |
|---|---|
| 데이터 동기화 | Search Console / Analytics / 스토어 데이터를 대시보드로 매일 가져오는 작업 — 다른 모든 것의 연료가 됩니다 |
| 에이전트 실행 | 매 동기화 이후 자동으로 실행되는 최적화 작업, 브리프 대기열을 채우는 리서치 스윕, 그리고 실행 상태로 남겨둔 팀들 |
동기화 설정은 각 도메인에, 실행 설정은 각 팀에 있는 걸 보실 텐데, 하나로 통합된 자동화 페이지가 아닙니다 — 처음 찾아볼 때는 어색하게 느껴질 수 있다는 걸 압니다. 하지만 이건 의도된 설계입니다. 동기화 주기는 데이터에 관한 것입니다: Search Console이 실제로 얼마나 빨리 새로고침되는지. 실행 주기는 팀에 관한 것입니다: 그 팀이 확인한 내용에 얼마나 빨리 반응하기를 원하는지. 서로 다른 질문에는 서로 다른 답이 필요합니다. 이전 버전의 플랫폼에서는 이 둘을 하나의 페이지에 묶어놓았는데, 그러다 보니 하나만 건드려도 다른 쪽까지 함께 고려해야 했습니다. 이를 분리한 게 해결책이었습니다.
최적화 팀에 무언가를 예약하기 전에 알아두면 좋은 것: 예약된 시간에 실행되는 작업과 직접 손으로 시작한 작업은, 일단 시작되고 나면 완전히 동일한 결과물을 만들어냅니다. 같은 보고서, 같은 기록 항목, 같은 크레딧 비용, 실행 중에도 열어서 진행 상황을 지켜볼 수 있는 동일한 기능까지요. 예약된 실행이 비용 절감을 위한 경량 버전일 거라고 가정하는 분들을 봤는데, 그렇지 않습니다. 직접 트리거한 실행을 신뢰하지 않는다면, 타이머에 올리지 마세요.
마이그레이션된 일정에서 실제로 무엇이 잘못되었는가
이전 도구에서 시간을 그대로 복사해 붙였다고 하셨죠 — UTC 14:00, 원래는 로컬 시간으로 오후 2시에 실행되도록 의도한 값이었습니다. 이게 바로 그 함정입니다. 저희 시간 필드는 UTC가 아니라 로컬 시계값을 원합니다. 감지된 시간대를 바로 아래에 표시해주기 때문에 굳이 추측할 필요가 없습니다. 그런데 그 자리에 UTC 값을 붙여넣으면 이미 로컬 시간인 것처럼 취급되어 다시 한 번 UTC로 변환되고, 결과적으로 오후 2시가 아니라 오후 4시에 실행되게 됩니다. 나머지 두 도메인에 대한 해결 방법: 시간을 로컬로 다시 입력하고, 이전 도구가 제공한 UTC 값은 무시하세요.
실제로 물어보신 그 한 시간 차이 — 동기화가 6시가 아니라 7시에 실행된 것 — 은 서머타임(DST)으로 인한 현상이며, 3월과 10월마다 다시 헤매기보다는 한 번 제대로 이해해두면 좋은 부분입니다. 1월에 베를린 기준 6:00 동기화를 설정하면 플랫폼은 5:00 UTC로 저장합니다. 겨울에는 베를린이 UTC+1이기 때문입니다. 단순한 스케줄러라면 계속 5:00 UTC에 실행되도록 남겨둘 텐데, 서머타임 전환이 오면 베를린은 UTC+2로 바뀌고, 같은 5:00 UTC 시각이 이제 로컬 기준 7:00에 해당하게 됩니다 — 오류 없이 조용히, 예상보다 두 시간 늦은 숫자로 나타날 뿐입니다. 저희는 저장 시점이 아니라 입력 시점에 현재 오프셋을 기준으로 변환하기 때문에, 6:00 일정은 서머타임 여부와 관계없이 실행되는 날의 실제 시계 기준 6:00을 의미합니다. 로컬로 다시 입력한 후에도 여전히 한 시간 오차가 보인다면, 그건 지원팀에 문의할 가치가 있습니다 — 새로 입력한 일정에서는 이런 일이 발생하지 않아야 합니다.
실제 주기 설정하기
- 동기화: 매일, 그 이상은 무의미합니다. Search Console 데이터는 잘해봐야 2~3일 지연되어 들어옵니다. 세 개 도메인에 걸쳐 매시간 동기화한다고 해서 더 신선한 데이터를 얻을 수 있는 게 아니라, 같은 지연된 데이터를 계속 반복해서 가져오는 작업으로 동기화 기록만 채우게 됩니다.
- 최적화: 별도 시각이 아니라 동기화에 연결됩니다. 지금 예약하려는 것과 관련해 가장 중요한 부분입니다. 어느 날 Google API가 느려서 동기화가 6시가 아니라 6시 2분에 끝나면, 최적화 작업은 자체 6시 15분 슬롯을 기다리지 않고 바로 그 신선한 데이터를 대상으로 실행됩니다 — 동기화가 길어졌을 때 어제 데이터를 대상으로 실행되는 위험을 감수하지 않습니다. 두 개의 독립된 시계는 서로 어긋나기 전까지는 괜찮아 보이는 법입니다.
- 리서치: 매주, 콘텐츠 팀이 실제로 소화할 수 있는 양에 맞춥니다. 브리프는 하루아침에 낡지 않지만, 검토되지 않은 브리프가 대기열에 쌓여 있어도 아무도 손대지 않으면 크레딧만 소모됩니다. 팀이 현실적으로 주 4~5개의 브리프를 승인할 수 있다면, 그 정도가 나오도록 스윕 규모를 설정하세요 — 매일 스윕이 매주 검토 습관에 데이터를 쏟아부으면 아무도 처리하지 못할 백로그만 쌓입니다.
- 광고 — 다음 달 해당 팀을 다룰 때는: 의도적으로 일정 없음. 초안은 요청 시 생성되며, 사용자 없이는 아무것도 게시되거나 비용이 집행되지 않습니다. 자세한 이유는 자동 광고 집행에 반대하는 이유에서 다루지만, 요약하면 콘텐츠 동기화의 일정 실수는 사소한 불편이지만 광고 비용의 일정 실수는 곧 청구서라는 것입니다. 오늘 설정하는 것과 그 팀의 설정이 똑같을 거라 기대하지 마세요.
그렇다면 — 최적화를 자율 모드로 전환해야 할까요?
질문이 시사하는 것보다 덜 극적인, 솔직한 답을 드리면: 켠다고 해서 바뀌는 건 생각보다 적습니다. 에이전트는 직접 실행 버튼을 눌렀을 때 없던 새로운 능력을 얻는 게 아닙니다 — 파괴적인 작업에 대한 확인 절차도, 판단도, 모든 것이 동일합니다. 바뀌는 건 오직 언제 실행할지를 누가 결정하느냐뿐입니다. 지금은 당신이고, 일정을 설정하면 시계가 결정합니다.
저라면 "자율 모드가 안전한가"보다 이렇게 묻겠습니다: 최근 세 번의 수동 최적화 실행 결과가 설정한 주기대로 무인으로 다시 일어나도 괜찮은가요? 그렇다면 준비된 겁니다 — 켜세요. 만약 그 세 번을 직접 검토했기 때문에만 안심할 수 있었던 거라면, 그것도 하나의 진짜 신호이며, 조금 더 수동으로 유지하는 것이 옳은 선택이지 배짱이 부족해서가 아닙니다.
현재 상황 — 세 개 도메인을 막 이전했고 시각이 아직 완전히 정착되지 않은 상태 — 을 고려하면, 며칠 더 자율 모드를 보류하시길 권합니다. 남은 두 개의 일정을 수정하고, 내일 동기화가 올바른 시각에 실행되는지 지켜보고, 최적화를 두세 번 더 수동으로 실행해 실제로 어떤 일이 벌어지는지 처음부터 끝까지 확인해보세요. 그런 다음 예약하세요. 위의 주기 관련 질문들은 추상적으로 생각할 때보다 실제 실행 결과를 눈앞에 두고 답하는 게 훨씬 쉬워지며, 일주일 기다린다고 해서 손해 볼 건 없습니다.
