54건이 밀린 줄 알았는데 3건이었다 — 점검 숫자를 두 갈래로 가르기

아침에 대시보드는 「지남·미발행 0」이었다

채널마다 무엇이 언제 나가야 하는지를 적어 둔 편성표가 있다. 대시보드는 그 표를 읽어 「오늘 몇 건」과 「날짜가 지났는데 안 나간 것 몇 건」을 보여 준다. 아침에 열었을 때 뒤쪽 숫자가 0이었다.

0은 좋은 숫자처럼 보인다. 밀린 게 없다는 뜻이니까. 그런데 같은 화면에 이상한 것이 하나 더 있었다. 어떤 채널의 「채움」이 0으로 찍혀 있었는데, 나는 전날 밤에 그 채널 편성을 35칸 채운 기억이 있었다.

두 숫자가 서로 다른 이야기를 하고 있었다. 하나는 「밀린 게 없다」고 하고, 하나는 「채운 적이 없다」고 한다. 둘 다 맞을 수는 없다.

숫자의 출처를 먼저 봤다

대시보드가 읽는 파일을 열었다. 안에 기준일이 적혀 있었고 그 값이 닷새 전이었다. 이 파일은 각 채널 폴더에 흩어진 편성표를 모아 만드는 생성물인데, 그 «모으는 일»을 닷새 동안 아무도 돌리지 않았다.

화면은 고장 나지 않았다. 닷새 전 사진을 정확하게 보여 주고 있었을 뿐이다. 「0건」은 «없다»가 아니라 «닷새 전에는 없었다»였다.

수집을 돌리자 0이 54가 됐다

모으는 명령을 한 번 돌렸다. 화면이 바뀌었다.

「채움」은 127에서 162로 올랐다. 전날 밤에 채운 35칸이 그제야 잡혔다. 「발행」은 1에서 3이 됐고, 문제의 「지남·미발행」은 0에서 54가 됐다.

54는 큰 숫자다. 하루 열한 칸이 나가는 편성이니 닷새면 쉰다섯 칸이다. 거의 전부가 밀렸다는 뜻으로 읽힌다. 그 순간의 반응은 「큰일 났다」에 가까웠다.

숫자가 커지면 판단이 멈춘다

이 반응 자체가 문제의 일부다. 밀린 것이 3건이면 「지금 하나 하고 두 개는 내일」이 된다. 54건이면 어디서 시작할지가 안 보이고, 그러면 대개 아무것도 시작하지 않는다. 숫자가 정확한지와 별개로, 행동을 만들어 내는 크기인지가 점검 화면의 조건이다.

그래서 큰 숫자가 나왔을 때 먼저 할 일은 「빨리 처리한다」가 아니라 「이 숫자가 정말 한 종류인가」를 묻는 것이다. 한 칸에 서로 다른 것이 섞여 있으면 총합은 아무 뜻이 없다.

그래서 54를 한 칸씩 열어 봤다.

54 안에 서로 다른 두 가지가 섞여 있었다

열어 보니 대부분이 이미 나간 글이었다. 블로그 RSS를 그대로 읽어 보면 같은 날 같은 제목이 라이브에 올라가 있다. 그런데 편성표의 상태 칸에는 여전히 「예정」이라고 적혀 있었다.

즉 「지남·미발행」이라는 한 칸에 두 가지가 함께 들어가 있었다.

표에서 보듯 화면에 뜬 문구는 셋 다 같은데 해야 할 일은 완전히 다르다. 첫 줄은 원고를 써야 하고, 둘째 줄은 한 글자만 고치면 되고, 셋째 줄은 아예 다른 작업이다.

라이브로 가른다

둘을 가르는 방법은 하나뿐이다. 기록끼리 비교하지 않고 «실제로 나간 것»을 본다. 블로그는 RSS가 있고, 자체 사이트는 글 목록 데이터가 있다. 그 둘을 날짜와 제목으로 맞춰 보면 「나갔다」와 「안 나갔다」가 갈린다.

맞춰 본 결과 실제로 안 나간 것은 3건이었다. 나머지는 나갔는데 상태를 안 고친 것이거나, 처음부터 편성이 비어 있던 칸이었다.

