24/7 라이프-옵스(life-ops) 에이전트가 하나의 천재적인 봇일 줄 알았는데, 사실은 10개의 지루한 봇들이었습니다

저는 SF 영화 같은 장면을 기대하며 이 토끼굴(rabbit hole)에 발을 들였습니다.

여러분도 들어본 제안일 것입니다. Mac mini나 홈 서버(home server)에서 항상 켜져 있는 에이전트 하나가, 당신이 잠든 사이 조용히 당신의 삶을 관리하는 것이죠. Plex 라이브러리를 정리하고, Home Assistant를 관리하며, 여행을 계획하고, 행정 업무를 처리하고, RSS를 모니터링하다가 정말 중요한 일이 생겼을 때만 당신에게 알림을 보냅니다.

그러다 r/openclaw에서 미디어 서버와 개인 운영(personal ops) 설정을 위해 정확히 이 작업을 수행하고 있는 한 남자에 대한 스레드를 읽게 되었습니다.

그리고 흥미로웠던 점은 그 판타지가 아니었습니다.

바로 아키텍처(architecture)였습니다.

그 설정은 매우 일반적인 도구들을 사용했습니다: Unraid, Plex, Sonarr, Radarr, FileBot, Home Assistant, archive.org, Discord, Telegram. 에이전트는 영화 예고편 데모 같은 지능을 보여주는 것이 아니었습니다. 그것은 백그라운드 작업(background work)을 하고 있었습니다. 끊임없이 말이죠.

그 문구가 제 머릿속을 떠나지 않았습니다: 백그라운드 작업.

그것이 24/7 에이전트를 위한 진정한 설계 제약 조건(design constraint)입니다.

추론 벤치마크(reasoning benchmarks)가 아닙니다.
AGI(인공 일반 지능)의 느낌도 아닙니다.
GPT-5.4나 Claude Opus 4.6 중 누가 원샷 프롬프트(one-shot prompts)에서 승리하느냐의 문제도 아닙니다.

어려운 부분은, 다음 중 어느 하나로 변하지 않으면서 하루 종일 지루한 작업들을 묵묵히 수행할 수 있는 무언가를 구축하는 것입니다:

상태 관리 재앙 (state-management disaster)
과금 재앙 (billing disaster)

그리고 첫 번째 놀라운 사실은, 가장 뛰어난 버전은 대개 하나의 에이전트가 아니라는 점입니다.

그것은 여러 개의 작은 에이전트들입니다.

승리하는 패턴은 슈퍼 에이전트가 아닙니다

그 OpenClaw 스레드에서 가장 좋았던 댓글 중 하나는, 약 10개의 에이전트를 운영하며 그중 약 6개가 매일 활성화되어 있고, 각 에이전트가 좁은 역할(narrow role)을 수행하고 있다는 사람의 글이었습니다.

이것은 "나는 Jarvis를 만들었다"라는 말보다 덜 인상적으로 들릴 수 있습니다.

하지만 훨씬 더 정확하게 들리기도 합니다.

만약 당신이 개인 운영(personal ops), 홈랩(home-lab) 자동화, 또는 항상 켜져 있는 어시스턴트를 구축하고 있다면, 그 아키텍처는 단일 자율 뇌(single autonomous brain)보다는 작은 운영 팀(tiny ops team)에 더 가깝게 보일 것입니다.

다음과 같은 형태 말이죠:

분류(triage) 및 최종 결정을 위한 인박스/운영자(inbox/operator) 에이전트
Plex, Sonarr, Radarr, FileBot, 자막 정리, 누락된 에피소드를 위한 미디어(media) 에이전트
Home Assistant 루틴 및 장치 동작을 위한 홈(home) 에이전트
웹 검색, archive.org 추출, 가계도 조사, 여행 계획을 위한 리서치(research) 에이전트
알림, 요약, 후속 조치, 반복 작업을 위한 관리(admin) 에이전트
실제 방해 요소만을 Telegram으로 에스컬레이션(escalate)하는 알림 레이어(notification layer)

