AI에게 "지난주 거래처 미팅 일정 정리해줘"라고 시킨다. AI는 쓸 수 있는 도구 목록 — 캘린더 조회, CRM 조회, 메일 검색, 문서 생성 — 가운데 하나를 골라 일을 시작한다. 그런데 이 네 줄을 프롬프트에 어떤 순서로 적느냐에 따라, 똑같은 요청인데도 어제는 캘린더를, 오늘은 메일 검색을 부른다. 요청도 도구도 그대로다. 달라진 건 줄을 적은 순서뿐이다.
여기서 다룰 대상은 긴 설명을 들려주는 업무가 아니다. 보기 가운데 하나를 빠르게 고르고, 조건이 참인지 판정하고, 점수를 매기는 — 선택과 판정이 핵심인 업무다. 논문은 근거를 길게 펼치지 않고 결과만 즉시 내놓는 이런 모델을 '시스템 1 모델'이라 부른다. 사람이 직관으로 순식간에 판단하는 사고에 빗댄 이름이다. 그리고 바로 그 즉답의 순간에, 위 장면처럼 순서 같은 사소한 것이 답을 흔든다. 싱가포르국립대(NUS) 연구팀의 Jeva는 그 흔들림을 구조에서 없애려는 시도다.
요즘 공개된 시스템 1 모델은 대개 이렇게 작동한다. 요청과 후보(보기)를 한 덩어리 글로 이어 붙여 언어모델에 넣고, 모델이 각 보기에 매긴 점수나 전용 출력 장치에서 답을 읽는다. 여기서 '점수'는 로짓, 즉 확률로 바꾸기 전의 원점수를 말한다. 방법은 간편하다. 문제는 '결정'이라는 일의 성격과 잘 안 맞는다는 데 있다.
논문은 결정 문제가 암묵적으로 요구하는 네 가지 성질을 한자리에 정리한다.
네 성질은 겉으로는 따로 노는 요구처럼 보이지만, 뿌리는 하나다. 의미를 표현하는 일, 후보끼리 견주는 일, 답이 존재하는지 판정하는 일이 전부 같은 예측 과정 안에 뒤엉켜 있다는 것. Jeva의 설계는 이 셋을 떼어 놓는 데서 출발한다.
먼저 하나의 공유 인코더가 요청과 각 보기를 따로따로 벡터로 만든다. 벡터란 텍스트의 특징을 담은 숫자 묶음이다. 이때 보기를 벡터로 만들 때는 현재 질문도, 진행 상태도, 다른 보기도, 보기 번호도 넣지 않는다. 그래서 한 보기의 표현은 요청이 무엇이든 늘 똑같이 고정된다. 바로 이 고정이 캐시의 전제다. 손님이 누구든 메뉴판은 한 번만 찍어 두고 계속 쓰는 식당을 떠올리면 된다. 매번 새로 인쇄할 이유가 없다.
보기 표현을 고정했으니, 보기마다 따로 점수를 매겨 끝내면 될 것 같다. 하지만 그러면 보기끼리 견주는 과정이 사라진다. Jeva는 가벼운 '결정 블록'을 둬서, 고정된 보기들을 훑어 읽으며 '요청 쪽 상태'만 조금씩 다듬는다. 요청 상태란 후보들을 살펴보며 갱신해 가는, 요청의 내부 표현이다.
왜 이 다듬기가 중요한지는 두 장면을 비교하면 또렷해진다. 라우터가 쓸 수 있는 도구가 A(메일 검색)와 B(범용 문서 생성)뿐이고, "지난 미팅 회의록 정리" 요청이 들어왔다고 하자. 둘 중에는 B가 낫다. 여기서 두 가지가 벌어질 수 있다. 하나, A와 B는 그대로 두고 프롬프트에 적은 순서만 뒤섞는 경우 — 판단은 바뀌면 안 된다. 둘, C(회의록 전용 요약 도구)를 실제로 새로 연동하는 경우 — 이때는 이야기가 다르다. C가 들어오면 "이 요청을 누가 맡나"를 보는 기준 자체가 '회의록을 다룰 수 있나'로 옮겨 가고, 그 축에서는 A와 B의 우열마저 다시 따져야 할 수 있다. 후보 집합 전체가 달라졌기 때문이다.
보기를 완전히 독립적으로 채점하면 두 번째가 불가능하다. 다른 보기를 넣고 빼도 두 보기의 상대적 우열은 절대 바뀌지 않는다. Jeva는 요청 상태를 '지금의 후보 집합 전체'에 맞춰 조정하기 때문에, 순서만 바뀌면 판단을 지키고 집합이 바뀌면 우열을 다시 따진다.
순서 불변은 집계 방식으로 지킨다. 결정 블록이 보기들을 모을 때 순서에 영향받지 않는 대칭 집계를 써서, 보기를 섞으면 결과 확률도 같이 섞일 뿐 값은 변하지 않는다. 또 모든 보기를 같은 채점 방식으로 처리하니, 보기 수가 늘어도 출력 쪽을 키울 필요가 없다.
'해당 없음'은 아예 별도 장치로 뗀다. 보기끼리의 상대적 우열만으로는 "그래서 받아들일 만한 보기가 하나라도 있느냐"에 답할 수 없다. 모든 점수에 같은 값을 더해도 보기 간 경쟁 구도는 그대로지만, '정답이 있느냐 없느냐'는 달라져야 하기 때문이다. Jeva는 학습으로 정한 문턱값과 온도를 쓰는 '커버리지 게이트'로, 먼저 '없음'과 '후보 집합' 사이에 확률을 나눈 뒤 그 안에서 보기 간 경쟁을 푼다. 온도는 확률분포를 얼마나 뾰족하게 혹은 평평하게 만들지 조절하는 값이다. 이렇게 떼어 놓은 한 구조가 고르기(Choice), 검증(Noul), 점수 매기기(Score) 세 출력을 모두 담당한다.
이 문제를 푸는 흐름은 크게 둘이다. 하나는 요청과 후보를 함께 글로 인코딩해 답 토큰이나 결정 마커에서 읽는 계열, 다른 하나는 질의와 후보를 따로 인코딩해 재사용과 효율을 얻는 계열이다. Jeva의 자리는 그 사이다. 보기는 따로 인코딩해 재사용하되, 채점 전에 요청 상태를 후보 집합 전체에 맞춰 먼저 조정한다. 세 축으로 보면 차이가 선명하다.
| 접근 | 대표 모델 | 후보 재사용 | 집합 상호작용 | '없음' 분리 |
|---|---|---|---|---|
| 함께 인코딩 | SemIf·JevK5·InternDecision·Re·Flex·KEV·Laya | 못 함 | 함 | 제한적 |
| 따로 인코딩 | DPR·ColBERT·CLM | 함 | 못 함 | 안 다룸 |
| Jeva | — | 함 | 함 | 커버리지 게이트로 분리 |
첫 계열이 포기한 재사용을, 둘째 계열이 놓친 집합 상호작용을 Jeva가 각각 메우는 셈이다. 집합을 순서 없이 다루는 신경망 계열(Deep Sets·Set Transformer·Perceiver)의 대칭 집계 아이디어와도 닿아 있다. '없음' 처리는 답변 가능성을 묻는 SQuAD 2.0 같은 과제와 문제의식이 겹치지만, Jeva는 '없음'을 '유효한 후보의 부재'로 못 박고 불확실함과 분리한다는 점이 다르다.
제목이 내건 약속부터 보자. 같은 Choice 600개를 원본·역순·무작위로 돌려, 보기의 정체성을 맞춰 정렬한 뒤 순서만 바꿨을 때 결정이 흔들리는지 쟀다. Jeva는 한 번도 흔들리지 않았다. 순서를 바꿔 생긴 확률분포의 차이(TV 거리, 두 분포 사이의 거리)가 평균 약 3.17e-08로 사실상 계산 오차였다. 더 눈여겨볼 건 두 숫자가 같다는 점이다. 원래 정확도와, 테스트한 모든 순서에서 전부 맞힌 비율이 똑같이 76.67%다. 순서가 결과에 아무 정보도 보태지 않았다는 뜻이다. 다만 정확히 말하면, 구조가 수학적으로 보장하는 건 정확한 산술과 고정된 가중치 아래 각 보기의 확률값 자체가 순서에 흔들리지 않는다는 것이다(그래서 TV 거리가 꼭 0이 아니라 부동소수점 오차 수준에 그친다). 최종 선택까지 그대로인 건 최고점 보기가 유일할 때이고, 점수가 맞비길 때 첫 보기를 고르는 구현이나 부동소수점 오차에서는 선택이 갈릴 수 있다(명제 3·부록 B.5). 이 실험에서는 그런 뒤집힘이 한 건도 없었다. 반면 다른 모델은 5건 중 1건꼴로 결정이 바뀌었다.
| 모델 | 뒤집힘율 | 전순서 정확도 |
|---|---|---|
| Jeva | 0.00% | 76.67% |
| Jev-1.13.0 | 17.00% | 66.67% |
| InternDecision-4B | 22.67% | 64.50% |
| JevK5 | 26.17% | 47.83% |
'없음'을 가려내는 능력도 선두였다. BANKING77에서 보기 16개, 정답이 없는 588건을 섞은 3,080건으로 쟀더니 Jeva의 AUROC(높을수록 좋음)는 98.66%로, KEV-BF16(93.61%)·InternDecision-4B(84.27%)·JevK5(79.44%)를 크게 앞섰다. 멀쩡한 보기를 '없음'이라 잘못 부르는 비율을 5.02%로 묶어 두고도, 실제 부재 정답의 93.88%를 잡아냈다. 틀린 도구를 억지로 부르느니 "할 수 없다"고 말하는 쪽이 중요한 업무라면 이 숫자가 핵심이다.
확장성은 보기를 불려 가며 봤다. ToolRet 500건에서 Jeva는 요청을 전부 처리하며 집계 정확도 78.40%를 냈고, 재귀적으로 보기를 좁혀 가는 JevK5는 64.00%에 그쳤다. 보기를 32개에서 2,048개까지 불린 83개 쿼리에서는, 모든 크기에서 계속 맞힌 쿼리가 Jeva 58개 대 JevK5 48개였고 CLM은 7개뿐이었다. InternDecision 계열은 등록 보기 한도에 걸려 큰 묶음에서는 일부 요청만 처리했다. 구조를 다시 짜지 않아도 후보가 늘어난다는 약속이 숫자로 확인된 셈이다.
재사용 속도는 후보 계산을 캐시했을 때 지연이 얼마나 주는지로 쟀다(이전 답은 캐시하지 않는다). MLDR에서 p50 지연이 2,102.0ms에서 75.1ms로 떨어졌고, 후보를 공유하는 Typed Decisions에서는 93.1ms에서 46.6ms로 줄며 후보 인코딩의 99.2%를 건너뛰었다. 그러면서도 결정은 바뀌지 않았고 확률의 최대 차이는 0.00736이었다. 다만 이 지연은 전부 H200 가속기에서 나온 값이다.
정확도 자체는 8개 슬라이스 중 7개에서 앞섰다. 유일하게 뒤진 Typed Decisions에서 한 끗 밀리고, 타입 충실도에서도 Score RMSE 하나만 근소하게 열세다. 세부는 아래 보조 표에 모았다.
| 항목 | Jeva | 비교 |
|---|---|---|
| BANKING77·MASSIVE (보기 8·16개) | 90% 이상 | — |
| Mind2Web cross-task / website / domain | 79.99% / 62.25% / 66.23% | — |
| Typed Decisions | 78.30% | InternDecision-4B 78.70% |
| Noul Brier / MAE (낮을수록 좋음) | 0.0184 / 0.0939 | 각 최저 |
| Score MAE / RMSE | 0.2315 / 0.3222 | RMSE만 InternDecision-4B 0.3208에 열세 |
이 숫자들은 서로 다른 실험의 서로 다른 지표라, 하나의 성과로 합쳐 읽으면 안 된다. 각기 다른 데이터와 조건에서 나온 값이다.
저자가 인정하는 제약은 연구의 범위를 가늠하게 해 준다. 각 텍스트는 자기 인코더의 길이 예산을 따로 갖지만, 그렇다고 개별 텍스트의 길이 한계가 사라지지는 않는다. 집합에 맞춰 상태를 조정하는 과정에서 점수가 바뀔 수 있어, 보기를 추가할 때 (후보, 없음) 전체에 대한 최종 선택이 그대로 유지된다는 보장은 없다(부록 A.3). 재사용도 공짜가 아니다. 캐시되는 건 후보 쪽 계산뿐이고 상태 인코딩과 결정 읽기는 매 요청 그대로 돈다. 그래서 보기 집합이 매번 완전히 새로워 재사용할 게 거의 없는 서비스라면 캐시 이득은 작아진다. 평가는 Qwen3.5-4B 백본에 결정 블록 하나로 고정해 보고했으니, 더 크거나 작은 백본에서 네 성질과 효율이 어떻게 달라지는지는 이 범위에서 단정할 수 없다. Jeva의 강점은 평균 정확도로 압도하는 데 있다기보다, 네 성질을 함께 보장하는 데 있다고 읽는 편이 정확하다.
온틀은 AI PM이 사람의 반복 업무를 덜어 주는 서비스다. 맨 앞 장면으로 돌아가자. 사용자가 "지난주 거래처 미팅 일정 정리해줘"라고 하면, PM은 등록된 도구·연동 목록에서 하나를 골라야 한다. 이 '어느 도구가 이 요청을 맡나'가 바로 Choice 결정이다.
토큰 점수에 기대는 라우터는 도구 목록을 적은 순서가 바뀌면 같은 요청에 다른 도구를 고를 수 있다. 다만 이건 우리가 운영에서 측정한 현상이 아니라, 그런 구조라면 나타날 수 있는 위험으로 봐야 한다. Jeva식 분리는 이 위험을 구조에서 막는다. 순서가 결과에 아예 들어가지 않기 때문이다. 반대로 새 연동을 하나 붙이는 건 순서 변경과는 다른 상황이다. 후보 집합 자체가 달라졌으니 선택이 바뀌는 게 오히려 맞고, Jeva는 이때 우열을 다시 따지도록 설계돼 있다. 두 경우를 섞지 않는 게 중요하다.
'없음'도 두 판단을 섞으면 안 된다. 하나는 '이 요청을 맡을 도구가 아예 없다'는 판단이다. 아직 연동하지 않은 외부 시스템 같은 경우다. 다른 하나는 '그 도구를 실제로 실행해도 되느냐'는 승인 판단이다. 커버리지 게이트가 맡는 건 앞쪽 — 그럴듯하지만 틀린 도구를 억지로 부르는 대신 "지금은 할 수 없다"고 명시하게 하는 일이다. 실행 승인은 온틀의 외부 발신·실행 전 승인 원칙이 따로 맡는다.
효과는 선언이 아니라 숫자로 확인할 가설로 두는 게 맞다. 같은 요청을 도구 목록 순서만 바꿔(원본·역순·무작위) 돌려 뒤집힘율과 확률 차이를 재면, 순서 민감도가 실제로 문제인지, Jeva식 분리가 그걸 없애는지 알 수 있다. 고객사마다 거의 고정인 도구·문서 목록을 캐시했을 때 결정은 그대로면서 지연이 주는지도 같은 식으로 측정한다. 연동을 계속 붙이는 제품이라면 보기가 늘어도 출력 구조를 다시 짤 필요가 없다는 점이 특히 값질 텐데, 이 역시 실측으로 확인할 몫이다.
결국 Jeva를 먼저 검토할지는 두 가지로 판가름난다. 후보가 요청마다 반복돼 재사용할 게 많은가, 그리고 '정답 없음'을 '헷갈림'과 반드시 구분해야 하는가. 둘 다 "그렇다"이고 선택지가 계속 늘어나는 업무라면 — 도구 라우팅이 딱 그렇다 — 가장 먼저 올려 볼 설계다. 반대로 라벨이 고정이고 보기마다 안정적인 점수가 필요한 업무라면, 순서 불변이나 확장성은 큰 값을 내지 못한다.
결정 블록은 고정된 보기들을 훑으며 요청 상태를 잔차 방식으로 두 번 보정한다. 잔차 업데이트란 값을 통째로 새로 쓰는 대신 기존 값에 보정량을 더해 가는 방식이다. 논문은 이 설계가 세 가지를 수학적으로 보장함을 명제로 보인다. 결정 블록이 하나뿐이어도 집합에 따라 두 보기의 우열이 뒤집힐 수 있다는 것(Proposition 1 — 독립 채점용 소프트맥스인 식 2는 분모가 약분돼 이게 불가능하다), 커버리지 게이트의 '없음' 확률이 '후보 개수로 나누는 정규화'와 다르다는 것(Proposition 2, 식 6 — 기존 후보들의 최종 점수가 고정된 경우에 한해, 기존 최댓값보다 낮은 보기를 더 넣어도 '없음' 확률이 흔들리지 않는다. 후보 수를 분모로 쓰는 평평한 소프트맥스가 후보가 늘수록 '없음'을 묽히는 것과는 다르다. 다만 실제 Jeva에서는 후보를 추가하면 요청 상태와 기존 점수가 함께 바뀌므로 '없음' 확률도 달라질 수 있다 — 부록 A.3), 그리고 순서 불변을 구조가 보장한다는 것(Proposition 3)이다. 다만 Proposition 3이 보장하는 건 출력 확률분포가 순서에 불변이라는 것이고, 최종 선택의 불변은 정확한 산술 아래 최고점 보기가 유일할 때 따라온다 — 동점을 첫 보기로 깨는 구현이나 부동소수점 오차에서는 선택이 달라질 수 있다(부록 B.5).
학습은 Qwen3.5-4B를 백본으로 삼아, 결정 블록 하나와 rank-64 LoRA로 두 투영과 결정 헤드(1337만 파라미터)만 학습했다. LoRA는 모델 전체가 아니라 작은 추가 가중치만 학습하는 경량 방식이다. 커리큘럼은 타입 결정, 의도 선택, 검증, 읽기·추론, 대규모 후보 검색 순으로 진행한다.
공개형(open-set) 평가에서 그런 모델에도 우회로를 열어 줬습니다. None 보기를 직접 주거나, '후보가 존재하는지' 묻는 보조 질문으로 후보 확률을 보정하게 한 방식입니다. 모델 내부 비교는 체크포인트와 쿼리 순서를 고정했고, 지연은 모두 H200에서 측정했습니다.
같은 구조를 해석만 달리합니다. Choice는 보기 중 하나를 고르고, Noul은 참/거짓을 검증하되 긍정 쪽 보기의 확률로 답합니다. Score는 수치 기준표(루브릭)에 대한 기댓값으로 점수를 냅니다. 어떤 기준으로 읽느냐만 다를 뿐, 인코더에 들어가는 입력이 출력마다 따로 늘지는 않습니다.
아닙니다. 서빙할 때는 LoRA를 병합해 고정하고, 그 모델로 보기 메모리를 미리 계산해 둡니다. 캐시가 겨냥하는 건 이 사전 계산한 후보 쪽이고, 이전에 내놓은 답은 캐시하지 않습니다.