24시간 AI 에이전트 운영법

이 글의 목표 — 설치 다음에 진짜 중요한 것

Hermes Agent나 OpenClaw를 처음 보면 대부분 설치법부터 찾습니다. Docker 설치, Node.js 설치, 텔레그램 봇 토큰 만들기, API 키 넣기. 물론 설치는 필요합니다. 하지만 실제로 오래 쓰는 사람과 하루 만에 포기하는 사람의 차이는 설치가 아니라 운영법에서 갈립니다.

AI 에이전트는 일반 챗봇이 아닙니다. 파일을 읽고, 코드를 고치고, 터미널 명령을 실행하고, 브라우저를 열고, Git 커밋을 만들 수 있습니다. 즉 생산성 도구이면서 동시에 사고를 낼 수 있는 작업자입니다. 그래서 "일단 켜두고 아무거나 시킨다"가 아니라, 작은 회사의 야간 운영실처럼 규칙을 세워야 합니다.

이 글의 목표는 단순합니다.

집 컴퓨터나 VPS에서 24시간 켜진 Hermes/OpenClaw를, 휴대폰 한 줄 지시만으로 안전하게 굴리는 방법을 정리합니다.

여기서 말하는 활용법은 "AI에게 코딩 시키기" 수준이 아닙니다. 개발, 조사, 콘텐츠 작성, 장애 확인, 배포 전 점검, 로그 요약, Git 정리, 장기 작업 감시까지 포함합니다. 핵심은 AI가 밤새 일을 해도 다음 날 사람이 이어받을 수 있도록 검증 가능한 흔적을 남기게 하는 것입니다.

---

24시간 AI 에이전트는 무엇을 대신해야 하나

사람을 완전히 대체하는 도구가 아니다

24시간 AI 에이전트를 "사람 없이 알아서 사업을 굴리는 로봇"으로 생각하면 실패합니다. 지금 단계에서 AI 에이전트는 최종 책임자가 아니라 초안 작성자, 반복 작업자, 야간 점검자, 문제 조사자에 가깝습니다.

좋은 역할은 다음과 같습니다.

나쁜 역할은 다음과 같습니다.

따라서 운영 원칙은 이렇습니다.

AI에게는 조사, 초안, 수정, 검증을 맡기고, 파괴적 실행과 최종 배포 결정은 사람 승인으로 남긴다.

24시간 운영의 진짜 장점

24시간 켜두는 이유는 AI가 잠을 안 자기 때문만이 아닙니다. 핵심은 시간차 작업입니다.

밤에 질문을 던져두면 아침에 분석 결과가 와 있습니다. 외출 중에 버그를 맡기면 집에 도착하기 전 원인 후보와 테스트 결과가 준비되어 있습니다. 유튜브나 블로그 아이디어를 던지면 초안, 목차, SEO 키워드, 참고 링크가 정리되어 있습니다.

사람이 계속 붙잡고 있을 필요가 없는 작업을 AI가 대신 굴려 주는 것, 이것이 24시간 에이전트의 가치입니다.

---

Hermes와 OpenClaw의 역할 분리

둘 다 "메시지로 AI에게 일을 시키는 시스템"처럼 보이지만, 운영 관점에서는 장점이 다릅니다.

Hermes Agent가 강한 영역

Hermes는 개인 운영자에게 맞춰 점점 똑똑해지는 에이전트로 쓰기 좋습니다. 특히 다음 작업에 강합니다.

• 내 프로젝트 구조를 기억하고 반복 작업을 줄이기
• 성공한 작업 절차를 스킬로 저장하기
• Telegram에서 개발·배포·문서 작업을 계속 이어가기
• 장기 프로젝트의 컨벤션과 선호를 기억하기
• 파일, 터미널, 브라우저, 스케줄러, 메시징을 한 흐름으로 묶기

Hermes를 쓰면 좋은 사람은 이런 사람입니다.

"내가 자주 하는 작업을 AI가 점점 배워서, 다음번에는 더 빨리 처리했으면 좋겠다."

OpenClaw가 강한 영역

OpenClaw는 여러 채널과 여러 에이전트를 게이트웨이로 묶는 구조에 강점이 있습니다. 특히 다음 작업에 어울립니다.

