Jev로 이해하는 AI 에이전트의 빠른 분류와 판단

출처: https://www.youtube.com/watch?v=-fotMlYGMOc · 코딩애플 · 6:18 · 2026-10-07

요지

영상은 Jev를 긴 글을 생성하는 LLM 대신, 주어진 상태를 읽고 정해진 형식으로 분류·선택·평가하는 모델로 소개한다.
에이전트가 검색할지, 로컬 파일을 읽을지처럼 반복해서 내려야 하는 판단을 별도 모델에 맡기면 전체 실행 시간과 비용을 줄일 여지가 있다.
핵심 입력은 현재 상황과 판단 근거를 담은 state, 질문과 응답 형식을 지정하는 questions다.
영상이 강조하는 차별점은 분류 기능 자체보다, 작업마다 전용 모델을 학습하지 않고 자연어로 다양한 분류 문제를 제시할 수 있다는 점이다.
정해진 타입으로 답한다는 사실이 판단의 정확성을 보장하지는 않으며, 배경 지식과 한국어 이해의 한계를 고려해 문맥 제공과 검증이 필요하다.

개요

AI 에이전트는 사용자 요청을 받자마자 결과물을 만들기만 하는 프로그램이 아니다. 필요한 정보가 있는지 확인하고, 어떤 도구를 호출할지 고르고, 실행 결과를 보고 다음 행동을 결정한다. 이때 모든 결정을 큰 언어 모델에 맡기면 짧은 판단에도 모델 호출 시간과 토큰 비용이 반복해서 발생한다.

영상은 이 판단 부분을 담당하는 모델로 Jev를 소개한다. 글쓰기·복잡한 추론을 담당하는 LLM과, 제한된 선택지에서 빠르게 답하는 모델을 함께 사용하는 구상이다. 아래 설명은 제공된 자막을 바탕으로 구성했으며, 영상에 등장하는 성능 수치와 제품 특성은 발표자의 주장으로 구분한다. 코드 예시는 실제 Jev API 명세를 재현한 것이 아니라 구조를 학습하기 위한 실행 가능한 보충 예제다.

배경 / 사전 지식

생성 모델과 분류 모델은 출력의 목적이 다르다. 생성 모델은 설명문이나 코드처럼 길이와 내용이 열린 결과를 만든다. 분류 모델은 입력을 읽고 미리 정한 범주 중 하나를 선택한다. 손글씨 이미지를 보고 0부터 9 중 하나를 고르는 숫자 인식이 대표적인 분류 문제다.

분류는 오래전부터 사용되었다. 영상도 Jev의 새로움을 분류라는 기능의 발명에서 찾지 않는다. 대신 자연어로 상태와 질문을 주면 여러 작업에 적용할 수 있는 범용성과, 에이전트의 반복 판단에 적합한 속도·비용을 강조한다. 다만 이를 사용한다고 작업별 평가 데이터나 입력 정리까지 불필요해지는 것은 아니다.

에이전트의 도구 선택 역시 분류 문제로 표현할 수 있다. 예를 들어 가능한 행동을 search_web, read_local, ask_user로 정하면, 다음 행동 결정은 이 셋 중 하나를 고르는 문제가 된다. 선택 결과를 받은 실행기가 실제 도구를 호출하고, LLM은 그 결과를 바탕으로 답변을 작성할 수 있다.

RAG는 판단에 필요한 근거를 찾아 입력에 넣는 방법이다. 모델이 업무 규칙이나 내부 문서를 모를 때 관련 자료를 검색해 제공한다. 여기서 중요한 것은 자료를 많이 넣는 것이 아니라, 이번 선택을 바꿀 만한 근거를 넣는 것이다.

핵심 개념

제한된 형식의 판단 출력

영상에서 Jev는 자유로운 문장 생성보다 정형화된 응답을 만드는 모델로 소개된다. 대표적인 출력은 선택지 중 하나, 일정 범위의 수치, 기준에 따른 등급이다. 프로그램은 이런 결과를 조건 분기나 작업 배정에 바로 활용할 수 있다.

그러나 출력 형식의 유효성과 내용의 정확성은 다르다. 항상 허용된 선택지를 반환해도 잘못된 도구를 고를 수 있다. 따라서 영상 도입부의 ‘할루시네이션 0%’라는 표현을 모든 판단이 정확하다는 보장으로 해석해서는 안 된다.

`state`: 현재 상태와 판단 근거

state는 모델이 판단할 상황을 설명하는 입력이다. 사용자 요청뿐 아니라 사용 가능한 자료, 업무 규칙, 이미 수행한 행동, 부족한 정보 등을 포함할 수 있다.

예를 들어 ‘이 요청을 어디로 보낼까?’만 전달하는 것보다 ‘사용자가 내부 운영 절차를 물었고, 로컬에 최신 운영 문서가 있으며, 외부 검색으로는 내부 문서를 찾을 수 없다’고 전달해야 적절한 선택을 기대할 수 있다.

