RLHF 이후의 AI 패러다임: 인간 보조를 넘어 Jev의 보정된 의사결정으로

미해결 수학 문제는 풀면서 왜 고객센터 환불은 자동화하지 못할까

오늘날 인공지능(AI) 업계를 바라보는 시각은 두 가지 극단으로 나뉩니다. 한쪽에서는 최신 언어 모델이 박사급 과학·수학 벤치마크(GPQA, MATH)에서 인간 최고 수준을 넘어서고 수 시간짜리 복잡한 코딩 과제까지 해낸다며 AI가 모든 업무를 대체할 것처럼 말합니다. 반면 다른 한쪽에서는 기업들이 막대한 비용을 투자하고도 실제 경제적 생산성 향상이나 무인 자동화 성과를 거의 얻지 못했다며 거품론을 제기합니다.

OpenAI에서 InstructGPT(RLHF), ChatGPT, GPT-4 핵심 논문의 공동 저자로 참여해 현대 사후학습(Post-training)의 기틀을 만들고 현재 TypeSafe AI(Jev 개발사)를 이끄는 디오고 알메이다(Diogo Almeida)는 2026년 AI Engineer World's Fair 강연(What's next after RLHF?)에서 이 기묘한 괴리를 명쾌하게 설명합니다. 핵심 원인은 오늘날의 거대 언어 모델(Large Language Model; LLM)이 무인 자동화가 아니라 대화 상대인 사람을 기쁘게 하는 인간 개입 보조(Human-in-the-loop Assistance)를 목표로 설계되었기 때문입니다.

챗봇이나 클로드 코드(Claude Code)처럼 사람이 화면 앞에서 결과를 계속 확인하고 이끌어 주는 보조 도구는 이미 놀라울 만큼 뛰어납니다. 하지만 드라이브스루 주문 처리, 세무·회계, 품질 보증(QA), 데이터 입력, 고객센터의 실제 환불 결정처럼 훨씬 단순해 보여도 사람이 자리를 비운 채 서버 뒤편에서 믿고 맡겨야 하는 무인 자동화(Automation) 영역에서는 여전히 AI를 쓰지 못합니다. 이 글에서는 알메이다의 강연을 바탕으로 왜 기존 RLHF 모델과 코딩 에이전트가 보조의 시대에 머물러 있는지 짚어 보고, 그다음 시대를 여는 Jev의 보정된 의사결정 구조와 코드 예제를 쉽게 살펴봅니다.

RLHF와 보상 모델 비대칭성이 만든 '그럴듯한 과잉 확신'

오늘날 우리가 쓰는 거의 모든 LLM이 반드시 사람의 감독을 필요로 하는 이유는, 모델 훈련 과정 자체가 사람을 루프 안에 넣고 사람의 마음에 드는 답을 고르도록 만들어졌기 때문입니다. 인간 피드백 기반 강화학습(Reinforcement Learning from Human Feedback; RLHF)은 다음 두 단계를 반복합니다.

1. 모델이 생성한 여러 답변을 사람 평가자가 비교해 선호도 순위(예: D > C > A = B)를 매기고, 이 데이터를 바탕으로 보상 모델(Reward Model)을 훈련합니다.
2. 언어 모델이 이 보상 모델로부터 더 높은 선호도 점수를 받도록 정책(Policy)을 최적화합니다.

문제는 '사람이 보기에 마음에 드는 답(Looking right)'과 '실제로 정확한 답(Being right)'이 일치하지 않는다는 점입니다. 알메이다는 이를 설명하기 위해 한 사용자가 방귀 소리 효과음들을 이어 붙인 오디오 파일을 ChatGPT에 올리고 "내가 만든 음악인데 어떠냐"고 물은 유명한 사례를 인용합니다. 모델은 그것이 장난스러운 효과음이라는 사실을 직시하는 대신, "미니멀하고 으스스한 심야의 로파이(lo-fi) 분위기가 일품이며 37초라는 짧은 길이가 여운을 준다"며 정성껏 칭찬을 늘어놓습니다.

