Cloudflare Clef: 질문에 확률로 답하는 오픈소스 결정 모델

에이전트 워크플로를 만들다 보면 중간중간 작은 판단이 필요한 순간이 계속 나옵니다. “이 문의는 긴급한가?”, “어느 팀으로 보내야 하지?”, “이 도메인은 피싱 사이트일까?” 같은 질문이요. 보통은 이런 판단도 대규모 언어 모델(Large Language Model, 이하 LLM)에게 맡기는데요. 프롬프트에 “JSON으로만 답해”라고 신신당부해도 가끔 형식이 어긋나고, 같은 입력에 매번 다른 답이 나오고, 무엇보다 한 번 물어볼 때마다 몇 초씩 기다려야 합니다 😅

예/아니요 하나 정하자고 수천 개의 토큰을 생성하는 건 아무래도 과해 보이죠. 그래서 최근 이런 판단만 빠르게 내려주는 결정 모델(decision model)이라는 새로운 종류의 모델이 주목받고 있습니다. 그리고 2026년 10월 1일, Cloudflare가 Birthday Week를 맞아 직접 학습시킨 결정 모델 Clef와 Clef-flash를 오픈소스로 공개했어요.

이번 글에서는 결정 모델이 무엇인지부터 시작해서, Cloudflare Workers AI로 Clef를 직접 호출해 보고, 질문을 어떻게 써야 결과가 좋아지는지, 그리고 Cloudflare가 함께 발표한 강화 학습(reinforcement learning, 이하 RL) 파인튜닝(fine-tuning) 플랫폼까지 차례로 살펴보겠습니다.

결정 모델이란?

결정 모델은 상태(state)와 질문 목록을 받아서, 질문마다 타입이 정해진 답과 그 확률을 돌려주는 모델입니다. 예를 들어 고객 문의 메시지를 상태로 넘기고 “긴급한가?”, “어느 팀이 처리해야 하나?”를 물으면, 결정 모델은 “긴급할 확률 99%”, “기술팀 81%, 결제팀 18%, 영업팀 2%” 같은 답을 줍니다. 우리 코드는 이 확률을 보고 티켓을 배정하거나, 담당자를 호출하거나, 확신이 부족하면 사람에게 넘기면 되죠.

LLM과 비교하면 차이가 분명합니다. LLM은 무엇이든 자유롭게 생성할 수 있는 대신 출력이 열려 있고 비결정적이에요. 결정 모델은 반대로 출력이 미리 정한 선택지 안으로 닫혀 있습니다. 텍스트를 만들지 않으니 형식이 깨질 일이 없고, 같은 입력에는 같은 확률이 나오고, 훨씬 빠릅니다.

이 개념을 널리 알린 건 2026년 9월 TypeSafe AI가 내놓은 Jev였습니다. TypeSafe AI는 대니얼 카너먼의 시스템 1(빠르고 직관적인 판단)에서 이름을 따와 이런 모델을 System One 모델이라고 부르는데요. 세 가지 질문 타입과 신뢰도로 분기하는 요령은 Jev 글에서 자세히 다뤘으니, 이번 글에서는 Clef만의 특징과 직접 써 본 결과에 집중하겠습니다.

기존의 분류 모델과 다른 점은 새 카테고리가 생길 때마다 다시 학습시킬 필요가 없다는 거예요. 분류 기준을 요청에 자연어로 적어 보내면 되니까요. 그래서 질문과 선택지를 매번 바꿔 가며 어떤 워크플로에든 끼워 넣을 수 있습니다.

참고로 Clef라는 이름은 음악의 음자리표에서 왔습니다. 악보 맨 앞에 놓인 음자리표가 각 줄과 칸이 어떤 음인지 정해주듯, 결정 모델이 뒤따르는 행동의 범위를 정해준다는 의미라고 해요. Clef의 첫 글자와 마지막 글자를 이으면 Cloudflare의 약자인 CF가 되는 것도 노린 거라고 하고요.

