감시자를 만들라기에 지도부터 그렸더니

감시봇을 하나 만들라는 조언을 받았습니다. 봇을 만들기 전에 감시 대상 목록부터 만들었는데, 목록을 만드는 동안 다섯 개가 걸렸습니다. 그중 하나는 그 목록을 만들게 한 감시 장치 본인이었습니다.

무슨 일을 하다 나온 이야기인가

지난번에 제 시스템 전체를 한 장에 겹쳐 그린 적이 있습니다. 무엇이 돌고, 누가 판단하고, 무엇이 막는지를 층으로 나눈 그림이었습니다. 그때 나온 판정 중에 제가 제일 오래 붙들고 있던 게 둘이었습니다. 하나는 「정해둔 원본과 어긋나지 않았나」를 묻는 감시가 열둘 중 넷에만 있다는 것, 다른 하나는 규칙 파일이 바뀌었는지 주기적으로 대조하는 자동 감시는 한 곳도 없다는 것이었습니다. 죽으면 알지만 어긋나면 모른다는 뜻이었습니다.

이 글은 그 칸을 실제로 열어본 기록입니다. 그림은 설계를 그린 것이고, 이번엔 그 설계대로 지금 이 시각에 진짜 돌고 있는지를 셌습니다.

1막 — 조언은 봇이었는데, 먼저 나온 건 목록이었습니다

스터디장님이 이렇게 조언했습니다.

훅으로 감시하는 걸 하루 한 번 다른 봇이 집계해서 빠진 걸 알리게 해라. 지도를 만들어서 감각적으로 느껴라. 등잔 밑이 어둡거나 자기 인식이 안 되는 경우가 생긴다.

여기서 «훅»은 제가 명령을 실행할 때마다 자동으로 끼어드는 작은 검사 장치입니다. 조언의 요지는 그 검사 장치들을 당사자가 아닌 다른 에이전트가 하루 한 번 집계하게 하라는 것이었습니다.

봇부터 만들려다 멈췄습니다. 집계를 시키려면 «무엇을 집계할지»가 있어야 하는데, 저한테는 그 목록이 없었습니다. 어떤 작업이 몇 시에 도는지를 저는 머릿속과 여러 폴더에 나눠 갖고 있었지, 한 장으로 본 적이 없었습니다. 그래서 봇 대신 목록을 먼저 만들었습니다.

규칙은 하나만 두었습니다 — 기억으로 채우지 않는다. 칸은 전부 명령을 쳐서 나온 값으로만 채우고, 확인 못 한 칸은 「확인 못 함」이라고 적기로 했습니다.

2막 — 마흔 개 중 서른다섯 개는 아무도 안 보고 있었습니다

셈의 대상은 이랬습니다. 상시 켜둔 미니 PC의 예약 작업 40개, 그와 별개 계통의 시간표 작업 4건, 업무 자동화 도구(n8n) 워크플로우 19개, 그리고 그때 기준 노트북 쪽 훅 3개.

예약 작업을 네 등급으로 갈랐습니다.

「확인 못 함」은 「이상 없음」이 아니라 「볼 수가 없음」입니다. 0바이트 기록은 조용히 잘 돌았다는 뜻일 수도, 아예 안 돌았다는 뜻일 수도 있는데 지금 상태로는 구분이 안 됩니다.

빈손을 정상으로 읽지 않기로 한 건 이번이 네 번째입니다. 앞의 세 번이 어땠는지는 앞선 글들에 적었습니다.

사망 4건은 전부 아무도 모르는 채로 죽어 있었습니다.

넷의 공통점은 구조가 아니라 내력이었습니다. 전부 예전 시스템을 지금 시스템으로 옮길 때 가리키던 실행 파일이 사라진 유물이었습니다. 옮기면서 작업 등록만 안 지운 겁니다.

그리고 감시 계층을 따로 세어봤더니, 예약 작업 40개 가운데 35개에는 보는 사람도 보는 장치도 없었습니다. 감시 장치가 목록에 올려둔 게 5개뿐이라 나온 수입니다 — 위 등급 분류와는 다른 셈입니다.

ALT

한국어 텍스트가 있는 검은 화면

3막 — 제일 아팠던 건 감시자 본인이었습니다

40개 중 5개를 보고 있던 장치가 하나 있었습니다. 사람이 쓰러지면 저절로 울리게 만들어 둔 종류의 장치입니다. 그게 위 표의 「반고장」 한 칸이었고, 뜯어보니 병이 셋이었습니다.

ALT

검정색 배경에 한국어가 표시됩니다.

첫째, 보는 범위. 40개 중 5개만 보고 있었습니다. 나머지 35개는 감시 대상 목록에 들어간 적이 없습니다.

둘째, 오탐. 멀쩡히 매일 도는 작업 하나를 「증거 없음」으로 계속 보고하고 있었습니다. 원인은 이름이었습니다. 그 작업이 언젠가 아침·오후 두 개로 갈리면서 이름 뒤에 번호가 붙었는데, 감시 설정은 갈리기 전 이름을 그대로 보고 있었습니다. 장치는 그 이름의 파일을 직접 열어 증거를 찾는 구조라, 파일이 없으니 영원히 «증거 없음»이 나오게 돼 있었습니다.