• 다양한 메신저와 앱을 한곳에 연결하기
• 팀 또는 여러 계정의 자동화 흐름 만들기
• 생활형 비서, 알림, 일정, 메시지 처리 자동화
• 채널별 에이전트 분리 운영

OpenClaw를 쓰면 좋은 사람은 이런 사람입니다.

"텔레그램뿐 아니라 여러 채널에서 AI 비서를 쓰고 싶고, 코딩 외의 생활 자동화도 같이 묶고 싶다."

실전 추천 조합

처음부터 둘 다 복잡하게 붙일 필요는 없습니다. 추천 순서는 다음입니다.

1. Hermes 하나로 시작 — 코딩, 문서, Git, 배포 점검 루틴을 안정화합니다.
2. Telegram 연결 — 휴대폰으로 지시하고 결과 받는 흐름을 만듭니다.
3. Docker 작업 폴더 분리 — AI가 만질 수 있는 공간을 제한합니다.
4. 반복 작업을 스킬화 — 성공한 절차를 스킬로 저장합니다.
5. 필요할 때 OpenClaw 추가 — 채널이 늘거나 생활 자동화가 필요할 때 붙입니다.

즉, Hermes는 작업자, OpenClaw는 게이트웨이 허브로 생각하면 쉽습니다.

---

운영 구조 — 휴대폰, 게이트웨이, 작업 컴퓨터, Git, 배포

24시간 AI 에이전트 운영 구조는 다섯 부분으로 나뉩니다.

휴대폰

휴대폰은 지시와 승인 장치입니다. 텔레그램으로 다음을 합니다.

• 새 작업 요청
• 진행 상황 확인
• 위험 작업 승인/거절
• 결과 요약 수신
• 에러 로그 확인
• 다음 작업 지시

중요한 점은 휴대폰이 개발 환경이 아니라는 것입니다. 휴대폰은 리모컨입니다.

게이트웨이

게이트웨이는 텔레그램 메시지를 받아 에이전트에게 전달하는 프로세스입니다. Hermes에서는 gateway가 이 역할을 합니다. OpenClaw도 게이트웨이 중심 구조입니다.

게이트웨이는 24시간 켜져 있어야 합니다. 그래서 노트북보다 다음 환경이 낫습니다.

• 집에 항상 켜진 미니 PC
• NAS 옆 보조 서버
• 저전력 중고 노트북
• 월 $5~10 VPS
• Docker가 안정적으로 도는 리눅스 머신

작업 컴퓨터

작업 컴퓨터는 실제 파일과 명령이 실행되는 곳입니다. 여기에는 다음이 있어야 합니다.

• Docker
• Git
• Node.js 또는 프로젝트별 런타임
• 작업 폴더
• 필요한 API 키
• 로그 저장 위치

단, 모든 폴더를 AI에게 열어주면 안 됩니다. 예를 들어 Windows라면 다음처럼 분리합니다.

D:\Shared               # 일반 공유
D:\Shared-Developer     # 개발 프로젝트
D:\Private              # AI 접근 금지
C:\Users\...\Pictures  # AI 접근 금지

AI가 읽고 쓸 수 있는 폴더는 Shared 계열로 제한합니다.

Git

Git은 AI 작업의 안전벨트입니다. 24시간 AI 운영에서는 Git이 선택이 아니라 필수입니다.

AI가 코드를 바꾸면 반드시 다음이 가능해야 합니다.

• 변경 파일 확인
• diff 확인
• 테스트 후 commit
• 문제가 있으면 revert
• 원격 push
• Vercel 같은 배포 시스템이 자동 반영

운영 규칙은 간단합니다.

큰 작업은 커밋 단위로 쪼개고, 커밋 메시지만 읽어도 무엇을 했는지 알 수 있게 한다.

배포

Vercel, Cloudflare, Railway 같은 배포 시스템을 붙이면 Git push가 배포 트리거가 됩니다. 이때 AI에게 배포까지 전부 맡길지, push까지만 맡길지 정해야 합니다.

추천은 다음입니다.

---

처음 정해야 할 7가지 운영 규칙

24시간 에이전트를 켜기 전에 아래 7가지를 정해 두세요.

작업 폴더

AI가 만질 수 있는 루트 폴더를 정합니다.

좋은 예:

/workspace/shared-developer

나쁜 예:

/
C:\Users\내이름
전체 홈 디렉토리

