Jev 1.14 이미지 입력 사용법, GPT-6 Luna와 50문제 비교

Jev 1.14 이미지 입력을 어떻게 쓰는지, 그리고 같은 부류의 OpenAI Decisions API(GPT-6 Luna)와 50문제로 나란히 돌려 보면 정확도⁠·속도⁠·비용이 어떻게 나오는지 정리했습니다. 이미지를 넣어 질문하는 방법, 위치를 찾는 새 질문 유형 박스(Box), 아직 미리 보기 단계라 생기는 제약까지 담았습니다.

결과부터: 정답 48 대 49

TypeSafe가 2026년 10월 14일 내놓은 Jev 1.14에서 가장 큰 변화는 이미지를 보는 기능입니다. 다른 성능도 조금씩 좋아졌고, TypeSafe는 그중 다국어 성능에서 가장 큰 개선을 기대한다고 안내합니다. 다만 공식 문서에서 가장 강한 언어는 여전히 영어입니다. jev-latest 별칭은 발표 일주일 뒤 1.14로 넘어가므로, 버전이 바뀌는 게 싫다면 jev-1.14.0처럼 버전을 고정해 씁니다.

같은 이미지와 같은 질문 50개를 Jev와 GPT-6 Luna에 넣어 비교한 결과는 이렇습니다.

• 정확도: Jev 48개, GPT-6 Luna 49개. 거의 같습니다.
• 속도: 한 문제에 Jev 0.27초, Luna 0.37초. Jev가 빨랐습니다.

흔히 "200배 빠르다"는 말이 붙지만, 그건 글을 쓰는 대형 언어 모델과 견준 제작사 자체 수치입니다. 같은 결정 모델끼리 견준 이 테스트에서는 0.27초 대 0.37초 정도 차이였습니다.

Jev는 어떤 모델인가

Jev는 긴 글을 쓰는 대신 질문에 대한 확률로 바로 답하는 결정 모델입니다. 문장을 만들지 않으니 빠르고 쌉니다. 기본 개념(시스템 원 모델, 질문 유형 Choice·Noul·Score)은 TypeSafe 공식 문서(docs.typesafe.ai)에 정리돼 있습니다.

Jev 1.14에서 새로 열린 기능

새 기능은 세 가지입니다.

• 이미지 입력: 질문에 이미지를 넣을 수 있습니다.
• 박스(Box): 이미지 속 위치를 찾는 새 질문 유형입니다.
• 긴 입력: TypeSafe-Danger-Zone-Long-Context: true 헤더를 넣으면 한 번에 약 26만 토큰(262K)까지 긴 글을 넣을 수 있습니다. 기본 한도는 요청당 6만 4천 토큰, 질문당 3만 2천 토큰입니다. 긴 입력 모드는 더 느리고 정확도도 떨어진다고 TypeSafe는 밝힙니다.

세 기능 모두 아직 미리 보기 단계입니다. TypeSafe는 이 단계를 "Dreamer-ready"라고 부르며, 실제 서비스(프로덕션)에 쓸 준비는 아직 안 됐다고 밝힙니다. 그래서 요청할 때 기능을 켜는 설정(헤더)을 따로 넣어야 합니다.

이미지는 1.13부터 볼 수 있었다

조금 놀라운 점은 Jev가 원래부터 이미지를 볼 수 있었다는 것입니다. 공식 문서에도 이미지 입력은 Jev 1.13과 1.14 모두 지원한다고 적혀 있습니다. 처음 공개할 때 이미지 기능을 막아 두었다가 이번에 연 셈입니다. 실제로 이전 모델 1.13에 같은 이미지 문제를 내 보면 24개 가운데 23개를 맞혔습니다.

OpenAI가 이미지를 받는 Decisions API를 공개 베타로 연 것은 10월 6일입니다. 그때만 해도 Jev는 아직 이미지를 못 본다는 반응이 많았는데, 일주일 남짓 만에 상황이 달라졌습니다.

Jev에 이미지 넣어 질문하는 5단계

쓰는 방법은 간단합니다. 평소처럼 질문을 보내되, 이미지를 함께 올리고 질문 안에서 그 이미지를 이름으로 가리키면 됩니다.

준비물

• TypeSafe API 키(콘솔 console.typesafe.ai에서 발급)와 SDK. 파이썬이면 typesafe_sdk 패키지를 씁니다.
• 질문에 첨부할 이미지 파일. PNG나 JPEG 정지 이미지만 되고, 가로세로 각각 280~1568픽셀, 파일 하나에 16MiB까지입니다. 범위를 벗어난 이미지는 자동으로 줄여 주지 않고 거부되니 미리 줄여서 넣습니다.
• 위치 찾기(박스)를 쓰려면 모델 1.14(jev-1.14.0 또는 jev-preview)
• 비용: 2026년 10월 기준 입력 100만 토큰당 0.042달러이고 출력은 무료입니다. 요금은 바뀔 수 있으니 공식 안내를 확인합니다.

1단계. 평소 쓰던 방식으로 Jev에 보낼 질문 문장을 준비합니다

