Jev가 사진을 읽는다: 반품 확인부터 손상 부위 찾기까지

고객이 금이 간 머그잔 사진을 보냅니다. 고객 지원 도구는 서로 다른 세 가지 질문에 답해야 합니다. 머그잔이 보이는가, 사진에 손상이 찍혔는가, 검토자는 어느 부분을 살펴봐야 하는가? 도자기에 관한 유창한 문단은 이 과정에서 가장 유용한 중간 결과가 아닙니다.

TypeSafe AI는 2026년 10월 14일 Jev 1.14.0 및 새로운 box 출력 타입과 함께 실험적 이미지 지원을 발표했습니다. 이미지는 Jev 1.13과 1.14 모두에서 사용할 수 있고 Box는 1.14가 필요합니다. TypeSafe는 이 기능들이 실험 단계라고 밝히며 운영 자동화에 사용하라고 권고하지 않습니다. 공식 발표

유용한 변화는 범용 멀티모달 비서보다 범위가 좁습니다. 사진을 타입이 지정된 결정이나 프로그램에서 다룰 수 있는 위치 좌표로 바꿀 수 있습니다. 반품 워크플로가 어떻게 달라지는지, 인터페이스가 무엇을 받는지, 사각형을 증거로 착각하지 않으면서 신중한 프로토타입을 만드는 방법을 살펴보겠습니다.

자체 제작한 설명 도식입니다. 사진을 입력하면 판정과 좌표가 각각 출력되고, 사람이 제안된 손상 부위를 검토합니다. 워크플로 예시이지 실제 모델 결과를 기록한 것이 아닙니다.

요약:

• Jev는 이미지 생성을 지원하는 것이 아니라 정지 이미지 이해를 위한 실험 경로를 제공합니다.
• 대상이 존재하는지 먼저 확인한 다음 제안된 위치를 신뢰하세요.
• 원본 사진과 사람의 검토를 유지하고, 코드가 좌표와 권한, 후속 조치를 검증하도록 하세요.

사진을 설명 대신 판정으로 바꿀 수 있다

Jev의 기존 장점은 범위가 정해진 답변이었습니다. 제공된 선택지 중 하나를 고르거나, 설명된 수준에 따라 평가하거나, 예·아니요 명제를 판정합니다. 이 기반은 Jev 의사결정 모델에 관한 이전 가이드에서 다뤘습니다. 새로 추가된 것은 질문에 시각적 근거를 제공하고 공간 좌표까지 돌려받는 기능입니다.

반품 인터페이스에서는 업무 분담이 달라집니다. 모델은 손상이 보인다고 제안할 수 있고, 애플리케이션 코드는 제출된 이미지 옆에 그 제안을 표시할 수 있습니다. 어느 쪽도 손상이 언제 생겼는지, 사진이 해당 주문의 것인지, 환불 권한이 있는지 입증하지 않습니다. 각각 다른 근거가 필요한 별도의 질문입니다.

이 경계는 모델 레퍼런스, API 요청 계약, 이미지 지원 SDK를 따른 것입니다. PDF 몇 페이지에 그림이 들어 있다고 해서 PDF 폴더가 문서 처리 파이프라인으로 바뀌지는 않습니다. 마찬가지로 프레임을 몇 개 추출해도 네이티브 비디오 이해나 클립의 사운드트랙 접근을 뜻하지 않습니다.

저희의 관점은 이렇습니다. 흥미로운 단위는 근거에 연결된 작고 검사 가능한 판정입니다. 후속 작업을 전부 자동화해도 된다는 새 권한이 아닙니다.

같은 사진을 서로 다른 작업으로 바꾸는 공식 예시 세 가지

TypeSafe의 JavaScript 문서에는 구체적인 시작 예시 세 가지가 있습니다. 공개된 코드 예제이지 실제 고객 배포나 측정 결과를 보고한 것이 아닙니다. 실제 사진에서의 정확도를 보장하는 약속이 아니라 프로토타입 패턴으로 활용하세요.

첫 번째 예시는 파손된 머그잔 주장과 제품 사진을 함께 넣고, Noul에 손상 여부를 묻고 Score로 심각도를 평가합니다. 고객 지원 대기열에서는 이를 응용해 의심되는 손상이 있는 사례를 검토 목록 상단에 올릴 수 있습니다. 그래도 검토자는 전체 사진과 고객 설명을 볼 수 있어야 하며 제안을 거부할 수 있어야 합니다.