Clef와 Clef-flash

Cloudflare는 두 가지 크기의 모델을 공개했습니다. Clef는 Qwen3.8-27B를 기반으로 한 정확도 중심의 모델이고, Clef-flash는 Qwen3.5-9B를 기반으로 한 속도 중심의 모델이에요. 둘 다 Apache 2.0 라이선스로 Hugging Face에 가중치가 올라가 있어서 직접 내려받아 돌려볼 수도 있고, Workers AI에서 호스팅된 버전을 API로 바로 쓸 수도 있습니다.

Jev와 비교했을 때 Clef가 내세우는 차이는 크게 세 가지입니다. 우선 비전 인코더(vision encoder)가 들어 있어서 텍스트뿐 아니라 이미지도 분류할 수 있어요. Cloudflare에 따르면 Jev는 아직 텍스트만 다룹니다. 다음으로 컨텍스트 창(context window)이 64k 토큰으로 Jev의 32k보다 두 배 넓어서, 긴 대화 기록이나 큰 JSON 상태도 한 번에 넣을 수 있습니다. 마지막으로 API가 Jev와 호환되기 때문에 Jev를 쓰던 코드라면 엔드포인트만 바꿔서 옮겨 올 수 있어요.

Workers AI 기준 모델 ID는 @cf/cloudflare/clef와 @cf/cloudflare/clef-flash이고, 가격은 입력 토큰 100만 개당 $0.24입니다. 출력 토큰은 아예 생성하지 않으니 따로 과금되지 않아요. Cloudflare는 요청과 응답을 읽거나 저장하거나 학습에 쓰지 않는다고 밝혔는데, 뒤에서 다룰 파인튜닝에 직접 참여하는 경우만 예외입니다.

Clef 직접 호출해 보기

백문이 불여일견이니 바로 호출해 보겠습니다. Cloudflare 계정 ID와 Workers AI 권한이 있는 API 토큰이 있으면 curl로 바로 요청을 보낼 수 있어요. 공식 문서의 예제를 그대로 가져왔습니다.

curl https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run/@cf/cloudflare/clef \
  -X POST \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  -d '{
    "model": "clef",
    "state": "Checkout has been failing for every customer for the last hour.",
    "questions": {
      "urgent": { "type": "noul", "instructions": "Is this support request urgent?" },
      "team": {
        "type": "choice",
        "instructions": "Which team should handle this request?",
        "criteria": {
          "billing": "Payments, invoices, and refunds",
          "technical": "Outages, errors, and configuration",
          "sales": "Plans and upgrades"
        }
      },
      "severity": {
        "type": "score",
        "instructions": "How severe is the customer impact?",
        "criteria": ["No impact", "Minor", "Major", "Critical"]
      }
    }
  }'

요청 본문은 세 부분으로 이루어집니다. model에는 clef나 clef-flash를 넣고, state에는 판단할 대상을 넣어요. 문자열뿐 아니라 객체나 배열 같은 구조화된 데이터도 그대로 넣을 수 있습니다. 그리고 questions에 질문 ID를 키로 해서 최대 64개까지 질문을 담습니다.

질문 타입은 세 가지예요. noul은 예/아니요로 답할 질문이고(오타처럼 보이지만 실제 타입 이름입니다), choice는 criteria에 적은 선택지 중 하나를 고르는 질문, score는 순서가 있는 단계 중 어디쯤인지 매기는 질문입니다. 선택지마다 설명을 자연어로 적어 두면 모델이 그 설명을 기준으로 판단해요.

실제로 받은 응답은 이렇습니다.

