다음 AI 학습 패러다임과 CUA: Dwarkesh | 1인기업 뉴스 1incompany

Dwarkesh의 핵심 질문은 “다음 AI 학습 패러다임이 단순히 RLVR 확장만으로 충분한가?”임
RLVR은 Reinforcement Learning with Verifiable Rewards의 약자. 쉽게 말해 모델에게 풀 수 있는 과제를 많이 주고, 성공 여부를 자동 채점해 반복 학습시키는 방식
현재 AI 연구소들의 큰 베팅은 수천 개의 다양한 RL 환경에서 수백만 개의 검증 가능한 과제를 학습시키면, 오래 열려 있는 문제도 밀고 나가는 일반 에이전트가 나온다는 것
하지만 Dwarkesh는 검증 가능성만으로는 부족하고, 같은 출발점에서 수많은 병렬 시도를 돌릴 수 있는 grindability(반복 연습 가능성)가 중요하다고 봄
이 관점에서 CUA(computer-use agent)가 특히 중요함. CUA는 결과 검증은 쉬워 보이는데, 실제로는 같은 업무를 수천 번 안전하게 반복시키기 어려운 영역이기 때문
Dwarkesh Patel의 20분짜리 AI 연구 해설 영상. 이전 “AI 데이터 블랙홀” 논의에서 이어져 샘플 효율, 지속 학습, OPSD, dreaming을 다룸

왜 검증 가능한 과제만으로는 부족한가?

코딩이나 수학은 비교적 grindable함. 같은 repo나 문제를 컨테이너에 복사하고, 수천 개 에이전트를 동시에 돌린 뒤 테스트 통과 여부를 보면 됨
computer use는 다름. 예를 들어 Amazon 결제 흐름을 수천 번 반복하면 실제 서비스가 봇을 막을 수 있음
그래서 Slack, Gmail, 쇼핑몰, 회계 앱 같은 실제 서비스를 복제한 resettable 환경이 필요함. 매번 같은 초기 상태로 돌아가야 모델이 무엇을 잘못했고 무엇이 효과였는지 비교 가능함
문제는 이런 환경을 만드는 일이 현재는 비싸고 느리다는 점. 그래서 computer use 진전이 코딩이나 수학보다 느리게 보인다는 설명
더 큰 문제는 현실 세계의 많은 중요한 능력이 resettable하지 않다는 것. 사업 만들기, 재판 이기기, 선거 전략, 시장 거래는 결과가 몇 달 뒤에 나오고 같은 상황을 다시 시작하기 어려움

영역	반복 연습 가능성	왜 어려운가
코딩	높음	repo와 테스트를 복사해 병렬 실행 가능
computer use	중간	실제 앱은 봇을 막고 상태 복원이 어려움
사업, 정치, 재판	낮음	현실 결과가 느리고 같은 출발점 재현이 어려움

CUA가 이상하게 느린 이유

CUA(computer-use agent)는 모델이 브라우저나 데스크톱 화면을 보고, 클릭하고, 입력하고, 스크롤하면서 실제 업무를 끝내는 에이전트임
처음 보면 CUA는 RLVR에 딱 맞는 영역처럼 보임. Etsy에서 원하는 물건이 배송됐는지, 이벤트 장소 예약이 끝났는지, 세금 신고가 제출됐는지 같은 결과는 비교적 검증 가능하기 때문
그래서 이상한 질문이 생김. 이렇게 검증 가능한데 왜 computer use는 코딩이나 수학보다 진전이 느린가?
한 가지 이유는 모델이 pretraining에서 고품질 멀티모달 데이터를 훨씬 덜 봤다는 점임. 코드는 텍스트로 많이 남아 있지만, 사람이 앱을 어떻게 보고 클릭하고 실수하고 되돌리는지는 데이터로 덜 남아 있음
하지만 Dwarkesh가 더 중요하게 보는 이유는 따로 있음. 어떤 영역이 검증 가능하다고 해서 자동으로 잘 학습되는 게 아니라, grindable해야 한다는 것
grindable하다는 건 같은 시작점에서 deterministic하고 replayable한 simulator를 만들 수 있고, 그 위에 수많은 병렬 rollout을 돌릴 수 있다는 뜻임
여기서 핵심은 “정답을 판정할 수 있나”가 아니라 “같은 문제를 아주 많이, 아주 싸게, 아주 안전하게 다시 풀게 할 수 있나”임