두 번째는 판매자가 올린 사진과 카탈로그 이미지를 비교합니다. 두 사진이 같은 제품을 보여 주는지 묻고 흐림, 잘림, 제품 외 요소를 포함해 사진의 사용 적합성을 분류합니다. 마켓플레이스에서는 제품 식별과 사진 품질을 하나의 승인 결정으로 묶지 않는 편이 유용할 수 있습니다. 전문가처럼 보이는 선명한 사진이라도 다른 제품의 사진이면 통과시켜서는 안 됩니다.

세 번째는 Box에 손상 부위를 찾도록 요청합니다. 결과를 검토자용 오버레이나 제안 크롭으로 활용할 수 있습니다. 잘리지 않은 원본도 함께 보존하세요. 주의를 특정 부분에 모으면 주장을 살펴보기 쉬워지지만, 의미를 바꾸는 맥락을 감출 수도 있습니다.

손상 평가, 카탈로그 비교, 손상 위치 탐지에 대한 공식 예시를 참고하세요. 저희가 제안하는 반품 흐름은 이런 패턴에 애플리케이션 보호 조치를 더한 것이며 실제 시험을 보고하는 글은 아닙니다.

상자만으로 찾을 대상이 없다고 판단할 수는 없다

TypeSafe Box 계약의 핵심은 대상이 없음을 나타내는 출력이 없다는 점입니다. 요청한 대상이 없어도 Box 질문은 네 개의 경계값을 반환합니다. 따라서 온전한 머그잔을 둘러싼 사각형만으로 손상이 있다는 사실을 입증할 수 없습니다.

요청한 대상이 있는지 별도로 Noul에 물어보세요. 이 워크플로에서는 머그잔이 보이는지와 손상이 보이는지를 구분합니다. 머그잔이 있다는 긍정 답변만으로 손상 오버레이를 표시할 권한이 생기지는 않습니다. 관련된 존재 확인이 검증된 규칙을 통과하지 않으면 손상 상자 제안은 무시하세요.

존재 확인은 실수를 치료하는 만능책이 아닙니다. 두 판정이 동시에 틀릴 수 있습니다. 밝은 반사가 이 빠진 흔적으로 보이거나, 무늬가 있는 유약 위의 실제 균열을 놓칠 수 있습니다. 머그잔이 없는 사진, 온전한 머그잔, 모호한 반사, 물체가 여러 개 있는 사진, 손상이 분명한 사진으로 임계값을 정하기 전에 시험하세요.

자체 제작한 의사결정 도식입니다. 유효한 사각형은 대상 존재 확인을 통과한 뒤에만 사용할 수 있습니다. 검사에 실패하거나 결과가 불확실하면 원본 사진을 사람의 검토에 넘기며 자동 거부로 이어지지 않습니다.

사각형은 판결이 아니라 가리키는 표시라고 생각하세요.

좌표를 도형 정보로 다루고 의미도 확인한다

Box는 이미지의 왼쪽 위 모서리를 기준으로 잰 이미지 크기 대비 비율로 left, right, top, bottom을 반환합니다. 값은 0부터 1까지이며 left < right, top < bottom이어야 합니다. 질문 하나당 상자 하나를 반환하며 물체 탐지 목록을 주지는 않습니다. Box 응답 계약

예시로 준비된 이미지가 1200 x 900일 때 왼쪽 0.20, 위쪽 0.30, 오른쪽 0.60, 아래쪽 0.70은 픽셀 경계 240, 270, 720, 630에 해당합니다. 산술 예시이지 Jev의 실제 응답이 아닙니다. 자르기 API는 보통 왼쪽, 위쪽, 오른쪽, 아래쪽 순서를 기대하므로 JSON 속성 순서에 의존하지 말고 필드 이름에 맞춰 매핑하세요.

무엇이든 그리기 전에 유한한 숫자인지, 범위와 순서가 유효한지 검사하세요. 이어 해당 영역이 실제로 손상 부위를 가리키는지 확인합니다. 사진을 크기 조정·회전·패딩·타일링했다면 좌표를 원본에 되돌리는 데 필요한 변환을 보관하세요. 그렇지 않으면 그럴듯한 상자가 엉뚱한 픽셀을 가리킬 수 있습니다.

오류가 난 뒤가 아니라 요청 전에 이미지를 준비한다

공식 이미지 제한은 명확하며 경계값도 포함합니다. 범위를 벗어난 이미지는 자동 크기 조정되지 않고 거부되며, 이미지 하나라도 거부되면 요청 전체가 실패합니다.

확장 요청에서는 반복 참조도 매번 다시 계산됩니다. 파일 크기, 이미지 크기, 컨텍스트 길이는 서로 별개의 검사 항목입니다. 이미지 제한