이는 OpenClaw와 같은 도구들이 실제로 어떻게 유용하게 쓰이는지를 명확하게 보여줍니다.

OpenClaw의 셀프 호스팅(self-hosted) 게이트웨이(Gateway)는 컨트롤 플레인(control plane)처럼 작동합니다. 세션은 Discord나 Telegram 같은 채널 전반에 걸쳐 에이전트, 워크스페이스(workspace), 또는 발신자별로 격리된 상태를 유지합니다.

이것이 단순한 구현 세부 사항(implementation detail)처럼 들릴 수도 있습니다.

하지만 그렇지 않습니다.

장시간 실행되는(long-running) 에이전트에게 세션 격리는 생존의 문제입니다.

만약 미디어 정리 작업이 비영리 단체 모금 초안 작업으로 침범하거나, Home Assistant 루틴이 미완료된 archive.org 작업의 컨텍스트(context)를 상속받게 된다면, 시스템 전체가 마치 유령이 들린 것처럼 작동하기 시작할 것입니다.

개발자들은 보통 이를 고통스러운 과정을 통해 깨닫게 됩니다. 장시간 실행되는 에이전트는 프롬프트(prompt)의 문제가 아니라 운영(operations)의 문제가 됩니다.

이는 OpenClaw, n8n, Make, Zapier를 사용하든, 혹은 커스텀 Python 워커 팜(worker farm)을 사용하든 마찬가지입니다.

이러한 설정이 일주일 동안은 똑똑해 보이다가 3주 차에는 저주처럼 느껴지는 이유

많은 사람들이 에이전트 스택(agent stack)이 이상해지기 시작하면 모델(model)을 탓합니다.

하지만 대개 모델의 문제는 아닙니다.

그것은 상태 드리프트(state drift) 때문입니다.

원문 Reddit 게시물은 실제 에이전트 시스템에서 볼 수 있는 전형적인 실패 유형을 정확히 설명했습니다:

프로젝트 목록이 "대기 중" 목록에서 벗어남
완료된 작업이 다시 나타남
항목이 사라짐
백그라운드 워커(background workers)가 소극적이 되거나 일관성이 없어짐

이것은 "LLM은 가짜다"라는 뜻이 아닙니다.

이것은 "당신에게 지속 가능한 진실의 원천(durable source of truth)이 없다"는 뜻입니다.

한 댓글 작성자는 목록 하단에 공유 메모리/스토어(shared memory/store)를 추가함으로써 서로 다른 뷰(view)들이 충돌하는 것을 막아 이 문제를 해결했다고 말했습니다.

이것이 바로 작업 상태(task state)가 사람들이 생각하는 것보다 더 중요한 이유입니다.

보드(board)가 곧 제품이다

OpenClaw에서 가장 화려하지 않으면서도 가장 중요한 아이디어 중 하나는 워크보드(Workboard)입니다.

보드가 흥미롭기 때문이 아닙니다.

지속적인 에이전트(persistent agents)에게는 원장(ledger)이 필요하기 때문입니다.

진짜 원장 말입니다.

만약 에이전트가 답장 초안을 작성했지만 보내지 않았다면, 그 작업은 완료된 것일까요?
작업자가 세 번 재시도(retry)하고 실패했다면, 그것을 어디서 확인할 수 있을까요?
새벽 3시 14분에 경고(alert)가 발생했다면, 어떤 실행(run)이 이를 생성했을까요?
세션(session)이 만료(stale)되었다면, 무엇이 진행 중이었는지 어떻게 알 수 있을까요?

로그(logs), 실행 ID(run IDs), 세션 ID(session IDs), 재시도(retries), 그리고 이벤트 이력(event history)과 연결된 가시적인 상태(visible state)가 필요합니다.

이것이 바로 다음의 차이입니다:

"내 에이전트는 마법 같다"
그리고 "내 에이전트는 현실과 접촉해도 살아남을 수 있다"

