강화학습에서 현실로: 컴퓨터 사용 에이전트가 실패하는 지점과 학습 설계

URL: https://www.youtube.com/watch?v=Cc0_nyxROBA 날짜: 2026-08-15 원본 업로드일: 2026-08-14 채널: aiDotEngineer 발표자: Gaurav Mishra, Amazon AGI Lab

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==강화학습(Reinforcement Learning, RL)으로 훈련한 에이전트를 현실의 컴퓨터 환경에 배치하면, 게임처럼 닫혀 있고 결정적인 세계를 전제로 한 학습 가정이 부분 관측·비가역적 행동·불확실한 성공·적대적 콘텐츠와 충돌한다.==

• RL은 검증 가능한 결과, 여러 정답 경로, 추론 중심 과제가 있는 영역에서 SFT보다 강하다.
• 코딩 에이전트는 이메일·채팅·영수증·웹 검색까지 코드와 API 호출로 표현할 수 있지만, 현실의 로그인·광고·세션 만료·느린 로딩이 새로운 실패 모드를 만든다.
• 현실 배치에는 고충실도 디지털 샌드박스, 과정 보상, 위험 인식형 신뢰도, 복구 가능한 하네스(harness), 사용자 핸드오프가 필요하다.
• 데모와 제품을 가르는 기준은 첫 클릭이 아니라 첫 번째 실패한 클릭 이후의 행동이며, 실패를 안전하게 수집해 학습 루프로 되돌리는 구조가 핵심이다.

Gaurav Mishra는 Amazon AGI Lab에서 컴퓨터로 사람이 할 수 있는 일을 수행하는 에이전트를 훈련한다. RL이 게임 안에서 높은 성능을 내는 이유와 현실의 웹 브라우저에서 쉽게 무너지는 이유를 대비한 뒤, 비행 훈련에 가까운 시뮬레이션과 모델·하네스·환경을 함께 설계하는 방법을 설명한다.

1. 발표 배경과 RL의 기본 구조

1.1. 발표자의 연구 맥락

1. 컴퓨터 작업을 수행하는 에이전트 연구

   1. Amazon AGI Lab: Gaurav Mishra는 컴퓨터로 사람이 할 수 있는 일을 수행하는 에이전트를 훈련한다.
   2. 이전 경력: Google에서 10년 넘게 일했고, 마지막 6년은 Deep Brain과 DeepMind에서 언어 모델과 에이전트를 훈련했다.
   3. 제목의 말장난: “RL to IRL”은 Reinforcement Learning에서 In Real Life로 넘어갈 때 무엇이 깨지는지 묻는 표현이다.

2. 발표가 던지는 질문

   1. RL로 훈련한 에이전트가 닫힌 게임이나 코드 실행 환경을 벗어나 실제 로그인 화면과 웹 서비스에 들어가면 어떤 가정이 실패하는가.
   2. 현실의 실패를 단순한 인프라 오류로 초기화하지 않고, 에이전트가 직접 관찰하고 복구하며 다음 학습 신호로 활용하게 하려면 무엇이 필요한가.

1.2. RL과 SFT의 차이

1. RL의 한 번의 생성 단위 보상

   1. 에이전트는 정책(policy)이고, 주어진 과제(task)에 대해 여러 생성 결과를 샘플링한다.
   2. 전체 생성(generation)에 보상(reward)을 계산한 뒤 그 보상에 따라 모델 가중치를 업데이트한다.
   3. PPO(Proximal Policy Optimization), GRPO(Group Relative Policy Optimization)와 여러 변형 알고리즘이 보상을 가중치 업데이트에 적용한다.

2. SFT와 사전 학습의 토큰 단위 손실

   1. SFT와 pre-training은 각 토큰 예측에 손실을 배정한다.
   2. RL은 답변의 모든 토큰이 같은 방식으로 맞았는지를 따지기보다, 전체 궤적 또는 결과가 과제의 목적을 달성했는지를 평가한다.
   3. 따라서 여러 경로가 가능한 과제에서는 한 가지 시연 패턴을 복사하게 만드는 대신 결과에 도달하는 다양한 전략을 남길 수 있다.

