저는 r/openclaw에 평소와 다름없는 부고 기사를 예상하며 스레드를 열었습니다:

https://reddit.com/r/openclaw/comments/1vhg5dx/is_openclaw_dead/

여러분도 그 패턴을 아실 겁니다.

한때 열광적이었던 오픈 소스 (open source) 프로젝트가 피드에서 점차 사라지고, 릴리스 (releases)는 조용해지며, 누군가가 모두가 이미 생각하고 있던 질문을 던집니다: '이거 끝난 건가?'

하지만 그 스레드는 그보다 훨씬 유용했습니다.

그것은 정말로 OpenClaw가 죽었는지에 대한 문제가 아니었습니다. 데모 단계가 끝난 후 팀들이 에이전트 인프라 (agent infrastructure)로부터 실제로 원하는 것이 무엇인지에 대한 문제였습니다.

그리고 그 답은 사람들이 원하는 것만큼 화려하지 않습니다.

사람들이 원하는 것:

• 휴대 가능한 메모리 (portable memory)
• 제공자 전환 (provider switching)
• 헤드리스 자동화 (headless automation)
• 업데이트 후에도 여전히 작동하는 무언가
• 매주 관리(babysit)할 필요가 없는 무언가

그것이 진짜 갈림길입니다.

'오픈 소스 vs 호스팅'이 아닙니다.

'제어권 vs 유지보수 부담'입니다.

스레드에서 가장 좋았던 댓글은 메모리 소유권에 관한 것이었습니다

토론에서 가장 날카로웠던 댓글은 이것이었습니다:

“아니요. codex와 cowork 모두 다른 누군가가 당신의 메모리 기질 (memory substrate)을 소유합니다. OpenClaw는 당신의 설정 위에서 작동합니다. 즉, 상황이 닥쳤을 때 전환하기가 더 쉽다는 뜻입니다.”

그것이 논점의 핵심입니다.

많은 사람들이 OpenClaw를 마치 추가 설정이 필요한 채팅 UI (chat UI)인 것처럼 이야기합니다.

그것은 핵심을 놓친 것입니다.

OpenClaw는 챗봇 앱보다는 로컬 우선 에이전트 제어 평면 (local-first agent control plane)에 훨씬 가깝습니다. 가치 있는 부분은 인터페이스가 아닙니다. 가치 있는 부분은 당신의:

• 워크스페이스 (workspace)
• 세션 히스토리 (session history)
• 메모리 (memory)
• 도구 (tools)
• 라우팅 로직 (routing logic)

이 당신의 설정에 그대로 남아있다는 점입니다.

지속적인 무언가를 구축하는 순간, 이것은 매우 중요해집니다.

다음과 같은 것들을 생각해 보세요:

• Slack 지원 에이전트
• Discord 봇
• Telegram 응답기
• 예약된 리서치 루프 (scheduled research loops)
• n8n 핸드오프 (handoffs)
• 다단계 내부 자동화

일단 그 단계에 도달하면, 모델을 전환할 때 비용이 많이 드는 부분은 대개 API 호출이 아닙니다.

그것을 둘러싸고 있는 메모리 레이어 (memory layer)와 도구 연결 (tool wiring)입니다.

사람들이 OpenClaw를 떠날 때 실제로 대체하고 있는 것

해당 스레드에서 가장 설득력 있는 비판은 잔인할 정도로 단순했습니다:

“OpenClaw(OC)를 작동하게 유지하는 데 다른 무엇보다 더 많은 시간을 썼습니다. Hermes로 전환했고, 이제는 실제로 무언가를 성취하고 있습니다.”

이 말이 사실처럼 느껴지는 이유는 구체적이기 때문입니다.

“셀프 호스팅 (self-hosting)은 나쁘다”가 아닙니다.
“모델 성능이 더 떨어진다”도 아닙니다.
“호스팅 방식이 더 똑똑하다”도 아닙니다.

그저: “지쳤다”는 것입니다.

만약 당신이 셀프 호스팅 에이전트 인프라 (self-hosted agent infrastructure)를 운영해 본 적이 있다면, 그것이 정확히 무엇을 의미하는지 알고 있을 것입니다.

당신은 단순히 패키지를 설치하고 끝내는 것이 아닙니다. 당신은 런타임 (runtime)을 운영하고 있는 것입니다.

