나는 평소와 다름없는 논쟁을 예상하며 Reddit(레딧)의 토론에 빠져들었습니다. 즉, GPT-5 대 Claude Opus, Gemini 대 DeepSeek, 호스팅형 대 로컬 벤치마크 차트와 같은 내용 말입니다. 하지만 진지한 에이전트(Agent) 사용자들은 그런 것을 두고 논쟁하지 않습니다. r/openclaw의 거대한 스레드를 읽고 실제 설정들을 파헤쳐 본 결과, 저는 실제 전투가 훨씬 더 단순하다는 결론을 내렸습니다. 바로 '누가 워크플로우 표면적(workflow surface area)을 소유하는가?'입니다. 리더보드에서 누가 가장 똑똑한 모델을 가졌느냐가 아닙니다. 업무가 실제로 일어나는 장소들을 누가 통제하느냐의 문제입니다: 편지함(inbox), 캘린더(calendar), 문서(docs), 브라우저(browser), 채팅(chat), 내부 도구(internal tools), 작업 상태(task state), 권한(permissions). 만약 당신이 실제 업무를 위한 에이전트를 구축한다면, 이 질문은 평가(eval) 점수 2%를 더 올리는 것보다 훨씬 더 중요합니다.

유용한 사고 모델: 모델은 범용 제품(commodities)이고, 표면(surfaces)은 해자(moats)이다.
모델은 교체될 수 있습니다. 하지만 워크플로우 표면은 대체하기가 훨씬 더 어렵습니다. 만약 에이전트가 이미 Gmail, Google Docs, Calendar, Drive, Meet, Search, 그리고 Android에 대한 신뢰할 수 있는 접근 권한을 가지고 있다면, 엄청난 우위를 점한 상태에서 시작하는 것입니다. 사용자가 12개의 API를 직접 연결하도록 요구하지 않고도 읽기, 초안 작성, 일정 예약, 검색, 알림, 후속 조치를 수행할 수 있기 때문입니다. 이것이 바로 에이전트 분야에서 Google이 위험한 이유입니다. Gemini가 마법 같아서가 아닙니다. Google은 이미 업무가 발생하는 위치에 자리 잡고 있기 때문입니다.

반면, OpenClaw와 같은 도구들은 다른 방식으로 승리하고 있습니다. 표면을 소유하는 것이 아니라, 당신에게 더 많은 표면에 접근할 수 있는 권한을 부여함으로써 말입니다. 이는 다음과 같은 의미를 갖습니다:

• 제어 평면(control plane)으로서의 Telegram(텔레그램)
• 복잡한 작업을 위한 브라우저 자동화(browser automation)
• 로컬 모델(local model) 지원
• 내부 대시보드에 대한 직접 접근
• 프로젝트 전반에 걸친 지속적 메모리(persistent memory)
• 여러 모델 간의 커스텀 라우팅(custom routing)
  이는 매우 다른 제품 전략입니다. 그리고 솔직히 말해서, 많은 개발자에게 이것이 훨씬 더 흥미로운 전략입니다.

실제 사용자 설정에서 본 것들
이 Reddit 스레드들의 가장 좋은 점은 사람들이 추상적인 이야기만 하지 않았다는 것입니다. 그들은 실제 스택(stacks)을 게시하고 있었습니다. 한 사용자는 Mac Mini M4에서 다음과 같은 설정을 설명했습니다:

• OAuth를 통한 GPT-5
• 기본 인터페이스로서의 Telegram
• 메모리 및 워크플로우 라우팅(workflow routing)
• 프로젝트별 스레드
• 샌드박스(sandbox)로 실행되는 두 번째 프레임워크
  이것은 "어떤 모델이 가장 똑똑한가?"를 묻는 설정이 아닙니다.

