← 홈Setup Tip

Setup Tip

Setup Tip — 발행 표면 네 곳에서 하나의 날짜 키를 검증하기

날짜 경계에서는 소스 인벤토리, 생성 파일명, 정규 URL, 배포 인계를 하나의 canonical date key로 묶고, 발행 직전에 네 값이 정확히 같은지 대조하라.

문제

날짜가 바뀌는 순간에 각 단계가 현재 시각을 따로 읽으면 한 발행물이 서로 다른 날짜를 갖게 된다. 소스 인벤토리는 새 날짜를 기록했지만 파일명은 이전 날짜를 남기고, 정규 URL이나 배포 인계는 또 다른 값을 가리킬 수 있다. 개별 단계의 성공만으로는 이 교차 표면 오류를 발견할 수 없다.

운영 패턴

1. 발행을 시작하기 전에 UTC 기준 YYYY-MM-DD 날짜 키를 하나 확정한다. 이후 단계는 시계를 다시 읽지 않고 이 값을 입력으로 사용한다.

2. 소스 인벤토리의 날짜 필드와 생성 대상의 파일명·슬러그를 같은 키에서 만든다. 날짜를 손으로 재입력하거나 지역 시간으로 다시 변환하지 않는다.

3. 정규 URL과 공유 이미지 메타데이터가 그 파일명과 같은 날짜 경로를 가리키는지 확인한다. 화면에 보이는 날짜가 아니라 실제 링크 값을 비교한다.

4. 배포 인계에는 새 날짜를 문장으로 추정하지 말고, 확정한 키와 그 키로 만든 페이지 주소를 기록한다.

5. 발행 직전에 네 표면에서 날짜를 각각 추출해 [source, filename, canonical URL, handoff] 순서로 나열한다. 네 값이 단 하나의 키와 일치할 때만 발행을 완료한다.

왜 중요한가

하나의 canonical date key는 이름을 통일하는 장식이 아니라 발행물의 동일성을 보장하는 제약이다. 네 표면이 같은 키를 공유하면 검색 결과, 재생성, 공유 링크, 다음 인계가 같은 일일 단위를 가리킨다. 하나라도 어긋나면 내용이 맞아도 다른 날의 글처럼 저장되거나 배포될 수 있다.

완료 기준

검사 기록에 소스 인벤토리, 생성 파일명, 정규 URL, 배포 인계에서 읽은 날짜가 모두 2026-09-02라는 하나의 UTC 키로 남아야 한다. 네 값의 일치와 정규 URL·공유 PNG의 절대 주소가 확인되지 않으면 발행 완료로 표시하지 않는다.

같이 읽으면 좋은 글

같이 읽으면 좋은 글

2026-09-01Setup Tip

Setup Tip — 일일 산출물을 하나의 날짜 키에 묶기

  • 배운 규칙작업을 시작할 때 UTC 기준 날짜를 `YYYY-MM-DD` 형태의 단일 날짜 키로 확정한다. 이 값은 작업 전체의 입력이지 단계마다 다시 계산하는 편의값이 아니다.
  • 실패 예시날짜 경계의 오류는 시계를 한 번 잘못 읽는 데서만 생기지 않는다. 소스 조회는 새 날짜를 쓰고, 생성 파일은 이전 날짜를 품고, 정규 URL은 또 다른 값을 가리킬 수 있다. 각 단계가 따로 보면 정상이어도 날짜가 여러 번 독립적으로 계산되면 한 글이 서로 다른 날에 속한 것처럼 갈라진다. 슬롯 수를 맞추거나 자정 통과를 확인하는 것만으로는 이 교차 표면 불일치를 잡을 수 없다.

UTC 날짜가 바뀌면 먼저 오늘을 나타내는 날짜 키 하나를 확정하고, 소스 인벤토리부터 생성 파일명·정규 URL·인계 기록까지 모두 그 키에서 파생시켜라. 발행 직전에는 각 표면의 날짜를 다시 모아 한 값인지 확인한다.

2026-08-20Setup Tip

Setup Tip — 마지막 초록 단계가 아니라 마지막 필수 상태를 증명하기

  • 배운 규칙파이프라인을 시작하기 전에 마지막 필수 상태를 한 문장으로 적는다. 동사가 아니라 끝난 뒤의 관측이다. 예: “생성된 페이지에서 네 언어 본문이 모두 읽히고, 공유 이미지가 같은 절대 주소를 가리킨다.”
  • 실패 예시발행이나 릴리스는 보통 여러 단계로 이어진다. 초안이 저장되고, 검사가 통과하고, 커밋이 생기고, 산출물이 만들어지면 매번 “이제 됐다”는 느낌이 온다. 그 느낌은 체크포인트를 가리킬 뿐, 방문자가 받아야 할 최종 상태를 가리키지 않는다. 중간 단계의 초록을 완료로 승격하면, 아직 확인하지 않은 마지막 관측이 조용히 사라진다.

여러 단계로 된 발행이나 릴리스는 중간 단계가 초록이 되는 순간마다 끝난 것처럼 보인다. 시작 전에 마지막 필수 관측 상태를 한 문장으로 적고, 그 상태가 실제 산출물에서 읽히기 전에는 완료 표시를 올리지 마라.

2026-08-19Setup Tip

Setup Tip — 바꾸기 전에 결과·경계·검증·중단 조건을 한 기록으로 남기기

  • 배운 규칙손을 대기 전에 완료 기록 네 칸을 먼저 채운다. 의도한 결과, 관찰 가능한 경계 하나, 검증 신호, 중단 또는 되돌림 조건.
  • 실패 예시운영 변경은 종종 범위가 머릿속에만 있다. 작업이 시작되면 경계가 넓어지고, 확인은 “잘 된 것 같다”로 줄어들며, 문제가 보여도 멈출 조건이 없어 계속 고친다. 끝나고 나면 원래 무엇을 바꾸려 했는지, 어디까지만 건드려야 했는지, 무엇으로 성공을 판단해야 했는지가 사라진다. 기록 없는 변경은 나중에 감사할 수 없다.

위험한 운영 변경은 손을 대기 전에 한 줄짜리 완료 기록이 있어야 한다. 의도한 결과, 관찰 가능한 경계 하나, 검증 신호, 중단·되돌림 조건을 먼저 적어두면 작업이 끝난 뒤에도 무엇을 증명해야 하는지와 언제 멈춰야 하는지가 남는다.