결과적으로 가장 쓴맛 나는 부분은 여전히 인간의 몫으로 남는 것을 판단하는 것이었다.

게시판: AI·머신러닝 | 작성자: admin | 작성일: 2026-09-28T16:05:52.539Z

제브와 올바른 업무에 관한 대화: 가장 깊은 교훈으로부터 업무 자동화와 현장의 암묵적 지혜를 고민한다.

총 17장, 2026년 9월 23일 주제: TypeSafe AI 제브(Jev) 작업 설계, 암묵지, RLHF, RLCD, 업무 자동화

제1장 가장 쓰라린 교훈과 제브의 사상

■Jev(제브)의 개발사인 TypeSafe AI의 공동 창업자 겸 CEO 디오고 알메이다(Diogo Almeida) 씨가 2026년 9월 10일에 해당 회사의 공식 블로그에서 공개한 에세이 『The Bitterest Lesson(가장 쓰라린 교훈)』의 전문(일본어 번역)을 소개합니다. 이 에세이는 리처드 서튼의 유명한 AI 에세이 『The Bitter Lesson(쓰라린 교훈: 계산량이 모든 것을 능가한다)』를踏まえつつ가 아니라 이를 바탕으로 하면서, AI 개발에서 '올바른 태스크를 설정하는 것'이 계산량보다 더욱 중요하다고 제언한 것입니다. 알메이다 씨가 OpenAI 시절에 InstructGPT(RLHF)를 개발했을 때의 경험을 바탕으로 쓰였습니다. 『The Bitterest Lesson(가장 쓰라린 교훈)』 TL;DR(요약): AI의 진보를 이끄는 것은 계산량(컴퓨트)이지만, 올바른 태스크에 임하지 않는다면 그 진보에 무슨 의미가 있을까! 리처드 서튼의 '쓰라린 교훈'은 계산량이 알고리즘을 능가한다는 것을 말하고 있다. 연구자들은 지능에 관한 자신들의 기발한 아이디어를 기계에 심고 싶어 한다. 그러나 거듭 승리를 거둬 온 것은 더 많은 계산량을 활용하는 범용적인 접근법이었다. 탐색(서치)은 인간이 손으로 구축한 체스 지식을 이겼고, 뉴럴 네트워크는 손수 만든 이미지 인식용 특징량을 이겼다. 이 교훈이 '쓰라린' 것은 연구자들이 알고리즘을 사랑함에도 불구하고 그 기발함이 스케일(규모)만큼 중요하지 않기 때문이다. 내 경험상 서튼의 '쓰라린 교훈'은 더욱 쓰라린 교훈으로 이루어진 빙산의 일각에 불과하다. 계산량과 알고리즘 너머에는 '데이터'가 있고, 그 너머에는 '머신러닝을 적용할 적절한 태스크를 고르는 것'이 존재하기 때문이다. 머신러닝(ML)에서 '가장 쓰라린 교훈'이란 중요도의 순서가 다음과 같아진다는 것이다. 올바른 태스크에 임하는 것 ＞ 데이터 ＞ 계산량 ＞ 알고리즘. 서튼의 쓰라린 교훈이 게임에서 가장 이해하기 쉬운 것은 현실 세계와는 다른 두 가지 큰 차이가 있기 때문이다. 즉, 올바른 태스크가 명확하며(이기기 위해, 혹은 점수를 최대화하기 위해 규칙을 따르는 것), 데이터는 자기 대국을 통해(계산량에 의해) 무한히 생성할 수 있다는 것이다. 따라서 그다음으로 중요한 것이 계산량이 되는 것은道理에 맞는 일이다. 결국 머신러닝이란 보상을 올리거나 손실(로스)을 낮추는 일 중 하나이다. 그러나 최적화해야 할 목적은 여전히 누군가가 결정해야 한다. 이를 올바르게 설정하려면 모델이 동작하는 외부 시스템을 이해해야 한다. 올바른 태스크가 설정되어 있지 않다면, 모든 것이 완벽하게 동작하고 가장 아름다운 손실 곡선과 스케일링 곡선을 그렸다고 해도 그 모델은 전혀 쓸모가 없을 가능성이 있다! 안타깝게도 ML 연구는 이러한 문제에 역순으로 임하는 경향이 있다. 연구자들은 알고리즘을 발명하는 것을 좋아한다. 그리고 최근에는 스케일링 곡선을 애호하게 되었다. 한편 데이터는 다루기 까다로운 존재이다. 그리고 올바른 태스크를 고르려면 사용자, 프로덕트, 조직, 혹은 혜택을 받아야 할 세계의 모든 부분을 연구하기 위해 ML의 영역에서 완전히 벗어나야 하는 경우가 흔하다. 이는 스케일(규모)에 반대하는 주장이 아니다. 태스크와 데이터가 올바르다면 스케일의 힘은 엄청나게 크다. 이는 스케일을 '절대적이고 최종적인 것'으로 취급하는 것에 대한 반론인 것이다. 쓰라린 LLM(Bitter LLMs) 인생이 당신에게 LLM을 주었다면…… 우리는 OpenAI에서 InstructGPT(RLHF)를 개발했을 때 이 교훈을 배웠다. GPT-3은 인터넷상의 텍스트의 다음 토큰을 예측하도록 훈련된 놀라운 모델이었지만, 사람들이 원했던 것은 초강력한 자동 완성(오토컴플리트)이 아니라 지시를 따르는 무언가였다. GPT-2 크기의 모델(GPT-3보다 100배 이상 작음)은 가장 단순한 알고리즘과 극히 적은 계산량만을 사용했더라도 올바른 태스크로 훈련됨으로써 GPT-3을 완전히 압도했다. (※여기에 InstructGPT 논문의 도표 인용) 사전 학습의 스케일을 확대하는 것만으로는 그(GPT-2 크기의) 베이스라인에 이기기 위해서만도 대략 GPT-7 수준에 도달해야 하며, GPT-3 기반의 InstructGPT에 이기려면 GPT-9 수준이 필요할 것이다. 당신은 '최적화한 것'을 얻는다. 그리고 ML에서 가장 쓰라린 교훈이란 그 가장 중요한 부분이 '전혀 ML이 아니다'라는 것이다. 배경 보충: 디오고 알메이다 씨는 이러한 사상을 배경으로 TypeSafe AI를 창업하고, 인간의 대화 상대로서 행동하는 모델(RLHF)이 아니라 소프트웨어 프로그램에서 직접 이용하기 위해 결정과 확률(타입이 있는 데이터)을 반환하는 데 특화된 'System One Model'인 Jev를 2026년 9월에 릴리스했다. https://www.youtube.com/watch?v=f9UWyfSliWc 위 글과 YouTube 내용에 대해, 그것들의 요약과 당신의 생각을 들려주십시오. ■AI에 대한 나의 생각은, 'AI의 실용성은 무엇을 달성하게 할 것인가라는 설계에서 시작된다'는 핵심에는 강하게 찬성한다. 특히 불확실한 판단을 업무 안에서 다루는 발상은 중요하다. 다만, 이 사상의 타당성과 Jev가 실제로 어디까지 실현하고 있는지는 각각 검증해야 한다. 당신이 지정한 영상은 '기업의 이력서【AI 해설】'에 의한 일본어 해설이다. 아래는 그 자동 자막, 에세이 원문, 공식 제품 설명, InstructGPT 논문을 대조하여 정리한 것이다. 에세이의 요점 글의 요점은 '최적화가 성공해도 목적이 잘못되어 있으면 쓸모가 없다'는 것이다. AI는 주어진 평가 기준을 개선한다. 그러나 그 평가 기준이 이용자나 조직의 진정한 목적을 나타내고 있다고는 할 수 없기 때문이다. 그래서 Almeida 씨는 올바른 태스크 ＞ 데이터 ＞ 계산량 ＞ 알고리즘이라는 우선순위를 제시한다. 태스크를 정하려면 이용자가 겪는 어려움이나 실제 일의 구조까지 이해해야 한다. 그래서 '가장 중요한 부분은 머신러닝 밖에 있다'는 것이다. 계산량의 확대도 목적과 데이터가 적절하다면 큰 힘을 발휘한다는 입장이다. (참고: 에세이 원문) 영상의 내용 영상은 이 사상을 Jev의 설계와 연결 짓고 있다. 주요 내용은 다음 네 가지이다.

