Cloudflare Clef, 판단 전용 AI가 필요한 순간

고객 문의가 들어왔습니다. “결제 버튼을 눌러도 오류만 뜹니다. 다른 고객도 결제가 안 된다고 합니다.”

친절한 사과문을 쓰는 일보다 먼저 해야 할 일이 있습니다. 청구팀과 기술지원팀 중 누구에게 보낼지, 당장 확인해야 하는 장애인지 정하는 일입니다. 이때 필요한 결과는 긴 설명이 아니라 담당 부서와 긴급도일 수 있습니다.

Cloudflare가 10월 1일 공개한 Clef와 Clef-flash는 이런 순간을 겨냥한 판단 모델입니다. 상황과 질문, 허용한 선택지를 넣으면 선택지별 확률을 반환합니다. 이미 좋은 LLM이 있는데도 별도 모델을 고려할 이유는, 서비스 안에서 같은 종류의 짧은 판단을 반복할 때 생깁니다. 공식 출시 안내

고객 문의를 넣으면 무엇이 나올까요?

앞의 결제 장애 문의를 가상의 쇼핑몰 사례로 이어 보겠습니다. 운영팀이 모델에 맡길 질문은 두 개입니다.

이 문의는 어느 부서가 처리해야 하나요? 청구팀, 기술지원팀, 영업팀, 검토 대기 중에서 골라 주세요. 긴급도는 일반·높음 중에서 고르되, 서비스 이용이 막힌 장애라면 높음으로 분류해 주세요.

Clef에서는 현재 상황을 state, 판단할 항목들을 questions로 전달합니다. 부서 선택은 choice, 예·아니요 판단은 noul, 순서가 있는 등급 평가는 score로 표현합니다. 질문마다 기준도 함께 줄 수 있습니다. 부서명만 던지는 것보다 “청구팀은 청구서·환불, 기술지원팀은 기능 오류·장애”처럼 담당 범위를 알려 주는 편이 이 사례의 목적에 맞습니다. Clef API 문서

이 사례에서 기대하는 분류는 기술지원팀, 높은 긴급도입니다. 이는 설명을 위한 예상 결과이며 특정 확률이나 실제 실행값을 뜻하지 않습니다. 시스템은 반환된 선택과 확률을 읽고 티켓을 옮기거나, 사람이 확인할 대기열에 넣을 수 있습니다.

여기서 Clef가 하는 일은 분류 결과를 내는 데까지입니다. 티켓을 이동시키는 코드, 담당자에게 알리는 기능, 고객에게 보낼 답장은 별도로 연결해야 합니다. 모델 하나를 호출한다고 고객지원 업무 전체가 완성되는 것은 아닙니다.

Jev 공개 16일 뒤, 무엇이 달라졌을까요?

Typesafe가 Jev의 얼리 액세스를 발표한 날은 9월 15일, Cloudflare가 Clef를 발표한 날은 10월 1일입니다. 공개 발표 사이의 간격은 16일입니다. 이제 막 Jev를 이해했는데 비슷한 모델이 벌써 나왔다는 인상이 드는 이유입니다. Jev 최초 발표, Clef 출시 기록

이 짧은 간격을 이해하려면 어디서 출발했는지를 봐야 합니다. 분류 기술은 오래전부터 있었고, Clef도 기존 Qwen 모델을 바탕으로 판단용 출력과 후속 학습을 더했습니다. Cloudflare는 Jev가 나온 주에 자체 결정 모델 실험을 공개했다고 설명합니다. 발표 간격이 짧다는 사실과 새로운 기반 모델 전체를 그 기간에 처음부터 만들었다는 주장은 다릅니다. Clef 개발 과정

두 제품의 공통 목표는 같습니다. 문의와 회사 기준을 읽고 프로그램이 사용할 선택·점수·확률을 돌려줍니다. Clef는 Jev의 System One API 호환도 내세웁니다. 같은 양식의 주문서를 받을 수 있게 만든 셈이지만, 주문을 처리하는 주방까지 같은 것은 아닙니다. 연결 형식이 비슷해도 모델, 학습, 확률, 오류 양상은 다시 비교해야 합니다. Jev 요청·응답 규격, Clef 호환성 안내

실질적인 차이는 입력과 운영 선택에서 먼저 드러납니다. Jev는 텍스트를 대상으로 하는 TypeSafe API이고, Clef는 이미지 입력과 공개 가중치, Workers AI 호스팅을 함께 제시합니다. Jev 지원 입력, Clef 모델 카드