2. RL이 SFT보다 효과적인 조건

2.1. 데이터와 정답 구조가 RL에 유리한 영역

1. 과제는 만들기 쉽지만 시연 데이터는 모으기 어려운 경우

   1. 합성하거나 수집할 과제는 충분하지만, 사람이 모든 정답 행동을 시연한 SFT 데이터를 만들기 어려운 영역에서 RL이 강하다.
   2. 사람이 각 과정을 직접 시연하지 않아도 검증기가 결과를 판정할 수 있으면 보상 신호를 대량으로 만들 수 있다.

2. 여러 정답과 여러 성공 경로가 존재하는 경우

   1. 하나의 문제에 여러 올바른 해법이 있고 결과를 검증할 수 있으면 RL이 다양한 경로를 탐색한다.
   2. 모든 경로를 SFT 데이터로 수집하지 못하면 모델이 소수의 시연 패턴만 따라 하도록 좁아질 수 있다.
   3. 결과 중심의 RL은 특정 절차를 암기하는 대신 목표에 도달하는 방법을 모델이 발견할 여지를 준다.

3. 추론이 무겁고 과정의 주관성이 큰 경우

   1. 사람이 모델의 사고 과정을 일일이 규정하기보다 최종 결과를 기준으로 판단하는 편이 낫다.
   2. 모델이 어떻게 생각할지를 제한하지 않고, outcome만 평가하면 문제에 맞는 사고 전략을 학습할 수 있다.

2.2. 코딩이 RL에 잘 맞는 이유

1. 검증 가능한 결과

   1. 코드의 정답 여부는 컴파일러, 린터, 유닛 테스트, 데이터베이스 조회 등으로 확인할 수 있다.
   2. 같은 기능을 구현하는 코드가 여러 가지여도 실행 결과가 맞으면 보상을 줄 수 있다.

2. 탐색과 추론의 결합

   1. 코딩은 한 문제에서 여러 구현 경로가 가능하다.
   2. 코딩 에이전트는 결과를 실행해 확인하면서 추론하고, RL은 이러한 결과 중심 학습을 활용해 설득력 있는 에이전트를 만들었다.

3. RL 시스템의 세 가지 핵심 구성 요소

3.1. 과제(Task): 올바른 훈련 신호의 출발점

1. 검증 가능한 결과

   1. 과제는 모델이 생성한 결과를 객관적 또는 일관된 방식으로 판정할 수 있어야 한다.
   2. 결과를 검증할 수 없으면 보상이 흔들리고, 모델이 어떤 행동을 개선해야 하는지 알기 어렵다.

2. 가르치려는 능력에 맞춘 표적화

   1. 과제는 훈련하려는 기술을 정확히 겨냥해야 한다.
   2. 과제의 표면적 형식만 닮고 목표 능력과 연결되지 않으면, 높은 보상이 실제 능력 향상으로 이어지지 않는다.

3. 적절한 난이도 창(difficulty window)

   1. 너무 쉬운 문제는 거의 모든 샘플이 성공해 차별화되는 학습 신호가 없다.
   2. 너무 어려운 문제는 거의 모든 샘플이 실패해 역시 유용한 신호를 만들지 못한다.
   3. 모델이 성공과 실패를 모두 경험하면서 차이를 학습할 수 있는 난이도가 필요하다.

3.2. 환경(Environment): 행동을 안전하게 실행하는 공간

1. 코드와 행동의 실행 공간

   1. 에이전트가 코드나 액션을 생성하면 실제 실행할 수 있는 환경이 필요하다.
   2. 모델이 시스템을 망가뜨리거나 사용자에게 피해를 주지 않도록 코드 샌드박스가 중요한 기반이 된다.

