AI 에이전트/LLM을 제품 퍼널에 붙이는 순간, 가장 먼저 터지는 건 ‘기능’이 아니라 ‘사고’입니다. 프롬프트 인젝션으로 툴이 오남용되거나(데이터 과다 조회, 민감정보 유출), 예상치 못한 코드 실행이 파이프라인을 타고 번지면 한 번의 이슈가 곧바로 신뢰 하락→환불/해지→리텐션 붕괴로 이어집니다. 그리고 더 무서운 건, 공격이 아니어도 “도움이 되려는 에이전트”가 비용을 태워서(COGS 폭주) 같은 결과를 만든다는 점입니다.
dev.to의 Biotrackr 사례(Will Velida)는 이 현실을 정면으로 보여줍니다. 겉으로는 “코드 인터프리터 없는 읽기 전용 챗봇”인데도, OWASP가 말하는 LLM05(Improper Output Handling)·ASI(에이전트 보안) 관점의 통제가 여전히 필요하다고 강조하죠. 이유는 단순합니다. 에이전트는 ‘실행 환경(컨테이너) + 툴 호출(파라미터는 LLM 출력에서 생성) + 배포 파이프라인(CI/CD)’을 갖는 순간 이미 공격면을 갖습니다. 즉, 코드 실행 기능이 없더라도 LLM 출력은 신뢰할 수 없는 입력이며, 툴 파라미터가 곧 행동이 됩니다.
맥락을 그로스로 번역하면 이렇게 바뀝니다. 에이전트 제품의 핵심 리스크는 “모델 성능”보다 “행동 반경”입니다. 사용자는 에이전트가 똑똑해질수록 더 많은 권한을 맡기고, 팀은 자동화를 늘릴수록 더 많은 툴을 붙입니다. 이때 권한 경계가 얇으면 한 번의 인젝션/오판이 곧바로 고비용 쿼리, 과다 토큰 사용, 게이트웨이 과부하, 데이터 도메인 횡단 호출로 연결됩니다. 결과적으로 Activation은 잠깐 좋아질 수 있어도(‘와, 된다’) D7부터 “불안/느림/과금폭탄/계정잠김” 경험이 누적되며 Churn이 상승합니다.
Biotrackr가 택한 방어는 전형적인 보안 체크리스트가 아니라, 제품 지표를 지키는 ‘가드레일’입니다. (1) LLM 출력=불신 전제로 모든 툴 파라미터 입력 검증(날짜 파싱, 범위 제한, 페이지 사이즈 캡) (2) 쿼리는 문자열 결합 대신 파라미터라이즈드로 고정 (3) 에이전트가 프로덕션에 직결되지 않게 API 게이트웨이(APIM)로 중계해 인증/레이트리밋/쿼터/킬스위치를 중앙화. 이 조합은 보안뿐 아니라 비용 통제 장치이기도 합니다. “100년치 데이터 뽑아줘” 같은 툴 오남용은 곧바로 토큰·DB·게이트웨이 비용을 폭발시키는데, 하드 리밋이 이를 제품 레벨에서 차단합니다(출처: dev.to의 ‘Unexpected Code Execution’, ‘Tool Misuse’ 글).
시사점은 명확합니다. 에이전트 보안은 ‘컴플라이언스’가 아니라 ‘리텐션/마진’ 문제입니다. 우리가 설계해야 할 건 멋진 프롬프트가 아니라 퍼널 가드레일입니다. 추천하는 실행 단위는 3가지입니다. 첫째, 툴마다 “최소 권한 + 최대 비용” 프로필을 만드세요(읽기 전용, 범위/페이지/빈도 상한). 둘째, 모든 툴 호출은 게이트웨이에서 인증·정책·레이트리밋을 강제하고, 키 폐기만으로 외부행동을 멈출 수 있는 킬스위치를 두세요. 셋째, 온보딩에서 ‘가능한 것’보다 ‘불가능한 것(한도)’을 먼저 고지해 기대치를 맞추세요. 에이전트 경험에서 기대치 관리 실패는 곧 “불안한 제품” 라벨로 이어져 재방문을 깎습니다.
전망: 앞으로 에이전트 제품의 경쟁력은 모델 성능 격차가 아니라, 안전하게 YOLO 모드로 돌릴 수 있는 운영 설계에서 갈립니다. Google의 Gemini CLI 글이 제안하는 것처럼(출처: dev.to GoogleAI), 샌드박스(Docker), 세션/토큰 사용 한도, GitHub·클라우드 권한을 쪼개는 최소권한 토큰/서비스계정은 “자동화의 속도”를 유지하면서도 “사고의 반경”을 줄입니다. 그로스 관점에서 이건 D7/D30 방어 장치이자, 엔터프라이즈 세일즈에서 보안 실사(InfoSec) 통과율을 올리는 매출 레버입니다. 결론은 하나: 에이전트 보안은 비용을 쓰는 일이 아니라, LTV를 지키는 투자입니다.