항상 켜져 있는(always-on) 에이전트에게는 데모의 품질보다 보드(boards), 로그(logs), 재시도(retries), 그리고 만료된 세션 감지(stale-session detection)가 더 중요합니다.

실용적인 라이프-옵스(life-ops) 스택은 대부분 지루한 소프트웨어입니다

이 부분이 제가 연구에서 가장 좋아했던 대목입니다.

스택은 이국적이지 않습니다.

자동화 인터페이스(automation surfaces)를 갖춘 홈랩(home-lab) 소프트웨어일 뿐입니다.

미디어 스택

Reddit 예시에서 사용된 것들은 다음과 같습니다:

Unraid
Plex
Sonarr
Radarr
FileBot
라이브 TV 채널

이것만으로도 유용한 에이전트를 위한 충분한 접점(surface area)이 됩니다.

미디어 에이전트에게 영화적인 취향은 필요 없습니다.

에이전트에게 필요한 것은 다음과 같습니다:

잘못된 명명 규칙(naming) 감지
파일 이름 올바르게 변경
누락된 에피소드 인지
메타데이터/자막 가져오기
예외 케이스(edge cases) 에스컬레이션

이런 종류의 명령은 90%의 "AI 에이전트" 데모보다 더 유용합니다:

filebot -rename -r "/input" \
  --db TheMovieDB::TV \
  -non-strict \
...

이것이 진짜 작업입니다.

홈 오토메이션(Home automation)

Home Assistant는 이미 OpenAI 통합 기능을 갖추고 있으며, Assist를 통해 노출된 엔티티(entities)를 제어할 수 있습니다.

이것은 강력합니다.

또한 문서에서 사용자에게 API 사용량을 모니터링하고 제한을 설정하라고 명시적으로 경고한다는 점도 시사하는 바가 큽니다.

그 경고는 각주가 아닙니다. 그것은 설계 신호(design signal)입니다.

항상 켜져 있는 자동화는 수많은 작은 호출(calls)을 생성합니다.

조사 및 아카이브 작업

동일한 Reddit 설정에는 다음이 포함되었습니다:

archive.org 다운로드
가계 조사(ancestry research)
백패킹 여행 계획
콘서트 알림
RSS 모니터링

다시 말하지만, 평범한 작업들입니다.

internetarchive Python 라이브러리는 이미 깔끔한 자동화 인터페이스(automation surface)를 제공합니다.

예시:

from internetarchive import search_items

query = 'collection:opensource_movies AND subject:"documentary"'
...

Discord는 대화형 상호작용(conversational interaction)에 적합합니다.
Telegram은 일반 채팅과 구별되는 느낌을 주기 때문에 우선순위가 높은 알림(high-priority alerts)에 더 효과적입니다.

여기서 미래지향적인 것은 아무것도 없습니다.

그렇기 때문에 신뢰할 수 있는 것입니다.

비용이 많이 드는 부분은 천재성이 아닙니다. 바로 유휴 상태(idling)입니다.

이 부분은 더 많은 개발자들이 주목해야 할 지점입니다.

지속적인 에이전트(Persistent agents)가 비용이 많이 드는 이유는 하나의 거대하고 천재적인 작업을 수행하기 때문이 아닙니다.

작은 작업들을 결코 멈추지 않고 수행하기 때문에 비용이 많이 드는 것입니다:

폴링 (polling)
요약 (summarizing)
재시도 (retrying)
분류 (classifying)
상태 확인 (checking state)
메시지 라우팅 (routing messages)
출력물 재작성 (rewriting outputs)
알림 생성 (generating alerts)
로깅 (logging)

토큰 불안(token anxiety)이 발생하는 지점이 바로 여기입니다.

하나의 거대한 프롬프트 때문이 아닙니다.

수천 개의 아주 작은 백그라운드 호출(background calls) 때문입니다.

그리고 바로 이 지점에서 컴퓨팅 모델(compute model)이 대부분의 사람들이 예상하는 것보다 훨씬 더 일찍 중요해집니다.