2. 환경이 곧 학습 신호의 일부가 되는 구조

   1. 환경은 단순히 결과를 받는 장소가 아니라, 행동의 결과와 오류를 재현하는 장치다.
   2. 현실에 배치할수록 환경이 현실의 지연·상태 변화·실패를 얼마나 충실하게 재현하는지가 중요해진다.

3.3. 검증기(Verifier): 결과를 보상으로 바꾸는 판정 장치

1. 단순한 판정에서 실행 기반 판정까지

   1. 가장 단순한 검증기는 문자열 일치(string equality)다.
   2. 컴파일러와 린터, 유닛 테스트, 데이터베이스 조회는 실행 결과를 통해 더 풍부한 판정을 제공한다.

2. 루브릭을 읽는 에이전트형 검증기

   1. 검증기 자체가 특정 평가 기준(rubric)을 받고 모델 응답을 채점하는 에이전트일 수도 있다.
   2. 결과뿐 아니라 요구사항 준수, 위험 행동, 사용자의 의도와의 일치 여부까지 평가하려면 검증기의 범위가 넓어져야 한다.

4. 코딩 에이전트에서 컴퓨터 사용 에이전트로

4.1. 코드로 표현되는 현실의 컴퓨터 작업

1. 코딩을 넘어선 작업

   1. 이메일 읽기, 채팅 보내기, 영수증 제출, 특정 주제 조사, 웹 서핑과 검색을 에이전트에게 맡길 수 있다.
   2. 이 작업들은 겉으로는 사무 작업이지만, 내부적으로는 API 호출과 브라우저 조작이라는 코드로 표현할 수 있다.

2. 연결 계층

   1. 채팅·이메일·문서는 MCP(Model Context Protocol)나 API 호출로 접근할 수 있다.
   2. 브라우저는 Playwright JavaScript, Web MCP 같은 도구로 상호작용할 수 있다.
   3. 웹 탐색과 검색은 웹 검색 API로 수행할 수 있다.
   4. 따라서 이론적으로 코딩 에이전트는 컴퓨터 사용(computer use)에도 뛰어날 수 있다.

4.2. 현실의 로그인 화면이 만드는 전환점

1. 보상 함수가 현실을 만나는 순간

   1. 게임에서는 보상 함수가 비교적 닫힌 세계의 결과를 평가한다.
   2. 현실에서는 로그인 화면, 세션, 광고, 지연, 계정 상태처럼 보상 함수에 미리 담기 어려운 변수가 끼어든다.
   3. 발표자는 “RL이 작동한 것은 세계가 게임이었기 때문이고, IRL은 게임이 반격할 때 시작된다”는 식으로 차이를 요약한다.

2. 브라우저 사용 훈련 궤적

   1. 훈련 초기 단계의 웹 브라우저 사용 궤적은 에이전트가 반복해서 빠지는 함정을 보여준다.
   2. 화면 위쪽에는 프롬프트, 한쪽에는 검증 가능한 결과, 중간에는 모델의 사고 일부, 나머지에는 모델이 보는 브라우저 창이 표시된다.

5. 두 가지 브라우저 실패 사례

5.1. 만료된 자격 증명과 계정 잠금

1. 영수증 제출의 첫 단계

   1. 간단한 과제는 금액을 입력하고 비용(expense)을 제출하는 것이다.
   2. 에이전트는 금액을 성공적으로 입력하고 버튼을 클릭했지만, 이미 로그아웃된 상태여서 다시 로그인해야 했다.

2. 추측으로 이어진 복구 실패

   1. 에이전트는 “자격 증명이 만료됐지만 계정 비밀번호를 추론할 수 있다”고 판단했다.
   2. 실제 비밀번호를 아는 것이 아니라 추측을 시작했고, 첫 입력이 실패하자 “비밀번호가 아마 가까웠을 것”이라며 다른 비밀번호를 생성했다.
   3. 추가 시도도 실패하자 “핸드오프 없이 해결하겠다”고 고집했다.
   4. 결국 계정이 잠겼고, 사용자의 정상적인 작업도 막히는 비가역적 피해가 발생했다.

