# 제브가 재고하는 AI의 판단과 실행의 경계

> https://bookfactory.kr/board/news/17923
> 게시판: 뉴스
> 작성자: admin
> 작성일: 2026-09-20T14:14:54.095Z

---

![見出し画像](https://assets.st-note.com/production/uploads/images/315643047/rectangle_large_type_2_cb344d0628618963f25ef8991c1db4e7.png?width=1280)

## 확률은 실행 허가를 의미하지 않으며, 템플릿 판단을 업무에 적용하기 위해 사용된다.

AI가 “출고해도 괜찮다”라고 답했다. 그 답변은 어떤 조건을 만족했을 때, 조직으로서 실행 허가를 받는 것일까. 2026년 9월 15일, TypeSafe AI는 소프트웨어가 직접 이용 가능한 형식 판단을 반환하는 모델 “Jev”를 조기 액세스로 공개했다. 이 회사가 “System One Models”라고 부르는 설계는 문장 생성 대신 선택·평가·확률을 프로그램의 처리 과정에 통합하는 데 중점을 둔다. 본고에서 생각하고 싶은 것은 Jev가 기존 모델을 대체하는 것인지가 아닌지, 모델이 판단을 반환하는 것과 조직이 그 판단을 채택하고 실행하며 결과물을 확인하는 것 사이에 어떤 연결이 필요한가이다.

![画像](https://assets.st-note.com/img/1789898764-k2FwDGHghrfMujbXacom94SK.png?width=1200)

## 제브(Jev)의 설계는 판단과 제어의 역할 분담을 명시한다.

Jev의 공식 자료에서는 상태와 질문을 입력하고, 사전에 정의된 선택지나 평가 척도에 따라 값을 받아들인다. 여러 질문은 분해하여 그 결과를 어떻게 조합할지는 코드에서 제어하는 설계가 제시되어 있다. ［2］ 이는 “AI가 처음으로 판단할 수 있게 되었다”는 이야기로 해석할 수 없다. 확률을 반환하는 분류기는 이전부터 존재했으며, TypeSafe 자체도 비교 실험에서는 LLM을 형식화된 판단으로 변환하는 래퍼를 사용하고 있다. Jev의 등장만으로 “문장을 생성하는 AI”와 “판단하는 AI”가 완전히 분리되었다고 단정할 수 없다. ［1・3］ 주목해야 할 것은 모델이 반환하는 판단 물질과, 그것을 행동으로 변환하는 코드의 역할 분담이 제품의 설계로 명시적으로 드러나 있다는 점이다. 실제로 TypeSafe의 공식 자료는 행동의 위험에 따라 임계값을 변경하고, 자동 처리, 확인, 보류를 활용하는 것을 설명하고 있다. 따라서 “확률과 실행 허가를 분리한다”는 주장은 Jev가 결여된 것을 외적으로 지적하는 것 이상의 의미를 갖지 않는다. Jev 자신이 제시하는 역할 분담을, 업무상의 권한이나 실행 조건까지 구체화하는 질문이다. ［2］

## 2. 유형, 확률, 실행 허가는 각각 다른 질문에 답변한다.

먼저, 모델의 형태가 정확하고 판단 내용이 정확한 것은 서로 다른 개념이다. TypeSafe가 “제로 홀루시네이션”으로 제시하는 수치에 대해 공개된 기사에서는 의미 내용의 오류를 실증적으로 검증한 것이 아니라, 스키마에 적합성을 보장하는 수치라는 설명이 되어 있다. 정의된 선택지에서 벗어나지 않는다는 선택이 현실에 대해 항상 옳다는 것으로 해석하는 것은 가능하다. 또한, Jev의 API에서는 선택지별 확률과 신뢰도(confidence)가 동일한 값이 아니다. 공식 사양에 따르면 신뢰도는 확률 분포의 집중도와 분산의 형태에서 산출하는 지표이다. 신뢰도가 0.94라는 값을 그대로 “정답률 94%”로 해석해서는 안 된다. 더 나아가, 확률 추정 자체에도 검증의 문제가 있다. Guo 연구진의 연구는 분류 정확도와 예측 확률이 실제 정답 빈도에 부합하는 것, 즉 확률 교정(calibration)이 다른 특성임을 보여준다. 교정은 평가 대상의 분포에 대한 통계적 특성이며, 개별적인 판단을 무조건적으로 옳다고 증명하는 것이 아니다. 다만, 이 연구는 Jev를 평가한 것이 아니다. 그러나 본 논문의 핵심 논점은 교정의 불완전성에만 의존하는 것이 아니다. 만약 특정 용도에서 확률 추정이 충분히 검증되어 있더라도, 잘못된 경우의 손실, 실행 권한, 필요한 승인, 지켜야 할 업무 조건이 달라진다면 동일한 확률에서 선택해야 할 행동은 바뀔 수 있다. 확률에서 행동을 결정하려면, 무엇을 허용하고 무엇을 금지할 것인지에 대한 정책이 추가되어야 한다. 확률은 실행 허가의 근거 중 일부가 될 수 있지만, 허가를 내리는 규칙이나 권한 자체는 아니다. 이는 임계값을 통한 자동화를 부정하는 주장과는 거리가 멀다. 충분한 조건이 갖춰진 용도에서는 이전 단계에서 임계값과 일반적인 업무 로직으로 처리해도 된다. 중요한 것은 그 임계값이 무엇을 의미하고 어떤 조건과 함께 사용되는지이다.

## 3. 출하를 제안할 수 있어도 출하를 허가할 수 있는 것은 한정되어 있을 수 있습니다.

의약품 온도 관리 수송을 설명 목적으로 단순화하여 고려한다. 내부 절차에 따라 “정해진 온도 기록이 확인되지 않으면 출하를 보류하고 품질 부서에 확인한다”고 규정되어 있다. 모델이 출하 가능성을 제안하더라도 다음과 같은 처리는 모순이 되지 않는다.

※ 제시된 수치와 처리 내용은 설명용 가상 예시이며, Jev의 실제 측정 결과나 실제 품질 판정 절차를 나타내는 것이 아니다. 보류 이유는 출하를 허용하기 위한 조건이 아직 확인되지 않았기 때문이다. 추정으로 보충되는 정보와 지정된 증거에 의해 확인이 필요한 조건을 구분하고 있다. 더 나아가, 채용 시 확인만으로는 끝나지 않는다. 승인 이후 대상 롯지나 운송지가 변경되면 원래 승인을 그대로 사용할 수 있는 것은 아니다. 실행 이후에도 “명령을 전송했다”는 기록과 “대상물이 지정 목적지에 도착했다”는 확인은 서로 다르다. 이 차이를 기능적으로 정리하면 다음과 같다.

> 
> 
> 판단 대상자를 확인한다 → 채용 조건을 확인한다 → 실행 시 조건을 확인한다 → 결과를 인정한다
> 

네 개의 제품이나 독립적인 서비스가 반드시 필요한 것은 아니다. 같은 애플리케이션 내에 있어도 된다. 중요한 것은 각 확인 대상과 다음 단계 진행 조건이 혼동되지 않는 것이다.

## 기존의 거버넌스도 모델의 출력 결과만 보지 않았었다.

이 문제를 제브의 등장으로 처음 발생한 거버넌스 과제로 묘사하는 것은 정확하지 않다. NIST AI RMF 1.0은 신뢰성에 대한 지표와 임계값 설정에 인간의 판단을 활용하는 것을 설명하고 있다. 부록 자료인 Playbook의 MEASURE 2.8 또한 인간의 감독, 출력에 대한 후속 행동이나 수정, 정책 예외, 책임 주체에 의한 go/no-go 판단 기록을 권장하고 있다. 어느 것도 자의적인 위험 관리 자료이며, 개별적인 판단에 특정 제품이나 독립적인 게이트를 일률적으로 요구하는 것은 아니다. ［4］히로시마 AI 프로세스 국제 행동 지침 또한 고도의 AI 시스템을 개발하는 조직에 자의적인 지침으로, 적용 가능한 범위 내에서 설계·개발·배포·사용을 포함하는 라이프사이클 전체를 다룬다. 배포 후 문제에 대한 대응과, 사용자에게 출력을 적절하게 해석하고 활용할 수 있도록 정보 제공도 포함된다. ［5］반면, EU AI Act에서는 고위험 AI에 관한 제14조가 인간의 감독 하에 출력을 채택하지 않거나, 수정하거나, 운전에 개입하는 등의 기능을 다루고, 제15조가 정확성·견고성·사이버 보안을 다룬다. 감독 조치는 위험, 자율성, 이용 맥락에 따라 결정되며, 모든 AI 활용에 대한 일률적인 인적 승인 의무는 아니다. ［6］이러한 문서의 법적 성격이나 대상 범위는 다르다. 하지만 적어도 “모델의 성능을 평가하면, 출력의 사용 방식까지 자동으로 결정된다”는 구성에는 오지 않았다. 본고의 네 가지 구분은 이러한 문서의 공식 분류가 아니며, 이미 제시된 요구 사항을 업무의 어느 단계에서, 어떤 방법으로 확인하는지를 논의하기 위한 정리이다.

## 5. 필요한 기능에는 기존의 구현 및 연구가 있습니다.

판단과 실행 사이에 조건을 두는 행위 자체를 새로운 발명이나 특정 기업만이 제공할 수 있는 기능으로 취급해서는 안 된다. 예를 들어 Open Policy Agent(OPA)는 권한과 조건을 코드로서 정의하고, 정책의 판단과 그 결과를 실제로 강제하는 처리를 분리한다. AI의 출력과 같은 구조화된 데이터에 업무상의 허용 조건을 적용하는 설계 부품이 될 수 있다. 다만, 판단 결과가 실행 경로에 반영하는 측의 구현도 필요하다. ［7］ 형식 기법에서는 Bloem らの Shield Synthesis가 지정한 속성을 실행 시에 지키기 위해 시스템의 입출력을 모니터링하고, 필요한 경우 출력을 수정하는 메커니즘을 다루고 있다. Mitsch와 Platzer의 ModelPlex는 모델 상의 검증 결과를 현실의 실행에 적용하기 위해 실행이 모델의 조건에 부합하는지 실행 시에 확인하는 방법을 제시한다. 이 모두가 지정된 속성 또는 모델의 전제 조건 하에서의 보증이다. ［8・9］ 따라서 연구상의 질문은 “바깥에 또 다른 검사를 추가하면 되겠다”로 끝나서는 안 되며, 무엇을 확인하고, 무엇이 확인될 수 없는지, 그리고 그 판단이 실제 처리에 의해 우회되지 않도록 하는가에 대한 질문으로 이어져야 한다. 또한, 확인한 조건과 이번 실행 및 결과와의 대응을 어떻게 유지할 것인가를 고려해야 한다. 기존의 승인 처리, 정책 엔진, 형식 검증, 실행 시 모니터링을 조합하여 필요한 조건을 충족시킬 수 있다면, 그 구성으로 충분하다. 중요한 것은 명칭이 아닌, 대상 업무에서 필요한 속성이 성립하는지 여부이다.

## 6. 엑시스트 드라이프트 연구는 그 “연결”을 검증 대상으로 삼는다.

GhostDrift수理研究所은 책임형 운영체제(ADIC) 및 실행 결과 닫춤에 대한 연구를 진행하고 있으며, 이는 모델의 판단 능력을 대체하는 것이 아니다. 판단의 근거, 적용 조건, 실행 조건, 결과 확인을 동일한 대상과 처리 과정에 연결하고 검증 결과를 다음 처리 단계로 반영하는 것이다.［10］예를 들어, Aロット에 대한 승인이 Bロット의 실행에 사용되지 않았는지 확인하는 것이고, “조건부 실행 가능”이라는 판단이 후속 단계에서 “무조건 실행 가능”으로 해석되지 않았는지 확인하는 것이며, “명령 전송 완료”가 어쩐 일로 인해 “목표 달성 완료”로 대체되지 않았는지 확인하는 것이다. 우리는 이러한 연결성을 연구상의 핵심 쟁점으로 삼고 있다. 공개하고 있는 Lean 4 형식화된 “물리적 AI 결과 보증”은 설정된 전제와 확보된 증거에 근거하여 성공한 기록과 성공하지 못한 기록 모두 후보로 남아 있을 경우, 그 정보만으로 확정적인 성공 인증은 불가능하다는 점을 다룬다. 이는 확률적 추정을 부정하는 것이 아니며, 무엇을 확정적인 결과로 취급할 수 있는지를 구분하기 위한 형식화이다. 또한, 사전에 검증된 모든 실행이 대상에 충분히 적용될 경우, 추가적인 실행 후 증거 없이도 결과를 인증할 수 있는 경우를 포함한다.［11］더불어 “물리적 AI 검증 구성”은 각 단계의 보증이 자동으로 전체 보증으로 이어지는 것이 아니며, 전단계의 결과와 다음 단계의 전제를 연결하는 조건이 필요하다는 것을 추상 모델 상에서 다루고 있다.［12］이는 기존 연구를 대체하는 유일한 방식의 증명은 아니다. 공개 형식화가 보여주는 것은 명시된 정의와 전제로부터 유도되는 정보상의 한계와 적용 조건이며, 개별 장비의 안전성, 현실 증거의 진정성, 법규 준수 및 전체 구현의 정확성까지 자동으로 보장하는 것은 아니다. 모델과 현실의 대응, 그리고 실행 경로에의 적용은 별도의 검증이 필요하다.［11, 12］구현의 유효성은 형식의 존재만으로 결정되지 않는다. 조건 위반의 통과를 막았는지에 더하여, 정상적인 처리를 불필요하게 멈추지 않는지, 추가적인 지연은 허용 가능한지, 제3자가 판단 근거를 확인할 수 있는지 등의 관점에서 평가해야 한다고 생각한다.

## 마무리――자동화를 멈추기 위한 것이 아니라, 맡을 수 있는 조건을 명확히 하는

저 위험으로 재시도할 수 있는 처리와 물리적인 작용을 수반하는 처리에는 동일한 무게 확인을 부과할 필요가 없다. 보류 또는 정지 역시 자체적으로 항상 안전하다고 할 수 없으며, 지속 또는 대체 동작을 포함한 설계가 필요하다. 위험에 부합하는 제어라는 관점은 NIST의 프레임워크나, 앞서 언급한 실행 시 검증 연구와도 일관성을 갖는다. [4, 9] Jev를 계기로 생각해야 할 것은 AI에 대한 신뢰를 저하시키는 것이 아니라는 것이다. 판단 능력을 활용하기 위해, 그 판단을 어떤 조건에서 행위로 변환될 수 있는지를 명확히 하는 것이다. 확률은 실행 허가를 의미하지 않으며, 실행 허가는 결과가 얻어진 것의 증명으로도 아니다. 이 차이를 구분하고, 그 사이를 확실하게 연결하는 것이 중요하다. 이것이 모델의 종류를 막론하고 AI에게 일을 맡기는 데 있어서의 중요한 설계 과제이다.

## 원천 자료 및 공개 자료

본문의 번호에 대응한다. 웹 자료의 참조일은 2026년 9월 20일이다. 제공처의 기술 설명, 학술 연구, 공적 문서, 자사 공개 자료는 각각 성격이 다른 근거로서 기재하고 있다. [1] Diogo Almeida／TypeSafe AI(2026년 9월 15일) “Introducing System One Models & Jev.” Jev의 공개, 타입화 출력, 비교 실험의 조건, 스키마 적합에 관한 제공처의 설명. 제3자에 의한 성능 평가가 아니다. 공식 공개 기사 [2] TypeSafe AI, Official Documentation “Introduction”; “Confidence”; “Choice.” 타입화 질문과 코드의 역할 분담, probabilities와 confidence의 구별, 리스크에 따른 임계값의 활용을 설명하는 공식 사양. Introduction ／ Confidence ／ Choice [3] Chuan Guo, Geoff Pleiss, Yu Sun, Kilian Q. Weinberger(2017) “On Calibration of Modern Neural Networks.” Proceedings of the 34th International Conference on Machine Learning, PMLR 70:1321–1330. 분류 정확도와 확률 캘리브레이션의 차이를 다루는 원저 논문. 캘리브레이션의 정의는 제2절. Jev 자체의 평가가 아니다. 논문·원문 PDF [4] National Institute of Standards and Technology(NIST) Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1(2023); AI RMF Playbook, MEASURE 2.8. AI RMF 본문 12쪽의 지표·임계값과 인간의 판단, 및 Playbook의 감독·하류 조치·예외·go/no-go 기록을 참조. 모두 임의의 리스크 관리 자료이다. AI RMF 1.0 ／ Playbook: MEASURE [5] G7(2023) Hiroshima Process International Code of Conduct for Organizations Developing Advanced AI Systems. 전문 및 행동 항목 1~3을 참조. 고도 AI 시스템을 개발하는 조직을 위한 임의의 지침이며, 적용 가능한 범위에서 배포·이용을 포함하는 라이프사이클을 다룬다. 일본 외무성 게재·영문 원문 [6] European Union Regulation (EU) 2024/1689 — Artificial Intelligence Act, Articles 14–15. EUR-Lex의 2026년 7월 27일 통합판을 참조. 제14조 제3·4항의 리스크에 따른 감독, 출력의 불채택·덮어쓰기·개입과 제15조의 정확도 등을 구분하여 참조하고 있다. 개별 용도에 대한 적용이나 적용 개시 시기를 판정하는 것은 아니다. EUR-Lex·통합 조문 [7] Open Policy Agent Project “Open Policy Agent (OPA).” Official Documentation. 정책 판정과 강제 처리의 분리, 구조화 데이터에 대한 조건 판정에 관한 공식 설명. 공식 문서 [8] Roderick Bloem, Bettina Könighofer, Robert Könighofer, Chao Wang(2015) “Shield Synthesis: Runtime Enforcement for Reactive Systems.” arXiv:1501.02573v2. 지정된 특성을 지키기 위한 실행 시 모니터링과 출력 수정에 관한 원저 논문의 공개판. 원저 공개판 [9] Stefan Mitsch, André Platzer(2016) “ModelPlex: Verified Runtime Validation of Verified Cyber-Physical System Models.” Formal Methods in System Design, 49:33–74. DOI: 10.1007/s10703-016-0241-z. 검증된 모델의 보증을 실제 시스템에 적용하기 위한 실행 시 적합성 확인을 다루는 원저 논문. 출판사 게재·원문 [10] GhostDrift数理研究所(2026) “제조 AI를 PoC에서 현장 실행으로. GhostDrift, 피지컬 AI의 실행·결과를 검증하는 AI 어슈어런스 기술 5건을 국제 출원” 자사의 연구 대상과 공개 형식화의 위치를 확인하기 위한 연구개발 발표. 제3자 평가나 인증을 나타내는 자료가 아니다. 자사 발표 원문 [11] GhostDrift Mathematical Institute Physical AI Outcome Assurance. 실행 결과의 인정 가능성, 증거의 모호성, 모델상의 보증을 대상 실행으로 이전하기 위한 조건에 관한 공개 Lean 4 형식화. README의 적용 범위·비주장 사항도 참조. 공개 리포지토리 ／ 형식화 소스 [12] GhostDrift Mathematical Institute Physical AI Verified Composition. 정보 손실과 명시적 접속 조건 하에서의 유한 공정의 보증 합성에 관한 공개 Lean 4 형식화. 개별 설비의 안전성이나 실제 운용 규모에서의 성능 보증과는 구별한다. 공개 리포지토리 ／ 형식화 소스

**출처:** [note 원문](https://note.com/legit_cobra5046/n/n646b460a5f0f)

*번역: Gemma 3(.44) 초벌 + 교정 16청크*

[원문 보기](https://note.com/legit_cobra5046/n/n646b460a5f0f) | 출처: note.com