며칠째 꺼지지 않은 컴퓨터 한 대가 제 대신 일하고 있어요. 아침엔 브리핑을 만들고, 밤엔 백업을 돌리고, 저장소가 제대로 붙어 있는지 확인해요.
그런데 며칠을 굴려보고 나서야 알았어요. 제일 무서운 순간은 에러가 뜰 때가 아니라, 아무 일도 안 일어난 채로 조용할 때였어요.
에러는 그래도 신호를 줘요. 조용한 실패는 당장 눈에 띄는 알림을 주지 않을 수 있어요. 그래서 한참 뒤에 운영 기록을 대조하고 나서야 알게 됐어요.

이 글은 장비 추천 글이 아니에요. 다 읽고 나면 두 가지를 알 수 있어요. 내 자동화가 지금 살아 있는지 확인하는 세 가지 방법과 새 장비보다 먼저 준비해야 할 순서예요.
먼저 밝혀둘 게 있어요. 아래 운영 기록은 2026년 8월 5일 기준으로 제 환경 한 곳에서 관찰한 값이에요. 권장 설정이 아니라 한 사례고, 지금 정상이라는 게 지난 모든 실행이 정상이었다는 증거도 아니에요.
1. 24시간 에이전트는 채팅창이 아니라 작은 서비스예요
처음엔 저도 채팅창을 계속 열어두는 그림을 상상했어요. 실제로 해보니 훨씬 덜 낭만적이었어요. 작은 서비스 하나를 운영하는 일에 가까웠어요.
제가 사용한 OpenClaw 공식 문서에서는 예약 실행이 모델 안이 아니라 게이트웨이 프로세스 안에서 돌아요. 게이트웨이가 꺼져 있으면 시계도 같이 멈춰요. 작업 정의와 실행 이력은 재시작 뒤에도 남고, 실행마다 백그라운드 작업 기록이 하나씩 생겨요.
이 문장 하나가 제 그림을 바꿔놨어요. 모델이 똑똑해서 제때 움직이는 게 아니라, 실행 주체가 켜져 있어서 움직이는 거예요.

2. 첫 번째 벽 — 켜져 있는 자리
7월 초에 게이트웨이 쪽 서비스가 끊긴 뒤 여러 예약 작업의 실행 기록이 남지 않았어요. 되살린 뒤에는 순서대로 손으로 복구하고 하나씩 확인해야 했어요.
여기서 배운 게 하나 있어요. 게이트웨이가 멈춘 동안에는 예약 작업이 시작되지 않아 해당 실행 기록이 남지 않을 수 있어요. 조용한 게 위험한 이유가 이거예요.
제 환경에서는 재부팅 뒤 다시 시작하도록 운영체제의 상주 서비스로 등록해 뒀어요. 이건 제 맥 환경의 설정이라 모든 운영체제에 그대로 적용된다고 말하긴 어려워요. 각자 쓰는 환경에서 자동 시작과 자동 재시작을 어떻게 거는지는 따로 확인해야 해요.
3. 두 번째 벽 — 저장되지 않은 기억
“어제 그거 이어서 해줘”가 잘 안 되는 이유가 여기 있어요. 재시작 뒤에도 이어져야 할 기억은 디스크에 명시적으로 남겨야 해요. 알아서 유지되는 숨은 영구 상태는 없어요.
문서에 따르면 이 기억은 작업 폴더 안에 평문 마크다운으로 쌓여요. 사람이 직접 열어서 읽고 고칠 수 있다는 게 장점이에요. 평문이므로 비밀정보는 넣지 말고 파일 접근권한과 백업 범위도 확인해야 해요.
그런데 여기 반전이 하나 있어요. 기억은 맥락을 보존할 뿐 정책을 강제하지 않아요. 메모에 “이건 함부로 하지 마”라고 적어두는 건 강제되는 보안 경계가 아니라 모델이 참고하는 지침이에요.