앞의 쇼핑몰이 텍스트 문의만 분류한다면 이미지 지원의 가치는 작을 수 있습니다. 반면 오류 화면까지 함께 판독하거나 이미 Cloudflare에 운영 환경을 두고 있다면 Clef를 비교할 이유가 더 분명해집니다. 새 제품의 차이는 기능 목록보다 우리 업무에서 생략할 수 있는 전처리와 운영 부담으로 읽는 편이 좋습니다.

담당자를 고르는 AI와 답장을 쓰는 AI

접수창구를 떠올리면 차이가 쉬워집니다. 한 직원은 문의를 읽고 담당 부서에 도장을 찍습니다. 다른 직원은 상황을 정리해 고객에게 보낼 답장을 씁니다. 같은 문의를 읽지만 산출물이 다릅니다.

일반 LLM도 부서를 고르거나 정해진 형식으로 결과를 낼 수 있습니다. Clef의 특징은 이 분류 작업을 중심으로 출력 구조를 만든 데 있습니다. 입력을 처리하는 prefill 단계를 거친 뒤 허용된 선택지들을 함께 평가합니다. 설명문을 한 토큰씩 이어 쓰는 생성 단계를 거치지 않는 구조입니다. Cloudflare의 구조 설명

비유하자면 도장을 찍기 위해 먼저 장문의 사유서를 완성할 필요가 없는 셈입니다. 다만 일반 LLM도 짧게 답하도록 만들 수 있으므로, 모든 LLM이 긴 설명을 쓴다는 뜻은 아닙니다. 입력을 읽고 계산하는 비용 역시 남아 있습니다.

크게 보기

×확대 이미지 닫기

Clef-flash의 모델 카드에는 각 질문의 허용된 선택지에 점수를 매긴 뒤 확률로 바꾸는 구조가 설명돼 있습니다. 새로운 부서 이름을 문장으로 만들어 내는 대신, 시스템이 제시한 후보 안에서 판단하도록 하는 방식입니다. 덕분에 프로그램이 결과를 받아 쓰기 편해지지만, 정해진 형식으로 나오는 것과 올바른 부서를 고르는 것은 다른 문제입니다. Clef-flash 모델 카드

확률이 높아도 잘못된 부서로 갈 수 있습니다

결제 장애 문의를 청구팀으로 보내 버렸다고 가정해 보겠습니다. 출력에는 허용된 부서명이 들어 있고 형식도 정상입니다. 그런데 청구팀이 해결할 수 없는 장애라서 다시 기술지원팀으로 넘겨야 합니다. 문법 검사는 통과했지만 업무는 한 번 돌아갔습니다.

이때 “더 정확하게 판단해 주세요”라고만 고치면 무엇이 바뀌어야 하는지 불분명합니다. 기준을 다음처럼 보완할 수 있습니다.

결제 버튼 오류나 여러 고객의 결제 실패는 기술지원팀으로 분류해 주세요. 청구서 발행·이미 결제된 금액의 환불은 청구팀입니다. 어느 쪽인지 판단할 정보가 부족하면 검토 대기로 보내 주세요.

기준을 바꾼 뒤에는 정상 결제 문의와 실제 장애 문의를 함께 확인해야 합니다. 장애를 잘 잡겠다고 모든 “결제” 문의를 긴급으로 올려도 운영팀의 일이 늘어납니다. 무엇을 놓쳤는지, 무엇을 과하게 올렸는지를 따로 보는 이유입니다.

크게 보기

×확대 이미지 닫기

모델이 내놓는 확률도 실제 정답률과 동일하게 받아들이면 안 됩니다. 우리 회사의 한국어 문의, 짧은 은어, 한 문장에 섞인 여러 요구에서 얼마나 맞는지는 별도로 확인해야 합니다. “높은 확률이면 자동 처리”라는 기준 역시 과거 사례에서 오류와 검토량을 함께 보며 정해야 합니다. 어디서나 통하는 안전한 숫자 하나가 있는 것은 아닙니다.

Jev의 공식 문서도 영어에서 정확도가 가장 좋고 한국어·중국어·일본어 등을 같은 수준으로 처리한다고 보장하지 않는다고 설명합니다. Clef와 Jev 중 어느 쪽이 한국어 문의를 더 잘 분류하는지는 일반 벤치마크만으로 정할 수 없습니다. Jev 언어 지원