구체적으로는 이렇게 갈렸다. 블로그 한 곳은 닷새 치 네 편이 전부 정시에 나가 있었고 상태만 「예약」으로 남아 있었다. 다른 한 곳은 세 편 중 두 편이 나갔고 한 편이 정말 밀려 있었다. 자체 사이트는 사흘 치가 비어 있었는데 그중 하나는 소재가 이미 다른 날 나간 중복이라 애초에 낼 수 없는 칸이었다.

「밀렸다」로 한 덩어리였던 것이 이렇게 나뉘면 처리 방법이 각각 달라진다. 정시에 나간 네 편은 상태 문구만 고치면 끝이고, 중복 칸은 소재를 다시 정해야 하며, 진짜 밀린 한 편만 원고 작업이 필요하다.

이때 날짜로 맞추면 안 된다. 예약이 하루씩 밀려 나간 회차가 있어서, 날짜만 보면 멀쩡한 글이 「안 나감」으로 잡힌다. 제목으로 맞춰야 한다. 실제로 한 채널은 편성 순서와 발행 순서가 서로 어긋나 있었는데, 날짜로 맞췄다면 세 칸이 한꺼번에 틀렸을 것이다.

왜 기록이 갈렸나 — 두 벌을 두고 한 벌만 고쳤다

원인은 단순했다. 같은 편성 정보가 두 곳에 있었다. 하나는 대시보드가 쓰는 상세 기록이고, 하나는 각 채널 폴더에 있는 편성 파일이다.

글을 올린 뒤에는 앞쪽만 고쳐 왔다. 뒤쪽은 어느 날 «옮겨 둔» 뒤로 한 번도 갱신되지 않았다. 그런데 점검 숫자를 만드는 쪽은 뒤쪽이었다.

보기에는 둘 다 살아 있으니 어느 쪽이 정본인지 헷갈릴 일이 없어 보인다. 실제로는 고치는 쪽과 읽는 쪽이 달랐고, 그 사이가 벌어지는 동안 화면은 아무 경고도 하지 않았다.

두 벌은 반드시 낡는다

같은 사실을 두 곳에 적어 두면 언젠가 갈린다. 사람이 부지런해서 버티는 기간이 있을 뿐이다. 그래서 정리할 때 선택지는 둘이다. 한 벌로 합치거나, 둘을 맞추는 일을 코드가 하게 하거나.

이번에는 급한 대로 손으로 스물세 칸을 맞췄다. 다만 그렇게 하면 내일 또 갈린다는 것도 같이 적어 뒀다. 손으로 맞춘 것은 고친 게 아니라 미뤄 둔 것에 가깝다.

「같이 고쳤다」는 기록은 증거가 아니다

이번 정리 중에 한 가지가 더 나왔다. 며칠 전 기록에 「두 갈래를 같이 고쳤다」고 적혀 있었는데, 실제로 파일을 열어 보니 한쪽만 고쳐져 있었다. 적을 때는 고칠 생각이었고, 적은 뒤에 잊었을 것이다.

그래서 두 벌 구조에서는 «고쳤다는 기록»을 근거로 쓰지 않는 편이 안전하다. 확인이 필요하면 파일을 열어 값을 본다. 이건 의심이 아니라 비용 문제다 — 파일 하나 여는 데 몇 초, 틀린 전제로 하루를 가는 데는 몇 시간이 든다.

빈 칸까지 「밀렸다」로 세고 있었다

남은 34건을 다시 보면 또 한 가지가 나온다. 그중 상당수가 제목이 없는 칸이다. 편성을 아직 안 채운 자리다.

안 채운 칸은 「밀린 일」이 아니다. 「정할 일」이다. 그런데 점검 코드는 「날짜가 지났고 상태가 발행이 아니다」만 보기 때문에 빈 칸도 똑같이 셌다.

이건 숫자를 부풀리는 것으로 끝나지 않는다. 34건을 보면 사람이 아예 손을 안 대게 된다. 34는 하루에 처리할 수 있는 양이 아니니까. 반대로 「진짜 3건, 채울 칸 20개」로 나뉘어 있으면 둘 다 오늘 할 수 있는 일이 된다.

점검 화면의 목적은 «정확한 숫자»가 아니라 «다음 행동»이다. 한 숫자가 서로 다른 행동을 요구하는 항목을 합쳐서 보여 주면, 그 숫자는 커질수록 쓸모가 없어진다.

그래서 어디까지 고쳤나

이날 한 것은 셋이다.

첫 번째로 수집을 돌려 화면을 오늘로 맞췄다. 이게 없으면 나머지 판단이 전부 닷새 전 자료 위에서 이뤄진다.