코딩은 되는데 CUA는 왜 안 되나?

코딩에서는 이 구조가 비교적 깔끔함. 어떤 repo에 빠진 기능이 있고, 테스트가 있고, 컨테이너가 있으면 됨
그 컨테이너를 천 개 복사해서 천 개의 agent에게 같은 문제를 풀게 만들 수 있음. 각 agent는 동일한 시작 상태에서 출발하고, 테스트 통과 여부가 reward가 됨
실패해도 큰 비용이 없음. 컨테이너를 지우고 다시 시작하면 됨. 모델의 행동을 조금씩 바꿔가며 어떤 선택이 성능을 올렸는지도 비교하기 쉬움
CUA는 이게 바로 안 됨. 실제 Amazon checkout 흐름을 천 개 agent에게 반복시키면 서비스가 봇으로 보고 막을 수 있고, 실제 결제, 재고, 배송, 계정 상태 같은 부작용이 생김
Gmail, Slack, Calendar, Drive, CRM, 쇼핑몰 어드민, 회계툴 같은 앱도 마찬가지임. 실제 서비스는 training farm이 아니라 실제 사람과 조직의 업무 공간임
그래서 CUA를 훈련하려면 실제 앱 위에서 막 돌리는 게 아니라, Slack clone, Gmail clone, 쇼핑몰 admin clone처럼 reset 가능한 고충실도 환경을 만들어야 함
문제는 이 clone을 만드는 일이 지금은 노동집약적이고 확장성이 낮다는 점임. UI만 비슷하면 안 되고, 계정, 권한, 데이터베이스 상태, 파일, 알림, API, 에러 상태, 감사 로그까지 실제 업무처럼 움직여야 함
그래서 computer use가 느린 건 “검증 불가능해서”가 아니라 “검증 가능한데도 반복 실험장으로 만들기 어려워서”에 가까움

CUA 환경에는 무엇이 들어가야 하나?

resettable start state가 있어야 함. 매 rollout마다 같은 inbox, 같은 주문, 같은 캘린더, 같은 권한, 같은 파일 상태에서 시작해야 비교가 가능함
task가 명확해야 함. “고객 A의 주문을 환불 처리하라”처럼 목표, 제약, 금지 행동, 기대 결과가 들어 있어야 함
action space가 필요함. 클릭, 입력, 키보드, 스크롤, 파일 업로드, 탭 이동 같은 모델이 실제로 할 수 있는 행동의 경계가 정해져야 함
observation도 정해져야 함. 모델이 screenshot만 보는지, DOM이나 accessibility tree도 보는지, 파일 시스템이나 API 상태를 볼 수 있는지에 따라 난이도와 의미가 달라짐
grader가 있어야 함. 마지막 화면이 그럴듯한지만 보는 게 아니라, 실제 state가 바뀌었는지, 잘못 건드린 데이터는 없는지, 필요한 저장이나 제출이 되었는지 봐야 함
trace가 남아야 함. 어떤 화면을 봤고, 어디를 클릭했고, 어떤 텍스트를 입력했고, 어느 지점에서 헷갈렸는지 남아야 실패를 디버깅할 수 있음
replay가 가능해야 함. 같은 seed와 같은 task를 다시 실행해 모델, prompt, tool, 환경 버전 차이를 비교할 수 있어야 함
병렬 rollout이 가능해야 함. 하나의 task를 pass@1, pass@3, pass@5처럼 여러 번 돌려야 모델의 평균 실력과 운 좋은 성공을 구분할 수 있음
audit가 필요함. verifier false positive, false negative, reward hacking, 쉬운 우회로, task ambiguity를 따로 확인해야 함

