OMO JEV 플러그인은 탐색 비용을 얼마나 줄일까: 설치부터 실험 결과까지

OMO에 JEV를 붙이면 토큰을 덜 쓸까? 에이전트가 코드를 찾느라 여러 파일을 읽는 작업이라면 궁금할 만하다. 공개된 omo-jev-plugin의 설정과 실험 결과를 따라가며 무엇이 줄었고, 무엇은 아직 확인되지 않았는지 살폈다.

Jev는 코드를 작성하는 대신 다음 선택을 돕는다

OmO는 여러 모델과 도구를 활용해 작업을 진행하는 에이전트다. 현재 OmO 문서는 OpenCode용 플러그인과 독립 실행형 OmO Native를 구분한다. omo-jev-plugin의 설치 안내는 omo 명령을 쓰는 OmO 또는 senpi 환경을 대상으로 한다. Claude Code에 같은 명령으로 설치하는 플러그인은 아니다. (github.com)

플러그인이 연결하는 Jev는 TypeSafe의 판단 모델이다. TypeSafe 문서에 따르면 Jev는 텍스트를 받아 선택과 점수 같은 구조화된 판단을 반환한다. 플러그인은 이 판단을 바탕으로 스킬과 다음 도구가 적합한지 살피고, 반복되는 실패나 완료 가능성을 에이전트에 알린다. Jev가 직접 도구를 실행하거나 기존 권한 검사를 대신하지는 않는다. (raw.githubusercontent.com)

‘JEV를 붙이면 절약된다’는 말은 두 기능으로 나눠 봐야 한다. 일반 판단 기능은 에이전트가 다음 행동을 고를 때 짧은 제안을 더한다. 저장소의 비용 비교는 그 기능 전체가 아니라 별도로 켜는 실험적 코드 검색을 대상으로 했다. 방에서도 탐색이 많은 작업에 기대를 걸었지만, 모든 작업의 사용량이 줄었다는 검증으로 읽을 수는 없다. (raw.githubusercontent.com)

설치 후에는 제안 모드와 공급자 키를 확인한다

저장소 README가 안내하는 설치 명령은 omo install npm:omo-jev-plugin이다. 처음 로드하면 ~/.omo/jev-plugin.jsonc가 생성되고 advise 모드가 지정된다. 선택한 공급자의 API 키도 설정해야 판단 요청이 나간다. 키가 없으면 플러그인은 경고를 표시하고 판단 API를 호출하지 않는다. (raw.githubusercontent.com)

기본 공급자는 Jev 호환 API다. 설정 파일의 provider.jev_compatible.apiKey에 키를 넣거나 OmO 실행 프로세스에 TYPESAFE_API_KEY를 제공할 수 있다. OpenRouter의 Span-01 Lite도 선택할 수 있다. 다만 README는 두 공급자가 같은 방식으로 선택·점수를 계산하지 않는다고 명시한다. 공급자만 바꾸고 결과가 같을 것이라 기대해서는 안 된다. (raw.githubusercontent.com)

작동 범위는 모드에 따라 다르다. shadow는 판단을 기록하지만 에이전트 행동은 바꾸지 않는다. advise는 스킬과 도구 후보 등을 제안한다. act는 별도로 활성화한 경우에 한해 호출 차단, 모델 선택 같은 동작까지 적용한다. 기존 설정에서 모드를 생략하면 off로 해석된다. 설치 뒤에는 실제 모드와 키 상태를 함께 확인해야 한다. (raw.githubusercontent.com)

탐색 실험은 어떤 입력과 결과를 비교했나

비용 비교에 쓰인 jev_code_search는 기본적으로 꺼져 있다. 신뢰된 Git 프로젝트에서 설정 파일에 "experimentalCodeSearch": true를 넣고 새 세션을 시작하면 등록된다. 질문 문장과 선택적인 프로젝트 내부 경로를 입력하면 관련 파일의 경로·줄 번호·코드 발췌를 돌려준다. 답을 작성하거나 파일을 수정하는 도구는 아니다. (raw.githubusercontent.com)