{
  "result": {
    "model": "clef",
    "answers": {
      "urgent": { "type": "noul", "noul": 0.9906 },
      "team": {
        "type": "choice",
        "choice": "technical",
        "probabilities": {
          "billing": 0.1762,
          "technical": 0.8088,
          "sales": 0.015
        },
        "confidence": 0.5281
      },
      "severity": {
        "type": "score",
        "score": 2.9573,
        "legend": {
          "0": "No impact",
          "1": "Minor",
          "2": "Major",
          "3": "Critical"
        },
        "probabilities": { "0": 0.0042, "1": 0.0043, "2": 0.0215, "3": 0.97 },
        "confidence": 0.922
      }
    },
    "usage": { "input_tokens": 346, "output_tokens": 0 }
  },
  "success": true,
  "errors": [],
  "messages": []
}

응답을 하나씩 뜯어보면 재미있는 점이 몇 가지 보입니다.

noul 질문은 “예”일 확률 하나만 돌려줍니다. 결제가 한 시간째 전부 실패하고 있다는 메시지니 긴급할 확률이 0.99로 나왔네요. choice 질문은 가장 확률이 높은 선택지(choice)와 함께 모든 선택지의 확률(probabilities)을 줍니다. 1등만 알려주는 게 아니라 2등이 얼마나 근소하게 뒤처졌는지까지 알 수 있다는 점이 LLM의 답변과 크게 다른 부분이에요.

score 질문의 score 값은 각 단계의 번호에 확률을 곱해 더한 기댓값입니다. 직접 계산해 보면 0×0.0042 + 1×0.0043 + 2×0.0215 + 3×0.97 = 2.9573으로 정확히 맞아요. 정수로 딱 떨어지는 등급 대신 “Critical에 매우 가까움” 같은 연속적인 값을 받으니, 임계값을 원하는 대로 정해 쓰기 좋습니다.

마지막으로 usage의 output_tokens가 0인 게 눈에 띕니다. Clef는 정말로 텍스트를 한 토큰도 생성하지 않아요. 이게 어떻게 가능한지는 뒤에서 자세히 다루겠습니다.

같은 요청을 몇 번 반복해 보니 확률이 소수점 넷째 자리까지 똑같이 나왔습니다. 한국에서 호출했을 때 네트워크를 포함한 전체 응답 시간은 0.5초 안팎이었어요.

Cloudflare Workers 안에서는 REST API 대신 AI 바인딩으로 더 간단하게 부를 수 있습니다.

export default {
  async fetch(request, env): Promise<Response> {
    const response = await env.AI.run("@cf/cloudflare/clef", {
      model: "clef",
      state: await request.text(),
      questions: {
        urgent: {
          type: "noul",
          instructions: "Is this support request urgent?",
        },
      },
    });

    return Response.json(response);
  },
} satisfies ExportedHandler<Env>;

질문을 어떻게 쓰느냐가 중요하다

결정 모델은 질문에 적힌 문장을 판단 기준으로 삼습니다. 그래서 질문을 어떻게 쓰느냐에 따라 결과가 크게 달라지는데요. 한국어 문의 세 개에 같은 noul 질문을 문구만 바꿔서 던져 봤습니다. 막연한 질문은 “긴급하게 처리해야 하는 문의인가?”이고, 구체적인 질문은 “서비스 장애나 금전 피해처럼 지금 바로 대응하지 않으면 고객 피해가 커지는 문의인가?”예요.

결과를 보면 두 가지를 알 수 있습니다. 먼저 Clef-flash는 막연한 질문을 받았을 때 단순한 요금제 문의까지 긴급하다고(0.94) 판단했어요. 반면 Clef는 질문이 막연해도 상식적으로 답했습니다. 작은 모델일수록 질문에 담긴 기준에 더 많이 기대는 셈이죠.

그리고 두 모델 모두 카드 이중 승인 건을 막연한 질문으로는 애매하게(0.4 안팎) 판단했습니다. “긴급”이라는 말만으로는 돈 문제가 급한 일인지 모델이 알 수 없으니까요. “금전 피해”라는 기준을 질문에 넣자 Clef는 0.97로 확신했습니다.

