[카테고리:] AI 기술

고객 문의를 읽고 담당 부서를 고르는 일에는 긴 답변이 필요하지 않습니다. 검색 결과를 다시 정렬할 때도 문장보다는 문서별 점수가 쓸모 있습니다. TypeSafe AI의 Jev는 이런 판단을 맡는 모델입니다. 글을 생성하는 대신, 프로그램이 다음 작업에 사용할 선택값과 확률을 돌려줍니다.

속도와 가격을 앞세운 모델이지만, 공개 실험에서 나온 결과는 업무마다 달랐습니다. 단순한 감성 분류에서는 높은 정확도를 냈고, 선택지가 많은 분류에서는 비교 모델에 뒤졌습니다. 아래 수치와 가격은 2026년 9월 22일 확인한 공식 자료와 외부 실험에서 가져왔습니다. 직접 API를 측정한 결과는 아닙니다.

1. Jev는 무엇을 입력받고 무엇을 돌려줄까

Jev에는 판단할 자료인 state와 질문, 허용할 답을 함께 보냅니다. 고객 문의 하나를 놓고 담당 부서, 긴급 대응 여부, 우선순위를 각각 묻는 식입니다. TypeSafe는 이렇게 문장 대신 판단값을 받는 방식을 System One이라고 부릅니다. TypeSafe 소개

질문 형식은 세 가지입니다. Choice는 후보 중 하나를 고르고, Noul은 ‘예’의 확률을 반환합니다. Score는 순서가 있는 평가 기준에 따라 점수를 매깁니다. 앞의 고객지원 예시는 이 인터페이스를 설명하기 위한 가상 사례입니다. 공식 API 문서

형식을 제한하면 엉뚱한 문자열이 나오는 문제는 줄일 수 있어도 오분류까지 막지는 못합니다. ‘결제팀’과 ‘계정팀’ 중 하나를 반환하게 해도 결제 문의를 계정팀에 보낼 수 있습니다. 기존 LLM도 구조화된 출력을 지원하는 만큼, Jev와 비교할 때 볼 것은 JSON 생성 여부보다 같은 작업의 속도와 오류율, 비용입니다.

2. 빠른 이유는 문장 생성보다 병렬 판단에 집중하기 때문이다

TypeSafe의 설명에 따르면 Jev는 토큰을 하나씩 생성하는 대신 여러 판단의 확률을 병렬로 출력합니다. 같은 자료에 관한 질문들을 함께 처리하고, 답변 문장을 길게 생성하는 과정을 줄이는 설계입니다. 회사는 RLCD라는 학습 방법으로 모델이 아는 것과 불확실한 것을 확률에 반영하도록 훈련한다고도 설명합니다. 실제 업무에서 그 확률이 얼마나 정확한지는 별도로 검증할 문제입니다. System One 공식 설명 · 공식 출시 글

공개된 설명만으로 내부 신경망까지 알 수는 없습니다. Archer Hume은 API를 실험한 뒤, 공통 상태를 처리하고 질문별 계산을 분리하는 구조라면 관측 결과를 설명할 수 있다고 분석했습니다. 상태의 KV 캐시를 공유한다는 설명도 이 추정에 속합니다. 정확한 어텐션 구조나 기반 모델, MoE 사용 여부는 공개 자료로 확인되지 않았습니다. 구조를 추적한 원문 실험

병렬 처리에도 순서가 필요한 일은 남습니다. 한 문의의 담당 부서와 긴급성은 각각 판단할 수 있습니다. 하지만 부서를 먼저 고른 뒤 그 부서의 규칙을 적용하려면 앞선 답을 기다려야 합니다. 이런 작업은 애플리케이션에서 요청을 단계별로 나눠 처리합니다.

3. 성능 수치에서 비교 조건을 빼면 안 된다

TypeSafe가 내세우는 수치는 193.6배 빠르고 444.6배 저렴하다는 것입니다. 특정 System One 워크플로에서 얻은 배율이지, 모든 분류 작업에 통하는 수치는 아닙니다. 비교 모델이 설명이나 추론 토큰을 얼마나 생성했는지도 결과에 영향을 줍니다. 공개 평가는 보안 사고, 에이전트 실행 기록 검토, 송장 처리, 고객지원 네 업무를 대상으로 했습니다. 이 벤더 평가의 기준 라벨은 GPT-6 Astra와 Claude Fable 5.1이 높은 추론 설정에서 낸 답을 평균해 만들었습니다. 벤더 평가 방법 TypeSafe의 성능 주장과 평가 링크

