내가 이름 붙인 것을, 내가 못 찾았다
분명히 내가 이름까지 붙인 아이디어였다. 그런데 막상 쓰려고 하니 통합뇌 어디에서도 찾을 수 없었다.
이름은 RPM이다. 회사 일에 쓰려고 지었다. 보고서를 위로 올려 본 사람은 안다. 내가 쓴 보고서는 팀장을 거치고 본부장을 거칠 때마다 짧아지고 정작 중요한 이야기는 그 사이 어딘가에서 빠진다. RPM은 그 빠지는 자리를 찾아보자는 틀이었다.
8월 마지막 날, 그 아이디어를 꺼내려고 통합뇌의 마크다운 파일 163개를 처음부터 끝까지 뒤졌다. 찾은 건 0건이었다. RPM만 다룬 파일은 하나도 없었다. 남은 건 목록 한쪽에 달린 세 줄 요약뿐이었다.
클로드 여섯 곳, 통합뇌 하나
1화 끝에 이런 뜻으로 적었다. 도구가 바뀌어도 버틸 수 있게 내 기억과 데이터는 내 디스크에 둔다고. 그게 내가 아는 유일한 대비책이라고.
그 문장을 실제로 만든 게 통합뇌다. 폴더 하나에 프로젝트 기록과, 무엇을 왜 정했는지, 어디서 실패했는지를 마크다운 파일로 쌓아 둔다. 통합뇌에 연결된 클로드는 대화를 시작할 때마다 이 폴더를 먼저 읽는다. 그래서 어제 노트북에서 정한 일을 오늘 집 PC에서 다시 설명할 필요가 없다.
내가 쓰는 클로드는 여섯 곳에 있다. 노트북의 클로드 코웍과 클로드 코드, 집 PC의 클로드 코웍과 클로드 코드, 늘 켜 둔 홈서버의 클로드 코드, 그리고 웹과 폰에서 여는 claude.ai다.
앞의 다섯은 통합뇌에 연결돼 같은 기억을 읽는다. claude.ai만 내 디스크를 볼 수 없다. claude.ai에서 나눈 이야기를 통합뇌에 남기려면 내가 직접 복사해 붙여 넣는 수밖에 없다. 그리고 RPM은 claude.ai에서 나왔다.
외근 가는 택시 안이었다. 보고서 자동화에 대한 생각이 떠올라서 폰으로 claude.ai를 열고 한참을 풀었다. 이동 중에 생각을 풀어 놓을 곳이 폰밖에 없었으니, 그 대화가 통합뇌 밖에 남은 건 당연했다.
세 줄 요약만 남은 아이디어
남은 세 줄은 이런 내용이었다. 회사에서 보고가 여러 단계를 거쳐 위로 올라가는 구조를 AI가 뒤집어 놓는다. 그러니 그 단계 사이 어딘가에 기회가 있다.
거기까지였다. 택시 안에서 나는 이 아이디어를 어디에 써먹을지 방향을 세 가지로 정리해 뒀다. 그런데 그 세 가지가 통합뇌 어디에도 없었다.
없다는 걸 확인한 순간 스트레스가 확 밀려왔다. 택시 안에서 이어 가던 생각을 처음부터 다시 쌓아야 한다고 생각했으니까. 남은 세 줄을 아무리 들여다봐도 “뭐였더라, 이게 무슨 이야기였지?” 소리만 나왔다.
반전은 이 글을 고치던 중에 왔다. claude.ai 대화 목록에서 검색해 보니, 택시 안에서 나눈 그 대화가 고스란히 남아 있었다.
대화는 그대로였다. 빠져 있던 건 내가 그 대화를 했다는 기억 쪽이었다. 아이디어까지 세워 놓고는 그 이야기를 했다는 사실조차 잊은 거다. 있는 줄 모르는 기록은 없는 기록과 똑같이 쓸모가 없다.
그달에 같은 일이 두 번 더 있었다
이런 일은 8월에만 세 번째였다. 앞의 두 번은 이랬다.
시작은 8월 23일의 윈도우 재설치였다. 홈서버를 파일 보존 방식으로 다시 깔았고 문서가 다 남아 있어서 마음을 놓았다. 그런데 남지 않은 게 있었다. 예약 작업들은 자동 실행 조건이 초기화된 상태였고 내가 따로 설치했던 파이썬도 함께 사라졌다. 그걸 나흘 동안 몰랐다.
집 대시보드는 앱과 자동화가 지금 몇 개 가동 중인지 한 화면에 모아 보여 주는 페이지다. 계기는 새 앱이었다. 하나를 더 만들었는데 대시보드의 앱 개수가 꿈쩍하지 않았다. 열어 보니 화면은 정상으로 뜨고 숫자와 표도 다 있었다. 다만 전부 작업이 멈추기 전의 숫자였다. 에러 화면도, 접속 오류도 없었다.
거꾸로 따라가 보니 데이터는 구글 드라이브까지는 제때 올라와 있었다. 멈춘 건 마지막 한 구간이었다. 드라이브에 있는 파일을 홈서버로 가져오는 예약 작업 하나.
같은 이유로 멈춘 작업이 두 개 더 있었다. 하나는 홈서버가 통합뇌 최신본을 받아 오는 작업이었다. 그동안 홈서버의 클로드는 지난 기억을 읽고 일했다. 다른 하나는 파이썬이 지워져서 멈춘 앱이었다. 앱 앞단의 로그인 확인 화면은 살아 있어서 브라우저로 열면 아무 문제 없어 보였다.
이번엔 원본이 아니라 사본이었다
그다음엔 반대 방향으로 한 번 더 헤맸다. 이번엔 스킬 파일이었다. 클로드가 일할 때 따르는 방법을 적어 둔 파일인데, 고쳐 놓아도 반영이 안 됐다. 고치고 저장하고 다시 물어도 클로드 코웍 대화는 옛 내용으로 답했다. 나는 파일이 저장되지 않는 줄 알았다.
원본은 멀쩡했다. 205줄짜리 최신본이 제자리에 있었다. 옛 내용을 들고 있던 건 그 코웍 대화였다. 대화가 시작될 때 파일을 한 번 복사해 두고 그 뒤로 줄곧 169줄짜리 사본을 보고 있었다. 대화 창을 새로 열었더니 그제야 고친 내용으로 답했다. 클로드 코드에서는 대화 중간에 스킬 파일을 고쳐도 반영된 적이 있다. 이번 일은 코웍 대화에서 생겼다.
“고쳤는데 안 바뀐다”면 원본보다 사본을 먼저 의심한다. 원본과 나 사이에 어느 시점의 사본을 들고 있는 단계가 하나라도 있으면 같은 일이 생길 수 있다. 그리고 나는 클로드를 여섯 곳에서 쓰고 있다.
셋 다 에러는 없었다
세 사건을 나란히 놓고 보니 모양이 같았다. claude.ai에 남은 대화는 여기 있다고, 멈춘 대시보드는 멈췄다고, 옛 사본은 낡았다고 알려 주지 않았다. 셋 다 에러가 나지 않았다. 원본은 셋 다 제자리에 멀쩡히 있었다. 문제는 원본과 나 사이의 한 단계였다. 그 단계가 멈췄거나, 오래된 사본을 내밀고 있었다.
자동화는 크게 두 가지 방식으로 실패한다. 시끄러운 실패는 빨간 화면이나 알림이 와서 그날 안에 고친다. 조용한 실패는 마지막으로 성공한 화면을 그대로 보여 주면서 내가 직접 들어가 확인할 때까지 아무 신호도 보내지 않는다.
8월 말에 세어 보니 앱 목록에 올라 있는 게 42개, 그중 가동 중인 게 29개였다. 개수가 늘면 하나씩 열어 보는 데 드는 시간도 는다. 못 열어 볼 정도는 아닌데, 어느 순간부터 안 열어 보게 된다. 앞으로도 계속 생길 종류의 일이라는 뜻이다.
그래서 감시기 하나, 규칙 하나
만든 건 두 가지다. 하나는 도구, 하나는 규칙이다.
도구는 감시기다. 예약 작업마다 “이 시간 안에는 성공했어야 한다”는 기한을 두고 기한이 지났는데 성공 기록이 없으면 그걸 실패로 친다. 아무 일도 일어나지 않은 상태를 사건으로 다루는 게 핵심이다. 그때까지 내 감시는 거의 전부 “에러가 나면 알려 줘”였는데, 재설치 뒤 멈춘 작업들은 하나같이 에러를 내지 않았다.
성공 기록을 위해 따로 만든 건 없다. 작업 스케줄러는 원래 작업마다 언제 마지막으로 실행됐는지와 결과가 어땠는지를 적어 두는데, 감시기는 그 두 값을 읽는다. 8월에 만든 감시기는 한 시간에 한 번, 아래 부록의 일곱 가지를 확인했다. 확인 결과가 직전과 달라졌을 때만 텔레그램 메시지를 보냈다. 다 만든 뒤에는 시험을 했다. 작업을 일부러 고장 내 알림이 오는지 보고 원래대로 돌려놓은 뒤 복구 알림까지 오는지 봤다.
감시기를 어디에 둘지도 정해야 했다. 감시기용 예약 작업을 따로 만들면, 재설치 한 번에 그 작업의 실행 조건도 같이 초기화된다. 그래서 바깥 서비스가 지켜보는 작업 안에 넣었다. 한 시간마다 실행되는 생존신호 작업인데, 이 작업이 제때 신호를 보내지 않으면 서버 바깥의 healthchecks.io 같은 서비스가 알림을 보낸다.
규칙은 한 줄이다. claude.ai에서 나온 건 그 자리에서 통합뇌로 옮긴다. 나중에 몰아서 정리하지 않는다. 그 나중은 오지 않는다는 걸 이번에 확인했다.
솔직히 말하면 규칙 쪽이 더 중요한데, 더 안 지켜질 거다. 감시기는 내가 잠든 새벽에도 혼자 확인을 이어 간다. 옮겨 적는 규칙은 그렇지 않다. 내가 기억하고 손을 움직여야만 지켜진다. 이 글을 쓰는 나도 다음에 창을 닫으면서 똑같이 놓칠 것 같다.
RPM은 당분간 미뤄 두기로 했다. 검증 안 된 개념을 돈 받는 일의 뼈대로 쓰면 위험하다. 그렇다고 개념을 버리지는 않았다.
세 줄짜리 요약은 8월 마지막 날 바로 파일 하나로 만들었다. 목록에도 올리고 어떻게 잃어버렸는지도 적어 뒀다. 대화를 찾은 다음에는 그 경위 기록도 다시 열었다. 잃어버린 사건이 아니라, 있는 줄 몰랐던 사건이라고 바로잡았다.
1화의 문장을 고쳐 쓴다
1화에서 나는 기억을 내 디스크에 두는 게 대비책이라고 했다. 8월을 지나고 보니 그 문장은 절반이었다. 디스크에 모아 두는 것 위에 하나가 더 있어야 했다.
디스크에 없다는 걸 알려 주는 장치.
기억을 모으는 일과, 뭔가 모이지 않았을 때 그걸 알아채는 일은 서로 다른 일이다. 나는 앞의 일만 해 왔고 뒤의 일은 8월에 처음으로 필요해졌다.
자동화를 늘려 본 사람은 아마 다 거치는 단계일 거다. 만드는 게 어려운 시기가 지나면, 만든 게 아직 작동하는지 알기 어려운 시기가 온다.
회사 일도 다르지 않았다. 회사에서 쓰는 봇 하나는 결과를 적는 시트 탭을 처음에 100줄로 만들어 뒀는데, 그 100줄이 다 차서 새 줄을 쓰지 못하고 있었다. 실패 메시지를 버리도록 짜여 있어서 경고 한 번 없었다. 8월 13일부터 분류를 기다리던 자료 47건이 그대로 멈춰 있었다(나중에 다시 넣었다). 알림이 오지 않는다고 잘 작동한다는 뜻은 아니었다.
홈 블로그 부록
감시 항목을 표로 풀고 명령 한 줄과 구조도 원본을 붙였다.
감시기 점검 항목 일곱 개 (2026년 8월 기준)
| 보는 것 | 이러면 알린다 |
|---|---|
| 등록 | 예약 작업이 목록에서 사라졌다 |
| 사용 여부 | 작업이 꺼져 있다 |
| 첫 실행 | 등록만 되고 한 번도 실행되지 않았다 |
| 마지막 실행 시각 | 정해진 간격보다 오래됐다 |
| 결과 코드 | 마지막 결과가 실패다 |
| 계속 실행돼야 하는 작업 | 멈춰 있다 |
| 응답 | 실행 중이라고 나오는데 응답이 없다 |
텔레그램 알림은 이 일곱 가지 가운데 상태가 달라진 것이 있을 때만 간다.
작업 스케줄러 기록을 직접 보는 명령
윈도우 PowerShell에서 아래 한 줄을 실행하면 예약 작업마다 마지막 실행 시각과 결과 코드가 나온다. 결과 코드가 0이면 성공이다. 우리 감시기도 이 두 값을 읽는다.
Get-ScheduledTask | Get-ScheduledTaskInfo | Select-Object TaskName, LastRunTime, LastTaskResult
0이 아닌 값이 다 실패는 아니다. 267009는 지금 실행 중, 267011은 아직 한 번도 실행되지 않았다는 뜻이다. 한 번도 실행되지 않은 작업은 마지막 실행 시각이 1999년 11월 30일로 나온다. 윈도우 기본 작업이 수백 개 섞여 나오니, 내가 만든 작업만 보려면 이렇게 거른다.
Get-ScheduledTask | Where-Object TaskPath -notlike '\Microsoft\*' | Get-ScheduledTaskInfo | Select-Object TaskName, LastRunTime, LastTaskResult
구조도 원본
이 글의 구조도 세 장은 SVG 원본으로 내려받을 수 있다.
다음 글에선
2화 끝에서 집 안 허브 세 개가 서로 말을 안 하던 이야기를 하겠다고 해 놓고 이번 글은 다른 데로 샜다. 8월에 이쪽 문제가 연달아 생겨서다.
허브 이야기는 다음 두 편에서 한다. 스위치는 한 회사 제품이고 센서는 일부가 다른 회사 제품이라, 둘 다 우리 집에 있으면서 서로를 몰랐다. 다음 글은 그 허브 셋을 Home Assistant 하나로 묶고 나서 달라진 우리 집의 하루이고 그다음 글은 묶는 데 들어간 주말 이야기다.
오늘은 여기까지. 읽다가 떠오른 생각이 있다면 지금 메모 앱에 한 줄 적어 두길. 나는 그 한 줄을 미뤘다가, 멀쩡히 남아 있던 대화를 잃어버린 줄 알았다.