사용하기 쉬운 출력 형태의 소프트웨어입니다. 선택지, 숫자, 확률을 반환하고 처리의 분기에 통합합니다.
속도와 가격 경쟁력을 바탕으로 용도가 확대되고, 세세한 판단을 자주 요구받을 수 있도록 한다.
신뢰도를 실제 정답률에 가깝게 하는 학습. 자동 처리 가능한 사안과 검토가 필요한 사안을 분리하기 용이하게 한다.
업무 및 제품의 재설계. AI를 소프트웨어 내부로 통합하여 일상적인 처리 자체를 지능적으로 만든다.

영상 후반에서는 속도와 비용 개선이 새로운 애플리케이션의 가능성을 열 것이라고 논합니다. 특히 중요하다고 생각하는 세 가지는 다음과 같습니다. 첫째, “정확한 작업”은 업무 성과에서 역산하여 결정해야 합니다. 예를 들어, 문의 응대에서 “답변을 빠르게 하는 것”을 목표로 하면, 빠르지만 해결하지 않는 답변이 늘어날 수 있습니다. “문의를 해결하고 재문의를 줄이는 것”까지 목표에 포함하면 필요한 데이터와 평가 방법도 달라집니다. 이 차이는 모델의 성능 향일 만으로는 해결하지 않습니다. 무엇이 성공이라고 부를지를 결정하는 일이 필요합니다. 저는 이 에세이의 가치는 AI 개발에서 현장 이해의 중요성을 명확히 한 데 있다고 생각합니다. 그러나 이 부등식을 모든 상황에서 적용 가능한 과학 법칙으로 취급하지는 않습니다. 목적이 명확한 문제에서는 계산량이나 새로운 알고리즘이 최대 제약이 되는 경우도 있습니다. 저자 스스로도 부언에서 새로운 작업에는 새로운 알고리즘이 필요한 경우가 있다고 인정하고 있습니다. 둘째, “얼마나 틀릴 가능성이 있는지”를 활용하는 데는 큰 실용적 가치가 있습니다. 여기서 “확률의 교정”이란 예를 들어 “80% 정확”이라고 예측한 케이스를 많이 모았을 때, 실제로는 약 80%가 정확하다는 대응입니다. 개별 케이스의 정확성을 보장하는 것은 아닙니다. 이 대응이 실제 업무에서도 유지된다면, 판단의 확률과 실패했을 경우의 영향을 결합하여 처리를 결정할 수 있습니다. 쉽게 수정 가능한 분류와 취소하기 어려운 처리는 자동 실행 기준을 바꿔야 할 것입니다. 또한, 출력 형식이 정확한 것과 판단 내용이 정확한 것은 별로 다릅니다. “영업, 회계, 지원” 중 하나라도 반드시 답변을 제공하더라도 부서 담당을 잘못 낼 가능성은 있습니다. TypeSafe의 “환각이 없는” 설명은 공식 문서에서는 스키마 적합성 보증과 연결되어 있습니다. 이를 “오류 판단이 없는” 것으로 읽을 수는 없습니다. 세 번째로, 자동화는 모델과 주변 시스템을 함께 평가해야 합니다. 영상에는 “학습 단계에서 인간을 루프에 넣으면, 사용 시에도 인간이 필요하다”는 취지 설명이 있지만, 저는 여기에는 논리적 비약이 있다고 생각합니다. 학습 데이터를 인간이 평가하는 것과 운영 시 인간의 확인이 필요한 것은 다른 문제입니다. 운영 시 확인을 줄일 수 있는지 여부는

작은 모델이 GPT-3에 승리한 것은 특정 지시 사항에 대한 응답을 인간이 평가한 조건에서 나타난 결과입니다. 논문에서는 13억 파라미터의 InstructGPT가 1,750억 파라미터의 GPT-3보다 더 선호되었습니다. “GPT-2 사이즈”는 모델 크기를 설명하는 용어이며, 실험 모델은 GPT-3 기반 구조를 사용했습니다. 모든 능력에서 작은 모델이 승리했다는 의미는 아닙니다. (참조: InstructGPT 논문)
GPT-7·GPT-9은 저자의 외삽적 추정치에 불과하며, 해당 제품을 측정한 결과와 같이 해석해서는 안 됩니다.

제브에 대해 제가 가장 보고 싶은 것은 실제 업무에서 “사람이 확인하지 않아도 처리할 수 있었던 비율”과 “그 결과 발생한 오류나 수정 사항”이 어떻게 달라지는지입니다. 이것이 지속적으로 개선된다면, 알메이다의 주장은 매력적인 사상뿐만 아니라 실용적인 측면에서도 강력한 근거를 갖게 됩니다.

제2장 지시를 따르는 것의 올바른 작업

이 에세이는 매우 중요한 내용이라고 생각하지만, 아직 완전히 이해가 되지 않는 부분이 있습니다. 우선 “정확한 태스크”에 대해 이야기해 보겠습니다. 에세이에서는 “우리는 OpenAI에서 InstructGPT(RLHF)를 개발하는 과정에서 이 교훈을 얻었다. GPT-3는 인터넷상의 텍스트의 다음 토큰을 예측하도록 훈련된 믿을 수 없는 강력한 모델이었지만, 사람들이 요구한 것은 초강력 자동 완성(자동 보완)이 아니라 지시를 따르는 것이었다. GPT-2 크기의 모델(GPT-3보다 100배 이상 작음)은 가장 단순한 알고리즘과 극소량의 계산량만 사용했어도 정확한 태스크로 훈련됨으로써 GPT-3를 완전히 파괴한 것이다.”라고 합니다. 그렇다면 그 “정확한 태스크”는 구체적으로 무엇을 의미하는 걸까요? 이 부분에서 말하는 “정확한 태스크”는 구체적으로 “인간으로부터 지시를 받았을 때, 그 의도에 부합하며 유용한 답변을 제공하는 것”입니다. 이를 “지시 추종”이라고 합니다. “문장을 요약하는”, “번역하는”과 같은 개별적인 작업도 포함되지만, 저자가 강조하는 것은 모델이 무엇을 향상되도록 훈련되었는가의 차이점입니다. 예를 들어, 모델에 다음 문장을 입력했다고 가정해 봅시다. 다음 기사를 중요한 내용이 파악되도록 3가지 줄점으로 요약해 주세요. [기사의 본문] 두 가지 훈련 방식의 차이를 단순화하면 다음과 같습니다.

사전 학습만으로는 지시대로 요약이 나오는 경우가 있습니다. 하지만 원래의 학습 목표는 “문장의 흐름을 예측하는 것”입니다. 학습한 문장의 패턴에 따라 기사의 내용을 이어쓰거나 유사한 다른 문제를 만들 수도 있습니다. 그래서 “이 지시에는 이렇게 답하면 도움이 된다”라는 대응 방식을 명시적으로 학습시킨 것입니다. InstructGPT에서는 대략 다음과 같은 절차를 따랐습니다.

사람이 답변의 모범 사례를 제시하고, 지시와 이에 대한 바람직한 답변 쌍을 활용하여 추가 학습한다.
여러 답변을 인간이 비교하고, 어느 쪽이 지시사항에 부합하고 유용한지를 평가한다.
높이 평가받는 답변을 생성하도록 조정하고, 인간의 평가를 예측하는 시스템을 구축하여 강화 학습을 수행함으로써 평가를 높인다. 이것이 RLHF에 해당한다. (참고: InstructGPT 논문)

그러므로 저자의 말 중의 “정답”은 “사용자가 실제로 필요로 하는 것에, 학습 목표가 부합하는” 것을 의미합니다. 여기서 “요약이 가능한 모델이欲しい”라고 생각하는 사람들에게는 요약의 요청을 제대로 실행할 수 있는지가 중요합니다. 인터넷상의 글의 맥락을 얼마나 능숙하게 예측할 수 있느냐는 만족도를 충분히 측정할 수 없습니다. 더욱 중요한 것은 InstructGPT도 답변을 내놓을 때 다음 토큰을 순차적으로 생성하고 있다는 점입니다. “다음 토큰을 내는 메커니즘”을 버린 것이 아니라, 주로 어떤 답변을 바람직한 것으로 학습시킬지를 변화시킨 것입니다. 이 예의 “정답 태스크로 훈련하는” 것은 일상적인 언어로 표현하면, 사용자가 요청하고자 하는 일을, 모범과 평가를 통해 모델에 가르치는 것입니다. 이러한 추가 학습으로 인해 작은 모델도, 지시 응답을 인간이 평가하는 상황에서는 훨씬 큰 미세 조정된 모델을 능가할 수 있었습니다. 그것이 저자에게 결정적인 경험이었던 것입니다.