세션 만료를 검사하는 위치를 찾는다면 질문과 src 같은 검색 범위를 전달하는 식이다. Jev가 관련 코드 구간을 고르면 OmO는 반환된 원문을 근거로 후속 조사를 이어갈 수 있다. 검색 대상은 Git이 추적하거나 무시하지 않은 소스 파일이다. 후보가 48개를 넘으면 경로를 더 좁혀야 하며, 파일 전체를 빠짐없이 읽는 검색도 아니다. (raw.githubusercontent.com)

저장소 README의 실험은 한 저장소에서 여러 파일에 걸친 동작을 추적하는 동일한 질문을 사용했다. openai/gpt-6-sol로 일반 검색과 Jev 검색을 각각 다섯 번 실행했고 양쪽 모두 다섯 번 코드 근거를 찾았다. 공개된 5회 총비용은 일반 검색 0.327948달러, Jev 검색 0.264182달러다. 후자에는 Jev 사용료 추정치 0.004038달러가 포함돼 있다. 차이는 19.4%였다. (raw.githubusercontent.com)

이 숫자는 ‘OMO 전체 토큰 19.4% 절감’과 다르다. README가 비교한 지표는 해당 조사 과제의 총비용이다. 표에는 호스트 모델 비용과 Jev 추정 비용이 나뉘어 있다. 실행 시간 단축이나 다른 저장소에서의 재현도 증명하지 않는다. TypeSafe가 게시한 Jev 1.13 요금은 입력 100만 토큰당 0.042달러로, 실험의 Jev 비용 계산에 사용됐다. (raw.githubusercontent.com)

비용표 밖에서 판단할 조건들

코드 검색을 켜면 파일 경로와 일부 소스 내용이 선택한 판단 공급자로 전송된다. README는 경로 필터가 코드 안의 비밀값까지 찾아내지는 못한다고 경고한다. 비공개 프로젝트를 다루는 소규모 팀이라면 절감액을 따지기 전에 전송 가능한 코드인지 판단해야 한다. 키를 프로젝트별 설정 파일에 적었다면 그 파일을 공유하지 않도록 주의할 필요도 있다. (raw.githubusercontent.com)

일반 판단 기능도 요청 일부와 도구·스킬 후보 정보를 공급자에게 보낸다. 도구 결과 본문은 기본적으로 전송하지 않지만 관련 옵션을 켜면 전송 범위가 넓어진다. README에 따르면 상세 텔레메트리는 기본 활성화돼 있다. "telemetry": { "detailed": false }로 상세 수집을 끌 수 있으나 세션 이벤트와 공통 메타데이터 수집까지 중단되지는 않는다. (raw.githubusercontent.com)

써본 사람들 사이에는 OmO의 여러 에이전트가 복잡한 일에 도움이 된다는 반응과 단순한 일에는 토큰 소비가 부담스럽다는 반응이 함께 있다. 어느 쪽도 이 플러그인의 절감률을 입증하지는 않는다. 방에서 제기된 효율 기대를 검증하려면 같은 저장소와 과제에서 검색 방식뿐 아니라 성공 여부·총비용·소요 시간을 함께 비교해야 한다. (reddit.com)

탐색이 적은 작업에도 이득이 남을까

정확한 기호나 경로를 이미 안다면 README는 일반 grep과 read를 쓰라고 권한다. 작은 수정에까지 Jev 검색을 끼워 넣는다면 추가 판단 요청이 그만한 값어치를 하는지 따져야 한다. 반대로 여러 파일의 연결 관계를 찾아야 하는 조사는 공개 실험과 조건이 가깝다. 개인 개발자에게 중요한 차이는 플러그인 설치 여부보다 자신이 반복하는 작업의 형태다. (raw.githubusercontent.com)

shadow 모드의 /jev-shadow-report는 추천 도구와 실제 첫 도구, 연속 오류 등을 집계한다. 그러나 README는 그 기록이 Jev를 적용했을 때 호출이 줄어든다는 인과적 증거는 아니라고 못 박는다. 현재 공개된 근거는 한 탐색 과제에서의 비용 절감이다. 다음에 확인할 것은 더 다양한 과제에서 같은 품질을 유지하면서 비용과 시간을 함께 줄이는가다. (raw.githubusercontent.com)