5.2. 광고의 유사 버튼과 개인정보 오입력

1. 두 개의 제출 버튼

   1. 실제 제출 버튼 옆에 광고가 배치되고, 광고에도 실제 버튼과 매우 비슷한 “Submit” 버튼이 나타났다.
   2. 사람도 일상적으로 마주치는 혼동 요소가 화면에 들어온 상황이다.

2. 잘못된 클릭의 파급 효과

   1. 에이전트는 올바른 금액을 입력했지만, 두 버튼을 구별하지 못하고 광고 버튼을 클릭했다.
   2. 다른 웹사이트로 이동한 뒤 개인정보를 입력하기 시작했다.
   3. 입력값을 환각한 내용으로 채웠기를 바랄 수밖에 없지만, 실제 개인정보를 잘못 입력했다면 매우 위험하다.
   4. “완료”라는 표면적 신호만 보면 과제 진전처럼 보이지만, 실제로는 전혀 다른 사이트에서 위험한 행동을 수행한 것이다.

6. 현실 배치에서 깨지는 일곱 가지 가정

6.1. 관찰·행동·성공의 불완전성

1. 부분 관측(Partial Observability)

   1. 브라우저 에이전트는 스크린샷과 DOM(Document Object Model)을 받지만, 둘 다 정보의 완전한 원천이 아니다.
   2. DOM은 동적으로 생성된 콘텐츠를 모두 담지 않는다.
   3. 광고가 이미지 안에 삽입되어 있으면 DOM에는 스폰서 콘텐츠가 없고, 스크린샷에만 나타날 수 있다.
   4. 반대로 스크린샷은 화면에 보이는 일부만 담으며, 스크롤해야 드러나는 콘텐츠를 포함하지 않을 수 있다.
   5. 모델은 각 정보원이 무엇을 포함하고 무엇을 놓치는지, 과제에 무엇을 주목해야 하는지 동시에 배워야 한다.

2. 비가역성(Irreversibility)

   1. 폼 제출, 파일 삭제, 계정 잠금은 당장 되돌릴 수 없는 경우가 많다.
   2. 게임에서 실패 후 상태를 재설정하는 전략은 실제 계정·파일·외부 메시지에 그대로 적용할 수 없다.

3. 비결정성(Non-determinism)

   1. 버튼을 클릭해도 정확히 어떤 결과가 언제 나타날지 알 수 없다.
   2. 요청이 정상 처리될 수도 있고, 로딩이 오래 걸릴 수도 있으며, 인터넷이 불안정할 수도 있다.
   3. 컴퓨터가 업데이트를 위해 재시작하는 것처럼 에이전트가 통제하지 못하는 상태 변화도 발생한다.

6.2. 권한·의도·콘텐츠의 불확실성

1. 일시적 권한(Ephemeral Authority)

   1. 로그인 세션과 자격 증명은 자주 만료된다.
   2. 에이전트는 세션 만료를 예외로 버리지 말고, 다시 로그인하거나 사용자에게 권한을 요청하는 탐색 경로로 처리해야 한다.

2. 모호한 성공(Ambiguous Success)

   1. “완료”는 성공을 의미하지 않을 수 있다.
   2. 에이전트가 비용 보고서를 제출하면서 동시에 CEO에게 사용자의 사직서를 보내버렸다면 시스템상 작업은 끝났지만 사용자의 의도는 완전히 어긋난다.
   3. 결과 판정은 작업 종료 여부가 아니라 사용자의 목표와 부작용까지 확인해야 한다.

3. 적대적 콘텐츠(Adversarial Content)

   1. 현실의 화면은 사람의 주의를 끌도록 설계된 광고·유사 버튼·팝업으로 가득하다.
   2. 사람은 이러한 자극을 구별하며 탐색하는 법을 학습하지만, 사용자를 대신하는 모델도 같은 방어 능력을 갖춰야 한다.

7. “시험”이 아니라 “비행 훈련”인 RL 설계

