옵저버빌리티 로그가 프롬프트 인젝션 통로가 될 때: Sentry의 2단계 탐지 파이프라인과 결정 모델(Clef)·ModernBERT 전환기

비신뢰 에러 로그 유입부터 1차 고속 분류기(Clef·ModernBERT)와 2차 엄격 검증자(Strict Reviewer)를 거치는 Sentry의 2단계 프롬프트 인젝션 방어 파이프라인 개념도

옵저버빌리티 수집 파이프라인에서 이슈 생성 직전에 프롬프트 인젝션을 차단하는 2단계 아키텍처 개념도다.

Cloudflare 공식 개발자 채널에 공개된 Cloudflare Connect 2026 세션 영상(Sentry at Cloudflare Connect: The prompt is lava)은 에러·로그·트레이스를 수집하는 옵저버빌리티(observability) 플랫폼이 AI 코딩 에이전트 및 MCP(Model Context Protocol)와 결합할 때 발생하는 새로운 프롬프트 인젝션 위협과, 이를 하루 수억~10억 건 규모에서 파산하지 않고 걸러내는 탐지 파이프라인 설계를 다룬다. Sentry의 엔지니어 Greg는 외부 클라이언트에서 유입되는 에러 데이터를 검증하기 위해 범용 LLM에서 시작해 Cloudflare Clef 같은 결정 모델(decision model), 그리고 150M 파라미터급 텍스트 인코더(ModernBERT)로 탐지 계층을 진화시킨 과정을 공유했다.

결론부터 말하면, 하루 수억 건의 비신뢰 텔레메트리 중 실제 악성 인젝션 시도가 100건 안팎에 불과한 환경에서는 모든 이벤트에 범용 LLM을 태우는 방식이 비용 면에서 성립하지 않으며, 1차 고속 필터(휴리스틱·결정 모델·경량 인코더)로 99.9999%의 정상 이벤트를 걸러낸 뒤 극소수의 의심 건만 고성능 검증 모델(Strict Reviewer)로 넘기는 2단계 파이프라인을 구축해야 한다. 다만 이 글은 Cloudflare Connect 2026 발표 영상과 관련 기술 문서를 교차 검증해 파이프라인 구조와 비용·성능 특성을 정리한 것이며, 자체 수집 데이터셋에서 각 분류기의 정밀도(Precision)·재현율(Recall)을 직접 측정한 벤치마크 결과는 아니다.

왜 옵저버빌리티 플랫폼이 프롬프트 인젝션의 진입점이 되는가

프론트엔드 앱이나 모바일 클라이언트에 탑재되는 Sentry SDK는 공개된 수집 엔드포인트인 DSN(Data Source Name)을 통해 에러와 스택 트레이스를 Relay 서버로 전송한다. 이 데이터는 본질적으로 신뢰할 수 없는 외부 입력(untrusted input)이다. 과거에는 대시보드에서 사람이 눈으로만 에러를 읽었기 때문에 에러 메시지 안에 이상한 문구가 들어 있어도 큰 문제가 되지 않았다.

하지만 최근 개발 조직들이 로컬 코딩 에이전트에 옵저버빌리티 MCP 서버를 연결하거나 Sentry Seer 같은 자동 근본 원인 분석(RCA)·디버깅 에이전트를 붙이면서 공격 표면이 달라졌다(CSA Agentjacking 분석 보고서). 공격자는 의도적으로 조작된 에러 메시지를 클라이언트에서 발생시켜 이슈로 등록시킨다.

방어자 입장에서 이 공격을 차단할 수 있는 지점은 크게 세 곳이지만, 효과는 뚜렷하게 갈린다.

이슈 생성 직전(Pre-Issue Creation, 최적 차단 지점): 인바운드 이벤트가 실제 이슈로 롤업(roll-up)되어 웹훅이나 자동화 파이프라인을 깨우기 전에 악성 여부를 판별해 폐기(squash)한다.