하루 종일 저강도 활동을 수행하는 3~10개의 워커(workers)를 보유하고 있다면, 단일 프롬프트에서 몇 푼을 아끼는 것보다 예측 가능한 월간 컴퓨팅 비용이 더 중요합니다.

이는 OpenClaw에도 해당됩니다.
n8n에도 해당됩니다.
Make에도 해당됩니다.
Zapier에도 해당됩니다.
커스텀 워커 플릿(custom worker fleets)에도 해당됩니다.

에이전트를 24/7 가동하기 시작하면, 토큰당 과금 방식(per-token pricing)은 매우 특정한 방식으로 짜증스럽게 다가옵니다. 즉, 비용이 많이 드는 부분은 당신이 인지조차 못 하게 된 주변 트래픽(ambient traffic)이라는 점입니다.

그것이 바로 에이전트 워크로드(agent workloads)에 있어 정액제 AI(flat-rate AI)가 매력적인 이유입니다.

예측 가능한 월간 가격을 제공하는, 즉시 사용 가능한 OpenAI 호환 API는 수천 개의 작은 호출에 걸쳐 토큰 소모를 감시하는 것보다 상시 가동 시스템(always-on systems)에 훨씬 더 적합합니다.

그것이 바로 여기서 Standard Compute가 흥미로운 핵심 이유입니다.

만약 당신이 에이전트 중심의 자동화 (agent-heavy automations)를 구축하고 있다면, Standard Compute는 고정된 월간 가격으로 무제한 AI 연산 (AI compute)을 제공하며, OpenAI 호환 SDK 및 HTTP 클라이언트와 함께 작동하고, 백그라운드 활동을 지속적으로 측정해야 하는 필요성을 제거해 줍니다. 지속적인 워커 (persistent workers), 재시도 (retries), 요약 (summaries), 그리고 라우팅 루프 (routing loops)의 경우, 해당 모델이 토큰당 과금 (per-token billing) 방식보다 더 합리적입니다.

단순히 "무제한"이라는 말이 화려하게 들리기 때문이 아닙니다.

지루한 백그라운드 작업이야말로 에이전트가 가장 많이 하는 일이기 때문입니다.

어떤 도구가 실제로 무엇에 가장 적합한가?

이 작업의 모든 부분이 동일한 인터페이스에 속할 수는 없습니다.

제 생각은 꽤 단순합니다:

옵션	실제로 가장 적합한 용도
OpenClaw	장기 실행되는 개인 운영 (personal ops)을 위한 최적의 컨트롤 플레인 (control plane): 셀프 호스팅 게이트웨이 (self-hosted Gateway), Discord 및 Telegram을 통한 멀티 채널 액세스, 격리된 에이전트 세션, 그리고 진행 중인 작업과 연결된 작업 추적
...

만약 Discord, Telegram을 가로지르는 개인 운영을 위한 컨트롤 플레인과 장기 실행되는 작업 상태 (task state)가 필요하다면, 저는 Home Assistant + OpenAI를 직접 사용하는 대신 OpenClaw를 선택할 것입니다.

코드 수정, 디버깅 또는 개발자 실행이 필요하다면, Claude Code나 Codex를 선택할 것입니다.

통합 중심의 파이프라인 (integration-heavy pipelines)이 필요하다면, n8n이나 Make를 사용할 것입니다.

실수는 하나의 도구가 전체 스택을 지배해야 한다고 가정하는 것입니다.

내가 가장 먼저 구축할 것

만약 제가 이것을 집에서 구축한다면, Reddit에서 본 꿈보다 더 작게 시작할 것입니다.

열 개가 아니라, 세 개의 에이전트로 말이죠.

1차 아키텍처 (First-pass architecture)