분류 결과를 돈을 돌려주거나 계정을 정지하는 권한과 바로 연결하는 일도 신중해야 합니다. 문의함 이동은 되돌리기 쉽지만 환불이나 계정 조치는 영향이 다릅니다. 같은 모델을 쓰더라도 실행 권한과 승인 조건은 업무의 영향에 맞게 따로 정하는 편이 좋습니다.

분류 뒤에 여러 단계의 처리·승인·재시도가 붙기 시작하면 모델 선택과 별도로 흐름을 관리해야 합니다. 이 지점은 루프·그래프 엔지니어링의 적용 기준과 연결됩니다. Clef가 어느 부서로 보낼지 판단해도, 승인 대기 상태를 저장하고 실패한 작업을 복구하는 책임은 주변 시스템에 남습니다.

규칙·일반 LLM·Clef의 자리를 나누면

숫자로 된 환불 금액이 회사의 한도를 넘는지 검사하는 일은 코드 규칙으로 해결할 수 있습니다. 이미 명확한 조건에 AI를 끼워 넣으면 비용과 확인할 대상만 늘어날 수 있습니다.

반대로 고객이 자유롭게 쓴 문의에서 의도를 읽어 여러 담당 부서 중 하나를 고르는 일은 문맥 판단이 필요합니다. 이 판단이 충분히 반복된다면 Clef 같은 모델을 비교할 이유가 생깁니다. 판단 뒤에 고객 상황을 반영한 답장까지 만들어야 한다면 일반 LLM이 맡을 역할도 남습니다.

문의가 적고 사람이 금방 분류하거나, 이미 쓰는 LLM이 비용과 속도 요구를 충족한다면 새 모델을 더할 이유가 약합니다. 호출 하나를 줄여 아끼는 비용보다 연동·평가·운영에 드는 수고가 클 수 있기 때문입니다. 기존 분류기나 작은 모델로 충분한 업무도 있습니다.

제가 이 제품에서 주목하는 지점은 “모든 AI를 교체한다”는 약속보다 반복되는 판단만 따로 최적화할 선택지가 늘었다는 것입니다. 질문이 자주 바뀌거나 예외 설명이 핵심인 업무까지 무리하게 선택지로 접어 넣을 필요는 없습니다.

빠르다는 숫자와 잘한다는 숫자는 따로 읽어야 합니다

Cloudflare가 공개한 평가에서 Clef의 중앙 응답 지연은 209.3ms, Clef-flash는 38.8ms, 비교 대상 Jev는 524.1ms입니다. 43개 평가 실행을 모은 공급자 측 결과이며, 우리 서비스에서 사용자가 체감할 응답시간을 보장하는 수치는 아닙니다. 입력 길이, 네트워크, 대기열, 앞뒤 업무가 더해지기 때문입니다. 공식 평가 안내

이 표본에서 Jev의 중앙 지연을 나누면 Clef의 약 2.5배, Flash의 약 13.5배입니다. 이는 Cloudflare가 같은 평가 묶음에서 측정한 값의 비교입니다. Jev가 자체 발표에서 제시한 속도 배수와 섞거나, 모든 요청에서 같은 차이가 난다고 확대하면 안 됩니다.

발표에는 성능과 지연을 함께 비교하는 Decision Index 공식 차트 원본도 있습니다. 종합적인 위치를 살펴보는 자료로 쓰되, 우리 업무에서 중요한 항목의 결과는 따로 확인하는 편이 좋습니다.

품질도 한 줄 순위로 끝나지 않습니다. 다음은 공식 모델 카드의 Decision Index 결과 중 강점과 약점이 함께 보이는 항목입니다. 점수는 모델 카드에 표시된 소수 첫째 자리 값을 사용했습니다. 원표에는 Jev의 세부 버전이 표시되지 않아, 뒤에서 요금을 비교하는 현재 Jev 1.13과 동일 버전의 결과라고 확정할 수는 없습니다.

각 행 안에서 비교해야 합니다. accuracy는 정답 비율이고, macro-F1은 분류별 정밀도와 재현율을 조합한 값을 평균한 지표라서 같은 종류의 점수가 아닙니다. 표에 뽑은 항목의 평균으로 종합 순위를 만들면 의미가 흐려집니다.

