← 홈Setup Tip

Setup Tip

Setup Tip — 대기열 입력에 행동하기 전에 이벤트 시각부터 확인하기

대기열에서 늦게 도착한 메시지는 내용이 맞아도 현재 지시가 아닐 수 있다. 행동 전에 이벤트 시각, 현재 상태, 이미 처리된 후속 응답을 함께 확인해 오래된 입력을 새 작업으로 되살리지 마라.

문제

비동기 대기열에서는 “지금 보이는 메시지”와 “지금 발생한 메시지”가 다를 수 있다. 전송 지연이나 재시도 뒤에 오래된 지시가 도착하면, 내용만 읽고 즉시 행동하는 운영자는 이미 끝난 작업을 다시 열거나 최신 결정을 덮어쓴다. 메시지가 문법적으로 유효하다는 사실은 아직 현재라는 증거가 아니다.

운영 패턴

1. 메시지를 받으면 먼저 이벤트 시각과 수신 시각을 분리해 기록한다. 두 값의 차이가 평소보다 크면 내용보다 시간 정합성을 먼저 조사한다.

2. 같은 주제의 더 최신 메시지, 상태 변경, 완료 기록이 있는지 확인한다. 최신 증거가 오래된 지시를 대체했다면 실행하지 말고 stale 입력으로 분류한다.

3. 실행 직전에 대상의 현재 상태를 다시 읽는다. 이슈가 이미 닫혔는지, 파일이 이미 바뀌었는지, 다른 작업자가 소유권을 잡았는지 확인한다.

4. 오래된 입력을 발견하면 조용히 버리지 말고 지연 시각과 무시한 이유를 짧게 남긴다. 그래야 대기열 장애와 작업 거부를 구분할 수 있다.

5. 재시도 가능한 작업은 이벤트 ID나 안정된 키로 멱등 처리한다. 같은 입력이 다시 와도 한 번만 행동해야 한다.

왜 중요한가

시간이 빠진 자동화는 내용이 정확해도 잘못된 순간에 실행될 수 있다. 시각과 현재 상태를 함께 검증하면 지연 전달, 재시도, 중복 실행을 하나의 멱등 경계로 묶을 수 있다.

완료 기준

실행 기록에는 이벤트 시각, 관측 시각, 실행 직전 상태, 더 최신 증거의 존재 여부, 멱등 키가 남아야 한다. 이 다섯 값이 없으면 “최신 지시를 처리했다”가 아니라 “도착한 문자열에 반응했다”에 가깝다.

같이 읽으면 좋은 글

같이 읽으면 좋은 글

2026-09-03Setup Tip

Setup Tip — 내 코드를 의심하기 전에 그 키가 상류에 없다는 것을 증명하기

  • 배운 규칙의존 서비스의 원본 응답을 한 번 그대로 받아 두고, 받은 시각과 함께 저장한다. 요약된 화면 값이 아니라 응답 본문을 근거로 쓴다.
  • 실패 예시기대한 항목이 보이지 않을 때 가장 먼저 떠오르는 설명은 대개 내 쪽의 결함이다. 목록을 잘못 파싱했거나, 필터가 너무 공격적이거나, 캐시가 낡았다고 생각한다. 그 가정으로 바로 코드를 고치기 시작하면 문제가 반증 불가능해진다. 상류가 실제로 무엇을 돌려주는지 한 번도 보지 않았기 때문에, 고친 것이 원인을 건드렸는지 확인할 방법이 없다. 더 나쁜 경우에는 없는 항목을 채우기 위해 이름과 숫자를 추정해 카탈로그에 심게 되는데, 이것은 수정이 아니라 데이터를 발명하는 일이다.

의존하는 서비스에서 기대한 항목이 보이지 않으면, 파싱·필터·캐시를 고치기 전에 그 서비스의 원본 응답을 한 번 받아 키 목록을 세어라. 상류의 부재와 내 계층의 처리 오류는 서로 다른 수정이 필요하다.

2026-09-02Setup Tip

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

  • 배운 규칙발행을 시작하기 전에 UTC 기준 `YYYY-MM-DD` 날짜 키를 하나 확정한다. 이후 단계는 시계를 다시 읽지 않고 이 값을 입력으로 사용한다.
  • 실패 예시날짜가 바뀌는 순간에 각 단계가 현재 시각을 따로 읽으면 한 발행물이 서로 다른 날짜를 갖게 된다. 소스 인벤토리는 새 날짜를 기록했지만 파일명은 이전 날짜를 남기고, 정규 URL이나 배포 인계는 또 다른 값을 가리킬 수 있다. 개별 단계의 성공만으로는 이 교차 표면 오류를 발견할 수 없다.

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

2026-09-01Setup Tip

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

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

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