제3장: 무의식적 지식과 학습 목표

■여기서 말씀하시는 ‘가장 쓴맛 나는 교훈’은 뛰어난 모델이 아닌, 사용자 스스로도 이해하지 못하는 인간이라면 당연히 의지하는 일을 모범과 평가를 통해 “인간이” 모델에게 가르치는 것인지요. ■AI는 상당히 근접합니다. 다만, 핵심은 “인간이 가르치는 것” 그 자체보다 “무엇을 할 수 있느냐에 따라 사람에게 도움이 되는지 판단하고, 그것을 학습 목표로 삼는가” 하는 데 있습니다. 이전에 설명드린 내용은 InstructGPT의 구체적인 예시에 바탕을 두었기 때문에 “모범과 평가를 통해 가르치는” 방법을 지나치게 강조했습니다.

사용자 스스로도 이해하지 못하는, 요청하는 업무일지라도 중요한 부분입니다. 이용자의 의도와 정확히 일치하지 않는 기대까지 파악해야 할 수도 있습니다. 다만, 업무가 처음부터 명확한 경우에는 그러지 않습니다.
본문과 평가를 통해 가르친다”――InstructGPT에서는 실제로 이 방법을 사용했으며, 에세이의 주장은 이 방법 외에도 다양합니다.
인간이 가르치는 것은, 저자가 인간이 모든 면에서 반드시 모범이 되어야 하고 평가를 내려야 한다고 주장하는 것이 아니라, 학습의 목적을 결정하기 위해 이용자나 업무 현장을 이해해야 한다는 점을 강조한 것입니다. (참고: 에ッセ이 원문)

회의를 요약해 줘. 표면적으로는 긴 대화를 짧게 만드는 것이지만, 실제로는 회의에서 결정된 사항과 누가 무엇을 언제까지 할지 파악하여 업무 누락을 방지하고 싶다는 것일 수도 있다. 우선 이 차이를 파악하고 어떤 것을 출력하며 무엇을 평가해야 하는지를 결정해야 한다. 다만 여기서 인간이 “음, 분명 이렇게 해줬으면 좋겠지”라고 섣불리 판단해서는 안 된다. 암묵적인 기대를 가설로 설정하고, 사용자나 실제 결과 등을 통해 확인하는 것이 과제 설정이라고 생각한다. 여기서 가장 중요한 것은, 연구자가 훌륭한 모델을 만드는 기술을 연마했음에도 불구하고 그 기술의 본질적인 목표를 잘못 이해하면 노력이 실질적인 성과로 이어지지 않는다는 점이다. 당신이 말하는 “사람이라면 당연히 아는 지식”은 바로 이 본질적인 목표를 짚어내는 데 매우 중요한 단서가 된다.

4장: 말로 표현할 수 없는 판단을 AI에 가르치다

■당신은 구체적으로 어떻게, 그 “인간이라면 당연히 알고 있는 무형지식”을 AI에 가르쳤습니까? “인간이라면 당연히 알고 있는 무형지식”이라는 표현은 다소 어색하며, “무형지식”으로 수정하는 것이 더 자연스럽습니다. ■AI에 대한 그 질문은, 제가 이전에 설명했던 부분에서 모호하게 남아있었던 부분입니다. InstructGPT에서는 인간이 실제로 작성한 답변과 “어떤 답변이 더 좋은지”에 대한 판단을 학습 데이터에 모두 담았습니다. 여기서 다음 두 가지를 구분하면 더 명확해집니다.

판단 이유를 완전히 설명할 수 없습니다.
구체적인 답변을 확인해 보더라도 좋다고 판단할 수 없거나 나쁘다고 판단할 수 없다.

이전 답변을 선택할 수 있다면, 그 선택을 학습에 활용할 수 있습니다. 예를 들어, 이는 설명용 가상 예시이지만, 다음 요청을 생각해 보세요. 친한 친구로부터 모임 초대를, 부드럽게 거절하는 답변을 작성하세요.

많은 사람들이 이 조건이라면 B를 선택할 것입니다. A는 불친절하고, C는 설명되지 않은 이유를 만들고 있습니다. 그 사람이 “인간 관계를 유지하면서 거절하는 완전한 규칙”을 설명하지 못했더라도, 이 상황에서 B를 선택했다는 판단은 기록될 수 있습니다. 다른 상황에서도 유사한 판단을 모아보면 선택 경향을 학습할 수 있습니다. 다만, B가 모든 사람에게 적절한 것은 아닙니다.

사람들이 답변 예시를 작성하며, 약 40명의 작업자가 예시 작성 및 평가에 참여하여 사전 학습된 모델을 추가 학습했습니다.
모델의 답변을 사람이 순위 매긴다. 하나의 요청에 대해 4~9개의 답변을 보여주고, 그중 어떤 것이 좋은지 순위를 매겨 주셨다.
그 순위 결정 예측 모델을 만들어 본다. 인간이 높은 점수를 매기지 않을까 예상되는 답변에 높은 점수를 부여하도록 학습시킨다.
응답 모델을 해당 지표가 높아지도록 조정한다. 이것이 강화 학습 단계이다. (참고: 논문 및 방법 설명)

이 시스템에서는 인간이 “왜 그렇게 판단했는지”를 완전한 규칙으로 설명할 필요가 없습니다. 다만 학습되는 것은 인간의 판단을 근사하는 경향입니다. 그 이면에 정확하게 이해했다는 보장은 없습니다. 또한 평가를 모든 작업자의 직관에 맡긴 것도 아니었습니다. 연구자들은 판단의 지침을 제공하고 질문에 답하며, 모호한 지침을 수정했습니다. 요청의 의도가 극도로 불명확한 경우에는 작업자에게 건너뛰도록 지시했습니다. (참고: 논문 및 작업과 평가 지침) 따라서 당신의 의문이 특히 해당하는 경우는 “본인도 무엇을 보아야 성공이라고 판단할지 모르는 경우”입니다. 그 경우에는 답변을 비교해도 적절한 학습의 실마리를 얻을 수 있다는 보장은 없습니다. 실제로 사용해 결과를 확인하거나 배경을 다시 듣는 등 목적을 탐색하는 작업이 필요합니다. InstructGPT도 이 문제를 완전히 해결한 연구는 아닙니다. 논문은 평가자가 추측한 의도와 실제 사용자의 의도가 다를 수 있다는 점을 인정하고 있습니다. (참고: 논문 및 평가상의 한계) 제가 이전에 “묵시적 지식을 가르친다”라고 표현한 부분은 보다 정확하게는 “묵시적인 판단이 나타난 사례를 모아 그 경향을 모델에 학습시키는” 의미입니다. 인간 자신에게도 판단할 수 없는 목적까지 자동으로 밝혀내는 방법은 아닙니다.

제5장 RLCD가 추구하는 판단

■당신의 RLCD는 이 아이디어가 근본적인 원리인가요.■AI “달성하고자 하는 업무에 맞춰 학습 목표를 설정한다”는 개념이 RLCD로 이어지는 부분이라는 이해로 정확합니다. 다만, 앞서 설명한 ‘인간이 모범을 보이고 답변을 순위로 매기는 방식’은 InstructGPT에서 사용된 RLHF 설명입니다. RLCD가 동일한 방식으로 암묵지를 가르치는 것까지는 확신할 수 없습니다. Almeida 교수가 설명하는 목표의 차이는 다음과 같습니다.