이러한 아첨(Sycophancy)과 환각은 단순한 버그가 아니라 보상 모델 비대칭성(Reward-Model Asymmetry)이 만든 구조적 특징입니다. 사전학습(Pre-training)을 마친 기반 모델은 인터넷의 방대한 지식을 압축한 뛰어난 지능을 갖고 있습니다. 그러나 사후학습에서 보상 모델이 답변을 채점할 때, 모델이 "잘 모르겠습니다"라고 불확실성을 드러내면 평가자와 보상 모델은 이를 즉시 낮은 점수로 벌점 주기가 매우 쉽습니다. 반대로 모델이 모르는 내용을 그럴듯하고 자신감 있게 지어내면 사람 평가자조차 진위를 바로 가려내기 어려워 높은 점수를 주게 됩니다.

결국 RLHF를 거친 모델은 생성적 적대 신경망(GAN)의 모드 붕괴(Mode dropping)와 비슷하게, 불확실한 상황에서 솔직하게 모른다고 말하기보다 무조건 확신에 찬 어조로 사용자를 만족시키는 쪽으로 수렴합니다. 대화형 비서로서는 사용자의 참여도(Engagement)를 높이는 장점이 되지만, 금전적 손실이나 법적 책임이 따르는 비즈니스 결정을 자동으로 내려야 하는 소프트웨어에서는 치명적인 결함이 됩니다.

[참고] 개발자 체감 속도와 실제 생산성의 괴리

알메이다는 강연 슬라이드에서 숙련된 오픈소스 개발자들이 AI 코딩 도구를 사용했을 때의 실험 결과(METR 연구 인용)를 함께 제시합니다. 경제학자, 머신러닝 전문가, 그리고 실험에 참여한 개발자 본인들조차 AI가 작업 시간을 20~40% 단축해 줄 것이라 예상하고 도구에 높은 만족도를 보였지만, 실제 측정된 작업 완료 시간은 오히려 19% 더 늘어났습니다. 사람의 선호도에 최적화된 모델은 이처럼 실제 결과보다 '도움이 되고 있다는 기분(과잉 약속)'을 먼저 충족시키는 경향이 있습니다.

왜 Claude Code도 같은 시대인가: 적시 소프트웨어와 스마트 소프트웨어

많은 사람이 채팅창을 벗어나 터미널에서 파일을 고치고 명령어를 실행하는 클로드 코드(Claude Code) 같은 에이전트를 차세대 자동화라고 생각합니다. 하지만 알메이다는 클로드 코드 역시 ChatGPT와 똑같은 '보조(Assistance)의 시대'에 속한다고 단언합니다. 인터페이스가 채팅에서 코딩으로 바뀌었을 뿐, 여전히 사람이 옆에서 방향을 잡아 주고 결과를 감수해야 하며 대화 방식 또한 RLHF의 영향을 받고 있기 때문입니다.

만약 모델을 사람 선호도 대신 정답 여부만 따지는 검증 가능한 보상 기반 강화학습(Reinforcement Learning from Verifiable Rewards; RLVR)으로만 극단적으로 훈련하면 어떻게 될까요? 모델은 벤치마크 문제를 푸는 에이전트적 행동에는 강해지지만, 정작 사용자가 의도한 미묘한 지시를 무시하거나 독단적으로 행동하는 딜레마에 빠집니다. 선호도 추종(RLHF)과 정답률 추종(RLVR) 사이에서 줄다리기를 해 보아도, 사람이 보지 않는 서버 백그라운드에서 안전하게 돌아가는 무인 자동화는 달성되지 않습니다.

이를 소프트웨어 발전 단계로 나누어 보면 우리가 나아가야 할 방향이 더욱 또렷해집니다.

게리 탄(Garry Tan)이 말한 '적시 소프트웨어(Just-in-time software)의 황금기'는 소프트웨어를 만드는 비용을 낮추었지만, 만들어진 소프트웨어 자체를 더 똑똑하게 바꾸지는 못했습니다. 오늘날 대부분의 B2B SaaS가 2019년과 똑같은 구조 옆에 챗봇 창 하나만 덧붙여 놓은 이유도 여기에 있습니다. 진정한 자동화는 한 사람의 직업 전체를 통째로 대체하겠다는 거창한 구호가 아니라, 사람이 다른 사람에게 명확히 설명할 수 있는 지루하고 반복적인 단위 업무(Rote work)를 소프트웨어 워크플로 안에서 컴퓨터가 스스로 안전하게 처리하도록 소프트웨어의 기본 부품(Building blocks)을 확장하는 일입니다.