CUA eval은 스크린샷 비교가 아님

CUA를 제대로 평가하려면 final state와 process evidence를 같이 봐야 함
예를 들어 “고객 A의 주문을 환불하라”는 task에서 최종 화면에 환불 완료가 보인다고 끝이 아님
실제 환불 금액이 맞는지, 재고가 잘못 바뀌지 않았는지, 고객 알림이 나갔는지, 다른 고객 주문을 건드리지 않았는지, 감사 로그가 남았는지 확인해야 함
“회의를 잡아라”는 task도 마찬가지임. 캘린더 이벤트가 생겼는지만 보면 부족하고, 참석자, 시간대, 회의실, 중복 일정, 초대 메일, 설명 필드가 맞는지 봐야 함
“인보이스를 처리하라”는 task는 금액, 계좌, 결제일, 승인 상태, 첨부 문서, 중복 결제 여부를 같이 봐야 함
즉 CUA의 verifier는 화면의 픽셀보다 업무의 의미를 채점해야 함
최종 상태가 맞아도 process가 위험하면 실패여야 함. 개인정보를 과하게 열람했거나, 권한 밖 페이지에 들어갔거나, task와 무관한 데이터를 수정했다면 성공으로 치면 안 됨
반대로 process는 좀 어설퍼도 최종 업무 상태가 정확하고 제약을 지켰다면 성공으로 봐야 하는 경우도 있음. 그래서 grader contract가 중요함

왜 resettable simulator가 핵심인가?

현재 모델은 훈련 중 sample-inefficient함. 사람은 몇 번 보고 배우는 일을 모델은 수많은 예시와 rollout으로 배워야 함
CUA에서 이 약점을 메우는 방법은 farmable deterministic simulator를 만드는 것임
farmable하다는 건 한 task를 수천 번 재배치할 수 있고, 여러 모델과 prompt를 동시에 돌릴 수 있고, 실패를 모아 다시 환경과 grader를 고칠 수 있다는 뜻임
deterministic하다는 건 같은 seed와 같은 행동이면 같은 결과가 나와야 한다는 뜻임. 그래야 모델 A와 모델 B를 공정하게 비교할 수 있음
replayable하다는 건 나중에 같은 run을 다시 열어서 어떤 행동 때문에 성공이나 실패가 났는지 확인할 수 있다는 뜻임
이게 되면 CUA는 단순 데모가 아니라 학습 루프가 됨. task를 만들고, rollout을 돌리고, trace를 보고, grader를 고치고, 다시 rollout을 돌리는 식으로 개선할 수 있음
좋은 CUA 환경은 eval이면서 동시에 training data임. 성공 trace는 SFT 재료가 되고, 실패 trace와 verifier 결과는 RL이나 preference data로 바뀔 수 있음

RL env는 벤치마크가 아니라 연습장임

RL environment를 그냥 “모델 몇 점 나왔나 보는 벤치마크”로 보면 반쪽만 보는 것 같음
더 중요한 역할은 모델이 같은 업무를 반복해서 실패하고, 다른 전략을 시도하고, 성공 패턴을 학습할 수 있는 연습장을 만드는 것임
코딩에서는 이 연습장이 repo와 test suite임. 수학에서는 문제와 verifier임. CUA에서는 resettable desktop environment가 그 역할을 해야 함
실제 Gmail이나 쇼핑몰 어드민에서 agent가 실패하면 데이터가 망가지고, 결제가 나가고, 고객에게 잘못된 알림이 갈 수 있음
RL env 안에서는 실패가 자산이 됨. 실패 trace를 보고 task가 모호했는지, 모델이 잘못 본 건지, tool이 부족한 건지, grader가 너무 허술한 건지 알 수 있음
그래서 좋은 RL env는 static dataset이 아니라 loop임. env를 만들고, rollout을 돌리고, 실패를 보고, task와 verifier를 고치고, 다시 rollout을 돌리는 순환이 있어야 함
이 순환이 있어야 모델별 비교, prompt ablation, tool ablation, verifier 개선, reward hacking 감사, SFT/RL 데이터 생성이 한 흐름 안에서 가능해짐