작업 폴더를 좁힐수록 사고 범위도 좁아집니다.

자동 승인 범위

AI가 사람 승인 없이 해도 되는 일을 정합니다.

허용 가능:

• 파일 읽기
• 테스트 실행
• lint 실행
• 빌드 실행
• 새 문서 작성
• 새 브랜치 생성
• diff 요약

승인 필요:

• Git push
• 배포 트리거
• DB schema 변경
• 프로덕션 환경변수 변경
• 파일 대량 삭제
• 결제·계정·권한 변경

커밋 규칙

AI가 커밋할 때 메시지 규칙을 정합니다.

예:

feat: add qna moderation queue
fix: handle failed answer retry state
chore: stop tracking local artifacts
content: add hermes openclaw operations guide

커밋 메시지는 사람이 다음 날 보고 이어받기 위한 운영 로그입니다.

검증 규칙

작업 종류별 검증 명령을 정합니다.

검증 없는 자동화는 편한 것이 아니라 위험한 것입니다.

보고 형식

AI가 작업 후 보내는 보고 형식을 고정합니다.

추천 형식:

완료:
- 무엇을 바꿨는지

검증:
- lint/test/build 결과

주의:
- 남은 리스크
- 사람이 확인할 것

다음:
- 이어서 하면 좋은 작업

중단 규칙

AI가 계속 고치다가 더 망치는 것을 막기 위한 규칙입니다.

추천:

• 같은 문제를 3번 고쳐도 실패하면 중단
• 원인을 모르면 수정하지 말고 조사 보고
• 프로덕션 데이터는 직접 수정하지 않음
• 파괴적 명령은 승인 없이는 실행하지 않음
• 테스트 실패를 무시하고 push하지 않음

비밀 관리

API 키, 토큰, SSH 키, DB 비밀번호는 파일 하나에 몰아넣고 Git ignore 처리해야 합니다. AI에게 "토큰 어디 저장해"라고 물었을 때 대답이 명확해야 합니다.

원칙:

• 토큰은 Git에 올리지 않는다
• remote URL에 토큰을 박지 않는다
• ~/.git-credentials에 저장할지 말지는 사용자가 결정한다
• 임시 push는 파일에서 읽어 환경변수로만 사용한다
• 출력 로그에 토큰을 찍지 않는다

---

일을 맡기는 법 — 좋은 지시와 나쁜 지시

24시간 AI 에이전트는 지시 품질에 따라 결과가 크게 달라집니다.

나쁜 지시

사이트 좀 고쳐줘

문제가 너무 넓습니다. AI가 무엇을 목표로 해야 하는지, 어디까지 건드려도 되는지 모릅니다.

다 알아서 해

가장 위험합니다. "알아서"의 범위가 코드 수정인지, DB 변경인지, 배포인지 불명확합니다.

빨리 배포해

검증을 생략하게 만들 수 있습니다.

좋은 지시

/workspace/shared-developer/000_24h365days 기준으로 /hermes 목록에 새 포스트 1개 추가해.
기존 포스트 구조를 먼저 읽고 같은 방식으로 작성해.
코드 수정 후 npm run lint, npm run build 통과 확인해.
Git push는 내가 말하기 전까지 하지 마.

좋은 지시는 다섯 가지가 들어갑니다.

1. 작업 경로
2. 목표
3. 참고할 기존 패턴
4. 검증 방법
5. 권한 경계

실전 지시 템플릿

[작업 경로]
/path/to/project

[목표]
무엇을 만들거나 고칠지 한 문장으로 설명

[참고]
비슷한 파일, 기존 구현, 지켜야 할 규칙

[금지]
건드리면 안 되는 파일/DB/배포/토큰

[검증]
실행해야 할 명령과 성공 기준

[보고]
변경 파일, 검증 결과, 남은 리스크를 요약

이 템플릿을 쓰면 에이전트가 훨씬 안정적으로 움직입니다.

---

개발 작업 활용법

코드베이스 전수 분석

처음 맡길 일은 "코드 고치기"가 아니라 "프로젝트 이해하기"입니다.

지시 예시:

이 프로젝트 전수 분석해.
폴더 구조, 기술 스택, 주요 라우트, DB, 환경변수, 테스트/빌드 상태, 운영 리스크를 정리해.
수정은 하지 말고 보고만 해.