• 확인: 질문 문장이 있습니다. 이미지가 없을 때와 똑같이 씁니다.

2단계. 첨부할 이미지에 이름을 붙이고, 질문에서 그 이름을 가리킵니다

이미지에 door 같은 이름을 붙였다면 질문에는 백틱(`)으로 감싼 이름을 씁니다.

이 사진에 사람이 있나요

위 문장을 실제 요청에 넣을 때는 "door에 사람이 있나요?"처럼 이미지 이름을 넣어 씁니다.

• 확인: 질문 안에 이미지를 가리키는 이름이 들어 있습니다.

3단계. 질문과 함께 이미지 파일을 올립니다

SDK를 쓰면 이미지 객체를 질문 옆에 넣기만 하면 업로드까지 알아서 합니다. 공식 문서 예제를 바탕으로 한 파이썬 코드입니다.

from pathlib import Path

from typesafe_sdk import Choice, Image, Noul, TypeSafeClient

with TypeSafeClient() as client:
    result = client.system_one(
        state={"door": Image(Path("door-camera.jpg"))},
        questions={
            "person_present": Noul(instructions="`door`에 사람이 있나요?"),
            "carrying": Choice(
                instructions="`door` 속 사람이 무엇을 들고 있나요?",
                criteria={
                    "package": "상자나 택배",
                    "bag": "장바구니나 쇼핑백",
                    "nothing": "빈손",
                },
            ),
        },
        extra_headers={"TypeSafe-Danger-Zone-Images": "true"},
    )
    print(result.answers)

• 주의: 이미지가 1568픽셀을 넘으면 줄여서 넣습니다. 세로로 긴 썸네일 같은 이미지가 여기에 자주 걸립니다.
• 확인: 요청에 이미지 파일이 들어갑니다. 여러 질문에서 같은 이미지를 쓸 때는 state에 한 번만 넣고 각 질문에서 이름으로 가리키는 편이 용량을 아낍니다.

4단계. 요청에 이미지 기능을 켜는 헤더를 한 줄 더합니다

TypeSafe-Danger-Zone-Images: true

• 주의: 새 기능은 미리 보기 단계라 이미지나 박스 질문이 들어간 요청마다 이 헤더가 따로 필요합니다. 빠뜨리면 400 오류가 납니다. 위 파이썬 예제의 extra_headers 줄이 이 설정입니다.
• 확인: 이미지가 들어간 질문이 처리됩니다.

5단계. 질문 유형을 고릅니다

다음 세 유형이 모두 이미지를 받습니다.

• 예와 아니요를 묻는 질문(Noul)
• 선택지 가운데 하나를 고르는 질문(Choice)

• 점수를 매기는 질문(Score)

• 대안: 이미지에서 위치를 찾는 박스 질문은 모델 1.14가 있어야 합니다. 요청의 model 값을 jev-1.14.0 또는 jev-preview로 정합니다.

• 확인: 결과가 확률로 나옵니다. 박스는 위⁠·아래⁠·왼쪽⁠·오른쪽 네 변의 위치를 이미지 크기에 대한 비율(0~1)로 돌려주고, 자신감 값(confidence)을 함께 줍니다.

다 했는지 확인

• 이미지가 들어간 질문이 Jev에서 처리된다
• 박스를 쓸 때는 1.14 모델을 썼다

막히기 쉬운 곳

• 박스가 안 될 때: 박스는 모델 1.14가 필요합니다. 쓰는 모델이 jev-1.14.0이나 jev-preview인지 봅니다.
• 이미지 요청이 400 오류로 거절될 때: 미리 보기라 TypeSafe-Danger-Zone-Images: true 헤더가 꼭 필요합니다. 올린 이미지를 질문 어디에서도 가리키지 않아도 400 오류가 납니다.
• 큰 이미지가 거부될 때: 가로세로 1568픽셀까지만 받으니 줄여서 넣습니다. GIF, WebP, HEIC는 PNG나 JPEG로 바꿉니다.

두 모델을 같은 조건으로 비교하고 싶다면 두 회사의 공식 문서를 Claude Code에 주고 테스트 코드를 맡기면 됩니다. 몇 분이면 같은 질문을 두 모델에 돌리는 코드가 나옵니다.

50문제 비교 테스트는 이렇게 짰다

비교 상대는 OpenAI Decisions API입니다. GPT-6 Luna 모델로 돌아가고, Jev처럼 글과 이미지를 함께 봅니다.

다섯 그룹으로 나눴고, 그룹마다 10문제씩 두 모델에 같은 이미지와 같은 질문을 넣었습니다.

• 영어가 들어간 이미지
• 한국어가 들어간 이미지
• 영어 글
• 한국어 글
• 실제 웹사이트 메인 페이지 SEO 검수

그룹별 결과

이미지: 둘 다 20문제 전부 정답

메뉴판 가격, 영수증 합계, 작은 글씨로 적힌 쿠폰 코드, 유튜브 썸네일 문구 등을 물었습니다. 일부러 함정도 넣었습니다.

• 영수증: 질문에 300원이 틀린 합계를 넣었습니다.
• 쿠폰 코드: 연한 회색 작은 글씨로 적어 두고, 가짜 코드로 물었습니다.

결과는 두 모델 모두 영어 이미지와 한국어 이미지 각 10개를 전부 맞혔습니다. 한글과 영어가 섞인 썸네일도 문제없이 읽었습니다.

영어 글: Luna 10개, Jev 9개

글 테스트에서는 리뷰 만족도, 스팸 문자, 문의, 코드 버그, 악성 댓글을 물었습니다.

영어 글은 Luna가 10개를 모두, Jev는 9개를 맞혔습니다. Jev는 마지막 원소를 제대로 가져오는 멀쩡한 코드를 0.64의 확률로 버그라고 답했습니다.

한국어 글: 둘 다 틀린 반어법 리뷰

두 모델이 똑같이 틀린 한국어 리뷰가 있었습니다.

와, 배송 진짜 빠르네요. 주문하고 2주 만에 왔어요. 최고입니다.

사람이 읽으면 화가 난 리뷰인데, 둘 다 만족한 고객이라고 답했습니다. Jev는 0.94, Luna는 1.0이었습니다. 같은 뜻의 영어 리뷰는 둘 다 비꼬는 말이라는 걸 알아챘습니다. 한국어 반어법은 아직 두 모델 모두 약합니다. 한국어 리뷰 분류에 쓴다면 반어법이 섞인 문장은 사람이 다시 보는 단계를 두는 편이 안전합니다.

웹사이트 SEO 검수: 둘 다 10개 정답

메인 화면 캡처와 페이지 HTML을 함께 넣고 이런 것을 물었습니다.

• 첫 화면에 사이트를 설명하는 큰 제목과 가입 버튼이 있는지
• 제목 태그와 설명 문구가 적당한지
• 가장 큰 제목 태그가 하나뿐인지

두 모델 모두 10개를 다 맞혔습니다. 그중 하나는 실제로 고쳐야 할 문제였습니다. 메인 페이지 이미지 가운데 81개의 대체 텍스트(alt, 이미지를 글로 설명하는 속성)가 비어 있었습니다. 검색 엔진과 화면 낭독기는 이 설명으로 이미지를 이해하는데 그게 빠져 있었고, 두 모델 모두 이 문제를 짚었습니다.

Jev에만 있는 박스

박스는 이미지에서 찾고 싶은 것을 말하면 그 위치를 상자로 알려 주는 기능입니다. 결과를 이미지 위에 분홍 상자 같은 표시로 그려 확인할 수 있습니다.

메뉴판 가격, 확인 버튼, 연한 쿠폰 코드, 30줄짜리 코드 속 버그가 있는 줄까지 여섯 번 모두 제자리를 찾았고, 한 번에 0.2초에서 0.3초가 걸렸습니다.

비용: 단가는 절반 이하, 총액은 거의 같다

• 단가: 입력 100만 토큰에 Jev 0.042달러, Luna 0.1달러. Jev가 절반 이하입니다.
• 토큰 사용량: 같은 이미지를 넣어도 Jev가 토큰을 두 배 넘게 썼습니다.
• 50문제 전체 비용: 둘 다 0.4센트 정도로 거의 같았습니다. 우리 돈으로 6원이 안 됩니다.

이미지를 많이 넣는 작업이라면 단가만 보지 말고, 같은 이미지에 실제로 몇 토큰이 잡히는지까지 보고 비교해야 합니다.

이 비교 테스트의 한계

• 50문제로 규모가 작습니다.
• 이미지 상당수는 정답을 확실히 알 수 있도록 직접 만든 것입니다.
• 이미지 기능은 아직 미리 보기라 요청 형식이나 정확도가 바뀔 수 있습니다. TypeSafe도 이미지가 섞인 질문의 성능이 글만 있을 때보다 떨어진다고 밝힙니다.
• Jev는 이미지 크기를 가로세로 1568픽셀까지만 받습니다.

그러니 48 대 49라는 결과도 이 조건 안에서의 비교입니다. 내 작업에 쓸 만한지는 실제 데이터 수십 건으로 직접 돌려 봐야 압니다.

Jev 같은 결정 모델은 같이 쓴다

결론은 "우선 쓸 만하다"입니다.

긴 코드와 글은 Claude나 Codex가 쓰고, 빠르게 반복되는 판단은 Jev 같은 결정 모델에 맡기는 식으로 같이 쓰면 작업에 따라 토큰 비용을 크게 낮출 수 있습니다. 예를 들어 상품 사진에 문제가 있는지, 문의 메일이 환불 요청인지, 페이지에 필수 요소가 빠졌는지 같은 판단은 결정 모델에 넘기고, 답장 작성이나 수정안 작성은 언어 모델이 맡는 식입니다. 이런 모델은 발전 속도가 빠를 수 있어 버전이 바뀔 때마다 같은 테스트를 다시 돌려 보는 것이 좋습니다.