`questions`: 질문과 응답 계약

questions에는 무엇을 판단할지와 어떤 형태로 답할지를 지정한다. 영상은 다음과 같은 유형을 시연한다.

출력 유형	의미	활용 예시
0~1 수치	특정 속성에 대한 정도나 가능성 표현	추가 정보가 필요할 가능성 평가
선택형	제공된 후보 중 하나 선택	다음에 실행할 도구 선택
단계 평가형	주어진 평가 기준에 따라 등급 선택	요청의 우선순위를 1~5로 평가

자막에는 0~~1 수치 유형의 이름이 Noul로 기록되어 있으나 정확한 API 식별자는 확인할 수 없다. 실제 구현에서는 공식 명세를 확인해야 한다. 또한 0~~1 출력이 실제 사건의 확률과 잘 일치하는지는 별도로 평가해야 한다.

System One 모델과 역할 분담

영상은 빠른 판단을 담당하는 모델을 ‘System One 모델’이라고 부른다. 이 교안에서는 이를 제한된 판단을 빠르게 수행하는 역할을 가리키는 표현으로 사용한다.

역할 분담의 예는 다음과 같다. 작은 판단 모델이 필요한 도구를 선택하고, 실행기가 도구를 호출하며, LLM이 수집된 근거를 종합해 설명을 작성한다. 모든 문제를 판단 모델에 넣기보다는 결과를 명확한 선택지나 평가 기준으로 표현할 수 있는 지점부터 적용하는 것이 이해하기 쉽다.

작동 원리

판단 지점을 분리한다. 전체 작업 중 ‘다음에 무엇을 할 것인가’처럼 반복되는 결정을 찾는다. 설명문 작성과 도구 선택을 하나의 요청에 섞지 않는다.
가능한 답을 정의한다. 검색, 로컬 문서 읽기, 사용자에게 추가 질문하기처럼 실행기가 처리할 수 있는 선택지를 정한다. 판단 불가 상황도 표현할 수 있게 한다.
현재 상태를 구성한다. 사용자 요청, 자료의 존재 여부, 최신성 요구, 관련 규칙을 state에 넣는다. 필요한 내부 지식은 검색으로 확보해 보충한다.
질문과 응답 형식을 지정한다. 어떤 기준으로 선택해야 하는지 설명하고, 응답이 선택형인지 수치형인지 정한다. 단계 평가에는 각 점수의 의미를 제공한다.
판단 결과를 검증한다. 응답이 허용된 값인지 확인한다. 선택한 도구의 실행 조건과 권한도 별도로 검사한다.
실행하고 상태를 갱신한다. 도구 결과를 다음 판단의 입력에 반영한다. 문장 생성이나 복잡한 해석이 필요하면 LLM으로 넘긴다.
전체 흐름을 측정한다. 판단 호출 하나의 속도뿐 아니라 도구 실행, 재시도, 최종 결과의 품질까지 포함해 기존 방식과 비교한다.

영상은 게임 플레이, 게시물 필터링, 트레이딩 봇, 브라우저 자동 탐색을 활용 사례로 든다. 이들은 짧은 판단이 반복되는 작업이라는 공통점이 있다. 트레이딩 봇 사례에서 손실이 발생했다는 언급은 빠른 판단과 좋은 판단이 별개라는 점도 보여준다.

코드 예시

다음 코드는 Python 3 표준 라이브러리만 사용하는 도구 선택 예제다. state와 questions를 만들고, 선택 결과를 검증한 뒤 정해진 처리기로 보내는 구조를 보여준다. mock_decide는 규칙 기반 대역이며 Jev를 호출하거나 모델 성능을 재현하지 않는다.

import json


def mock_decide(state, questions):
    context = json.loads(state)

    if context["missing_required_info"]:
        action = "ask_user"
    elif context["needs_current_public_info"]:
        action = "search_web"
    elif context["has_relevant_local_doc"]:
        action = "read_local"
    else:
        action = "ask_user"

    question = questions["next_action"]
    if question["type"] != "choice":
        raise ValueError("Unsupported question type")
    if action not in question["choices"]:
        raise ValueError("Action is outside the allowed choices")
    return {"next_action": action}


def run():
    state = json.dumps(
        {
            "request": "내부 운영 문서의 배포 절차를 요약해 줘",
            "missing_required_info": False,
            "needs_current_public_info": False,
            "has_relevant_local_doc": True,
        },
        ensure_ascii=False,
    )
    questions = {
        "next_action": {
            "question": "요청을 처리하기 위해 먼저 할 행동은?",
            "type": "choice",
            "choices": ["search_web", "read_local", "ask_user"],
        }
    }

    result = mock_decide(state, questions)
    action = result.get("next_action")
    allowed = questions["next_action"]["choices"]
    if action not in allowed:
        action = "ask_user"

    handlers = {
        "search_web": lambda: "외부 검색 단계로 전달",
        "read_local": lambda: "로컬 운영 문서 읽기 단계로 전달",
        "ask_user": lambda: "사용자에게 필요한 정보를 질문",
    }
    print(json.dumps(result, ensure_ascii=False))
    print(handlers[action]())


