Cloudflare Clef 공개: LLM 대신 decision model을 써야 하는 순간

Cloudflare가 Clef와 Clef-flash를 공개했습니다. 두 모델은 Workers AI에서 실행되는 오픈소스 decision model이며, Apache 2.0 라이선스로 Hugging Face에도 공개됐습니다. Cloudflare 개발자 changelog는 Clef가 typed answer와 probability를 반환하며, 10개 decision benchmark 중 7개에서 앞서고, Jev보다 최대 13배 빠르게 동작한다고 설명합니다. Cloudflare 블로그는 여기에 강화학습(RL) 기반 fine-tuning 플랫폼까지 함께 발표했습니다.

이 소식이 중요한 이유는 단순히 “새 모델이 나왔다”가 아닙니다. 최근 에이전트 시스템에서 가장 많이 반복되는 작업은 장문의 답변 생성이 아니라 짧은 판단입니다. 이 요청을 어느 팀에 보낼지, 이 사용자를 차단할지, 이 문서를 검색할지, 이 작업을 사람에게 넘길지 같은 결정입니다. 이런 작업에 매번 범용 LLM을 호출하면 비용, 지연, 파싱 실패가 쌓입니다. Clef는 이 문제를 정면으로 겨냥합니다.

decision model이란 무엇인가

decision model은 자유 형식 텍스트를 생성하기보다, 미리 정의된 선택지에 대해 확률을 반환하는 모델입니다. 예를 들어 고객 문의가 들어왔을 때 “긴급 여부: 예/아니오”, “담당 팀: 결제/기술지원/영업”, “사람 승인 필요: 예/아니오” 같은 질문을 던지면 각 답변의 확률을 돌려줍니다. 결과는 코드가 바로 사용할 수 있는 구조화된 값입니다.

범용 LLM도 같은 일을 할 수 있습니다. 프롬프트에 JSON으로 답하라고 지시하면 됩니다. 하지만 운영 환경에서는 세 가지 문제가 생깁니다. 첫째, JSON 형식이 깨질 수 있습니다. 둘째, 선택지 밖의 말을 덧붙일 수 있습니다. 셋째, 토큰 생성 과정 때문에 짧은 판단에도 불필요한 지연이 생깁니다. decision model은 이 지점을 줄이기 위해 만들어진 도구입니다.

Cloudflare는 Clef가 입력 상태와 typed question을 읽고 허용된 답변마다 확률을 반환한다고 설명합니다. 즉, 에이전트가 다음 행동을 고르는 라우터로 쓰기 좋습니다. “이 요청은 검색으로 충분한가, 결제 API를 호출해야 하는가, 사람에게 넘겨야 하는가”처럼 workflow 중간에서 계속 필요한 판단을 저렴하고 빠르게 처리할 수 있습니다.

Clef가 겨냥하는 실무 문제

첫 번째 문제는 LLM 비용입니다. 많은 팀이 에이전트 PoC를 만들 때 모든 판단을 하나의 큰 모델에 맡깁니다. 처음에는 편합니다. 하지만 트래픽이 늘면 단순 분류, 라우팅, 정책 판단까지 큰 모델 호출로 쌓입니다. 사용자는 답변 하나를 받았다고 느끼지만 내부에서는 검색 여부 판단, 도구 선택, 위험도 분류, 응답 스타일 선택 등 여러 번의 모델 호출이 일어납니다.

두 번째 문제는 지연 시간입니다. 사용자가 기다리는 시간은 모델이 긴 답변을 쓸 때만 생기는 것이 아닙니다. 짧은 판단이 5번 이어지면 전체 응답은 느려집니다. Cloudflare 블로그는 도메인을 가져와 렌더링하고 분류하는 내부 예시에서 Clef가 2.2초, gpt-oss-120b가 4.7초였다고 언급했습니다. 수치 자체는 Cloudflare 자체 측정이라는 점을 감안해야 하지만, decision model의 방향성은 분명합니다. 생성하지 않아도 되는 일은 생성 모델로 처리하지 말자는 것입니다.

세 번째 문제는 운영 통제입니다. 자유 형식 답변은 유연하지만, 정책 시스템과 붙일 때는 불편합니다. 반면 “allow, deny, escalate”처럼 닫힌 선택지는 로깅, 대시보드, A/B 테스트, 임계값 조정이 쉽습니다. 예를 들어 0.7 이상이면 자동 처리, 0.4~0.7이면 사람 검토, 0.4 미만이면 재질문처럼 정책을 숫자로 만들 수 있습니다.