2026년 10월 18일 확인한 TypeSafe 이미지 문서를 바탕으로 자체 제작한 제약 도식입니다. 파일별, 처리된 이미지, 확장 요청, 요청 본문 한도는 각각 독립적으로 적용됩니다.

TypeSafe는 전송 전에 픽셀 방향을 바로 세우라고도 안내합니다. API는 메타데이터를 제거하며 EXIF 방향 정보를 적용하지 않습니다. 지원하지 않는 형식은 먼저 변환하세요. 준비 안내

프로토타입에서는 본인 소유 사진의 이름을 분명히 한 복사본을 준비하고 원본은 그대로 보관하세요. 로컬에서 크기를 확인한 뒤 실제 전송할 복사본을 미리보기로 살펴보세요. 짧은 변은 최소 크기를 맞추려고 패딩해야 할 수 있으므로 좌표를 해석하기 전에 그 패딩을 기록하세요.

1.14를 고정하고 실험 기능 스위치를 명시한다

10월 18일 기준, 공개된 별칭 표에서 jev-latest는 jev-1.13.0, jev-preview는 jev-1.14.0을 가리킵니다. Box 예제에서는 latest가 가장 새로운 프리뷰를 뜻한다고 가정하지 말고 jev-1.14.0을 고정하세요. 모델 별칭

다음 절차는 검토 전용 로컬 예제를 만듭니다. 마지막 명령을 실행하면 과금 대상 추론 요청이 전송되며 SDK가 재시도할 수도 있습니다. 이 코드는 반품을 승인하거나 계정을 변경하지 않습니다. 사람이 없고 배송 라벨, 주소, 비공개 문서도 찍히지 않은 본인 소유의 준비된 사진을 사용하세요.

1. 접근 권한을 얻고 적절한 조직을 선택합니다. TypeSafe 안내에 따르면 회원 가입에 대기자 명단 승인이 더는 필요하지 않습니다. 콘솔에서 API 키를 만들고 시험 전에 조직 크레딧을 확인하세요. 계정 접근, 크레딧 설정

2. Node.js 22 이상을 사용합니다. 이미지를 지원하는 JavaScript SDK 릴리스는 0.7.0이며 10월 14일자로 게시됐습니다. 버전을 고정해 이 예제의 클라이언트 의존성을 명확히 합니다. SDK 변경 기록

node --version
mkdir jev-photo-check
cd jev-photo-check
npm init -y
npm install @typesafe-ai/[email protected]

3. 현재 셸에서만 사용할 키를 설정합니다. Windows PowerShell에서는 첫 번째 블록을, macOS 또는 Linux Bash/Zsh에서는 두 번째 블록을 사용하세요. 자리표시자는 로컬에서 실제 값으로 바꾸고 진짜 키를 커밋하지 마세요.

$env:TYPESAFE_API_KEY = "your-api-key"

export TYPESAFE_API_KEY="your-api-key"

4. owned-mug.jpg를 준비하고 inspect-return.mjs를 만듭니다. 아래는 문서화된 SDK 도우미를 사용해 새로 작성한 응용 예제입니다. 이미지 요청을 보내기 전에 실험 기능 헤더를 설정합니다. 아래 두 확률 기준은 설명을 위한 애플리케이션 규칙이지 TypeSafe의 권고값이 아닙니다. 모든 결과는 사람이 검토해야 합니다. SDK 사용법

import { readFile } from "node:fs/promises";
import { box, image, noul, TypeSafeClient } from "@typesafe-ai/sdk";

if (!process.env.TYPESAFE_API_KEY) {
  throw new Error("Set TYPESAFE_API_KEY before choosing to run this example.");
}

const client = new TypeSafeClient({
  defaultHeaders: { "TypeSafe-Danger-Zone-Images": "true" },
});
const photo = image(await readFile("owned-mug.jpg"));
const response = await client.systemOne({
  model: "jev-1.14.0",
  state: { photo },
  questions: {
    mugVisible: noul("Is a mug clearly visible in `photo`?"),
    damageVisible: noul("Is physical damage clearly visible on the mug in `photo`?"),
    damageRegion: box("The physically damaged area of the mug in `photo`"),
  },
});

const { mugVisible, damageVisible, damageRegion } = response.answers;
const edges = damageRegion.box;
const coordinates = [edges.left, edges.top, edges.right, edges.bottom];
const validBox = coordinates.every(
  (value) => Number.isFinite(value) && value >= 0 && value <= 1,
) && edges.left < edges.right && edges.top < edges.bottom;