외부 평가에서는 강점과 약점이 함께 드러났습니다. 검색 서비스 Parallel의 9월 18일 평가에서 Jev는 검색 결과 재정렬 지표인 NDCG@10 약 0.7을 기록했습니다. 내부 모델 중 하나와 비슷한 수준입니다. 이 지표는 상위 결과의 순위 품질을 나타내므로 정답률 70%로 읽으면 안 됩니다. 라벨이 많은 주제 분류와 검색어의 최신성 판단은 내부 전문 모델이 더 잘했습니다. 자체 추론 인프라를 갖춘 Parallel에는 문서당 비용도 자사 모델 쪽이 낮았습니다. Parallel의 직접 평가

Aman Kumar는 공개 데이터셋마다 300개 항목을 뽑아 비교했습니다. Jev의 정확도는 SST-2 감성 분류에서 95.7%, 선택지가 77개인 Banking77에서 76.0%였습니다. Banking77에서는 비교 대상 두 모델보다 낮았습니다. 20개를 동시 호출했을 때 지연 중앙값은 0.8~0.9초였습니다. 클라이언트에서 측정한 이 시간은 서버 내부 처리 시간과 구분해야 합니다. 공개 데이터와 실제 업무를 사용한 평가

Aman Kumar의 실험에는 비용을 읽을 때 유의할 조건도 있습니다. 비교 LLM에 답 하나가 아니라 선택지별 확률까지 출력하도록 요청했습니다. 실제 서비스에서 라벨 하나만 받는다면 비용 차이가 달라질 수 있습니다. Jev의 도입 여부를 감성 분류 성적이나 홍보 배율 하나로 결정하기 어려운 이유입니다.

4. 낮은 토큰 가격과 낮은 업무 비용은 같은 말이 아니다

2026년 9월 22일 확인한 입력 가격은 100만 토큰당 0.042달러이고 출력은 무료입니다. 홈페이지의 ‘10억 입력 토큰당 42달러’와 같은 단가입니다. 가격은 바뀔 수 있습니다. TypeSafe 모델·가격 안내

질문과 선택지까지 합친 총 과금 입력이 요청당 정확히 1,000토큰이라고 가정해 보겠습니다. 100만 번 호출하면 10억 토큰이므로 입력 비용은 42달러입니다. 단가를 풀어 쓴 계산일 뿐 실제 청구액을 예상한 것은 아닙니다. 요청 크기와 재시도에 따라 과금량이 달라지고, 서버 운영비도 따로 듭니다.

애매한 요청을 더 큰 모델로 넘긴다면 두 모델의 호출비를 함께 내게 됩니다. 잘못 분류한 문의를 사람이 다시 처리하는 비용도 있습니다. 싼 호출이 곧 싼 업무 처리를 뜻하지는 않습니다. 비교할 비용은 API 단가에서 끝나는 것이 아니라 재검토를 거쳐 쓸 수 있는 결과를 얻기까지의 총액입니다.

5. 확률은 자동 실행 허가증이 아니다

모델이 내놓은 확률을 믿을 수 있는지는 여러 사례를 모아 실제 정답 비율과 대조해 봐야 알 수 있습니다. 이것이 확률 보정의 문제입니다. 개별 답의 숫자가 높다는 것만으로 정답을 보장하지는 않습니다. Archer Hume의 실험에서는 선택지 순서나 구성을 바꾸자 확률도 달라졌습니다. 같은 질문의 후보 순서를 바꾸거나 비슷한 후보를 추가하는 테스트가 필요한 이유입니다. 확률과 선택지 변화에 관한 실험

응답 필드의 의미도 서로 다릅니다. Choice의 confidence는 선택된 답의 확률 자체가 아니라 확률분포에서 계산한 지표입니다. Noul은 ‘예’의 확률을 반환하므로 값이 낮으면 오히려 ‘아니요’에 대한 확신이 높을 수 있습니다. 확신도 공식 문서