분류 평가인 BANKING77에서는 Clef가 Jev보다 14.5점 높지만, 도구 호출 판단인 When2Call에서는 8.6점 낮습니다. Clef-flash는 CLINC150+OOS에서 Jev보다 22.5점 낮습니다. 공개 점수의 차이이며 서로 다른 평가를 합산한 우열은 아닙니다. 빠른 모델을 고르는 일과 필요한 분류 품질을 확보하는 일은 함께 검증해야 한다는 뜻입니다.

출시 소개에 강조된 일부 평가만 보면 이러한 차이를 놓치기 쉽습니다. 반대로 어려운 지식 문제 점수가 낮다는 이유만으로 고객 문의 분류에 쓸모없다고 결론 내릴 수도 없습니다. 벤치마크는 후보를 좁히는 자료이고, 마지막 비교 대상은 우리 업무의 실제 문의여야 합니다.

Jev와 비교하면 더 저렴할까요?

Workers AI의 공개 단가는 Clef가 입력 100만 토큰당 0.24달러, Clef-flash가 0.09달러입니다. 단가표에는 두 모델의 출력 토큰 요금이 따로 제시되지 않습니다. Workers AI 가격표

Jev 1.13의 공식 입력 단가는 같은 100만 토큰당 0.042달러이고 출력은 무료입니다. 입력 단가만 비교하면 Clef는 Jev의 약 5.71배, Flash도 약 2.14배입니다. 따라서 Clef 출시를 “Jev보다 더 싸진 모델의 등장”으로 설명할 수는 없습니다. Jev 모델·요금 안내

문의 한 건이 세 모델에서 같은 수의 과금 토큰이 된다는 보장도 없습니다. 문의 내용과 전달한 맥락·질문·기준이 사용량에 반영되므로, 같은 일을 시킨 실제 사용량도 확인해야 합니다.

예를 들어 API가 보고한 총 입력이 요청당 1,000토큰, 10만 건 처리라고 가정하면 총 1억 토큰입니다. 문의 본문만 1,000토큰이라는 가정이 아닙니다. 무료 할당량이나 다른 서비스 비용을 반영하기 전, 모델 입력 단가만 곱한 산술 예시는 다음과 같습니다.

이 표를 “고객지원 자동화 월 9달러”로 읽으면 안 됩니다. 실제 서비스에는 호출량 변화, 재시도, 답장을 만드는 별도 모델, Worker 실행과 데이터 저장, 사람이 다시 확인하는 업무가 남습니다. Workers AI도 무료 할당량과 유료 플랜 조건에 따라 실제 청구가 달라집니다.

처리량이 충분하고 품질도 맞는다면, 텍스트 분류의 모델 요금만으로는 Jev가 먼저 눈에 들어옵니다. Clef에 더 비용을 낼 이유는 필요한 평가에서의 품질, 이미지 입력, 응답 지연, 기존 인프라와의 연결이 그 차액을 설명해 줄 때입니다. 공개 가중치를 직접 실행하면 API 요금 대신 GPU와 운영비를 부담하므로, 이 표의 단가로 자체 실행비를 계산할 수는 없습니다.

특히 잘못된 담당 부서로 보내 재분류가 늘면 저렴한 입력 단가만으로는 이득을 판단하기 어렵습니다. 도입 비교에서는 분류에 성공한 건당 비용과 사람이 되돌려 처리한 건수를 함께 보는 편이 실용적입니다.

바로 호출하는 방법과 직접 운영하는 방법

가볍게 평가를 시작할 경로는 Cloudflare가 호스팅하는 Workers AI입니다. Clef는 27B, Flash는 9B 모델이며, 호스팅 문서의 입력 문맥 한도는 둘 다 65,536토큰입니다. 한 요청에 질문을 1개부터 64개까지 넣을 수 있습니다. 웹 챗봇을 하나 더 구독하는 방식보다는, 기존 서비스에서 API로 부르는 구성에 가깝습니다. Clef 문서, Clef-flash 문서

여기서 “Jev의 두 배 문맥”이라는 비교는 주의해서 읽어야 합니다. Jev의 현재 문서는 요청 전체 64k, 그중 state와 가장 긴 질문의 합은 32k로 설명합니다. 총량과 부분 한도가 함께 있는 구조라서 Clef의 64k와 Jev의 32k 숫자만 떼어 비교하면 중요한 조건이 빠집니다. 또한 Jev 공식 모델 안내에는 파라미터 수가 제시돼 있지 않아, 모델 크기까지 같게 맞춘 비교라고 볼 근거도 없습니다. Jev 입력 한도

