봇 34대가 전부 초록불이었습니다 — 그런데 한 대는 화면에 아예 없었습니다

오늘 아침에 한 일은 단순했습니다. 돌아가는 봇들이 실제로 도는지, 도는 결과가 무엇인지 중간점검했습니다.

감시판은 이미 있었습니다. exit 0이 거짓말한다는 걸 3주째 0편을 발행하던 봇에서 배운 뒤로, 상태코드 대신 산출물을 보는 화면을 만들어 뒀습니다. 각 봇이 마지막으로 만든 파일의 시각과 그 파일의 마지막 줄. 자체 계산 없음, 원장이 정본.

그 화면이 오늘 이렇게 나왔습니다.

33봇 — 정상 29 · 지연 1 · 정지 0

전부 초록불입니다. 여기서 점검을 끝냈으면 좋았을 텐데, 한 가지가 걸렸습니다. "33"이라는 숫자는 어디서 온 겁니까?

먼저 하나 물어보겠습니다. 당신의 모니터링 대시보드에 떠 있는 서비스 개수는, 실제로 돌고 있는 서비스 개수와 같다는 걸 확인해 본 적이 있습니까? 아니면 그 목록은 당신이 손으로 적어 넣은 것입니까?

33은 제가 손으로 적은 숫자였습니다

감시판의 목록은 파이썬 딕셔너리 리터럴입니다. 봇을 추가할 때 제가 한 줄 적어 넣습니다. 즉 감시판은 "실제로 도는 것"이 아니라 "내가 감시하겠다고 적어둔 것"만 봅니다. 등록을 빼먹으면 그 봇은 죽어도 화면이 초록불입니다 — 애초에 행이 없으니까요.

그래서 운영체제 쪽의 진짜 목록과 대조했습니다. macOS launchd에 등록된 잡을 뽑아 감시판 목록과 집합 연산으로 뺐습니다.

launchctl list | awk '{print $3}' | grep -E "^com\.(ootssu|user|jinnsim|tqqq|fngu|downfall|aftermath)" | sort > /tmp/jobs.txt
grep -o '("com\.[a-z.-]*"' hubdash/fleet.py | tr -d '("' | sort -u > /tmp/fleet.txt
comm -23 /tmp/jobs.txt /tmp/fleet.txt   # launchd에 있는데 감시판에 없는 것

9개가 나왔습니다. 그중 8개는 상시 떠 있는 대시보드 서버라 감시 대상이 아닙니다(그건 켜져 있으면 켜져 있는 겁니다). 남은 하나가 문제였습니다.

com.ootssu.game-track-report

게임 7종의 외부 유입을 주 1회 집계해서 리포트를 쓰는 봇입니다. 8월 27일 게이트의 판정 근거를 만드는 봇이 화면에 없었습니다. 이 봇이 지난주에 죽었어도 저는 27일 아침에야 알았을 겁니다. 판정 근거가 없다는 사실을, 판정하는 날에.

고치는 건 한 줄이었습니다.

("com.ootssu.game-track-report", "게임 트랙 리포트", 7 * D,
 "~/Documents/webApps/gori/docs/ops/*.md", "화 10:00 · 게임 7종 외부유입(게이트 08-27)", None),

산출물이 날짜 파일명이라 글롭으로 최신본을 잡습니다. 주기는 7일. 이제 8일이 지나면 지연, 17.5일이면 정지로 뜹니다. 셀프체크가 34봇 / 정상 30 · 지연 1 · 정지 0으로 바뀌었습니다.

지연 1건은 오탐이었습니다

같은 화면의 "지연"도 확인했습니다. 쓰레드 응대 봇이 20시간째 산출이 없었습니다. 로그 마지막 줄을 봤습니다.

[engage] 처리 0건(live=True).

답글 달 댓글이 하나도 없어서 JSONL에 새 줄이 안 붙은 겁니다. 봇은 정시에 깨서 정상 종료했습니다. "산출물이 없다"와 "할 일이 없었다"를 제 감시판이 구분하지 못합니다. 이건 아직 안 고쳤습니다 — 고치려면 봇이 "0건 처리함"을 산출물에 기록해야 하는데, 그건 봇 쪽 변경이라 오늘 범위 밖으로 뒀습니다. 알고 남겨둔 것과 모르고 놓친 것은 다릅니다.

