AI/에이전트 제품에서 가장 비싼 장애는 모델이 틀리는 게 아니라, 통제 불가능한 비용과 신뢰 붕괴입니다. 키 하나 유출로 하룻밤 사이 수천~수만 달러가 새고, “왜 나왔는지”도 모르면 가격 정책/온보딩/세일즈 모두가 흔들립니다. 이건 보안 사건이면서 동시에 전환률↓, 리텐션↓, 환불/클레임↑로 이어지는 성장 문제입니다.
dev.to의 한 글은 GCP에서 API 키가 유출됐을 때 자동으로 막아주는 ‘킬스위치’가 사실상 부재하고, 예산 알림은 4~12시간 지연돼 사후 통지에 가깝다고 지적합니다. 공격은 몇 분 내 스캐너로 탐지되고 즉시 호출이 시작되는데, 알림이 도착했을 땐 이미 “여덟 시간짜리 과금”이 끝나 있다는 식이죠. 결국 사용자는 ‘깨어있기’와 ‘수동 삭제’에 운영을 맡깁니다(출처: dev.to, CloudSentinel 사례).
다른 dev.to 글은 OpenAI 사용량 페이지가 얼마를 썼는지(what)는 보여주지만 어디서 썼는지(where)는 못 보여준다는 점을 찌릅니다. 멀티테넌트/멀티기능 제품에선 비용이 “기능·테넌트·대화·실패 요청” 단위로 쪼개져야 실험이 가능합니다. 작성자는 호출을 래핑해 토큰/지연/기능 메타를 저장하고, 처음 대시보드로 두 기능 간 100배 비용 격차를 잡아냈다고 합니다(출처: dev.to, per-call cost dashboard).
세 번째 글은 에이전트 하이재킹이 ‘모델 취약점’이 아니라 런타임 입력(문서/RAG/툴 응답)로도 발생한다고 보여줍니다. 흰 글씨로 숨긴 PDF 지시문 하나로 대화 내역 유출을 시키는 ‘간접 프롬프트 인젝션’은, 사용자 입력만 필터링하는 팀을 정면으로 뚫습니다(출처: dev.to, LLM agent hijack). 즉 비용 통제·관찰성·보안은 기능 뒤에 붙이는 옵션이 아니라, 제품 신뢰의 코어입니다.
그로스 관점에서 해석하면, 위 세 문제는 모두 같은 메커니즘을 가집니다. ① 사고/과금 폭탄/데이터 유출 같은 운영 리스크가 ② CS/환불/장애 공지로 표면화되고 ③ 유입 채널의 전환(Activation)과 유료 전환(Revenue)이 떨어지며 ④ “AI는 불안하다”는 인식이 쌓여 리텐션과 레퍼럴이 붕괴합니다. CAC는 오르고 LTV는 내려갑니다. 신뢰가 깨진 제품은 성능이 좋아도 퍼널이 새는 양동이입니다.
시사점은 명확합니다. 에이전트 제품의 MVP는 ‘기능 데모’가 아니라 운영 안전장치 MVP여야 합니다. 실행 가능한 플레이북으로 정리하면:
1) API 키 킬스위치(요청량 기반): 비용 지표(빌링) 대신 모니터링 지표(요청 수)를 사용해 분 단위로 감지하고, 임계치 초과 시 “프로젝트 전체”가 아니라 문제 키만 폐기합니다. 예산 알림은 보조 수단이고, 1차 방어선은 실시간 요청량입니다(Cloud Monitoring의 request_count처럼).
2) 코스트 옵저버빌리티(Per-call, Per-tenant): OpenAI/LLM 호출은 반드시 래퍼를 통해서만 나가게 하고, tenant_id, feature(endpoint), conversation_id, model, tokens, latency, status, cost를 남깁니다. 핵심은 로그가 서비스 응답을 느리게 하지 않도록 fire-and-forget로 설계하는 것. 이 데이터가 있어야 “모델 다운그레이드/캐싱/프롬프트 다이어트” 같은 COGS 실험이 LTV 개선으로 연결됩니다.
3) 에이전트 런타임 방어(인젝션·툴·메모리): 사용자 입력만이 아니라 RAG 청크/툴 응답을 ‘데이터’로 격리하고, 툴 allowlist + 호출 횟수 제한 + 메모리 신뢰 구획을 둡니다. 보안은 정책 문서가 아니라 미들웨어/게이트로 강제되어야 재현 가능한 운영이 됩니다.
전망: 에이전트 시장이 커질수록 경쟁력은 “더 똑똑한 답변”에서 “더 예측 가능한 운영”으로 이동합니다. 앞으로의 차별화 포인트는 킬스위치/세분화된 비용 원가/런타임 방어를 묶어 SLO(가동률·비용 상한·보안 사고 0)로 제시하는 팀이 가져갈 가능성이 큽니다. 특히 SMB/스타트업 고객일수록 ‘한 번의 과금 폭탄’이 즉시 해지로 이어지기 때문에, 이 레이어를 먼저 깔아두는 제품이 CAC를 더 싸게, 더 오래 회수합니다.