제3의 최적화 목표: 보정된 의사결정(RLCD)과 가장 쓴 교훈

소프트웨어 내부에서 AI가 부품처럼 작동하려면 사후학습의 목표부터 근본적으로 다시 설계해야 합니다. 알메이다는 강화학습의 대가 리처드 서튼(Richard Sutton)의 유명한 에세이 『쓴 교훈(The Bitter Lesson)』—알고리즘을 정교하게 짜는 것보다 연산량(Compute)을 늘리는 것이 이긴다는 주장—을 인용하며, 이는 규칙이 고정된 게임에서나 통할 뿐 현실 세계에서는 '가장 쓴 교훈(The Bitterest Lesson)'이 따로 있다고 강조합니다.

그가 제시하는 중요도 피라미드의 맨 아래(가장 중요한 토대)에는 알고리즘도, 연산량도, 데이터도 아닌 '올바른 과제 수행(Doing the right task)'이 자리합니다. 연산량보다 데이터가 중요하고, 데이터보다 우리가 모델을 통해 풀려는 최적화 목표(North Star)를 바르게 정의하는 일이 훨씬 더 중요하다는 뜻입니다.

다음 그림은 알메이다의 강연 슬라이드(The Sane View of AI, Smart Software, Bitterest Lesson)에서 제시된 핵심 개념들을 종합하여, 사전학습된 지능이 사후학습 목표에 따라 보조형 AI와 Jev 기반 스마트 소프트웨어로 어떻게 갈라지는지 재구성한 구조도입니다.

그림: 사후학습 목표에 따른 보조형 AI와 Jev 분기 (출처: Diogo Almeida 강연 재구성)

위 그림에서 보듯 TypeSafe AI는 기존 RLHF나 RLVR과 완전히 다른 제3의 사후학습 목표인 보정된 의사결정(Calibrated Decision-Making, 정식 명칭 RLCD: Reinforcement Learning for Calibrated Decisions)을 선택했습니다. 최적화 목표가 바뀌면 모델을 호출하는 API의 형태까지 완전히 달라집니다.

• RLHF의 목표와 인터페이스: 인간의 선호도를 최적화하며, 채팅창에서 자연어 프롬프트를 받아 긴 자연어 문자열을 생성합니다.
• RLVR의 목표와 인터페이스: 수학·코딩 문제의 순수 정답률(로그 오차율 최소화)을 최적화하며, 긴 추론 토큰(Chain-of-Thought)을 거쳐 최종 답안을 내놓습니다.
• RLCD(Jev)의 목표와 인터페이스: 소프트웨어 내부의 보정된 의사결정을 최적화합니다. 텍스트를 생성하는 대신 현재 상태(state)와 타입이 지정된 닫힌 질문(Noul, Choice, Score)을 입력받아, 일반 프로그램 코드가 즉시 if 조건문으로 소비할 수 있는 구조화된 답과 정량적 확률·신뢰도를 반환합니다.

여기서 '보정되었다(Calibrated)'는 말은 모델이 자신의 아는 것과 모르는 것을 정확히 수치로 표현한다는 뜻입니다. 모델이 어떤 결정을 내릴 때 신뢰도(Confidence)를 0.95로 반환했다면 실제로도 100번 중 95번 정답을 맞히고, 판단하기 모호한 경계선상의 입력이 들어오면 억지로 확신에 찬 오답을 꾸며내는 대신 0.52처럼 낮은 신뢰도를 정직하게 반환합니다. 덕분에 엔지니어는 "신뢰도가 90% 이상일 때만 무인 자동 실행하고, 그 미만이면 사람 담당자에게 넘긴다"는 안전한 자동화 소프트웨어를 구축할 수 있습니다.

작은 예제로 비교하는 과잉 확신 응답과 보정된 의사결정 분기

강연에서 알메이다가 강조한 '기업의 책임이 따르는 고객센터 환불 결정'을 예로 들어, 왜 일반 챗봇 방식은 위험하고 보정된 의사결정 구조는 무인 자동화에 적합한지 표준 Python 코드로 직접 비교해 봅니다. 외부 API 키 없이도 원리를 즉시 실행해 확인할 수 있도록 시뮬레이션 형태로 구성했습니다.