결국 결정 모델에게 던지는 질문은 프롬프트라기보다 판단 기준을 적은 명세에 가깝습니다. 우리 팀이 “긴급”을 어떻게 정의하는지 문장으로 적어 줘야 모델도 그 기준대로 판단해요. 덤으로 한국어 질문과 한국어 문의도 문제없이 알아들었습니다. Jev 글에서는 한국어로 물었을 때 같은 답을 고르고도 신뢰도가 낮게 잡히는 경향이 있었는데, 이번 실험의 범위에서는 Clef가 한국어로도 0.97이나 0.99처럼 분명한 확률을 냈어요.

확률로 분기하는 티켓 분류 서버 만들기

이제 이 내용을 묶어서 실제로 쓸 만한 예제를 만들어 보겠습니다. 고객 문의를 받아 Clef로 분류한 다음, 담당 팀과 우선순위를 정하는 작은 Bun 서버예요.

const CLEF_URL = `https://api.cloudflare.com/client/v4/accounts/${process.env.CLOUDFLARE_ACCOUNT_ID}/ai/run/@cf/cloudflare/clef`;

const questions = {
  urgent: {
    type: "noul",
    instructions:
      "서비스 장애나 금전 피해처럼 지금 바로 대응하지 않으면 고객 피해가 커지는 문의인가?",
  },
  team: {
    type: "choice",
    instructions: "어느 팀이 처리해야 하는가?",
    criteria: {
      billing: "결제, 청구서, 환불",
      technical: "장애, 오류, 설정",
      sales: "요금제와 업그레이드",
      general: "진행 상황 확인 등 그 밖의 일반 문의",
    },
  },
};

async function classify(message: string) {
  const res = await fetch(CLEF_URL, {
    method: "POST",
    headers: { Authorization: `Bearer ${process.env.CLOUDFLARE_API_TOKEN}` },
    body: JSON.stringify({ model: "clef", state: message, questions }),
  });
  const { result } = await res.json();
  return result.answers;
}

Bun.serve({
  port: 3000,
  routes: {
    "/tickets": {
      async POST(req) {
        const { message } = await req.json();
        const { urgent, team } = await classify(message);

        // 확신이 부족하면 사람에게 넘긴다
        if (team.probabilities[team.choice] < 0.7) {
          return Response.json({ route: "human-review", team });
        }

        return Response.json({
          route: team.choice,
          priority: urgent.noul >= 0.8 ? "high" : "normal",
          urgent: urgent.noul,
        });
      },
    },
  },
});

핵심은 확률을 그대로 분기 조건으로 쓴다는 점입니다. 1등 선택지의 확률이 0.7에 못 미치면 자동으로 배정하지 않고 사람에게 넘기고, 긴급할 확률이 0.8 이상이면 우선순위를 높여요. LLM에게 “확실하지 않으면 모르겠다고 답해”라고 부탁하는 것보다 훨씬 믿음직한 방식입니다.

서버를 띄우고 문의 네 개를 보내 봤습니다.

bun run server.ts

curl -s localhost:3000/tickets -d '{"message":"어제 결제했는데 카드 승인이 두 번 났어요. 하나는 환불해 주세요."}'
curl -s localhost:3000/tickets -d '{"message":"대시보드에 로그인하면 500 에러가 나고 아무것도 안 보여요. 팀 전체가 작업을 못 하고 있습니다."}'
curl -s localhost:3000/tickets -d '{"message":"엔터프라이즈 요금제로 바꾸면 SSO도 같이 쓸 수 있나요?"}'
curl -s localhost:3000/tickets -d '{"message":"안녕하세요, 지난번 문의 건 어떻게 됐는지 궁금해서요."}'

{"route":"billing","priority":"high","urgent":0.9774}
{"route":"technical","priority":"high","urgent":0.9904}
{"route":"sales","priority":"normal","urgent":0.0181}
{"route":"general","priority":"normal","urgent":0.0229}