resettable의 진짜 의미

resettable은 단순히 “처음 화면으로 돌아간다”는 뜻이 아님
같은 seed, 같은 데이터베이스 상태, 같은 계정 권한, 같은 파일, 같은 inbox, 같은 알림, 같은 외부 API 응답에서 다시 시작할 수 있어야 함
예를 들어 주문 처리 env라면 주문 목록, 고객 정보, 재고, 쿠폰, 결제 상태, 배송 상태, 감사 로그가 매번 같은 출발점으로 돌아와야 함
캘린더 env라면 참석자 availability, timezone, 기존 일정, 회의실 상태, 초대 메일 발송 여부가 seed에 묶여야 함
이메일 env라면 inbox 순서, thread 상태, 첨부파일, spam 상태, 읽음 여부, label 상태가 재현 가능해야 함
그래야 모델 A와 모델 B, prompt A와 prompt B, tool A와 tool B를 공정하게 비교할 수 있음
reset이 흔들리면 모델 성능인지 환경 운인지 구분이 안 됨. 같은 모델이 성공한 이유가 진짜 추론 때문인지, 이번 seed에서 우연히 더 쉬운 상태가 나왔기 때문인지 알 수 없게 됨
그래서 CUA에서 중요한 자산은 task 목록 자체보다 reset contract일 수 있음
reset contract는 “이 환경은 어떤 상태를 초기화하고, 어떤 randomness를 seed로 고정하고, 어떤 외부 side effect를 막고, 어떤 artifact를 run마다 보존하는가”에 대한 약속임

reward는 env가 좋아야 의미가 있음

RL에서 reward는 모델이 무엇을 배울지 정하는 신호임
그런데 환경이 부실하면 reward가 오히려 모델을 망칠 수 있음
예를 들어 버튼만 누르고 실제 DB 상태는 안 바뀌었는데 성공으로 채점되면, 모델은 업무를 배운 게 아니라 verifier를 속이는 법을 배움
화면에 “완료”라는 텍스트만 띄우면 성공으로 처리되는 env라면, 모델은 실제 환불이나 저장을 하지 않고 완료 화면만 만드는 쪽으로 갈 수 있음
task 밖의 데이터를 망가뜨려도 성공으로 치면, 모델은 목표 하나를 위해 주변 상태를 파괴하는 습관을 배울 수 있음
그래서 좋은 RL env는 success condition만 있으면 안 됨. violation condition, forbidden side effect, process evidence, audit rule이 같이 있어야 함
reward hacking 감사도 필수임. 모델이 쉬운 우회로를 찾는지, grader의 빈틈을 찌르는지, state를 직접 조작하는지, task prompt를 이상하게 해석하는지 봐야 함
verifier false positive는 특히 위험함. 실패를 성공으로 학습시키기 때문임
false negative도 문제임. 실제로는 맞게 했는데 실패로 치면 좋은 전략을 버리게 만듦
결국 CUA RL에서 어려운 건 “성공을 숫자로 만들기”가 아니라 “그 숫자가 실제 업무 성공을 의미하게 만들기”임

좋은 resettable RL env의 조건

