AI 에이전트를 유입·전환의 ‘프로덕션 채널’로 붙이면, 모델 성능은 생각보다 늦게 문제를 일으킵니다. 실제로 CAC를 흔드는 첫 번째 변수는 운영 안정성(상태 유지, 재시작, 장기 실행)과 COGS(토큰+오케스트레이션+브라우저 런타임)입니다. 채널이 되려면 24/7로 돌아가야 하고, 24/7은 곧 비용 구조와 실패 확률의 게임입니다.
dev.to의 현장 정의는 이 포인트를 정확히 찌릅니다. 에이전트는 “Observe→Decide→Act→Persist” 루프를 갖춘 소프트웨어이며, Persist(상태 지속)가 빠지면 챗봇에 가깝다(Elena Revicheva, dev.to). 그로스 관점에서 Persist는 기능이 아니라 ‘전환 파이프라인의 내구성’입니다. 상태가 날아가면 사용자는 같은 정보를 다시 입력하고, 퍼널은 매번 초기화되며, 그 순간 전환율이 떨어져 CAC가 올라갑니다.
문제는 상태가 단순 대화 히스토리가 아니라는 점입니다. 기사에서 말하는 것처럼 대화/유저/태스크/환경 상태가 층으로 쌓이고, 컨테이너가 죽거나 수평 확장되면 일관성 유지가 지옥 난이도가 됩니다. 여기서 흔한 실수는 “컨텍스트 윈도우에 다 넣자”인데, 토큰은 비싸고, 배포/재시작 시 날아가며, 무엇보다 운영적으로 디버깅 불가능해집니다. 상태를 DB/스토어로 분리하고, 스텝마다 필요한 상태만 ‘컴파일’해 올리는 설계가 결국 실험 회전수를 지킵니다.
장기 실행 품질 저하도 CAC 이슈로 직결됩니다. 다른 dev.to 글은 30~40분 구간에서 에이전트가 목표를 잃고 반복/퇴행하는 ‘reasoning decay’를 설명합니다(Frank_brsrk, dev.to). 수학적으로 스텝 신뢰도가 95%여도 20스텝 성공확률은 36%로 떨어집니다. 이건 “똑똑한 모델”로만 해결되지 않습니다. 장기 태스크를 짧은 태스크로 쪼개고(플래너-워커), 실패 신호를 구조화하고, 컨텍스트를 누적이 아니라 큐레이션해야 ‘재시도 비용’이 폭발하지 않습니다. 재시도는 곧 LLM 콜 증가, 대기시간 증가, 이탈 증가입니다.
마지막으로, 브라우저 자동화는 많은 팀의 COGS를 조용히 태웁니다. 관리형 헤드리스 브라우저가 분당 과금(세션-미닛)인 시장에서, 하루 1,000페이지×2분만 돌아도 월 수천~수만 달러가 나갑니다. 그래서 Playwright를 self-host하고 브라우저 풀/세션 매니저/태스크 큐로 90% 유스케이스를 커버했다는 사례가 나옵니다(refaatalktifan, dev.to). 그로스 해석은 간단합니다. 브라우저 비용을 깎으면 “새 기능”이 아니라 “퍼널 실험 탄약”이 늘어납니다. 같은 예산으로 더 많은 랜딩/온보딩/CTA 테스트를 돌릴 수 있고, CAC는 구조적으로 내려갑니다.
시사점은 세 가지입니다. (1) 에이전트를 채널로 쓰려면 ‘상태’를 제품 데이터 모델로 승격해야 합니다: 유저 단계, 진행률, 실패 원인, 롤백 포인트를 이벤트로 남기고 재시작 가능하게. (2) 장기 실행은 품질 문제가 아니라 확률 문제이므로, 태스크 분해·검증·리커버리 루프를 먼저 설계해야 합니다: “계속 생각하는 에이전트”가 아니라 “짧게 실행하고 검증하는 워크플로우”가 이깁니다. (3) COGS는 토큰만이 아닙니다. 오케스트레이션/DB 왕복/브라우저 런타임까지 포함한 ‘액션 1회당 비용’을 정의하고, 가장 비싼 액션부터 캐시·풀링·라우팅으로 깎아야 합니다.
전망: 에이전트 경쟁은 곧 ‘운영 능력’ 경쟁으로 수렴합니다. Observe-Decide-Act-Persist를 갖춘 순간, 당신은 LLM 앱이 아니라 분산 시스템을 운영하게 되고, 그 운영 품질이 전환율과 CAC를 지배합니다. 다음 라운드의 그로스 팀은 카피/크리에이티브만 보는 팀이 아니라, 상태·장기 실행·브라우저 비용을 깎아 실험 회전수를 폭발시키는 팀일 겁니다. 결국 CAC는 마케팅이 아니라, 운영 설계에서 먼저 무너집니다.