그것은 오케스트레이션 (orchestration) 설정입니다. 영리한 디테일은 사용자 한 명과 봇만 있는 Telegram 그룹 하나를 사용한 다음, 프로젝트마다 토픽 (topic)을 생성하여 각 대화가 그 자체로 하나의 작업 세션 (working session)이 되도록 만든 것이었습니다. 이는 투박하고(scrappy) 기묘하지만, 매우 훌륭한 방식입니다. 대형 벤더 (Big vendors)들은 보통 기묘한 방식부터 출시하지 않습니다. 오픈 에코시스템 (Open ecosystems)은 그렇게 합니다. 프로덕션 (production) 환경에서 가장 먼저 무너지는 것은 지능이 아닙니다. 바로 비용과 신뢰성입니다. 이것이 스레드 (threads)에서 얻은 가장 실질적인 교훈이었습니다. 사람들은 주로 모델의 품질에 대해 불평하는 것이 아니었습니다. 그들은 에이전트 (agents)가 멍청한 작업에 돈을 낭비하는 것에 대해 불평하고 있었습니다: 하트비트 체크 (heartbeat checks), 크론 (cron) 트리거 방식의 폴링 상태 확인 (polling status checks), 브라우저 실패 후의 재시도 (retries), 프리미엄 추론 (premium reasoning)이 필요 없는 컨텍스트 (context) 재읽기 등 말입니다. 이것이 많은 "에이전트 데모 (agent demos)"들이 하루 종일 실행될 때 무너지는 지점입니다. 비용이 많이 드는 부분은 종종 어려운 추론 단계가 아닙니다. 그 주변의 쓰레기 같은 작업들입니다. 단순한 라우팅 (routing) 규칙이 모든 곳에 사용되는 더 강력한 모델보다 낫습니다. 많은 팀이 여전히 모델 선택을 다음과 같이 처리합니다: model : claude-opus. 이것은 쉽습니다. 하지만 동시에 Claude Opus가 필요하지 않은 작업에 대해 거대한 청구서를 받게 되는 방식이기도 합니다. 더 현실적인 설정은 다음과 같습니다: agent_routing : { heartbeat_checks : glm-5.1, cron_pings : glm-5.1, browser_research : claude-sonnet-4.6, hard_reasoning : gpt-5.4, local_private_tasks : qwen-3.6-27b }. 그 라우팅 레이어 (routing layer)는 모델 출시의 드라마에 비하면 지루합니다. 하지만 바로 그곳에 당신의 경제성이 달려 있습니다. 만약 당신의 에이전트가 24시간 7일 내내 작동한다면, "모든 곳에 최고의 모델을 쓰는 것"과 "중요한 곳에 최고의 모델을 쓰는 것"의 차이는 장난감과 시스템의 차이입니다. 폐쇄형 에코시스템 (Closed ecosystems) 대 오픈 에코시스템 (open ecosystems). 저는 한쪽이 완전히 승리할 것이라고 생각하지 않습니다. 스택 (stack)이 두 가지 카테고리로 나뉘고 있다고 생각합니다.

카테고리	폐쇄형 생태계 에이전트 (Closed ecosystem agents)	개방형 생태계 에이전트 (Open ecosystem agents)
승리 요인	네이티브 접근 권한 (Native access), 신뢰 (trust), 편의성 (convenience), 세련된 UX, 기업 친화적 권한 관리 (enterprise-friendly permissions)	브라우저 제어 (Browser control), 로컬 모델 (local models), 커스텀 워크플로우 (custom workflows), 내부 도구 (internal tools), 기묘한 글루 코드 (weird glue code), 빠른 실험 가능성 (faster experimentation)
지속 가능한 우위	통합 (Integrations), 메모리 (memory), 라우팅 (routing), 재시도 (retries), 권한 (permissions), 액션 표면 (action surfaces)

만약 다음과 같은 기능이 필요하다면: Gmail, Calendar, Docs, Meet, Android 알림, 관리자 친화적 제어 기능 등이라면 Google 스타일의 생태계를 이기기는 매우 어렵습니다. 반면 다음과 같은 기능이 필요하다면: 브라우저 자동화 (browser automation), Telegram 제어, 로컬 Qwen 또는 Llama 폴백 (fallback), 기묘한 CRM 통합, 직접적인 데이터베이스 접근, 내부 관리 패널, 커스텀 롱러닝 워크플로우 (custom long-running workflows) 등이라면 개방형(open) 측면이 매우 빠르게 매력적으로 다가올 것입니다.

개발자가 "워크플로우 표면적 (workflow surface area)"에 주목해야 하는 이유

왜냐하면 이것이 에이전트를 구축하는 방식을 바꾸기 때문입니다. 만약 여러분이 여전히 주로 "가장 좋은 모델 하나를 고르는 것"의 관점에서 생각하고 있다면, 여러분은 잘못된 레이어 (layer)를 최적화하고 있는 것입니다. 진짜 아키텍처 (architecture) 질문은 다음과 같은 것들에 가깝습니다:

