InstructGPT를 만든 사람이 18분 동안 무대에서 한 이야기는 이것이다. 'AI가 벤치마크를 다 부수는데 왜 고객센터는 아직 사람이 결정하나?' 그의 답은 난이도가 아니라 목표에 있다 — 오늘의 AI는 전부 사람의 선호를 최적화하도록 만들어졌고, 그래서 사람 옆에서는 경이롭지만 사람 없이는 못 미덥다. 이 글은 그 논리를 처음부터 끝까지 따라가고, GPT-4 기술 보고서가 남긴 결정적 증거(후학습이 보정을 10배 망가뜨렸다)를 실측 수치로 다시 그린다. 인터랙티브 위젯 7종과 삽화 12장. 그리고 과장하면 안 되는 지점도 함께 짚는다.
2026년 여름, 샌프란시스코 모스콘 웨스트에서 열린 AI Engineer World's Fair 무대에 한 사람이 올라갔다. 발표 제목은 「What's next after RLHF?」 — RLHF 다음은 무엇인가. 18분짜리 짧은 발표였고, 발표자는 자기소개를 이렇게 했다.
제가 왜 이 얘기를 할 자격이 있냐면요. 저는 OpenAI의 대표작들, 최소한 공개된 대표작들의 공저자입니다. GPT-4, ChatGPT, RLHF/InstructGPT. 제가 있던 팀이 기본적으로 후학습(post-training)이라는 개념을 발명했어요. 그러니까 이 주제에 대해서는 꽤 자격이 있습니다.
그런데 제가 좀 특이한 점은, OpenAI 사람 중에 ChatGPT를 까는 몇 안 되는 사람이라는 겁니다. (청중 웃음)
디오고 알메이다(Diogo Almeida)다. 이 발표의 한국어 편집본이 「Jev CEO가 이야기하는 AI 자동화가 어려운 이유」라는 제목으로 2026년 9월 18일 유튜브에 올라오면서 국내에도 알려졌다. (정확히는 Jev는 회사 이름이 아니라 그가 만든 모델 이름이고, 회사는 TypeSafe AI다. 이 구분은 뒤에서 다시 다룬다.)
발표 자체보다 흥미로운 것은 그 뒤에 벌어진 일이다. 무대 위에서 그는 두 가지를 예고했다 — "오늘 중에 아주 매운 걸 하나 올릴 건데, 힌트는 원래의 스케일링 법칙이 틀렸다는 겁니다", 그리고 "저희는 곧 출시합니다". 둘 다 지켜졌다.
이 특집은 그 18분을 처음부터 끝까지 풀어 쓴 것이다. 앞서 다룬 「가장 쓴 교훈」 특집이 무엇을 최적화할 것인가라는 질문을 다뤘다면, 이 글은 그 질문의 가장 실용적인 답 하나 — "사람을 도와주는 AI"와 "사람 없이 일을 처리하는 AI"는 같은 물건이 아니다 — 를 끝까지 따라간다.
발표는 진단에서 시작한다. 지금 AI를 보는 시각은 극단 두 개뿐이고 중간이 없다는 것이다.
컬트 1: AI는 잘 되는 정도가 아니라 미친 듯이 잘 되고 있다. 벤치마크마다 인간 수준을 넘어서고, 새 벤치마크가 나오는 족족 부서지고, 게다가 모델이 자율적으로 일할 수 있는 시간이 지수적으로 늘고 있다(그는 이 대목에서 METR의 시간 지평 연구를 염두에 둔다 — 50% 성공률 기준 과제 길이가 약 7개월마다 두 배가 된다는 그 그래프다).
컬트 2: AI는 안 되는 정도가 아니라 미친 듯이 안 되고 있다. 거품이고, 순환 출자이고, 실질 가치를 못 만들고 있다. 그리고 결정타 — "AI가 그렇게 대단하면 왜 나오는 건 죄다 챗봇 아니면 코딩 어시스턴트인가?"
모두가 동의하는 유일한 사실은, 극단적인 관점 두 개만 있고 그 사이에는 아무것도 없다는 겁니다. 다들 AI가 미쳤다고 생각하는데, 이유가 서로 다른 거죠.
그가 원하는 것은 제정신인 관점(the sane view)이다. 양쪽의 증거를 다 테이블에 올려놓고, 그 간극을 설명하는 가장 단순한 설명을 찾는 것.
오른쪽 일들은 왼쪽 일들보다 훨씬, 훨씬, 훨씬 쉬워 보입니다. 어떻게 미해결에 가까운 수학 문제는 풀면서, 고객센터는 여전히 사람이 결정해야 하는 걸까요?
그리고 한마디 덧붙인다 — "AI 근처에서 일하는 사람이라면 누구나 이 질문에 답을 갖고 있어야 한다고 생각합니다. 이게 지금 이 분야의 증거니까요."
그의 답은 이렇다.
왼쪽 과제들은 우연히 사람이 루프에 있는 과제가 아닙니다. 왼쪽에서는 그 일의 목표 자체가 루프 안의 사람을 만족시키는 것입니다. (…) Claude Code의 일은 코드가 돌아가게 만드는 것만이 아니에요. 그렇다면 대화하는 방식이 완전히 달랐겠죠. 목표는 그 안의 사람을 만족시키는 것입니다.
반대쪽, 훨씬 기초적으로 보이는 이 일들은 목표가 사람을 루프에서 빼는 것입니다. 이상적으로는 아무도 들여다보지 않는 서버에서 백그라운드로 돌고, 결국에는 신경 쓰지 않는 레거시 소프트웨어가 되는 것.
이것이 보조(assistance)와 자동화(automation)의 분수령이다. 중요한 것은 인터페이스에 채팅창이 있느냐가 아니다. 결과를 최종적으로 누가 책임지느냐다.
직접 나눠 보면 이 구분이 얼마나 실전적인지 금방 보인다. 같은 모델을 쓰더라도 성공의 정의와 필요한 성질이 완전히 달라진다.
여기서 그는 꽤 날카로운 말을 한다.
모든 기업이 배운 교훈은 이겁니다 — 사업에 걸린 게 있는 결정에는 AI를 쓰지 마라. 흔한 패턴은 비용이 전부 사용자에게 가고 우리 회사로는 안 오게 만드는 겁니다. 사용자를 무한한 문서와 챗봇 상담으로 던져 넣는 건 완전히 괜찮고, 비싼 결정을 내리게 하는 건 안 되는 거죠. 끔찍한 패턴이지만, 이게 지금 AI의 현주소입니다.
이 문장을 읽고 자기 회사의 AI 도입 현황을 떠올려 보면 뜨끔한 경우가 많을 것이다. 챗봇은 붙였는데, 챗봇이 실제로 무언가를 결정하고 실행하는 권한은 하나도 못 받은 상태. 그 챗봇의 진짜 기능이 "사람 상담사에게 도달하는 비용을 올리는 것"이라면, 그건 자동화가 아니라 비용의 외주화다.
왜 이렇게 됐을까? 알메이다의 답은 알고리즘에 있다.
RLHF는 ChatGPT뿐 아니라 사실상 오늘날 모든 LLM 뒤에 있는 알고리즘입니다. 제가 아는 한, 사용량 기준으로 대략 100%의 LLM이 RLHF로 학습돼 있어요.
(이 100%는 그의 어림짐작이지 조사 결과가 아니다. 그도 "제가 아는 한"이라고 단서를 달았다.)
RLHF를 한 줄로 줄이면 이렇다 — 사람의 선호를 모으고, 그 선호에 맞게 최적화한다. 자세한 작동 원리(보상 모델, 브래들리–테리 순위, KL 페널티, 굿하트 문제)는 RLHF 특집에서 따로 다뤘으니 여기서는 결론만 가져온다.
이게 모두가 묻는 질문 — "왜 모든 LLM은 사람이 루프에 있어야 하나?" — 에 아주 명확한 답을 줍니다. 간단한 답은, 우리가 문자 그대로 사람을 루프에 넣었기 때문입니다. 그 루프의 목표는 사람의 선호를 최적화하는 것이었어요. 소프트웨어를 자율적으로 돌리는 게 아니라.
그래서 과장(overpromising)은 기능입니다. 설계상 그렇게 되어 있어요. (…) 구조적으로, 모든 RLHF 모델은 결과가 좋든 나쁘든 인간 선호와 실제 결과 사이에 항상 큰 차이를 갖게 됩니다. 최적화하는 주 목표가 인간 선호니까요.
그리고 그가 든 사례가 그날 청중을 가장 많이 웃긴 대목이다.
제가 이 트윗을 정말 좋아하는데요. ChatGPT한테 방귀 효과음 오디오 파일을 보내고 "제가 만든 음악 어떤가요?"라고 물어본 겁니다. (웃음)
답: "솔직한 감상을 말씀드릴게요. 아주 기묘하고 분위기 있는 앰비언트 작품이네요."
이게 그냥 RLHF가 작동하는 방식이에요. 모르면 인간 선호에 가장 좋다고 생각되는 쪽으로 기울어집니다. 사용자가 루프 안에 있다면 이게 말이 되죠. 모든 RLHF 모델의 종착지는 인게이지먼트 최적화니까요. 그런데 자동화를 원한다면, 필요한 건 사람 기분은 신경 안 쓰고 과제를 정확하게, 보정된 방식으로 해내는 것입니다.
그가 밀어붙이는 강한 버전의 주장은 이것이다.
보상 모델 안의 비대칭 때문에, 모델이 아무리 틀려도 맞아 보이게 됩니다.
직접 골라 보면 이 비대칭이 어떻게 만들어지는지가 체감된다. 아래 위젯에서 당신이 누르는 선택이 곧 학습 신호다.
여기서 균형이 필요하다. 알메이다의 사례들은 일화지, 통제된 실험이 아니다. 다행히 이 우려를 정면으로 조사한 연구가 있다.
Anthropic의 Towards Understanding Sycophancy in Language Models(Sharma et al., 2023)는 인간 피드백으로 미세조정된 AI 비서들이 사실보다 사용자의 믿음에 맞추는 행동(아첨)을 보이는지 조사했다. 결론은 이렇다.
즉 "선호 보상이 설득력 있는 오류를 강화할 수 있다"는 것은 연구로 뒷받침된다. 하지만 "RLHF는 언제나 모델을 부정확하게 만든다"는 것은 과한 해석이다. 실제로 InstructGPT 논문은 원본 GPT-3보다 환각이 줄었다고 보고했다(폐쇄형 과제 환각률 41% → 21%). 알메이다 본인도 발표 뒤 정리된 기록에서 이 점을 부정하지 않는다.
여기까지는 논증이다. 이제 숫자를 보자. 알메이다의 주장을 가장 잘 뒷받침하는 자료는 놀랍게도 OpenAI 자신이 GPT-4 기술 보고서에 실어 놓은 그림 한 장이다.
쉽게 말하면 이렇다.
"90% 확신한다"고 말한 판단들을 충분히 많이 모았을 때, 그중 실제로 약 90%가 맞는가?
정확도와는 다른 축이다. 정확도는 "얼마나 자주 맞느냐"이고, 보정은 "자기가 얼마나 맞을지를 얼마나 정확히 아느냐"다. 자동화에서는 후자가 더 중요할 때가 많다. 언제 실행하고 언제 멈출지를 그 숫자로 정하기 때문이다.
GPT-4 Technical Report의 5장 「한계」에는 이런 문장이 있다.
GPT-4는 자신의 예측에 대해 자신 있게 틀릴 수 있으며, 실수할 가능성이 높을 때도 재확인을 하지 않는다. 흥미롭게도, 사전학습 모델은 매우 잘 보정돼 있다(답에 대한 예측 확신이 대체로 실제 정답 확률과 일치한다). 그러나 후학습 과정을 거치면 보정이 감소한다(Figure 8). (…) 후학습은 보정을 상당히 해친다.
숫자로는 기대 보정 오차(ECE)가 0.007 → 0.074, 약 10배다. 아래 위젯은 그 두 그림을 우리 손으로 다시 그린 것이다. 막대 높이는 논문이 배포한 벡터 그림의 좌표를 축 눈금 기준으로 환산한 실측치다.
이 그림이 말하는 것은 단순하다. 사전학습 모델이 "85% 확신한다"고 하면 실제로 84.4% 맞았다. RLHF를 거친 모델이 같은 말을 하면 실제로는 50.5% 맞았다. 동전 던지기에 "확신 85%"라는 이름표가 붙은 것이다.
청중 질문에 답하면서 그는 자기 나름의 메커니즘을 제시한다.
저는 사전학습이 문제라고 생각하지 않아요. 사전학습은 정말 훌륭합니다. 인터넷의 지식을 지능의 핵심으로 압축해 냈다는 건 경이로운 일이고, 사전학습 모델은 엄청나게 똑똑합니다.
문제는 그걸 어떻게 캐내느냐입니다. 환각은 인간 선호를 최적화하는 데 내재된 것이라고 봐요. 보상 모델 안에 GAN이 갖는 것과 비슷한 비대칭이 있습니다. (…) 모델이 자신 없어 보이는 건 알아채기가 아주 쉽고, 보상 모델 입장에서 벌주기도 쉽습니다. 그래서 모드를 버리고 자신 있게 말하도록 부추겨지는 거죠.
풀어 쓰면 이렇다. 보상 모델은 "머뭇거림"을 아주 잘 감지한다. "~일 수도 있습니다만 확실하지 않습니다"는 눈에 띄게 점수가 깎인다. 반면 자신 있게 말한 오답은, 채점자가 진위를 일일이 확인하지 않는 한 잘 걸리지 않는다. 불확실성을 드러내는 데만 확실한 벌점이 붙는 비대칭이다. 학습은 그 비대칭을 성실히 따라간다.
TypeSafe의 공개 문서도 같은 현상을 모드 드롭(mode dropping)이라는 이름으로 설명한다 — 선호 최적화가 특정 스타일에 확률을 몰아주면서 나머지 가능성의 확률을 깎는다는 것이다. GAN의 모드 붕괴(mode collapse)의 약한 버전이라는 비유다.
흥미롭게도 OpenAI 자신도 2025년에 비슷한 진단을 내놨다. Why language models hallucinate의 논지는 "표준적인 학습·평가 절차가 불확실성 인정보다 추측을 보상한다"는 것이다. 객관식 시험에 비유하면, 모르는 문제를 찍으면 맞을 수도 있지만 빈칸으로 두면 확정 0점이다. 정확도만으로 채점하는 순간, 모델은 찍는 쪽이 유리해진다.
그 글에 실린 SimpleQA 비교표가 이 구조를 한눈에 보여 준다.
| 지표 | gpt-5-thinking-mini | OpenAI o4-mini |
|---|---|---|
| 기권률 (답을 특정하지 않음) | 52% | 1% |
| 정확도 (높을수록 좋음) | 22% | 24% |
| 오답률 (낮을수록 좋음) | 26% | 75% |
정확도만 보면 o4-mini가 앞선다(24% vs 22%). 리더보드에 올라가는 숫자도 그것이다. 그런데 오답률은 75% vs 26%, 거의 세 배다. 자동화에 쓴다면 어느 쪽이 안전한지는 물어볼 필요도 없다.
시스템 두 개를 비교해 보자.
| 시스템 | 자동 처리 | 맞힌 건수 | 틀린 건수 | 사람에게 |
|---|---|---|---|---|
| A — 전부 자동 | 100건 | 80건 | 20건 | 0건 |
| B — 확신 낮으면 보류 | 70건 | 65건 | 5건 | 30건 |
정답 수만 보면 A가 이긴다(80 vs 65). 그런데 틀린 자동 처리 한 건이 큰 피해를 만든다면 B가 낫다. 반대로 사람 검토 비용이 아주 비싸면 다시 A가 나을 수도 있다.
요점은 어느 쪽이 정답이냐가 아니다. 정답률 하나로는 결정할 수 없다는 것이다. 비교해야 할 것은 최소 네 가지다 — 자동 처리 비율, 자동 처리한 건의 오류율, 보류 비용, 오류 발생 시 손실.
슬라이더를 움직여 보면 곧바로 드러나는 사실이 하나 있다. 모델을 하나도 바꾸지 않았는데 최적 설정이 완전히 달라진다. 오류 1건이 1만원일 때와 200만원일 때, 문턱은 전혀 다른 자리에 있어야 한다. 임계값은 모델 성능이 아니라 업무의 비용 구조가 정한다.
그리고 이 계산이 성립하려면 전제가 하나 필요하다 — 모델이 말하는 확신이 실제 정답률과 맞아야 한다. 앞 장의 Figure 8이 왜 그렇게 중요한지가 여기서 드러난다. 보정이 무너지면 이 표 전체가 허구가 된다.
발표의 후반부는 조금 철학적이다. 그리고 가장 기억에 남는 대목이기도 하다.
소프트웨어에서 제일 미친 부분은, 모든 SaaS가 기본적으로 2019년 이후로 변하지 않았다는 겁니다. LLM 시대에 SaaS는 별로 안 변했어요. 가끔 챗봇이 옆에 하나 붙는 것 말고는. AI가 이룬 진보를 생각하면 말도 안 되는 일인데, AI가 보조 네이티브라는 걸 생각하면 아주 예측 가능한 결과이기도 합니다. AI가 보조를 위해 만들어졌으면, SaaS에서 할 수 있는 게 뭐겠어요? 옆에 어시스턴트 하나 붙이는 거죠.
그리고 대비를 하나 놓는다. 초기 OpenAI 헌장의 표현은 "이윤"이 아니라 "엄청난 양의 일을 하는 것"에 관한 것이었다고. 그때 사람들이 기대한 것은 소프트웨어가 더 똑똑해지는 것이지, 소프트웨어를 더 싸게 쓰게 되는 것이 아니었다.
Garry Tan의 이 표현을 좋아하는데요 — "우리는 적시 생산 소프트웨어(just-in-time software)의 황금기에 들어서고 있다." 그는 칭찬으로 한 말일 겁니다. 그런데 저는 이게 양날의 검이라고 봐요. (…) 저는 Claude Code를 정말 좋아하고 계속 쓸 겁니다. 하지만 제가 원하는 건 더 똑똑한 소프트웨어예요. 왜 소프트웨어는 더 표현력이 좋아지지 않죠? 왜 소프트웨어의 구성 요소는 아직도 똑같은 거죠?
| 소프트웨어 패턴 | 지능이 기여하는 자리 | 달라지는 것 |
|---|---|---|
| 전통적 소프트웨어 | 사람이 워크플로를 명세한다 | — |
| 적시 생산 소프트웨어 | AI가 코드를 만들어 준다 | 만드는 속도가 빨라진다. 프로그램이 할 수 있는 일의 범위는 그대로다 |
| 똑똑한 소프트웨어 | AI가 워크플로 안에서 일을 한다 | 프로그램의 표현력 자체가 넓어진다 |
그가 제시한 단위는 놀랄 만큼 작다.
자동화를 생각할 때, 그건 한 사람의 일을 통째로 자동화하는 것의 합이 아닙니다. 이런 겁니다 — 여기 아주 기계적인 반복 작업이 있고, 너무 단순해서 남에게 말로 "이거 이렇게 해 주세요"라고 전달할 수 있을 정도고, 이상적으로는 아주 기본적이어서 거의 공짜로 반복 실행될 수 있는 것. 혹은 컴퓨터가 할 수 있는 것. 그런데 그게 지금 일어나지 않고 있어요. 우리는 소프트웨어를 쓰는 일만 자동화하고 있고, 그 소프트웨어의 표현력은 그대로입니다. 저는 그게 비극이라고 생각해요.
이 관점을 실제 업무에 적용해 보면 설계가 확 바뀐다.
이 접근은 Anthropic의 에이전트 설계 지침과도 맞닿는다 — 미리 정한 코드 경로로 모델과 도구를 엮는 워크플로와 모델이 실행 과정을 스스로 정하는 에이전트를 구분하고, 업무에 맞는 가장 단순한 구조부터 시작하라는 것. 더 자율적인 구조가 언제나 더 나은 건 아니다.
질의응답 막바지에 누군가 물었다. "말씀하신 세 번째 것, 새로운 건가요 아니면 그냥 RLVR인가요?"
절대 RLVR이 아닙니다. 새로운 겁니다. (…) 서튼의 쓴 교훈은 계산이 알고리즘보다 중요하다는 거죠. 게임에서는 맞지만 현실에서는 아닙니다. 저는 전체 스택이 이렇다고 봐요 — 데이터가 계산보다 중요하고, 올바른 과제를 하는 것이 데이터보다 훨씬 중요하다.
그리고 LLM 후학습의 모든 갈래에는 각자의 북극성이 있습니다. RLHF는 인간 선호를 최적화합니다. RLVR은 순수한 정확성의 로그 오류율 같은 걸 최적화하죠. 그런데 저희는 보정된 의사결정을 최적화하는 세 번째 것을 하고 있습니다. 사전학습 모델의 지능을 소프트웨어에 실제로 유용한 형태로 직접 꽂아 넣는 거예요.
(이 대목이 두 달 뒤 「가장 쓴 교훈」 에세이로 확장된다. 그 논증은 별도 특집에서 자세히 다뤘다.)
마지막 질문 — "보상이 마지막에만 주어지나요, 과정 전체에 뿌려지나요?" 그는 학습 구조를 밝히지 않는다. 대신 이렇게 답한다.
사실 API의 생김새 자체가 다릅니다. RLHF의 API 모양과 RLVR의 API 모양이 다르고, 저희가 하는 것과도 다릅니다. 그래서 저희는 처음부터 다시 생각하고 있어요. 지시 따르기라는 게 있기 전에는 아무도 지시 따르기를 생각하지 않았던 것처럼 말이죠. 후학습에 큰 갈래가 새로 생길 때는, 보통 완전히 외계 같아 보이다가 지나고 나면 너무 당연해집니다.
같은 질문에 세 목표가 각각 어떤 모양의 답을 내놓는지 직접 비교해 보자.
강연 시점에는 "아직 스텔스"였지만, 두 달 반 뒤 Jev가 공개되면서 그 API의 모양이 드러났다. 궁금증이 남은 독자를 위해 공개 문서 기준으로 정리한다.
TypeSafe 문서에 따르면 이 모델은 텍스트를 생성하지 않는다. 상태(state)와 타입이 정해진 질문들을 받아, 구조화된 답과 확률 분포를 돌려준다.
| 질문 타입 | 무엇을 묻나 | 무엇을 돌려주나 |
|---|---|---|
| Choice | 정해진 목록에서 하나 고르기 | 선택된 항목 + 항목별 확률 + confidence |
| Score | 기준표(rubric)에 따라 점수 매기기 | 점수 + 등급별 확률 + confidence |
| Noul | 이 진술이 참인가 | 참일 확률 (0~1) |
세 타입을 한 번의 호출에 섞을 수 있고, 모든 질문이 같은 상태에 대해 병렬로, 서로 격리되어 평가된다. 질문을 더 넣어도 응답 시간이 거의 늘지 않고, 질문끼리 서로 오염시키지 않는다는 것이 문서의 설명이다.
설계 원칙도 명시돼 있다 — "질문 하나는 한 가지만 묻게 하라."
확장된 추론이 필요하거나 독립적인 여러 요인을 저울질해야 하는 질문이라면 쪼개라. 각 요인을 별도 질문으로 묻고, 코드에서 결과를 합쳐라. (…) 예를 들어 "이 스타트업 피치를 평가하라" 대신 시장 규모·기술 실현 가능성·차별성을 따로 묻고, 당신의 공식으로 점수를 합쳐라. 우선순위가 바뀌면 프롬프트를 다시 쓰는 대신 코드의 계수 하나를 바꾸면 된다.
문서의 「Confidence」 장은 이렇게 시작한다.
지적인 시스템이 사람이든 기계든, 정직한 불확실성을 표현하지 못한다면 그 시스템은 신뢰받을 수 없다.
그리고 권장하는 사용 패턴은 3구간이다 — 높으면 자동 실행, 중간이면 확인 후 진행, 낮으면 실행하지 않고 사람에게. 결정적인 것은 그다음 문장이다.
확신 임계값은 숫자 하나가 아니다. 같은 시스템 안에서도 행동마다 다른 수준에서 문을 걸어야 한다 — 틀렸을 때의 결과에 따라서.
문서의 예제 코드를 우리 맥락으로 옮기면 이렇게 된다.
resp = client.system_one(
state=user_message,
questions={
"action": Choice(
instructions="사용자가 하려는 일은 무엇인가?",
criteria={
"check_balance": "잔액 조회",
"approve_transfer": "대기 중인 출금 요청 승인",
"support": "문제 해결 요청",
},
),
},
)
action = resp.answers["action"]
c = action.confidence
if c < 0.5:
# 모델이 정말 모르겠다고 말하고 있다. 찍지 않는다.
route_to_human(user_message)
elif action.choice == "check_balance":
# 낮은 위험. 화면을 잘못 보여 줘도 되돌릴 수 있다.
show_balance(account_id)
elif action.choice == "approve_transfer":
if c > 0.9:
# 높은 위험 + 높은 확신 → 확인 절차를 거쳐 실행
confirm_then_execute(account_id)
else:
# 높은 위험 + 어중간한 확신 → 먼저 검증
ask_user_to_confirm(account_id)
잔액 조회는 0.5만 넘으면 그냥 실행하고, 출금 승인은 0.9를 넘어야 한다. 같은 모델, 같은 호출, 다른 문턱. 위험이 문턱을 정한다는 원칙이 코드 한 곳에 모여 있고, 비용 구조가 바뀌면 숫자만 고치면 된다.
confidence를 "확률 분포의 모양에서 계산한 통계량"이라고 명시한다. 이 숫자가 곧 정답 확률이라는 보장이 아니다. 업무에 쓰려면 실제 데이터로 "0.9라고 말한 건들이 정말 90% 맞았는가"를 확인하고 문턱을 정해야 한다. 문서도 "보수적인 값으로 시작해 자기 데이터로 시험하고 조정하라"고 쓴다. 4부의 Figure 8이 바로 이 확인을 건너뛰면 어떻게 되는지를 보여 준 것이다.
이 발표는 설득력이 있다. 그래서 더 조심해서 읽을 필요가 있다. 과장하기 쉬운 지점 다섯 개를 짚는다.
알메이다 본인의 표현은 "RLHF가 틀렸다고는 말하지 않겠습니다. 다만 이상한 우회로였고, 예상하지 못한 우회로였죠"다. 그리고 RLHF와 RLVR는 양자택일도 아니다. DeepSeek-R1의 후학습만 봐도 추론 과제에는 규칙 기반 보상을, 도움됨·안전성에는 선호 기반 보상을 함께 쓴다. 검증 가능한 정확성과 사람에게 유용한 행동은 같이 학습시킬 수 있다.
Claude Code는 제품·에이전트 도구의 이름이고, RLHF·RLVR는 모델 학습 방법이다. 알메이다가 "Claude Code도 보조 시대"라고 말한 것은 목표 수준의 비교이지, 그 제품의 학습 배합을 특정한 것이 아니다(그 자신이 "이건 좀 고급 얘기인데"라고 단서를 달았다). 실제로 Claude Code는 스크립트·CI 환경에서 비대화형으로 돌리는 용법을 공식 문서에 두고 있다.
Choice의 선택지를 신규 / 수정 / 근거 부족으로 제한해 두면 엉뚱한 형식의 응답은 원천 차단된다. 하지만 실제로는 수정 공고인데 신규를 고르는 오류까지 사라지는 것은 아니다. "타입 안전"과 "환각 불가"는 스키마 위반이 불가능하다는 뜻이지, 세상에 대한 오판이 없다는 뜻이 아니다.
193.6배 빠르다, 444.6배 저렴하다 같은 수치는 회사가 자기 워크플로 평가셋으로 잰 값이고, 기준 정답도 다른 프런티어 모델들의 평균이다. 회사 스스로 발표문에 그 한계를 길게 적어 둔 점은 인정할 만하지만, 독립 검증은 아직 없다. 평가할 때 던져야 할 질문은 "출력이 깔끔한가"가 아니라 "비슷한 비용과 자동 처리 비율에서 실제 오류를 얼마나 줄였는가"다.
이 점은 오히려 회사 문서가 가장 정직하다. 「Model jaggedness」 페이지는 현재 모델의 실패 모드 아홉 가지를 실명으로 나열한다.
| 실패 모드 | 무슨 일이 일어나나 | 대신 이렇게 |
|---|---|---|
| 문자 그대로 읽기 | 의도가 아니라 쓰인 단어대로 답한다 | 조건을 정확히 명시하고 경계 사례를 기준에 넣는다 |
| 수·계산 | 계산기가 아니다 | 산술은 코드에서 한다 |
| 세기 | 개수를 신뢰성 있게 못 센다. 대상이 커질수록 오차가 커진다 | 후보마다 질문 하나씩 던지고 코드에서 합산한다 |
| 날짜·시간 비교 | 날짜를 순서 있는 양이 아니라 텍스트로 읽는다 | 구성 요소를 뽑아 코드에서 비교한다 |
| 간접 참조 | 여러 단계를 건너뛰는 추론에 약하다 | 단계를 줄이고 관련 상태를 직접 가리킨다 |
| 불필요한 정보가 많은 상태 | 노이즈에 흔들린다 | 먼저 걸러 필요한 것만 보낸다 |
| 적대적 입력 | 프롬프트 공격에 취약하다 | 정밀한 지시문 + 배포 전 경계 사례 테스트 |
| 모순된 지시 | 기준끼리 충돌하면 결과가 흔들린다 | 기준과 지시를 일치시킨다 |
| 생성 | 글을 쓰지 못한다 | 생성형 모델을 쓴다 |
이 표는 사실 "이 모델을 쓰지 마라"는 목록이 아니라 역할 분담표다. 날짜 계산·산술·개수 세기·권한 검사처럼 명확한 것은 처음부터 코드가 하고, 모델에게는 진짜 애매한 판단만 준다. 그게 이 설계 철학의 본론이다.
강연에서 제품 발표까지를 걷어내고 남는, 오늘 당장 쓸 수 있는 것들만 추린다.
근거 부족을 넣고, 그 경우의 처리 경로를 미리 정해 둔다. 95%를 맞히면서 나머지 5%가 언제인지 말하지 않는 모델은 자동화에 쓸 수 없다.무대에서 그는 "오늘 중에 아주 매운 걸 올릴 건데, 힌트는 원래의 스케일링 법칙이 틀렸다는 겁니다"라고 했다. 며칠 뒤 올라온 글이 「Scaling Laws, Honestly」(2026년 7월 4일)다. 본문과 직접 이어지지는 않지만, 같은 사람의 사고방식을 보여 주는 좋은 사례라 짧게 옮긴다.
주장은 이렇다. OpenAI의 원래 스케일링 법칙(Kaplan 등, 2020)과 DeepMind의 친칠라(2022)가 서로 다른 답을 준 이유는 흔히 알려진 "파라미터를 세는 방식의 차이" 때문이 아니라 버그 때문이었다는 것이다. 버그의 재료는 세 가지다.
그리고 덧붙인 한 줄이 이 사람의 성격을 보여 준다.
여담: 저도 그때 OpenAI에서 LLM 최적화를 하고 있었고, 저도 이 버그를 놓쳤습니다. 😅 학습률 스케줄은 워낙 명백하게 중요한 하이퍼파라미터라, 일부러 그렇게 설정한 것처럼 보였거든요.
친칠라가 GPT-3의 절반도 안 되는 크기로 4배 넘는 토큰을 학습시켜 이길 수 있었던 이유가 여기 있다. 300B 토큰에서 학습률이 0으로 떨어지는 스케줄이었다면 애초에 불가능한 결과였다.
이 발표를 "RLHF는 실패했고 새 학습법이 모든 걸 해결한다"로 요약하면, 정작 쓸모 있는 부분을 놓친다.
남는 것은 질문의 교체다. 지금까지 우리가 AI에 대해 물어 온 것은 대체로 이것이었다.
이 모델이 얼마나 어려운 문제를 풀 수 있는가?
알메이다가 제안하는 질문은 다르다.
첫 번째 질문의 답은 벤치마크가 준다. 두 번째 묶음의 답은 아무도 대신 주지 않는다. 자기 업무의 비용 구조를 재고, 자기 데이터로 확신을 검증하고, 어디서 멈출지를 코드에 적어 넣어야 나온다.
좋은 자동화는 말을 잘하는 모델에 도구를 많이 붙인 것이 아니다. 모델의 판단 능력, 실제 데이터로 확인한 신뢰도, 그리고 코드가 쥐고 있는 실행 범위 — 이 셋이 함께 설계된 시스템이다. 그리고 그 셋 중 둘은 모델 제공자가 아니라 우리가 만든다.