전형적인 유지보수 작업은 다음과 같습니다:

openclaw status --all
openclaw doctor
openclaw health --json

그다음 아마도:

openclaw gateway logs --tail
openclaw repair

그리고 Node 런타임이 어긋나면서 발생하는 버전 관련 문제들이 뒤따릅니다.

이것은 OpenClaw가 가짜라는 증거가 아닙니다.

오히려 현실적인 방식으로 문제를 일으킬 만큼 실재한다는 증거입니다.

어떤 팀들에게는 이것이 수용 가능한 범위일 수 있습니다.

하지만 많은 팀에게 이것은 바로 포기하게 되는 지점입니다.

여전히 OpenClaw를 사용하는 사람들은 떠난 사람들보다 더 진지해 보인다

이 부분이 제 생각을 바꾼 지점이었습니다.

같은 스레드 속에, OpenClaw를 통해 18개의 cron job을 실행하면서 스케줄링된 멀티 에이전트 (multi-agent) 마케팅 자동화를 위해 Claude Code를 병행 사용하고 있는 누군가의 댓글이 숨어 있었습니다.

그것은 장난 수준의 유스케이스 (use case)가 아닙니다.

그것은 OpenClaw를 상시 가동되는 에이전트 배관 (agent plumbing)으로 취급하는 사람의 모습입니다.

그리고 일단 그렇게 프레임을 짜고 나면, 제품이 훨씬 더 이해가 됩니다.

OpenClaw는 로컬 세션 (local sessions)과 메모리 (memory)를 보존하면서 여러 채널과 제공업체 (providers) 앞에 위치할 수 있습니다. 만약 당신의 시스템이 “하루에 몇 번 코딩 어시스턴트를 여는 한 사람”이 아니라, “계속 실행되어야 하는 일련의 지속적인 워크플로 (workflows)”라면 이는 매우 유용합니다.

여기 사고방식의 차이가 있습니다:

호스팅된 어시스턴트 (Hosted assistant):
- 대화형 세션 (interactive sessions)에 최적화됨
- 더 매끄러운 설정
...

스케줄링된 작업 (scheduled jobs)을 실행할 때는 이러한 트레이드오프 (trade-off)가 매우 다르게 다가옵니다.

허니문 단계 이후에 멀티 모델 오케스트레이션 (multi-model orchestration)이 중요한 이유

대부분의 에이전트 스택은 첫 번째 제공업체 변경이 일어나기 전까지는 훌륭해 보입니다.

그때 현실이 나타납니다.

아마 Claude Opus가 24/7 워크플로우(workflow)를 돌리기에는 너무 비쌀 수도 있습니다.
아마 GPT-5가 특정 코딩 단계에서 더 나을 수도 있습니다.
아마 Grok이 특정 연구 작업에 더 적합할 수도 있습니다.
아마 저렴한 분류(classification) 작업을 위해 로컬 Qwen이나 Llama를 사용하고 싶을 수도 있습니다.
아마 작업이 실행되는 바로 그 순간에 한 제공업체가 속도 제한(rate-limit)을 걸 수도 있습니다.

이제 진짜 질문은 이것입니다:

메모리(memory)와 도구(tool) 레이어를 다시 작성하지 않고도 모델을 교체할 수 있는가?

그것이 진정한 해자(moat)입니다.

더 예쁜 채팅 말풍선이 아닙니다.
출시 주간의 하이프(hype)도 아닙니다.

이식성(Portability)입니다.

이 문제의 실질적인 버전은 다음과 같습니다:

# 나쁜 아키텍처 (bad architecture): 모델 선택이 곳곳에 유출됨
if provider == "anthropic":
    memory_key = "claude_session_id"
...

이것은 빠르게 엉망이 됩니다.

더 나은 아키텍처는 다음과 같습니다:

# 더 나은 아키텍처 (better architecture): 런타임(runtime)이 메모리/도구를 소유하며, 모델은 교체 가능함
agent = RuntimeAgent(
    memory_store="postgres://agent-memory",
...

팀들이 호스팅된 제품(hosted products)이 더 쉬움에도 불구하고 셀프 호스팅 런타임(self-hosted runtimes)에 계속 관심을 갖는 이유가 바로 이것입니다.

나중에 매우 중요해지는 지루한 비교

이 표는 팀이 압박 속에서 워크플로우를 마이그레이션(migrate)해야 하기 전까지는 지루해 보입니다.

하지만 그때가 되면 이것이 이야기의 전부가 됩니다.

호스팅 방식은 보통 편의성에서 승리합니다. 하지만 운영 비용(operating cost)에서 항상 승리하는 것은 아닙니다.

이 지점이 대규모로 에이전트 자동화(agent automations)를 구축하는 모든 사람에게 대화가 유의미해지는 부분입니다.

많은 팀이 유지보수(maintenance)에 지쳐서 셀프 호스팅 스택(self-hosted stacks)을 떠납니다.

일리가 있습니다.

하지만 그들은 설정의 고통을 사용 비용 모니터링(usage-cost monitoring)과 맞바꿨다는 사실을 깨닫게 됩니다.

에이전트가 가끔 하는 채팅이 아니라, 하루 종일 실행되는 백그라운드 시스템(background systems)일 때는 이 차이가 훨씬 더 중요합니다.

만약 귀하가 다음과 같은 도구로 자동화를 구축해 보았다면:

• n8n
• Make
• Zapier
• OpenClaw
• 커스텀 워커 큐(custom worker queues)

이미 그 문제를 알고 계실 것입니다.

데모에서는 저렴해 보이는 워크플로우가 24/7로 실행되면 비싸집니다.

예시: 토큰당 과금 (per-token billing)의 함정

단순한 에이전트 파이프라인 (agent pipeline)은 다음과 같은 작업을 수행할 수 있습니다:

1. 수신 메시지 분류 (classify inbound message)
2. 메모리 검색 (retrieve memory)
3. 컨텍스트 요약 (summarize context)
4. 응답 생성 (generate response)
5. 도구 호출 실행 (run tool calls)
6. 메모리 다시 쓰기 (write memory back)

이것은 단 한 번의 모델 호출이 아닙니다. 여러 번의 호출입니다.

이제 여기에 다음 항목들을 곱해 보십시오:

• 모든 수신 이벤트 (inbound event)
• 재시도 (retries)
• 백그라운드 작업 (background jobs)
• 다중 에이전트 (multiple agents)
• 다중 환경 (multiple environments)

이 지점에서 팀들은 제품을 출시하는 대신 토큰 대시보드를 모니터링하기 시작합니다.

이 지점에서 정액제 API 액세스 (flat-rate API access)가 흥미로워집니다

이것이 바로 OpenClaw 논의가 더 큰 문제와 직접적으로 연결되는 이유이기도 합니다. 즉, 팀들은 기존의 두 가지 고충(pain points)을 겪지 않으면서도 모델 유연성을 확보하기를 원한다는 것입니다.

일반적인 고충은 다음과 같습니다:

1. 모든 것을 셀프 호스팅 (self-host)하고 런타임 (runtime)을 관리(babysit)해야 함
2. 호스팅된 API를 직접 사용하고 청구서(bill)를 관리(babysit)해야 함

이제 세 번째 옵션이 생겼습니다.

Standard Compute는 기본적으로 OpenAI 호환 API 형태를 원하지만, 토큰당 과금에 대한 불안감은 원치 않는 팀들을 위한 것입니다.

기존의 SDK나 HTTP 클라이언트를 Standard Compute로 지정하기만 하면, 다음과 같은 사항들을 처리해 줍니다:

• 고정 월간 가격 (flat monthly pricing)
• GPT-5.4, Claude Opus 4.6, Grok 4.20 간의 동적 라우팅 (dynamic routing)
• 프롬프트 최적화 (prompt optimization)
• 배치 처리 (batching)
• 적응형 스로틀링 (adaptive throttling)

따라서 귀하의 실제 목표가 다음과 같다면:

• 에이전트를 24/7 계속 실행하기
• 단일 제공업체에 종속되어 시스템을 재구축하는 것 피하기
• 매일 토큰 지출을 확인하는 일 중단하기

그것은 가공되지 않은 토큰당 API 사용이나, 팀이 더 이상 유지 관리하고 싶어 하지 않는 취약한 셀프 호스팅 스택보다 훨씬 더 실용적인 설정입니다.

예시: 기존 OpenAI 클라이언트 교체하기

from openai import OpenAI

client = OpenAI(
...

이미 OpenAI 호환 클라이언트를 기반으로 자동화 시스템을 구축해 놓았고, 다시 작성(rewrite)하고 싶지 않다면 이 점이 중요합니다.

진짜 질문은 "OpenClaw가 죽었는가?"가 아닙니다

진짜 질문은 이것입니다:

런타임 (runtime)에 대한 제어권을 유지하기 위해 귀하의 팀은 얼마나 많은 관리(babysitting)를 감수할 용의가 있습니까?

그것이 바로 결정 사항입니다.

만약 귀하의 대답이 "매우 많이"라면, OpenClaw는 여전히 실질적인 문제를 해결해 줍니다.

만약 귀하의 대답이 "거의 없다"라면, 호스팅 방식이나 API-first 설정이 아마 더 합리적일 것입니다.

하지만 귀하의 대답이 다음과 같다면:

• 우리는 이식성 (portability)이 필요하다
• 우리는 제공업체 유연성 (provider flexibility)이 필요하다
• 우리는 예측 가능한 비용이 필요하다
• 우리는 취약한 셀프 호스팅 런타임 (self-hosted runtime)을 유지 관리하고 싶지 않다

그렇다면 흥미로운 범주는 "어떤 에이전트 UI가 승리하는가"가 아닙니다.

그것은 "어떤 인프라가 우리가 파트타임 정비공이나 파트타임 회계사가 되지 않고도 계속해서 제품을 출시할 수 있게 해주는가"입니다.

어떤 에이전트 스택을 선택하기 전에 내가 던질 질문들

만약 귀하가 OpenClaw, Claude Code, Hermes, 또는 귀하만의 커스텀 런타임을 평가하고 있다면, 다음 다섯 가지 질문을 던져보십시오:

1. 메모리 (memory)는 어디에 저장되는가?
2. 세션 구조를 재설계하지 않고도 Claude에서 GPT-5나 Grok으로 전환할 수 있는가?
3. 가격이 변동되거나 제공업체가 속도 제한 (rate-limit)을 걸면 어떻게 되는가?
4. 이것이 몇 주 동안 헤드리스 (headless) 상태로 실행될 수 있는가?
5. 이것은 매달 어느 정도의 운영자 주의 (operator attention)를 필요로 하는가?

만약 5번 질문을 무시한다면, 1번 질문은 대개 오래가지 않아 중요하지 않게 될 것입니다.

왜냐하면 서류상으로 가장 뛰어난 아키텍처를 가진 스택이라 할지라도, 귀하의 팀이 그것을 운영하는 것을 싫어한다면 결국 패배하기 때문입니다.

나의 견해

OpenClaw는 죽지 않았습니다.

다중 모델 오케스트레이션 (multi-model orchestration)을 유지하기 위해 셀프 호스팅 에이전트 인프라를 관리하는 것에 지친 팀들이 OpenClaw를 선택하지 않았을 뿐입니다.

그것은 다른 문제입니다.

그리고 그 스레드는 한 가지를 매우 명확하게 보여주었습니다. 그것을 여전히 진지하게 사용하는 팀들은 런타임 제어 (runtime control), 이식 가능한 메모리 (portable memory), 그리고 헤드리스 자동화 (headless automation)를 매우 중요하게 생각한다는 점입니다.

그들은 그것이 유행이라서 사용하는 것이 아닙니다.
그 기능들이 중요하기 때문에 사용하는 것입니다.

문제는 대부분의 팀이 유지 관리의 부담 없이 그러한 이점들을 원한다는 것입니다.

그것이 바로 고정 요금제이면서 OpenAI 호환이 가능한 인프라가 에이전트 빌더들에게 점점 더 흥미로워지고 있는 정확한 이유입니다.

귀하는 다음 중 하나를 선택하지 않고도 제공업체 유연성과 상시 자동화를 유지할 수 있습니다:

• 가공되지 않은 토큰당 과금 (per-token billing)에 대한 불안감
• 또는 매주 셀프 호스팅 런타임을 돌보며 관리하는 것

그것이 "OpenClaw가 죽었는가?"라는 질문 뒤에 숨겨진 진짜 이야기입니다.

죽음이 아닙니다.

단지 운영자의 지속적인 주의를 요구하는 도구들에 대해 시장의 인내심이 훨씬 낮아졌을 뿐입니다.