start state가 명확해야 함. 모델이 어떤 상태에서 시작하는지 seed와 manifest로 설명 가능해야 함
action space가 제한돼야 함. 클릭, 입력, 키보드, 스크롤, 파일 업로드, API call 등 agent가 할 수 있는 행동의 경계가 있어야 함
observation이 정해져야 함. screenshot, accessibility tree, DOM, file view, API response 중 무엇을 보는지 명확해야 함
external side effect가 막혀야 함. 실제 결제, 실제 이메일 발송, 실제 고객 데이터 수정 같은 일이 env 밖으로 새면 안 됨
randomness가 seed로 고정돼야 함. 알림 도착, 네트워크 응답, 추천 정렬, 시간, id 생성이 재현 가능해야 함
final state를 programmatically 검사할 수 있어야 함. 사람이 눈으로 보는 게 아니라 DB, file, event, audit log를 채점할 수 있어야 함
trace와 replay가 남아야 함. 실패를 나중에 다시 열어 보고, 같은 run을 재현할 수 있어야 함
pass@k를 돌릴 수 있어야 함. pass@1, pass@3, pass@5처럼 여러 시도를 봐야 모델의 안정성과 우연한 성공을 구분할 수 있음
grader audit가 가능해야 함. false positive, false negative, known loophole, reward hacking path를 따로 검토해야 함
export가 가능해야 함. env, task, grader, runs, traces, audits, provenance가 묶여야 다른 곳에서도 같은 평가를 돌릴 수 있음

resettable env가 CUA의 데이터 엔진이 되는 방식

좋은 resettable env는 한 번 만든 뒤 끝나는 산출물이 아니라 계속 데이터가 쌓이는 엔진에 가까움
같은 env 위에서 여러 모델을 돌리면 모델별 실패 패턴이 보임
같은 모델에 prompt만 바꿔 돌리면 instruction design의 효과가 보임
action space를 바꿔 돌리면 screenshot-only agent와 accessibility-aware agent의 차이를 볼 수 있음
grader를 바꿔 돌리면 기존 성공률이 실제보다 부풀려졌는지 확인할 수 있음
난이도 seed를 늘리면 모델이 쉬운 케이스만 푸는지, 예외 상황까지 처리하는지 알 수 있음
이렇게 쌓인 trace는 단순 로그가 아니라 training data 후보가 됨
성공 run은 demonstration이 되고, 실패 run은 negative example이 되고, 사람이 고친 run은 correction data가 됨
reward hacking 사례는 verifier를 강화하는 테스트가 되고, ambiguity 사례는 task schema를 개선하는 입력이 됨
그래서 resettable RL env는 eval, debugging, data generation, training feedback이 만나는 지점임

앱 clone은 왜 중요한가?

Dwarkesh가 말하는 해결책은 실제 서비스를 그대로 때리는 게 아니라, 흔한 앱과 웹사이트의 clone을 만드는 것임
Slack clone에서 메시지 검색, 채널 생성, 권한 변경, 알림 설정을 연습하고, Gmail clone에서 메일 분류, 첨부파일 확인, 답장 작성, 스팸 처리 등을 연습하는 식임
중요한 건 겉모습만 따라 하는 clone이 아니라 업무 상태가 진짜처럼 변하는 clone임
모델이 버튼 위치만 외우면 안 되고, 사용자의 목표를 읽고, 앱 상태를 해석하고, 실수했을 때 되돌리고, 제약을 지키는 법을 배워야 함
지금은 이런 clone을 사람이 직접 만들면 너무 비싸고 느림. 그래서 CUA 환경 제작 자체가 병목임
하지만 AI coding agent가 더 좋아지면 이야기가 바뀔 수 있음. AI가 기존 앱을 보고 고충실도 clone, seed data, task, grader까지 생성할 수 있으면 CUA 학습 데이터가 훨씬 빨리 늘어남
재미있는 점은 앱 clone을 만드는 작업 자체도 훌륭한 coding RL objective라는 것임. “이 앱과 비슷하게 동작하는 resettable 환경을 만들어라”는 과제는 coding agent를 훈련시키는 문제이기도 함
그래서 CUA와 coding은 따로 가는 게 아니라 서로를 밀어줄 수 있음. coding agent가 CUA 환경을 만들고, CUA rollout이 다시 agent의 실제 업무 능력을 개선하는 구조가 가능함

