Cloudflare Clairic 분석: 문서 추출·계산·미래 추정을 나누는 법

발주서의 세 질문은 서로 다른 일을 요구한다

구매 담당자가 발주 메일을 업무 표에 옮긴다고 하자. “발주 번호는?”, “배송비를 포함한 금액은?”, “실제로 언제 도착할까?”는 모두 짧은 값으로 답할 수 있다. 그래서 같은 추출 작업처럼 보인다. 하지만 첫째는 문서에서 찾는 일, 둘째는 조건을 해석해 계산하는 일, 셋째는 아직 일어나지 않은 일을 예상하는 일이다.

Cloudflare가 2026년 10월 19일 발표한 Clairic은 이 세 종류와 시계열 예측을 typed value, 즉 자료형이 정해진 값으로 반환하는 모델이다. 현재 Workers AI의 @cf/cloudflare/clairic으로 제공되는 preview이며, 공개 가중치는 추후 제공할 계획이라고 밝혔다. 이 글은 10월 20일 확인한 문헌 분석이다. 모델을 직접 호출하거나 한국어 문서 처리 성능을 측정하지 않았다. 공식 출시 기록

중요한 변화는 모든 문서 업무가 자동화됐다는 데 있지 않다. 여러 필드를 채우기 위해 긴 답변을 생성하던 단계에 값을 얻는 전용 모델을 넣을 수 있다는 점이다. 어떤 칸을 맡기고 어떤 칸을 남겨 둘지 결정하려면 출력 형식보다 먼저 그 값이 어떻게 결정되는지 보아야 한다.

긴 답변을 만들지 않고 필드의 값을 얻는 구조

Clairic 요청은 읽을 자료인 state와 이름·자료형·지시를 지정하는 fields로 구성된다. Cloudflare는 입력에 대한 forward pass로 값을 구하고 출력 토큰을 순차 생성하지 않는 방식을 System One이라고 설명한다. 여기서 System One은 공급자의 모델 분류다. 사람의 사고 방식이나 모든 과제에서의 우위를 입증하는 말로 받아들일 필요는 없다. 구조와 입력 방식 설명

이 설명은 “JSON 응답이 없다”는 뜻이 아니다. 프로그램은 여전히 결과 객체를 받는다. 차이는 모델이 자유로운 문장을 이어 쓰는 대신 필드의 유형에 맞춰 답을 내놓는다는 데 있다. 필드가 한 pass에 함께 들어가지 않으면 서버가 여러 병렬 pass로 나누므로, 필드를 무한히 늘려도 요청 비용이 같다는 뜻도 아니다. 모델 매개변수

값 추출, 선택, 설명을 구분하면 모델을 조합하는 이유가 명확해진다. 공식 개념 문서는 추출 모델을 값 획득에, decision model을 미리 정한 선택지 중 판단에, 생성 모델을 열린 형태의 내용 작성에 대응시킨다. 아래의 발주 업무 배치는 그 구분을 적용한 편집 제안이다. 모델 유형의 구분

필요한 결과	발주 업무에서의 예	먼저 고려할 처리
원문에 있는 값	품목 번호·수량·기재된 납기	추출 모델 또는 기존 파서
규칙으로 정해지는 값	검증된 수량 × 단가 + 배송비	코드 계산, 단순 계산 필드는 대조용
정해진 선택	담당 부서 A·B·C로 분류	명확한 규칙 또는 decision model
설명과 협의 문장	납기 변경을 요청하는 메일	확인한 사실을 받은 생성 모델

표의 모든 행에 AI가 필요하지는 않다. 양식이 고정된 전자 발주서라면 기존 필드와 계산식을 그대로 읽는 편이 단순하다. 메일 본문과 비정형 문서가 섞이고 표현이 자주 달라지는 곳에서 전용 추출 모델을 검토할 이유가 생긴다.

가상 발주서로 추출·계산·추정 분리하기

다음은 이 글에서 만든 한국어 가상 입력이다. 실명·실제 주문·실제 모델 응답이 아니다.

발주 PO-K42. 품목 센서 브래킷 12개, 개당 18,000원.
배송비 6,000원. 모든 금액은 부가세 별도.
공급자 요청 납기: 2026-10-27.
실제 출고일과 운송장 번호는 아직 미정.
기준일: 2026-10-20.

이 문서를 읽어 업무 표를 설계하면 다음과 같다. 기대값은 사람이 정의한 정답 또는 계산값이며 Clairic이 반환한 결과가 아니다.

업무 표의 칸	근거와 기대값	다음 행동
발주 번호	원문에 있는 PO-K42	원문 위치와 함께 표시
수량·단가·배송비	각각 12·18,000·6,000	단위·문서 일치 확인
세전 합계	12 × 18,000 + 6,000 = 222,000원	코드로 재계산해 대조
요청 납기	원문에 있는 2026-10-27	공급자 확정일과 구분
운송장 번호	미정이므로 유효 값 없음	공급자에게 확인할 항목으로 유지
실제 도착 예상	이 문서만으로 확정 불가	운송 정보·이력 확보 후 전망으로 표시

