같은 영상이 여섯 번 올라간 이유: 기록을 먼저 남기고, 죽은 것만 살리고, 근거 약한 추정은 철회한 하루

3줄 요약

• 무슨 작업: 같은 영상이 여섯 번 업로드된 사고와 감시 프로그램이 서버를 수백 개 쌓아 둔 사고를 고쳤고, 주력 채널의 첫 롱폼을 공개한 뒤 부진 원인에 대한 내 추정을 데이터로 다시 확인해 철회했다.
• 왜 중요: 두 사고 모두 코드가 틀려서가 아니라 "언제 기록하나"와 "무엇을 다시 띄우나"를 잘못 정해서 생겼다. 자동화에서 가장 흔하고 가장 조용한 실패 유형이다.
• 빌더에게의 의미: 두 번 일어나면 안 되는 일은 하자마자 기록하고, 복구는 죽은 부품만 한다. 그리고 그럴듯한 가설은 규칙으로 만들기 전에 반례부터 찾는다.

기록은 위험한 단계보다 먼저 와야 한다

같은 영상이 여섯 번 올라간 원인은 업로드 성공 기록을 마지막 단계 뒤에 두었기 때문이다.

업로드 스크립트는 영상을 올리고, 썸네일을 붙이고, 마지막에 "올렸음"을 기록하는 순서였다. 그런데 썸네일 단계가 하루 사용 한도에 걸려 실패하면서 스크립트가 거기서 멈췄다. 영상은 이미 올라갔는데 기록은 남지 않았다. 두 시간마다 도는 다음 회차는 기록이 없으니 "아직 안 올렸다"고 판단하고 또 올렸다. 그게 여섯 번 반복됐다.

정리는 이렇게 했다.

• 기록이 남아 있던 한 편만 예약을 유지하고 나머지 다섯 편은 삭제
• 순서를 바꿔 업로드 직후 곧바로 기록하고, 썸네일은 실패해도 되는 선택 단계로 분리
• 앞으로 쓸 업로드 스크립트는 고친 판에서만 복사하도록 기준 파일을 정함

핵심은 단계마다 무게가 다르다는 점이다. 영상 업로드는 되돌리기 어렵고, 썸네일은 나중에 다시 붙이면 그만이다. 되돌리기 어려운 일이 끝난 순간이 기록할 순간이다.

감시자는 죽은 것만 다시 살려야 한다

대시보드 감시 프로그램이 30분마다 서버를 하나씩 더 띄워서 사흘 만에 284개가 쌓여 있었다.

감시 프로그램은 데이터 수집기가 안 보이면 묶음 전체를 다시 실행하게 되어 있었다. 수집기만 죽었는데 멀쩡히 돌던 웹 서버까지 새로 띄웠고, 옛 서버는 그대로 남았다. 수집기가 왜 죽었는지도 따로 봤다. 창 없이 실행되는 환경에서는 오류 출력 통로가 없어서 첫 오류를 기록하려는 순간 그 자체로 다시 오류가 났다.

그래서 두 가지를 고쳤다. 수집기가 오류를 파일에 쓰게 했고, 감시 프로그램은 수집기만 다시 띄우도록 범위를 좁혔다. 중복 280개는 가장 오래된 것만 남기고 정리했다. 감시는 "무엇이 살아 있어야 하나"를 부품 단위로 알고 있어야 한다. 묶음 단위로 알면 복구가 곧 누수가 된다.

그럴듯한 가설은 규칙이 되기 전에 철회했다

주력 채널의 첫 롱폼을 공개한 날, 같은 사연을 담은 쇼츠 한 편이 노출을 거의 받지 못했다.

처음엔 이렇게 추정했다. 롱폼에 그 사연이 먼저 들어갔고, 유튜브가 뒤에 나온 쇼츠를 중복으로 보고 퍼뜨리지 않았다. 그래서 "롱폼에는 공개 후 사흘 지난 쇼츠만 묶는다"는 규칙까지 제안했다. 그런데 반례가 바로 있었다. 같은 롱폼에 들어간 다른 쇼츠는 정상으로 퍼지고 있었고, 유튜브는 오히려 롱폼을 쇼츠로 잘라 올리기를 권한다. 본 사람은 전부 끝까지 봤으니 시청자가 넘겨 버린 것도 아니었다. 그날 안에 추정과 규칙을 둘 다 거둬들이고, 이틀 뒤 숫자를 다시 보기로 했다.

롱폼 자체도 노출이 검색 몇 번뿐이었다. 쇼츠만 하던 채널이라 롱폼을 추천할 기존 시청자가 아직 없다고 보고, 잘 퍼지는 쇼츠 여덟 편 전부에서 롱폼으로 가는 연결을 걸었다. 제목과 썸네일은 A/B 테스트 중이라 건드리지 않는다.

같은 날 아동 동화 채널에서는 반대 판단을 했다. 인트로를 뺀 판으로 교체하려던 편이 하루도 안 돼 채널 최고 조회를 넘기자 교체를 취소했다. 새로 올리면 쌓인 추천 흐름이 처음부터 다시 시작된다. 고치는 것보다 지키는 게 나은 때도 있다.

오늘 배운 것

자동화든 판단이든 실패는 순서와 범위에서 난다. 기록은 되돌리기 어려운 일 바로 뒤에, 복구는 죽은 부품에만, 규칙은 반례를 찾아본 뒤에. 세 가지 모두 하나를 묻는다. 지금 하려는 일이 정확히 어디까지 영향을 주는가.