Jev의 Pokémon Red 플레이는 37시간 만에 끝났지만, Claude가 승리 시스템 구축을 도왔다

Jev는 16,150회의 모델 의사결정이 필요했던 Pokémon Red 플레이를 37시간 40분 만에 완료했다. 비슷한 게임에서 수주 또는 수개월 동안 헤맨 이전 챗봇 실험들과 비교하면 눈에 띄는 결과다. 그러나 비LLM 시스템의 승리처럼 보이는 이 성과에는 중요한 단서가 있다. 개발자는 Claude Opus 5가 실패를 진단하고 Jev를 둘러싼 의사결정 환경을 개선하는 데 도움을 줬다고 말한다.

이 구분은 중요하다. Jev는 게임 화면을 보고, 여정 전체를 기억하거나, 컨트롤러를 직접 조작하지 않았다. 맞춤형 소프트웨어 하니스가 Game Boy의 메모리에서 선별된 데이터를 읽고, 가능한 선택지를 구성하며, 각 선택지에 관한 정보를 추가했다. 이후 Jev는 준비된 행동들 가운데 하나를 골랐다.

보도에 따르면 Claude는 시스템의 다른 계층에서 작동했다. 로그를 검토하고 Jev에 유용한 정보가 부족한 상황을 찾아내며, 의사결정 모델에 제시되는 선택지와 지침을 개선하는 데 도움을 줬다. 따라서 이 플레이는 AI 에이전트에 관한 익숙한 가정에 도전하지만, 소규모 의사결정 모델이 최첨단 챗봇보다 독립적으로 더 뛰어난 사고를 할 수 있음을 입증하는 것은 아니다.

Jev의 Pokémon Red 플레이는 37시간 후 종료됐다

헤드라인 성과는 개발자가 공개한 설정 안에서는 사실이지만, 이는 고립된 모델이 아니라 완전한 소프트웨어 시스템을 측정한 결과다.

Frigade의 개발자 Christian Mathiesen은 이 오픈소스 실험을 구축했으며, 2026년 9월 25일부터 9월 26일까지 마지막 플레이를 스트리밍했다. 프로젝트의 공개 플레이 데이터에 따르면 Jev는 Pokémon Red를 37시간 40분 만에 완료했다.

저장소에는 16,150회의 의사결정과 약 3,920만 개의 입력 토큰이 기록돼 있다. 보도에 따르면 일반적인 의사결정에는 약 0.4초가 걸렸다. Jev는 전체 파티가 전멸한 경우를 16번 겪었으며, 그중 14번은 Elite Four에 도전하는 과정에서 발생했다. 완료까지 Elite Four에 15번 도전해야 했다.

최종 파티에는 레벨 83의 Charizard와 레벨 62의 Graveler가 포함됐다. Nidoqueen, Beedrill, Haunter, Primeape가 나머지 구성을 채웠다. 이러한 세부 사항은 이 시스템이 초반 지역의 짧고 미리 정해진 경로만 따른 것이 아님을 보여준다.

Jev는 스타터를 선택하고, 파티를 관리하며, 포켓몬을 잡고, 공격을 선택하고, 아이템을 구매하고, 회복하고, 훈련하며, 이동할 장소를 결정했다. 메뉴도 처리하고 스토리 프롬프트에도 응답했다. 저장소에 따르면 하니스는 게임 메모리에 직접 쓰거나 이벤트 플래그를 변경하지 않았다.

그러나 이 시스템은 Game Boy를 든 사람이 받는 것보다 훨씬 더 구조화된 정보를 받았다. 하니스는 지도, 파티 정보, 배틀 상황, 인벤토리, 화면 텍스트를 위해 메모리를 읽었다. 그리고 그 상태를 유용한 정보가 첨부된 명시적 선택지로 변환했다.

내비게이션에서는 일반 코드가 충돌 확인과 A 경로 탐색을 수행했다. A는 정해진 목적지까지의 경로를 계산하는 알고리즘이다. Jev는 지도에서 개별 방향 버튼을 누르는 모든 순간을 결정하지 않았다. 더 높은 수준의 목표를 선택했고, 결정론적 소프트웨어가 물리적 실행의 상당 부분을 처리했다.

