Insights

AI의 판단, 어디까지 믿을 수 있을까? Jev 활용 사례와 기업 보안 통제

October 28, 2026

min Read

Jev는 주어진 정보를 바탕으로 분류·평가·선택을 수행하는 Decision Model입니다.

앞서 「Jev란? Decision Model의 등장과 달라지는 AI 보안에서 살펴본 것처럼, 판단 결과를 미리 정한 선택지나 점수, 확률로 반환하므로 소프트웨어가 요청을 분류하거나 다음 처리 경로를 정하는 데 활용할 수 있습니다. 기본 사용 방식은 판단할 자료와 질문, 평가 기준을 함께 전달하는 것입니다. 이를 통해 무엇을 평가하고 어떤 기준으로 판단할지 구체적으로 정합니다.

예를 들어 고객이 “교환이 아닌 반품을 하고 싶습니다.”라고 문의했다고 가정해 보겠습니다.

State: 판단할 자료인 고객 문의
Question: 고객이 원하는 처리가 무엇인지 묻는 질문
Criteria: 환불교환·기타와 같은 선택지와 각 항목의 기준

공식 문서는 원하는 결과에 따라 세 가지 질문 유형을 제공합니다.

질문 유형	반환하는 결과	활용 예시
Choice	미리 정한 선택지 중 하나와 선택지별 확률, confidence	문의가 환불·교환·기타 중 무엇에 해당하는지 분류
Score	정의한 평가 기준에 따른 점수와 확률 분포, confidence	문의의 긴급도를 정해진 단계로 평가
Noul	조건이 참일 확률을 0~1 값으로 반환	해당 문의에 사람의 검토가 필요한지 평가

질문은 하나의 의미 판단에 집중하도록 나누는 것이 좋습니다. “고객의 문제를 알아서 처리해 줘”라고 모든 일을 맡기는 대신, 문의 유형과 긴급도, 검토 필요성을 각각 평가하고 결과를 코드에서 조합하는 방식입니다. 좁고 명확한 질문을 나눈 뒤 코드로 결합하는 설계를 권장합니다.

이때 ‘반품을 요청한다’는 판단과 ‘실제로 환불해도 된다’는 조건 확인은 별개입니다. 모델은 문의의 의도를 평가하고, 업무 시스템은 주문 상태와 금액, 사용자 권한, 환불 규정을 확인합니다. 실제 처리를 허용하는 규칙은 애플리케이션에서 관리해야 합니다.

Jev와 생성형 LLM은 무엇이 다른가요?

ChatGPT나 Claude와 같은 생성형 LLM은 문서 작성, 요약, 분석, 코드 생성 등 다양한 작업에 활용되지만, Jev는 그 중에서도 가능한 결과의 범위가 정해진 판단에 집중합니다.

다만 생성형 LLM도 JSON Schema에 맞춘 Structured Outputs를 지원하며, 분류와 평가를 수행할 수 있습니다. 따라서 “LLM은 글만 쓰고 Jev만 판단한다”는 구분은 정확하지 않습니다. 비교할 지점은 같은 업무에서 어떤 결과가 필요하고, 어떤 방식이 적합한가입니다.

비교 항목	생성형 LLM	Jev
주요 활용	미리 정한 선택지 중 하나와 선택지별 확률, confidence	문의가 환불·교환·기타 중 무엇에 해당하는지 분류
출력 방식	정의한 평가 기준에 따른 점수와 확률 분포, confidence	문의의 긴급도를 정해진 단계로 평가
설명문 작성	조건이 참일 확률을 0~1 값으로 반환	해당 문의에 사람의 검토가 필요한지 평가
업무 연결	생성 결과나 도구 호출을 애플리케이션과 연동	판단 결과를 코드의 분기·정렬·라우팅에 활용

두 방식을 한 업무 과정에서 함께 사용할 수도 있습니다. 예를 들어 고객 문의를 분류하는 단계에는 판단 모델을, 고객에게 보낼 답장 초안을 작성하는 단계에는 생성형 LLM을 활용하는 구성입니다.

한국어 업무에 적용한다면 한국어 문의와 사내에서 사용하는 표현으로도 평가해야 합니다. 공식 문서는 Jev의 주요 학습 언어가 영어이며, 다른 언어의 성능이 동일하지 않다고 설명합니다.

Decision Model은 AI 업무에서 어디에 활용할 수 있는가?

공식 Spring AI 블로그는 Jev를 활용한 분류와 평가, 입력·출력 검사 등의 구현 사례를 소개합니다. 생성형 모델을 사용하는 업무 과정에 별도의 판단 단계를 넣는 방식입니다.

대표적인 활용 지점은 다음과 같습니다.

요청 라우팅: 요청의 유형을 평가해 처리할 서비스나 검토 경로를 선택합니다.
검색 문서 선별: 검색한 자료가 질문과 관련 있는지 평가하고, 답변에 사용할
자료의 순서를 정합니다.
입력 출력 검사: 사용자의 요청과 모델의 답변을 기준에 따라 평가하고,
통과·검토·차단 경로를 구분합니다.

구조화된 판단에도 보안 통제가 필요한 이유

1) 출력 형식이 맞아도 판단은 틀릴 수 있습니다

구조화된 출력은 애플리케이션이 결과를 읽고 처리하기 쉽게 만듭니다. 하지만 정해진 선택지 안에서 답했다는 사실이 그 선택의 정확성을 보장하지는 않습니다.