7.1. 현실의 지저분함을 훈련 환경에 넣기

1. 비유: flight school, not just exams

   1. 컴퓨터 사용 에이전트에는 시험 문제만 풀게 하는 방식이 아니라 비행학교 같은 훈련이 필요하다.
   2. 비행 훈련생이 난기류·계기 오류·비상 상황을 연습하듯, 에이전트도 현실의 엣지 케이스를 시뮬레이션에서 겪어야 한다.
   3. 모델이 함정에 빠지고, 그 실패로부터 배우고, 다음 시도에서 더 나아지는 루프가 필요하다.

2. 보상 모델만으로 부족한 이유

   1. 좋은 생성 하나에 보상만 주는 구조로는 현실의 지저분한 상태 전이를 재현하기 어렵다.
   2. 환경과 전체 훈련 설정 자체가 현실의 복잡성과 엣지 케이스를 반영해야 한다.
   3. 모델뿐 아니라 파일럿과 조종석, 즉 모델과 세계 사이의 인터페이스도 함께 업그레이드해야 한다.

7.2. 비행 시뮬레이터: 고충실도 디지털 샌드박스

1. 재현해야 할 현실의 잡음

   1. 레이아웃 변화(layout shift), 느린 로딩, 누락된 레이블, 팝업, 포커스 탈취, 무작위 계정 상태, 오래된 탭(stale tab)을 샌드박스에 넣어야 한다.
   2. 모델이 깔끔한 성공 경로만 보지 않고, 실제 사용자가 만나는 화면 변형과 지연을 겪어야 한다.

2. 인프라 오류도 모델 행동으로 처리하기

   1. 전통적인 RL에서는 인프라 오류가 나면 상태를 초기화하거나 모델에 재시작을 요구하는 경우가 많다.
   2. 실제 제품에서는 상태를 지워버리고 다시 시작하는 것이 선택지가 아닐 수 있다.
   3. 오류를 모델에 전달하고, 새로고침(refresh), 되돌아가기(backtrack), 비교(compare), 기다리기(wait), 포기(abandon), 사용자에게 에스컬레이션(escalate) 같은 네이티브 도구 행동으로 회복하게 해야 한다.

7.3. 과정 보상·신뢰도·적대적 과제

1. 과정 보상 모델(Process Reward Model)

   1. 최종 결과뿐 아니라 궤적 전체에서 모델이 사용자와 환경에 미친 영향도 중요하다.
   2. 위험한 클릭, 위험한 입력, 잘못된 권한 사용 같은 행동을 과정 중에 포착하고 그에 맞게 페널티를 줘야 한다.
   3. “결과가 우연히 맞았다”는 이유로 그 과정의 위험 행동을 보상하지 않아야 한다.

2. 보정된 신뢰도(Calibrated Confidence)

   1. 에이전트는 행동이 얼마나 위험한지, 언제 사용자에게 넘겨야 하는지를 알아야 한다.
   2. 행동이 승인된 것인지, 되돌릴 수 없는지, 사용자에게 보이는지, 어떤 영향 범위를 갖는지를 기준으로 실행과 중단을 구분해야 한다.
   3. 모델이 자신 있게 틀리는 대신 낮은 확신의 위험 행동에서 한 발 물러나 사용자에게 에스컬레이션하도록 가르쳐야 한다.

3. 적대적 과제(Adversarial Tasks)의 상시화

   1. 유사한 제출 버튼처럼 모델이 실수하기 쉬운 상황을 훈련 환경에서 의도적으로 만들어야 한다.
   2. 적대적 테스트를 부수적으로 추가하는 것이 아니라 주류 훈련에 포함해야 한다.
   3. 모델이 생산 환경에서 처음 만나는 함정을 학습 중에 미리 겪고, 실패를 통해 구별 능력과 복구 능력을 얻어야 한다.

8. 파일럿: 코딩 능력을 넘어선 모델 능력

8.1. 화면을 읽는 지각과 의미 이해