하니스에는 다음 목표와 그 위치를 설명하는 스토리 마일스톤도 포함됐다. 진행 상황은 게임의 실제 이벤트 플래그에 따라 검증됐다. 이를 통해 에이전트는 스토리 내 현재 위치를 구조적으로 파악할 수 있었지만, 숨겨진 아이템은 계속 감춰져 있었다.

루프 방지 기능도 한 층을 더했다. 이전에 시도한 선택지가 아무런 변화를 만들지 못했을 경우 경고를 받을 수 있었다. 반복된 실패는 대체 선택을 촉발할 수 있었다. 시스템은 결국 가장 최근의 마일스톤 체크포인트를 다시 불러올 수도 있었다.

이러한 개입이 플레이의 가치를 무효화하는 것은 아니다. 실용적인 모든 AI 에이전트는 주변 소프트웨어, 메모리, 도구, 복구 로직에 의존한다. 다만 관련된 성취는 하나의 모델과 카트리지 간의 순수한 대결이 아니라, 잘 설계된 에이전트 아키텍처라는 뜻이다.

가장 타당한 결론은 제한적이다. 목적에 맞춰 구축된 환경 및 결정론적 제어와 결합된 의사결정 모델이 수천 번의 연속적 선택을 요구하는 긴 게임을 완료했다. 이 실험은 Jev가 픽셀 입력, 제한 없는 행동 공간 또는 외부 상태 관리 없이 어떤 성능을 보일지는 보여주지 않는다.

Pokémon이 계속해서 AI 에이전트의 약점을 드러내는 이유

Pokémon은 개별 턴 수준에서는 단순해 보이지만, 길게 이어지는 상호의존적 의사결정 사슬은 취약한 기억력과 부실한 복구 능력을 가차 없이 드러낸다.

오리지널 Pokémon Red는 턴제이며 시각적 요소가 제한적이고, 빠른 액션 게임과 비교하면 관대하다. 그럼에도 에이전트는 여러 시간에 걸쳐 목표를 유지해야 한다. 플레이어는 지도를 탐험하고, 대화를 읽으며, 파티를 구성하고, 자원을 관리하고, 이후 진행을 막는 장애물이 무엇인지 기억해야 한다.

한 번의 잘못된 배틀 선택이 게임 전체를 끝내는 경우는 드물다. 하지만 반복되는 작은 실수는 아이템을 소진시키고, 파티를 약화시키거나, 플레이어를 회복 센터로 되돌려 보낼 수 있다. 에이전트는 국지적으로 매력적인 행동이 장기 계획을 해칠 수 있음을 알아차려야 한다.

이러한 조합은 Pokémon을 범용 AI 모델의 공개 시험대로 만들었다. 2025년 2월, Anthropic은 Claude 3.7 Sonnet에 메모리, 스크린샷, 버튼 입력 도구를 제공했다. 해당 확장 사고 연구는 수만 번의 상호작용에 걸친 게임 플레이를 설명했다.

이 실험은 다듬어진 챗봇 대화가 흔히 감추는 약점을 드러냈다. 모델은 위치를 놓치거나, 실패한 경로를 반복하거나, 낡은 계획에 집착하면서도 일관성 있어 보이는 말을 할 수 있다. 게임에서는 모든 결정이 지속되는 환경을 변화시키므로 이러한 오류가 눈에 보인다.

이후 다른 개발자들은 Gemini, GPT, 최신 Claude 모델을 중심으로 구축한 시스템을 스트리밍했다. 일부는 결국 Pokémon 게임을 완료했지만, 비교는 여전히 어려웠다. 각 프로젝트는 서로 다른 정보를 노출했고, 서로 다른 메모리 시스템을 사용했으며, 서로 다른 형태의 개발자 지원을 허용했다.

2026년 1월의 게임 에이전트 분석은 선도 모델들이 이 플레이 도중 느리고, 혼란스러우며, 과신하는 경향이 있다고 설명했다. 이 비판은 Pokémon보다 더 넓은 문제를 짚었다. 범용 모델은 환경에 대한 내부 그림이 불완전해도 설득력 있는 논리를 만들어낼 수 있다.

Jev는 다른 접근법을 취한다. TypeSafe AI는 이를 System One 모델로 설명하며, 이는 긴 텍스트 생성보다 빠르고 제한된 판단에 최적화됐다는 뜻이다. 컨텍스트와 집중된 질문을 받아 선택, 점수 또는 예·아니오 확률을 반환한다.