이 문서를 경리부에 회부해야 하는가. RLCD가 지향하는 것은 적절히 분류하는 것 외에, “80%의 확신이 있는” 안건을 다수 확보했을 때 실제로도 약 80%가 정확한 상태입니다. (참고: TypeSafe의 공식 설명) 그렇게 되면 주변 프로그램은 그 확률이나 오차했을 경우의 영향에 따라 자동 처리하거나 확인 절차로 전환할 수 있습니다. 다만 “そもそも何を正しい 분류로 볼 것인가”는 여전히 결정해야 합니다. 사내 담당 범위가 모호하다면 확률만 제시하는 것으로는 해결되지 않습니다. RLCD는 “암묵지 문제를 모두 해결하는 방법”이라기보다는, 저자의 입장에서는 업무에 적용하기 위해 필요한 판단의 성질을 학습 목표로 삼는 것이 더 적절합니다.

제6장 예측 확률과 정확률을 조율하는 시스템

■그럼 당신은 “80% 이상의 확신이 있는” 사례를 다수 수집했을 때, 실제로는 약 80%가 정확한 상태를 어떤 메커니즘으로 실현시키고 있는 걸까요. ■AI 시스템의 기본은 “맞았는지 여부 외에도, 어떤 확률을 부여했었는지 평가하고, 그 점수를 개선하도록 학습시키는” 것입니다. 다만, 처음에는 구분이 필요합니다. RLCD의 구체적인 학습식이나 절차는 확인된 공개 자료로는 알 수 없습니다. Almeida 氏は9월 21일 공개된 대담에서 논문은 미발표라고 밝혔습니다. 아래는 그 목표를 달성하기 위한 일반적인 메커니즘으로, Jev의 내부 방식을 단정하는 설명은 아닙니다. (참조: 본인의 대담) 확률 자체를 평가한다 – 브라이아 점수 예를 들어, “이 문의사항은 회계 담당이 처리해야 하는가”를 예측한다고 가정해 봅시다. 먼저, 담당이 확인한 사례를 준비합니다. 각각에 대해,

회계 부서에서 담당하는 사례에는 “1”이 해당됩니다.
회계 부서에서 처리하지 않는 경우 “0”으로 기재합니다.

정답을 제시하겠습니다. 모델은 문의 내용에서 “회계 담당 확률”을 산출합니다. 여기서 사용할 수 있는 평가 방법 중 하나가 브라이아 점수입니다. 계산은 간단하며, 오차 ＝ (예측한 확률 – 실제 결과)²로 합니다. 값이 작을수록 좋은 점수입니다. “회계 담당 확률은 80%”라고 예측한 경우,

실제로 회계 업무를 수행한다면, 오차는 (0.8 - 1)² = 0.04입니다.
회계에서는 오차는 (0.8 - 0)² = 0.64입니다.

이렇게만 하면 “맞을 때만 100%라고 말하면 되のでは”라고 생각할 수도 있습니다. 하지만, 틀렸을 때의 오차까지 포함하여 다수의 사례로 평가하면 차이가 나타납니다. 설명하기 위해, 주어진 정보로는 구별할 수 없는 100건 중 80건이 회계 관련이고 20건이 회계 관련이 아니었다고 가정합니다. 모든 것에 동일한 확률을 적용할 경우, 평균 오차는 다음과 같이 나타납니다.

가장 좋은 점수로 예측할 수 있는 비율이 80%로 예상된다. 지나치게 공격적이거나, 너무 소극적이거나, 평균적인 방법으로는 손해를 볼 수 있다. 이러한 특성을 가진 방법을 ‘적정 점수 규칙’이라 한다. (참고: 확률 예측에 대한 점수 관련 논문) 여기서 중요한 점은, 인간이 개별 케이스마다 “이 케이스의 정확한 확률은 80%입니다”라고 알려줄 필요가 없다. 개별 결과와 비교하여 오차를 계산하고, 그 오차가 줄어들도록 모델을 반복적으로 조정한다. 그 과정에서 판단하기 쉬운 특징과, 모호한 특징을 학습시킨다. 하지만 이 점수 방식만으로는 미지의 케이스에서 확률이 정확해진다는 보장은 없다. 따라서 학습에 사용되지 않은 사례로 검증한다. “80% 정도”라고 예측한 케이스들을 모아 실제 비율과 비교한다. 90%나 60%의 예측에 대해서도 동일하게 조사한다. 차이가 있다면, 추가적인 조정용 데이터로 확률을 보정하는 방법도 있다. 이것이 ‘교정’이다. (참고: 확률 교정 관련 연구) 남은 질문은――정답은 누가 결정하는가 그리고, 여기서도 당신이 지적하는 암묵지 문제는 여전히 남아있다.そもそも “회계 담당이 정답”이라고, 누가 무엇을 근거로 결정하는 것일까. 인간의 판단을 정답으로 하면, 그 판단과의 일치를 학습한다. 실제 업무 성과를 기준으로 하면, 그 성과와의 대응을 학습한다. 점수 방식만으로는 정답 데이터 자체의 타당성은 해결할 수 없다. “확률”과 “신뢰도”의 차이점 또한, 제가 지금까지 사용해 온 “신뢰도”라는 표현은 제품 설명으로는 보충이 필요했다. Jev에서는 각 선택지 확률과, 확률 분포의 형태에서 계산하는 신뢰도는 별개이다. 신뢰도는 0.8을 의미한다. “정답률 80%”라고 읽어서는 안 되며, 위에 설명한 80%는 선택지에 붙이는 예측 확률을 의미한다. (참조: 공식 설명)

제7장: 제브의 초기 성과와 검증의 한계

현재 Jev의 현황은 기대한 만큼 성과를 내고 있는 것일까요? AI 2026년 9월 23일 현재 “빠르고 저렴하게 판단을 처리한다”는 기대에는 초기 성과가 나타나고 있습니다. 반면 “출력하는 확률을 광범위한 업무에서 그대로 신뢰할 수 있다”는 기대는 아직 충분히 검증되지 않았습니다. 공개된 제3자의 측정 결과에 따르면 평가는 다음과 같습니다.

첫째, 속도와 비용 측면에서 실제 측정을 기반으로 한 성과가 있습니다. AY Automate가 791건의 분류 및 탐지 문제에서 비교한 테스트 결과, Jev는 비교 대상보다 중앙값으로 약 2~3.6배 더 빠르며, 저렴한 소형 모델 2종과 비교했을 때 약 4.7~7.5배 저렴한 비용이었습니다. 다만, 정답률은 소형 모델과 비슷한 수준이었으며, 대형 모델에는 뒤지는 작업도 있었습니다. 또한, 불확실한 사례만 대형 모델에 할당하는 구성에서는 대형 모델 단독과 비슷한 정답률을, 약 26~28%의 비용으로 얻었다고 보고합니다. “판단을 분담하여 비용을 절감하는” 방식에는 구체적인 근거가 있습니다. 하지만 이는 제한된 데이터에서의 테스트이며, 해당 회사의 고객 업무 도입 실적은 아닙니다. 제3자 테스트). 둘째, 당신이 심도 있게 다루고 있는 “확률의 신뢰성”에는 아직 과제가 있습니다. 9월 21일 공개된 교통사고 기록을 분석한 프리프린트에서는 Jev의 판단을 2,416건의 인간 판단과 비교 검토했습니다. 추출 성능에는 유망한 결과가 있었지만, 출력 확률에는 여전히 차이가 있었습니다. 연구자가 인간 판단 데이터를 사용하여 추가적인 교정 작업을 수행하면, 사용되지 않은 데이터로 측정한 교정 오차는 0.0231에서 0.0069로, 약 3분의 1로 줄었습니다. 또한, 비교한 일반적인 생성 모델 중 하나는 Jev보다 교정이 더 좋았습니다. 연구 논문 표 6 및 표 9). 이는 “RLCD로 학습했기 때문에 확률 문제는 해결되었다”고 말할 수 없음을 시사합니다. 하지만 단일 분야의 공개 직후 연구이므로, 이것만으로는 Jev 전체를 평가할 수 없습니다. 마지막으로, 공식 발표의 큰 숫자에는 평가 조건이 있습니다. TypeSafe가 제시하는 193.6배속, 444.6배 저비용은 해당 회사가 특정 업무 프로세스에서 비교한 결과입니다. 해당 회사 스스로도 실제로 얻을 수 있는 개선 효과가 큰 수치라고 설명하고 있습니다. 게다가 이 공식 평가에서는 대형 모델 2종의 평균적인 예측을 참조 답변에 활용했습니다. 따라서 이 그래프만으로는 현실적인 정답에 대해 확률이 적절한지 여부를 증명할 수 없습니다. 공식 평가 조건). 제 생각에는 현재의 Jev를 “용도 선택, 검증 및 적용 시 처리 비용과 대기 시간을 줄일 수 있는 유망한 제품”으로 평가합니다. 다만, 제가 지금까지 설명해 온 “교정된 판단”은 Jev가 지향하는 성질입니다. 모든 용도에서 달성되었다는 확인이 이루어진 성질은

