게시 시각, 어림하지 않기

정해진 시각에 글을 올리는 자동화가 일찍 올리지 않게 하려면, AI가 짐작한 시각을 쓰지 않고 시스템 시계로 계산한 결과를 게시 직전에 확인해야 합니다. 리도의 예약 게시 작업은 이 확인을 넣은 뒤에도 글이 올라갈 때마다 공개 화면의 시각을 목표와 다시 대조합니다. 그래도 1초 일찍 올라간 날이 있었고, 그 기록도 아래에 함께 적었습니다.

2026년 11월 5일 확인한 작업 기록과 지침 파일 기준입니다. 생활 정보를 올리는 Threads 계정 하나의 사례이며 고객사 프로젝트가 아닙니다. 시각을 지킨 것이 조회나 문의를 늘렸다는 측정은 이 글에 들어 있지 않습니다.

무슨 일이 있었습니까?

10월 24일 저녁, 20시에 올려야 할 글이 19시 39분 19초에 올라갔습니다. 목표보다 20분 41초 이른 시각입니다.

이 작업에는 규칙이 두 개 있습니다. 글마다 목표 시각이 있고, 같은 계정의 직전 첫 글과 최소 2시간 30분 간격을 둡니다. 그날 직전 첫 글은 17시 9분 48초에 올라갔으니 간격도 2시간 29분 31초로 29초 모자랐습니다. 두 규칙을 한꺼번에 어긴 셈입니다.

그날 작업 기록은 원인을 이렇게 적었습니다. 실제 시각을 20시대로 잘못 어림했고, 작업 중 경과 시간을 짐작한 값이 실제 시계와 약 35분 벌어져 있었다는 것입니다. 시계를 읽은 것이 아니라 흘러간 시간을 세어 본 것이 문제였습니다. 이미 공개된 글은 지우거나 다시 올리지 않았고, 장부에 편차만 적었습니다. 같은 날 저녁에 시각 검사 지침 파일이 만들어졌고, 파일 수정 시각은 19시 42분입니다.

나무 책상 위에 작은 탁상시계와 비어 있는 노트, 연필이 놓인 창가 장면원본 전체 보기 ↗

시각 검사는 무엇을 계산합니까?

두 가지 시각을 받아 가장 이른 게시 가능 시각을 구하고, 지금이 그 뒤인지 앞인지만 말해 줍니다. 입력은 목표 시각과 직전 첫 글의 공개 시각이고, 출력은 PASS 또는 WAIT입니다.

지금 시각은 시스템 시계(Date.now())만 씁니다. 지침 파일은 시험용으로 시각을 직접 넘기는 칸이 함수에 있지만 실제 운영에서는 절대 넘기지 말라고 적어 두었습니다. 시험에서 나온 PASS는 게시 허가가 아니기 때문입니다. 직전 글의 시각이 형식에 맞지 않거나 미래로 찍혀 있으면 함수가 PASS나 WAIT를 내지 않고 오류로 멈춥니다. 모르는 값으로 계산을 이어 가지 않게 한 것입니다.

WAIT가 나오면 게시 버튼을 누르지 않습니다. 남은 시간을 기다린 뒤 최신 첫 글과 계정을 다시 확인하고 다시 계산합니다. 계산한 지 30초가 지났거나 최신 글이 바뀌었을 때도 다시 계산합니다. PASS가 나와도 계정, 중복, 그림, 사실 검수는 그대로 따로 합니다.

지침 파일은 스스로 한계도 적어 두었습니다. 이 검사는 게시 도구와 물리적으로 연결된 차단 장치가 아니고, 발행하는 쪽이 반드시 실행하고 지켜야 하는 검수 단계라는 것입니다. 코드가 버튼을 잠그지는 않습니다. 그래서 아래 기록은 이 단계가 실제로 지켜졌는지를 글마다 공개 시각으로 다시 보는 장치이기도 합니다.

직전 글의 시각은 어디서 가져옵니까?