회사는 이러한 출력을 일반 소프트웨어 내부의 구성 요소로 위치시킨다. Jev 소개는 분류, 라우팅, 점수화, 분기를 강조한다. Jev를 LLM의 모든 기능을 대체하는 존재로 제시하지는 않는다.

개발자가 게임을 재구성하면 이처럼 좁은 역할은 Pokémon에 놀랄 만큼 잘 맞는다. 대부분의 순간에 플레이어는 에세이를 쓰거나 제한 없는 계획을 발명하지 않는다. 공격을 선택하고, 목적지를 정하고, 아이템을 사거나, 훈련 여부를 결정한다.

과제는 올바른 선택지 집합을 만들고 적절한 정보를 붙이는 데 있다. 모델이 관련된 모든 선택지를 본다면, 빠른 의사결정 엔진은 게임을 계속 진행시킬 수 있다. 하니스가 중요한 사실을 숨긴다면, 속도는 에이전트가 잘못된 판단을 더 빨리 반복하도록 도울 뿐이다.

이 때문에 Jev의 결과는 챗 모델만으로 에이전트를 구축하는 팀에 압박을 가한다. 많은 반복적 에이전트 단계에는 비싸고 제한 없는 응답이 필요하지 않다는 점을 시사한다. 특화 모델은 준비된 의사결정을 처리하고, 일반 코드는 정확한 계산과 실행을 담당할 수 있다.

또한 하나의 대형 모델이 하나의 연속적인 대화 안에서 지각, 기억, 계획, 판단, 제어를 모두 수행해야 한다는 생각에도 도전한다. Pokémon 플레이는 이러한 책임을 뚜렷한 구성 요소로 나눈다. 이 분리가 이 실험의 가장 중요한 기여로 보인다.

Jev 대 챗봇은 잘못된 대결 구도다

의미 있는 대결은 단일형 AI와 각 작업을 가장 적합한 구성 요소에 맡기는 분할형 시스템 사이의 대결이다.

챗봇은 제한 없는 프롬프트를 받아 언어를 생성한다. 이 유연성은 낯선 상황을 설명하고, 계획을 작성하고, 모호한 지시를 해석하고, 대화를 통해 복구할 수 있게 한다. 같은 유연성은 소프트웨어가 단 하나의 선택만 필요로 할 때 불필요한 지연과 신뢰하기 어려운 형식을 만들 수 있다.

Jev는 새로운 전략 문서를 작성하거나 화면을 자유롭게 설명할 수 없다. 애플리케이션이 제공한 질문과 선택지로부터 타입이 지정된 판단을 반환한다. 이러한 제약은 코드가 출력을 더 쉽게 소비하도록 만든다.

Pokémon 시스템에서 역할 분담은 명시적이었다. 에뮬레이터는 기계 판독 가능한 상태를 생성했다. 하니스는 그 상태를 변환하고, 경로를 계산하고, 배틀 결과를 추정하며, 가능한 대안을 준비했다. Jev는 경직된 규칙으로 다루기 어색한 영역에서 판단을 제공했다.

이 아키텍처는 챗봇 데모보다 성숙한 프로덕션 워크플로에 더 가깝다. 신뢰할 수 있는 시스템은 흔히 결정론적 작업과 확률적 작업을 분리한다. 코드는 산술을 계산하고, 권한을 강제하며, 스키마를 검증해야 한다. 모델은 고정 규칙으로 깔끔하게 해결할 수 없는 모호성을 다뤄야 한다.

이 플레이는 외부화된 메모리의 가치도 보여준다. 하니스가 매 의사결정마다 현재 상태 설명을 다시 구축했기 때문에 Jev는 계속 길어지는 대화 기록이 필요하지 않았다. 관련 이력은 애플리케이션이 저장하고 필요할 때 삽입해야 했다.

이 설계는 긴 컨텍스트가 오래된 계획으로 어수선해질 위험을 낮춘다. 또한 개발자에게 어떤 사실이 중요한지 결정하도록 강제한다. 이러한 명확성은 신뢰성을 높일 수 있지만, 상당한 책임을 모델에서 시스템 설계자로 옮긴다.

범용 챗봇은 그러한 작업의 상당 부분을 감춘다. 개발자는 스크린샷을 전달하고, 광범위한 목표를 제공하며, 다음에 무엇을 할지 모델에 물을 수 있다. 인터페이스는 단순해 보이지만, 모델은 지각, 해석, 계획, 응답 생성을 모두 떠안는다.