if __name__ == "__main__":
    run()

실행하면 next_action은 read_local이 되고, 로컬 운영 문서를 읽는 단계로 전달한다는 메시지가 출력된다. 처리기는 실제 검색이나 파일 읽기 대신 메시지만 반환하므로 외부 서비스나 API 키 없이 실행할 수 있다.

실제 연동에서는 mock_decide를 공식 SDK나 HTTP 호출로 교체한다. 이 예제의 필드 구조를 실제 Jev 요청 명세로 간주해서는 안 된다. 반면 허용된 결과만 처리하는 검증과 실행기 분리는 실제 모델을 연결한 뒤에도 유지할 수 있다.

함정·실수

정형 출력이면 오답이 없다고 생각한다. 타입이 맞아도 의미가 틀릴 수 있다. 형식 검사와 별개로, 정답이 있는 사례를 모아 판단 정확도를 평가한다.
속도·가격 배수를 그대로 일반화한다. 영상은 수백 배 빠른 속도와 1,000배 저렴한 가격을 언급하지만 자막에는 비교 조건이 충분히 제시되지 않는다. 자신의 입력 길이, 호출량, 재시도율로 확인한다.
배경 지식을 생략한다. 영상은 모델의 배경 지식이 부족하다고 지적한다. 내부 용어, 업무 기준, 예외 규칙을 state에 제공한다.
한국어 고유명사를 설명 없이 전달한다. 영상은 한국어 이해의 한계를 언급한다. 실제 한국어 요청으로 평가하고, 필요한 용어 정의와 문맥을 보충한다.
수치 출력을 검증된 확률로 받아들인다. 0.89라는 값만으로 실제 정답 가능성이 89%라고 단정할 수 없다. 임계값을 정하려면 실제 결과와 비교한 검증이 필요하다.
판단 결과를 무제한 실행 권한으로 연결한다. 모델이 고른 행동과 실행 가능한 행동은 별도로 관리한다. 허용 목록과 실행 조건을 검사하고, 실패 시 추가 질문이나 다른 모델로 넘긴다.

베스트 프랙티스

빈도가 높고 답의 범위가 좁은 판단부터 적용한다. 도구 라우팅, 문의 분류, 문서의 관련성 평가처럼 성공 여부를 비교하기 쉬운 작업이 출발점이다. 복잡한 설명이나 다단계 추론은 별도 LLM에 맡기는 구성을 검토한다.

입력 문맥과 평가 기준을 함께 설계한다. 상태에는 필요한 근거를 제공하고, 질문에는 선택 기준을 적는다. 1~5점 평가라면 각 단계의 의미를 정의한다. 선택지에는 정보 부족이나 판단 불가를 처리할 경로를 마련한다.

추가 모델 호출의 이익을 전체 작업 기준으로 확인한다. 판단을 분리하면 호출 횟수와 네트워크 왕복이 늘 수도 있다. 총 지연 시간, 총비용, 잘못된 도구 선택률, 재시도율, 최종 작업 성공률을 함께 비교한다.

기존 대안과 같은 평가셋으로 비교한다. 고정된 조건은 규칙 기반 코드로, 좁고 반복적인 분류는 전용 분류기로, 복잡한 문맥 해석은 LLM의 구조화 출력으로 처리할 수도 있다. 영상도 로컬 모델로 유사한 기능을 구현하는 사례를 언급한다. 기능을 흉내 낼 수 있다는 것과 같은 품질·속도를 낸다는 것은 따로 확인해야 한다.

실패 사례를 입력 개선으로 연결한다. 어떤 정보가 빠져 오판했는지 기록하고, 필요한 근거 검색과 상태 구성을 개선한다. 이는 영상이 강조한 배경 지식 부족을 실제 운영에서 다루는 방법이다.

참고

원본 영상: AI인데 글 생성을 못해서 난리난 Jev — 코딩애플.
영상에서 언급한 개발사와 모델: 타입세이프 AI, Jev. 표기는 제공된 자막을 따랐으며, 공식 사이트·API 문서 주소는 자막에 없다.
영상에서 언급한 관련 개념: System One 모델, 분류 모델, RAG, LLM을 이용한 분류, 로컬 모델 기반 대체 구현.
영상에서 언급한 사례: 포켓몬 레드 플레이, 실시간 게임, AI 생성 게시물 필터링, 트레이딩 봇, 브라우저 자동 탐색. 개별 프로젝트 링크와 재현 조건은 자막에 없다.
영상 중간의 OpenAI dots 소개는 스폰서 구간이다. 문자·전화 기반 작업 지시, 캘린더 연동, 뉴스 정리 사례를 다루며 Jev의 판단 모델 설명과는 별개의 내용이다.