공개 화면에 찍힌 날짜와 시간을 초 단위까지 읽어 옵니다. 화면의 "몇 시간 전" 표시, 사진 속 시계, 모델의 시간 어림은 근거로 쓰지 않습니다. 시각이 확인되지 않으면 확인될 때까지 게시하지 않는다는 것이 지침의 순서 2번입니다.

직전 글을 잘못 잡으면 간격 계산도 틀어집니다. 11월 4일 기록에는 프로필 목록에 같은 계정의 다른 글 일부가 보이지 않은 적이 있다고 남아 있습니다. 목록 맨 위 글이 곧 직전 첫 글이라고 믿지 않고, 확인한 글의 시각을 값으로 넘겨야 하는 이유입니다. 이 방식은 자동화가 한 일, 한 줄로 남기기에서 실행 시각과 결과를 도구 바깥에 적어 두자고 한 것과 같은 생각입니다.

검사를 넣은 뒤 공개 시각은 어땠습니까?

기록에서 확인한 일부 회차의 목표와 실제 공개 시각입니다. 날짜는 모두 2026년이고, 공개 시각은 공개 화면의 시간 표시를 읽은 값입니다.

사고 이후 기록된 회차는 대부분 목표 뒤 1초에서 10초 안에 올라갔습니다. 10월 24일 같은 20분대 이른 게시는 이 표에 없습니다. 다만 기록 몇 줄에서 "처음 끝까지 적용했다"는 표현이 서로 다르게 쓰여 있어서, 적용 횟수를 세어 효과를 말하지는 않겠습니다. 날짜별 공개 시각만 믿을 수 있는 값입니다.

목표 시각이 아니라 간격 규칙이 기다림을 정하는 날도 있었습니다. 11월 3일 13시 회차는 목표 13시가 이미 지났지만, 직전 글이 11시 0분 1초에 올라가 있어 2시간 30분을 채우는 13시 30분 1초까지 기다렸고 13시 30분 10초에 게시했습니다. 두 규칙 중 늦은 쪽을 따른다는 계산이 실제로 쓰인 장면입니다.

1초 일찍 올라간 날은 무슨 일이었습니까?

11월 4일 19시 30분 회차에서 검사는 PASS였고 게시도 그 직후에 눌렀는데, 공개된 시각은 19시 59분 59초였습니다. 작업용 컴퓨터 시계로는 20시 0분 0초 직후였지만 서버 기록은 목표보다 1초 이른 시각이었습니다.

기록은 컴퓨터 시계가 서버보다 약간 빠른 것으로 보인다고 적었고, 원인은 확정하지 못했습니다. 그래서 확정된 사실처럼 쓰지 않고 관찰로만 둡니다. 대응은 PASS를 받은 뒤에도 컴퓨터 시계로 목표 시각 2초 뒤까지 기다렸다가 누르는 것입니다. 11월 5일 02시 회차에서 컴퓨터 시계로 02시 0분 1초까지 기다린 뒤 PASS(02시 0분 6초)를 받고 눌렀더니 공개 시각이 02시 0분 10초로 정상이었습니다. 이 2초 규칙은 한 회차에서 통한 관찰이고, 지침 파일(마지막 수정 10월 24일)에는 아직 들어 있지 않고 회차 기록에만 있습니다.

같은 날 기록에 함정이 하나 더 있습니다. 목표를 기다리며 검사를 반복해서 돌리던 실행이 60초를 넘기자 작업 도구는 시간 초과 오류를 냈는데, 화면 안에서 돌던 스크립트는 멈추지 않고 계속 돌아 클릭까지 해 버렸습니다. 도구가 실패했다고 말해도 게시는 이미 일어났을 수 있다는 뜻입니다. 오류를 보고 곧바로 다시 올리지 않고 공개 화면부터 확인해야 하는 이유이고, AI 자동화 재시작 기준에서 정리한 "다시 실행하기 전에 외부 결과부터 확인한다"와 이어집니다.