겉보기의 단순함에는 연산 외의 비용도 따른다. 무언가 실패했을 때 개발자는 문제가 비전, 메모리, 추론, 도구 선택, 불명확한 지시 중 어디에서 비롯됐는지 파악해야 한다. 긴 자연어 응답이 단서를 제공할 수는 있지만, 정확한 진단을 보장하지는 않는다.

타입이 지정된 의사결정 파이프라인은 다른 증거를 노출한다. Jev 프로젝트는 각 호출의 전체 상태, 선택지, 확률, 지연 시간을 기록했다. 개발자는 어떤 선택이 가능했는지와 모델이 불확실성을 표현했는지를 확인할 수 있었다.

이러한 로깅은 에이전트 실패를 더 구체적인 엔지니어링 질문으로 바꾼다. 충분한 컨텍스트에도 모델이 잘못 선택했는가? 하니스가 필요한 선택지를 누락했는가? 올바른 고수준 결정이 나쁜 버튼 입력 순서가 됐는가? 각각의 답은 서로 다른 수정을 시사한다.

이것이 의사결정 모델이 언제나 승리한다는 의미는 아니다. 제한 없는 환경은 개발자가 예상하지 못한 사건을 일상적으로 도입한다. 제한된 선택지 모델은 애플리케이션이 한 번도 제공하지 않은 행동을 선택할 수 없다.

챗봇은 때로 낯선 상황에 대한 복구 계획을 발명할 수 있다. 비정상적인 텍스트를 해석하고, 현재 도구가 불충분한 이유를 설명하거나, 새로운 작업 순서를 제안할 수 있다. Jev의 더 좁은 인터페이스는 다른 구성 요소가 그 작업을 수행하는 데 의존한다.

따라서 Jev 대 LLM이라는 구도는 실제로 성공한 아키텍처를 가립니다. 완성된 실행은 빠른 의사결정 모델, 상세한 상태 변환기, 경로 탐색 코드, 체크포인트, 루프 방지 장치, 그리고 개발 과정에서 사용된 프런티어 모델을 결합했습니다.

이 스택은 대규모 언어 모델을 제거하지 않았습니다. 대신 그중 하나를 감독 역할로 옮겼습니다.

Claude Opus 5는 막다른 길에서 시스템을 코칭했다

Claude의 개입은 이 결과를 단순한 모델 이변이 아니라 2계층 AI 아키텍처의 증거로 바꿉니다.

Google News를 통해 보도된 개발자 설명에 따르면, Claude Opus 5는 로그를 모니터링하고 Jev에 제공되는 선택지와 문구를 조정하는 데 도움을 주었습니다. 이 작업은 의사결정 모델이 막다른 길에 도달했을 때 특히 중요해졌다고 전해집니다.

이 개입은 매 게임 턴마다 Claude가 행동을 선택하는 방식이 아니라 개발 과정에서의 변경을 통해 이뤄진 것으로 보입니다. 이러한 구분은 기록된 의사결정을 내린 Jev의 역할을 유지합니다. 그럼에도 챗봇이 실패한 곳에서 비LLM 시스템이 독립적으로 성공했다는 주장에는 복잡한 요소를 더합니다.

모델은 자신이 전달받은 세계 안에서만 잘 선택할 수 있습니다. 예를 들어 프롬프트가 필요한 아이템을 식별하지 못해 에이전트가 막힌 길을 반복해서 향한다고 가정해 봅시다. 이용 가능한 선택지를 다시 표현하면 도움이 될 수 있지만, 더 근본적인 해결책은 누락된 상태 정보를 추가하는 것입니다.

프런티어 모델은 이런 실패를 검토하는 데 적합합니다. 긴 궤적을 읽고, 반복된 시도를 비교하며, 어떤 사실이 빠졌는지 추론하고, 하네스 변경을 제안할 수 있습니다. 이는 진단과 새로운 텍스트 생성을 포함하는 개방형 작업으로, 바로 Jev가 수행하도록 설계되지 않은 업무입니다.

그 결과의 구성은 빠른 사고와 느린 사고의 구분을 닮았습니다. Jev는 빈번하고 범위가 제한된 판단을 처리합니다. Claude는 시스템이 비정상적으로 작동하거나 설계자가 표현하지 못한 상황을 만날 때, 덜 빈번한 분석을 수행합니다.