LLM과 decision model의 역할 분리

실무에서는 둘 중 하나만 고르는 문제가 아닙니다. 역할을 나눠야 합니다. 범용 LLM은 모호한 요구를 이해하고, 맥락을 요약하고, 코드를 작성하고, 사용자에게 설명하는 데 강합니다. decision model은 정해진 선택지 안에서 빠르게 판단하고, agent workflow의 분기점을 안정적으로 처리하는 데 강합니다.

예를 들어 고객지원 에이전트를 만든다면 전체 구조는 이렇게 나눌 수 있습니다. 사용자의 문의를 LLM이 요약합니다. decision model이 긴급도와 담당 팀을 정합니다. 검색 시스템이 관련 문서를 가져옵니다. LLM이 답변 초안을 씁니다. decision model이 사람 승인 필요 여부를 판단합니다. 마지막으로 사람이 승인하거나 자동 발송합니다. 이 구조에서는 LLM 호출 횟수를 줄이면서도 중요한 판단을 추적할 수 있습니다.

개발자용 코드 에이전트에도 적용됩니다. PR diff를 LLM이 읽고 요약하되, “보안 리뷰 필요”, “마이그레이션 포함”, “테스트 필수”, “자동 수정 가능” 같은 분류는 decision model로 처리할 수 있습니다. 이렇게 하면 리뷰 큐를 만들기 쉽고, 팀 규칙도 코드로 유지할 수 있습니다.

도입 전 확인할 점

Clef 같은 decision model을 바로 운영에 넣기 전에 확인할 것이 있습니다. 첫째, 선택지 설계입니다. 선택지가 애매하면 모델이 좋아도 결과가 흔들립니다. “중요함”처럼 추상적인 라벨보다 “24시간 내 사람 대응 필요”처럼 행동 기준이 있는 라벨이 낫습니다.

둘째, 임계값 설계입니다. probability가 나온다고 해서 자동으로 정답이 되는 것은 아닙니다. 자동 처리 기준, 보류 기준, 사람 검토 기준을 나눠야 합니다. 특히 결제, 보안, 권한 변경처럼 실패 비용이 큰 영역은 낮은 확률 차이로 자동 결정하면 안 됩니다.

셋째, 평가 데이터입니다. 우리 서비스의 실제 로그에서 200~500개 정도를 뽑아 사람이 라벨링한 검증 세트가 필요합니다. 공개 benchmark에서 좋다고 우리 업무에서도 좋은 것은 아닙니다. Cloudflare가 RL fine-tuning을 강조한 것도 이 때문입니다. decision model은 도메인별 라벨과 정책에 맞게 다듬을 때 가치가 커집니다.

개발팀 실행 체크리스트

• 에이전트 workflow에서 “텍스트 생성이 아니라 선택”에 해당하는 지점을 모두 표시합니다.
• 각 판단을 allow, deny, escalate, route처럼 닫힌 선택지로 바꿉니다.
• 실패 비용이 낮은 분류부터 Clef, Clef-flash, 기존 LLM JSON 응답을 비교합니다.
• 지연 시간, 비용, 파싱 실패율, 사람 검토 전환율을 같은 기준으로 기록합니다.
• probability 임계값을 자동 처리, 재질문, 사람 검토로 나눕니다.
• 운영 투입 전 실제 데이터 200개 이상으로 오프라인 평가를 만듭니다.
• 결과 로그에는 입력 요약, 선택지, 확률, 최종 액션, 사람 수정 여부를 남깁니다.

Clef의 의미는 “Cloudflare도 AI 모델을 냈다”보다 큽니다. 에이전트 시스템이 커질수록 모든 판단을 거대한 LLM에게 맡기는 방식은 비싸고 느려집니다. 앞으로 실무 AI 아키텍처는 생성 모델, 검색, 도구 호출, decision model을 분리해 조립하는 방향으로 갈 가능성이 큽니다. 개발자는 이제 프롬프트만 잘 쓰는 사람이 아니라, 어떤 판단을 어떤 모델에 맡길지 설계하는 사람이 되어야 합니다.