• 에이전트는 어디에 존재하는가?
• 에이전트가 건드릴 수 있는 시스템은 무엇인가?
• 어떤 상태 (state)를 유지하는가?
• 어떤 단계에 프리미엄 추론 (premium reasoning)이 필요한가?
• 어떤 단계는 저렴하게 처리할 수 있는가?
• 브라우저 자동화가 실패하면 어떻게 되는가?
• 관리 비용 (babysitting cost) 없이 어떻게 계속 실행되게 할 것인가?

이것이 바로 실질적인 에이전트 스택 (agent stack)입니다. 단순히 프롬프트 (prompts)만이 아닙니다. 단순히 평가 (evals)만이 아닙니다. 단순히 모델 선호도 (model preference)의 문제도 아닙니다.

더 현실적인 에이전트 아키텍처

이것은 대부분의 AI 데모보다 실제 프로덕션 (production) 환경에 더 가깝습니다:

• 인터페이스 (Interface): Telegram / Slack / 이메일
• 메모리 (Memory): 공유 벡터 스토어 (shared vector store) + 태스크 상태 (task state)
• 라우팅 (Routing): 일상적인 작업에는 저렴한 모델, 예외 케이스 (edge cases)에는 프리미엄 모델
• 액션 (Actions): 브라우저, 문서, 캘린더, CRM, 내부 도구
• 폴백 (Fallbacks): 클라우드 접근이 차단되었을 때 로컬 Qwen 또는 Llama 사용
• 관측 가능성 (Observability): 로그 (logs), 재시도 (retries), 알림 (alerts), 사용량 추적 (usage tracking)

이것은 챗봇 (chatbot)이 아닙니다. 이것은 운영 레이어 (operating layer)입니다.

아무도 인정하고 싶지 않은 비용 문제

많은 팀이 에이전트 경제학 (agent economics)이 여전히 엉망이라는 사실을 조용히 깨닫고 있습니다. 하루에 몇 번 실행되는 Zapier AI 에이전트는 허술한 오케스트레이션 (orchestration)으로도 버틸 수 있습니다. 하지만 진정한 '항상 켜져 있는 (always-on)' 에이전트는 그럴 수 없습니다.

만약 당신의 시스템이 끊임없이 다음과 같은 작업을 수행하고 있다면: API 폴링 (polling), 편지함 확인, 스레드 재요약, 브라우저 단계 재시도, 모든 상황을 가장 비싼 모델로 에스컬레이션 (escalating)하는 작업 등. 그렇다면 설령 데모가 훌륭해 보였을지라도 당신의 아키텍처 (architecture)는 망가진 것입니다. 이것이 바로 에이전트에게는 일반적인 채팅보다 예측 가능한 컴퓨팅 (predictable compute)이 더 중요한 정확한 이유입니다. 에이전트는 지속적입니다. 루프 (loop)를 돌고, 재시도하며, 무언가를 관찰하고, 백그라운드 작업을 수행합니다. 이는 토큰당 과금 (per-token billing) 방식이 매우 빠르게 고통스러워질 수 있음을 의미합니다. 단일 요청이 비싸기 때문이 아니라, 시스템이 실제로 멈추지 않기 때문입니다.

이 모든 것을 읽고 난 후, 내가 다르게 구축할 것들

만약 내가 오늘 에이전트 스택 (agent stack)을 설계한다면, 다음과 같은 순서로 최적화할 것입니다:

1. 인터페이스 (interface)를 점유하라
   사용자가 이미 머물고 있는 장소를 선택하십시오. 예시: Slack, Telegram, 이메일, 브라우저 확장 프로그램 (browser extension), 내부 운영 대시보드 (internal ops dashboard)

2. 프리미엄 모델 사용을 최소화하라
   실패 비용이 큰 경우에만 가장 강력한 모델을 사용하십시오. 예시: 계약서 검토 (contract review), 모호한 브라우저 복구 (ambiguous browser recovery), 장기 계획 수립 (long-horizon planning), 부작용이 있는 코드 생성 (code generation with side effects)

3. 오케스트레이션 (orchestration)을 제품으로 취급하라
   당신의 해자 (moat)는 단순히 모델만이 아닙니다. 그것은 다음의 조합입니다: 메모리 (memory), 라우팅 (routing), 재시도 (retries), 권한 (permissions), 도구 액세스 (tool access), 상태 관리 (state management)

4. 장기 실행 경제성 (long-running economics)을 고려하여 설계하라
   에이전트가 하루 종일 실행된다고 가정하십시오. 만약 비용 모델이 데모에서만 작동한다면, 그것은 작동하는 것이 아닙니다.