두 번째로 라이브와 맞춰 23칸의 상태를 고쳤다. 제목으로 맞췄고, 제목이 바뀐 회차는 바뀐 제목까지 같이 반영했다. 이 과정에서 «어느 표에도 없는 글»이 한 편 나왔다. 편성이 보류되면서 대타로 나간 글인데, 편성표만 보면 존재하지 않는 글이다.

세 번째로 남은 것을 셋으로 갈라 적었다. 진짜 안 나간 3건, 사람 판단이 필요한 2건, 편성이 빈 칸들. 이렇게 갈라 두면 다음에 화면을 열었을 때 무엇부터 할지가 바로 보인다.

아직 안 한 것

점검 코드 자체는 아직 안 고쳤다. 지금도 빈 칸을 밀린 일로 세고, 상태 문구가 완료 표시로 시작하면 발행을 못 알아본다. 둘 다 한 줄짜리 수정이지만, 고치는 순간 숫자가 다시 움직이므로 하루치 기록을 더 쌓아 놓고 한 번에 바꾸는 편이 안전하다고 봤다.

그리고 두 벌을 맞추는 일은 여전히 손으로 한다. 이 부분이 다음 차례다.

이 점검이 잡아 주는 것과 못 잡는 것

잡아 주는 것은 «날짜가 지났는데 상태가 발행이 아닌 칸»이다. 이것만으로도 잊고 지나간 회차를 찾아내는 데는 충분하다. 이번에도 닷새 치가 한 번에 드러났다.

못 잡는 것은 세 가지다. 첫째, 편성 자체가 없는 채널은 아예 세지 않는다. 주기가 비어 있으면 「대상밖」으로 빠지기 때문에, 한 번도 안 나간 채널이 조용히 통과한다. 둘째, 나갔지만 내용이 잘못된 글은 통과한다. 상태가 「발행」이면 그걸로 끝이다. 셋째, 편성표에 없는 글은 존재하지 않는 것으로 취급된다.

셋째가 이번에 실제로 나왔다. 편성이 보류되면서 대타로 나간 글 한 편이 어느 표에도 없었다. 라이브에는 멀쩡히 올라가 있는데 점검 화면에서는 보이지 않는다. 「안 나간 것」을 찾는 도구는 「예정에 없이 나간 것」을 못 본다.

자주 묻는 것

점검 숫자가 0이면 안심해도 되나요?

0이 언제 기준인지를 먼저 봐야 합니다. 점검 결과가 파일로 저장되는 구조라면 그 파일에 «기준일」이 있을 텐데, 그 값이 오늘이 아니면 0은 오늘 이야기가 아닙니다. 이번 경우가 정확히 그랬고, 실제로는 닷새 전 숫자였습니다.

기록끼리 비교하면 안 되나요?

기록 두 벌이 서로 같다는 것은 «둘 다 맞다»를 뜻하지 않습니다. 둘 다 틀렸어도 완벽히 일치할 수 있습니다. 그래서 판정은 기록이 아니라 실제로 나간 것으로 해야 합니다. 블로그라면 RSS, 사이트라면 글 목록 데이터가 그 자리입니다.

왜 날짜가 아니라 제목으로 맞추나요?

예약이 하루 밀리거나 소재를 바꿔 내보내는 일이 생기면 «편성된 날짜»와 «실제 발행일»이 어긋납니다. 날짜로 맞추면 멀쩡히 나간 글이 누락으로 잡히고, 반대로 안 나간 칸이 통과합니다. 제목은 그 회차를 따라다니므로 이런 어긋남에 강합니다.

빈 칸을 그냥 지우면 숫자가 깨끗해지지 않나요?

깨끗해지지만 «모자란다»는 사실이 같이 사라집니다. 빈 칸은 아직 소재를 못 정했다는 기록이기도 합니다. 지우는 대신 세는 조건에 「제목이 있는가」를 넣어 «밀린 일»과 «정할 일»을 나누는 편이 낫습니다.

이런 점검을 얼마나 자주 돌려야 하나요?

돌리는 주기보다 «언제 돌아가는가»가 중요합니다. 부를 때만 도는 구조면 바쁜 날 건너뛰게 되고, 하필 그런 날 밀리기 시작합니다. 하루를 시작할 때나 마감 루틴처럼 이미 반복되는 자리에 붙여 두는 편이 안전합니다.