🎯 바쁘시면 이것만 읽어도 돼요
자동화가 실패하는 방식 중에 제일 안 걸리는 건 조용히 성공한 척하는 거였어요. 로그는 성공, 종료 코드는 0, 에러도 없는데 하는 일이 없었어요
규칙 문서에 하지 말라고 주석까지 달아뒀는데 클로드가 그대로 어겼어요. 문서는 부탁이지 차단이 아니더라고요
그래서 훅을 만들었더니 그 훅이 저를 세 번 막았어요. 오탐 잡는 게 절반이었어요
👀 이런 분들께 도움돼요
클로드한테 자동화 스크립트를 맡겨두고 잘 도는지는 확인 안 해보신 분
CLAUDE.md에 규칙을 잔뜩 써뒀는데 잘 안 지켜지는 것 같은 분
백업이나 예약 실행을 걸어두고 알림이 안 오니까 잘 되는 줄 알고 계신 분
AI가 내놓은 결과물을 어디까지 믿어야 하나 애매하신 분
😮 Before: 알림이 안 와서 잘 되는 줄 알았어요
집에 남는 노트북으로 개인 서버를 만드는 중이었어요. 원고를 어디서든 열려고 시작한 일이에요. 저는 콘텐츠 마케팅 디자이너면서 클로드랑 웹앱을 만들어 굴리는 바이브코딩 개발자고, 소설도 쓰거든요.
그 노트북에는 이미 오픈소스 AI 에이전트가 하나 살고 있었어요. 메신저로 말을 걸면 대답하고 심부름도 하는 비서예요. 그런데 얘가 죽어도 제가 알 방법이 없었어요. 말을 걸어봐야 아는 거죠.
그래서 클로드한테 감시 장치랑 백업 자동화를 만들게 했어요. 만들고 나서 며칠은 알림이 하나도 안 왔어요. 저는 그걸 잘 돌아가는 신호로 읽었고요.
✨ After: 알림이 안 온 게 아니라 아무 일도 안 하고 있었어요
확인해보니 백업은 컨테이너를 멈춰놓고 다시 안 켰고, 파일을 옮기는 작업은 91번 실행돼서 91번 다 정상 종료했는데 파일을 하나도 안 옮겼어요. 원인은 셋 다 달랐는데 증상이 똑같았어요. 했다고 말하는데 안 한 거요.
지금은 감시 장치가 실제 상태를 다시 확인하게 고쳤고, 규칙 위반은 훅이 기계적으로 막게 해뒀어요.
🛠️ 이번에 한 것 (배경 30초)
집에 남는 윈도우 노트북을 24시간 서버로 돌리는 중이에요. 인터넷에 포트를 열지 않고 VPN 안에서만 접근해요.
에이전트가 죽으면 자동으로 살리고 메신저로 알려주는 감시 장치
매일 새벽에 에이전트의 기억이랑 설정을 압축해서 다른 기계로 보내는 백업
원고 동기화용 데이터베이스 컨테이너
이 셋이 서로 안 밟게 묶는 정비 잠금
이번 글은 이걸 만드는 방법이 아니라, 만들어놓고 잘 되는 줄 알았던 기간에 대한 이야기예요.
🔨 과정: 성공했다는 말을 세 번 믿었어요
1️⃣ 감시하는 쪽을 감시당하는 쪽에 두면 안 되더라고요
처음에 제가 원한 건 두 가지였어요. 안 죽게 하는 것, 죽으면 알려주는 것.
이게 한 덩어리인 줄 알았는데 아니었어요. 앞의 것은 그 기계 안에서 하는 일이고, 뒤의 것은 그 기계 밖에서 해야 하는 일이더라고요. 감시 장치를 감시 대상과 같은 기계에 두면, 그 기계가 통째로 나갈 때 감시 장치도 같이 죽어서 아무 소식이 없어요. 제일 알아야 할 순간에 제일 조용해지는 거죠.
알림 채널도 에이전트가 쓰는 채널과 분리했어요. 에이전트가 죽었다는 알림을 에이전트가 읽는 곳에 보내면, 살아난 뒤에 그걸 제 지시로 읽을 수도 있으니까요.
2️⃣ 재기동 완료라고 찍고 컨테이너를 방치했어요
백업은 컨테이너를 잠깐 멈추고 파일을 복사한 다음 다시 켜는 순서였어요. 데이터베이스가 쓰는 중에 복사하면 깨진 사본이 나오니까요.
며칠 뒤 로그를 열어보니 이렇게 적혀 있었어요.
09:46:51 compose stop 실패: Container Stopping 09:47:53 게이트 웨이·컨테이너 재기동 완료
두 줄이 서로 안 맞아요. 앞에서 실패했다는데 뒤에서는 완료라고 해요.
원인은 도커가 진행 상황을 오류 통로로 내보낸다는 거였어요. 컨테이너를 멈추는 중이라는 정상 메시지를 파워셸이 예외로 받아버렸고, 그래서 멈추기가 실패로 기록됐어요. 다시 켜는 부분이 조건문 안에 있었는데 그 조건이 거짓이 돼서 통째로 건너뛰었고요. 그런데 완료 로그는 조건 밖에 있어서 그대로 찍혔어요.
컨테이너는 그 상태로 다섯 시간 죽어 있었어요. 감시 장치는 에이전트만 보고 있어서 못 잡았고요.
3️⃣ 😲 하이라이트: 91번 실행해서 91번 성공하고 아무것도 안 했어요
백업 파일을 받는 쪽은 맥이에요. 한 시간마다 받은 파일을 정해진 폴더로 옮기는 작업을 걸어뒀어요.
며칠 뒤 확인해보니 파일이 이틀째 그대로 쌓여 있었어요. 작업 상태를 열어보니 이랬어요.
실행 횟수 91회 마지막 종료 코드 0 에러 로그 비어 있음
91번 다 정상이었어요. 그런데 옮긴 파일은 0개였어요.
제 예상은 스크립트 버그였어요. 조건문을 잘못 짰거나 경로를 틀렸겠거니 했죠. 그래서 손으로 같은 스크립트를 돌려봤는데, 그때는 파일이 멀쩡히 옮겨졌어요. 같은 스크립트가 제가 돌리면 되고 예약 실행으로 돌면 안 되는 거예요.
원인은 맥의 권한 정책이었어요. 예약 실행으로 뜬 프로그램은 다운로드 폴더를 못 읽어요. 문제는 거부되는 방식이었어요. 권한 없음이라고 에러를 내는 게 아니라 폴더가 텅 빈 것처럼 보여요. 그러니까 스크립트 입장에서는 받을 파일이 없는 거고, 할 일이 없으니 정상 종료하는 거예요.
이게 제일 무서운 종류라고 느꼈어요. 앞의 경우는 로그를 자세히 보면 앞뒤가 안 맞는 게 보이는데, 이건 로그가 완벽하게 정상이거든요. 실패한 흔적이 어디에도 없어요.
그리고 이 방식이면 실패했다는 걸 알 방법이 원리적으로 없어요. 알림은 문제가 생겨야 오는데 스크립트는 문제를 못 느끼고 있으니까요. 손으로 한 번 안 돌려봤으면 이틀이 아니라 몇 달도 그냥 갔을 거예요. 백업 파일이 쌓이는 걸 제가 눈으로 안 봤다면요.
고친 방법은 앱 형태의 실행기를 하나 거치는 거였어요. 그리고 이번엔 등록만 하고 끝내지 않고, 가짜 파일을 하나 만들어 넣고 실제로 집어가는 것까지 봤어요.
4️⃣ 하지 말라고 주석까지 달아뒀는데 그대로 어겼어요
여기까지가 로그가 남긴 말이었고, 이번엔 제가 남긴 말이 문제였어요.
이 작업 폴더에는 규칙 문서가 있어요. 그 안에 이런 줄이 있었어요.
포트를 모든 주소에 열지 말 것. 반드시 VPN 주소에만 바인딩
설정 파일에도 같은 경고를 주석으로 달아뒀어요. 그런데 클로드는 그걸 안 읽고 서버에서 설정을 새로 만들었고, 정확히 그 금지사항을 어겼어요. 이미 만들어둔 설정 파일이 있었다는 것도 나중에야 알았고요.
문서에 써두는 건 부탁이더라고요. 지켜지면 좋고, 안 지켜져도 아무 일도 안 일어나요.
그래서 훅을 만들었어요. 클로드가 명령을 실행하거나 파일을 쓰기 전에 가로채서, 금지된 설정이 들어 있으면 아예 막는 방식이에요. 이 작업 폴더에서만 걸리게 범위를 좁혔고요. 다른 프로젝트에서는 같은 설정이 정상일 수 있으니까요.
만들고 나서 바로 겪은 게 있어요. 훅을 설명하는 문서 를 쓰려는데 그 훅이 저를 막았어요. 금지된 명령 이름을 문서에 적었다는 이유로요. 시험용 데이터에 그 단어가 들어 있어서 또 막혔고, 문서를 다른 방식으로 쓰려다 또 막혔어요.
셋 다 오탐이었어요. 그래서 규칙을 좁혔어요. 설명하는 글은 검사하지 않고 실제로 실행되는 것만 본다. 금지 문자열이 들어 있다고 무조건 막지 말고 실제 설정 형태일 때만 막는다.
📊 결과
세 번 다 원인이 달랐는데, 얼마나 오래 몰랐는지랑 어떻게 들켰는지를 보면 성격이 비슷해요.
무엇
조용히 지나간 시간
들킨 계기
백업이 컨테이너를 안 켬
5시간
로그 두 줄이 서로 안 맞아서
파일 수거가 무동작
이틀 (91회 실행)
손으로 한 번 돌려봐서
규칙 문서 위반
사흘
워크스페이스 규칙을 뒤늦게 읽어서
셋 다 알림으로는 안 왔어요. 제가 열어봐서 알았어요.
훅은 12가지 상황으로 시험했고 전부 통과했어요. 그중 3가지가 오탐을 막는 케이스예요.
💡 효과적이었던 것
명령이 뱉은 글자로 성공을 판단하지 않고 종료 코드만 보게 바꾼 게 컸어요. 그리고 다시 켠 다음에 실제로 떠 있는지 한 번 더 확인하게 했어요. 로그에 완료라고 쓰는 것과 실제로 떠 있는 걸 확인하는 건 다른 일이더라고요.
조용히 끝나는 실행을 잡으려고 표식 파일을 하나 쓰게 한 것도 좋았어요. 작업을 시작할 때 표식을 남기고 끝날 때 지우는데, 다음 실행이 그 표식을 발견하면 지난번이 완료 없이 죽었다는 뜻이라 그때 알려줘요.
가짜 파일로 검증한 것도요. 등록만 하고 넘어갔으면 똑같은 일이 또 조용히 재발했을 거예요.
⚠️ 이런 건 아쉬웠어요
규칙 문서를 처음에 안 읽고 시작한 게 제일 아쉬워요. 클로드한테 읽으라고 시키지 않은 건 저고, 그 폴더에 이미 만들어둔 설정 파일이 있다는 것도 한참 뒤에 알았어요.
컨테이너를 한 번에 둘 올린 것도요. 제 규칙 문서에 하나씩 올리고 재부팅까지 견디는지 확인한 다음 넘 어가라고 적어놨는데 그걸 건너뛰었어요. 그 탓에 문제가 생겼을 때 어느 쪽 때문인지 가리는 데 시간이 더 걸렸어요.
감시 장치가 거짓 경고를 한 번 보낸 것도 아쉬워요. 도커가 재시작 중일 때 컨테이너가 다 죽은 걸로 오판했거든요. 그때 제가 처음 한 생각이 알림을 무시할까였어요. 오탐이 잦은 안전장치는 결국 꺼버리게 되니까, 막는 규칙을 만드는 일의 절반은 안 막아야 할 걸 안 막게 만드는 일이더라고요.
📋 따라하려면
자동화 스크립트에서 성공 판정을 어떻게 하는지 찾아보세요. 명령이 출력한 글자로 판단하고 있으면 종료 코드로 바꾸세요
무언가를 켜거나 껐다면, 그다음 줄에 실제로 그렇게 됐는지 확인하는 한 줄을 넣으세요. 로그 문구는 그 확인이 아니에요
작업 시작할 때 표식 파일을 남기고 끝낼 때 지우세요. 다음 실행이 그 표식을 발견하면 지난번이 조용히 죽은 거예요
등록만 하지 말고 가짜 입력을 하나 넣어서 실제로 반응하는지 보세요. 1분이면 돼요
규칙 문서에 적어둔 것 중에 기계가 판별할 수 있는 건 훅으로 옮기세요. 판단이 필요한 규칙은 훅으로 못 만드니까 그건 문서에 두고요
내 다음 목표
서버 자체는 아직 손볼 데가 남았어요. 컨테이너 설정을 원래 만들어뒀던 파일 기준으로 다시 짜야 하고, 하나씩 올려서 재부팅까지 견디는지 확인하는 절차도 건너뛰었거든요.
그리고 이 서버를 왜 클라우드 대신 집에 뒀는지, 백업을 왜 클라우드에 안 올리기로 했는지 같은 판단들이 쌓였는데, 그건 따로 한 편으로 정리해볼게요.