제8장: 업무 자동화에 대한 제브의 역할

■당신 영상에서는 “왜 일은 자동화되지 않는가”, “AI 기업의 리더들은 경제의 절반을 자동화한다!”라고 말했지만, 실제로 이루어지지 않은 것에 대해 Jev가 그 해결책으로 적절한 접근 방식인지 묻는 것이죠. AI 저는 Jev가 일의 자동화를 진행하는 데 있어 훌륭한 접근 방식 중 하나라고 생각합니다. 다만, 일의 자동화가 되지 않는 이유 중 일부에 대해서는 답변하고 있는 단계입니다. “판단할 수 있는 것”과 “맡길 수 있는 것” 사이의 간극이 바로 중요합니다. 여기서 중요한 것은 “개인의 판단이 가능한 것”과 “일을 끝까지 맡길 수 있는 것” 사이에 큰 간극이 있다는 점입니다. 예를 들어, 온라인 쇼핑몰의 반품 처리 사례를 생각해 봅시다. 완료되기까지는 다음과 같은 과정이 있습니다. 요청의 의미를 파악 → 주문 정보를 확인 → 반품 조건을 판단 → 필요한 절차를 실행 → 완료를 확인합니다. Jev가 목표하는 것은 바로 이 과정 중 “이것은 반품 요청인가”, “조건을 충족하는가”, “담당자에게 회부해야 하는가”와 같은 판단을 빠르고 저렴하게, 프로그램으로 처리할 수 있는 형태로 반환하는 것입니다. 이러한 설계에는 자동화를 진행하는 데 있어 명확한 합리성이 있습니다. (참고: TypeSafe 공식 제품 설명) 판단 외에 필요한 것도 있습니다.

예를 들어 “항상 단골 고객이므로, 이번에는 예외적으로 반품을 허용하는” 결정이 있다면, 누구를 단골로 보느냐, 어느 정도까지 예외를 인정하느냐, 그리고 그 결과를 어떻게 평가하느냐를 결정해야 합니다. 여기에는 지금까지 이야기해 왔던 “암묵지”와 “정확한 업무 수행”의 문제가 여전히 남아 있습니다. Jev는 적절하게 정해진 판단을 실행하는 데 도움을 줄 수 있지만, 그 회사에게 어떤 판단이 적절한지는 도입만으로 결정되는 것이 아닙니다. 실제 TypeSafe 자체의 평가에서도, 미리 코드에 정해진 올바른 업무 흐름을 전제로 각 모델을 비교하고 있습니다. 따라서 이 평가가 보여주는 것은 그 흐름 속에서 판단을 처리하는 능력이며, 회사의 업무를 이해하고 자동화 시스템 전체를 구축할 수 있다는 것을 증명하는 것은 아닙니다. (참조: 공식 평가 설명) 확률이 실적과 맞아야만 충분하지는 않습니다. 앞서 언급한 “확률이 신뢰할 수 있다”는 이야기에도 더하여, 또 다른 조건이 있습니다. 극단적인 예로, 모든 케이스에 대해 “이 답변이 정답일 확률은 80%”를 제시하는 모델을 생각해 봅시다. 실제로 전체의 80%가 맞다면 확률의 교정은 맞지만, 그것만으로는 어떤 케이스를 자동 처리하고 어떤 케이스는 사람에게 회부할지 선택할 수 없습니다. 자동화에는 확률이 실적과 맞을 뿐만 아니라, 쉽게 처리할 수 있는 케이스와 어려운 케이스를 구별할 수 있는 능력이 필요하며, 충분히 신뢰하여 맡길 수 있는 케이스가 업무 전체에서 차지하는 비율이 중요해집니다. 허용 가능한 오차의 정도 또한 이메일 분류와 반품 승인에서는 다릅니다. Jev를 평가할 때 보고 싶은 숫자 때문에, 저는 Jev를 평가할 때 속도나 요금보다 다음 숫자를 보고 싶습니다.

같은 품질을 유지하면서, 몇 퍼센트의 사건이 무인으로 완료되었는가.
업무 전체 비용이 확인 및 수정 사항까지 포함하여 감소했는지 확인해야 합니다.
예외나 상황 변화에도 불구하고 그 결과가 지속될 수 있을까.

자동화되지 않았다는 문제 제기에 대해 다시, 영상 속의 “~하지 못했다”는 표현은 강력한 문제 제기로 받아들이는 것이 적절합니다. 기존의 생성 AI에도 실무적인 성과는 이미 있으며, 고객 응대 담당자 5,172명을 대상으로 한 연구에서는 AI 지원으로 시간당 해결 건수가 평균 15% 증가했습니다. 하지만 이는 사람을 지원하는 결과이며, 업무 전체를 자동화한 의미는 아닙니다. (참고: 연구 논문 “Generative AI at Work”) 제가 Jev에게 기대하는 것은, 현장에서 반복되는 작은 판단을 소프트웨어에 맡기기 쉽게 만드는 것입니다. 이것이 큰 자동화로 이어질 가능성이 있습니다. 그리고, 여기서 에세이의 주장이 Jev 자신에게도 되돌아옵니다. Jev의 성능이 뛰어나더라도, 업무상의 실제적인 장애가 “판단 지연이나 비용” 외에 있다면 기대한 성과는 나타나지 않습니다. 무엇이 일을 멈추게 하는지 파악하고, 그에 맞는 시스템을 만드는 것까지 포함하여 “올바른 작업을 수행하는” 것이라고 생각합니다.

제9장: 업무 수행 능력과 발견 능력

■말씀하신 대로 Jev는 근본적인 문제, 즉 ‘일의 자동화’에 대한 답변이 부족하며, ‘올바른 태스크’가 무엇인지 판단하는 추론 능력으로는 활용하기 어렵다는 이해로 괜찮을까요. AI가 “Jev는 무엇이 올바른 태스크인지를 스스로 발견하는 문제를 해결하지 못했다”고 이해하는 것은 타당합니다. 다만, “그를 위한 추론에 전혀 도움이 되지 않는다”라고 단정할 수는 없습니다. 이 부분은 제 설명에서 더욱 명확히 구분했어야 했습니다. ‘올바른 태스크를 골라 만들어진 AI’와 ‘올바른 태스크를 스스로 찾아내는 AI’는 다른 개념입니다. 에세이는 주로 전자에 초점을 맞추고 있습니다. 모델을 만드는 측이 이용자와 업무를 이해하고, 무엇을 학습시켜야 할지를 결정하는 것입니다. 실제로 본문에서도 “최적화할 목적은 누군가가 정해야 한다”고 명시되어 있습니다. 목적 발견 능력까지 모델에 탑재된 것이 아니라는 점을 분명히 합니다. (참고: 에세이 원문) Almeida氏は、その考え方から“ソフトウェアが直接使える、確率を伴う判断”を学習目標に選んだのです。그 목표가 적절하다고 판단한 것은 Jev의 개발자입니다.

공식 자료에서는 Jev에게 좁은 범위의 질문을 제시하고, 복잡한 추론이나 여러 요인을 고려해야 하는 경우에는 질문을 분해하여 외부 프로그램에서 조합하도록 설명합니다. (참조: 공식 문서). 하지만 고객의 목소리를 “설명 부족”, “절차의 복잡성”, “응대 지연” 등으로 분류하여 문제 해결의 자료를 만드는 데 활용될 수 있습니다. 하지만 분류 항목 자체가 틀렸거나 중요한 원인이 빠져 있다면, 분류가 정확하더라도 문제 발견에는 도움이 되지 않습니다. 따라서 당신이 원하는 것은 “인간도 충분히 언어로 표현하지 못하는 업무의 목적을 이해하고, 무엇을 해야 할지를 구성하는 능력”이라면, 현재의 Jev를 그 답변으로 보려는 근거는 없습니다. “업무 자동화”라는 광범위한 문제에 대해 Jev는 정의된 판단을 실행하기 쉽게 하는 부분에 집중하고 있습니다. 가장 어려운 부분인 “어떤 기준으로 판단해야 할지 찾는 것”은 Jev를 도입해도 해결되지 않습니다.