const presencePasses = [mugVisible.noul, damageVisible.noul].every(
  (value) => Number.isFinite(value) && value >= 0.95 && value <= 1,
);

console.log({
  model: response.model,
  usage: response.usage,
  humanReviewRequired: true,
  suggestedBox: presencePasses && validBox ? edges : null,
});

5. 이미지를 보내고 사용료가 발생할 준비가 된 경우에만 실행합니다. 세 운영체제 모두 node inspect-return.mjs를 실행하면 됩니다. 예외가 나거나 suggestedBox: null이 반환되면 원본 이미지를 검토할 수 있도록 유지하세요. 자동으로 반복 제출하지 마세요.

질문은 한 요청을 공유하지만, 애플리케이션의 확인 단계를 통과하지 않으면 상자를 사용하지 않습니다. 사용하지 않은 상자를 계산하는 비용까지 절감되는 것은 아닙니다. 이후 설계에서는 존재 확인 뒤 두 번째 요청으로 위치를 찾을 수 있습니다. 이 방식은 왕복 요청을 하나 더 하는 대신 불필요한 위치 탐지 요청을 줄입니다.

사진 한 장의 비용은 토큰 가격만으로 정해지지 않는다

두 버전 모두 공개된 입력 가격은 토큰 100만 개당 $0.042이고 출력 토큰은 무료입니다. 따라서 입력 토큰 1,000만 개는 안내된 요금으로 $0.42입니다. 이미지 천만 장의 가격이라는 뜻은 아닙니다. 공개 요금

이미지에는 별도의 이미지 요금 없이 텍스트 요율로 입력 토큰이 부과됩니다. TypeSafe 문서에는 아직 이미지 토큰 추산 공식이 없습니다. 승인된 평가의 비용을 계산할 때 사진당 비용을 지어내지 말고 응답의 usage.input_tokens를 사용하세요. 이미지 과금

예산에는 실패한 시도, 재시도, 전처리, 저장, 검토자 시간을 포함해야 합니다. 비용과 품질 측정치를 함께 관리하세요. 몇 센트를 절약해도 크롭이 지나치게 좁아 검토자가 매번 원본을 다시 열어야 한다면 도움이 되지 않습니다. 전체 검토 작업을 간단한 수동 기준선과 비교하세요.

불확실성과 개인정보, 서비스 부하를 고려해 설계한다

Noul은 별도의 confidence 필드 없이 확률을 반환합니다. Choice와 Score는 분포와 여기에서 파생한 신뢰도 값을 포함합니다. 이 값은 모델의 불확실성을 나타낼 뿐 정확성을 보증하는 증명서는 아닙니다. 신뢰도 문서

머그잔 워크플로에서는 합의된 라벨이 있는 보류 사진으로 확인 단계를 검증하세요. 비슷한 출력을 묶고 관찰된 정답률과 비교해 해당 작업에서 보정이 잘 됐는지 살펴보세요. 손상 누락과 오탐을 따로 측정하고, 오버레이 위치 오류와 잘못된 환불 결정을 구분하세요. 모델, 조명, 제품군, 촬영 절차를 바꾸면 임계값도 다시 평가하세요.

통과하지 못한 모든 이미지를 고객에 대한 불리한 증거로 취급하지 마세요. 카메라 품질이 나쁘거나 물체가 반사되거나 다른 각도의 사진이 필요한 경우 사진이 불충분할 수 있습니다. 유용한 검토 상태는 모델의 불확실성을 고객 책임으로 돌리지 않고 다른 사진 요청과 수동 검사 경로를 제공해야 합니다.

TypeSafe는 고객의 요청과 응답을 Jev 학습에 사용하지 않는다고 설명합니다. 도움말 센터에는 서비스 제공, 결제, 악용 방지, 텔레메트리도 처리에 포함될 수 있고 보존은 데이터, 계약, 제로 데이터 보존 약정에 따라 달라진다고 나와 있습니다. 학습에 사용하지 않는다는 것과 보존하지 않는다는 것은 다릅니다. 데이터 처리 정책

공개 서비스 상태 페이지에는 미국 지역과 us-east-1, us-east-2, us-west-2가 표시됩니다. 데이터 지역 요건이 있는 팀은 고객 사진을 올리기 전에 처리 위치를 확인해야 합니다. 콘솔에 접속할 수 있다는 사실은 데이터 상주 계약이 아닙니다.

업로드 전에 데이터 최소화를 적용하세요. 준비된 복사본에서 필요하지 않은 주소 라벨을 자르고, 원본 접근 권한을 제한하고, 이미지나 비밀 정보를 일반 로그에 넣지 마세요. 제공업체 정책과 별도로 자체 검토 기록의 보존 기간도 정하세요.