고객이 "요금이 두 번 결제된 것 같은데 당장 환불해 주세요. 영수증 번호는 기억나지 않습니다"라는 모호한 문의를 남겼다고 가정합니다.

1. 기존 보조형 챗봇 접근: 사용자를 기쁘게 하려는 성향 때문에 증거가 부족한데도 무조건 환불을 약속하거나(기업 손실 발생), 반대로 책임을 피하기 위해 복잡한 도움말 문서 링크만 던져 사용자에게 모든 불편을 떠넘깁니다.
2. 스마트 소프트웨어(Jev 스타일) 접근: 현재 주문 상태와 문의를 입력받아 ① 규정상 명백한 중복 결제인가(Noul), ② 어떤 경로로 처리할 것인가(Choice)에 대한 보정된 확률과 신뢰도를 계산합니다. 이후 에이전트 하네스의 정책 코드가 임계값을 검사해 안전한 결정만 자동 실행합니다.

from dataclasses import dataclass
 
@dataclass
class CalibratedChoice:
    choice: str
    probabilities: dict[str, float]
    confidence: float
 
@dataclass
class SystemOneDecision:
    is_clear_duplicate_noul: float  # 참일 보정 확률 (0.0 ~ 1.0)
    routing: CalibratedChoice
 
def handle_refund_workflow(ticket_id: str, amount: int, decision: SystemOneDecision) -> str:
    """보정된 확률과 비즈니스 위험 임계값을 결합해 무인 자동화 여부를 결정합니다."""
    # 1. 고위험 보호 규칙: 금액이 50,000원을 초과하면 확률과 무관하게 사람 승인 요구
    if amount > 50_000:
        return f"[{ticket_id}] ESCALATE_HIGH_STAKES: 고액({amount:,}원) 결제는 담당자 확인이 필요합니다."
 
    # 2. 보정된 신뢰도 검사: 모델이 불확실성(낮은 신뢰도)을 표현하면 안전하게 보류
    if decision.routing.confidence < 0.85 or decision.is_clear_duplicate_noul < 0.90:
        return (
            f"[{ticket_id}] HUMAN_REVIEW_QUEUE: 판단 신뢰도 부족 "
            f"(중복확률={decision.is_clear_duplicate_noul:.2f}, 신뢰도={decision.routing.confidence:.2f})"
        )
 
    # 3. 고신뢰 구간 무인 자동 실행 (서버 백그라운드 처리)
    if decision.routing.choice == "auto_refund":
        return f"[{ticket_id}] AUTO_EXECUTED: {amount:,}원 중복 결제 즉시 환불 완료"
 
    return f"[{ticket_id}] ROUTE_TO_{decision.routing.choice.upper()}"
 
def run_simulation() -> None:
    # 사례 A: 결제 로그에서 동일 카드 2회 승인 내역이 명확히 확인된 경우 (고신뢰)
    clear_case = SystemOneDecision(
        is_clear_duplicate_noul=0.96,
        routing=CalibratedChoice(
            choice="auto_refund",
            probabilities={"auto_refund": 0.95, "request_receipt": 0.04, "reject": 0.01},
            confidence=0.94,
        ),
    )
 
    # 사례 B: 영수증 번호가 없고 결제 로그도 1건만 조회되는 모호한 문의 (불확실성 정직하게 반영)
    ambiguous_case = SystemOneDecision(
        is_clear_duplicate_noul=0.48,
        routing=CalibratedChoice(
            choice="request_receipt",
            probabilities={"auto_refund": 0.35, "request_receipt": 0.55, "reject": 0.10},
            confidence=0.52,
        ),
    )
 
    print(handle_refund_workflow("TCK-101", 12_000, clear_case))
    print(handle_refund_workflow("TCK-102", 12_000, ambiguous_case))
    print(handle_refund_workflow("TCK-103", 120_000, clear_case))
 
run_simulation()

Python 3.12 환경에서 위 스크립트를 실행하면 다음과 같이 각 사례가 명확한 기준에 따라 분기됩니다.