이는 Jev의 한계 때문에 강요된 타협만은 아닙니다. 유용한 프로덕션 패턴일 수도 있습니다. 대부분의 소프트웨어 이벤트는 일상적이지만, 일부는 더 깊은 해석을 요구합니다. 모든 이벤트를 가장 강력한 모델로 처리하면 자원을 낭비하고 추가 지연을 유발할 수 있습니다.

대신 감독 모델은 불확실한 사례를 분석하고, 실패 사례 묶음을 검토하거나, 의사결정 정책을 다시 작성할 수 있습니다. 이후 이러한 개선은 더 빠른 구성 요소가 수행하는 수천 건의 후속 호출에 도움이 될 수 있습니다.

그러나 연구자들이 이 실행을 깔끔한 비교로 간주하기 위해서는 코칭 과정에 대한 더 엄격한 문서화가 필요합니다. 공개 요약에는 최종 하네스를 사용한 통제된 Jev 단독 기준선이 제시되지 않았습니다. 또한 Claude가 시스템을 변경한 빈도나 각 변경 뒤에 어느 정도의 진전이 있었는지도 정량화하지 않았습니다.

저장소의 이력에는 수백 건의 커밋이 있어, 원칙적으로는 진화 과정을 검토할 수 있습니다. 그러나 개발 커밋의 연속이 곧 실험 프로토콜은 아닙니다. 적절한 비교를 위해서는 환경을 고정하고, 개입 규칙을 정의하며, 통제된 시드로 여러 차례 시험해야 합니다.

또 다른 모호성의 원천도 있습니다. 모든 에이전트 벤치마크에는 스캐폴딩이 포함되지만, 스캐폴딩에는 상당한 작업 지식이 담길 수 있습니다. Jev 하네스는 스토리 이정표와 위치를 알고 있었고, 경로를 계산했으며, 피해량을 추정하고, 허용되는 행동을 준비했습니다.

스크린샷과 광범위한 버튼 도구만 제공받는 챗봇 실행은 다른 문제에 직면합니다. 더 많은 지각과 계획을 모델 내부에서 수행해야 합니다. 이러한 인터페이스를 맞추지 않은 채 완료 시간을 비교하면, 하네스가 제공한 이점을 모델의 공으로 돌릴 위험이 있습니다.

공정한 해석은 폄하도 승리 선언도 아닙니다. Jev는 결국 게임을 완료한 시스템 안에서 수천 건의 중요한 선택을 했습니다. Claude는 엔지니어들이 그 시스템을 개선하는 데 도움을 주었습니다. 이들은 함께 여러 유명 챗봇 시연보다 더 빠른 결과를 냈지만, 동일한 시험을 수행한 것은 아닙니다.

이 결과가 증명하지 못하는 것

한 번의 성공적인 플레이스루만으로 의사결정 모델이 일반적으로 LLM 에이전트보다 더 똑똑하고, 자율적이며, 신뢰할 수 있다는 점을 입증할 수는 없습니다.

가장 큰 불확실성은 재현성입니다. 공개된 결과는 주변 시스템을 적극적으로 개발한 뒤 완료된 한 번의 실행을 설명합니다. Pokémon에는 무작위 조우, 불확실한 전투 결과, 그리고 다양한 팀 구성 가능성이 있습니다.

두 번째 실행은 다른 경로를 따르거나 다른 장소에서 멈출 수 있습니다. 실험을 반복하면 시스템이 게임을 안정적으로 완료하는지, 아니면 유리한 궤적의 혜택을 받았는지를 확인할 수 있습니다.

이 설정에는 조건이 맞춰진 경쟁자도 없습니다. Jev와 Claude를 공정하게 비교하려면 두 모델 모두 동일한 상태 표현, 선택지, 결정론적 내비게이션, 복구 규칙, 체크포인트를 사용해야 합니다. 그렇지 않으면 벤치마크는 모델과 소프트웨어의 서로 다른 두 조합을 측정하게 됩니다.

유용한 실험은 세 가지 구성을 실행할 것입니다. 하나는 고정된 하네스에서 Jev를 사용합니다. 다른 하나는 다른 모든 구성 요소를 유지하면서 Jev를 범용 모델로 대체합니다. 세 번째는 감독자가 선택된 실패 사례를 검토하는 하이브리드 시스템을 사용합니다.