서로 다른 모양의 작은 탁상시계 두 개가 창가 선반에 나란히 놓여 있고 초침 위치가 조금 다른 장면원본 전체 보기 ↗

기다리는 동안 작성창은 어떻게 합니까?

글을 목표보다 먼저 완성해 두고, 시각 검사가 PASS를 낼 때까지 작성창을 열어 둡니다. 이 정보글 회차는 목표 30분 전에 시작하기 때문에 준비할 시간이 있습니다.

11월 3일 02시 회차는 01시 35분에 작성창을 완성해 두고 02시까지 기다렸는데도 작성창 상태가 유지됐습니다. 같은 날 13시 회차는 13시 4분에 완성한 뒤 약 25분을 기다렸고 역시 유지됐습니다. 10월 25일 11시 회차의 작성창 점유는 8분 안이었습니다.

기다리는 방법에도 제약이 있었습니다. 대기 명령을 590초 이하로 지정해도 590초에 끊기는 일이 있어서 500초 이하로 나누어 기다립니다. 한 번에 길게 기다리는 대신 짧게 나누어 시각을 다시 읽고, 마지막 구간에서만 촘촘히 검사합니다.

내 업무에 옮기려면 어떤 순서가 좋습니까?

아래는 이번 운영 기록에서 정리한 제안이며 고객 프로젝트에서 검증한 절차가 아닙니다.

1. 예약 시각을 글마다 하나의 값으로 적습니다. 회차가 밀리거나 다시 시작되어도 오늘 날짜로 바꾸지 않습니다.
2. 직전에 나간 결과의 실제 시각을 초와 시간대까지 확인합니다. 화면에 "몇 시간 전"만 있으면 시각이 확인된 것이 아닙니다.
3. 지금 시각은 AI의 짐작이 아니라 시스템 시계에서만 읽습니다.
4. 목표와 최소 간격 두 조건을 따로 계산하고, 둘 다 충족될 때만 PASS로 취급합니다.
5. 서버 시각과 내 컴퓨터 시각이 어긋날 수 있으므로, 목표 직후가 아니라 몇 초 여유를 두고 누릅니다. 여유 폭은 자기 환경의 기록으로 정합니다.
6. 도구가 오류를 내도 게시가 이미 일어났을 수 있다고 보고, 다시 시도하기 전에 공개 화면을 확인합니다.
7. 게시 뒤 공개 시각을 읽어 목표와 대조하고, 어긋나면 완료로 적지 않습니다. 지우거나 다시 올려서 감추지 않고 편차를 기록합니다.

누가 이 기록을 보고 규칙을 고칠지는 자동화를 만든 사람이 없는 날에서 다룬 담당자 정하기와 맞물립니다. 이 검사에 어떤 권한까지 맡길지는 AI 자동화, 권한을 세 단계로 나눠 주기의 읽기, 초안, 실행 구분으로 정리할 수 있습니다.

시각을 지키면 반응이 좋아집니까?

이 기록으로는 말할 수 없습니다. 위 표는 글이 목표 시각에 올라갔는지를 본 것이고, 정시에 올라간 글이 더 많이 읽혔는지는 따로 재야 하는 다른 질문입니다. 공개 시각과 조회·문의는 서로 다른 증거로 두고, 한쪽이 맞았다고 다른 쪽이 좋아졌다고 쓰지 않습니다.

공개와 기록을 나눈 이유에서 공개된 결과와 장부를 따로 둔 것도 같은 원칙입니다.

다음에 볼 것

정해진 시각, 직전 결과, 사람의 확인 지점을 업무 단위로 나누어 자동화를 설계하려면 DMS.Labs 업무 자동화 페이지를 보실 수 있습니다. 이 글의 범위는 Threads 계정 하나의 예약 게시와 10월 24일부터 11월 5일까지의 운영 기록이며, 도입 비용이나 절감 시간, 문의·매출 효과를 약속하지 않습니다.

본문의 두 이미지는 설명용으로 새로 생성한 장면입니다. 실제 운영 화면이나 고객 현장을 촬영한 사진이 아닙니다.