4. 세 번째 벽 — 권한은 문장이 아니라 설정
보안 문서가 말하는 순서는 신원, 범위, 모델이에요. 누가 시켰는지 확인하고, 어디까지 되는지 정하고, 그다음이 모델이에요.
프롬프트에 “조심해”라고 써두는 건 단단한 경계가 아니에요. 실제 반경을 좁히는 건 도구 정책, 승인 절차, 격리 설정, 허용 목록이에요.
초보자용으로 한 문장으로 옮기면 이래요. 사람이 보지 않을 때 최악의 상황이 생겨도 감당할 수 있는 범위 안에만 무인 작업을 두는 거예요.

5. 가장 비싼 교훈 — 시작은 완료가 아니에요
여기가 이 글의 핵심이에요. 제가 겪은 네 가지 문제는 원인이 달랐지만, 모두 같은 착각으로 이어졌어요. 시작했으니 됐겠지, 에러가 없으니 됐겠지, 성공이라고 떠 있으니 됐겠지.
완료 이벤트는 왔는데 결과를 안 챙긴 경우
- 겉보기 — 작업 완료 이벤트가 정상적으로 도착했어요.
- 실제 — 뒤이어 결과물을 수거해 전달하는 단계가 실행되지 않았어요.
- 배운 것 — 작업을 시작했다는 사실도, 완료 이벤트가 왔다는 사실도 완료의 증거가 아니에요.
종료 코드는 0인데 목적지 파일은 옛날 것
- 겉보기 — 자동화가 오류 없이 정상 종료됐어요.
- 실제 — 목적지에는 중간 단계의 낡은 스냅샷이 남아 있었어요.
- 배운 것 — 작업 순서를 바로잡고 최종 결과가 일치하는지 바이트와 해시로 직접 대조해야 했어요.
상태는 성공인데 알림이 안 온 경우
- 겉보기 — 상태 텍스트는 성공이라고 떠 있었어요.
- 실제 — 정작 받아야 할 알림은 오지 않았어요.
- 배운 것 — 전달 상태를 ‘보냄, 대기, 실패’로 나누고 각각 근거를 확인해야 했어요.
자동 검사만 통과한 경우
- 겉보기 — 언어 품질 검사가 자동으로 통과했어요.
- 실제 — 실제 데이터에는 그 검사가 못 보는 사각지대가 있었어요.
- 배운 것 — 자동 통과만으로는 부족하고, 사람이 대표 샘플을 직접 봐야 했어요.
정직하게 하나 덧붙일게요. 지금 제 백업 상태는 정상이라고 떠 있어요. 그게 지난 모든 실행이 정상이었다는 증거는 아니에요.

6. 살아 있나? 3분 점검
사고를 겪을 때마다 같은 질문 세 개로 돌아왔어요. 도구가 뭐든 그대로 쓸 수 있게 일반화해서 정리했어요.
점검 1 — 지금 켜져 있나요?
저장된 기록이나 지난 대화 목록이 아니라, 지금 이 순간 상태를 직접 물어보는 방식으로 확인해요. 세션 목록에 뭔가 남아 있다고 살아 있는 게 아니에요.
실패 신호는 이거예요. “예약을 걸어뒀으니 됐겠지.”
점검 2 — 마지막으로 진짜 돌아간 게 언제인가요?
실행 이력을 열어서 공백이 있는지 확인해요. 며칠간 실행 기록이 비어 있다면 실제로 실행되지 않았는지, 기록 수집이나 조회에 문제가 있는지 함께 확인해요.
실패 신호는 이거예요. “에러 메시지가 없으니 잘 됐겠지.”
점검 3 — 결과가 도착지에 있나요?
완료 표시 말고 결과 자체를 확인해요. 파일이면 크기와 내용까지, 알림이면 실제로 받았는지까지 확인해야 해요.
실패 신호는 이거예요. “완료 알림 왔으니 됐겠지.”
이 세 질문은 실행 상태와 결과 도착을 확인하는 점검이에요. 무인으로 맡기기 전에는 앞서 본 권한 범위도 별도로 확인해야 해요. 실제로 실행되는지, 권한이 안전한지, 완료를 증명할 수 있는지 확인하세요. 하나라도 빠지면 아직 24시간 자동화가 아니라 예약 실행 실험 단계예요.