이 작업을 먼저 하면 이후 요청의 품질이 좋아집니다. AI가 프로젝트의 지도 없이 코드를 고치면, 겉으로는 맞지만 구조를 깨는 수정이 나올 수 있습니다.

작은 기능 추가

좋은 단위:

• 버튼 하나 추가
• API response 필드 하나 추가
• 관리 화면 카드 하나 추가
• 목록 데이터 항목 하나 추가
• 상세 페이지 섹션 하나 추가

나쁜 단위:

• 전체 서비스 리뉴얼
• DB 구조 전면 개편
• 인증 시스템 전체 추가
• 모든 페이지 SEO 개선

24시간 에이전트에게는 큰 일을 잘게 쪼개서 맡겨야 합니다.

버그 수정

버그 수정 지시는 반드시 재현 조건을 포함합니다.

/qna에서 질문을 올리면 pending으로 남는 문제가 있어.
먼저 실패를 재현하고, 관련 route/lib/test를 읽고, 원인 후보를 정리해.
원인을 이해하기 전에는 수정하지 마.
수정 후 focused test와 npm test를 실행해.

핵심은 "바로 고쳐"가 아니라 "먼저 재현하고 원인을 찾아"입니다.

리팩터링

AI에게 리팩터링을 맡길 때는 변경 목적을 좁혀야 합니다.

좋은 예:

src/lib/question-ops.ts에서 중복된 status label 변환만 함수로 분리해.
동작 변경은 하지 말고 테스트 결과가 같아야 해.

나쁜 예:

코드 깔끔하게 정리해

"깔끔하게"는 사람마다 다릅니다. AI는 이 말을 듣고 필요 없는 구조 변경을 할 수 있습니다.

---

콘텐츠·조사·문서 작업 활용법

24시간 AI 에이전트는 콘텐츠 작업에도 좋습니다. 특히 반복되는 형식이 있는 경우 강력합니다.

포스트 작성

이 사이트처럼 포스트가 TS/JSON 파일로 관리되는 경우, AI에게 기존 포스트를 먼저 읽게 해야 합니다.

지시 예시:

/hermes 포스트 구조를 먼저 읽어.
기존 2개 포스트의 필드, 톤, 길이, markdown 구성 방식을 참고해.
새 글은 같은 구조로 추가하고 목록에 연결해.

중요한 점은 "블로그 글 써줘"가 아니라 코드베이스의 포스팅 시스템에 맞춰 넣으라는 것입니다.

조사 리포트

조사 작업은 반드시 출처와 확신도를 나눠야 합니다.

보고 형식:

운영 문서

AI에게 운영 문서를 만들게 할 때는 "다음 세션의 AI가 읽고 바로 이어받을 수 있게"라고 지시하면 좋습니다.

필수 포함:

• 프로젝트 경로
• 현재 상태
• 최근 커밋
• 검증 결과
• 남은 리스크
• 다음 작업 순서
• 건드리면 안 되는 것

---

운영·모니터링·복구 작업 활용법

매일 아침 점검

24시간 에이전트를 운영한다면 매일 아침 다음을 확인하게 할 수 있습니다.

운영 점검해.
1. git status
2. 최근 커밋 5개
3. npm run lint
4. npm test
5. npm run build
6. 라이브 주요 URL 접속 확인
7. 실패/주의사항 요약
수정은 하지 말고 보고만 해.

배포 후 점검

Vercel 배포가 끝나면 AI에게 브라우저로 확인하게 합니다.

확인 항목:

• 홈 접속
• 새로 추가한 페이지 접속
• 404 여부
• 제목/설명 표시
• 주요 버튼 링크
• 콘솔 에러
• 모바일 레이아웃

장애 조사

장애가 날 때는 AI에게 바로 고치라고 하지 말고 범위를 좁힙니다.

지금 /admin에서 에러가 난다.
수정하지 말고 먼저 조사해.
브라우저 콘솔, 서버 로그, 관련 route, 최근 git diff를 확인하고
원인을 1순위/2순위/3순위로 정리해.

조사와 수정을 분리하면 사고가 줄어듭니다.

---

24시간 루프 설계 — 30분, 4시간, 하루 단위

30분 루프 — 짧은 감시

목적: 빠른 이상 감지

할 일:

• pending 작업 확인
• 실패 job 확인
• 마지막 heartbeat 확인
• 새 질문/새 요청 확인
• 치명 에러만 보고

예:

30분 루프에서는 수정하지 말고 상태만 봐.
실패가 있으면 원인 후보와 다음 조치만 보고해.

4시간 루프 — 작은 개선

목적: 하나의 작은 작업 완료

할 일:

• 작은 버그 하나 수정
• 문서 하나 보강
• 테스트 하나 추가
• 운영 로그 정리
• 실패 질문 재시도

규칙:

• 한 번에 한 작업만
• 검증 필수
• 성공 시 commit
• push는 정책에 따라

하루 루프 — 품질 점검

목적: 사람이 보기 좋은 상태로 정리

할 일:

• 변경 사항 요약
• 실패한 작업 정리
• 다음 우선순위 추천
• 비용/토큰 사용 추정
• 보안 위험 확인
• 오래된 브랜치/임시 파일 확인

24시간 AI 운영은 자동으로 뭔가 많이 하는 것이 아니라, 정기적으로 상태를 작은 단위로 깨끗하게 유지하는 것입니다.

---

보안 경계선 — AI에게 절대 맡기면 안 되는 것

토큰과 비밀키

AI가 토큰을 사용할 수는 있지만, 토큰을 저장하는 방식은 엄격해야 합니다.

좋은 방식:

• ignore 된 로컬 파일에서 읽기
• 프로세스 환경변수로만 사용
• 로그 출력 시 마스킹
• 작업 후 임시 파일 삭제

나쁜 방식:

• Git remote URL에 토큰 포함
• 코드 파일에 토큰 작성
• README나 docs에 실토큰 커밋
• 터미널 출력에 토큰 그대로 노출

프로덕션 DB

AI에게 프로덕션 DB 직접 수정 권한을 주는 것은 매우 조심해야 합니다.

허용 가능:

• SELECT로 상태 확인
• schema 문서 읽기
• migration 초안 작성
• 백업 절차 문서화

승인 필요:

• DELETE
• UPDATE
• DROP
• TRUNCATE
• migration push
• 대량 데이터 변경

Docker 볼륨

Docker 볼륨은 최소로 열어야 합니다.

좋은 예:

/workspace/shared-developer:/workspace/shared-developer

나쁜 예:

/:/host
C:\:/mnt/c

AI가 실수해도 피해가 작업 폴더 안으로 제한되어야 합니다.

---

비용 관리 — 모델, 서버, 배포비를 통제하는 법

모델 비용

24시간 에이전트가 계속 고성능 모델만 쓰면 비용이 커집니다. 작업별 모델 등급을 나누는 것이 좋습니다.

서버 비용

처음에는 집 미니 PC나 기존 노트북으로 충분합니다. VPS를 쓴다면 월 $5~10 수준에서 시작하세요. GPU 서버는 필요 없습니다. AI 추론은 외부 API가 하고, 서버는 명령 실행과 파일 작업을 담당합니다.

배포 비용

Vercel 같은 플랫폼은 Git push마다 빌드가 돌 수 있습니다. 그래서 데이터만 바꾸는 작업과 코드 변경 작업을 분리해야 합니다.

예:

• JSON 데이터만 DB sync로 반영 가능하면 Vercel 재배포 생략
• 코드 변경은 push → Vercel 배포
• 실험 작업은 브랜치/PR에서 확인
• 큰 파일과 docs는 Git에서 제외

---

실패했을 때 복구 순서

AI 운영에서 실패는 정상입니다. 중요한 것은 실패를 빨리 격리하는 것입니다.

1단계 — 현재 상태 고정

먼저 상태를 봅니다.

git status --short
git log --oneline -5

수정 중인 파일, 최근 커밋, 원격 상태를 확인합니다.

2단계 — 재현

에러가 재현되는지 확인합니다.

npm run lint
npm test
npm run build

브라우저 문제라면 해당 URL을 직접 열고 콘솔을 확인합니다.

3단계 — 최근 변경 확인

git diff
git diff HEAD~1..HEAD

가장 최근에 바뀐 파일부터 봅니다.

4단계 — 되돌릴지 고칠지 결정

기준:

5단계 — 보고

복구 후에는 반드시 원인과 재발 방지책을 남깁니다.