구체적인 개발 설정 (dev setup)

현재 에이전트를 실험 중이라면, 실질적인 스택은 다음과 같을 수 있습니다:

예시 서비스

agent-api
worker
browser-runner
memory-store: postgres, redis
telegram-bot
observability

그리고 당신의 라우팅 레이어 (routing layer)는 다음과 같이 간단할 수 있습니다:

function pickModel ( taskType : string ) {
switch ( taskType ) {
case " heartbeat " :
case " polling " :
return " glm-5.1 " ;
case " browser_research " :
return " claude-sonnet-4.6 " ;
case " hard_reasoning " :
case " critical_planning " :
return " gpt-5.4 " ;
case " private_local_task " :
return " qwen-3.6-27b " ;
default :
return " gpt-5.4 " ;
}
}

이 함수 하나가 일주일간의 벤치마크 논쟁보다 더 중요할 수 있습니다.

에이전트가 데모를 넘어 프로덕션 (Production) 단계로 넘어가면, 트위터에 올리기에는 재미없지만 신경 써야만 하는 문제들이 나타나기 시작합니다. 이것이 바로 비즈니스의 전부가 되는 지루한 인프라 문제입니다.

• 요청 라우팅 (Request routing)
• 동시성 제한 (Concurrency throttling)
• 재시도 (Retries)
• 배치 처리 (Batching)
• 모델 폴백 (Model fallback)
• 비용 상한선 (Cost ceilings)
• 상시 가동 사용 패턴 (Always-on usage patterns)

이 지점에서 많은 팀이 표준 API 가격 책정 방식의 한계에 부딪힙니다. 사람이 수동으로 프롬프트를 입력할 때는 토큰당 과금 (Per-token billing) 방식도 견딜 만합니다. 하지만 소프트웨어가 끊임없이 프롬프트를 생성할 때는 상황이 훨씬 악화됩니다. 이것이 바로 "에이전트를 위한 무제한 컴퓨팅 (Unlimited compute for agents)"이 단순한 가격 마케팅 용어가 아닌 이유입니다. 이는 당신이 무엇을 자동화할 의지가 있는지를 변화시킵니다.

만약 당신의 n8n, Make, Zapier, OpenClaw 또는 커스텀 에이전트 워크플로우 (Workflow)가 루프를 돌 때마다 토큰 소비를 걱정해야 한다면, 결국 두려움을 바탕으로 설계를 하게 됩니다. 반면 비용이 예측 가능하다면, 처리량 (Throughput)과 신뢰성 (Reliability)을 중심으로 설계하게 됩니다. 그것이 훨씬 더 나은 구축 환경입니다.

장기적인 자동화를 실행하는 팀들에게 주목할 만한 부분은 다음과 같습니다. 고정 월정액을 제공하는 OpenAI 호환 API를 그대로 사용하면, 기존의 오케스트레이션 (Orchestration) 로직은 유지하면서도 모든 백그라운드 작업을 과금 리스크로 취급하지 않아도 됩니다. 이것이 Standard Compute가 가진 실질적인 매력입니다.

나의 견해
다음 AI 에이전트 전쟁은 일차적으로 Gemini 대 GPT-5 대 Claude의 대결이 아닙니다. 그 싸움도 중요하지만, 그것은 하류 (Downstream)의 문제입니다. 상류 (Upstream)에서의 싸움은 다음과 같습니다: "누가 당신의 일상적인 워크플로우 접점을 점유하는가?"

만약 Google이 신뢰할 수 있는 접점들을 소유하게 된다면, 그들은 무시무시하게 강력해질 것입니다. 만약 OpenClaw와 같은 도구들이 특이한 워크플로우들을 계속 점유한다면, 그들은 가장 창의적인 사용자들을 계속 끌어들일 것입니다. 그리고 승리하는 팀은 단순히 좋은 모델만을 가진 팀이 아닐 것입니다. 그들은 다음을 보유하게 될 것입니다:

• 실제 업무 접점에 대한 최고의 접근성
• 최고의 오케스트레이션 레이어 (Orchestration layer)
• 최고의 라우팅 로직 (Routing logic)
• 최고의 메모리 및 도구 제어 (Memory and tool control)
• 에이전트가 하루 종일 작동할 수 있게 하는 비용 구조

마지막 부분은 여전히 과소평가되어 있습니다. 모델의 지능도 중요합니다. 하지만 진정한 에이전트에게는 워크플로우 중력 (Workflow gravity)이 더 중요합니다.