연구자들은 이후 반복 시험 전반에서 완료율, 의사결정 수, 개입 횟수, 실제 경과 시간, 복구 동작을 비교할 수 있습니다. 이러한 측정은 특화 모델이 도움이 되는 지점과 프런티어 모델이 여전히 필요한 지점을 보여줄 것입니다.

개발자가 메모리 검사를 사용했다는 점도 더 넓은 결론에는 한계를 둡니다. 구조화된 게임 상태를 읽으면 시각적 지각 문제가 제거됩니다. 의사결정을 시험하기에는 합리적인 선택이지만, Jev가 복잡한 시각 환경에서 직접 작동할 수 있음을 입증하지는 않습니다.

실제 애플리케이션은 완벽한 허용 선택지 목록을 제공하는 경우가 드뭅니다. 지원 라우터는 알려진 모든 범주 밖의 새 이슈를 받을 수 있습니다. 브라우저 에이전트는 새로 디자인된 페이지를 마주할 수 있습니다. 물리적 로봇은 계획기가 한 번도 표현하지 못한 물체를 관찰할 수 있습니다.

범위가 제한된 모델에는 이런 사례를 위한 안전한 탈출 경로가 필요합니다. 신뢰도 임계값은 불확실한 결정을 사람이나 범용 모델로 넘길 수 있습니다. 애플리케이션에는 올바른 선택 자체가 완전히 빠진 경우를 감지하는 방법도 필요합니다.

확률만으로는 이 문제를 해결할 수 없습니다. 사용할 수 있는 모든 선택지가 틀렸기 때문에, 모델은 나쁜 대안들 사이에서 높은 신뢰도를 보일 수 있습니다. 개발자는 행동 집합을 검증하고 후속 결과를 모니터링해야 합니다.

Jev의 루프 방지 장치는 그러한 안전장치의 필요성을 보여줍니다. 하네스는 효과가 없었던 선택에 태그를 붙이고, 반복 실패 뒤에는 대안을 샘플링했으며, 최후의 수단으로 체크포인트를 복원했습니다. 이러한 메커니즘은 하나의 잘못된 판단이 시스템을 영원히 가두는 것을 방지했습니다.

이는 또한 완료가 매 단계에서 순수하게 올바른 선택을 한 결과만은 아니었음을 의미합니다. 시스템은 오류를 허용하고 복구했습니다. 프로덕션 AI에도 같은 품질이 필요하지만, 비즈니스 워크플로에는 피해를 되돌릴 수 있는 편리한 체크포인트가 없는 경우가 많습니다.

잘못된 게임 행동은 몇 분을 잃게 할 수 있습니다. 잘못된 삭제, 결제 또는 고객 응답은 오래 지속되는 결과를 낳을 수 있습니다. Jev 스타일 아키텍처를 고려하는 개발자는 어떤 의사결정이 되돌릴 수 있고 어떤 의사결정에 승인이 필요한지 정의해야 합니다.

이 실험은 보안에 대해서도 거의 말해주지 않습니다. 외부 출처의 텍스트를 소비하는 모델은 조작적인 지시나 오해를 부르는 맥락을 접할 수 있습니다. 출력을 유형화된 선택지로 제한하면 행동 표면은 좁아지지만, 올바른 해석을 보장하지는 않습니다.

마지막으로 Pokémon Red는 알려져 있고 안정적인 환경입니다. 지도, 전투 메커니즘, 메뉴, 스토리 구조는 실행 중에 바뀌지 않습니다. 이러한 안정성 덕분에 엔지니어는 유난히 상세한 상태 변환기를 구축할 수 있습니다.

많은 엔터프라이즈 환경은 계속 변합니다. 문서는 새로운 형식으로 들어오고, 정책은 바뀌며, 도구는 불완전한 데이터를 반환합니다. 환경의 변동성이 클수록 하네스에 더 많은 유지보수가 필요합니다.

따라서 이 실행은 보편적 순위가 아니라 설계 가설을 뒷받침합니다. 행동이 제한되고, 맥락을 구조화할 수 있으며, 결정론적 소프트웨어가 결과를 실행할 수 있을 때 특화 의사결정 모델은 유망해 보입니다. 시스템이 새로운 것을 해석하고, 계획을 생성하거나, 자신의 표현을 수정해야 할 때는 범용 모델이 여전히 가치 있습니다.