원인:
검증:
복구:
재발 방지:
남은 확인:

---

바로 복사해서 쓰는 운영 프롬프트

개발 작업 맡기기

/workspace/shared-developer/000_24h365days 기준으로 작업해.
먼저 관련 파일 구조를 읽고 기존 패턴을 파악해.
그 다음 최소 변경으로 구현해.
검증은 npm run lint, npm test, npm run build 순서로 해.
Git commit은 해도 되지만 push는 내가 말하기 전까지 하지 마.
결과는 변경 파일, 검증 결과, 남은 리스크로 요약해.

포스팅 추가

/hermes 포스트를 1개 추가해.
기존 포스트 2개와 hermes-posts.ts 구조를 먼저 읽어.
새 글은 같은 HermesPost 타입으로 만들고 목록에 연결해.
본문은 목차, 표, 체크리스트, 실전 예시를 포함해서 상세하게 작성해.
완료 후 npm run lint와 npm run build를 확인해.

운영 점검

운영 점검만 해. 수정하지 마.
확인할 것: git status, 최근 커밋, lint/test/build, 라이브 홈, /admin, /qna, 새로 바뀐 페이지.
문제가 있으면 원인 후보와 다음 조치만 보고해.

장애 조사

문제가 생겼다. 고치기 전에 조사부터 해.
에러 메시지, 재현 방법, 최근 변경, 관련 파일, 데이터 흐름을 확인해.
원인 가설을 1~3순위로 정리하고, 가장 작은 수정안을 제안해.
내가 승인하기 전에는 프로덕션 데이터나 배포 설정은 건드리지 마.

야간 자동 작업

다음 4시간 동안 작은 배치 단위로만 진행해.
각 배치는 하나의 목표만 가진다.
변경 후 검증하고, 성공하면 commit한다.
push는 하지 않는다.
실패하면 세 번 이상 임의 수정하지 말고 원인과 blocker를 문서화한다.

---

최종 체크리스트

24시간 AI 에이전트를 실제로 굴리기 전에 아래를 확인하세요.

환경 체크

• [ ] 24시간 켜둘 컴퓨터가 있다
• [ ] Docker가 설치되어 있다
• [ ] AI가 만질 작업 폴더가 분리되어 있다
• [ ] Git remote가 연결되어 있다
• [ ] Vercel 등 배포 트리거 정책을 이해했다
• [ ] 토큰 파일은 Git ignore 상태다

운영 체크

• [ ] AI가 해도 되는 작업과 안 되는 작업을 정했다
• [ ] push/배포 승인선을 정했다
• [ ] lint/test/build 검증 규칙을 정했다
• [ ] 실패 시 3회 이상 임의 수정 금지 규칙을 정했다
• [ ] 작업 보고 형식을 정했다
• [ ] 매일 점검 루틴을 정했다

보안 체크

• [ ] Docker 볼륨이 최소 범위다
• [ ] 홈 디렉토리 전체를 마운트하지 않았다
• [ ] 프로덕션 DB 쓰기 권한은 제한했다
• [ ] GitHub 토큰 권한은 필요한 만큼만 줬다
• [ ] 토큰은 로그에 출력되지 않는다
• [ ] 공개 채널에서 운영 명령을 받지 않는다

첫 주 운영 목표

처음부터 완전 자동화를 목표로 하지 마세요. 첫 주 목표는 다음 정도면 충분합니다.

1. 텔레그램으로 작업 요청 가능
2. AI가 프로젝트 구조를 이해
3. 작은 코드 수정 1개 성공
4. 포스트나 문서 1개 추가 성공
5. lint/test/build 검증 성공
6. Git commit/push 흐름 성공
7. 실패했을 때 사람이 복구 가능

이 일곱 가지가 되면 이미 "나만의 24시간 AI 운영실"의 기초는 완성입니다.

마지막으로 가장 중요한 원칙을 남깁니다.

24시간 AI 에이전트의 목표는 사람이 사라지는 것이 아니라, 사람이 더 중요한 판단에 집중하도록 반복 작업을 안전하게 넘기는 것입니다.

Hermes Agent와 OpenClaw는 그 목표에 가장 가까운 오픈소스 도구입니다. 설치는 시작일 뿐입니다. 진짜 차이는 운영 규칙, 검증 루프, 복구력에서 납니다.