월요일에만 참이 되던 함수
소셜 타래를 자동 발행하는 엔진에 is_devlog_day 라는 판정이 있었습니다. 오늘이 개발 블로그 글을 타래로 소개하는 날인지 정하는 함수인데, 조건은 한 줄이었습니다. 월요일이면 참, 아니면 거짓.
그 자체로는 문제가 없어 보였습니다. 일주일에 한 번, 블로그 소개 체인과 최근 글 한 편을 묶어 올린다. 리듬이 깔끔했습니다.
문제는 재고 쪽에 있었습니다. 소개할 글이 33편 쌓여 있었고, 최근글 자리는 하루에 하나였습니다. 주 1회 노출이면 33편이 한 바퀴 도는 데 33주가 걸립니다. 반년을 훌쩍 넘깁니다.
당신의 자동 발행 파이프라인에서, 재고가 한 바퀴 도는 데 몇 주가 걸리는지 계산해본 적이 있으신가요?
병목은 로직이 아니라 달력이었다
로테이션 자체는 멀쩡했습니다. 최근글은 날짜를 시드로 돌아가니 같은 월요일이라도 매주 다른 글이 나옵니다. 로직에 오류는 없었습니다. 그래서 더 늦게 눈에 띄었습니다.
병목은 함수가 참을 돌려주는 빈도였습니다. 일주일에 하루만 참이면, 로테이션이 아무리 잘 섞여도 노출 속도는 그 하루에 묶입니다. 재고가 늘수록 꼬리는 길어지는데, 꼬리가 길어지고 있다는 사실을 알려주는 지표는 어디에도 없었습니다. 글은 쓰는 족족 재고에 들어가고, 재고는 주 1편씩만 빠져나갔습니다.
당신이라면?
당신이라면 매일 참으로 바꾸시겠습니까, 아니면 요일을 하나만 더 추가하시겠습니까?
월요일과 목요일, 역할은 다르게
저는 하루를 더 추가하는 쪽을 골랐습니다. is_devlog_day 를 월요일과 목요일에 참이 되도록 바꿨습니다.
다만 같은 포맷을 두 번 돌리지는 않았습니다. 월요일은 기존대로 소개 체인과 최근글을 묶고, 목요일은 최근글 한 편만 올립니다. 소개 체인을 주 2회 반복하면 같은 설명을 두 번 보는 셈이라, 목요일은 단건으로 뺐습니다.
최근글이 날짜 시드 로테이션이라는 점이 여기서 도움이 됐습니다. 월요일과 목요일은 시드가 다르니 두 날에 서로 다른 글이 나옵니다. 요일별 로테이션을 따로 만들 필요가 없었습니다.
33주짜리 꼬리는 절반으로 줄었습니다. 바뀐 것은 두 파일, 18줄 추가에 4줄 삭제입니다. 요일 판정과 목요일 단건 분기에 테스트를 붙였습니다.
자가진단 체크리스트
- 자동 발행 재고 수를 주당 노출 횟수로 나눠본 적이 있습니까?
- 요일 판정 함수가 참을 돌려주는 날을 늘리면, 같은 포맷이 반복되는 날이 생기지 않습니까?
- 로테이션 시드가 날짜라면, 추가한 요일이 기존 요일과 다른 항목을 뽑는지 확인하는 테스트가 있습니까?
솔직한 부분
주 2회가 맞는 빈도인지는 모릅니다. 매일 참으로 바꾸는 선택지도 있었지만 그 비교는 하지 않았습니다. 목요일 단건 노출이 월요일 묶음보다 반응이 좋은지 나쁜지도 데이터가 없습니다. 33편을 반 바퀴 더 빨리 돌리고 나면 다시 처음으로 돌아가는데, 그때 재고가 몇 편인지에 따라 이 숫자는 또 바뀝니다. 지금 확실한 것은 꼬리가 절반이 됐다는 산수뿐입니다.