자동 처리 기준은 오류의 피해에 맞춰 정합니다. 중요한 문서를 걸러내는 검색 필터라면 호출비를 조금 아끼는 것보다 누락을 줄이는 일이 우선일 수 있습니다. 시험 자료로 임곗값을 정한 뒤, 그 과정에 쓰지 않은 자료로 오탐과 누락을 다시 측정하는 방식입니다.

실행 권한은 판단값과 분리해 두는 것이 안전합니다. 외부 이메일이나 문서에 모델의 판단을 바꾸려는 지시가 섞여 있을 수 있기 때문입니다. 파일 삭제나 송금을 높은 점수 하나에 맡기는 설계는 피해야 합니다. 이는 Jev에서 새로 발견된 결함이 아니라, 외부 데이터를 읽는 자동화 시스템 전반에 적용할 원칙입니다.

6. 어디에 넣으면 쓸모가 있을까

인터페이스와 공개 평가를 보면 다음 작업에서 시험해 볼 만합니다. 검증된 운영 성과를 나열한 것은 아닙니다.

• 고객지원: 문의의 주제와 긴급성을 분류해 담당 부서 후보를 제안합니다. 애매한 문의는 사람이 확인하고, 답장 전송 권한은 별도로 둡니다.
• 검색·RAG: 검색기가 찾은 문서를 재정렬합니다. 후보를 아예 버리는 필터로 쓴다면 중요한 문서의 누락률도 측정합니다.
• LLM 라우팅: 요청 종류와 난이도를 모델 선택에 활용합니다. 어떤 모델이 해당 업무를 잘하는지 평가한 자료가 먼저 있어야 합니다.
• 콘텐츠 검토: 출처와 맞지 않거나 과장·반복이 의심되는 문단을 편집자에게 보냅니다. Jev의 판정이 사실 확인이나 발행 승인을 대신하지는 않습니다.

블로그라면 마지막 용도부터 작게 시험할 수 있습니다. 초안 문단과 근거 자료를 함께 주고 재검토할 부분을 고르게 합니다. 편집자는 지적이 맞았는지, 놓친 문제는 없었는지 기록합니다. 처음부터 발행을 자동화하기보다 어떤 오류를 찾는 데 도움이 되는지 확인하는 단계입니다.

7. 도입 전에 작게 비교할 항목

확인 시점의 공식 모델은 jev-1.13.0입니다. jev-latest는 가리키는 버전이 바뀔 수 있는 별칭이므로 실험 기록에는 실제 버전을 남기는 것이 좋습니다. 입력 한도도 두 가지입니다. 요청 전체는 64k토큰, state와 가장 긴 질문을 합친 길이는 32k토큰 이내여야 합니다. 현재 모델과 입력 한도

현재 쓰는 방식과 Jev에 같은 입력을 주고 같은 기준으로 채점하면 비교를 시작할 수 있습니다. 한국어 서비스를 만들면서 영문 벤치마크만 볼 수는 없습니다. 실제 한국어 문의와 문서를 넣고, 애매한 문장이나 긴 입력, 비슷한 선택지, 근거가 부족한 사례도 함께 시험합니다. 계산·카운팅·날짜 산술과 복잡한 추론은 공식 문서에서도 약점으로 꼽습니다. 정확한 계산이나 날짜 비교는 코드에 맡길 일입니다. Jev 1.13의 알려진 한계

정확도와 함께 기록할 것은 중요한 사례의 누락률, 사람의 재검토 비율, 전체 처리 지연, 재시도와 후속 모델 호출을 포함한 비용입니다. 질문 문구와 선택지 구성도 남겨야 나중에 모델 버전을 바꿨을 때 같은 조건으로 비교할 수 있습니다.

Jev를 써 볼 자리는 긴 글을 쓰는 단계보다 반복해서 선택하고 점수를 매기는 단계에 가깝습니다. 설명 작성과 복잡한 추론은 기존 모델에 남겨 두고, 작은 판단 업무 하나를 떼어 비교하는 출발점입니다. 그 업무의 오류와 총비용이 실제로 줄어드는지가 도입의 근거가 됩니다.

