고객이 주문 주소를 바꿔 달라고 한다. 메시지에는 환불 요청과 파손된 포장, 이번이 세 번째 문제라는 암시도 담겨 있다. 이 메시지에 유용한 답을 만드는 일은 하나의 업무다. 어떤 기록을 수정하고 어느 팀이 개입하며 어떤 조치에 권한이 필요한지 결정하는 일은 별개다.
2026년 9월 15일 얼리 액세스로 TypeSafe AI가 선보인 모델 Jev는 이런 결정에 초점을 둔다. 소프트웨어가 쓸 수 있도록 제약이 있는 구조화된 답을 낸다. 출시는 범용 모델과 긴 대화에 애플리케이션을 얼마나 의존해야 하는지 다시 생각해 보라는 제안이다. TypeSafe의 출시 발표
이 주장은 TypeSafe 공동 창업자 겸 CEO Diogo Almeida가 swyx의 진행으로 출연한 9월 21일 Latent Space 인터뷰에서 가장 충분히 다뤄진다. 2시간 22분 분량의 대화 전체 영어 자막을 검토하고 제품 문서를 확인했다. 이는 인터뷰와 공개 근거를 분석한 것이며 Jev를 독립적으로 벤치마크하지 않았다. 원 인터뷰 시청
우리가 보기에 Jev의 가장 중요한 제안은 자동화의 단위에 관한 것이다. 회사는 전체 프로세스를 책임 있게 넘기기 전에 기존 절차 안의 제한된 판단 하나를 자동화할 수 있다. 그 판단을 충분히 저렴하게 반복하고 명확히 측정할 수 있다면 매번 대화형 세션을 쓰지 않아도 익숙한 업무용 소프트웨어가 유용한 기능을 얻게 된다.
이는 업무 흐름을 설계하는 사람에게도 사용자만큼 영향을 준다. 어떤 조치가 허용되는지와 무엇을 오류로 볼지, 예외는 누가 처리할지를 여전히 사람이 정해야 한다. 이런 결정의 품질에 따라 접근 방식이 믿을 만한 서비스를 만들지 아니면 실수를 빠르게 할지가 달라진다.
TypeSafe가 실제 출시한 것
문서에 나온 Jev 인터페이스에는 상태 정보와 유형이 지정된 질문 집합이 입력된다. 기본 구성은 세 가지다. Choice는 지정된 선택지 중 하나를 고르고, Score는 평가 기준에 맞춰 점수를 매기며, Noul은 진술의 확률을 0에서 1 사이 값으로 나타낸다. Choice와 Score는 분포와 신뢰도 필드를 반환한다. Noul에는 별도의 신뢰도 필드가 없다. 여러 질문은 주어진 상태를 공유하면서도 각각 독립적으로 평가할 수 있다. TypeSafe 인터페이스 문서
고객 서비스 애플리케이션은 이런 구성 요소로 주소 변경과 취소 요청을 구분하고 긴급성을 평가하며 메시지에 파손 근거가 있는지 확인할 수 있다. 이는 가상의 예이지 Jev 배포 결과가 아니다. 그런 다음 애플리케이션이 답을 어떻게 처리할지 결정한다.
해석과 권한은 서로 다른 책임이므로 이런 분리가 유용하다. AI가 고객이 환불을 원한다고 추론할 수 있다. 그렇다고 그 결론에 도달했다는 이유만으로 환불을 실행할 권한을 얻어서는 안 된다. 애플리케이션은 주문을 확인하고 환불 한도를 적용하며 필요한 경우 승인을 요구할 수 있다.
TypeSafe는 빠르고 직관적인 사고를 뜻하는 표현을 빌려 이 모델 범주를 System One이라고 부른다. 이 이름은 의도된 업무를 설명하는 것으로 받아들여야 한다. 인간과 비슷한 인지를 인증하거나 쉬운 일과 어려운 일을 명확히 구분하지 않는다. 특히 필요한 정보가 빠진 경우 짧은 질문도 복잡한 판단을 숨길 수 있다.
공학적 변화는 더 작고 살펴볼 수 있는 판단에 있다
Almeida는 질문의 범위를 좁힌 뒤 답을 코드에서 결합하는 분해 방식을 제안한다. 인터뷰, 1:03:02
파손된 주문 사례를 다시 생각해 보자. 불만을 처리하라는 단일 지시에는 여러 판단이 하나의 응답에 숨겨져 있다. 더 살펴보기 쉬운 설계라면 요청된 조치가 무엇인지와 주문을 식별할 수 있는지, 확보한 근거가 파손 주장을 뒷받침하는지 각각 확인한다. 정책 규칙은 이런 판단과 분리해 둔다.
그러면 실패를 조사하기도 쉬워진다. 시스템이 주소 변경을 반품팀에 전달했다면 운영자는 전달 판단을 살펴볼 수 있다. 파손 평가는 잘못됐다면 해당 구성 요소를 과거 사례로 시험할 수 있다. 광범위한 지시를 다시 쓰고 모델이 일관되게 해석하길 기대하지 않아도 명시적 규칙을 바꿔 정책을 수정할 수 있다.
비용도 있다. 구성 요소가 늘면 유지할 인터페이스도 늘어난다. 질문에서 답을 분명히 해 주는 맥락을 실수로 빠뜨릴 수 있다. 겉보기에는 독립적인 두 판단이 같은 오해의 소지가 있는 근거에 의존할 수 있다. 각각은 허용할 만한 구성으로 이룬 업무 흐름도 전체 결과는 받아들일 수 없을 수 있다.
TypeSafe가 문서화한 패턴에는 여러 질문을 함께 던지고 점수를 결합하며 불확실한 사례를 추가 처리로 보내는 방식이 있다. 이는 구조적 선택지를 설명할 뿐 특정 고객 절차가 무인 운영 준비를 마쳤다는 증거는 아니다. TypeSafe의 패턴
유용한 시험은 분해가 진단과 결과 모두를 개선하는지 확인하는 것이다. 어느 단계가 실패했는지 설명할 수 있는 점은 가치가 있다. 실패의 빈도와 결과를 줄여야 사업적 근거도 생긴다.
유효한 답도 틀릴 수 있다
출시 때 Jev가 “환각을 일으킬 수 없다”는 주장은 좁게 해석해야 한다. TypeSafe는 허용된 출력 스키마에 맞는다는 조건에 보장을 연결한다. 이는 선택된 답변이 사실임을 입증하지 않는다. 자체 발표도 스키마 보장과 경험적 평가를 구분한다. TypeSafe의 타입 안전성 설명
애플리케이션이 다음 값만 허용한다고 하자: damaged, late 및 other. damaged 을 반환해도 완전히 유효한 답일 수 있다.
구조화된 출력은 이미 사용되는 공학적 접근이기도 하다. OpenAI는 2024년 8월 스키마 제약형 Structured Outputs를 도입하면서 반환값 안에서도 모델이 실수할 수 있다고 명시했다. 따라서 Jev가 모든 구조화 AI 출력을 발명한 것으로 치켜세우기보다 의사결정 품질과 불확실성 보고, 지연 시간, 비용의 특정 조합으로 평가해야 한다. OpenAI의 최초 발표와 한계
구매자에게 이 구분은 평가 계획을 바꾼다. 스키마 시험은 소프트웨어가 답을 처리할 수 있는지 묻는다. 사실성 시험은 답이 근거와 맞는지 묻는다. 정책 시험은 그에 따른 행동이 허용되는지 묻는다. 하나를 통과했다고 나머지 시험을 대신할 수 없다.
인터뷰에서 가장 중요한 질문은 보정에 관한 것이다
Almeida는 1:09 지점에서 완벽하게 보정됐다는 제안을 거부하고 모델의 오류를 인정한다. 인터뷰, 1:08:50
보정은 예측된 확률이 여러 예측 집단에서 실제 결과와 얼마나 일치하는지에 관한 개념이다. 모델은 모든 고확률 사례를 맞히지 못하더라도 불확실성을 알리는 데 유용할 수 있다. TypeSafe의 입문 자료는 이 차이를 분명히 유지한다. TypeSafe의 보정 설명
API의 신뢰도 필드에도 별도의 구분이 필요하다. TypeSafe는 이를 답변 분포에서 계산한 통계라고 설명한다. 선택한 답이 맞을 독립적으로 측정된 확률과 같은 값은 아니다. 문서는 작업과 그 결과에 맞춰 임계값을 정하라고 권한다. TypeSafe의 신뢰도 문서
이는 실무적인 문제다. 짧은 영어 메시지에서는 성능이 좋지만 여러 요청이 섞인 긴 불만에는 어려움을 겪는 분류 모델을 생각해 보자. 하나의 종합 점수는 이런 약점을 감출 수 있다. 약한 집단에서 높은 신뢰도로 내린 결정은 익숙한 집단의 같은 표시 수치보다 더 주의 깊게 봐야 할 수 있다.
따라서 팀은 누락된 정보와 익숙하지 않은 표현, 의도적으로 혼란을 일으키는 입력을 포함해 예상되는 사례를 평가해야 한다. 범주별 오류를 살펴보고 검토로 넘기는 비용을 잘못 행동했을 때의 비용과 비교해야 한다. 데모에서 본 숫자를 그대로 가져오는 대신 근거에 기반해 임계값을 정하고 실제 운영해야 한다.
보정 연구는 Jev보다 오래됐다. 널리 인용되는 Chuan Guo 등의 2017년 논문은 현대 신경망의 부정확한 보정과 개선 방법을 다뤘다. 이 연구는 문제의 배경을 제공하지만 TypeSafe 모델을 검증하지는 않는다. 현대 신경망 보정에 관하여
서비스가 바뀔 때도 신뢰성은 중요하다
대화에서는 견고성과 결정론을 구별하고 일반적인 장기 지원 약속이 없는 버전 안정성을 논의한다. 인터뷰, 41:24 및 49:40
이는 별개의 구매 관련 질문이다. 결정론은 동일한 입력이 동일한 출력을 내는지 묻는다. 견고성은 기록 식별자가 달라지는 등 무관한 변화가 비합리적인 행동 변화로 이어지는지 묻는다. 모델은 같은 오답을 반복해 결정론적일 수도 있다. 주변 업무 흐름이 신뢰성을 유지하는 동안 모델의 출력은 조금씩 달라질 수도 있다.
두 속성 중 어느 것도 수명 주기 위험을 해결하지 않는다. 기업은 어떤 모델 버전이 결정을 내렸는지, 그 버전을 계속 쓸 수 있는지, 대체 모델은 어떻게 평가할지 알아야 한다. 제공업체의 시험 성적이 좋아져도 고객이 세심하게 조정한 업무 흐름의 행동은 바뀔 수 있다.
대표 사례를 보존하고 버전을 기록하며 중요한 업무를 옮기기 전에 대체 모델을 비교하는 것이 합리적이다. 대체 경로도 중요하다. 정확한 결정 서비스라도 이용할 수 없게 될 수 있다. 애플리케이션에 멈추거나 다른 곳으로 업무를 보내는 안전한 방법이 없다면 가동 시간이 실제 의사결정 품질의 일부가 된다.
이 지점에서 매력적인 API는 운영상 의존성으로 바뀐다. 모델이 빨라져도 조달과 모니터링, 이전 계획이 사라지지는 않는다. 호출 하나가 단순해 보이기 때문에 오히려 소홀해지기 쉽다.
속도와 가격 숫자에 맥락이 필요한 이유
TypeSafe가 내세운 워크플로 성과에는 속도 193.6배, 비용 444.6배 개선이 포함된다. 발표는 이를 회사가 작성한 업무 흐름에서 얻은 최고 수준의 이득이라고 밝힌다. 정답은 독립적으로 확인한 실제 분류가 아니라 다른 모델의 확률 추정치에서 나왔다. 회사는 짧은 시연이 Jev에 유리하며 장기적으로 지속 가능한 가격은 아직 정해져야 한다고도 주의한다. TypeSafe 평가의 유의 사항
이런 한계 설명은 수치와 함께 전달되어야 한다. 기준 모델과 일치하는 결과는 정보를 줄 수 있지만 해결된 고객 사례의 정답 여부와는 다른 것을 측정한다. 공급업체가 설계한 업무 흐름은 구매자에게 관련 있어도 해당 구매자 요청의 실제 분포를 대표하지 않을 수 있다.
올바른 비교는 맥락 수집과 판단, 규칙 적용, 예외 처리, 실패 복구 등 업무 전체를 포함해야 한다. 검토자에게 너무 많은 일을 넘기면 모델 호출이 저렴해도 총비용은 커질 수 있다. 더 느린 호출이 값비싼 재작업을 피한다면 경제적일 수도 있다.
지연 시간도 애플리케이션이 실제 사용하는 지역에서 측정해야 한다. 서비스 인프라 가까이에서 한 시연은 다른 지역 사용자에게 같은 경험을 약속하지 않는다. 대화형 시스템은 평균뿐 아니라 느린 요청도 살펴야 한다. 백그라운드 처리라면 처리량과 총비용이 더 중요할 수 있다.
Jev라는 이름은 효율성이 소비를 늘릴 수 있다는 아이디어를 떠올리게 한다. 개별 기업에는 예산 문제가 따른다. 어떤 새로운 결정을 평가할 만해지고 어떤 결정은 불필요하게 평가할 만큼만 저렴해지는가? 모델 호출이 늘어나는 것 자체가 성과는 아니다.
다른 연구 목표, 아직 완성되지 않은 근거
Almeida는 선호 최적화에 대한 비판과 데이터, 작업 선택, RLCD를 연결해 연구 주장을 펼친다. 인터뷰, 7:23 및 22:12
RLCD는 Reinforcement Learning for Calibrated Decisions의 약자다. TypeSafe는 이를 사람의 선호나 검증 가능한 보상 방식과 대조하며 활용 가능한 결정과 확률을 목표로 한 학습이라고 설명한다. 이는 자사 목표에 대한 회사의 설명이다. 완전한 훈련 방법이 독립적으로 확인됐다는 뜻으로 오해해서는 안 된다. TypeSafe AI 입문 자료
방법을 평가하는 동안에도 더 넓은 질문은 살펴볼 만하다. 학습 목표는 어떤 행동에 보상을 주는가? 설득력 있는 설명을 최적화한 모델은 쓰기 편하면서도 코드가 실행할 수 있는 형태로 불확실성을 드러내지 않을 수 있다. 의사결정 중심 인터페이스는 불확실성을 더 쉽게 다루게 하지만 출력은 여전히 현실에 맞춰 외부에서 확인해야 한다.
TypeSafe는 선호 최적화가 보상받는 응답 쪽으로 가능성 높은 출력의 범위를 좁힐 수 있는 현상을 모드 드롭과 연결한다. 이는 실패 유형에 관한 회사의 설명이지 선호 학습 모델이 모두 의사결정에 쓸 수 없다는 발견은 아니다. TypeSafe의 선호 최적화 논의
Almeida의 배경을 생각하면 이 주장은 특히 흥미롭다. 그는 사람의 피드백으로 언어 모델이 지시를 따르도록 학습하는 방법을 연구한 InstructGPT 논문의 공동 저자다. 저자라는 사실은 확인할 수 있지만 모든 연구소가 잘못하고 있다는 포괄적 주장은 별개의 문제다. InstructGPT 논문
사전 학습 비용과 방향 없이 새 연구소를 만드는 일에 대한 그의 반대도 유용한 작업을 선택해야 한다는 같은 주장에 속한다. 인터뷰, 1:49:32 및 2:03:10
구매자에게 유용한 교훈은 제품이 정의된 절차에서 무엇을 할 수 있는지 묻는 것이다. 연구 경력과 컴퓨팅 지출, 차별화된 모델 구조는 회사가 어떤 제품을 내놓게 됐는지 설명할 수 있다. 하지만 다른 회사에서 실제 운영할 때의 경제성을 입증하지는 않는다.
인터뷰에서는 Almeida의 OpenAI 퇴사와 어려웠던 초기 도입, 개발자 주도 성장도 다룬다. 인터뷰, 1:31:27 및 1:56:48
이런 회고는 회사의 우선순위를 설명하지만 도입 성과를 감사한 근거는 아니다. 개발자 플랫폼은 결국 지속적으로 유용한 업무와 해당 업무가 실패할 때 제공하는 지원으로 평가해야 한다. 출시 뒤 나타난 열기는 조사할 이유이지 실적 기록을 대신하지 않는다.
새 대화창보다 기존 소프트웨어가 더 큰 혜택을 얻을 수 있다
Almeida는 더 강력한 SaaS 제품과 배경으로 물러나는 AI를 전망한다. 인터뷰, 1:19:57
이는 살펴볼 만한 설득력 있는 방향이다. 소프트웨어에는 유용한 판단으로 다음 단계를 바꿀 수 있는 지점이 이미 있기 때문이다. 일정 관리 앱은 예약 전에 모호한 요청을 찾아낼 수 있다. 미디어 자료실은 연구자를 위해 자료를 정리할 수 있다. 서비스 데스크는 일반적인 업데이트와 주의가 필요한 불만을 구별할 수 있다. 이는 가능한 설계이지 Jev 배포 사례에 관한 보고는 아니다.
인터페이스는 거의 달라지지 않을 수도 있다. 사용자는 실수가 줄고 반복 분류가 덜 필요하거나 적절한 담당자를 기다리는 시간이 짧아지는 변화를 체감할 수 있다. 이미 업무 흐름을 이해하고 더 나은 판단을 반영할 수 있는 기업이 상업적 이점을 얻을 수도 있다.
기존 소프트웨어 기업도 계속 경쟁해야 한다. 같은 판단을 여러 개발자가 이용할 수 있다면 모델 호출만으로는 차별화하기 어렵다. 주변 제품이 유용한 데이터 접근과 세심한 상호작용 설계, 일을 끝낼 수 있는 믿을 만한 방법을 제공해야 한다.
고용에 관한 주장은 더 신중해야 한다. 한 업무에 드는 노력을 줄이면 인력 구성이 바뀌거나 서비스 물량이 늘거나 예외 처리로 일이 이동할 수 있다. 결과는 조직과 서비스 수요에 달렸다. 인터뷰나 얼리 액세스 출시만으로 특정한 수의 일자리가 유지되거나 사라지거나 생긴다고 볼 수 없다.
BIG CHANGE의 업계 개요에서 측정 가능한 사건은 의사결정 자동화의 또 다른 접근법이 이용 가능해진 것이다. 폭넓은 도입과 생산성 향상, 노동시장 영향은 각기 다른 근거가 필요한 다음 단계의 질문이다.
다크 데이터와 실시간 소프트웨어, 데모의 한계
인터뷰에서는 저장된 데이터와 인터랙티브 애플리케이션, 검증, 컴퓨터 사용 시연을 논의한다. 인터뷰, 1:34:50
범주마다 다른 평가가 필요하다. 자료실 처리 작업은 약간의 지연을 감수할 수 있지만 결과를 표본 조사하고 원본 기록까지 추적할 계획이 필요하다. 실시간 인터페이스는 예측 가능한 응답성이 중요하다. 다른 모델을 평가하는 검사기는 두 시스템이 같은 실수를 하는 경우까지 포함해 해당 모델이 실제로 하는 오류로 시험해야 한다.
컴퓨터 사용에서 행동을 고르는 것은 시스템의 일부일 뿐이다. 인터페이스를 정확히 파악하고 행동을 실행하며 예상한 변화가 발생했는지 확인하는 방법도 필요하다. 세련된 시연은 한 번 순서가 작동했음을 보여 줄 수 있지만 신뢰할 수 있는 자동화는 반복 시험과 중단 후 복구가 필요하다.
게임에도 같은 주의가 적용된다. 모델이 조종하는 캐릭터는 더 풍부한 상태에 대응할 수 있고 게임 엔진은 가능한 행동을 계속 제한할 수 있다. 플레이가 나아지는지는 반응성과 일관성, 경험 설계에 달려 있다. 모든 프레임에 추론을 추가한다고 게임이 자동으로 더 흥미로워지는 것은 아니다.
이런 차이를 구분하면 범주 오류를 피할 수 있다. 유용한 구성 요소에는 실제 수행한 역할에 맞춰 공을 돌려야 하며 주변의 더 큰 애플리케이션이 가진 모든 역량까지 넘겨서는 안 된다.
미세 조정과 비전, 추가 모델 형태는 인터뷰에서 가능한 선택지로 언급된다. 인터뷰, 1:10:27 및 1:26:23
로드맵 대화를 출시 계획의 전제 조건으로 삼아서는 안 된다. 현재 이용할 수 있는 인터페이스를 기반으로 만들고 별도 구성 요소가 제공해야 할 것을 파악하며 새 기능이 실제 출시되면 평가한다. 그러면 추측을 제품 기능처럼 제시하지 않고도 향후 개선의 혜택을 볼 여지를 남긴다.
코딩 에이전트가 업무를 나누는 방식이 달라질 수 있다
Almeida는 단일 모델 반복을 넘어 코딩 에이전트 사이에서 더 저렴하게 상태를 관리하고 컨텍스트를 공유하는 방안을 제안한다. 인터뷰, 1:40:17 및 2:09:29
가능한 구조라면 유능한 코딩 모델이 변경 사항을 만들고 더 작은 판단 호출이 관련 파일을 분류하며 일반 소프트웨어가 생성된 작업을 관리할 수 있다. 별도 검토자가 최종 패치를 살펴볼 수 있다. 이는 설계 제안이지 벤치마크를 거친 권고나 Jev가 이미 기존 코딩 에이전트를 대체한다는 증거는 아니다.
매력적인 부분은 선택적으로 컨텍스트를 제공할 수 있다는 점이다. 하위 작업에 인터페이스 하나와 몇 가지 제약만 필요하다면 대화 전체를 보내는 것은 낭비일 수 있다. 명시적인 작업 기록을 쓰면 어떤 사실이 중요한지와 무엇을 이미 결정했는지, 어떤 변경이 남았는지 파악하기 쉬워질 수 있다.
위험한 부분은 조정 제안을 동시성 보장으로 착각하는 것이다. 두 에이전트가 모두 파일을 써야 한다고 판단할 수 있다. 확률적 모델이 서로 충돌하는 쓰기를 막는 소프트웨어 메커니즘을 대신해서는 안 된다. 권한과 버전 확인, 잠금 장치로 결과를 계속 통제해야 한다.
마찬가지로 이전 작업을 더 저렴하게 검색하면 기억 관리를 개선할 수 있지만 지속 학습이라고 불리는 모든 문제를 해결하지는 않는다. 앞선 시도를 기억하고 실패 이유를 이해하며 새로운 상황에 안정적으로 적응하는 일은 서로 다른 능력이다. 설득력 있는 평가는 에이전트나 호출 수만 세지 않고 완료한 작업과 회귀, 충돌, 사람의 개입을 살펴본다.
안전은 시스템 전체로 이동할 뿐 사라지지 않는다
Almeida는 모델의 거부보다 애플리케이션 수준 안전 통제를 선호하고 swyx는 그 결과에 이의를 제기한다. 인터뷰, 13:11 및 1:42:29
여기에는 실제 설계 문제가 있다. 무인 애플리케이션은 의존 요소가 거부하거나 실패하거나 불확실한 결과를 내는 경우를 처리해야 한다. 명시적인 대응 경로가 필요하다. 그렇다고 모든 보호 장치를 어디에 두어야 하는지가 결정되는 것은 아니다.
모델이 의도된 조치를 정확히 식별하더라도 애플리케이션은 접근 권한을 강제해야 한다. 기록 삭제 요청을 완벽히 이해했더라도 권한이 없을 수 있다. 기술적으로 유효한 요청도 운영자 정책을 위반할 수 있다. 적절한 맥락 없이 의사결정 서비스가 이런 질문에 책임 있게 답할 수는 없으며 애플리케이션이 행동의 통제권을 유지해야 한다.
따라서 소프트웨어로 더 많은 판단을 옮길수록 배포 전에 경계를 정하는 일이 중요해진다. 어떤 근거가 필요한지와 되돌릴 수 있는 작업은 무엇인지, 결과에 사람이 이의를 제기하거나 수정하는 방법을 정해야 한다. 모델과의 번거로운 상호작용을 줄였다고 전체 시스템의 안전성이 입증되는 것은 아니다.
큰 변화를 보여 주려면 무엇이 필요한가
출시로 명확한 시험을 할 수 있게 됐다. 결과를 관찰할 수 있는 제한된 절차 하나를 고른다. 현재 어떻게 작동하는지, 실수와 이를 고치는 데 사람이 들이는 시간까지 기록한다. 행동 권한을 주기 전에 대표 사례로 의사결정 기반 방식을 시험한다.
개입 없이 정확히 완료한 사례의 비율과 검토에서 놓친 오류, 사람에게 넘어간 작업량, 사례 완료당 총비용을 측정한다. 검토자가 결과를 승인한 이유를 살펴볼 수 있도록 원래 근거를 보존한다. 모델과 정책, 입력 집단이 바뀔 때 비교 시험을 반복한다.
이 평가로 절차 일부만 자동화할 준비가 됐다는 사실이 드러날 수도 있다. 그래도 유용한 결과다. 모호한 사례를 경험 있는 담당자에게 맡기면서 일반 분류만 자동화하는 일은 더 넓은 자율성을 정당화하지 않고도 가치가 있을 수 있다.
Jev의 출시와 Almeida 인터뷰는 AI가 경제에 들어오는 방식에 관한 야심 찬 가설을 내놓는다. 반복적이고 제약된 판단이 사람들이 이미 의존하는 소프트웨어를 더 유능하게 만들 수 있다는 것이다. 다음 근거는 오류와 예외까지 계산에 포함해 장기간 실제 업무를 처리하는 시스템에서 나와야 한다. 흥미로운 모델 구조가 독자가 실제로 볼 수 있는 변화가 되는 지점이 여기에 있다.