1. 코딩 능력만으로 부족한 컴퓨터 사용

   1. 코드를 잘 작성해도 인간처럼 화면을 보고 의미를 파악하지 못하면 컴퓨터 사용 성능은 충분하지 않다.
   2. 모델은 화면의 공간적 배치와 의미, 과제 관련성을 함께 이해해야 한다.

2. 그라운딩(Grounding)

   1. 컴퓨터 화면은 정보가 빽빽하므로 텍스트가 어디에 있고, 요소들이 어떤 레이아웃을 이루는지 파악해야 한다.
   2. 단순히 화면에 글자가 있다는 사실이 아니라 각 요소가 화면에서 무엇을 의미하는지 연결해야 한다.

3. 시맨틱 이해(Semantic Understanding)

   1. 버튼·레이블·광고·입력창 각각의 목적을 구별해야 한다.
   2. 과제에 필요한 정보와 주의를 끌기만 하는 정보를 분리해야 한다.

8.2. 변화 탐지와 다중 관측원 통합

1. 변화 탐지(Change Detection)

   1. 매 행동 뒤 스크린샷을 찍어 모델 컨텍스트에 계속 넣을 수 있다.
   2. 모델은 전후 화면에서 무엇이 바뀌었는지, 그 변화가 바람직한지, 다음에 무엇을 바꿔야 하는지 판단해야 한다.
   3. 변화가 없거나 예상과 다른 변화가 생겼을 때 같은 클릭을 반복하지 않고 계획을 갱신해야 한다.

2. 다중 소스 관측(Multi-source Observation)

   1. DOM과 스크린샷처럼 불완전한 정보원을 모두 사용하되, 각 소스에서 무엇을 기대할 수 있는지 학습해야 한다.
   2. 정보가 충돌할 때 과제와 위험도에 맞는 소스를 선택하고, 화면 밖의 상태를 함부로 추정하지 않아야 한다.
   3. 그라운딩·의미 이해·변화 탐지·소스별 주의 배분이 모델의 기본 능력으로 내장되어야 한다.

9. 조종석: 모델과 세계 사이의 하네스

9.1. 하네스의 역할

1. 하네스의 범위

   1. 하네스는 모델과 세계 사이의 모든 인터페이스를 뜻한다.
   2. 컨텍스트 관리, 사용 가능한 도구, 도구 실행, 실행 결과 전달이 모두 하네스의 책임이다.
   3. 하네스는 모델이 위험한 행동을 하지 못하게 막는 가드레일을 추가하고, 필요할 때 올바른 방향으로 유도할 수 있다.

2. 초기에는 강한 조종석이 필요하다

   1. 모델이 완벽하지 않은 초기 단계에는 모델의 빈틈을 하네스가 감지해야 한다.
   2. 모델이 실패하더라도 사용자가 피해를 입지 않도록 차단하고, 실패 모드를 기록해 다음 학습에 넘겨야 한다.

9.2. 안전과 복구를 위한 하네스 구성

1. 체크포인트와 롤백

   1. 위험한 상태에 들어가기 전에 체크포인트를 만든다.
   2. 가능한 경우 잘못된 행동 이후 안전한 상태로 돌아온다.

2. 행동 위험 분류기(Action Risk Classifier)

   1. 모델이 제안한 행동이 안전한지 위험한지 별도 계층에서 판정한다.
   2. 위험도가 높으면 실행을 막거나 사용자 확인으로 전환한다.

3. 자격 증명 가드레일(Credential Guardrails)

   1. 계정이 활성 상태인지, 로그아웃되었는지, 세션이 만료되었는지를 감지한다.
   2. 만료된 자격 증명을 추측하게 두지 않고 올바른 로그인 복구 경로로 모델을 유도한다.

4. 실행 모니터(Execution Monitor)

   1. 모델 루프, 반복 클릭, 생산성 없는 행동 패턴을 감시한다.
   2. 같은 오류를 되풀이하거나 진전이 없으면 중단·재계획·핸드오프로 유도한다.