숫자 카드 네 개, 매끈한 그래프, 둥근 모서리, 보라색 강조색. AI에게 대시보드를 만들어 달라고 했더니 필요한 부품은 다 나왔습니다. 그런데 정작 어떤 정보부터 봐야 할지는 잘 보이지 않습니다. 코드도 실행되고 버튼도 눌리지만, 완성된 제품보다 샘플 화면처럼 느껴지는 이유입니다.

바이브 코딩 대시보드가 어설퍼 보이는 이유는 장식이 부족해서가 아니라 판단 기준이 없기 때문입니다. 여기서 바이브 코딩은 자연어로 요구하고, AI가 만든 화면을 보며 반복해 고치는 작업 방식을 뜻합니다. AI로 만든 모든 화면이 나쁘다는 뜻은 아닙니다. 이 글은 특정 모델의 우열을 가리는 실험이 아니라, 공식 디자인 지침에 비추어 실무에서 놓치기 쉬운 지점을 짚어봅니다.

1. 예쁜 부품은 있지만 읽는 순서가 없다

매출, 방문자, 오류율, 가입자 수를 같은 크기의 카드에 넣으면 화면은 균형 잡혀 보입니다. 하지만 운영 담당자가 서비스 장애를 살펴보는 화면이라면 오류율과 미처리 경고가 먼저 눈에 들어와야 합니다. 같은 정보라도 경영 보고용인지, 장애 대응용인지에 따라 자리가 달라져야 합니다.

Carbon의 프레젠테이션 대시보드 지침은 중요한 정보를 앞세우고, 불필요한 지표를 줄이며, 시각적 위계를 분명히 하라고 안내합니다. 이 지침을 실제 작업에 적용하려면 컴포넌트를 고르기 전에 사용자가 내려야 할 결정부터 적어야 합니다. 카드를 반드시 네 개 놓아야 할 이유는 없습니다. Carbon의 대시보드 지침

고객지원 팀장이 “어느 문의부터 처리해야 하나?”를 판단해야 한다면, 미처리 건수만 크게 띄워서는 부족합니다. 약속한 응답 시간을 넘긴 문의와 담당자가 없는 문의를 먼저 보여주고, 목록을 눌러 바로 배정할 수 있어야 합니다. 예쁜 요약 카드보다 첫 화면에서 다음 행동으로 이어지는 구성이 중요합니다.

2. 숫자는 큰데 단위와 비교 기준이 없다

“응답 시간 4.2”만 적힌 카드는 제대로 읽기 어렵습니다. 4.2가 초인지 시간인지, 평균인지 중앙값인지, 어느 기간에 접수된 문의를 모은 것인지 알 수 없기 때문입니다. 초록색 상승 화살표가 붙어 있어도 응답 시간이 늘어난 것을 좋은 변화로 보는지부터 헷갈립니다. 지표의 뜻은 빼고 색으로 평가를 대신한 셈입니다.

아래 숫자는 설명을 위해 만든 가상 고객지원 데이터입니다. 실제 서비스의 운영 수치나 개선 효과를 나타내지 않습니다. 숫자는 그대로 두고 설명과 배치만 바꾸는 예시입니다.

첫 응답 시간은 “4.2” 옆에 초록색 상승 화살표만 두지 말고, “중앙값 4.2시간 · 선택한 7일 · 직전 7일 3.0시간”으로 써야 단위와 기간이 보입니다.

변화량도 “+40%”만 강조하기보다 “1.2시간 증가 · 응답 속도 악화”라고 표시하면 변화의 의미까지 알 수 있습니다.

미처리 문의는 “128”만 보여주지 말고, “미처리 128건 · 그중 응답 목표 초과 23건”으로 적어 먼저 확인할 대상을 나눠야 합니다.

다음 행동으로 이어지는 버튼이라면 “상세 보기”보다 “목표 초과 문의 23건 확인”이 누르면 어디로 가는지 분명합니다.

