자료를 여러 번 처리하는 일이라고 모두 공개 날짜가 필요한 것은 아니다. 반대로 예약 글을 준비하는 작업은 실행을 시작하는 시각과 실제 공개될 시각이 다르다. 나는 두 시간을 같은 날짜 칸으로 다루지 않고 일반 반복과 매체별 일정 조건을 나눴다. 날짜가 없어서 못 하는 업무와 날짜를 잘못 줘서 멈춰야 하는 업무도 구분하고 싶었다.
일반 workflow에는 빈 일정이 가능하다
plan의 workflow 분기는 firstSchedule이 없으면 항목 schedule을 빈 문자열로 둔다. 폴더 이름에 날짜를 강제로 넣게 하지 않는다. 날짜가 필요한지는 연결할 플러그인의 입력 계약과 이번 작업의 의도에 달린다. 일반 반복기를 쓴다고 모든 업무를 예약 게시로 바꾸지는 않는다.
그렇다고 모든 플러그인이 빈 날짜를 받아들인다는 뜻은 아니다. 일정이 필요한 매체 단계라면 그 입력 검사에서 다시 거절할 수 있다. 나는 반복기에서 날짜를 강제하지 않는 선택과 실제 절차의 필수 날짜를 없애는 선택을 구분했다. 범용성은 개별 업무의 조건을 지우는 방식으로 만들고 싶지 않았다.
시각을 주면 항목별 일정으로 펼친다
firstSchedule이 있으면 첫 시각에 intervalHours와 항목 인덱스를 적용해 각 시각을 만든다. 일반 workflow도 이 값이 주어졌다면 미래 시각과 초 단위 조건을 검사한다. 날짜를 생략해도 간격 입력 자체의 범위 검사는 남아 있으므로 모든 시간 관련 검사가 사라지는 것은 아니다.
수량과 일정이 결합하면 준비 결과에서 각 항목의 시각을 읽어야 한다. 첫 날짜만 맞는다고 마지막 날짜까지 원하는 결과라고 보장할 수 없다. 나는 반복 횟수와 간격이 만든 전체 목록을 검토 자료로 남기는 편이 낫다고 생각했다. 편한 날짜 계산과 올바른 공개 계획은 다른 확인이다.
매체별 날짜 규칙을 하나로 과장하지 않는다
전용 예약 경로는 첫 시각을 주거나 지원하는 날짜 폴더 이름을 읽는다. 시간대가 없는 입력은 현재 구현에서 한국 시간으로 해석하고 명시한 시간대는 변환한다. 미래 여유와 초·마이크로초 조건을 검사하며 네이버 경로에는10분 단위 조건이 더 있다.
이 조건을 모든 플랫폼이 같은10분 간격만 지원한다는 설명으로 확대하지 않는다. 같은 반복 뼈대를 써도 실제 매체의 예약 규칙은 다르다. 나는 날짜 오류를 하나의 “형식 오류”로 숨기기보다 어느 입력과 플랫폼 규칙을 확인해야 하는지 설명할 수 있어야 한다고 봤다.
startAt은 실제 반복을 시작하는 별도 시각이다
공개 시각과 별도로 startAt을 두고, 없으면 현재를 사용한다. 날짜가 있는 첫 항목보다 충분히 앞서 작업을 시작할 수 있는지도 검사한다. 미래 공개 글을 지금 미리 등록하는 경우 실행 시간과 공개 시간이 다를 수 있다는 사실을 자료 구조에 남긴 것이다.
실행기가 늦게 시작했을 때의 처리도 별도다. worker는 시작 시각을2분 넘겼으면 overdue로 남기고 무조건 과거 작업을 실행하지 않는다. 이것은 콘텐츠의 예약 시각을 자동으로 바꿨다는 뜻이 아니다. 실행 지연과 일정 재작성은 다른 결정이며 새 의도와 조건을 확인해야 한다.
미리보기와 등록, 실제 예약 완료를 구분한다
preview는 계산한 항목과 시각을 보여 주지만 registered와 publicationVerified는 거짓이다. register가 로컬 실행을 접수해도 실제 매체 예약이 모두 끝났다는 뜻은 아니다. 시각표가 만들어졌다는 사실과 서버에 반영된 예약은 다른 결과다.
기존 단위 시험도 typed reservation 호출 한 번의 queued 결과가 publicationVerified 거짓인 상태를 유지하는지 확인한다. 이 글은 구현과 기존 시험을 읽었고 실제 새 예약을 만들지 않았다. 시간 계산을 설명하기 위해 원래 사용자의 일정과 업체 자료를 재발행하지 않는다. 준비와 실행, 서비스 결과를 각각의 근거로 남긴다.
필요한 시간만 묻고 남은 조건을 드러낸다
사람에게 처음부터 모든 날짜와 내부 값을 묻게 하면 간단한 반복도 어려워진다. 반대로 편하게 만들겠다고 필요한 일정을 추정하면 원치 않는 시각에 공개될 수 있다. 나는 날짜가 필요한 업무에서만 그 의미를 분명히 묻고 실제 입력 목록으로 연결하는 쪽을 택했다.
회사 프로그램의 배치 시작과 청구 기준일, 고객에게 보이는 발송 시각도 서로 다를 수 있다. 시간을 한 칸으로 줄이는 것이 직관성은 아니다. 사용자가 어떤 시간이 어떤 결과를 바꾸는지 알 수 있어야 한다. 일정 입력을 나누는 일은 필드를 늘리기보다 업무의 시간을 정확히 설명하는 작업이었다.