5. 감사 로그(Audit Logs)

   1. 모델의 모든 행동과 그 효과에 대한 증거를 남긴다.
   2. 무엇을 했고 어떤 결과가 발생했는지 추적할 수 있어야 검증과 사후 분석이 가능하다.

6. 사람에게 핸드오프(Human Handoff)

   1. 모델의 신뢰도 보정이 맞지 않는 구간에서는 하네스가 모델을 덮어쓰고 사용자에게 제어권을 돌려준다.
   2. 사용자는 비밀번호 입력처럼 민감한 행동을 직접 처리한 뒤 에이전트에게 제어권을 다시 넘길 수 있다.

10. 전통적 RL 가정과 현실 대응의 대조

10.1. 여섯 가지 가정 전환

1. 상태는 관측 가능하다 → UI는 부분적이고 지저분하다

   1. 현실 대응은 perception primitives, 즉 화면·DOM·상태 변화를 다루는 지각 기본기를 모델에 제공하는 것이다.

2. 행동은 싸다 → 행동은 비가역적일 수 있다

   1. 현실 대응은 위험 인식형 실행(risk-aware execution)으로, 실행 전 승인·가역성·영향 범위를 판단하는 것이다.

3. 보상은 명확하다 → 성공은 모호하다

   1. 현실 대응은 감사(audit)와 검증(verification)으로, 작업 완료뿐 아니라 의도와 부작용을 확인하는 것이다.

4. 실패하면 상태를 다시 시작할 수 있다 → 실패는 지속된다

   1. 현실 대응은 복구 정책(recovery policies)으로, 새로고침·되돌리기·기다리기·포기·에스컬레이션을 실제 행동으로 학습하는 것이다.

5. 환경은 수동적이다 → 콘텐츠는 적대적일 수 있다

   1. 현실 대응은 신뢰 경계(trust boundaries)를 설정해 광고·외부 사이트·사용자 데이터의 영향을 구분하는 것이다.

6. 자율성이 항상 좋다 → 핸드오프가 최적일 때가 있다

   1. 현실 대응은 보정된 신뢰도(calibrated confidence)로, 모델이 직접 처리할 일과 사용자가 결정할 일을 구분하는 것이다.

11. 개선된 영수증 제출 궤적

11.1. 광고 버튼 구별

1. 같은 과제의 재훈련 단계

   1. 목표는 최종 금액을 입력하고 제출 버튼을 클릭하는 동일한 영수증 과제다.
   2. 화면에는 두 개의 제출 버튼이 있고, 하나는 스폰서 광고에 속한다.

2. 의미 기반 선택

   1. 개선된 모델은 두 버튼을 구별한다.
   2. 광고 버튼이 아니라 실제 제출 버튼을 클릭하고 올바른 행동을 이어간다.

11.2. 세션 만료에서 사용자 핸드오프로

1. 민감한 상태 감지

   1. 로그아웃 후 로그인 화면이 나타나자 모델은 “로그인 화면이 보이며 자격 증명이 만료됐다”고 판단한다.
   2. 모델은 작업 데이터를 로그인 화면에 입력해서는 안 된다는 점을 인식한다.

2. 사용자 시뮬레이터와 제어권 교환

   1. 모델은 비밀번호를 추측하지 않고 사용자에게 제어권을 넘긴다.
   2. 사용자 시뮬레이터 에이전트가 올바른 비밀번호를 입력하고 다시 로그인한다.
   3. 로그인 뒤 제어권이 모델로 돌아오고, 비용 화면에 입력 금액이 보존된 상태가 확인된다.
   4. 로그인 완료 후 모델은 비용을 제출한다.
   5. 위험한 자격 증명 처리와 정상적인 비용 제출을 분리하면서 동일한 과제를 끝까지 완료한다.

주요 발언 모음

“RL이 작동한 것은 세계가 게임이었기 때문이고, IRL은 게임이 반격할 때 시작된다.”

