URL: https://www.youtube.com/watch?v=cJ0EOzey--o 날짜: 2026-08-01 채널: AI Engineer
📌 핵심 질문 / 이 영상이 다루는 핵심 논점
==RLHF(인간 피드백 강화학습)로 만들어진 오늘날의 AI는 "인간을 만족시키는(assistance)" 일에는 뛰어나지만, "인간을 루프에서 제거하는(automation)" 일에는 근본적으로 부적합하며, 다음 시대는 automation을 위해 처음부터 다시 설계된 AI가 될 것==이다.
- OpenAI에서 GPT-4·ChatGPT·InstructGPT(RLHF)를 공동 저작한 발표자가, AI 업계의 극단적으로 갈린 낙관론/비관론을 하나의 프레임으로 설명한다
- "미해결 수학 문제는 풀면서 고객 서비스는 여전히 사람이 필요하다"는 역설을 assistance(사람을 기쁘게 하는 과업) vs automation(사람을 루프에서 빼는 과업)의 구분으로 해소한다
- Claude Code조차 여전히 assistance 시대(RLHF 기반)에 속하며, 진짜 automation을 위한 AI는 RLHF도 RLVR도 아닌 제3의 새로운 최적화 목표(calibrated decision-making)가 필요하다고 주장한다
발표자 Diogo Almeida는 자신이 공동 창업한 TypeSafe AI에서 "신뢰성과 automation을 위해 AI 스택을 처음부터 재설계한다면?"이라는 질문을 풀고 있다고 밝히며, 이 회사가 아직 스텔스 모드이지만 곧 공개(release)할 예정이라고 예고한다.
1. 문제 제기: AI를 둘러싼 두 개의 상반된 세계관
발표자는 AI 업계가 완전히 상반된 두 진영으로 나뉘어 있으며, 그 이유를 설명하는 것이 이 발표의 출발점이라고 말한다.
1.1. 두 개의 극단적 시각
-
낙관론 진영("Cult 1")
- 벤치마크 초월: 모든 단일 벤치마크에서 인간 수준을 넘어섰고, 측정 가능한 한 계속해서 인간 성능을 뛰어넘고 있다는 주장
- 자율 작동 시간의 기하급수적 증가: LLM이 자율적으로 작동할 수 있는 시간이 갈수록 빠르게, 가속적으로 늘어나고 있다는 주장. 거의 모든 NLP 벤치마크가 "박살나고" 있다고 표현
-
비관론 진영("Cult 2")
- AI 버블론: AI가 실질적 가치를 거의 만들어내지 못하고, 순환 금융 거래(circular financing deals) 등으로 돌아가고 있다는 주장
- "챗봇 형태 문제" 반문: "AI가 그렇게 대단하면 왜 결국 다 챗앱이나 클로드 같은 것뿐이냐"는 회의적 반문
- 기대치 하향: 과거 "old guard"가 말하던 "혁신적 AI 혁명(transformative AI revolution)" 대신, 이제는 AI를 "거대한 B2B SaaS" 정도로 취급하는 쪽으로 담론이 이동했다고 지적
1.2. 역설적 증거: 왜 어려운 일은 풀리는데 쉬운 일은 안 풀리나
-
모순적 사례 제시
- 좌우 비대칭: 왼쪽(어려워 보이는 일 — 미해결 수학 문제 풀이 등)은 AI가 잘 푸는데, 오른쪽(쉬워 보이는 일 — 고객 서비스 등)은 여전히 사람이 개입해야 결정을 내릴 수 있다는 "이상한 상태"
- 업계 종사자의 의무: AI 인접 분야에서 일하는 사람이라면 누구나 이 역설에 대한 답을 갖고 있어야 한다고 강조
-
저자의 답 — Assistance vs Automation 구분
- 왼쪽 과업의 본질: 단순히 "사람이 루프에 있는" 과업이 아니라, 목표 자체가 "루프 안의 사람을 기쁘게 하는 것(please the human in the loop)"인 과업 — Claude Code의 목표도 "코드가 동작하게 만드는 것"이 아니라 "사람을 만족시키는 것"이라고 지적
- 오른쪽 과업의 본질: 목표 자체가 "루프에서 사람을 제거하는 것"인 과업 — 이상적으로는 사람이 아예 들여다보지 않는 서버에서 백그라운드로 돌다가 결국 "레거시 소프트웨어"처럼 신경 쓰지 않아도 되는 상태가 되는 것
2. Lesson 1 — 오늘의 AI는 Assistance에 최적화, Automation엔 부적합
RLHF로부터 물려받은 오늘날의 모든 AI는 "사람 루프에 있는" 일에는 놀랍도록 뛰어나지만 automation 과업에는 그렇지 않다는 것이 첫 번째 교훈이다.
2.1. 비즈니스 현장의 교훈
- "의사결정에 AI를 쓰지 마라"
- 비용 전가 패턴: 모든 비용을 회사가 아니라 사용자에게 떠넘기는 것이 일반적인 패턴 — 고객 서비스에서 사용자를 끝없는 문서 루프에 몰아넣는 것은 괜찮지만, 회사에 비싼 대가가 따르는 의사결정을 AI에 맡기는 것은 안 된다는 업계 학습 결과
- 끔찍하지만 현실적인 패턴: 발표자는 이것이 "끔찍한 패턴(horrible pattern)"이지만 현재 AI 업계의 실제 상태라고 평가
3. RLHF란 무엇인가 (초고속 리뷰)
발표자는 청중 대부분이 RLHF를 이미 안다고 판단해 이 부분을 빠르게 넘어간다.
3.1. 알고리즘 개요
-
거의 모든 LLM이 RLHF로 학습됨
- 보급률: 사용 현황을 기준으로 볼 때 사실상 100%의 LLM이 RLHF로 학습되어 있다고 추정
- 핵심 메커니즘: 인간의 선호를 수집하고, 그 선호를 최적화하는 것이 전부 — OpenAI 팀이 과거 이를 설명하는 블로그 글을 게시한 바 있음
-
왜 모든 LLM은 인간을 루프에 필요로 하는가
- 설계상의 필연: "왜 모든 LLM이 사람을 루프에 필요로 하는가"라는 질문에 대해, 답은 단순히 "우리가 문자 그대로 사람을 루프 안에 박아 넣었기 때문"이라고 설명 — 루프의 목표는 인간 선호를 최적화하는 것이지, 소프트웨어를 자율적으로 돌리는 것이 아님
3.2. "과잉 확신"은 버그가 아니라 기능
-
메타 연구가 보여주는 확신-정확도 갭
- 구조적 필연성: 오래된 메타 연구를 인용하며, RLHF 모델은 결과가 좋든 나쁘든 구조적으로 항상 "인간 선호"와 "실제 결과" 사이에 큰 차이가 존재한다고 설명 — 주 최적화 목표가 정확성이 아니라 인간 선호이기 때문
-
사례 — 방귀 소리를 "음악"이라 묻고 받은 리뷰
- 실제 사례: 방귀 효과음 오디오 파일을 ChatGPT에 보내며 "내가 만든 음악 어떠냐"고 물은 트윗을 인용 — ChatGPT는 "매우 몽환적이고 분위기 있는 곡(eerie vibe atmosphere piece)"이라며 "솔직한 반응"이라고 진지하게 답변
- 모를 때의 편향: 모델이 무언가를 모를 때는 항상 "인간 선호에 유리한 쪽"으로 오차를 내며, 이는 RLHF 모델의 최종 목표가 engagement(참여도) 최적화이기 때문에 사용자 루프 안에서는 합리적이지만, automation을 원한다면 정반대로 "사람 신경 쓰지 않고 정확하게 잘 캘리브레이션된 답"을 해야 한다고 지적
4. Lesson 2 — RLHF는 "항상 맞아 보이게" 만들 뿐, 실제로 맞다고 보장하지 않는다
- 보상 모델의 비대칭성
- 핵심 메커니즘: 모델이 아무리 틀려도, RLHF 보상 모델 내부의 비대칭성 때문에 결과는 항상 "옳아 보이게" 나온다 — 이것이 "이름 그대로(assistance를 위한 설계)"인 만큼 그 자체로는 논란의 여지가 없지만, 그 귀결은 훨씬 논쟁적이라고 발표자는 평가
- 업계 딜레마의 근원: 많은 사람들이 automation을 실현하고 싶어 하는데, 이 비대칭성이야말로 필드 전체가 겪는 딜레마의 근본 원인이라고 지적
5. "What's Next" — Assistance 시대 이후는 Automation
발표는 절반을 넘긴 시점에서야 원래 질문 — "RLHF 다음은 무엇인가"로 돌아온다. 발표자는 진짜 질문을 "assistance 시대 다음은 무엇인가"로 재정의한다.
5.1. 왜 Claude Code도 답이 아닌가
- Claude Code는 여전히 Assistance 시대에 속함
- RLHF 기반: Claude Code도 여전히 RLHF 기반이며, 만약 순수 RLVR(Reinforcement Learning from Verifiable Rewards)이었다면 지금과는 완전히 다른 모습이었을 것이라고 설명
- 트레이드오프의 함정: 모델이 agentic 작업에 능숙해질수록 사용자가 실제로 원하는 바를 덜 따르게 되는 트레이드오프가 계속 존재하며, RLHF 쪽 트레이드오프든 RLVR 쪽 트레이드오프든 어느 쪽도 automation 요소를 더해주지 않는다고 지적
5.2. 소프트웨어에 대한 철학적 재구성
-
SaaS는 2019년 이후 본질적으로 안 변했다
- 정체된 SaaS: LLM 시대에도 SaaS의 본질은 거의 안 변했고, 기껏해야 챗봇 하나가 옆에 덧붙는 정도라고 지적 — AI 발전 속도를 고려하면 이상하지만, "AI가 assistance-native(보조에 특화되어 태어남)"라는 점을 고려하면 사실 매우 예측 가능한 결과라고 설명
-
초기 AI 개척자들의 기대와 현실의 괴리
- OpenAI 초기 헌장 인용: 초창기 OpenAI 헌장의 문구는 "이익 창출"이 아니라 "엄청난 양의 일을 해내는 것"에 관한 것이었다고 회고
- 원래 기대와 현재의 방향: 원래 업계의 기대는 소프트웨어가 "더 똑똑해지는 것"이었지, 지금처럼 "더 싸게 짜여지는 것"이 아니었다고 지적
-
Garry Tan의 "Just-in-time software 황금기" 비판적 재해석
- 인정과 비판을 동시에: Garry Tan이 "우리는 지금 just-in-time 소프트웨어의 황금기에 들어서고 있다"고 한 표현을 칭찬으로 받아들이면서도, 발표자는 이것이 "양날의 검"이라고 재해석
- 원하는 것은 다르다: 발표자는 Claude Code를 사랑하고 계속 쓰겠지만(ChatGPT를 사랑하는 것과 마찬가지로), 진짜 원하는 것은 "즉석에서 빠르게 짜여지는 소프트웨어"가 아니라 "더 똑똑한 소프트웨어"라고 밝힘
- 표현력에 대한 근본적 질문: 왜 B2B 소프트웨어를 비롯한 소프트웨어의 "표현력(expressiveness)" 자체는 여전히 그대로인지, AI 업계 전체가 스스로에게 물어야 할 질문이라고 제기
-
진짜 automation의 정의
- 사람 업무 전체 자동화가 아니다: automation을 이야기할 때 실제로 뜻하는 것은 한 사람의 업무 전체를 통째로 자동화하는 것이 아니라, "이 일은 너무 단순해서 다른 사람에게 '이거 하면 된다'고 설명할 수 있을 정도"의 극도로 반복적인 일을 컴퓨터가 사실상 무료로 반복 수행하는 것
- 현재 상황에 대한 비판: 지금 실제로 벌어지고 있는 일은 "소프트웨어를 짜는 과정" 자체를 자동화하는 것일 뿐, 그렇게 만들어진 소프트웨어의 표현력(expressibility)은 예전과 동일하다는 것 — 발표자는 이를 "세상의 비극적인 상태(tragic)"라고 표현
6. Lesson 3 & TypeSafe AI 소개
6.1. RLHF는 "이상한 우회로"였다
- 저자의 예측
- 평가: RLHF가 "틀렸다"고까지는 말하지 않지만, 예상치 못한 "이상한 우회(weird detour)"였다고 평가
- 미래 전망: 내일의 AI는 automation을 위한 것이 될 것이며, 결국 "더 똑똑한 소프트웨어"가 존재하는 세상이 올 것이라고 전망 — 지금은 LLM의 지능 수준에 비해 실제로 자동화된 업무가 "반올림 오차(rounding error)" 수준에 불과하다고 지적
6.2. TypeSafe AI가 풀고 있는 질문
-
핵심 질문: "신뢰성과 automation을 위해 AI 스택을 처음부터 다시 설계한다면 어떻게 될까?"
- 현재 상태: 회사는 아직 스텔스 모드지만, 발표자가 이런 자리에서 이야기를 시작한 것은 초기 공개 활동의 일환이며 곧 공개(release) 예정이라고 밝힘
- 채용: 함께 일하고 싶거나 "스마트 소프트웨어"를 처음 만드는 사람 중 하나가 되고 싶다면 메일링 리스트나 채용 페이지에 신청하라고 안내
-
학습 패러다임별 "북극성(North Star)" 비교
- RLHF: 인간 선호(human preference)를 최적화
- RLVR: 순수 정확도, 즉 로그 오류율(log error rates)을 최적화
- TypeSafe의 접근: calibrated decision-making(캘리브레이션된 의사결정)을 최적화하며, 사전학습 모델의 지능을 소프트웨어에 실제로 쓸모 있게 "직접 주입(mainlining)"하는 것이 목표라고 설명 — Sutton의 "bitter lesson"(알고리즘이 컴퓨팅보다 중요하다)을 게임에서는 맞지만 현실에서는 아니라고 재해석하며, 자신은 "데이터가 컴퓨팅보다 중요하고, 올바른 과제 설정이 데이터보다 더 중요하다"는 입장이라고 밝힘
-
API 형태 자체가 다르다
- 구조적 차이: RLHF의 API 형태와 RLVR의 API 형태가 다르듯, TypeSafe가 하고 있는 것의 API 형태도 이 둘과 다르다고 설명 — "아무도 instruction following을 생각해본 적 없던 시절 그것을 실현했던 것"처럼 완전히 처음부터 다시 사고하고 있다고 비유
- 낯섦에서 당연함으로: 포스트 트레이닝 방식에 큰 분기가 생길 때마다 처음엔 완전히 낯설어 보이다가, 나중에 돌아보면 당연해 보이는 패턴을 따른다고 언급
7. Q&A
7.1. 사전학습(pretraining) 관련 질문
-
청중 질문: Yoshua Bengio가 제안하는 것처럼, pretraining 단계에 classifier head를 함께 학습시키면 어떤가
- 답변의 전제: 발표자는 "복잡한 주제"라며 시간 관계상 단순화된 답변만 제공하겠다고 언급
-
저자의 답변
- Pretraining은 문제가 아니다: pretraining 자체는 "경이로운(phenomenal)" 것이며, 인터넷의 지식을 지능의 핵심으로 압축해낸 사전학습 모델 자체는 놀랍도록 지능적이라고 평가
- 문제는 "지능을 캐내는 방식": 문제는 pretraining이 아니라 그렇게 압축된 지능을 "어떻게 캐내는가(unearth)"에 있다고 지적
- Hallucination의 근원: hallucination은 인간 선호 최적화에 내재적(intrinsic)이며, GAN에서 볼 수 있는 것과 유사한 보상 모델의 비대칭성 때문이라고 설명 — 모델이 확신 없는 상태를 보이면 보상 모델 입장에서 이를 벌주기가 매우 쉬우므로, 결과적으로 모델은 모드를 버리고(drop modes) 확신에 찬 답변 쪽으로 몰리게 된다고 언급하며 "이건 매우 고급 주제"라고 스스로 덧붙임
7.2. RLVR 여부 및 기타 질문
-
"그럼 이게 RLVR이냐"는 질문
- 명확한 부정: 확실히 RLVR이 아니며, 완전히 새로운 것(a new thing)이라고 답변
- Sutton의 bitter lesson 재해석: 게임에서는 "알고리즘이 컴퓨팅보다 중요하다"는 bitter lesson이 맞지만 현실에서는 아니라고 하며, 전체 스택으로 보면 "데이터가 컴퓨팅보다 중요하고, 올바른 과제(task) 설정이 데이터보다 훨씬 더 중요하다"는 게 자신의 입장이라고 재확인
-
"보상이 전체 프로세스에 주입되는가"라는 질문
- API 형태의 차이로 재확인: RLHF의 API 형태와 RLVR의 API 형태가 다른 것처럼, 자신들의 접근도 API 형태 자체를 처음부터 다시 설계하고 있다는 답변으로 마무리 — 시간 초과("빨간불이 깜빡인다")로 자리를 정리함
8. 마무리 및 티저
-
트위터 시작 예고
- 팔로우 요청: 트위터를 새로 시작하려 하며, "spicy한(자극적인)" 내용을 올릴 예정이니 팔로우해달라고 요청
-
오늘 중 올릴 트윗 예고
- 힌트: "원래의 스케일링 법칙(scaling laws)이 틀렸다"는 주장을 담은 글을 오늘 중 올릴 것이라고 예고하며 발표를 마무리
주요 발언 모음
"It is not the Claude code era. I will justify this later on, but I actually believe them to be part of the same era." "The goal of it is to please the human in the loop... on the other side, all of these tasks that seem way more basic, the goal is to not have — remove the human loop." "Do not use AI for decisions with stakes to your business." "Overpromising is a feature. This is by design." "No matter how wrong the models are, they will look right because of the asymmetry within the reward model in RLHF." "I love cloud code, to be clear, just like I love ChatGPT. I would keep using it. But like what I want is smarter software." "What we're doing is we're just automating the writing of the software. But then its expressibility is the same. That to me is like tragic in the state of the world." "What if the AI stack was redesigned for reliability and automation?" "RLHF is optimizing for human preference. RLVR is optimizing for like log error rates of pure correctness, but we are doing a third thing that is optimized for calibrated decision-making." "Hallucination... to me is intrinsic to optimizing for human preference. There's an asymmetry in the reward model kind of like a GANs have." "The original scaling laws were incorrect." (오늘 트위터에 올릴 예정이라며 예고한 티저)
핵심 데이터 & 수치
- RLHF 보급률: 사용 현황 기준 사실상 100%의 LLM이 RLHF로 학습됨
- assistance vs automation 구도: 미해결 수학 문제는 풀리는데 고객 서비스는 여전히 사람이 필요하다는 현재 AI 산업의 역설적 상태를 발표 전체의 출발점으로 사용
- RLHF 3대 학습 패러다임 비교: RLHF(인간 선호 최적화) / RLVR(정확도·로그 오류율 최적화) / TypeSafe 접근(calibrated decision-making 최적화) — 각기 다른 "North Star"와 API 형태를 가짐
- 발표자 배경: OpenAI에서 GPT-4, ChatGPT, InstructGPT(RLHF) 공동 저작, post-training을 하나의 개념으로 만든 팀의 일원
결론 및 시사점
- 오늘날 AI(ChatGPT부터 Claude Code까지)는 모두 RLHF 기반 "assistance 시대"에 속하며, 근본적으로 "사람을 만족시키는 것"에 최적화되어 있어 고위험 의사결정이나 완전한 automation에는 부적합하다.
- 비즈니스에서는 비용과 리스크가 큰 의사결정을 AI에 맡기지 말고, AI로 인한 비용은 회사가 아니라 사용자(예: 무한 반복되는 셀프서비스)에게 돌아가도록 설계하는 것이 현재의 실질적 교훈이다.
- RLHF의 구조적 특성상 모델은 "틀려도 맞아 보이게" 답하도록 설계되어 있으며, 이는 hallucination이 버그가 아니라 인간 선호 최적화라는 목표 자체에 내재된 결과임을 이해해야 한다.
- 다음 시대의 소프트웨어는 "더 빠르고 싸게 짜여지는 것"이 아니라 "더 똑똑해지는 것"이어야 하며, 진짜 automation은 소프트웨어를 짜는 과정의 자동화가 아니라 소프트웨어 자체의 표현력을 근본적으로 바꾸는 것이어야 한다.
- TypeSafe AI는 RLHF·RLVR과 다른 제3의 최적화 목표(calibrated decision-making)와 API 설계로 이 문제를 처음부터 다시 풀고 있으며, 곧 공개될 예정이므로 관련 동향을 주시할 필요가 있다.
