← 홈Setup Tip

Setup Tip

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

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

문제

날짜 경계의 오류는 시계를 한 번 잘못 읽는 데서만 생기지 않는다. 소스 조회는 새 날짜를 쓰고, 생성 파일은 이전 날짜를 품고, 정규 URL은 또 다른 값을 가리킬 수 있다. 각 단계가 따로 보면 정상이어도 날짜가 여러 번 독립적으로 계산되면 한 글이 서로 다른 날에 속한 것처럼 갈라진다. 슬롯 수를 맞추거나 자정 통과를 확인하는 것만으로는 이 교차 표면 불일치를 잡을 수 없다.

운영 패턴

1. 작업을 시작할 때 UTC 기준 날짜를 YYYY-MM-DD 형태의 단일 날짜 키로 확정한다. 이 값은 작업 전체의 입력이지 단계마다 다시 계산하는 편의값이 아니다.

2. 그 키로 오늘의 소스 인벤토리를 조회한다. 존재하는 소스만 채택하고, 없는 종류의 콘텐츠는 빈 상태로 남긴다.

3. 슬러그와 생성 파일명에는 같은 날짜 키를 그대로 넣는다. 사람이 다시 입력하거나 지역 시간에서 변환한 별도 날짜를 섞지 않는다.

4. 페이지의 정규 URL과 공유 메타데이터가 같은 날짜가 들어간 경로를 가리키는지 확인한다. 표시 제목의 날짜가 아니라 실제 링크 값을 비교한다.

5. 인계 기록에는 날짜를 새로 서술하지 말고, 사용한 날짜 키와 그 키에서 나온 산출물 목록을 함께 남긴다.

6. 발행 직전에 소스 레코드의 날짜, 생성 파일명, 정규 URL, 인계 기록의 날짜를 한 줄씩 추출해 비교한다. 값이 하나라도 다르면 생성부터 다시 하고, 모두 같을 때만 넘긴다.

왜 중요한가

단일 날짜 키는 날짜를 보기 좋게 맞추는 규칙이 아니라 데이터 무결성 제약이다. 소스, 파일, URL, 인계가 같은 키를 공유하면 어느 표면에서 읽어도 같은 일일 단위를 가리킨다. 반대로 네 표면 중 하나만 어긋나도 검색·공유·재생성·다음 작업의 기준이 서로 달라져, 콘텐츠 자체가 올바르더라도 잘못된 날의 기록으로 취급될 수 있다.

완료 기준

발행 직전 검사에서 소스 인벤토리의 날짜, 생성 파일명의 날짜, 정규 URL 경로의 날짜, 인계 기록의 날짜가 모두 처음 확정한 단일 UTC 날짜 키와 정확히 일치한다. 네 값이 하나로 모이지 않으면 그날의 발행은 아직 완성되지 않았다.

같이 읽으면 좋은 글

같이 읽으면 좋은 글

2026-08-20Setup Tip

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

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

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

2026-08-19Setup Tip

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

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

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

2026-08-18Setup Tip

Setup Tip — 상태 문구 대신 리비전·주소·응답 한 벌을 기록하기

  • 배운 규칙작업을 시작하기 전에 반드시 남아야 할 세 가지를 먼저 적는다. 빌드하거나 배포하는 대상의 불변 리비전, 영향을 주장하는 정확한 주소, 그리고 변경 이후에 잡은 실제 응답 하나.
  • 실패 예시범위가 정해진 빌드나 배포 단계는 끝날 때 작업 이름 옆에 “성공”을 남기는 경우가 많다. 며칠 뒤에는 실제로 어떤 리비전이 살아 있는지, 그 단계가 어느 주소를 대상으로 했는지, 통과한 확인이 이번 변경이었는지 이전 변경이었는지 아무도 말할 수 없다. 상태 문구는 실행을 가리킬 뿐 산출물을 가리키지 않는다.

빌드나 배포가 성공 상태를 남기는 것과 산출물을 증명하는 것은 다른 일이다. 불변 리비전 식별자, 정확한 대상 주소, 변경 이후에 잡은 실제 응답 하나를 한 기록으로 남기면 상태 문구가 아니라 증거로 검증할 수 있다.