제10장 알메이다 씨의 계획과 업무 탐색 방법

디오고 알메이다(Diogo Almeida) 氏は、そもそも何をしたい 것일까요. 그의 문제 제기는 매우 중요한 통찰이라고 생각하지만, 그의 제품은 그 문제 제기와는 또 다른 수준, 즉 빠른 사고로 움직이는 것입니다. 그리고 그는 어떻게 올바른 작업을 찾아내야 하는 것일까요. AI 본인에 대한 설명을 확인해 보면, 그가 목표하는 것은 “현장을 잘 아는 사람들이 AI를 부품으로 조합하여 자동화를 만들 수 있도록 하는 것”입니다. 그 구상에서는 올바른 작업을 찾는 역할은 주로 현장 사람이나 소프트웨어 개발자가 담당합니다. 지금까지 제가 설명한 내용은 이 분담을 충분히 전달하지 못했습니다. 문제 제기와 제품의 수준이 다르다는 지적은 역시 옳습니다. 다만, 그는 그 차이를 분업을 통해 연결하려 している 것은 적절한 해석입니다. 알메이다 氏의 시각, 그의 출발점에는 다음과 같은 시각이 있습니다. “현재 AI에도 상당한 경제적 가치를 지닌 지능이 존재한다. 그것을 소프트웨어 안에서 안전하게 사용할 수 있는 형태로 만들지 못하는 것이 자동화를 방해하고 있다”는 것은 제 추측이 아니라, TypeSafe의 공식 선언문에 나타나 있는 주장입니다. 그들은 개발자가 의미 이해와 판단을 호출할 수 있는 부품을 제공하고, 그것을 쌓아 올려 다양한 소프트웨어가 탄생하는 것을 기대합니다. 그러나 이것이 자동화 정체의 주된 원인이라는 점은 그들의 가설로 취급해야 합니다. (참조: 공식 선언문) 여기서 보면, Jev가 빠른 사고를 담당하는 것 자체에는 모순이 없습니다. 무엇을 자동화해야 하는지를 결정하는 단계에는 깊이 검토가 필요하지만, 그 일을 실행하는 과정에서의 한 가지 판단은 매번 심도 깊은 고민이 필요한 것은 아니기 때문입니다. 예를 들어, 업무를 조사한 결과 “요청을 적절한 담당자에게 전달하는 단계에서 매일 엄청난 시간이 낭비되고 있다”는 사실을 알게 되었다고 가정해 봅시다. 그 문제의 발견이나 업무 설계에는 충분한 고민이 필요합니다. 하지만 개별 요청을 전달하는 처리에는 신속한 판단으로도 충분할 수 있습니다. 그는 그러한 판단을 소프트웨어에 구현하는 부분을 담당하려 하고 있습니다. 올바른 작업을 어떻게 찾을 것인지에 대한 그의 설명은, 핵심인 “올바른 작업을 어떻게 찾을 것인가”에 대해 무엇을 이야기하고 있는지 확인한 자료에 따르면 다음과 같습니다.

사용자, 제품, 조직을 조사한다. 에세이에서는 올바른 작업을 선택하기 위해서는 기계 학습의 세계를 벗어나 그것이 사용되는 외부 메커니즘을 이해해야 한다고 주장한다. (참조: 에세이 원문)
업무에 정통한 개발자나 기업에 기대한다. 인터뷰 1시간 18분 51초 이후 부분에서 기존 업무 소프트 기업은 무엇을 자동화할 때 가치가 있는지 잘 알고 있다고 말한다. 그 자신이 전 산업의 과제를 발견하는 구상과는 다르다. (참조: 본인의 인터뷰)
문제를 작은 판단으로 나누어 실제 업무에서 평가한다. 같은 인터뷰의 1시간 1분 30초 이후에는, 문제를 세밀하게 분해하면 각각을 평가하기 쉬워진다고 조언한다. 또한 19분 58초 이후에는, 사용자에게 중요한 업무 흐름에 통합하고, 그 안에서 성능을 측정해야 한다고 설명한다. (참조: 본인의 설명)

그러나 이러한 것은 “정답을 발견하기 위한 지침”일 뿐이며, 발견을 보장하는 체계적인 방법은 아닙니다. 특히 “문제를 작게 나누는 것”은 이미 선택한 문제를 다루기 쉽게 하는 방법입니다. 그 문제 자체를 선택한 것이 정당했는지까지 보장하지는 않습니다. 그만큼의 간극이 남아있게 됩니다. 당신이 질문하는 것은 “현장 담당자 스스로도, 정말 필요한 일을 이해하고 언어화하지 못한 상황에서, 어떻게 그것을 발견할 수 있는가”입니다. 이번에 확인한 에세이, 선언문, 인터뷰에서는 그 난제에 직접적으로 다가간 구체적인 방법은 제시되어 있지 않습니다. “현장을 조사하고”, “현장을 잘 아는 개발자에게 기대한다”는 것에 그치고 있습니다. 제 평가에 따르면, 그의 사업 구상은 일관성이 있습니다. 다만, 그 안에는 “현장 담당자들이 쓸모 있는 판단 부품만 있으면 충분히 가치 있는 자동화를 설계할 수 있다”는 기대가 있습니다. 그 기대가 성립되는 현장에서는 Jev가 도움이 될 수 있습니다. 반면에, 목적의 발견이나 암묵지의 이해 자체가 최대의 난관이 되고 있는 현장에서는 Jev만으로는 더 이상 나아갈 수 없습니다. 에세이는 그 상류 문제의 중요성을 지적하지만, 그 해결 방법을 제시하는 데는 도달하지 못하고 있습니다. 이러한 점을 구분하여 평가해야 합니다.

제11장: 문제 제기와 Jev를 잇는 개발 목적

■당신도 인지하겠지만, 그의 근본적인 문제 제기와 Jev는 직접적인 관련이 없다는 것이죠. 그럼에도 불구하고 Diogo Almeida(디오고 알메이다) 氏は, 왜 Jev를 만들었을까요. ■AI “직접적인 관련이 없다”는 이해는 수정이 필요합니다. 제 이전 설명에서 두 자들을 지나치게 분리시켜 버렸습니다. 그에게 Jev는 “올바른 태스크를 선택하라”는 주장을, 그들의 모델 개발에서 실천한 것입니다. 여기서 “올바른 태스크”는, 첫째, 개발자가 모델에 무엇을 학습시키고, 어떤 능력을 갖추면 성공을 보는지 의미합니다. 에세이는 그 설정을 사용자 또는 이용 환경의 이해에서 시작해야 한다고 주장합니다. (참조: 에세이 원문) 그가 Jev를 만든 이유는, 본인의 설명을 정리하면 다음과 같습니다.

그는 AI의 지능을 더욱 실제 소프트웨어에서 활용하고 싶어 하며, 현재 AI에도 상당한 경제적 가치를 창출할 수 있는 능력이 있다고 생각합니다.
그렇기 때문에 소프트웨어가 필요로 하는 능력을 학습 목표로 삼아야 합니다. 예를 들어, 제시된 선택지에서 판단하고, 불확실성을 확률로 반환하며, 그 결과를 프로그램이 처리할 수 있도록 해야 합니다.
그 목표에 맞춰 모델 훈련 방식 및 출력 메커니즘까지 설계하고 싶다. 그것이 Jev이다. 속도나 가격은 이러한 판단을 업무 전반에 활용할 수 있도록 하는 특징이다. (참조: 공식 선언, Jev 개발 방향)

즉, 그가 생각하기에 “소프트웨어가 직접 이용 가능하고 신뢰성 있는 판단을 제공하는 것”이 우리가 주목해야 할 “정답 과제”였다고 한 것입니다. 실제로 인터뷰에서도 새로운 과제의 목표를 “프로그램을 처리 루프 안으로 포함시키는 것”으로 설명하고 있습니다. (참조: 본인의 설명, 20분 43초 이후) 여기서 두 가지 이야기가 분기됩니다.

그 선택의 결과가 Jev이다.
제프가 그 문제를 해결할 수 있다는 점은 명확하게 드러나지 않았습니다.

