Nanojev가 200줄의 최소 Jev 스타일 의사결정 모델을 구현함

Nanojev의 가장 큰 의미는 폐쇄형 의사결정 모델을 완전히 복제했다는 데 있지 않고, 상태 인코딩·질문별 격리·확률 출력·보정이라는 핵심 동작을 작은 코드로 재현했다는 데 있다고 봅니다. 약 200줄의 구현과 Qwen3.5-4B-Base, LoRA, 포인터 헤드를 결합해 실제로 동작하는 시스템을 만들었다는 점은 상당히 인상적입니다. 다만 현재 결과만으로 TypeSafe의 System One과 같은 판단 구조를 만들었다고 말하기에는 검증의 빈틈이 큽니다.

수치가 보여주는 성능은 분명 준수합니다. 6,191개 학습 요청과 1,000개 평가 요청을 사용했고, 두 번째 에포크에서 정확도 0.907을 기록했으며, 학습에 포함되지 않은 도메인에서도 정확도 0.910을 기록했습니다. 그러나 여기에는 평가 단위의 불명확성이 남습니다. 평가 요청은 1,000개인데 평가 질문은 2,344개로 제시되어 있어, 요청과 질문이 어떤 방식으로 집계됐는지 독자가 확인하기 어렵습니다. 55개 도메인 중 5개만 미학습 영역이라는 사실도 일반화의 강한 증거라기보다, 데이터 구성과 도메인 간 유사성을 더 공개해야 해석할 수 있는 결과에 가깝습니다.

특히 질문 유형별 성능 차이는 이 모델의 본질을 드러냅니다. 예·아니오 유형인 noul은 0.956, 선택형은 0.933이지만 순서형 점수는 0.787에 그쳤습니다. 즉 Nanojev는 정교한 연속 판단을 수행한다기보다, 구조가 명확한 분류 문제에서 강한 모델일 가능성이 큽니다. 그렇다면 이를 범용 의사결정 모델이라고 부르기보다는 유형이 지정된 판단 인터페이스라고 설명하는 편이 정확합니다. 이 차이를 숨기면 사용자는 숫자 하나를 근거로 모델의 판단 능력을 과대평가하게 됩니다.

구조적 격리는 실용적인 장점입니다. 상태를 한 번 인코딩한 뒤 질문마다 캐시 복사본을 사용하고, 한 상태에 대한 20개 질문 처리 시간이 포크 방식에서 160ms, 행 단위 처리에서 1.9초였다는 결과는 서버 설계 관점에서 설득력이 있습니다. 형제 질문에 심은 비밀의 확률이 0.001이고 상태 자체의 비밀은 0.999로 발견됐다는 실험도 의도한 정보 흐름을 잘 보여줍니다. 하지만 이것은 보안 보장이 아니라 제한된 프롬프트 격리 테스트입니다. 실제 환경에서는 상태 표현에 남은 간접 단서, 공통 어휘의 상관관계, 캐시 재사용 과정의 구현 오류까지 시험해야 하며, 현재 실험만으로 비밀 누출이 방지된다고 단정하기는 어렵습니다.

보정 결과는 오히려 이 프로젝트의 중요한 교훈입니다. 두 번째 에포크는 정확도를 0.895에서 0.907로 높였지만 NLL은 0.257에서 0.333으로, ECE는 0.013에서 0.054로 악화됐습니다. 온도 T=1.97을 적용한 뒤 정확도는 유지되고 NLL은 0.246, ECE는 0.022가 됐습니다. 이는 정답률과 신뢰도는 다른 품질이라는 사실을 분명히 보여줍니다. 온도 보정은 답변 자체를 개선한 것이 아니라 확률 표현을 덜 과장되게 만든 것입니다. 실제 의사결정에 쓰려면 이 보정을 새로운 도메인과 시간 변화 뒤에도 다시 검증해야 합니다.

가장 뼈아픈 단서는 레퍼런스 카드가 마지막 옵션일 때 실패했다는 결과입니다. 옵션의 의미가 아니라 위치나 종료 토큰의 패턴에 의존한다면, 포인터 헤드와 리스트 단위 구조는 효율적인 동시에 취약한 휴리스틱이 됩니다. 옵션 순서를 무작위로 바꾸거나, 동의어와 길이가 다른 문장을 넣거나, 선택지 수를 변화시키는 순열 불변성 테스트가 반드시 필요합니다. 이 검사를 통과하지 못하면 0.907이라는 평균 정확도는 모델의 판단력보다 데이터 형식에 대한 적응력을 반영할 가능성이 큽니다.

그래서 Nanojev는 실패한 복제품이 아니라, 다음 검증을 촉구하는 훌륭한 최소 실험으로 평가하고 싶습니다. 데이터 생성 과정과 중복 여부, 요청·질문 단위의 정의, 모든 시드와 도메인별 분산, 옵션 순서에 대한 민감도를 공개한다면 재현성이 크게 높아질 겁니다. 앞으로는 이 시스템이 폐쇄형 Jev를 닮았다는 주장보다, 빠르고 격리된 확률형 의사결정 모듈로서 어떤 조건에서 신뢰할 수 있는지를 입증하는 방향으로 흘러가야 합니다. 지금 필요한 것은 더 짧은 코드가 아니라 더 कठ한 반례와 더 정직한 평가입니다.