LLM/에이전트를 제품에 붙이는 팀이 늘수록, 경쟁 우위는 ‘답변 품질’이 아니라 ‘신뢰(보안/검증)’에서 갈립니다. dev.to의 LLM API 보안 글이 지적하듯, 대부분의 팀은 정답률·톤·문맥 유지 같은 해피패스만 테스트하고, “시스템 프롬프트를 유출할 수 있는가?”, “콘텐츠 속 악성 지시문을 따라가는가?”, “허용되지 않은 툴을 호출하려 드는가?” 같은 실패 경로는 거의 검증하지 않습니다. 문제는 이 실패가 기능 버그가 아니라 ‘도입 전환율’을 깨는 세일즈 리스크로 번역된다는 점입니다.
맥락을 성장 관점으로 해석하면 명확합니다. PoC에서는 공격적 사용자가 없고 데이터도 얕아서 티가 안 납니다. 하지만 확장 국면에서 이메일·PDF·티켓·웹페이지 등 “모델이 읽는 모든 것”이 인젝션 벡터가 되면서, 간접 프롬프트 인젝션과 툴 남용이 현실로 바뀝니다(출처: dev_to/ammarj). 이때 보안 사고가 한 번이라도 터지면, 보안 심사 체크리스트가 길어지고 법무·컴플라이언스가 끼며, 구매 의사결정자는 ‘도입’ 대신 ‘보류’를 택합니다. 즉, 리스크는 기술 부채가 아니라 CAC를 밀어 올리는 퍼널 병목입니다.
LLM API가 전통적인 API와 다른 이유도 CAC와 직결됩니다. 전통 API는 입력을 검증하면 코드가 의도대로 실행되지만, LLM은 “토큰을 보고 더 설득력 있는 지시를 따르려는” 논리 레이어입니다. 공격자는 코드 취약점을 찾지 않아도 됩니다. 우리보다 더 강한 지시문을 쓰면 됩니다. 그래서 시스템 프롬프트를 단순 ‘가이드’가 아니라 ‘보안 경계’로 다루고(유출/요약 금지, 역할 고정, 인코딩된 문자열은 데이터로만 취급, 허용 툴 명시), 서버사이드에서 모델 출력을 불신(trust-no-one)하며, 툴 권한을 최소화(least privilege)해야 합니다(출처: dev_to/ammarj).
여기에 두 번째 글이 중요한 힌트를 줍니다. AWS Bedrock처럼 “프롬프트를 저장/학습하지 않는다”는 외곽 경계(perimeter)는 강해지고 있지만, 에이전트가 실제로 추론하는 ‘내부’에는 여전히 민감정보가 원문 그대로 들어가는 경우가 많습니다(출처: dev_to/obed_mpaka). 에이전트는 의사결정을 위해 주민번호/카드번호 ‘값’이 아니라 “값이 존재한다/타입이 무엇이다/어떤 액션을 해야 한다”가 필요할 때가 많습니다. 즉, 토큰화·마스킹을 “출력에서 가리는” 사후처리로 두면 늦고, 프롬프트에 들어가기 전부터 안전한 플레이스홀더로 치환해 모델이 원문을 애초에 보지 않게 만드는 구조가 신뢰를 만듭니다.
세 번째 글은 ‘검증 가능성’이 신뢰를 어떻게 제품화하는지 보여줍니다. MCP 기반 에이전트 툴 콜은 기본적으로 “에이전트가 그랬다고 주장하는 로그”에 의존합니다. Agent Receipts처럼 툴 콜마다 서명된 영수증(Ed25519, 해시 체인)을 남겨 사후에 독립적으로 검증 가능하게 만들면(출처: dev_to/ojongerius), 보안팀/감사팀/구매팀의 질문이 바뀝니다. “믿어도 되나요?”가 아니라 “어떤 증거로 증명하나요?”로 전환됩니다. 이 한 문장 차이가 엔터프라이즈 세일즈에서 시간을 줄이고, 결과적으로 CAC를 낮춥니다.
시사점은 실행 항목으로 쪼개야 합니다. (1) 출시 체크리스트를 ‘품질 QA’에서 ‘적대적 QA’로 바꾸세요: 시스템 프롬프트 유출, 간접 인젝션, 역할/정책 혼선, 장문 대화에서의 규칙 붕괴(long-context decay), 툴 남용을 테스트 케이스로 고정합니다(OWASP LLM Top 10 정렬 권장). (2) 에이전트가 제안(propose)하고 서버가 결정(decide)하는 구조로 툴 실행을 분리합니다. (3) 민감정보는 “모델에 주지 않는” 방향(토큰화/플레이스홀더/실행 시점 해제)으로 재설계합니다. (4) 로그는 ‘설명’이 아니라 ‘증거’가 되도록 서명/검증 레이어를 붙입니다.
전망: 에이전트가 자동화하는 업무가 결제·청구·진료·권한 변경처럼 고위험 영역으로 이동할수록, 신뢰 레이어는 비용이 아니라 성장 기능이 됩니다. 앞으로의 경쟁은 “더 똑똑한 모델”보다 “더 짧은 세일즈 사이클”에서 결정날 가능성이 큽니다. 그리고 그 세일즈 사이클을 줄이는 가장 직선의 방법은, 제품이 신뢰를 ‘설명’하는 게 아니라 신뢰를 ‘증명’하는 것입니다. 팀이 지금 해야 할 일은 하나입니다. 다음 분기 CAC를 낮추고 싶다면, 에이전트를 더 붙이기 전에 ‘에이전트가 실패하는 방식’을 먼저 제품화해 두세요.