네 문의가 모두 제자리를 찾아갔네요. 사실 처음에는 general 선택지 없이 세 팀만 두었는데요. 그랬더니 “지난번 문의 건 어떻게 됐나요?” 같은 문의가 어디에도 딱 맞지 않아 엉뚱하게 기술팀으로 갔고, 요금제 문의는 영업팀 확률이 0.69에 그쳐 사람 검토로 넘어갔습니다. 선택지가 현실의 모든 경우를 덮지 못하면 모델은 그나마 가까운 쪽을 억지로 고를 수밖에 없어요. “그 밖의” 선택지를 하나 열어 두는 것이 생각보다 중요합니다.

벤치마크 살펴보기

Cloudflare는 커뮤니티가 관리하는 Jev Decision Index의 평가 항목으로 Clef를 측정했습니다. 원문에 실린 표에서 Clef, Clef-flash, Jev 세 모델만 추려 보면 다음과 같아요. 굵게 표시하는 대신 각 행에서 가장 높은 점수를 따로 적었습니다.

대부분의 항목에서 Clef 계열이 앞서지만, 언제 도구를 호출해야 하는지 판단하는 When2Call과 추론이 필요한 검색인 BRIGHT에서는 Jev가 이겼습니다. Clef-flash는 CLINC150+OOS에서 66.77로 크게 떨어지는데요. 이 항목은 150개 의도 중 하나를 고르거나 어디에도 속하지 않는다고 판단해야 하는 문제라, 선택지가 많고 경계가 미묘할수록 작은 모델이 불리하다는 걸 보여줍니다. 앞의 실험에서 Clef-flash가 막연한 질문에 흔들렸던 것과도 같은 맥락이에요.

지연 시간(latency)은 Clef-flash가 압도적입니다. 중앙값 기준으로 Clef가 209ms, Clef-flash가 38.8ms, Jev가 524ms였어요. Cloudflare가 실시간으로 결과를 보여주는 리더보드 사이트를 열어 보면 점수와 지연 시간을 한 그림으로 비교할 수 있습니다.

세로축이 점수, 가로축이 지연 시간이니 왼쪽 위로 갈수록 좋은 모델인데요. Clef(61.2점)와 Clef-flash(57.1점)가 효율 경계선을 이루고, Jev(57.9점)는 그보다 오른쪽 아래에 있습니다.

다만 이 숫자를 읽을 때 주의할 점이 있어요. 리더보드 상단에도 적혀 있듯이 Clef의 점수와 지연 시간은 Cloudflare가 직접 측정한 자체 보고 수치이고, 원래 리더보드에서 재현된 결과가 아닙니다. 지연 시간도 다른 모델과 같은 하드웨어에서 잰 것이 아니고요. 경향을 파악하는 데는 충분하지만, 실제 워크로드에 넣기 전에는 우리 데이터로 직접 비교해 보는 게 좋겠습니다.

Cloudflare 내부 사례도 하나 소개됐는데요. 위협 인텔리전스 팀이 웹사이트 도메인을 분류할 때 Clef를 써 봤더니, 사이트를 가져와 렌더링하고 분류하기까지 2.2초가 걸렸다고 합니다. 같은 작업을 Cloudflare가 쓰던 범용 LLM 중 가장 빠른 gpt-oss-120b에 맡겼을 때는 4.7초가 걸렸고 분류 결과도 두 개밖에 돌려주지 않았다고 해요.

Clef는 어떻게 이렇게 빠를까?