자체 에이전트(Seer)의 도구 호출 계층: 플랫폼이 직접 통제하는 에이전트 내부에서 매 툴 호출마다 가디언(guardian) 모델을 돌리는 방식이다. 효과적이지만 이미 생성된 이슈를 외부 도구가 읽는 것은 막지 못한다.

외부 MCP 응답 태깅(Tagging): MCP 서버가 반환하는 페이로드에 untrusted data 블록 태그를 붙여주더라도, 이를 소비하는 클라이언트 측 에이전트가 그 경계를 무시하고 명령을 실행하면 플랫폼 차원에서는 강제할 방법이 없다.

1억 건에서 10억 건으로: 탐지 모델 계층별 비용과 오탐률(False Positive) 트레이드오프

이슈 생성 직전에 모든 에러를 검사하려 할 때 가장 큰 장벽은 트래픽 규모와 오탐(False Positive) 비용이다. 하루 수억 건의 이벤트 중 실제 프롬프트 인젝션 공격은 약 100건 수준이다. 따라서 Sentry는 1차 저비용 패스(Cheap Pass)에서 의심스러운 이벤트만 추려내고, 2차 엄격 검증자(Strict Reviewer, Claude Opus급 대형 모델)가 최종 판정을 내리는 2단계 구조를 택했다.

발표(08:20~15:10)에서 비교한 네 가지 1차 필터링 모델 계층의 특성은 다음과 같다.

일 1,000만 건에서 10억 건 규모로 확장할 때 소형 LLM, 결정 모델(Clef), 텍스트 인코더(ModernBERT 150M), 초소형 증류 모델(4M)의 비용·특성 변화를 비교한 다이어그램이다.

1차 필터링 계층	대표 모델 및 파라미터 규모	핵심 동작 방식	비용·지연 시간 및 파이프라인 트레이드오프
소형 범용 LLM	`gpt-oss` 등 소형 생성형 모델	휴리스틱으로 줄인 일 1,000만 건에 대해 텍스트 생성 방식으로 악성 여부 질의	정확도는 준수하지만 일 10억 건(100배)으로 확장 시 추론 비용이 기하급수적으로 증가해 경제성 상실
결정 모델 (Decision Models)	Cloudflare Clef (27B / Flash 9B), `Jev`, `Mercury Decide`	자유 텍스트 생성 대신 입력 상태와 스키마에 대해 `0~1` 사이의 확률값만 즉시 출력 (출력 토큰 과금 없음)	소형 LLM 대비 약 1/3 비용 및 높은 정확도 달성. 단, 일부 결정 모델은 정상 이슈까지 과도하게 플래그(동일 부하에서 최대 50만 건 오탐)하여 2차 대형 모델 검증 비용을 폭증시킴
파인튜닝된 텍스트 인코더	ModernBERT-base, `mmBERT` (약 150M 파라미터)	양방향 어텐션 레이어를 거쳐 문자열에 바로 분류 점수를 매기는 전용 인코더를 GCP `L4 GPU`에 자체 호스팅	수십억 파라미터 모델 대비 훨씬 빠르고 저렴함(유사 부하 기준 약 `$12K` 수준). 초기 파인튜닝만으로 90% 이상 정확도 확보 후 섀도잉 테스트 진행 중
지식 증류 초경량 분류기 (목표 단계)	4M 파라미터급 초소형 증류(Distilled) 모델	150M 인코더와 상위 결정 모델·LLM의 출력(dark knowledge)을 4M 모델로 지식 증류	추론 지연 시간 1ms 미만, 전체 부하에서 일 `$700` 수준까지 비용 절감 가능. 모든 수집 파이프라인에 동기식(synchronously) 인라인 배치 가능

