AI Agent를 Old Mac에서 24/7 운영한 6개월 — pm2와 Discord로 만든 비서
Old Mac Mini에서 pm2로 Playwright 기반 AI 에이전트를 6개월간 무중단 운영하며 얻은 교훈을 정리합니다.
Old Mac(M4 Pro 24GB)에 AI 에이전트를 올려 24시간 돌린 지 6개월이 되었습니다. 비싼 클라우드 대신 방 안의 맥 미니에서 에이전트를 돌린다는 발상이 맞는 선택이었는지, 무엇이 잘 됐고 무엇이 무너졌는지를 솔직하게 정리해 봤습니다.
왜 Old Mac인가
처음에는 AWS EC2에 올릴 생각이었습니다. 하지만 에이전트가 하는 일을 나열해보니 금방 계산이 섰습니다. Playwright로 브라우저 자동화, Discord 알림 수발신, 로컬 Ollama 호출, 그리고 SSH로 New Mac의 Codex/Gemini CLI를 원격 실행. 이 중 절반 이상이 사내망 리소스에 의존했습니다. 그럴 거라면 집에 이미 있는 Mac Mini를 쓰는 게 비용은 물론이고 레이턴시 측면에서도 더 나았습니다.
결정적으로 Thunderbolt 5 브릿지가 New Mac과 Old Mac 사이를 120Gbps, sub-ms 지연으로 묶어주기 때문에 메인 개발 머신의 CLI 능력을 Old Mac에서 고스란히 쓸 수 있었습니다.
pm2 프로세스 구성
에이전트는 tsx watch로 개발하다가 프로덕션은 tsup으로 빌드해서 pm2가 돌립니다. ecosystem.config.cjs는 다음과 같이 단순하게 유지했습니다.
module.exports = {
apps: [{
name: 'saas-agent',
script: 'dist/bootstrap.js',
max_memory_restart: '1500M',
env: { NODE_ENV: 'production' },
log_date_format: 'YYYY-MM-DD HH:mm:ss',
}],
};
max_memory_restart는 Playwright 크롬 인스턴스가 가끔 누수되는 걸 방지하는 안전장치입니다. pm2 공식 문서에서 권장하는 그대로 pm2 save + pm2 startup 조합으로 부팅 시 자동 실행을 걸어두었고, 지난 6개월 동안 맥 재부팅은 4번 있었지만 에이전트는 모두 자동 복귀했습니다.
Discord를 컨트롤 패널로 쓰기
에이전트를 위한 별도 대시보드를 만드는 대신, 이미 매일 열어두는 Discord를 컨트롤 패널로 삼았습니다. discord.js v14의 슬래시 커맨드로 다음과 같은 명령을 노출해두었습니다.
/run codex <prompt>— New Mac의 Codex CLI에 SSH로 위임/run gemini <prompt>— Gemini CLI에 위임/status— pm2 프로세스 상태와 TB5 링크 체크/crawl jobfit— 채용공고 크롤러 즉시 실행
핵심은 "생각나는 순간에 바로 쓸 수 있어야 한다"였습니다. 전용 UI를 만들면 편리해 보여도 관리 대상이 하나 더 늘어날 뿐이라는 점을 초반에 체감했습니다.
SSE 대시보드 — 그래도 필요한 창
자동화가 많아지자 "도대체 에이전트가 지금 뭘 하고 있지?"라는 의문이 생겼고, 결국 경량 SSE(Server-Sent Events) 대시보드를 만들었습니다. 3100 포트에 이벤트 스트림을 열고, 각 작업 시작/완료/실패를 실시간으로 흘려보냅니다. 복잡한 클라이언트 상태 관리 없이 EventSource 한 줄이면 끝이라 유지보수 비용이 사실상 0에 가깝습니다.
가장 아팠던 장애 3가지
- Playwright 브라우저 누수 —
browser.close()를 try/finally로 감싸지 않았더니 실패한 작업마다 프로세스가 누적되어 2주 만에 메모리가 터졌습니다. - SSH 키 만료 — New Mac 쪽
authorized_keys를 실수로 재생성하면서 모든 원격 CLI 호출이 실패. 이후로는 ansible로 키를 관리합니다. - Discord Rate Limit — 알림 폭주 시 429가 터지며 일부 메시지가 유실. 큐에 넣고 초당 1건으로 쓰로틀링하는 로직을 추가했습니다.
6개월 후 결론
요약하면 "조용히 돌아가는 비서 하나 얻었다"입니다. 전기요금 외에 추가 비용이 없었고, 무엇보다 내 집 안에서 동작하기 때문에 데이터가 밖으로 나가지 않는다는 점이 심리적으로 편안합니다. 같은 맥락의 실험은 무료 클라우드 인프라 조합에서 이어집니다. 구성이 궁금하다면 소개 페이지를, 비슷한 에이전트를 만들고 싶다면 문의로 연락 주세요.
공유하기
이어 읽으면 좋은 글
같은 주제와 태그를 기준으로 GRAXEL 운영 맥락을 더 깊게 볼 수 있는 글입니다.
1인 개발자 SaaS 모노레포 vs 멀티레포 — Graxel 운영 1년 후 다시 보는 결정
pnpm과 Turborepo로 구축한 모노레포 아키텍처가 1인 개발자에게 정말 정답이었을까요? 1년간의 뼈저린 운영 회고와 실패담.
Cloudflare Pages 무료 티어로 SaaS 시작하기 — 진짜 1년 비용 후기
1인 개발자가 Cloudflare Pages 무료 티어로 1년간 portal, myhyetaek 등 5개 서비스를 운영하며 지출한 실제 비용과 뼈아픈 실패담을 공개합니다.
SaaS Factory 모노레포 운영기 — pnpm + Turbo로 12개 서비스 묶기
pnpm workspaces와 Turborepo로 공용 패키지와 12개 서비스를 동시에 관리하며 얻은 실전 패턴을 공유합니다.