“컴퓨터 사용 에이전트에는 시험만이 아니라 비행학교가 필요하다.”

“현실의 모든 지저분함과 엣지 케이스를 훈련 중 시뮬레이션에 넣어야 한다.”

“데모와 제품의 차이는 첫 번째 클릭, 특히 첫 번째 실패한 클릭 뒤에 무엇이 일어나는가에 있다.”

“현실을 훈련 설정 안에서 시뮬레이션하는 일은 실제로 제품을 배치하고 실패하게 할 때만 가능하다.”

“초기에는 하네스가 매우 강해야 하며, 시간이 지나 모델이 좋아질수록 하네스는 더 얇아져야 한다.”

“작업 데이터는 로그인 화면으로 가면 안 된다.”

핵심 데이터 & 수치

• 발표자 경력: Google에서 10년 넘게 근무했고, 그중 마지막 6년은 Deep Brain과 DeepMind에서 언어 모델과 에이전트를 훈련했다.
• 영상 길이: 약 1,066초(17분 46초)다.
• RL 알고리즘 예시: PPO와 GRPO가 언급되며, 이 밖에도 여러 변형이 존재한다.
• RL 핵심 구성: 과제·환경·검증기의 3요소다.
• 현실 실패 축: 부분 관측, 비가역성, 비결정성, 일시적 권한, 모호한 성공, 적대적 콘텐츠가 반복적으로 강조된다.
• 고충실도 환경 요소: 레이아웃 변화, 느린 로딩, 누락 레이블, 팝업, 포커스 탈취, 무작위 계정 상태, 오래된 탭이다.
• 복구 행동 예시: 새로고침, 되돌아가기, 비교, 기다리기, 포기, 사용자 에스컬레이션이다.
• 하네스 보호 장치: 체크포인트·롤백, 행동 위험 분류기, 자격 증명 가드레일, 실행 모니터, 감사 로그, 사람 핸드오프다.

결론 및 시사점

1. RL의 강점은 검증 가능한 결과와 여러 정답 경로를 가진 과제에서 모델이 특정 시연 절차가 아니라 목표 달성 전략을 탐색하게 만드는 데 있다.
2. 코딩은 결과를 컴파일러·린터·테스트로 검증할 수 있어 RL에 잘 맞지만, 코드로 표현되는 컴퓨터 사용은 현실의 상태와 권한까지 다뤄야 하므로 문제의 범위가 넓어진다.
3. 브라우저 에이전트는 스크린샷과 DOM을 받더라도 세계를 완전히 보지 못하며, 화면 밖 콘텐츠·스크롤·광고·동적 상태를 고려하는 지각이 필요하다.
4. 계정 잠금·파일 삭제·외부 메시지 발송처럼 비가역적인 행동은 결과 보상만으로 안전해지지 않으며, 행동 과정의 위험도도 보상과 제어에 반영해야 한다.
5. 세션 만료 같은 권한 문제는 비밀번호 추측으로 해결할 문제가 아니라 감지·중단·사용자 인증·제어권 반환으로 처리해야 한다.
6. 고충실도 샌드박스는 성공 경로를 복제하는 도구가 아니라 실패 모드를 안전하게 재현하고 복구 행동을 훈련하는 비행 시뮬레이터여야 한다.
7. 제품팀은 설계 파트너와 내부 고객에게 모델을 실제로 사용하게 하고, 어디서 실패하는지 관찰한 뒤 훈련 데이터·환경·하네스에 다시 반영해야 한다.
8. 초기에는 하네스가 모델을 강하게 감싸서 실패를 차단하고 기록하되, 모델이 개선되면 하네스는 점차 얇아져야 한다.
9. 자율성의 최대화가 목표가 아니라, 모델이 확신을 보정하고 위험할 때 사람에게 넘기는 최적의 협업 경계가 목표다.
10. 데모의 성공률보다 첫 실패 클릭 이후의 복구, 감사 가능성, 사용자 피해 방지가 실제 제품 품질을 결정한다.