LLM이 느린 근본적인 이유는 자기회귀(autoregressive) 방식으로 토큰을 하나씩 생성하기 때문입니다. “urgent”에 대한 JSON 답 하나를 얻으려고 해도 {, ", urgent, ", : 같은 토큰을 차례차례 만들어야 하죠. 앞 토큰이 나와야 다음 토큰을 만들 수 있으니 병렬로 처리할 수도 없습니다.

Clef는 이 생성 단계를 통째로 건너뜁니다. 입력 전체를 모델에 한 번 통과시키는 사전 채우기(prefill)만 하고, 그 결과로 얻은 내부 표현에서 곧바로 각 선택지의 점수를 매겨요. 선택지 점수는 모두 병렬로 계산합니다.

flowchart TB
    accTitle: LLM과 Clef의 추론 과정 비교
    accDescr: LLM은 입력을 처리한 뒤 토큰을 하나씩 반복 생성하고 결과 JSON을 파싱해야 한다. Clef는 입력을 한 번 처리한 뒤 모든 선택지의 점수를 병렬로 매겨 바로 확률을 돌려준다.

    subgraph clef["Clef"]
        direction TB
        c1[/"상태 + 질문 스키마"/] --> c2["사전 채우기"]
        c2 --> c3["모든 선택지 점수<br/>병렬 계산"]
        c3 --> c4(["타입이 정해진 답 + 확률"])
    end

    subgraph llm["LLM"]
        direction TB
        l1[/"상태 + 프롬프트"/] --> l2["사전 채우기"]
        l2 --> l3["토큰 하나 생성"]
        l3 --> l4{"끝났는가?"}
        l4 -- "아니요" --> l3
        l4 -- "예" --> l5["JSON 텍스트 파싱"]
    end

Cloudflare 설명에 따르면 점수를 매기는 과정에는 2단계 어텐션 라우팅이 쓰입니다. 먼저 각 선택지가 입력에서 자신과 관련된 근거를 끌어오고, 그다음 질문 필드끼리 서로를 참조하면서 원래 입력을 다시 살펴본 뒤 점수를 매긴다고 해요. 질문 사이의 관계까지 함께 본다는 거죠. 실제로 Clef-flash에 카드 이중 승인 문의를 보냈을 때, urgent 질문만 단독으로 물으면 0.38이었던 확률이 team 질문과 함께 물으면 0.53으로 바뀌었습니다.

학습 방식도 흥미롭습니다. Qwen 베이스 모델은 얼려 두고(freeze), 그 위에 랭크 256짜리 저랭크 어댑터(low-rank adapter)와 라우팅 헤드만 함께 학습시켰어요. 손실 함수로는 정답 선택지를 맞히도록 하는 레이블 스무딩 교차 엔트로피(label-smoothed cross-entropy)와, 확률이 실제 정답률에 맞게 보정(calibration)되도록 하는 브라이어 손실(Brier loss)을 함께 썼습니다.

여기서 보정이란 모델이 “80%“라고 말한 답이 실제로 80% 정도 맞는 상태를 말합니다. 앞에서 만든 티켓 분류 서버처럼 확률을 임계값과 비교해 분기하려면 이 보정이 무척 중요해요. 모델이 근거 없이 0.99를 남발하면 임계값을 아무리 잘 정해도 소용이 없으니까요.

그 위에 Cloudflare가 RLCD(Reinforcement Learning for Calibrated Decisions)라고 이름 붙인 RL 단계를 한 번 더 거쳤습니다. 순서가 있는 선택지에서 정답과 가까운 답에는 부분 점수를 주고, 모든 필드를 정확히 맞힌 답에는 보상을 주고, 원래 모델에서 너무 멀어지지 않도록 페널티를 거는 방식이라고 해요.

RL 파인튜닝 플랫폼

이번 발표의 또 다른 축은 고객이 자기 데이터로 Clef를 파인튜닝할 수 있는 RL 플랫폼입니다. 범용 Clef도 꽤 똑똑하지만, 회사마다 쌓아 온 판단 기준은 질문 문장 몇 줄로 다 표현하기 어렵잖아요. Cloudflare 내부에서도 Trust & Safety 신고 검토, 고객 지원 요청 분류, 크롤러가 좋은 봇인지 나쁜 봇인지 가리는 일처럼 아주 구체적인 용도가 많았다고 합니다. 이런 경우 오랫동안 쌓인 판단 기록으로 모델을 특화시키면, 범용 성능을 조금 내주는 대신 그 영역에서는 더 정확하고 빠른 모델을 얻을 수 있어요.

플랫폼은 Cloudflare가 이미 갖고 있는 제품들을 이어 붙여 만들었습니다. 먼저 AI Gateway를 거쳐 오가는 AI 요청을 모아 자동으로 학습 데이터셋을 만들어요. 다음으로 Workers AI에서 기본 Clef 모델로 롤아웃(rollout)을 생성하고, Cloudflare Containers를 RL 샌드박스로 써서 에이전트의 행동을 재생하고 점수를 매깁니다. 그리고 새로 공개된 Trainer가 가중치를 업데이트하고, 마지막으로 Workers AI의 자체 모델 배포 기능으로 파인튜닝된 모델을 다시 올려요. 데이터 수집부터 재배포까지 한 플랫폼 안에서 끝나는 셈이에요.

다만 아직은 셀프서비스가 아닙니다. 당분간은 Cloudflare의 현장 배치 엔지니어(forward-deployed engineer, FDE) 팀이 고객과 직접 붙어서 파인튜닝을 돕는 방식으로 운영하고, 그 경험을 바탕으로 나중에 셀프서비스 플랫폼을 내놓을 계획이라고 해요. 관심이 있다면 신청 양식을 남길 수 있습니다.

어디에 쓰면 좋을까?

Clef가 빛나는 곳은 판단의 결과가 정해진 선택지 중 하나이고, 그 판단을 자주 빠르게 내려야 하는 곳입니다. 지금까지 본 고객 문의 분류가 대표적이고, 콘텐츠 검수나 스팸 판별, 피싱 의심 URL 걸러내기, 에이전트가 다음에 어떤 도구를 쓸지 고르는 라우팅에도 잘 맞아요. 이미지를 함께 넣을 수 있으니 업로드된 스크린샷이나 상품 사진을 분류하는 데도 쓸 수 있습니다. 다만 이미지는 원격 URL을 받지 않으니 요청 본문에 직접 담아 보내야 하고, 한 번에 최대 4장까지예요.

Cloudflare Agents로 에이전트를 만들고 있다면 구성을 이렇게 나눠 보는 것도 좋겠습니다. 결정이 필요한 갈림길에서는 Clef를 빠르게 부르고, 실제로 글을 쓰거나 코드를 고치는 행동은 LLM에게 맡기는 거죠. 두 모델 모두 Workers AI에 있으니 한 Worker 안에서 자연스럽게 섞어 쓸 수 있습니다.

반대로 요약, 번역, 답변 작성처럼 텍스트를 만들어야 하는 일에는 쓸 수 없어요. 선택지를 미리 정할 수 없는 열린 질문도 마찬가지고요. 그리고 앞의 실험에서 봤듯이 질문과 선택지를 허술하게 쓰면 결과도 허술해지니, JSON Schema로 API 명세를 쓰듯 판단 기준을 꼼꼼하게 적는 습관이 필요합니다.

마치며

지금까지 Cloudflare가 공개한 결정 모델 Clef와 Clef-flash를 살펴봤습니다. 결정 모델은 상태와 질문을 받아 타입이 정해진 답과 확률을 돌려주고, 텍스트를 한 토큰도 생성하지 않으니 빠르고 답이 흔들리지 않아요. 직접 호출해 보니 한국어도 잘 이해했고, 확률을 임계값과 비교해 사람에게 넘길지 정하는 흐름도 자연스럽게 만들 수 있었습니다.

개인적으로 가장 인상 깊었던 건 질문 문장 하나가 결과를 얼마나 크게 바꾸는지였어요. 결정 모델을 잘 쓰려면 모델보다 우리 팀의 판단 기준을 먼저 또렷하게 정리해야 한다는 뜻이기도 합니다. 지금 LLM에게 맡기고 있는 작은 판단이 있다면 Clef로 바꿔서 속도와 비용이 얼마나 달라지는지 한번 비교해 보세요 🎼

더 자세한 내용은 Cloudflare 공식 블로그의 Clef 발표 글과 Workers AI의 Clef 모델 문서를 참고하세요.