계산은 따로 떼어 확인해야 합니다. 4.2시간에서 3.0시간을 빼면 1.2시간이고, 이를 기준값 3.0시간으로 나누면 40% 증가입니다. 다만 기준값이 0이면 같은 방식으로 증가율을 계산할 수 없습니다. 이때는 무한대나 임의의 퍼센트 대신 “비교 불가”와 절대 변화량을 표시하는 편이 정직합니다.

NN/g는 숫자를 해석하려면 비교할 맥락이 필요하고, 차트를 만들기 전에 전달할 목표부터 정해야 한다고 설명합니다. 대시보드에서는 각 지표 옆에 정의, 단위, 기간, 비교 기준을 함께 적는 방법으로 적용할 수 있습니다. NN/g의 차트 맥락과 선택 기준

3. 차트를 질문이 아니라 빈자리에 맞춰 고른다

빈칸이 정사각형이라고 도넛 차트를 넣고, 넓은 칸이 남았다고 꺾은선을 넣으면 화면은 채워집니다. 그러나 고객지원 유형별 건수를 비교하는 일과 시간에 따른 문의량을 보는 일은 서로 다른 질문입니다. 같은 데이터를 담을 수 있다고 해서 같은 차트가 어울리는 것은 아닙니다.

유형별 크기 차이를 보려면 막대그래프를, 날짜 순서에 따른 변화를 보려면 꺾은선그래프를 먼저 검토할 수 있습니다. 한국어 항목 이름이 길다면 가로 막대를 써서 라벨을 비스듬히 돌리지 않고도 표시할 수 있습니다. 반면 담당자별 정확한 건수를 확인하고 정렬해야 한다면 표가 더 직접적입니다. 앞서 인용한 NN/g 자료도 전달 목적에 맞는 기본 차트를 고르라고 강조합니다.

점검할 때는 이 질문으로 시작해 보세요. “이 그래프를 지우고 숫자 표로 바꾸면 무엇을 잃는가?” 패턴이나 비교 결과를 더 빨리 읽을 수 있는 것도 아니라면, 그래프가 장식으로만 쓰이고 있지 않은지 살펴봐야 합니다. 축의 범위, 빠진 날짜, 필터가 적용되는 범위도 함께 확인하세요. 차트가 화면에 그려졌다는 사실만으로 데이터 표현이 맞다고 판단해서는 안 됩니다.

4. 디자인 규칙 대신 유행하는 스타일만 붙인다

Anthropic이 2025년에 공개한 블로그 글은 별도의 안내 없이 LLM에게 랜딩 페이지를 만들게 하면 익숙한 디자인 패턴으로 수렴할 수 있다고 설명합니다. 그러면서 타이포그래피와 테마처럼 구체적인 지침을 주는 예시를 제시합니다. 다만 이는 자사 도구의 프롬프팅 방법을 설명한 자료입니다. 다른 모델이나 업무용 대시보드에서도 같은 결과가 난다고 일반화할 수는 없습니다. Anthropic의 프런트엔드 디자인 가이드

여기서 “보라색을 금지하면 된다”고 결론 내리면 다른 템플릿을 반복하기 쉽습니다. 업무용 화면에서는 개성 있는 폰트보다 긴 한국어 라벨의 줄바꿈, 숫자 정렬, 읽기 편한 본문이 더 급할 수 있습니다. Inter나 시스템 폰트 자체가 문제인 것도 아닙니다. 폰트 이름보다 어디에 쓰는지를 먼저 보세요.

먼저 제목, 본문, 보조 설명, 지표 숫자의 역할을 나누고 간격과 색에 이름을 붙이세요. 예를 들어 기본 글자색, 보조 글자색, 경고색을 구분하고 같은 의미에는 같은 값을 쓰도록 정합니다. 수정할 때도 카드를 하나씩 고치기보다 공통 규칙을 바꾸면 요소마다 들쭉날쭉한 화면을 줄일 수 있습니다.

흐린 회색 글자는 세련돼 보여도 읽기 어려울 수 있습니다. WCAG 2.2의 텍스트 대비 기준은 일반 텍스트에 최소 4.5:1, 큰 텍스트에 최소 3:1을 요구합니다. 여기서 큰 텍스트는 대체로 18pt 이상 또는 굵은 14pt 이상을 뜻하며, 18px과 같은 뜻이 아닙니다. 예외 조항이 있고, 이 기준을 통과했다고 접근성 요건을 모두 충족하는 것도 아닙니다. W3C의 최소 대비 해설