Jev 결과의 중요성을 보여줄 세 가지 신호

다음 시험은 이 아키텍처가 반복, 조건이 맞춰진 비교, 그리고 이를 위해 세심하게 준비되지 않은 환경에서도 살아남는지 여부입니다.

첫째, 고정된 버전의 하네스를 사용한 재현 가능한 Pokémon 실행을 지켜봐야 합니다. 여러 번의 무인 완료는 시스템이 신뢰할 수 있는 의사결정 루프를 구현한다는 주장을 강화할 것입니다. 공개된 실패 사례도 마찬가지로 가치가 있습니다. 상태 표현의 어느 부분이 여전히 취약한지 드러내기 때문입니다.

가장 유용한 공개 자료에는 전체 궤적, 고정된 모델 버전, 개입 로그, 명확한 완료 정의가 포함될 것입니다. 실행 사이에 이뤄진 사람의 변경과 자동 복구를 구분해야 합니다. 이 구분이 없으면 개발자는 개선이 모델에서 비롯된 것인지, 지속적인 엔지니어링 작업에서 비롯된 것인지 알 수 없습니다.

둘째, 조건이 맞춰진 Jev 대 LLM 시험을 찾아야 합니다. 두 시스템은 동일한 상태, 선택지, 내비게이션 코드, 체크포인트 규칙을 받아야 합니다. 그래야 현재의 아키텍처 대비가 측정 가능한 모델 비교로 바뀔 수 있습니다.

조건이 맞춰진 시험은 LLM이 비슷한 성능을 보이지만 더 느리게 반응한다는 결과를 낼 수 있습니다. Jev가 일상적인 선택에는 뛰어나지만 드문 상황에서는 뒤처진다는 결과도 가능할 것입니다. 또는 상세한 하네스가 어느 모델이든 지능 부담의 대부분을 덜어준다는 사실을 드러낼 수도 있습니다.

셋째, 객관적인 결과 라벨이 있는 게임 외부 애플리케이션을 지켜봐야 합니다. 티켓 라우팅, 모더레이션 대기열, 문서 분류, 도구 선택, 알림 우선순위 지정은 그럴듯한 후보입니다. 이러한 워크플로는 팀이 이후 결과를 기준으로 감사할 수 있는 반복적인 의사결정을 만들어냅니다.

가장 강력한 증거는 눈에 띄는 시연이 아닐 것입니다. 변화하는 입력에서도 안정적인 정확도, 명확한 보정, 낮은 예외율, 그리고 준비된 선택지 중 어느 것도 맞지 않을 때의 안전한 에스컬레이션일 것입니다.

개발자에게 당장의 교훈은 실용적입니다. 채팅 인터페이스가 그런 구성을 쉽게 만든다고 해서 하나의 모델에게 모든 인지 기능을 수행하도록 요구하지 마십시오. 지각, 상태, 판단, 실행, 메모리, 복구를 분리한 뒤 각 경계를 평가하십시오.

팀은 모든 의사결정의 근거가 되는 소스 자료를 보존함으로써 같은 아이디어를 자체 AI 워크플로에 적용할 수 있습니다. 검색 가능한 엔지니어링 지식 베이스는 검토자가 모델 동작을 사양, 로그, 이전 수정 사항과 연결하는 데 도움이 될 수 있습니다.

Jev Pokémon Red 실험이 중요한 이유는 아키텍처를 보이게 만들기 때문입니다. 집중된 모델이 수천 건의 선택을 처리했고, 일반 소프트웨어가 정확한 작업을 수행했으며, Claude는 표현이 실패했을 때 시스템 재설계를 도왔다고 전해집니다.

이는 LLM에 대한 명확한 승리가 아닙니다. LLM을 덜 자주, 더 의도적으로 사용해야 한다는 근거입니다.

다음 질문은 개발자가 수개월에 걸친 작업 특화 조정 없이 이 분업을 재현할 수 있는지입니다. 독립 팀이 하네스를 고정하고, 실행을 반복하며, 이 패턴을 실제 워크플로로 옮길 수 있다면 Jev는 Pokémon Red를 끝내는 이례적인 방식보다 더 큰 무언가를 보여주게 될 것입니다.