AI 에이전트를 제품에 붙이는 순간, ‘기능’보다 먼저 팔리는 건 ‘신뢰’입니다. 데모에선 멀쩡하던 에이전트가 프로덕션에서 흔들리면 체감 품질이 떨어지고, 그 즉시 전환율 하락·환불 증가·보안 심사로 인한 세일즈 지연이 발생합니다. 결국 CAC가 올라갑니다. 이번 dev.to 소스 3개는 그 원인을 두 갈래로 찌릅니다: (1) 데모→프로덕션 간극(신뢰성)과 (2) 프롬프트/툴 인젝션(보안). 이 둘은 분리된 문제가 아니라, “에이전트가 예측 가능하게 행동한다”는 동일한 신뢰 지표로 수렴합니다.
첫 번째 축은 ‘프로덕션 신뢰성’입니다. TaskConcierge의 글(“AI Agents in Production…”, dev.to)은 데모가 왜 항상 매끈한지 해부합니다. 컨텍스트가 길어질수록 추론 품질이 열화되고, 툴 호출은 95% 성공률이라도 체인으로 묶는 순간 0.95^n으로 급락합니다. 즉, 사용자 경험은 “가끔 실패”가 아니라 “복합 워크플로우에서 자주 실패”로 인지됩니다. 성장 관점에서 이건 D1에 바로 박힙니다. 온보딩에서 에이전트가 1번만 삐끗해도 ‘이 제품은 불안하다’로 라벨링되고, 이후 같은 채널/같은 메시지로 유저를 더 사와도 전환이 안 되는 상태(채널 효율 붕괴)가 옵니다.
두 번째 축은 ‘보안 신뢰’입니다. Klement Gunndu의 글(“Your AI Agent Will Be Prompt-Injected…”, dev.to)은 프롬프트 인젝션이 OWASP LLM Top 10(2025) 1번 취약점이라는 현실을 전제로, 실버불릿 대신 “공격 비용을 올리고, 탐지하고, 피해를 격리”하는 레이어드 방어를 제안합니다. 입력 검증(모델에 위험 입력을 아예 못 넣기) → 권한 분리(Dual LLM: 비신뢰 입력을 처리하는 격리 모델과 툴 실행 권한 모델 분리) → 출력 제약(Pydantic으로 allowlist) → 행동 모니터링(요청 의도 vs 실제 툴 행동 괴리 탐지). 핵심은 한 문장입니다: ‘원문 사용자 입력이 툴 실행 레이어에 닿지 않게 하라.’ 이 설계 하나가 보안 사고 확률을 줄일 뿐 아니라, 엔터프라이즈 영업에서 보안 질문을 “설명”이 아니라 “아키텍처”로 답하게 만들어 세일즈 사이클을 단축합니다.
세 번째 축은 에이전트 생태계의 새 공격면인 MCP 툴링입니다. Razashariff의 글(“MCPS: Security Layer for MCP…”, dev.to)은 MCP 자체가 메시지 서명/에이전트 아이덴티티/툴 정의 무결성 검증이 없어 ‘툴 포이즈닝’이 구조적으로 가능하다고 지적합니다. 실제로 MCP 관련 CVE와 침해 사례가 짧은 기간에 쏟아졌고, 연구 벤치마크에선 높은 공격 성공률도 언급됩니다. MCPS는 툴 정의 고정(pinning), 호출 서명(ECDSA), 리플레이 방지, 감사를 표준(IETF Draft) 레벨로 올려 “툴 설명 문자열 한 줄로 에이전트를 조종”하는 경로를 차단하려 합니다. 성장 관점에서 이건 ‘보안 기능’이 아니라 “도입 장벽(보안팀·법무·IT)의 마찰을 줄이는 판매 인프라”입니다.
시사점은 명확합니다. 신뢰/보안을 ‘리스크 대응’으로 취급하면 비용만 늘고, CAC는 그대로입니다. 반대로 신뢰를 “계측 가능한 퍼널 변수”로 만들면 CAC를 깎을 수 있습니다. 제안하는 실험 설계는 단순합니다. (1) 데모-프로덕션 갭 계측: 워크플로우별 성공률, 툴 체인 길이별 실패율, 재시도/루프 발생률을 이벤트로 쪼개서 추적. (2) 신뢰 가드레일 A/B: 좁은 작업 범위+휴먼 체크포인트+출력 allowlist 적용군 vs 미적용군의 온보딩 완료율, D7 리텐션, 환불/CS 티켓률 비교. (3) 보안 레이어의 세일즈 효과 측정: Dual LLM/MCPS 같은 아키텍처를 보안 문서(Threat model+감사로그 샘플)로 패키징해, 보안 Q&A 왕복 횟수와 계약 리드타임을 전후 비교. 신뢰는 ‘느낌’이 아니라 전환·리텐션·세일즈 사이클로 환산되는 숫자입니다.
전망을 보자면, 모델 성능은 좋아지겠지만(소스도 12~18개월 개선을 예측) CAC를 좌우하는 건 모델보다 ‘주변 인프라’가 될 가능성이 큽니다. 관측성(observability), 평가(evals), 롤백, 툴 무결성, 권한 분리 같은 “지루한 신뢰 레이어”가 결국 시장을 먹습니다. 멀티 에이전트로 쪼개 디버깅 가능성을 높이자는 흐름도 같은 맥락입니다(신뢰를 구조로 확보). 지금 할 일은 과감한 자율성 데모가 아니라, 실패 모드를 정량화하고(성공률의 분해), 공격면을 격리하며(권한 분리·서명), 그 결과를 퍼널 지표로 연결해 CAC 절감 루프로 만드는 것입니다. 신뢰를 제품의 ‘옵션’이 아니라 성장 엔진의 ‘기본값’으로 두는 팀이 다음 사이클에서 더 싸게, 더 오래 성장합니다.