Jev에 대한 나의 간단한 고찰
최근에 ‘Jev’라는 새로운 AI 모델이 나왔는데, 이게 되게 개발자들 사이에 화제가 되고 있는 것 같다. 해당 모델의 공식 페이지에서 설명하길 기존 프론티어 모델들 대비 빠른 응답 속도(평균 100ms 정도), 저렴한 토큰당 비용 그리고 구조화된 형식의 결과를 보장한다는 게 다른 모델들과 다른 차별점인 것 같은데, 나도 궁금해서 어제 저녁에 대기열에 등록하고 오늘 아침에 접근이 가능해져서 한번 빠르게 사용해보고 내 의견을 남겨본다.
Jev(System One) 모델은 무엇인가?
출처 : Introducing System One Models & Jev
TypeSafe 사에서 발표한 Jev 모델은 GPT, Claude 모델과 같이 글을 생성하는 챗봇이 아니라, 주어진 상황을 보고 소프트웨어가 바로 사용할 수 있는 구조화된 결과를 빠르게 반환하는 모델이다. 그리고 TypeSafe 사에서는 이렇게 구조화된 결과를 내는 모델을 System One 모델이라 칭하고, 이번에 나온 첫 번째 버전의 모델을 Jev라고 부른다. Jev 모델은 다른 프론티어 모델과 달리 엄청나게 빠른 속도와 저렴한 비용으로 이미 서비스에 통합되어 운영되고 있던 LLM 서비스의 대체재로서 화두가 되고 있다.
일반적인 LLM은 문장 내에서 이전 단어(토큰)를 기반으로 다음 단어(토큰)를 하나씩 생성해 최종적으로 문자열을 만들게 된다. 따라서, 결과로 나오는 문자열은 일반적인 답변 텍스트, 코드, 구조화된 JSON 등 자유롭게 만들 수 있지만, LLM의 결과가 항상 일관되게 나오지는 못하기 때문에 서비스에 LLM을 탑재하려면 결과를 파싱하고 스키마를 검증하는 절차가 필수적이다.
Jev 모델을 사용한 실제 사용 예시
하지만 System One 모델은 텍스트를 결과로 도출하는 것이 아닌 확률 자체를 반환하기 때문에 구조화된 결과를 보장한다. 실제로 위 예시는 현재 상태를 담는 State와 결과를 도출하기 위한 Questions를 Jev 모델에 입력하여 결과를 도출해낸 예시이다.
위 예시에서는 실제로 커머스 고객센터를 예시로 러닝화의 오배송에 대한 문의를 어떤 팀에 인계해야 하는지를 분류하는 예시이다. 결과로는 오배송을 담당하는 returns_team에 인계해야 한다는 결과가 나온 것을 볼 수 있다. 근데 여기서 주의 깊게 봐야 하는 것은 모델 결과 도출 시간이다.
예제가 간단하긴 하지만 모델의 추론 속도가 117ms인데, 이건 정말 놀라운 숫자이다. 그리고 Jev를 소개하는 공식 페이지에서 속도를 비교하기 위해 좀 더 복잡한 예시를 Jev 모델과 GPT 5.6 Terra 모델에 각각 입력으로 주고 결과를 반환했는데, Jev 모델은 114ms, GPT 모델은 8.5s(애초에 단위가 다르다)로 상당한 차이를 보여준다.
출처 : Introducing System One Models & Jev
그리고 여기서 더 놀라운 점은 추론을 위해 소모된 비용이다. Jev 모델은 최종적으로 $0.000081이 소모됐고, GPT 모델은 $0.014가 소모됐다. 대략 170배 정도의 차이가 나는 건데, 이는 실제로 서비스되는 운영 환경에 적용했을 때 비용 차이가 더 크게 날 수 있는 차이다.
대충 봤을 때에도 왜 커뮤니티가 이 모델로 굉장히 시끄러운지 알 수 있는 대목이었다. 간만에 나도 새로운 게임 체인저의 등장이라고 생각해서, 모델 접근 계정을 받자마자 바로 이번 주말 동안 무언가를 만들어보자는 목표를 세우고 프로젝트를 만들기 시작했다. (물론 클로드의 도움을 받아(사실 클로드가 혼자서))
빠르게 만들어 본 간단한 PoC
사실 Jev로 무엇을 만들어 볼까라는 생각을 하자마자 떠오른 아이디어는 웹 E2E 테스트 툴이었다. 실제로 사내에서 Playwright 기반의 E2E 테스트를 진행하는데, 여기에 Jev를 접목하여 좀 더 정밀하게 테스트를 할 수 있지 않을까라는 생각을 했다. 근데 좀 더 생각하니 ‘굳이?’라는 생각이 들었는데, 그 이유는 다음과 같다.
E2E 테스트는 왜 하는 것인가? 기본적으로 웹 E2E 테스트는 작업중이나 배포 전에 서비스를 전반적으로 테스트를 하기 위해 진행되며, 항상 동일한 환경/조건에서 동일한 로직으로 테스트를 진행한다. 테스트 중에는 이전 테스트와 비교해서 달라진 부분이 없어야 하고 이렇게 해야만 이전 테스트의 결과를 기반으로 신규 빌드에서는 UI가 깨졌다는 걸 알아차리거나 기능이 동작하지 않는다는 걸 빠르게 알 수 있기 때문이다.
따라서 E2E 테스트는 정적(항상 동일한 조건이어야 하는) 테스트이다. 그리고 이러한 정적인 환경에서 과연 Jev가 필요할까?라는 질문에는 나는 필요 없다고 답할 것 같다. 테스팅 기법에 에이전트를 도입하는 건 테스트 환경 자체가 동적 구조라서 매번 조건이 변하는 환경이거나 에이전트가 자유롭게 웹 서비스를 탐색하면서 무언가의 정보를 알아내야 할 때 주로 사용될 수 있다. 따라서, 내가 생각한 E2E 테스트로 Jev를 도입하는 건 좋은 선택이 아니라고 생각했다.
자 그럼 다시 돌아와서 어떤 걸 만들어 볼까?라는 생각을 계속 했는데 E2E 테스트가 미련이 남아서 그런가 계속 웹 쪽으로만 관심이 갔다. 그래서 에이전트가 직접 브라우저를 조종해서 무언가 결과물을 내는 프로젝트를 구현하는 걸로 목표를 세웠다. 이전 E2E 테스트 아이디어와 다른 점은 항상 정적인 경로로 웹 사이트를 테스트하는 게 아니라 에이전트가 그 경로를 직접 결정해줘야 한다는 점이다.
물론 내가 구현하는 게 아니라 클로드가…
실제로 에이전트가 브라우저를 조종하여 어떤 결과물을 내는 건 꽤 오래전부터 존재했다. Comet 브라우저도 생각보다 잘 해주고, 최근에 나온 GPT-6도 빠르게 이를 처리한다고 들었다. 근데 내가 굳이 이 레드오션에 뛰어든 건 가장 결과를 잘 볼 수 있는 예시라고 생각했기 때문이다.
그래서 쉽게 Claude나 Codex에서 호출하여 어떤 작업을 수행하기 위한 MCP 서버를 구현하기로 결정하고, 대략적으로 다음과 같은 구조로 설계를 진행했다.
대략적인 데이터 플로우
아무래도 Jev 모델은 주어진 선택지에서 선택만 할 뿐 선택지에 없는 옵션을 생성하지는 못하기 때문에 이 프로젝트에서는 실제로 Jev에게 명령을 정리해서 내려줄 지시자 에이전트가 필요했다. (위에서는 Claude/Codex가 이를 대신함)
만약 사용자가 “컬리 페이지에 접속해서 카레 재료를 장바구니에 담아줘”라는 쿼리를 날렸다고 했을 때, 이 지시자 에이전트는 Jev가 효율적으로 동작할 수 있도록 이를 아래와 같이 스텝을 나누어 한 스텝씩 MCP 서버에 전달하고, 해당 스텝이 완료됐다는 MCP의 결과가 반환되면 그다음 스텝으로 넘어가는 것이다.
Step 1) 컬리 페이지에 접속
Step 2) 카레 가루를 검색하고 첫 번째 제품을 장바구니에 담기
Step 3) 양파를 검색하고 첫 번째 제품을 장바구니에 담기
Step 4) 감자를 검색하고 첫 번째 제품을 장바구니에 담기
Step 5) 돼지고기를 검색하고 첫 번째 제품을 장바구니에 담기
자, 그럼 이 아키텍처를 적용한 실제 동작 영상을 살펴보자.
컬리에서 직접 카레 재료를 장바구니에 담는 예시
첫 번째 예시는 컬리에서 카레 2인분을 만들 재료를 알아서 장바구니에 담는 경우로, 단순히 특정 상품만 골라야 하는 게 아니라 카레를 만들기 위한 카레 가루, 양파, 감자, 돼지고기와 같은 재료들을 각각 장바구니에 담아줘야 한다.
이 예시에 대해서는 크게 정확도나 시간이 단축되지는 않았다. 카레 재료를 잘 고르긴 했으나 과연 2인분이 맞을까 생각이 드는 부분들(감자 1kg를 고르거나, 양파도 더 작은 양이 있었음에도 불구하고 1.8kg를 고르는 경우)이 있었다. 그리고 GPT-6와 비교하기 위해 동일하게 쿼리를 날렸는데 오히려 GPT-6 쪽이 2분 30초 정도로 더 빠르게 작업을 수행했고, Jev가 고른 상품들보다 좀 더 2인분에 맞도록 재료를 구입했다.
버스 예약 페이지에서 버스 시간을 찾는 예시
두 번째 예시는 버스 예약 페이지에서 내일 오전에 동서울에서 부산으로 가는 버스 시간을 조사하는 경우로, 생각보다 까다로운 게 페이지 접속하자마자 안내 배너가 4개나 떠서 사실상 모두 닫아야 검색을 할 수 있다. 그런데 이 예시는 생각보다 빠르게 해결했는데, 아마 사람이 했으면 더 빠르게 해결할 수 있을 것이다.
자 이렇게 두 예시를 살펴봤는데, 동작하는 영상만 보고서 ‘생각보다 잘 동작하네’라고 생각할 수 있다. 하지만 사실 두 예시를 녹화하기 전까지 정말 많은 우여곡절이 있었고, 아직도 이슈들이 많은 상태이다. 그리고 많이 불안정해서 동일한 쿼리를 던져도 결론 도출에 더 많은 시간이 걸리거나, 아예 실패하는(로그인 없이 장바구니에 담을 수 있는데 로그인을 강제함 등) 경우가 성공하는 케이스보다 더 많았다.
자 그렇다면 어떤 게 문제였을까?
Jev 모델의 짧은 생명주기
현재 아키텍처상 모든 명령은 지시자 에이전트에 의해 Jev 모델을 실행하는 방식이다. 그러다 보니 처음부터 끝까지 Jev 모델이 진행하는 게 아니라 지시자 에이전트에 의해 목표를 몇 가지의 스텝으로 변환하고 각 스텝을 Jev 모델이 진행하는 방식이다 보니 Jev 모델은 비교적 생명주기가 짧다. 이로 인해 지시자 에이전트와 Jev 모델의 왕복 순회가 늘어나며 사실상 에이전트가 브라우저 MCP로 작업을 진행하는 것과 크게 다르지 않게 되어버린 것이다.
HTML 요소 우선순위의 공백
스텝를 완수하기 위해 Jev는 HTML 요소들을 데이터로 받는데 사실상 요소에 대한 우선순위가 없기에 페이지상으로는 안내 모달이 가장 앞에 있는데 이를 따로 감지할 수가 없는 상태이다. 그래서 실제로 위의 컬리 예시에서 바로 장바구니에 물품을 담자 수량을 선택해달라는 안내가 발생했지만 이를 무시하는 경우가 발생했다.
일단 지금 언뜻 보기에는 위의 두 이슈가 가장 큰 것 같고, 이를 어떻게 해결할 수 있을지는 한번 고민이 필요할 것 같다.
내가 느낀 점
자 이번에는 Jev 모델을 사용하면서 내가 느낀 점들을 간략하게 공유하고자 한다.
1. 생각보다 한글을 잘 이해한다.
출처 : https://ahn-lab.org/jev-korean-benchmark/
위에서 간단히 설명한 예시나 이번 프로젝트를 보면 알겠지만, 생각보다 한글을 잘 이해한다. 실제로 Jev의 한국어 성능을 측정한 문서에 따르면 한글, 영어 모두 GPT 5.6 Luna 모델과 비슷하거나 높은 점수를 얻은 걸 알 수 있다.
사실 Luna 정도의 성능이면 꽤나 많은 도메인에서 수월하게 동작할 수 있다고 생각하기에 필요에 따라서는 Jev가 좋은 대체재가 될 수 있다고 생각한다.
2. 비용도 적게 드는데, 응답 속도도 빠르다.
실제 지출 비용
위 사진은 실제로 내가 주말간 Jev 모델을 가지고 놀면서 발생한 비용이다. 약 1800만 개의 토큰을 사용했고, 실제 지출된 비용은 71센트이다. GPT 5.6 Luna 기준으로 1M 입력 토큰이 0.2 달러 정도 발생하기 때문에 대략적으로 봤을 때 약 7배 정도 Jev 모델이 저렴한 것이다.
더 적은 비용과 함께 빠른 응답 속도도 큰 장점이다. 이번 프로젝트 내에서 Jev 모델을 호출할 때 평균적으로 400ms 정도 걸렸는데, 아무래도 입력 토큰이 많기도 해서 맨 위의 예시(100ms가 걸리던)보다는 좀 더 오래 걸리긴 했다. 하지만 토큰을 이해하고 결과를 내는 데 400ms 정도는 충분히 빠른 속도라고 생각한다.
3. 이미지나 영상을 입력받지 못한다.
출처 : https://docs.typesafe.ai/models
말 그대로 아직(yet이다) Jev 모델은 텍스트 외에 이미지/오디오와 같은 입력을 받지 못한다. 그래서 Jev가 이를 인식하기 위해서는 앞단의 별도 에이전트가 이미지와 오디오를 이해하고 Jev가 이해할 수 있도록 텍스트로 변환하는 절차가 필요하다.
만약 Jev 모델이 추후에 텍스트뿐만 아니라 다양한 종류의 입력을 지원한다면 위에서 이번 프로젝트의 한계점으로 설명한 “HTML 요소 우선순위의 공백” 부분도 고쳐볼 수 있을 것이라 생각한다.
4. 최대 입력 토큰에 제한이 있다.
출처 : https://docs.typesafe.ai/models
공식 문서에서 설명하길 Jev 모델에 요청할 수 있는 토큰 크기는 64k이다. 근데 보통 Jev를 사용할 때 많은 컨텍스트를 차지하는 건 State인데, 공식 문서상 State와 가장 긴 질문을 합쳐서 32k 토큰을 최대로 받을 수 있기 때문에 사실상 최대 32k의 토큰을 입력받을 수 있다고 볼 수 있다.
또한, 비교적 한글이 영어보다 토큰을 더 많이 소비하기 때문에 체감상 느끼는 최대 제한은 더 적을 것이다. 최신 프론티어 모델들은 대개 1M 토큰까지 지원하는데 비해 작은 컨텍스트 용량은 단점이 될 수 있을 것이다.
결론
주말 동안 Jev를 사용하면서 처음의 기대와는 사뭇 달랐던 부분도 있고 놀랐던 포인트들도 있었던 것 같다. 그리고 무엇보다 프로젝트를 진행하며 가장 오래 고민했던 부분은 Jev를 효과적으로 사용하기 위해 어떻게 프롬프트를 작성해야 하는가였다. 특히 Jev는 다른 LLM 모델들과는 달리 주어진 선택지 중에서 하나를 고르는 방식이기 때문에 효과적으로 통합되게끔 하는 게 어려웠던 포인트였다.
그렇다면 Jev는 어디에 쓰면 좋을까? 내 생각에는 CS 분류, 라우팅, 필터링처럼 선택지 중에 하나를 선택해야 하는 기능에서 효과를 발휘할 수 있을 것이라 생각한다. 이전에 이런 판단 자체를 LLM 에이전트가 진행했다면 높은 비용, 긴 응답 시간, 깨진 구조 반환 등의 리스크가 존재했을 텐데, Jev를 도입한다면 이 모든 리스크를 한꺼번에 해결할 수 있을 것이다. 반대로 이번 프로젝트처럼 선택지 자체를 매 상황마다 다르게 줘야 하는 환경 즉, 앞단에 지시자 에이전트와 같은 에이전트가 필요한 환경이라면 도입 효과가 크지 않을 것이라 생각한다.
이번 글에서는 Jev를 기반으로 프로젝트를 구현해가며 얻은 지식들을 공유해봤다. 아무래도 최근 다양한 모델이 출시되고 너 나 할 것 없이 AI 경쟁을 벌이는 시대에 이런 참신한 모델은 새로운 방향을 제시한다는 점에서 되게 좋다고 생각한다. 앞으로도 종종 이런 재밌는 게 나오면 종종 리뷰하는 시간을 가져보겠다. 그럼 다음 글에서 보자!