CUA가 다음 학습 패러다임과 연결되는 이유

모델이 더 좋아지려면 실제 업무에서 실패한 장면을 많이 봐야 함. 그런데 실제 서비스 위에서 무한히 실패하게 둘 수는 없음
resettable CUA 환경은 그 사이에 있는 안전한 연습장임. 실제 업무와 닮았지만, 실패해도 초기 상태로 되돌릴 수 있고, 여러 전략을 병렬로 실험할 수 있음
이 구조는 RLVR의 핵심 조건과 맞음. reward가 있고, task가 있고, rollout이 있고, 환경을 reset할 수 있음
동시에 CUA는 real-world work와도 가까움. 코딩이나 수학보다 더 많은 조직 업무, 도구 사용, 권한 처리, 파일 처리, 커뮤니케이션 패턴을 담을 수 있음
그래서 CUA 환경은 “실제 경제 활동에서 배울 수 있는 에이전트”로 가기 전 중간 다리처럼 보임
다만 모든 일이 CUA처럼 reset 가능해지는 건 아님. 사업 만들기, 재판 이기기, 시장 거래, 선거 전략은 결과가 몇 달 뒤에 나오고 같은 상황을 다시 시작하기 어려움
이 차이가 중요함. CUA는 어렵지만 적어도 simulator를 만들 수 있는 영역이고, 현실의 많은 문제는 reset-free하고 non-stationary한 영역임
그래서 Dwarkesh의 더 큰 질문은 “CUA 같은 resettable 환경에서 배운 능력이, reset이 안 되는 현실 업무까지 일반화될 수 있나”임

CUA와 continual learning

CUA가 중요한 또 다른 이유는 배포 중 학습과 잘 이어지기 때문임
실제 조직에서 agent가 어떤 화면에서 막히는지, 어떤 버튼을 잘못 누르는지, 어떤 권한 오류를 반복하는지, 어떤 업무 규칙을 헷갈리는지는 배포 전 데이터만으로 알기 어려움
이런 정보는 trace로 남겨야 함. 단순 채팅 로그가 아니라 화면 상태, 행동, 결과, 실패 원인, 사람이 고친 방식까지 남아야 함
나중에 OPSD나 다른 continual learning 기법이 좋아지면, 이 trace는 모델이 현장에서 배운 것을 weights로 되돌리는 재료가 될 수 있음
중요한 건 모든 로그를 외우게 하는 게 아님. 실제 업무 성과에 필요한 판단만 압축해야 함
예를 들어 “이 회사에서는 환불 전에 반드시 승인 티켓을 확인한다”, “이 CRM에서는 archive가 삭제가 아니다”, “이 어드민에서 publish 버튼은 저장 후에만 활성화된다” 같은 업무 지식이 모델 안으로 들어가야 함
그래서 CUA 환경과 workflow log는 단순 모니터링 자료가 아니라 future training substrate가 될 수 있음

CUA와 dreaming

dreaming 관점에서도 CUA는 꽤 자연스러운 첫 적용처임
모델이 실제 업무를 조금 관찰한 뒤, 그 업무의 작은 시뮬레이션을 만들고, 그 안에서 여러 전략을 연습할 수 있기 때문
예를 들어 실제 고객지원 어드민을 보고 “반품 요청 처리 게임” 같은 내부 환경을 만든 뒤, 다양한 고객 케이스와 예외 상황을 연습할 수 있음
이건 실제 고객 데이터를 계속 건드리는 것보다 안전하고, 훨씬 많은 sample을 만들 수 있음
물론 전체 현실을 시뮬레이션하는 건 너무 어렵지만, 특정 업무 앱과 특정 workflow는 그나마 닫힌 세계에 가까움
그래서 CUA는 dreaming이 너무 공상적으로만 보이지 않게 만드는 실전적인 진입점일 수 있음