텍스트 외에 영수증이나 오류 화면 같은 이미지도 판단에 넣을 수 있습니다. 다만 Workers AI의 공개 요청 규격은 이미지를 최대 4개까지 받으며 원격 이미지 URL을 직접 받지 않습니다. 모델 카드에 소개된 영상 입력 기능을 보고 호스팅 API에서도 같은 방식으로 영상을 보낼 수 있다고 가정하면 안 됩니다. 모델 자체가 할 수 있는 일과 특정 서비스가 열어 둔 입력 방식은 구분해야 합니다.

가중치는 Apache 2.0 라이선스로 공개돼 있어 직접 운영하는 경로도 있습니다. 하지만 “공개 모델”이 곧 “일반 노트북에서 편하게 실행”을 뜻하지는 않습니다. 공식 모델 카드의 실행 확인 환경에는 H200 한 장이 제시돼 있습니다. 이는 최소 요구사양을 뜻하지 않으며, 다른 환경에서 필요한 메모리·속도·호환성은 별도로 판단해야 합니다. Clef-flash 실행 안내

회사별 조정 방식도 다릅니다. Jev는 모든 계정에 같은 가중치를 제공하고, 고객 데이터로 모델을 별도 미세 조정하거나 LoRA를 적용하지 않는다고 안내합니다. 업무 기준은 요청의 state, instructions, criteria로 반영하는 방식입니다. Jev 맞춤화 안내

Cloudflare는 Clef를 회사별 업무에 맞춰 추가 학습하는 서비스도 발표했습니다. 현장 엔지니어 팀과 협력하는 서비스가 먼저이며, 사용자가 직접 학습하고 재배포하는 셀프서비스 플랫폼은 후속 계획입니다. 일반 API를 쓰기 전에 반드시 학습해야 한다는 뜻은 아니며, 지금 누구나 버튼 몇 번으로 끝낼 수 있는 기능처럼 이해해서도 안 됩니다. 미세 조정 서비스 발표

첫 도입은 자동 처리보다 분류 결과 비교부터

앞의 쇼핑몰이라면 처음부터 모든 문의를 자동 이관할 필요는 없습니다. 운영팀이 실제로 분류한 문의를 골라, Clef가 고른 담당 부서와 긴급도를 나란히 확인하는 것부터 시작할 수 있습니다. 새 분류 결과를 참고용으로 남기고 기존 업무를 유지하면 어디에서 의견이 갈리는지 보기 쉽습니다.

쉬운 정상 문의만 골라서는 판단이 어렵습니다. 결제 장애, 단순 환불, “환불도 받고 싶고 오류도 해결해 달라”는 혼합 문의, 정보가 모자란 문의를 포함해야 합니다. 이 사례에서 확인할 핵심은 다음 세 가지입니다.

• 놓친 긴급 장애: 기술지원이 바로 봐야 할 문의를 일반 문의로 내려보냈는지 확인합니다.
• 잘못된 이관과 검토량: 다른 부서로 보낸 건수와 검토 대기로 남긴 양이 실제 운영에 감당할 만한지 봅니다.
• 업무 전체의 시간과 비용: 모델 응답시간에 연동 지연, 재시도, 사람의 재분류를 더해 비교합니다.

기준을 고칠 때 쓴 문의와 마지막 성능을 확인할 문의도 나누는 편이 좋습니다. 익숙한 예시에만 잘 맞아진 것을 새로운 문의까지 잘 처리하는 것으로 착각하지 않기 위해서입니다.

Clef가 필요한 순간은 모델 이름이 새로워졌을 때가 아닙니다. 반복되는 문맥 판단이 실제 병목이고, 선택지와 검토 기준을 정의할 수 있으며, 검증 결과가 현재 방식보다 나을 때입니다. 그 조건이 맞는 곳에서는 답장 담당에게 접수 분류까지 모두 맡기던 구조를 바꿀 수 있습니다. 좋은 AI 하나를 모든 자리에 앉히는 대신, 업무에 맞는 역할을 고를 여지가 생긴다는 점이 이번 출시의 흥미로운 변화입니다.