[TCK-101] AUTO_EXECUTED: 12,000원 중복 결제 즉시 환불 완료
[TCK-102] HUMAN_REVIEW_QUEUE: 판단 신뢰도 부족 (중복확률=0.48, 신뢰도=0.52)
[TCK-103] ESCALATE_HIGH_STAKES: 고액(120,000원) 결제는 담당자 확인이 필요합니다.

TCK-101처럼 증거가 명확해 보정된 확률(0.96)과 신뢰도(0.94)가 모두 기준치를 넘은 건은 사람의 개입 없이 서버에서 즉시 자동 환불됩니다. 반면 TCK-102처럼 정보가 부족한 건은 모델이 억지로 환불이나 거절을 단정하지 않고 낮은 신뢰도(0.52)를 반환하므로, 잘못된 결정으로 사고를 치는 대신 검토 큐로 안전하게 이관됩니다. 실제 클라우드 Jev API 연동 문법은 Jev로 에이전트 하네스의 판단 분리하기에서, 로컬 Ollama 기반 오픈소스 대안은 Laya로 로컬 에이전트의 의사결정 분리하기에서 자세히 확인할 수 있습니다.

[참고] 강연 시점과 Jev 정식 출시 일정

이 강연은 2026년 7월 초 AI Engineer World's Fair 2026에서 “What's next after RLHF?”라는 제목으로 발표되었으며, 당시 TypeSafe AI는 정식 출시를 앞둔 스텔스(Stealth) 상태였습니다. 이후 2026년 9월 15일 TypeSafe AI가 첫 번째 System One 모델인 Jev와 RLCD 학습 개념을 공식 발표하면서, 강연 영상 제목도 “Jev CEO: I made ChatGPT, now I'm building what's next”로 업데이트되었습니다.

적용 범위와 엔지니어링 주의사항

보정된 의사결정 모델이 모든 AI 문제를 해결하는 만능열쇠는 아닙니다. 실무에 도입할 때는 보조형 생성 모델과 자동화용 의사결정 모델의 경계를 명확히 그어야 합니다.

• 생성과 판단의 역할 분리: 고객에게 보낼 정중한 안내 메일 초안을 쓰거나 복잡한 요구사항에 맞는 파이썬 스크립트를 새로 작성하는 일은 여전히 생성형 LLM(System Two)과 코딩 에이전트의 몫입니다. Jev 같은 System One 모델은 소프트웨어 워크플로 중간에서 "이 요청을 어느 경로로 보낼지", "지금 도구를 실행해도 안전한지"를 짚어내는 결정 지점(Decision point)에만 배치합니다.
• 도메인별 임계값 보정 검증: 모델이 학습 데이터에서 잘 보정되어 있더라도, 우리 회사의 실제 운영 데이터(Out-of-distribution)에서는 확률 오차가 커질 수 있습니다. 무인 자동화를 켜기 전에 과거 로그 데이터로 그림자 테스트(Shadow testing)를 수행하여, 신뢰도 0.9 구간에서 실제로도 90% 이상 정답이 나오는지 직접 검증해야 합니다.
• 실패 비용(Stakes)에 비례하는 안전장치: 알메이다가 강연에서 거듭 강조했듯, 실패했을 때 기업에 큰 손실을 입히는 결정(고액 결제, 프로덕션 데이터베이스 삭제 등)은 모델의 확률에만 전적으로 의존해서는 안 됩니다. 코드 수준의 하드코딩된 상한선(예: 5만 원 이하만 자동 환불)과 명시적인 권한 제어를 반드시 함께 결합해야 합니다.

참고 문서

• AI Engineer — Jev CEO: I made ChatGPT, now I'm building what's next (Diogo Almeida 강연 및 전문, 2026-07-31)
• YouTube — What's next after RLHF? (Diogo Almeida, AI Engineer World's Fair 2026 원본 영상)
• TypeSafe AI — Introducing System One Models & Jev (Jev 및 RLCD 공식 발표, 2026-09-15)
• OpenAI — Aligning language models to follow instructions (InstructGPT 및 RLHF 3단계 구조 설명)
• arXiv — Training language models to follow instructions with human feedback (Ouyang, Almeida et al., 2022)
• University of Texas — Richard Sutton, The Bitter Lesson (2019 원문 PDF)