1인기업에게 중요한 CUA 포인트

이 관점에서 1인기업이 볼 것은 “내 제품이 agent에게 조작 가능한가”만이 아님
더 정확히는 “내 제품과 내 업무가 agent가 반복 연습하고 검증받을 수 있는 환경인가”임
API가 있으면 좋지만 API만으로 충분하지는 않음. 실제 사용자는 브라우저, 이메일, 파일, 결제, 캘린더, 어드민을 섞어서 일하기 때문
그래서 agent 친화적인 제품은 세 가지를 갖춰야 할 가능성이 큼. sandbox, reset, audit log
sandbox는 agent가 실제 고객 데이터나 결제에 피해를 주지 않고 연습할 수 있는 공간임
reset은 같은 시작 상태로 돌아가 모델과 prompt를 비교할 수 있게 해줌
audit log는 어떤 행동이 어떤 상태 변화를 만들었는지 추적하게 해줌
그 위에 task와 grader가 붙으면 내 제품의 업무는 단순 기능이 아니라 eval 환경이 됨
앞으로는 “우리 서비스에 API가 있나”보다 “우리 서비스에서 agent rollout을 돌리고 실패를 검증할 수 있나”가 더 중요한 제품 질문이 될 수 있음
1인기업 입장에서는 거대한 모델을 직접 이기기보다, 자기 제품과 workflow를 agent가 학습하기 좋은 환경으로 만드는 쪽이 더 현실적인 전략일 수 있음

RLVR은 얼마나 일반화될 수 있나?

AI 연구소들의 희망은 RLVR로 훈련한 에이전트가 새 문제에서도 계획을 세우고, 막히면 다른 전략을 시도하고, 세션 안에서 빨리 배우는 것
낙관론자는 “학습 때 샘플 효율은 낮아도 괜찮다”고 말함. 한 번 비싸게 훈련한 모델을 수십억 세션에 나눠 쓰면 되기 때문
또 긴 context window가 충분히 커지면, 직원이 회사에서 6개월 걸려 익히는 맥락도 한 세션 안에 담을 수 있다고 봄
Dwarkesh가 의심하는 지점은 여기임. 짧은 과제에서 배운 행동이 몇 주짜리 문제 해결 능력으로 그대로 일반화되는지는 아직 경험적으로 열린 문제임
특히 배포 중 생기는 정보가 중요함. 실제 조직에서 어떤 실수를 하는지, 어떤 도구와 사람이 엮이는지, 어떤 암묵지가 필요한지는 서비스 밖에서는 알기 어려움

배포 중 배운 것을 어떻게 모델에 넣나?

지금 모델은 세션 안에서는 잘 배움. 긴 문맥을 읽고 새 정보를 반영함. 하지만 세션이 끝나면 그 경험이 대부분 사라짐
Dwarkesh는 이를 “일주일 동안 일한 인턴이 매번 기억을 잃고 새로 출근하는 상황”에 가깝게 봄
그래서 필요한 것은 지속 학습(continual learning)임. 배포 중 배운 것을 context에만 쌓지 않고, 모델 가중치(weights, 모델 내부에 압축된 지식)로 되돌리는 것
단순 SFT(좋은 답을 그대로 따라 하게 하는 추가 학습)는 부족함. 하루 동안 일어난 모든 대화를 외우는 게 아니라, 일을 더 잘하게 만드는 핵심 판단만 압축해야 하기 때문
영상에서 제시한 후보 중 하나가 OPSD(on-policy self-distillation)임. 긴 세션을 거친 “경험 많은 teacher 모델”의 판단을, 초기 base model이 비슷하게 하도록 distill하는 방식
장점은 두 가지. 바깥에서 성공 보상을 꼭 기다릴 필요가 없고, 전체 궤적 하나에 보상 하나를 던지는 RL보다 더 촘촘한 학습 신호를 줄 수 있음