실수하기 쉬운 부분은 delivery_date라는 하나의 필드에 요청 납기와 실제 예상 도착일을 섞는 것이다. 둘 다 날짜 형식에 맞아도 업무 의미가 다르다. 전자는 문서에 적힌 희망 조건이고 후자는 운송 상황에 대한 전망이다. 추출한 요청일을 고객에게 확정 납기로 알려 주면 숫자 형식 검사는 통과해도 업무는 실패한다.

필드 정의도 이 구분을 드러내야 한다. 아래 JSON은 공식 요청 구조를 바탕으로 만든 미실행 요청 설계안이다. 앞의 가상 문장을 state에 넣고 이 정의를 결합하는 상황을 뜻하며, 인증·호출 코드나 관측 응답은 포함하지 않았다. 필드와 요청 예시

{
  "model": "clairic",
  "reference_date": "2026-10-20",
  "fields": {
    "purchase_order": {"type": "text", "instructions": "발주 번호"},
    "requested_delivery": {
      "type": "date",
      "instructions": "문서에 기재된 요청 납기. 실제 도착일을 추정하지 말 것"
    },
    "subtotal_before_tax": {
      "type": "number", "integer": true, "unit": "KRW",
      "instructions": "수량 곱하기 단가에 배송비를 더한 세전 합계"
    },
    "tracking_number": {"type": "text", "instructions": "운송장 번호"}
  }
}

합계를 모델에 물을 수 있다는 것과 합계를 모델에 전적으로 맡겨야 한다는 것은 다르다. 이번 산술은 Python으로 별도 확인했다. 가상 계산 입력과 결과에는 수량 변경과 누락 사례도 있다. 부가세율과 과세 규칙은 입력에 없으므로 세후 결제액을 만들지 않았다. Cloudflare도 긴 연쇄 계산과 많은 표 행의 집계는 현재 preview의 약점으로 설명하며 코드 계산을 권한다. preview 제약

null·confidence·예측 구간은 각자 다른 질문에 답한다

Clairic 문서에서 추출·계산의 단일 값이 null이면 모델이 입력으로 답을 결정하기 어렵다고 판단한 것이다. 원문에 정말 없거나, 있어도 모델이 찾지 못했을 수 있다. 반면 estimate와 forecast는 입력 정보가 적어도 예측을 반환할 수 있다. 빈칸을 채웠다는 사실만으로 근거가 충분해지는 것은 아니다. 결과 해석

API에는 p_null, confidence, guess, value처럼 함께 보아야 할 값이 있다. 특히 공식 모델 예시에는 발주 번호가 없는 필드에서 value가 null이면서 guess와 높은 confidence가 함께 나온다. 따라서 confidence 숫자 하나만 보고 guess를 업무 값으로 복사하면, 모델이 유효 답으로 내놓지 않은 후보를 되살리게 된다. 공식 응답 객체

구매 화면을 설계한다면 null은 “공급자 확인 필요”로 남기고, 원문을 다시 확인하는 동작을 붙일 수 있다. 이것은 이 글의 UI 제안이며 제공되는 Clairic 앱 화면을 설명한 것이 아니다. 넓은 화면에서는 값 옆에 원문을, 좁은 화면에서는 필드 아래 펼치는 근거를 둘 수 있다. 추정치는 확정 칸과 분리하고 “예상” 표기를 값 가까이에 유지한다. 색깔만으로 사실과 전망을 구별하지 않는 편이 좋다.

추정의 p10부터 p90까지의 구간은 모델 분포 가운데 80%에 해당한다. 새 회사의 실제 배송이 열 번 중 여덟 번 그 안에 들어온다는 검증 결과는 아니다. 가령 가상 화면에 예상 3일에서 7일이 표시됐다고 해도, 별도로 정한 계약 납기와 비교해야 한다. 계약상 4일이 필요하면 중앙값 하나보다 늦어질 가능성이 의사결정에 더 중요할 수 있다. 여기의 3일에서 7일은 설명용 값이며 실제 예측이 아니다.

입력 범위도 결과를 바꾼다. “우리 회사가 원하는 최대 7일”을 추정 상한으로 강제하면, 실제로 10일 걸릴 상황을 적절히 표현하기 어려워진다. 공식 개념 문서도 제약이 답의 형식을 제한할 뿐 현실의 결과를 보장하지 않는다고 설명한다. 범위 제약의 의미

시계열 forecast를 고려한다면 누락된 외부 사건을 따로 생각해야 한다. 공급자는 최근 패턴을 따르는 기본 예측과 장기 예측의 한계, 낯선 자료에서 구간이 좁아질 가능성을 명시했다. 정기 배송의 반복 패턴과 파업·명절·새 운송 노선은 다른 문제다. 중요한 장기 수요 계획의 전용 모델을 바로 대체하기보다, 실제 관측과 비교하는 보조 전망부터 평가할 수 있다. 출시 설명과 한계