여기서 핵심 교훈은 1차 필터의 재현율(Recall)만 높다고 좋은 것이 아니라는 점이다. 1차 모델이 공격을 놓치지 않으려고 정상 에러 로그까지 의심 건으로 분류(False Positive)해 버리면, 수십만 건의 이벤트가 비싼 2차 Strict Reviewer로 넘어오면서 전체 파이프라인 비용이 오히려 폭발한다. 이 때문에 정밀하게 보정된(calibrated) 확률을 반환하는 Cloudflare Clef 계열 결정 모델이나 도메인 데이터로 직접 학습한 ModernBERT 분류기가 유리하다.

프로토타이핑과 스케일업의 경계: 결정 모델로 시작해 전용 인코더로 내려가기

발표자는 처음부터 자체 ML 학습 파이프라인을 구축하는 것은 개발자 경험(DX) 측면에서 비효율적이라고 지적한다. 따라서 트래픽 규모와 성숙도에 따라 단계적으로 접근하는 전략이 합리적이다.

초기 검증 및 중소 규모 트래픽: 별도 인프라 구축 없이 API 호출만으로 바로 쓸 수 있는 결정 모델(Workers AI의 Clef / Clef-flash)을 1차 필터로 배치하고, 자사 에이전트(예: Seer)의 실제 실행 경로에 있는 소량 트래픽에서 대형 모델로 2차 교차 검증(back-test)을 수행하며 경계선(on-the-cusp) 사례 데이터를 모은다.

대규모 트래픽 확장 및 다목적 재활용: 파이프라인의 유효성이 입증되고 일 수천만~수억 건 규모로 넘어가면, 축적된 판정 데이터를 라벨링해 150M급 인코더(ModernBERT 등)를 파인튜닝한다. 한 번 분류기 학습·서빙 루프를 구축해 두면 프롬프트 인젝션 탐지뿐 아니라 스팸 이벤트 필터링이나 텔레메트리 신호 분류에도 그대로 재사용할 수 있다.

옵저버빌리티 연동 에이전트를 운영할 때 확인할 점

사내에서 Sentry, Datadog, Grafana 등의 MCP 서버를 코딩 에이전트나 온콜(on-call) 자동화 워크플로에 연결해 쓰고 있다면 다음 기준을 즉시 점검해야 한다.

에러 로그와 스택 트레이스를 비신뢰 입력으로 취급: 운영 환경의 에러 메시지, 사용자 입력 본문, HTTP 헤더는 외부 사용자가 임의로 조작할 수 있는 텍스트다. 에이전트가 이슈 내용을 읽은 뒤 확인 절차 없이 셸 명령(npm install, pip install)이나 외부 네트워크 호출을 자동 실행하지 못하도록 샌드박스와 쓰기 도구 승인(human-in-the-loop)을 강제해야 한다.

입력 분류기와 도메인 신호(패키지 인덱스 등)의 결합: 텍스트 분류기 하나만으로 모든 변종 인젝션을 막기는 어렵다. 에러 로그 안에 특정 패키지 설치 지시가 포함되어 있다면, 분류기 점수와 별개로 해당 패키지 이름이 실제 사내·공식 레지스트리에 존재하는 정상 패키지인지 임베딩·인덱스로 교차 확인하는 신호를 결합하는 편이 안전하다.

1차 필터 선택 시 오탐(Benign Flagged)에 따른 2차 검증 비용 계산: 저비용 분류기나 결정 모델을 앞단에 둘 때는 단일 호출 단가만 보지 말고, 정상 트래픽의 몇 퍼센트가 2차 대형 모델로 에스컬레이션되는지(False Positive Rate)를 합산해 총 소유 비용(TCO)을 계산해야 한다.

결국 AI 에이전트가 외부 모니터링 시스템의 눈과 손을 대신하게 될수록, 옵저버빌리티 파이프라인 자체가 보안 게이트웨이 역할을 겸해야 하며 그 성패는 ‘정확한 탐지’를 ‘감당 가능한 추론 단가’ 안에 맞추는 엔지니어링에 달려 있다.