Jev를 Pi의 빠른 판단 계층으로 쓰자는 제안

Jev의 응답 시간은 약 150~250밀리초다. 글은 이 속도가 에이전트의 위험한 명령을 가려내거나 작업을 알맞은 모델로 보내는 데 쓸모 있다고 주장한다.

이 글은 Jev를 Pi 코딩 에이전트의 주된 추론 모델로 쓰지 말고, 짧고 정해진 선택을 맡기는 판단 계층으로 연결하자는 제안이다. Pi 확장 기능을 만드는 사람이라면 먼저 명령 실행을 막는 안전장치부터 붙이고, 이후 모델 선택과 비용 절감으로 넓혀 가라는 내용이다.

Jev는 무엇을 판단하나?

Jev는 TypeSafe의 ‘System One’ 모델이다. 글의 설명에 따르면, 상태와 정해진 선택지를 입력하면 선택 결과와 noul, 점수를 반환한다. 문장을 생성하거나 함수 이름을 만들어 내는 모델이 아니라, 범위가 제한된 결정을 내리는 모델이다. 빠른 응답과 낮은 비용을 에이전트에서 활용할 수 있다는 것이 글의 핵심 주장이다.

먼저 명령 실행을 막으려는 이유는?

Pi의 셸 명령 실행 전에 Jev에게 몇 가지 유형이 정해진 질문을 하는 방식이 소개된다. 명령이 되돌릴 수 없는지, 에이전트가 직전에 말한 작업과 맞는지, 영향이 작업 트리 밖으로 나가는지를 판단하게 한다.

pi-warden은 프롬프트와 에이전트의 직전 발언, 실행하려는 호출을 읽어 판단하는 도구로 소개된다. specpi-jev-guard는 같은 접근을 bash, powershell, write, edit 앞에 둔다. 명백한 위험은 로컬 규칙이 즉시 막고, 명령 자체는 그럴듯하지만 의도가 어긋난 경우는 Jev가 살핀다는 구상이다.

이 글이 안전장치를 먼저 권하는 까닭은 잘못된 리팩터링보다 의도하지 않은 rm이나 신뢰한 curl | shell이 더 큰 실패로 이어질 수 있기 때문이다. Jev가 느리거나 작동하지 않아도 로컬 규칙은 계속 적용된다는 점도 중요하다고 본다. 안전장치를 에이전트 내부에 두면 에이전트가 권한 규칙 자체를 바꿀 수 있으므로, 실행 전에 외부에서 검사해야 한다는 주장이다.

모델 선택과 연결 방식은 어떻게 구성하나?

명령 보호가 안정되면 Jev를 모델 라우터로 쓸 수 있다. Jev가 작업을 읽고 다음 차례를 처리할 모델과 추론 수준을 고른다. 일상적인 작업은 저렴한 모델에, 어려운 문제는 비싼 모델에 맡기고, 라우터의 선택에 동의하지 않으면 사용자가 모델을 고정할 수 있다는 방식이다.

글은 작업의 대부분이 단순 분류나 파일 수정이라면 매번 큰 모델을 쓸 필요가 없다고 주장한다. 가장 저렴하면서도 작업을 처리할 수 있는 모델로 보내는 신뢰도 기준의 라우팅을, Grist는 OpenCode v2에서 만들고 있고 Pi 사용자는 확장 기능으로 구현하고 있다고 소개한다.

또 다른 제안은 Jev를 한 제공자에 고정하지 않는 것이다. pi-system-one은 Pi에 범위가 제한된 결정을 위한 system_one 도구 하나를 제공하며, 제공자에 중립적인 소프트웨어 개발 도구 모음(SDK)을 기반으로 한다. 처음에는 Jev에 직접 연결했지만 Laya, von, Reflex 같은 제공자가 등장한 뒤에는 하나의 인터페이스에서 뒷단을 바꾸는 편이 낫다는 결론으로 이어졌다고 글은 설명한다. Jev 출시 약 2주 뒤에는 기존 모델에 같은 아이디어를 적용한 OpenAI의 Decisions API도 나왔다고 덧붙인다.

따라서 제안하는 구성은 bash와 edit 앞의 실행 전 검사, 로컬 규칙을 먼저 적용하고 Jev에 유형이 정해진 질문을 보내는 방식, 여러 제공자를 지원하는 system_one 도구, 사용자가 쉽게 모델을 고정할 수 있는 라우터다. 로그 축약, 검색 결과 재정렬, 문맥 압축을 위한 사전 필터는 선택 기능으로 둔다. 필요한 정보만 불러와야 하며, 문맥을 보호하는 안전장치가 문맥 창을 지나치게 차지해서는 안 된다는 지적이다.

무엇을 피해야 하나?

Jev를 주된 추론 모델로 삼거나, 마이그레이션 코드를 작성하게 해서는 안 된다는 것이 글의 권고다. Jev는 텍스트를 생성하지 않으므로 그런 작업을 맡기는 것은 역할이 맞지 않는다. 검색 순위 산정에 비밀 정보를 원문 그대로 보내는 것도 피해야 한다. 글은 한 검색·재정렬 프로젝트가 작업 내용과 후보 구절을 보내기 전에 흔한 비밀 정보를 가린다며, 이를 기본값으로 삼아야 한다고 주장한다.

로그 축약이나 검색 결과 재정렬, 문맥 압축도 쓸모는 있지만, 잘못된 명령으로 기기를 망가뜨릴 수 있는 상태라면 우선순위가 아니라는 것이 글의 결론이다. Jev의 가치는 에이전트를 대체하는 데 있지 않고, 비싼 모델 앞에서 행동을 검사하고 작업을 분배하는 데 있다는 주장이다.

Jev의 실제 가격과 150~250밀리초 응답 시간의 측정 조건, 소개된 확장 기능의 지원 범위와 비교 결과는 글에 나오지 않는다.