낮은 토큰 단가와 낮은 업무 비용을 구분하기

10월 20일 확인한 요금표의 Clairic 단가는 입력 100만 토큰당 0.10달러다. 출력 토큰 요금이 없다는 설명은 생성된 긴 답변의 비용을 줄이는 구조와 맞닿아 있다. 다만 입력에는 원문뿐 아니라 필드 정의와 분할 처리의 영향도 있으므로, 원문 길이만으로 청구량을 확정하지 말고 응답의 usage를 확인해야 한다. 공식 요금표, usage 예시

가상의 요청 10만 건에서 건당 과금 입력이 정확히 1,000토큰이라면 총 1억 토큰, 모델 입력 비용은 10달러다. 이는 현재 단가를 적용한 산술이며 실제 청구서가 아니다. 무료 할당·세금·Workers 실행·저장·후속 모델·재시도·사람의 검토 비용을 포함하지 않았다. 필드 증가로 건당 입력이 두 배가 되면 이 계산의 입력 비용도 두 배가 된다.

실제 비교에서는 “모든 필드를 모델에 한 번에 요청”하는 경로와 “필수 사실만 추출하고 계산은 코드로 처리”하는 경로를 나누어 볼 수 있다. 후자가 필요한 입력·필드를 줄일 가능성은 있지만 호출 분할이나 전처리 때문에 전체 지연이 늘 수도 있다. 답변 작성 모델이 대부분의 시간을 쓴다면 추출이 빨라져도 최종 업무는 여전히 느릴 수 있다. 이때는 검색·모델·도구 지연을 나누는 방법을 적용해 단계별 시간을 확인한다.

도입 전에 같은 발주서를 어떻게 비교할까

제품 발표만으로 기존 처리 경로를 교체할 이유는 부족하다. 다음은 구매팀이 보유한 공개 가능한 자료 또는 적법하게 사용할 수 있는 문서로 수행할 평가 설계다. 이번 글에서 실행한 모델 실험은 아니다.

첫째, 업무 정답을 사람이 먼저 정한다. 요청 납기·확정 납기·실제 도착일을 분리하고, 없는 운송장 번호를 정답 빈칸으로 표시한다. 세금·할인·배송비가 충돌하는 문서는 합계 하나를 억지로 정답으로 만들지 말고 재확인이 필요한 사례로 둔다.

둘째, 기존 파서나 현재 모델과 Clairic에 동일한 문서를 준다. 양식이 깨끗한 문서, OCR 오류가 있는 문서, 번호가 여러 개 있는 문서, 정보가 빠진 문서를 나누어 본다. 한국어 조사·띄어쓰기·날짜 표현은 이 글에서 확인하지 않았으므로 독립 평가 항목으로 둔다. 쉬운 문서 평균만으로 전환을 결정하지 않는다.

셋째, 정답이 있는 필드의 일치율과 정답이 없는 필드에 값을 채운 횟수를 따로 센다. 예측은 그 시점까지 알 수 있던 자료만 입력하고 이후 실제 도착일과 비교한다. 이미 도착한 날짜를 입력에 넣고 미래 예측을 맞혔다고 하면 평가가 성립하지 않는다.

아래 기록 양식은 다음 검토 때 복사해 쓸 수 있다. 결과 수치는 아직 없으며, 임계값은 검토 비용과 오류의 영향에 따라 정할 대상이다.

문서 묶음 / 확인일 / 모델 ID와 요청 정의 버전:
정답이 있는 필드: 전체 __개, 정확 __개, 잘못 추출 __개, 누락 __개
정답이 없는 필드: 전체 __개, 근거 없이 채운 값 __개
합계 비교: 입력 자체의 충돌 __건, 계산 불일치 __건
미래 추정: 평가 대상 __건, 실제 관측 완료 __건, 구간 밖 __건
전체 처리 시간 / 과금 입력 / 재시도 / 사람 검토 시간:
유지·부분 도입·보류 결정과 가장 큰 실패 유형:

Clairic의 유력한 시작점은 반복되는 비정형 문서를 구조화된 업무 표로 옮기는 단계다. 복잡한 계산, 원문에 없는 확정 사실, 충분한 이력 없는 장기 예측까지 한꺼번에 맡기면 장점을 평가하기도 어려워진다. 필요한 사실 필드부터 비교하고, 실제로 줄어든 재입력과 새로 생긴 검토 부담을 함께 보는 것이 도입 판단에 도움이 된다.

값을 얻은 뒤 권한·업무 상태와 대조하는 단계는 스키마와 업무 검증에서 이어 읽을 수 있다. 이번 글의 필드 구분표를 다시 쓸 때는 상단 저장 기능을, 다른 모델·구조 비교에는 AI 시스템 모음과 RSS를 이용할 수 있다.