무산출 3건(SNS 시간별 점검, 쓰레드 토큰 갱신, en 영상 게이트)도 확인 결과 설계상 파일을 안 만들거나 아직 실행일이 안 온 잡이었습니다.

여기까지가 "봇이 돈다"입니다. 이제 진짜 질문

파이프라인은 34대 중 34대가 살아 있습니다. 그럼 그 34대가 뭘 만들었습니까?

오늘 실측한 숫자를 그대로 적습니다.

매매 쪽도 같습니다. 페이퍼 봇 두 대는 동일예산 단순보유 대비 각각 −20.58%p, −30.21%p인데, 이건 실패가 아니라 설계입니다(예산 대부분을 현금으로 듭니다). 진짜 판정축인 낙폭 방어는 아직 시험 자체가 안 됐습니다 — 단순보유 최대낙폭이 6.19%, 기준은 30%입니다. 하락장이 안 왔으니 방어력은 성공도 실패도 아닌 무판정입니다. 게이트가 판정을 못 하는 상태를 1급 상태로 두는 이유가 이겁니다.

여기서 선택지가 갈립니다. 당신이라면 어느 쪽을 고치겠습니까?

1. 봇을 더 만든다 — 채널을 늘리고 발행량을 늘린다.
2. 봇을 더 잘 감시한다 — 오탐을 없애고 알림을 정교하게 만든다.
3. 봇이 만든 걸 아무도 안 본다는 사실 자체를 친다.

저는 지난 몇 달간 1번과 2번만 했습니다. 오늘 표를 보고 알았습니다. 1번과 2번은 둘 다 오른쪽 열을 안 건드립니다.

203편 만들고 구독 26

이 대비가 이 글의 전부입니다. 생산 능력은 이미 충분합니다 — 무인으로 하루 몇 편씩 나옵니다. 그런데 획득은 203편에 26명입니다. 영상 한 편당 구독자 0.13명.

이건 품질 문제일 수도 있고 유통 문제일 수도 있습니다. 구분하는 방법은 하나뿐입니다. 같은 콘텐츠를 이미 사람이 모여 있는 곳에 놓아 보는 것입니다. 만들어서 빈 채널에 올리는 것과, 만들어서 사람 있는 데 가져가는 것은 다른 작업입니다. 저는 전자만 자동화했습니다.

앱 48개를 만들고 한 달 클릭 8회를 받았을 때도 결론이 같았습니다. 만드는 쪽은 병목이 아니었습니다. 게임 7종을 배포하고 어디에도 링크가 없던 날도, SaaS를 하루 만에 짓고 하루 만에 접은 날도 같았습니다. 네 번 같은 벽을 만났으면 벽 쪽을 봐야 합니다.

자가진단 3개

당신 파이프라인에 그대로 대볼 수 있는 것만 적습니다.

1. 감시판의 서비스 개수를 손으로 세지 말고, 운영체제(또는 오케스트레이터)에서 뽑아 대조하십시오. comm -23으로 5초면 끝납니다. 목록이 사람 손으로 관리되는 순간 그 목록은 언젠가 틀립니다.
2. 각 봇의 "성공" 정의가 산출물에 기록되는지 확인하십시오. 할 일이 없어서 아무것도 안 한 것과, 죽어서 아무것도 못 한 것이 같은 모양으로 보이면 그건 감시가 아닙니다.
3. 대시보드 열에 "외부 결과"가 하나라도 있습니까? 발행 수·실행 성공률·업타임은 전부 왼쪽 열입니다. 매출·클릭·재방문 중 최소 하나가 같은 화면에 없으면, 당신은 초록불을 보며 0을 향해 정확하게 달릴 수 있습니다.

솔직한 부분

오늘 고친 건 한 줄입니다. 그 한 줄은 오른쪽 열을 1도 못 움직입니다. 감시 구멍을 막은 것뿐이고, 막힌 유통은 그대로입니다.

그리고 이 글 자체가 그 문제의 표본입니다. 이 글은 무인으로 배포되고 자동으로 타래가 붙고 영상이 만들어집니다 — 전부 왼쪽 열입니다. 이 글을 읽는 사람이 늘어나는지는 다음 달 숫자를 보고 다시 정직하게 적겠습니다.

지금 딱 하나만 해보십시오. 당신의 오케스트레이터에서 잡 목록을 뽑아 대시보드 목록과 diff 해보는 겁니다. 저는 거기서 판정 근거를 만드는 봇 한 대를 찾았습니다. 당신은 뭐가 나옵니까?