Jev를 LLM 앞뒤에 놓는 설계: 판단과 실행 권한을 나눈다
9월 25일 X에서 공유된 Jev 설계 요약은 LLM이 모든 판단을 맡는 에이전트 대신, 생성·좁은 판단·실행을 나누는 방법을 소개한다. 이어진 답글에는 12쪽짜리 How to Use Jev with LLMs PDF가 연결돼 있다.
Jev 설계 요약 X 게시물
먼저 저자 표기를 바로잡아야 한다. X 게시물은 PDF를 Jev 창립자가 공개한 자료라고 소개하지만, PDF 표지에는 공개 TypeSafe 문서와 사례를 바탕으로 만든 "독립 가이드"라고 적혀 있다. PDF 메타데이터의 작성자 항목도 "Independent field guide"다. 연결 경로만으로 창립자가 직접 썼거나 승인했다고 확인할 수 없다. 아래는 이 PDF의 설계안을 읽고, TypeSafe 공식 문서와 맞는 기능 설명을 대조한 내용이다.
생성, 판단, 실행을 서로 다른 자리에 놓는다
가이드의 첫 구분은 출력의 형태다. LLM은 글과 코드, 계획처럼 열린 결과를 만든다. Jev는 주어진 상태를 보고 미리 정한 선택지, 점수 단계, 참일 확률을 돌려준다. 코드에는 경로 선택과 권한 확인, 실제 실행을 남긴다. 가이드가 제안하는 경로는 요청을 먼저 규칙으로 검사하고, 필요하면 Jev가 의도와 위험을 좁게 판단하고, 그 결과에 따라 LLM에 보낼 자료와 도구를 고르는 순서다. LLM 결과가 나온 뒤에는 형식 검사를 하고, 필요한 의미 질문만 Jev에 다시 묻는다.
TypeSafe 문서의 이름은 Choice, Score, Noul이다. 고객 메시지를 환불·재예약·정보 요청 중 하나로 나누는 일은 Choice에 맞는다. 불만의 강도를 미리 정의한 단계에서 보는 일은 Score, 환불을 요구했는지의 확률을 얻는 일은 Noul에 맞는다. 여러 질문을 한 요청에 넣으면 같은 상태를 보지만, 각 답은 독립적이다. 앞 답을 뒷질문의 전제로 쓰려면 프로그램이 그 답을 새 상태에 넣어 다시 요청해야 한다.
확률은 실행 허가증이 아니다
가이드가 반복해서 선을 긋는 지점은 권한이다. Jev가 높은 확률로 "허용"을 골라도 사용자 계정의 권한이 늘어나지 않는다. 경로, 도메인, 금액, 데이터 반출 범위처럼 코드로 검사할 수 있는 조건은 코드에서 먼저 확인한다. TypeSafe의 confidence 설명도 Choice와 Score의 confidence가 선택지 확률 분포를 한 숫자로 줄인 값이라고 밝힌다. 분포가 한쪽에 몰렸다는 뜻이지, 답이 현실에서 맞았다는 검증 결과는 아니다. Noul에는 별도 confidence 필드가 없다.
PDF의 후반부는 상태와 질문의 버전, 확률, 선택된 경로, 적용한 기준, 사람의 수정, 실제 결과를 한 결정 기록으로 남기라고 제안한다. 자동 실행 전에는 과거 사례 재생, 결과만 기록하는 관찰 단계, 사람에게 추천만 하는 단계, 낮은 위험의 일부 자동화 순서로 범위를 넓히라고 썼다. 이는 이 가이드의 권고다. 이 글에서 Jev를 연결해 비용과 지연 시간, 오류 감소를 측정한 것은 아니다.
기존 Jev 활용 사례 글이 제품들이 어디에 작은 판단을 끼워 넣었는지 다뤘다면, 이 자료의 관심은 그 판단 뒤에 누가 실행 권한을 갖는지다. Jev의 답을 기록하고 실제 결과와 대조할 수 있어야, 빠른 결정 레이어가 판단을 개선했는지 알 수 있다.
