엔터프라이즈 LLM/에이전트 제품에서 ‘감사추적(audit trail)’은 보안팀의 체크리스트가 아니라 그로스 레버입니다. 이유는 단순합니다. 보안 사고가 터졌을 때 “무슨 일이 있었는지 증명”하지 못하면, 고객은 조사보다 먼저 계약을 멈춥니다. 최근 dev.to에 올라온 LiteLLM 공급망 공격 사례와 ‘관찰성≠감사’ 논쟁은, 감사추적이 결국 CAC를 낮추는 퍼널 최적화 장치라는 걸 정면으로 보여줍니다.
LiteLLM 사건(출처: dev.to, Waxell 글)은 2026-03-24 약 40분 동안(PyPI에 악성 버전이 올라갔다 격리되기까지) 발생한 공급망 공격을 다룹니다. 악성 .pth 페이로드가 SSH 키·클라우드 자격증명·K8s 설정·API 토큰을 수집하고 외부로 유출할 수 있었고, 이후 실제 피해 기업(예: Mercor)에서 대규모 데이터 유출·계약 중단·소송으로 이어졌다는 서사가 따라붙습니다. 여기서 핵심 질문은 기술이 아니라 세일즈 질문입니다. “우리 고객 데이터/세션 중 누가 그 40분 윈도우에 영향을 받았는지, 증명할 수 있나요?”
대부분 팀은 이 질문에 ‘추정’으로 답합니다. 컨테이너 캐시, CI/CD 설치 타이밍, 런타임 재시작, 네트워크 이그레스 등 변수가 많아지면 엔지니어링 로그만으로는 범위를 확정하기 어렵습니다. 그 순간부터 세일즈는 ‘가치’가 아니라 ‘리스크’ 협상으로 바뀌고, 딜은 법무/보안/구매를 끌어들이며 급격히 길어집니다. 즉, CAC가 올라갑니다(더 많은 세일즈 인력 시간, 보안 설문 대응, POC 연장, 할인 압박).
여기서 자주 생기는 착각이 “LangSmith/Langfuse 같은 트레이싱이 있으니 됐다”입니다. dev.to의 Ramon Galego 글은 이 지점을 정확히 찌릅니다. 관찰성 도구는 디버깅을 위한 것이고(빠른 검색, 짧은 보존, 개발자 친화), 감사추적은 감사/규제를 위한 증거입니다(장기 보존, 불변성, 체인 오브 커스터디, 비기술자 가독성). 트레이스가 ‘편집/삭제 가능한 데이터베이스’에 있으면, 사고 이후엔 그 자체가 법무 관점에서 증거로 약합니다. 즉 “보여드릴게요”가 아니라 “증명할게요”가 되어야 퍼널이 통과됩니다.
그로스 관점에서 감사추적은 AARRR의 Acquisition/Retention을 동시에 건드립니다. 첫째, 엔터프라이즈 전환율: 보안 검토 단계에서 가장 비싼 질문은 “사고 대응 시 어떤 증거를 얼마나 빨리 제공하나”입니다. 여기에 답이 준비돼 있으면 보안 설문(SSPQ) 왕복이 줄고, POC에서 ‘리스크 불확실성’이 제거돼 딜 사이클이 단축됩니다. 둘째, 리텐션: 사고 자체보다 더 큰 churn 트리거는 “우리 벤더는 범위를 특정 못한다”는 신뢰 붕괴입니다. Meta가 Mercor 계약을 즉시 중단했다는 사례(같은 기사 내 언급)는, 엔터프라이즈가 ‘조사 완료’를 기다리지 않는다는 신호입니다.
그러면 ‘CAC를 낮추는 감사추적’은 무엇을 남겨야 할까요? LiteLLM 글이 정의한 것처럼, 애플리케이션 로그가 아니라 인프라 레이어에서 정책 강제된 실행 기록이 핵심입니다. 최소 요건은 (1) 모든 LLM 호출, (2) 모든 툴 호출, (3) 외부 네트워크 요청(특히 도메인/목적지), (4) 자격증명 사용 이벤트(어떤 범주의 시크릿이 어느 세션에 노출됐는지), (5) 세션 라이프사이클(시작/종료/재시작)입니다. 그리고 이것이 (a) 세션 단위로 조회 가능하고, (b) 장기 보존되며, (c) 변경 불가능(해시 체인/서명/앵커링 등)해야 합니다.
최근 SDK 업데이트 사례(dev.to, asqav v0.2.9)처럼 output verification·attestation·preflight·budget tracking이 제품화되는 흐름은 힌트를 줍니다. 엔터프라이즈는 “우리 시스템이 안전하다”는 주장보다, 제3자가 검증 가능한 문서(attestation)와 변조 탐지 가능한 기록(output verification)을 원합니다. 이건 기능이 아니라 ‘세일즈 자산’입니다. 보안팀이 원하는 포맷으로 바로 제출 가능하면, 그 순간 세일즈 콜 수(=CAC)가 줄고, 구매 의사결정 속도가 빨라집니다.
시사점은 명확합니다. LLM/에이전트 제품팀은 감사추적을 ‘나중에 컴플라이언스 할 일’로 두면 안 됩니다. 초기부터 이벤트 스키마를 표준화하고(세션·액션·리소스·승인·이그레스·시크릿), 불변 저장소/보존 정책을 제품 패키지에 포함시키세요. 그리고 GTM에선 “우리는 트레이싱이 있습니다”가 아니라 “침해 윈도우가 주어지면 영향을 받은 세션을 결정적으로 특정하고, 고객이 검증 가능한 리포트를 X시간 내 제출합니다”를 약속해야 합니다. 이 한 문장이 보안 검토의 마찰을 줄여 퍼널을 통과시킵니다.
전망: 공급망 공격은 더 잦아지고, ‘공유 의존성(오픈소스+CI/CD 액션)’이 큰 에이전트 스택일수록 폭발 반경이 커집니다. 동시에 EU AI Act, HIPAA 등 보존/증거 요구는 강화됩니다. 관찰성만으로 버티던 팀은 어느 순간 “보안 사고 대응 불가능” 판정을 받고 파이프라인에서 밀려날 겁니다. 반대로 감사추적을 제품의 기본값으로 넣는 팀은, 보안이 비용센터가 아니라 CAC 절감 엔진이 됩니다. 결국 엔터프라이즈 그로스는 ‘기능 경쟁’이 아니라 ‘증거 경쟁’으로 이동하고 있습니다.