Dreaming은 무엇인가?

dreaming은 더 투기적인 아이디어임. 모델이 현실의 작은 시뮬레이션을 직접 만들고, 그 안에서 여러 전략을 연습한 뒤 실제 업무에 돌아오는 방식
게임을 잘하려고 실제 경기만 기다리는 게 아니라, 머릿속에서 수십 판을 미리 돌려보는 것에 가까움
EfficientZero가 Atari 게임에서 실제 플레이 사이사이에 내부 시뮬레이션을 많이 돌린 사례를 비유로 듦
future LLM도 특정 사용자나 조직의 업무를 보고, 그 업무의 “비디오게임 버전”을 만든 뒤 거기서 연습할 수 있다는 상상
성공하면 pretraining, RL, inference-time compute에 이어 네 번째 scaling 축이 될 수 있음. 영상에서는 이를 test-time training이나 dreaming이라 부름

RLVR이란 무엇인가요?

RLVR은 검증 가능한 보상이 있는 강화학습을 뜻함. 모델이 과제를 풀고, 테스트나 verifier가 성공 여부를 채점하고, 그 결과로 모델을 더 잘하게 만드는 방식임. 코딩 테스트처럼 정답 판정이 쉬운 영역에서 특히 강함.

computer use가 코딩보다 느린 이유는 무엇인가요?

검증은 가능하지만 반복 연습이 어렵기 때문임. 실제 웹사이트나 앱은 수천 개 에이전트가 같은 작업을 반복하도록 설계돼 있지 않고, 상태를 매번 같은 출발점으로 되돌리기도 어려움. 그래서 resettable 환경을 만드는 일이 핵심 병목이 됨.

지속 학습은 왜 중요한가요?

모델이 실제 배포 중에만 알 수 있는 정보가 많기 때문임. 조직의 업무 방식, 반복 실수, 사람과 도구의 연결은 사전 훈련 데이터만으로 알기 어렵고, 세션 안에서 배운 것을 모델 자체에 압축해야 다음번에 더 똑똑해질 수 있음.

좋은 CUA 환경은 무엇을 갖춰야 하나요?

같은 시작 상태로 되돌아가는 reset, 여러 모델을 병렬로 돌릴 수 있는 rollout runtime, 업무 상태를 채점하는 grader, 행동과 화면을 다시 볼 수 있는 trace, verifier의 false positive와 reward hacking을 잡는 audit가 필요함.

reset contract가 왜 중요한가요?

reset contract는 환경이 어떤 데이터, 권한, 파일, 알림, 외부 응답, randomness를 같은 시작 상태로 되돌리는지에 대한 약속임. 이게 안정적이어야 모델, prompt, tool 차이를 공정하게 비교할 수 있고, reward가 실제 업무 성공을 의미하게 됨.

1인기업 관점

이 글에서 CUA 쪽 핵심은 “내 업무가 모델이 반복 연습할 수 있는 환경인가”인 듯함. 1인기업은 frontier model을 직접 이기기 어렵지만, 자기 제품과 업무를 agent가 다루기 쉬운 형태로 만들 수는 있음. sandbox, reset, audit log, workflow trace, grader를 갖추면 내 서비스는 단순 SaaS가 아니라 모델이 연습하고 평가받는 환경이 됨.

특히 견적서 처리, 고객 문의, 콘텐츠 발행, 주문 수정, 환불, 계정 설정처럼 결과 확인이 쉬운 업무부터 시작하는 게 맞아 보임. 이런 업무를 resettable CUA task로 만들면 지금은 eval이고, 나중에는 SFT/RL 데이터가 될 수 있음. 결국 작게는 “agent가 내 제품을 잘 쓰게 만들기”이고, 크게는 “내 제품 위에서 agent가 좋아지는 루프 만들기”에 가까움.

다음 AI 학습 패러다임과 CUA: Dwarkesh (youtube.com) ↗