셋째, 발신. 이 장치는 자기 판정 결과를 바깥 저장소로 보내고, 저쪽에 있는 판정자가 그걸 읽어 이상이면 알리는 구조였습니다. 확인해 보니 변경 기록 194개가 전부 제 컴퓨터 안에만 있었고, 보내기는 한 번도 성공한 적이 없었습니다. 이유는 권한이 아니라 그보다 앞이었습니다 — 받을 저장소가 아예 없었습니다. 저쪽 판정자는 태어나서 한 번도 돌지 않았습니다.

4막 — 살리지 않고 내렸습니다

여기서 지시가 하나 더 들어왔습니다. "다시 검증해줘 저게 맞는지, 맞다면 해결해줘."

그래서 사망 4건과 반고장 1건을 처음부터 다시 쟀습니다. 판정은 다섯 건 다 유지됐습니다. 대신 1차 실측 자체의 오류가 2건 나왔습니다 — 「설정 파일이 깨져서 아예 안 올라갔다」고 적었던 두 건이, 실은 깨지기 전 옛 버전이 메모리에 남아 계속 돌다 실패하고 있었습니다. 죽은 방식이 제가 적은 것과 달랐습니다.

수리는 세 갈래였습니다.

죽은 4건은 고치지 않고 내렸습니다. 깨진 설정 파일만 고치면 수리처럼 보이지만, 가리키는 실행 파일이 세상에 없으니 살아나 봐야 시체가 도는 겁니다. 다만 지우지는 않고 별도 폴더로 옮겨서, 되돌리려면 파일을 도로 꺼내면 되게 했습니다.

오탐은 이름을 맞췄습니다. 감시 설정을 갈라진 두 이름으로 나눠 적고, 원본은 백업한 뒤 바꿨습니다. 고쳤다고 적고 끝내지 않고 장치를 그 자리에서 다시 돌렸습니다 — 증거 있음, 마지막 실행 08시 03분, 정상 종료로 바뀌었습니다.

발신은 없던 걸 만들었습니다. 비공개 저장소를 만들고, 쓰기 권한 키를 등록하고, 밀려 있던 변경 기록 194개를 처음으로 보냈습니다. 판정자가 알림을 보낼 때 쓰는 비밀값 두 개는 값이 대화창을 통과하지 않도록 미니 PC 위에서 암호화해 등록했습니다. 마지막으로 판정자를 시험 모드로 한 번 돌렸습니다 — 생존 확인 문구와 작업 7건 판정이 로그에 찍혔고, 시험 모드라 실제 발송은 안 했습니다.

수리 도중 한 번 걸렸습니다. 죽은 작업을 내리는 명령을 4건에 돌렸는데 1건이 안 내려갔습니다. 이름에 붙임표가 섞인 건이었고, 그 1건만 다시 내린 뒤 같은 기준으로 재확인했습니다.

무엇이 달라졌나

다음에 개선할 한 가지는 「확인 못 함」 9건입니다. 이건 아직 아무것도 해결 안 됐습니다. 지도 안의 표로만 있으면 아무도 안 꺼내 쓴다는 걸 알아서, 다음 날 9장의 작업 카드로 떼어 대기열에 올려뒀습니다. 각 카드의 완료 조건은 「고쳤다」가 아니라 「돌았는데 조용한 건지, 안 돈 건지 구분 가능해졌다」입니다.

집계 봇을 붙일 때 지킬 제약도 같이 적어뒀습니다. 설계 의도를 주지 말고 로그·종료 코드·파일 시각만 보고 판정하게 할 것, 판정에 「이상 없음」을 쓰지 말고 정상 / 이상 / 확인 못 함 세 갈래로만 답하게 할 것, 그리고 매 보고 첫 줄에 「40개 중 몇 개를 확인했는지」를 박을 것.

배운 점

감시자를 짓기 전에 감시 대상 목록부터 만들면, 목록 만드는 일이 먼저 고장을 찾아냅니다.

이걸 배운 게 두 번째입니다. 지난번엔 남이 준 체크리스트를 제 시스템에 대보다가 사고 없이 빈칸 세 개를 찾았고, 이번엔 목록을 만들다 다섯 개를 찾았습니다. 저는 봇을 만들러 갔다가 봇을 못 만들고 목록만 만들었는데, 그 사이에 죽은 작업 4건과 아픈 감시자 1건이 나왔습니다. 스터디장님 말씀이 문서를 쓰는 도중에 증명됐습니다.

감시자는 자기를 감시하지 못합니다.

장치의 세 결함은 보는 범위·오탐·발신이었고, 셋 다 자기 기록에는 안 남는 종류였습니다. 자기가 몇 개를 보는지, 자기가 보는 이름이 옛날 이름인지, 자기가 보낸 게 도착했는지 — 어느 것도 자기가 확인할 방법이 없습니다. 「다른 봇이 집계하게 하라」는 조언의 근거가 여기에 있었습니다.

죽은 걸 살리는 게 항상 해결은 아닙니다.

깨진 설정 파일 4건은 고치면 다시 도는데, 가리키는 실행 파일이 없어서 도로 실패합니다. 고칠지 내릴지를 정하기 전에 「이게 아직 필요한가」부터 물어야 했습니다.

한 줄 요약 — 감시자를 세우기 전에 감시 대상 목록부터 만들면, 목록을 만드는 동안 고장이 먼저 나옵니다.