5. 정상 데이터가 있을 때의 한 장만 완성한다

문의가 적당히 들어 있고 이름도 짧은 목업에서는 화면이 멀쩡해 보입니다. 그러나 데이터가 하나도 없거나 요청이 실패하면 어떨까요? 아무 설명 없이 그래프만 사라지면 이용자는 결과가 0건인지, 데이터를 불러오지 못한 것인지 구분할 수 없습니다. 표의 빈 셀을 0으로 채우면 실제 측정값이 0이라고 오해할 수 있습니다.

Carbon의 빈 상태 지침은 왜 비어 있는지와 사용자가 다음에 할 일을 안내하라고 설명합니다. 이 원칙에 따라 첫 사용, 필터 결과 없음, 권한 부족, 요청 실패를 서로 다른 문구와 행동으로 설계할 수 있습니다. Carbon의 빈 상태 지침

테스트 데이터에도 다루기 까다로운 사례를 넣어 보세요. 긴 한국어 제목, 매우 큰 숫자, 값이 없는 항목, 기준값이 0인 비교, 행이 많은 표가 그 예입니다. 좁은 화면에서는 핵심 카드의 순서를 다시 정하고, 표를 가로로 스크롤할 수 있다는 점을 분명히 알려야 합니다. 이 사례들은 특정 제품에서 실제로 측정한 장애가 아니라, 초안 단계에서 활용할 수 있는 검증 시나리오입니다.

6. “더 예쁘게” 대신 입력과 합격 조건을 준다

바이브 코딩 대시보드를 고치려면 AI에게 분위기만 요구하지 말고 판단에 필요한 재료를 줘야 합니다. 아래 프롬프트는 고객지원 사례에 맞춰 쓴 작업 지시입니다. 특정 도구의 공식 명령어가 아니고, 일정한 결과를 보장하는 만능 프롬프트도 아닙니다. 실제 프로젝트의 데이터와 사용자 역할에 맞게 바꾸어야 합니다.

먼저 목적과 데이터를 이렇게 적습니다.

고객지원 팀장이 처리 순서를 결정하는 대시보드를 설계해줘. 첫 화면의 최우선 항목은 응답 목표를 넘긴 문의이고, 해당 목록에서 담당자 배정으로 이어져야 해. 첫 응답 시간은 선택 기간의 중앙값이며 단위는 시간, 비교 대상은 같은 길이의 직전 기간이야. 증가하면 악화로 표시해. 실제 연결 전의 예시 데이터에는 가상 데이터라고 표시해.

설계 방법과 검증 조건도 구체적으로 붙입니다.

코드를 작성하기 전에 정보 우선순위, 지표 정의, 차트 선택 이유, 글자와 간격 규칙을 먼저 제안해줘. 로딩·빈 결과·권한 부족·요청 실패 화면도 포함해. 390px와 1440px 너비에서 긴 한국어 라벨과 표가 어떻게 표시되는지 점검하고, 실행해 확인한 항목과 아직 확인하지 못한 항목을 나눠 보고해줘.

390px와 1440px는 이 예시에서 선택한 점검 너비일 뿐, 모든 화면을 대표하는 표준도 충분조건도 아닙니다. 대상 기기에서 추가로 확인해야 합니다. 완성된 화면에서 실제 사용자가 목표 초과 문의를 찾고 담당자를 배정할 수 있는지 살펴보세요. 걸리는 시간과 실수는 직접 관찰해 기록해야 하며, AI가 그럴듯한 개선율을 대신 만들어서는 안 됩니다.

고칠 순서는 색상이 아니라 질문에서 시작합니다. 사용자의 결정 → 지표의 정의 → 정보의 우선순위 → 시각 규칙 → 예외 상태 → 실제 사용 검증 순으로 확인하세요. 그림자를 더 넣기 전에, 실제 사용자가 첫 화면에서 무엇을 판단하고 어디를 눌러야 하는지 말할 수 있는 대시보드인지부터 확인하는 편이 낫습니다.