최근 21일, 자동화 감시를 켜며 확인한 것

자동화는 켜는 일보다 상태를 믿지 않는 일이 더 어려웠습니다

최근 21일 동안 LifeCareLog에서는 랜딩 페이지의 작은 버그를 고치고, 여러 자동화 작업을 감시하는 흐름을 정리했습니다. 처음에는 감시 항목을 등록하면 상태도 곧바로 믿을 수 있을 것이라 생각했습니다. 실제로는 등록 시각, 초기 마커, 과거 오류 기록, 산출물 생성 여부를 분리해서 봐야 했습니다. 오늘은 그 과정에서 만든 것과 막힌 것, 아직 확인이 필요한 것을 기록합니다. 🔧

화면에 보이지 않는 흔적도 이유를 확인하고 정리했습니다.

만든 것: 랜딩 페이지 테마 스크립트의 불필요한 흔적을 제거했습니다

랜딩 페이지 테마 스크립트에는 실제 동작과 관계없는 이름 보존 도우미가 포함되어 있었습니다. 이 부분은 테마 전환 기능을 위한 코드처럼 보일 수 있지만, 현재 필요한 역할은 아니었습니다. 불필요한 코드를 제거해 스크립트가 맡는 책임을 조금 더 분명하게 만들었습니다.

작은 수정이지만, 랜딩 페이지는 처음 방문한 사람이 제품을 이해하는 표면입니다. 화면에 바로 보이지 않는 코드도 시간이 지나면 수정 범위를 헷갈리게 만들 수 있습니다. 앞으로도 기능과 관계없는 흔적은 발견할 때마다 이유를 확인하고 정리하려고 합니다.

확인한 것: 감시는 등록과 실행 결과를 같은 뜻으로 보지 않습니다

하네스 쪽에서는 auto-approve와 mkt-measure 감시를 활성화했습니다. launchd 등록 여부를 확인했고, mkt-measure는 014 적용도 함께 확인한 뒤 감시 대상으로 넣었습니다. 다만 등록된 시각이 첫 실행 성공을 뜻하지는 않습니다. 초기 마커는 등록 시각으로 남을 수 있으므로, 그 뒤 실제 산출물과 상태 변화를 따로 확인해야 합니다.

감시가 켜져 있다는 사실과, 자동화가 의도한 결과를 냈다는 사실은 다릅니다.

이 기준은 notify-outbox, backlog, blog-remix-select에도 적용했습니다. 이 항목들은 등록만으로 바로 활성화하지 않고, launchd 등록과 산출물 생성을 확인한 뒤 켜는 흐름으로 정리했습니다. 자동화가 조용히 실패할 때 가장 먼저 필요한 것은 새로운 기능보다 확인 가능한 흔적이라고 배웠습니다.

감시가 켜진 사실과 의도한 결과를 낸 사실은 다릅니다.

고친 것: 과거 오류 한 줄이 상태를 계속 DOWN으로 만들던 문제

리믹스 원장 감시에는 과거 error 한 줄이 남아 있으면 이후 상태가 계속 DOWN으로 보일 수 있는 문제가 있었습니다. 최근 성공 여부도 함께 읽도록 success 패턴을 추가했습니다. 오류 기록을 지우거나 감추는 방식이 아니라, 성공과 오류를 함께 판단할 수 있도록 기준을 보완한 것입니다.

이 작업은 상태 표시가 과거에 묶이지 않게 하려는 시도였습니다. 다만 success 패턴이 모든 실패 상황을 구분해 주는 것은 아닙니다. 성공으로 보이는 기록과 실제 게시·전달 결과가 일치하는지는 계속 별도로 확인해야 합니다.

아직 모르는 것: 감시의 신뢰도는 시간이 지나야 확인됩니다

distill-hermes에는 deadman 항목을 추가했습니다. 일정 시간 동안 기대한 신호가 없을 때 확인 대상으로 올리기 위한 장치입니다. 하지만 이 항목이 실제 장애를 충분히 빨리 알려 주는지, 정상적인 지연까지 불필요하게 경고하지 않는지는 아직 검증하지 못했습니다.

blog-draft-gen에는 devlog 초안이 사실 시트의 구체 수치 두 개 이상을 담도록 게이트를 추가했습니다. 초안이 추상적인 회고로만 흐르지 않게 하기 위한 기준입니다. 그렇다고 숫자가 많다고 원본성이 보장되는 것은 아닙니다. 숫자의 출처와 맥락, 실제 작업과의 연결을 함께 확인해야 합니다. 📜

끝냈다는 말보다 무엇을 근거로 판단했는지를 나눠 적었습니다.

다음 확인 행동

• 각 감시 항목이 등록 이후 실제 산출물을 남겼는지 확인합니다.
• 초기 마커와 첫 성공 기록을 분리해 읽을 수 있는지 점검합니다.
• success 패턴 추가 뒤에도 실제 실패가 DOWN 상태로 남는지 확인합니다.
• devlog 초안의 수치가 사실 시트와 정확히 연결되는지 검토합니다.

혼자 제품과 자동화를 함께 운영하면, 일을 끝냈다는 말보다 무엇을 근거로 끝났다고 판단했는지가 더 중요해집니다. 이번에는 감시를 더 많이 붙이는 일보다 상태를 섣불리 믿지 않는 기준을 만들었습니다. 여러분은 반복 작업의 성공 여부를 어떤 기록으로 확인하고 있나요?