새 장비보다 먼저 채워야 할 순서
실행 자리를 마련하더라도 무인 예약에 연결하기 전에는 좁은 권한과 승인선을 먼저 확정해야 해요.
- 꺼지지 않는 실행 자리 — 없으면 예약 작업이 아예 실행되지 않아요.
- 저장되는 맥락 — 없으면 매번 처음부터 다시 설명해야 해요.
- 좁게 잡은 권한 — 없으면 무인 상태의 사고 반경이 불필요하게 커져요.
- 결과 확인과 복구 경로 — 없으면 실패를 며칠 뒤에 발견해요.
- 백업 — 없으면 원본 상태를 잃었을 때 복구가 어렵거나 불가능할 수 있어요.
1번부터 4번까지는 새 장비 구매가 전제되지 않아요. 이미 쓰던 기기로 자리를 채울 수 있다면 그걸로 시작해도 괜찮아요.
7. 그럼 장비는 어디에 들어가나요
여기까지 오면 자연스럽게 생기는 질문이 있어요. 그 꺼지지 않는 자리를 뭘로 채우냐는 거예요.
제 경우엔 책상 구석에 저전력 소형 PC 한 대를 늘 켜두는 방식이었어요. 다만 분명히 해둘 게 있어요. 이 장비가 AI를 더 똑똑하게 만들어주진 않아요. 하는 일은 딱 하나, 자리를 지키는 거예요.
- 저전력 상시 가동 기기 — 예약 작업이 실행될 수 있게 켜져 있는 자리를 맡아요.
- NAS 같은 저장소 — 로그와 결과물 보관, 여러 기기에서 꺼내 보기를 맡아요. 백업은 별도 복구 사본과 검증 정책이 있어야 성립해요.
- 휴대용 AI PC — 밖에서 작업할 때의 선택지고, 24시간 예약 실행에는 필요하지 않아요.
안 쓰는 노트북이나 이미 있는 서버가 있다면 그걸로 시작해도 괜찮아요. 대신 항상 켜두는 기기는 보안 설정을 따로 챙겨야 하고, 전력과 소음도 직접 겪어보고 판단하는 편이 좋아요. 이 글에 전기요금이나 성능 수치를 적지 않은 이유도 같아요. 제가 직접 재본 값이 아니라서요.

마무리
며칠 넘게 돌려보고 남은 결론은 이래요. 24시간 에이전트에서 제일 아쉬운 건 모델의 머리가 아니라, 아무도 안 볼 때 조용히 어긋나는 부분이었어요.
오늘 딱 하나만 해본다면 이걸 권하고 싶어요. 이미 돌리고 있는 자동화 하나를 골라서, 결과물이 진짜 도착했는지 확인해보세요. 완료 표시 말고 결과 자체로요.
참고한 문서
- 예약 실행이 어디서 도는지 — https://docs.openclaw.ai/automation/cron-jobs
- 기억이 어디에 저장되는지 — https://docs.openclaw.ai/concepts/memory
- 권한과 승인 경계 — https://docs.openclaw.ai/gateway/security
- 살아 있는지 확인하는 방법 — https://docs.openclaw.ai/gateway/health
문서는 2026년 8월 5일에 확인했어요. 본문의 운영 기록도 같은 날 제 환경 한 곳에서 관찰한 값이에요.
이 글에는 제휴 링크가 없어요. 제품 링크는 판매 상태를 다시 확인한 뒤에만 붙일 생각이에요.


















