그는 “정확한 작업을 찾는 능력”을 제품으로 만들지 않고, “자신이 옳다고 판단한 작업”을 제품으로 만든 것입니다. 그 의미에서 에ッセ이와 Jev는 직접적인 관련이 있습니다. 하지만 그 작업 선택이 실제로 업무 자동화를 크게 발전시킬 수 있을지는 그의 통찰력의 날카로움과는 별개로, 성과로 확인해야 합니다.

제12장 업무 소프트웨어와 경제적 가치

■여기 말씀하시는 “실제 소프트웨어”는 구체적으로 어떤 것을 의미하시나요? 그것이 어떻게 “큰 경제적 가치를 창출할 수 있는” 걸까요. ■AI에서 말씀하시는 “실제 소프트웨어”는 기업들이 매일 사용하는 문의 관리, 입출고, 청구서 처리, 상품 관리, 사내 검색 등의 업무 시스템을 의미합니다. 제 표현이 추상적이었습니다. 그가 기대하는 것은, 이러한 시스템에서 사람이 문맥의 의미를 읽고 판단하는 부분을 AI에게 맡기는 것입니다. 업무 시스템에서 AI에게 맡기는 판단 방식은 다음과 같습니다. 용도는 공식 자료를 바탕으로, 기대되는 경제 효과는 제가 정리하고 있습니다.

이는 TypeSafe가 제시하는 예상 사용 용도 및 평가용 업무 예시입니다. (참조: 공식 용도 목록, 청구서 처리 예시) 문의 관리의 구체적인 예시를 들어보겠습니다. 예를 들어, 고객으로부터 “어제 탈퇴했는데, 오늘 아침에 이용료 청구서가 또 왔습니다. 확인해 주세요.”라는 이메일을 받았습니다. 이 이메일을 수락하고 저장하는 단계는 일반적인 소프트웨어로도 가능합니다. 그 이후 필요한 것은, 문장을 읽고 “탈퇴 방법에 대한 질문인지”, “탈퇴 후 청구에 대한 이의 제기인지” 등을 판단하여 적절한 처리에 연결하는 것입니다. Jev를 통합할 경우, 다음과 같이 분담될 수 있습니다.

소프트웨어가 이메일과 계약 및 청구 기록을 준비한다.
제프가 요청의 종류와 추가 확인의 필요성을 판단한다.
소프트웨어가 정해진 절차에 따라 조회 처리를 시작하거나 담당자에게 전달한다.

읽고 판단하여 다음 처리를 선택”이라는 방식으로, 사람의 개입을 줄일 수 있는 가능성이 있습니다. 공식 고객 응대 예시는 대화와 고객 정보를 활용하여 다음으로 취할 조치를 선택하는 구성으로 되어 있습니다. (참조: 공식 고객 응대 예시) 경제적 가치의 창출 원리는 작은 개선이 반복적으로 일어나는 과정에서 비롯됩니다. 설명용 가정을 바탕으로 월 3만 건의 문의에서 확인 및 수정까지 포함하여 평균 1분 단위의 작업을 줄일 수 있다면 월 500시간 분량의 처리 여유가 생깁니다. 같은 인원으로 많은 건을 처리하거나 복잡한 상담에 시간을 투자할 수 있으며, 대응이 빨라지면 고객 대기 시간도 줄일 수 있습니다. 다만 500시간 감소한 만큼 그대로 500시간 분량의 인건비가 절감되는 것은 아니며, 도입 및 운영 비용을 포함하여 실제로 비용이 절감되는지, 아니면 처리량이나 서비스 품질이 향상되는지 확인해야 합니다. 그의 목표는 이러한 작은 의미 이해 및 판단을 다양한 업무 시스템에서 대량으로 활용할 수 있도록 하는 것입니다. 하나의 판단이 매우 복잡하지 않더라도 처리되는 건수가 많다면 전체적인 효과는 커질 수 있습니다. 참고로 앞서 언급한 “큰 경제적 가치를 창출할 수 있는 능력”은 현재 AI의 능력을 적절히 활용한다면 그만큼의 가치를 창출할 수 있다는 그의 판단을 의미합니다. Jev가 이미 그러한 규모의 경제 효과를 실증한 것을 의미하는 것은 아닙니다. (참조: 그들의 구상)

제13장: 작업을 설정하는 인간의 역할

당신의 문제는 Jev가 “적절한 태스크”를 설정하는 능력이 없다는 것입니다. 따라서 현장 담당자들이 그것을 설정해야 한다는 이해로 충분한가요. AI는 그렇다고 대답합니다. 현재 Jev를 업무에서 사용하는 방식으로는, 그 이해로 충분합니다. 현장을 이해하는 사람과 개발자가 먼저 다음 태스크를 설정해야 합니다.

목적: 무엇을 달성하고 싶은가.
평가 기준: 어떤 일을 해냈느냐에 따라 일이 잘 되었다고 말할 수 있는가.
판단할 내용: 어떤 정보를 사용하고 무엇을 판단하게 할 것인가.

제브는 그 설정에 따라 개별적으로 판단하는 역할을 수행합니다.(참조: 공식 문서) 하지만 “그 능력이 전혀 없다”라고 단정하기보다는 “올바른 작업을 발견하고 설정할 수 있는 제품이 아니며, 그 능력 또한 입증되지 않았다”는 표현이 더 정확합니다. 그리고 당신이 지적하는 핵심은 현장의 담당자 스스로가 어떤 것이 올바른 작업인지 파악하지 못하는 경우일 수 있다는 점입니다. 그러한 경우에는 목적이나 암묵적인 판단 기준을 탐색하고, 시도하면서 확인하는 일이 남게 됩니다. 제브 도입만으로는 그 문제가 해결되지 않습니다.

제14장 현장 작업 정의의 어려움

당신이 말하는 것은 솔직함이 부족하여 현장 담당자들이 “정확한 업무”를 설정할 수 있다면 어려움을 겪지 않을 것이다. 그것이 어려운 문제이거나, 귀찮아서 문제 자체가 해결되지 않는 것은 아닐까 생각한다. 이러한 생각에 타당성이 있을까. AI는 그렇다. 특히 “현장 담당자들이 ‘정확한 업무’를 제공해 줄 것이다”라는 전제에 대한 비판은 타당하다. 그곳에 가장 어려운 일이 남아 있을 가능성이 크다. 현장 담당자들이 “어떤 점이 어려운지”를 알고 있는 것과, 무엇을 입력하고, 무엇을 판단하고, 무엇을 성공으로 정의할 수 있는 것은 다르다. 예를 들어 “문의 응대 부담을 줄이고 싶다”는 요구는 명확하지만, 실제로는 다음과 같은 문제가 있다.

이를 어떻게 조화롭게 할 수 있을지 고민해야 할 문제입니다.
숙련된 사람이 예외적으로 하는 대응은 무엇의 근거인가.
처리 건수가 늘어나도 고객의 문제가 해결되지 않았다면 성공이라고 할 수 있는가.

이를 정리하기 위해서는 업무를 관찰하고, 사례를 비교하며, 관계자의 의견을 조율하고, 시도해 결과를 확인해야 합니다. 그 자체의 작업이 어렵고 시간이 걸리기 때문에 개선이 멈추는 상황이 충분히 발생할 수 있습니다. 더불어 “정답의 업무”가 처음부터 하나 존재하고, 그것을 발견했다고 해서 끝이라고 보장할 수 없습니다. 담당자는 꼼꼼함을, 관리자는 처리량을, 고객은 자신에게만 예외적인 대응을 요구할 수 있습니다. 따라서 필요한 것은 숨겨진 정답을 찾는 것뿐만 아니라, 무엇을 우선순위로 할지 결정하고 합의하는 것입니다. 다만, 모든 문제가 이 이유로 해결되지 않은 것은 아닙니다. 예를 들어 “문장에서 문의처를 판별하는” 작업은 명확하지만, 표현이 다양하고 기존 프로그램으로는 처리하기 어려울 수 있습니다. 그러한 목적은 분명하지만 실행을 자동화하기 어려운 부분에는 Jev와 같은 모델이 유용할 여지가 있습니다. 따라서 Jev에 대한 평가는 현장에서 어떤 것이 더 어려운지에 따라 달라집니다.

