maintenance day는 시작하기도 전에 실패할 수 있다. backlog는 길고, 하나하나 다 그럴듯해 보이고, 막상 손대기 시작하면 목록은 더 길어진다. maintenance라고 부르지만 실제로는 범위 붕괴가 일어난다. 다 건드리려다 보니 아무것도 제대로 보호하지 못하는 상태다.

이건 maintenance-only day에 무엇부터 고쳐야 하는가 다음에 남는 문제다. 우선순위를 정해도, 무엇을 일부러 안 할지 정하지 않으면 하루는 다시 무거워진다.

1. 많은 사람이 maintenance backlog의 모든 항목을 도덕적으로 급한 일처럼 다룬다

1인 운영자는 maintenance 모드로 들어가면 backlog의 모든 항목이 오늘의 정당한 몫처럼 보이기 쉽다. 이것도 고쳐야 맞고, 저것도 정리해야 맞고, 저 항목도 미뤄둔 지 좀 됐다는 생각이 겹치면서 하루가 희석된다.

겉으로 보이는 문제는 “maintenance 목록이 너무 길다”다. 실제 문제는 목록에 제외 규칙이 없다는 데 있다. 적극적으로 빼는 기준이 없으면 maintenance는 하루를 다 먹고도 다음 발행을 여전히 무겁게 남긴다.

여기서 많은 1인 사이트가 묶인다. 작은 시각 버그, 메모 정리, 메타데이터 한 번 더 보기, 영향이 작은 설정 아이디어, 초안 조금 더 다듬기 같은 것들이 전부 비슷하게 합리적으로 보인다. 하지만 비용도 다르고, 오늘 꼭 필요한 정도도 다르다.

2. 라이브 피해가 없고, 반복 비용이 작고, 다음 발행을 막지 않으면 일단 미룬다

이 글의 핵심 기준은 단순하다. 지금 사용자에게 라이브 피해를 주지 않고, 앞으로의 발행 주기마다 반복적으로 시간을 빼앗지 않고, 다음 발행을 막지도 않는다면 오늘은 안 고쳐도 될 가능성이 크다.

라이브 사용자 피해가 없는가

방문자, 구독자, crawler가 오늘 직접 비용을 치르고 있지 않다면 긴급도는 내려간다. 내가 거슬린다는 것과 라이브 피해는 다르다.

반복 비용이 작은가

어떤 항목은 거슬리지만 거의 다시 안 나타난다. 반대로 어떤 항목은 매 발행마다 시간을 조금씩 빼앗는다. 반복되지 않는 귀찮음은 반복 마찰보다 더 쉽게 미룰 수 있다.

다음 발행을 막지 않는가

질문은 간단하다. 오늘 이걸 건너뛰면 다음 발행이 실제로 막히는가. 답이 아니라면, 오늘은 미뤄도 되는 후보일 수 있다.

나중에 묶는 게 더 싼가

일부 정리는 미래 배치에서 한꺼번에 처리하는 쪽이 더 싸다. dependency refresh, 스타일 다듬기, 메모 정리, 폴더 hygiene 같은 일은 오늘 maintenance 창구를 쪼개기보다 나중에 비슷한 일끼리 묶는 쪽이 효율적일 때가 많다.

3. 안 고쳐도 되는지 보기 전에 먼저 네 칸으로 나눈다

backlog가 끈적하게 느껴질수록, 각 항목을 네 질문으로 먼저 나눠보면 된다.

• 지금 라이브 사용자 피해가 있는가
• 이 문제가 매주 반복 마찰을 만드는가
• 오늘 무시하면 다음 발행이 막히는가
• 비슷한 작업과 나중에 묶는 편이 더 싼가

답 패턴이 `아니오, 아니오, 아니오, 예`에 가까우면 그 항목은 보통 명확한 “오늘 아님”이다. 가짜 일이란 뜻이 아니다. 오늘이 틀린 순간이라는 뜻이다.

4. 약한 maintenance 범위와 강한 maintenance 범위는 확실히 다르다

예를 들어 backlog에 stale analytics note 하나, 치명적이지 않은 모바일 spacing bug 하나, 깨진 RSS check 하나, 지저분한 image handoff note 하나, 반쯤 계획된 tag cleanup 하나가 있다고 해보자.

약한 maintenance 범위는 다섯 개를 전부 살아 있게 둔다. 하나하나 다 그럴듯해 보이기 때문이다. 그러면 하루는 흩어진 부분 정리의 합으로 끝난다.

더 강한 maintenance 범위는 다르다. analytics note와 spacing bug, tag cleanup은 오늘 제외하고, broken RSS check는 라이브 구조 문제라 남기고, image handoff note는 이번 주 다음 발행을 다시 늦출 경우에만 남긴다.

약한 maintenance 범위	강한 maintenance 범위
그럴듯한 일은 전부 살려둔다	안전한 미룸 후보를 적극적으로 뺀다
눈에 띈 것을 긴급도로 착각한다	라이브 피해와 미래 비용으로 거른다
곳곳에 부분 정리만 만든다	적은 수의 중요한 결과를 보호한다

다른 예시도 비슷하다. maintenance 중에 저트래픽 페이지 버튼 정렬 문제를 하나 발견했다고 해보자. 그 사실만으로 오늘 우선순위가 생기지는 않는다. 반대로 지난 발행의 feed나 verification 문제 하나가 아직 안 닫혔다면, 버튼 정렬은 거의 항상 오늘 안 해도 되는 일이다.

5. 이번 주에 안 고칠 것 프롬프트 하나만 둔다

복잡한 필터는 필요 없다. 아래 정도면 충분하다.

이 maintenance backlog를 보고 이번 주에 고치지 않아도 되는 항목을 골라줘. 지금 라이브 사용자 피해가 없고, 반복 비용이 작고, 다음 발행을 막지 않고, 나중에 비슷한 작업과 묶는 게 더 유리한 항목을 우선 미루게 해줘.

리스트가 여전히 무겁다면 한 줄만 더 붙이면 된다.

지금 사용자 피해를 막거나, 반복 운영 drag를 줄이거나, 다음 발행을 열어주는 일만 남기고 나머지는 뒤로 보내줘.

무엇부터 시작할까

오늘 maintenance를 시작하기 전에 backlog에서 세 개를 의도적으로 빼보자. 왜 지금 안 해도 안전한지 설명할 수 없다면, 아직 maintenance 범위가 너무 넓은 것이다.