AI가 답을 내놓는 방식이 달라지고 있습니다
Jev, 문장 대신 선택을 돌려주는 AI
TypeSafe AI가 9월 15일 Jev를 공개했습니다. 질문에 긴 문장으로 답하는 대신, 미리 정한 선택지나 점수와 확률을 돌려주는 모델입니다. 개발사가 ‘System One’이라고 부르는 이 접근은 문의 분류, 문서 선별처럼 소프트웨어가 다음 동작을 결정해야 하는 일에 초점을 맞춥니다.
비교해 볼 소식이 같은 주에 하나 더 있습니다. Z.ai는 GLM-5.3-FlashX를 공개하며 공식 문서에서 초당 200토큰으로 답을 내놓는다고 밝혔습니다. 새 모델을 만든 것이 아니라 같은 모델을 더 빠른 설정으로 서빙한 것입니다. 방법은 다르지만 두 소식은 같은 곳을 가리킵니다. 업무에 AI를 넣으려면 답이 빨라야 한다는 것이죠. 한쪽은 문장을 더 빨리 뽑아서, 다른 한쪽은 문장을 아예 만들지 않아서 그 문제를 풉니다.
모든 AI가 더 유창하게 말해야 하는 건 아니라는 점이 흥미롭습니다. 분류만 필요한 작업에서 글을 생성하는 과정을 덜어내겠다는 방향이죠. 현재 초기 접근 단계이며 입력은 텍스트 전용입니다. 한국어 품질은 따로 확인해야 합니다. 아래에서는 API 용어보다 실제 문의를 먼저 놓고, 어떤 일에 쓸 수 있을지 살펴보겠습니다.
Gemini Live, 대화하는 동안에도 일을 진행하다
Google이 발표한 Gemini 3.8 Live와 Live Extended Thinking은 작업을 진행하면서 대화를 이어갑니다. 공개 데모에서는 스케치를 보여주고 말로 수정 사항을 전달하며 웹 화면을 만듭니다. 요청을 보낸 뒤 결과가 나올 때까지 기다리는 대신, 만드는 도중에도 사람이 끼어들 수 있는 셈입니다.
음성 AI를 업무에 넣는다면 목소리뿐 아니라 ‘작업 중 요청을 바꿨을 때 어떻게 대응하는가’도 볼 만합니다. 예약을 처리하는 중 날짜를 바꾸는 상황처럼요. 이는 데모에서 읽은 활용 방향이며, 개발자용 API와 기업용 비공개 미리보기의 제공 범위는 구분해서 봐야 합니다. 이번 호의 질문으로 바꾸면, 사람과 주고받는 말에는 긴 답변이 필요하지만 “지금 무엇을 바꾸라는 요청인가”를 알아내는 일은 선택에 가깝습니다.
Qwen, 소리와 영상을 그대로 받는 모델
알리바바의 Qwen이 9월 18일 Qwen3.8-Omni-Flash를 공개했습니다. 글과 이미지뿐 아니라 소리와 영상을 한 번에 입력으로 받습니다. 발표에 따르면 29개 평가에서 이전 모델보다 평균 25% 이상 좋아졌고, 소리를 입력하는 가격은 시간당 98% 이상 내려갔습니다. 회사가 내세우는 방향은 “내용을 이해하는 모델”에서 “할 일을 계획하고 도구를 불러 끝내는 모델”입니다.
이번 호의 질문과 이어 보면 재미있습니다. 오늘 살펴볼 Jev는 글만 받습니다. 녹취나 영상으로 들어오는 업무라면 먼저 글로 바꿔야 하죠. 반대로 이 모델은 소리와 영상을 그대로 받아 다음 행동까지 잇겠다고 합니다. 우리 일에 들어오는 자료가 무엇인지부터 보면 어느 쪽이 필요한지 갈립니다. 다만 발표한 수치는 개발사가 잰 값이고, 한국어 음성과 우리 자료로는 따로 확인해야 합니다.
문의 세 개만 놓고 생각해보겠습니다
아래는 분류 기준을 설명하기 위한 가상의 문의입니다. Jev를 직접 실행한 결과는 아닙니다.
답장을 쓰기 전에, 어디로 보낼지부터
고객 문의가 들어오면 담당 팀을 정하고, 내용을 확인하고, 답장을 보냅니다. 이 세 단계에서 필요한 답은 서로 다릅니다. 첫 단계에 필요한 것은 담당 팀, 두 번째는 확인할 정보, 마지막은 고객이 이해할 설명입니다. 모두를 한 번에 ‘처리해줘’라고 묶지 않고, 우선 분류만 맡긴다고 생각해보죠.
선택지는 결제·기술·계정·기타로 정하되, 정보가 부족하거나 두 범주가 겹치면 ‘검토 필요’로 남기겠습니다. 이 기준으로 다음 문의를 읽어보세요.
“결제가 두 번 됐어요.”
담당 팀 추천은 ‘결제’로 할 수 있습니다. 하지만 중복 결제가 실제로 있었는지는 결제 기록을 확인해야 합니다. 문의를 분류하는 것과 문의 내용이 사실인지 확인하는 것은 다릅니다.
“결제하고 나서 로그인이 안 돼요.”
이 예시의 기준에서는 ‘검토 필요’입니다. ‘결제’라는 단어만 보고 결제팀으로 보내기보다, 로그인 오류와 이용권 활성화 문제 중 어느 쪽인지 추가로 확인합니다.
“지난번이랑 똑같아요. 빨리 처리해주세요.”
급해 보이지만 무엇이 문제인지 알 수 없습니다. 앞선 문의 기록을 가져오거나 증상을 다시 물어야 합니다. 빠진 정보를 추측해서 분류를 끝내지 않습니다.
Jev가 바꾸는 부분은 이 작은 판단입니다
‘어느 팀에 보낼까?’처럼 정해진 답 중 하나를 고르는 질문이 Jev의 Choice입니다. 선택 결과와 선택지별 확률이 돌아오므로, 뒤의 코드는 그 값을 보고 담당 팀을 추천하거나 검토함에 남길 수 있습니다. 고객에게 보낼 친절한 답장까지 만들 필요는 없습니다.
‘얼마나 급한가?’도 필요하다면 별도 질문으로 묻습니다. Jev는 같은 자료에 대한 여러 질문을 한 요청에서 독립적으로 평가합니다. 담당 팀과 긴급성을 나눠두면 ‘결제 문의는 결제팀에, 그중 급한 건 우선 검토’처럼 결과를 조합할 수 있습니다. 고객에게 답장을 쓰는 단계에는 다시 문장을 생성하는 모델을 쓰면 됩니다.
이번 주 플래드랩스 기술 블로그에서는 같은 “결제가 두 번 됐어요” 문의 하나에 담당 팀(Choice), 환불 요청 여부(Noul), 긴급도(Score)를 한 번에 묻는 코드 예시를 정리했습니다. 글의 결론은 한 문장입니다. “모델은 판단과 불확실성을 반환하고, 자동 처리할지 사람에게 넘길지는 코드가 결정합니다.”
‘선택지가 맞다’와 ‘선택을 잘했다’는 다릅니다
기존 LLM도 정해진 형식으로 답을 만들 수 있습니다. Jev의 특징은 그 기능의 유무가 아니라, 자유로운 글쓰기 대신 이런 판단에 집중했다는 점입니다. 주어진 선택지 안에서만 답하더라도 결제 문의를 기술 문의로 잘못 고를 수는 있습니다.
모델이 얼마나 확신했는지를 나타내는 값(confidence)도 정답 보증서는 아닙니다. 한 선택지에 확률이 얼마나 몰렸는지를 요약한 숫자일 뿐입니다. 0.9가 나왔다고 우리 업무에서 열 건 중 아홉 건을 맞힌다는 뜻은 아니죠. 한국어 표현과 팀의 분류 기준으로 맞는지 확인하고, 애매한 문의를 남겨둘 경로도 함께 설계해야 합니다.
그렇다면 확신도가 얼마일 때부터 자동으로 처리할까요? 블로그에서는 이 기준을 모델이 아니라 업무가 정한다고 봤습니다. 같은 확신도라도 문의를 담당 팀에 보내는 일과 결제를 취소하는 일에 같은 기준을 쓸 수는 없으니, 잘못 처리했을 때 드는 비용부터 따져야 합니다.
선택지에서 ‘기타’를 빼면 이런 일이 생깁니다
이건 설명이 아니라 실제로 확인한 결과입니다. Jev는 초기 접근 단계라 실행하지 못했지만, 선택지에 확률을 매기는 구조 자체는 일반 모델로도 흉내 낼 수 있습니다. 사내에 올린 자체 호스팅 모델에게 토큰을 하나만 만들게 하고 후보 글자의 확률을 읽어봤습니다. 범주 밖 문의로 “채용 공고 보고 연락드려요. 지원 절차가 어떻게 되나요?”를 넣었습니다.
기타 선택지가 있을 때는 기타를 0.99로 골랐습니다. 기타를 빼자 같은 문의를 버그·장애로 0.77에 보냈습니다. 없는 답을 고르라고 하면 모델은 있는 것 중에서 고릅니다. 차이는 숫자에서만 보였습니다. 기타가 있을 때는 한 곳에 확률이 몰렸지만, 기타를 빼자 두 선택지로 갈렸습니다. 고른 값만 저장했다면 이 문의는 그냥 버그·장애 문의가 됐을 겁니다. 선택지에 ‘기타’와 ‘검토 필요’를 두는 일이 질문 문장을 다듬는 것보다 결과를 크게 바꿉니다.
우리는 장애 분석 AI에 수정 권한을 주지 않았습니다
플래드랩스의 장애 분석 구축기에는 AI가 로그와 서버 상태를 읽고, 원인 후보와 근거를 Slack에 남기는 과정이 나옵니다. 진단 결과에는 사람이 확인할 명령도 들어갑니다. 하지만 진단기 자체는 서버를 재시작하거나 설정을 바꾸지 않습니다.
이 경우에는 ‘결제팀’ 같은 짧은 선택만으로 부족합니다. 운영자가 다음 조치를 정하려면 왜 장애로 판단했는지 읽을 수 있어야 하니까요. 반대로 문의를 어느 팀에 보낼지만 정하는 단계에서는 긴 설명이 없어도 됩니다. 같은 AI 업무라도 결과를 읽는 쪽이 사람인지, 값을 받아 분기하는 코드인지에 따라 필요한 답이 달라집니다.
Jev도 이 구분에서 보고 싶습니다. 모든 AI를 교체할 후보라기보다, 이미 있는 처리 과정에서 분류 한 단계를 맡길 후보입니다. 문의를 잘 나눈다는 이유만으로 환불 승인까지 붙이지 않고요. 모델을 고르기 전에 ‘이 결과로 다음에 무엇을 할 건가’를 정하면 맡길 범위도 작고 분명해집니다.
직접 돌려보며 하나 더 배웠습니다. 우리가 읽은 확률은 세 선택지만 따로 떼어 비율을 맞춘 값이었습니다. 그런데 어떤 문의에서는 모델이 애초에 셋 중 어느 것도 말하고 싶어 하지 않았습니다. 비율을 맞추는 순간 그 사실은 사라지고, 화면에는 그럴듯한 숫자만 남습니다. 숫자를 믿기 전에 그 숫자가 무엇을 감추고 있는지 봐야 한다는 걸 우리 손으로 확인했습니다.
모델을 켜기 전에, 선택지부터 맞춰보세요
지난주에 실제로 처리한 10건이면 됩니다. API 없이 동료 한 명과 30분이면 끝나는 확인입니다.
고객 문의가 아니어도 됩니다. 채용 서류를 1차로 나누는 일, 사내 요청을 담당 팀에 넘기는 일, 버그 리포트에 우선순위를 매기는 일처럼 매주 반복되고 결과에 따라 다음 행동이 정해지는 판단이면 충분합니다. 예시를 새로 만들지 말고 지난주에 실제로 처리한 10건을 그대로 가져오세요.
그다음 선택지를 적습니다. 이때 ‘기타’와 ‘검토 필요’를 반드시 넣으세요. 빠져나갈 자리가 없으면 애매한 건도 억지로 어딘가에 들어갑니다. 앞에서 본 것처럼 사람이 하든 모델이 하든 마찬가지입니다.
동료 한 명과 각자 10건을 분류한 뒤, 서로 다르게 고른 건만 펼쳐 봅니다. 누가 맞았는지 가리지 말고 판단에 필요한데 선택지 설명에서 빠져 있던 문장을 찾으세요. ‘결제 직후라도 로그인 증상이면 계정팀이 먼저 확인한다’ 같은 한 문장이면 됩니다.
두 사람이 같은 답을 낸 비율
10건 중 몇 건이 일치했는지 셉니다. 절반이 갈린다면 모델을 붙이기 전에 사람의 기준부터 정리해야 한다는 뜻입니다.
‘기타·검토 필요’로 간 비율
이 비율이 높으면 선택지가 업무를 덮지 못한 것입니다. 낮은데 애매한 건이 많았다면 빠져나갈 자리가 없어 억지로 분류된 것은 아닌지 봅니다.
빠져 있던 기준 한 문장
불일치한 건에서 찾은 문장을 선택지 설명에 적어 넣습니다. 여기까지 하면 이번 연습은 끝입니다.
여유가 있다면 모델에도 같은 선택지로
사람이 갈린 건에서 모델도 갈리는지만 봅니다. 맞힌 수보다 잘못 보낸 건과 보류한 건을 따로 세는 편이 쓸모 있습니다. 10건으로 배포를 결정하지는 않습니다.
판단을 코드에 연결하는 두 가지 방식
짧은 선택을 돌려주는 Jev와, 근거를 남기고 사람에게 조치를 맡긴 장애 분석 사례를 함께 봅니다.
Jev: 문장 대신 판단을 돌려주는 AI
같은 “결제가 두 번 됐어요” 문의로 Choice·Score·Noul 코드 예시를 짜고, 확신도를 자동 처리와 사람 검수로 나누는 기준을 정리했습니다. Jev가 브라우저를 조작하는 1배속 데모 영상도 볼 수 있습니다.
Jev 기술 글 읽기 →
장애 분석은 AI가, 조치는 사람이
장애 알림에서 관련 로그와 코드 문맥을 모으고, AI의 첫 진단을 기존 Slack 대화에 붙이기까지. 무엇을 자동화하고 무엇을 사람에게 남겼는지 구축 과정을 담았습니다.
구축 과정 읽기 →2026년 9월 19일 확인한 공식 발표와 문서를 바탕으로 작성했습니다.