조직 한도는 초당 요청 수와 토큰 수에 적용됩니다. API는 요청 제한에 429, 과부하에 529를 문서화하고 있습니다. 형식이 잘못됐거나 너무 큰 입력은 수정해야 하며, 그대로 다시 보내서는 안 됩니다. 요청 제한, API 오류

JavaScript SDK의 기본 재시도 정책은 두 번 재시도하며 지원되는 재시도 지연 헤더를 따릅니다. 제한 없는 바깥쪽 재시도 루프를 추가하지 마세요. 시간 한도를 정하고 조치할 수 있는 오류 상태를 보존하며, 향후 비즈니스 조치를 분리해 추론 재시도로 환불이 중복 실행되지 않도록 하세요. 재시도 정책

첫 사진 워크플로 전에 답할 질문

Jev가 반품 사진을 편집하거나 생성하나?

아닙니다. 이미지는 판정이나 제안 영역을 위한 근거입니다. 애플리케이션이 일반 이미지 처리 코드로 오버레이를 그리거나 크롭합니다. 수정하지 않은 원본을 따로 보관하세요. 쓸 만한 사각형이 원래 근거를 대신하지는 않습니다.

예제에서 latest 대신 1.14를 고정하는 이유는 무엇인가?

공개 별칭 표에서는 현재 jev-latest가 1.13을 가리키고 Box에는 1.14가 필요합니다. jev-1.14.0을 고정하면 해당 의존성이 명확해집니다. 별칭이 바뀌어도 동작이 유지된다고 가정하지 말고, 버전을 변경하기 전에 릴리스 정보를 확인하고 테스트 세트를 실행하세요.

손상 확률이 높으면 환불을 실행해도 되나?

그 근거만으로는 안전하지 않습니다. 확률은 제출된 이미지에 관해 질문한 내용에 대한 것이지 주문을 인증하거나 책임 소재를 확정하거나 환불 정책을 적용한 결과가 아닙니다. 검토 보조 기능으로 시작하고 대표 사례를 검증하며 중요한 조치는 사람이 결정하도록 하세요.

출력이 무료라면 이미지 요청도 비용이 들지 않나?

아닙니다. 이미지 토큰을 포함한 입력 토큰은 과금됩니다. 이미지 토큰 추산 공식이 아직 문서화되지 않았으므로 공개 요율은 사진당 견적이 아닙니다. 승인된 시범 운영에서 보고된 사용량을 확인하고 재시도와 검토 시간을 총비용에 포함하세요.

제품 동영상이나 PDF를 바로 보낼 수 있나?

문서화된 정지 이미지 인터페이스로는 보낼 수 없습니다. 처리 권한을 확보한 뒤 애플리케이션에서 적절한 프레임, 텍스트, 렌더링된 페이지를 추출해야 합니다. 프레임을 준비하면 시간 정보와 오디오 정보가 사라지므로 제공된 근거만으로 답할 수 있는 질문을 하세요.

결론: 권한을 넘기기 전에 주의를 집중시킨다

Jev 이미지 프리뷰가 제시하는 실용적인 방향은 시각적 근거를 소프트웨어가 검사할 수 있는 작은 답으로 바꾸는 것입니다. 머그잔 반품 도구는 존재, 손상, 위치, 검토를 분리해 이 방향을 시험할 수 있습니다. 가장 가치 있는 첫 결과는 자동 환불이 아니라 검토자가 덜 헤매고 더 충분한 근거로 판단하는 것입니다.

측정해야 할 기준은 이것입니다. 모델이 틀렸을 때도 제안된 영역이 사람이 원본 근거를 더 잘 이해하도록 돕나요?

출처와 범위

주요 출처는 2026년 10월 18일 확인했습니다. TypeSafe의 10월 14일 발표, 모델 및 요금, 이미지 제한과 과금, Box 계약, JavaScript 예제, SDK 릴리스 정보를 참고했습니다. 추가 정책과 신뢰성 자료는 관련 주장 옆에 연결했습니다. 작업 흐름과 도식은 설명을 위한 응용 예시이지 직접 수행한 벤치마크가 아니며, 이 글을 위해 유료 모델 호출은 하지 않았습니다. 도식은 벤더 미디어를 복사하지 않고 직접 제작했습니다.

결론과 원문을 함께 보관한다

직접 모델을 조사할 때는 원본 출처와 그에 대한 결론을 구분해 함께 보관하세요. Telli.sh 계정을 만들어 조사 자료와 파생 메모를 출처 맥락과 함께 정리할 수 있습니다.