에이전트/AI 기능을 제품에 붙일 때 성장 병목은 자주 착각에서 시작합니다. “모델이 더 똑똑해지면 다 해결된다”가 아니라, 에이전트가 첫 작업을 성공적으로 끝내는 온보딩 성공률, 그리고 그 과정에서 생기는 오작동에 대한 신뢰 손실, 마지막으로 운영·지원 비용이 먼저 터집니다. 즉, 전환 퍼널의 첫 단계에서 TTV(Time to Value)가 늘어지고, 셀프서브가 막히며, 결국 CAC가 올라갑니다.
dev.to의 「The Future Is Not the Agent Using a Human Interface」는 이 문제를 “에이전트가 인간용 UI를 억지로 쓰는 마찰”로 정리합니다. 에이전트는 메뉴를 탐색하지 않고 함수를 호출하고, 확인 팝업 대신 초기화 시점의 권한 경계가 필요하며, 사람이 읽는 에러 메시지보다 파싱 가능한 구조화된 출력/오류 계약(contract)을 원합니다. 인간 UI에 에이전트를 태우면 ‘가능은 하지만’ 성공률이 낮고, 실패 시 원인 규명이 어렵고, 재현도 힘듭니다. 성장 관점에선 이게 곧 온보딩 이탈률입니다.
두 번째 dev.to 글(Chrome DevTools Protocol 기반 CLI)은 온보딩 마찰을 줄이는 실전 힌트를 줍니다. 브라우저 자동화에서 가장 큰 마찰은 로그인(OAuth/MFA/CAPTCHA)과 세션 차이인데, CDP로 사용자가 이미 로그인해 둔 라이브 브라우저 세션을 재사용하면 인증 지옥을 스킵합니다. 이를 MCP(Model Context Protocol)로 감싸면, 에이전트가 브라우저를 “스크래핑 UI”가 아니라 표준화된 툴 호출로 다루는 구조가 됩니다. 성장 지표로 번역하면: “연동 설정 30분”이 “포트 열고 바로 실행”으로 바뀌며 TTV가 단축됩니다.
하지만 마찰을 없애려다 더 큰 비용을 부르면(보안 사고/데이터 유출) CAC는 다시 폭발합니다. 세 번째 dev.to 글은 MCP 툴 접근이 암묵적 신뢰(모델이 결정하면 실행)로 굴러가면 프롬프트/파라미터 인젝션, 과권한 툴로 쉽게 뚫린다고 경고합니다. 해결책은 뻔하지만 실행이 중요합니다: (1) 툴 메타데이터/설명 sanitize 및 신뢰 서버 allowlist, (2) 인자 검증·스키마 강제·타임아웃·출력 캡, (3) 최소권한 계정·네트워크 격리·non-root 실행, (4) 모델↔실행 사이 검증 레이어(ToolGuard)로 “기본 거부” 정책.
여기서 시사점은 하나로 수렴합니다. 에이전트 온보딩의 제품 요구사항은 ‘UI 튜토리얼’이 아니라 ‘계약 설계’입니다. 온보딩 체크리스트를 이렇게 바꾸면 퍼널이 열립니다. - 1) 에이전트용 인터페이스를 별도 레이어로 제공: MCP 툴 스키마, 구조화된 성공/실패 응답, 재시도 규칙 - 2) 첫 가치까지의 경로를 “탭 클릭”이 아니라 “단일 작업”으로 재구성: 에이전트가 수행할 최소 작업 1개를 Golden Path로 정의 - 3) 권한은 팝업이 아니라 초기화에서 명시: scope 기반 capability 선언 + 단계적 권한 상승(필요 시만) - 4) 관측성은 온보딩의 일부: 툴 호출 로그, 실패 이유 분류(인증/권한/파라미터/외부의존), 재현 가능한 리플레이
전망은 빠르게 “인간 UI는 유지하되, 비인간 호출자를 위한 계약이 제품 경쟁력”으로 이동합니다. 에이전트 사용량이 늘수록 UI 기반 자동화는 유지비(셀렉터 깨짐, 예외 처리, 지원 티켓)가 기하급수로 증가하고, 반대로 계약+검증+최소권한을 먼저 깔아둔 팀은 온보딩 성공률이 올라가 셀프서브가 열립니다. 결과적으로 세일즈/CS가 하던 ‘연동 대행’이 줄어 CAC가 구조적으로 내려갑니다. 지금은 아직 레거시 UI 위에 임시로 얹어도 버티지만, dev.to가 말하듯 전환 속도는 압축되고 있습니다. 남은 런웨이는 길지 않습니다.