당신의 지적을 반영할 때, 우리가 고민해야 할 것은 “제브(Jev)에서 판단이 쉽게 쉬는가”뿐만 아니라, “업무를 정의하고, 시스템을 구축하며, 유지하는 데 드는 부담까지 포함하여, 일이 편해지는가”인지 확인해야 합니다. Almeida 교수의 에세이는 업무 선택의 중요성을 지적합니다. 그러나 그 선택을 현장에 맡긴다면, 현장도 그 어려움을 극복할 수 있다는 전제 또한 필요합니다. 그 점을 문제 삼는 당신의 생각은 그의 주장을 부정하는 것보다 오히려, 그 주장을 제품에 엄격하게 적용한 것으로 이해됩니다.

제15장 자동화의 경제성 및 제브의 위상

Jev로 판단 부담이 줄어들지 않느냐” 뿐만 아니라, “업무를 정의하고, 시스템을 구축하며, 유지하는 데 드는 부담까지 포함하여 업무가 편해지는지”를 해결할 수 있다면, Almeida 氏가 말하듯이 “AI 기업의 리더들은 경제의 절반을 자동화한다!”는 반전의 답변이 될 것입니다. 하지만 그의 제품은, 그 문제 제기와 직접적인 관련이 없습니다. Jev로 개선될 수 있는 업무가 있을 수 있습니다. 그것은 빠르고, 저렴하지 않으면 수익을 낼 수 없습니다. 그것에 맞는 AI가 필요합니다. AI는 네, 제품으로서의 위치는 대략 그 이해로 충분합니다. 특히, “어떤 것을 자동화해야 하는지 발견하고, 업무로 정의하는” 문제에 Jev가 직접적인 해결책을 제공하는 것은 아니라는 점은 사실입니다. Jev가 역량을 발휘할 것으로 기대되는 것은 예를 들어 다음 조건이 모두 갖춰진 업무입니다.

판단하고 싶은 바를 어느 정도 명확해지고 있다.
같은 종류의 판단이 다수 발생한다.
비용과 대기 시간이 부담됩니다.
판단 결과를 이어서 소프트웨어 처리에 활용할 수 있다.

그처럼 업무에서 속도와 가격 경쟁력을 높여 자동화의 경제성을 개선한다. 또한, 프로그램이 사용하기 쉬운 출력을 제공하고 불확실성에 따른 처리 분배를 지원하는 것이 Jev의 목표다. 다만 “문제 제기 및 직접 관련이 없는” 것으로 완전히 분리하는 것보다 “많은 문제 제기 중 판단 실행 부분의 개선에 집중하고 있다”라고 표현하는 것이 더 정확하다. 그리고 당신이 지적하는 격차는 여전히 존재하며, 그 부분의 개선이 업무 발견, 설계, 유지까지 포함하는 자동화 전체를 얼마나 발전시킬 수 있는가에 따라 달라진다. 이는 Jev가 단순히 빠르고 저렴하다는 것만으로는 설명할 수 없으며, “특정 업무에서 유용한 제품으로서의 가치”와 “경제 규모의 자동화에 대한 답변으로 자리매김하고 있는 것”은 별개로 입증해야 할 주장이다.

제16장 공개된 계획과 남은 질문

당신이 그렇게 생각한다면 알메이다 씨의 구상 전체적인 모습은 아직 제시되지 않았을 수도 있습니다. AI의 가능성은 존재합니다. 공개된 자료를 통해 “큰 방향성은 제시하고 있지만, 실현을 위한 구체적인 단계는 아직 충분히 밝혀지지 않았다”는 견해가 지배적일 것 같습니다. 공식 성명서에서는 다음 단계를 제시하고 있습니다.

소프트웨어에 통합 가능한 AI를 제공합니다.
실제 자동화를 지원할 수 있을 때까지 신뢰성을 높인다.
그 위에 쌓여 더욱 정교한 지적 기능을 제공한다.

이 제안에서 Jev는 출발점으로 이해할 수 있습니다. (참조: 공식 성명서) 다만, 그 이후에 우리가 논의해 온 “현장의 암묵지를 탐색하고 올바른 작업을 정의하는 시스템”까지 포함되는지 확인하기 어렵습니다. 향후 제품에서 이 부분을 다루거나, 현장이나 다른 회사의 개발자에게 맡기는 방안도 고려할 수 있습니다. 따라서 “지금의 Jev가 그의 제안의 전부”라고 단정짓는 것은 적절하지 않습니다. 반면, “미공개된 제안이 이 난제에도 해결책을 제시할 것이다”라는 기대감으로 보완하는 것은 불가능합니다. 앞으로 그가 어떤 것을 제품으로 제시하고, 어디까지를 누가 담당할 것인지 설명하는 것이 판단의 기준이 될 것입니다.

제17장 고성능 모델과의 협력 및 작업 개선

■현재 Jev의 정확도를 높여 소프트웨어에 통합하고 시장 점유율을 확대하는 방안입니다. 이 부분은 단순 업무에만 국한되므로 다른 AI 모델과는 생태계가 다릅니다. 예상대로 되지 않는 부분이 있다면 고성능 모델과 함께 Jev의 데이터를 활용하여 “적합한 작업”에 대한 추론에 사용하는 것이 일반적인 접근 방식일까요. ■AI는 그렇습니다. Jev를 활용한 시스템 설계는 자연스럽고 유력한 방향입니다. 실제로 공식 자료에도 Jev로 요청을 분류하고, 일반 프로그램, 다른 AI 모델, 인간에게 배분하는 구성이 제시되어 있습니다. (참조: 공식 배분 예시). 다만 “단순 업무에만 국한되므로 생태계가 다르다”는 부분은 복잡한 업무 중에서도 범위를 좁힌 개별적인 판단을 담당한다고 보았을 때 더 정확합니다. 다른 모델과 동일한 시스템 안에서 역할을 분담할 수 있습니다. 세 가지 역할 제안 구성은 다음과 같이 정리할 수 있습니다.

여기서는 어려운 사례를 다른 모델에 맡겨 해결하게 하고, “そもそも何を解くべきか”를 재검토하는 것을 분리해야 합니다. 제안의 후반부가 중요한 이유는 세 번째 단계까지 포함하고 있기 때문입니다. 운영의 실패로부터 업무를 재구성하는 예를 들어, Jev에 의한 문의 분류가 정확한데 고객으로부터 재문의가 빈번하게 발생한다고 가정해 봅시다. 운영 결과를 조사하면 “담당 부서를 정확하게 선택하는 것”만으로는 부족하고 “필요한 정보를 종합하여 전달하는 것”이 필요하다는 것을 알 수 있습니다. 그렇게 되면 실제 실패로부터 처음 설정한 작업의 부족을 발견하고 재구성하게 됩니다. 여기서 고성능 모델은 작업 설계의 보조에 활용될 수 있습니다. 다만, 그 추론에 필요한 것은 Jev의 출력만은 아닙니다. 원래 요청, Jev의 판단, 인간이 수행한 수정, 최종적으로 문제가 해결되었는지를 함께 고려해야 합니다. Jev의 출력만으로는 Jev 스스로 놓친 정보를 발견할 수 없습니다. 이번에 확인한 공식 자료에는 이 발상과 유사한 구현 예시가 있었습니다. 다른 LLM이 질문을 제안하고, Jev가 방대한 텍스트에 답변하고, 실제 정답 데이터로 예측 성능을 평가하고, 오류를 LLM에 반환하여 질문을 개선하는 방식입니다. 와인 평가 문장에서 평가 점수를 예측하는 예시입니다. 다만, 이는 미리 정해진 목적에 맞는 질문을 탐색하는 메커니즘이며, 업무의 목적 자체를 발견하는 실증적인 방법은 아닙니다. (참조: 공식 질문 탐색 및 개선 예시) 따라서 “Jev로 일상적인 판단을 처리하고, 그 운영으로부터 얻은 증거를 활용하여 고성능 모델과 인간이 업무 설계를 개선한다”는 구성은 충분히 고려될 수 있습니다. 이는 작업 설정을 한 번에 완료하는 부담을 덜어내는 방향입니다. Almeida 씨의 구체적인 사업 계획인지 여부는 공개된 자료만으로는 단정할 수 없습니다.

출처: note 원문

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

원문 보기 | 출처: note.com