2) 외부 자료의 조작이 판단을 바꿀 수 있습니다

Check Point는 Jev를 투자 검토용 애플리케이션에 연결한 보안 실험을 공개했습니다.

연구진은 위험 신호가 담긴 가상 기업의 보고서를 제공한 뒤, 공격자가 문서의 일부를 바꿔 위험도를 낮게 평가하고 투자를 권하도록 유도했습니다.

실험에서 가장 강한 공격자 설정은 27회의 공격 실행 중 25회에서 목표한 판단 변경에 성공했습니다. 성공한 공격에는 위험 문제가 해결된 것처럼 보이는 감사 의견이나 수정된 평가 정보를 덧붙이는 방식이 포함됐습니다. 결과의 형식은 유효했지만, 모델이 참고한 근거가 조작돼 판단이 달라진 것입니다.

기업이 준비해야 할 네 가지 보안 통제

1) 판단에 사용하는 정보의 범위와 출처 관리

AI에 전달되는 정보에는 사용자가 입력한 질문 외에도 검색 문서, 이전 대화, 업무 도구의 조회 결과가 포함될 수 있습니다. 따라서 모델 호출 전에 어떤 자료가 함께 전달되는지 확인해야 합니다.

이 과정에서는 두 가지를 구분해 살펴야 합니다. 하나는 개인정보나 기업 기밀을 외부로 보내도 되는가이고, 다른 하나는 판단 근거로 삼는 자료를 신뢰할 수 있는가입니다. 민감정보를 가리는 것과 조작된 근거를 식별하는 것은 목적이 다릅니다. 자료의 접근권한과 출처를 확인하고, 판단에 필요한 범위로 입력을 구성하는 기준이 필요합니다.

2) 자동 처리와 사람의 검토 기준 정하기

T 회사는 AI의 예측 확률이 실제 결과와 얼마나 일치하는지를 확인하는 확률 보정(Probability Calibration)을 중요하게 다룹니다. 예를 들어 AI가 환불 요청일 가능성을 80%로 예측한 사례 중 실제 환불 요청이 약 몇%인지 확인하는 방식입니다.

이러한 예측 신뢰도를 바탕으로 업무의 위험 수준에 따라 자동 처리와 사람의 검토 기준을 구분해야 합니다. 고객 문의 분류와 외부 송금은 오류가 발생했을 때 미치는 영향이 다르기 때문입니다.

따라서 잘못 승인한 요청과 정상 요청을 불필요하게 차단한 사례를 각각 평가하고, 금전 거래 등 중요한 작업에는 별도의 확인 절차를 마련해야 합니다.

3) 모델의 판단과 실행 권한 분리

AI가 특정 도구를 선택했다고 해서 그 도구의 모든 기능을 실행하도록 허용할 필요는 없습니다. 실제 실행 전에는 사용자와 서비스의 권한, 요청한 작업의 범위, 전달할 값이 정책에 맞는지 확인해야 합니다.

예를 들어 문서 조회 업무에는 읽기 권한만 부여하고, 수정이나 삭제는 별도의 승인 조건을 두는 방식입니다. OWASP의 2026년 지침도 최소 권한, 영향이 큰 작업에 대한 사람의 승인, 모델의 판단에 의존하지 않는 별도의 권한 검증을 권고합니다.

판단 모델은 업무 처리에 필요한 정보를 제공하고, 실행 시스템은 허용된 행동의 범위를 지켜야 합니다.

4) 판단과 정책 적용 이력을 추적합니다

문제가 발생했을 때는 최종 결과뿐 아니라 어떤 입력과 질문을 사용했는지, 어떤 모델 버전과 기준값이 적용됐는지 확인할 수 있어야 합니다.

운영 과정에서는 모델 결과와 정책 적용 이력을 연결해 살펴보고, 변경 후에도 같은 기준이 유효한지 다시 평가하는 것이 좋습니다. 기록에 포함된 민감정보의 접근권한과 보관 범위도 함께 관리해야 합니다.

AI Keeper로 AI 사용 경로의 보호 기준 관리

Jev와 같은 판단 모델을 활용하더라도 기업이 정한 데이터 보호와 접근 기준은 계속 필요합니다. 여러 모델과 업무 서비스를 사용하는 환경에서는 이러한 기준을 실제 연결 경로에 일관되게 적용하는 것이 중요합니다.

AI Keeper는 기업 내 LLM과 AI 서비스를 Self-Hosted Gateway로 연결하고, 보안 정책과 접근 관리, 감사 체계를 공통으로 적용하도록 지원하는 AI Governance 플랫폼입니다. 기업이 사용할 AI와 전달할 정보를 관리하는 지점으로 활용할 수 있습니다.

1) 전송할 정보를 검사하고 사용 이력을 확인합니다

AI Keeper는 관리자가 설정한 보호 규칙에 따라 외부 AI로 보낼 내용을 검사합니다. 전송이 금지된 정보는 차단하고, 업무에 필요하지 않은 개인정보는 가린 뒤 전달하는 방식입니다. 질문뿐 아니라 연동된 서비스가 함께 보내는 문서 텍스트와 이전 대화 등도 검사 대상이 될 수 있습니다.

운영 관리에서는 다음과 같은 기능을 제공합니다.