Mac mini, VM 또는 홈 서버 상의 OpenClaw Gateway
일반적인 상호작용을 위한 Discord
고순위 알림만을 위한 Telegram
하나의 미디어 에이전트
하나의 홈 에이전트
하나의 관리(admin) 에이전트
첫날부터 활성화된 워크보드 (Workboard)
실행을 위한 직접적인 스크립트/API
계획/요약을 위한 GPT 또는 Claude

마지막 항목이 중요합니다.

계획 (planning), 요약 (summarization), 분류 (classification), 그리고 커뮤니케이션에는 LLM을 사용하세요.
실행 (execution)에는 결정론적 도구 (deterministic tools)를 사용하세요.

예시:

파일 작업을 위한 FileBot CLI
장치 제어를 위한 Home Assistant 액션 (actions)
archive.org 작업을 위한 Python 스크립트
스케줄링을 위한 Cron/systemd/timers/큐 워커 (queue workers)

OpenClaw 부트스트랩 (bootstrap)

npm install -g openclaw@latest
openclaw onboard --install-daemon

Workboard 활성화:

openclaw plugins enable workboard
openclaw gateway restart
openclaw dashboard

워커 분할 예시 (Example worker split)

agents:
  media:
    responsibilities:
...

실행 패턴 예시 (Example execution pattern)

LLM을 셸 실행 (shell execution)에서 가능한 한 제외하세요.

import subprocess

def rename_media(path_in: str, path_out: str):
...

모델은 이 함수를 언제 호출할지 결정해야 합니다.
매번 명령어를 즉흥적으로(freestyle) 만들어내서는 안 됩니다.

진짜 교훈: 지루함이 자율성보다 낫다

이러한 라이프-옵스 (life-ops) 설정에서 가장 강력한 패턴은 그 매력이 없을 정도로 지루하다는 점이 거의 짜증스러울 정도입니다.

승자는 눈부시게 자율적인 단 하나의 에이전트가 아닙니다.

중앙에 한 명의 운영자(operator)가 있고, 모두가 정직하게 임하도록 관리하는 태스크 보드 (task board)가 있으며, 아주 작은 일들을 신뢰성 있게 수행하는 좁은 범위의 워커 (narrow workers)들이 쌓여 있는 스택 (stack)입니다.

이는 개발자들에게 두 가지 즉각적인 시사점을 줍니다:

장시간 실행되는 에이전트를 채팅 세션 (chat sessions)이 아닌 운영 시스템 (ops systems)처럼 취급하세요.
지속적인 저강도 트래픽 (low-grade traffic)을 견딜 수 있는 컴퓨팅 모델 (compute model)을 선택하세요.

만약 당신의 설정에 Plex, Home Assistant, archive.org, Discord, Telegram, RSS, 그리고 실제 생활 주변에 쌓이는 온갖 기묘한 관리 작업들이 포함되어 있다면, 저는 다음과 같은 순서로 최적화하겠습니다:

상태 위생 (State hygiene)
세션 격리 (Session isolation)
예측 가능한 컴퓨팅 (Predictable compute)

그 외의 모든 것은 그 다음에 옵니다.

왜냐하면 꿈꾸는 것은 단 한 주말 동안만 마법처럼 느껴지는 에이전트가 아니기 때문입니다.

그것은 당신의 태스크 상태 (task state)를 망가뜨리거나 API 청구서를 확인하는 것이 두려워지게 만들지 않으면서, 몇 달 동안 조용히 지루한 업무를 처리하는 에이전트입니다.

만약 당신이 이미 OpenAI 호환 도구, n8n, Make, Zapier, OpenClaw 또는 커스텀 워커를 사용하여 이런 종류의 것을 구축하고 있다면, 이것이 바로 Standard Compute가 적합한 지점입니다. 하루 종일 수많은 작고 정당한 업무를 수행하는 상시 가동 에이전트 시스템 (always-on agent systems)을 위한 정액제 AI 컴퓨팅 (flat-rate AI compute)입니다.

그것은 당신의 백그라운드 루프 (background loops)가 무료인 척하는 것보다 훨씬 더 나은 토대입니다.