한 번의 평가는 prompt, environment, grader가 함께 만든다
AI 평가를 문제와 정답의 묶음으로만 보면, 모델이 실제로 무엇을 했는지 놓치기 쉽다. Mechanize의 Stephen Yang과 Ege Erdil은 각 테스트 케이스를 세 부분으로 나눈다. 모델이 받는 prompt, 모델이 행동하는 environment, 결과를 수치로 바꾸는 grader다. 같은 지시문도 어떤 파일과 도구에 접근할 수 있는지, 실행 결과가 다음 행동에 어떻게 돌아오는지, 무엇을 성공으로 세는지에 따라 전혀 다른 평가가 된다. 00:00–01:17
RL environment도 이 세 요소를 갖는다. 영상이 제시하는 차이는 용도와 반복 방식이다. RL environment는 학습 과정 안에서 수많은 rollout을 만들어 가중치 업데이트에 쓰인다. eval은 학습법이나 하이퍼파라미터를 고르고, 새 checkpoint가 이전 것보다 나아졌는지 판단하는 바깥쪽 계측기다. 양쪽의 파일 형식이 비슷해도 동일한 품질 기준이나 비용 구조를 적용할 수 없는 이유다. 01:17–02:05
화자들은 이 차이를 가격과 반복 횟수로 설명하다가 스스로 조건을 정정한다. RL은 많은 종류의 경험을 요구하므로 개별 과제의 저렴함과 다양성이 중요하다. 신뢰할 수 있는 eval은 같은 테스트를 여러 번 실행해 작은 차이를 구분하고 연구자의 결정을 바꾸므로, 한 사례에 더 많은 비용을 쓸 수 있다. 여기서 핵심은 ‘eval은 비싸고 RL은 싸다’는 고정 법칙이 아니다. 병렬도, 같은 과제의 재사용 횟수, 사람이 최종 결정을 내리는 빈도를 구분해야 한다는 점이다.
공개 benchmark 한 번 뒤에는 수많은 내부 checkpoint 비교가 있다
공개 모델의 benchmark 표는 완성된 모델끼리 비교하는 장면만 보여 준다. 실제 개발에서는 서로 다른 데이터, RL 방법, 병합 설정을 적용한 checkpoint가 계속 생긴다. 영상은 연구소 내부에서 이 후보들을 평가하는 횟수가 공개 리더보드 측정보다 훨씬 많다고 설명한다. 내부 eval이 없다면 새 학습법이 모델을 개선했는지, 한 능력을 올리면서 다른 능력을 잃었는지 판단하기 어렵다. 02:05–04:29
좋은 과제는 모델이 손도 대지 못하는 문제와 이미 항상 성공하는 문제 사이에 있어야 한다. 비밀번호 입력란의 최대 길이를 8자에서 16자로 바꾸는 일은 요구와 판정이 명확하다. 반면 GBA emulator를 구현하는 과제는 짧은 문장으로 적혀 있어도 오디오, 비디오, 게임 로직, 입력 장치와 다양한 ROM을 함께 처리해야 한다. 과제 설명의 길이와 실제 복잡성은 다르다. 영상은 이 대비를 통해 현재 모델의 능력 가장자리에서 차이를 드러낼 수 있는 과제를 찾으라고 말한다. 04:29–07:44
기술적으로는 평가 점수의 분산도 함께 봐야 한다. 같은 checkpoint를 반복 실행했을 때 점수 변동이 두 후보의 차이보다 크다면, 순위 하나만으로 학습법을 고르기 어렵다. 이 문장은 영상의 수치 보고가 아니라 평가 설계에 대한 해석이다. 반복 실행 수와 비용을 정할 때는 기대하는 개선 폭과 점수 변동을 함께 기록해야 한다.
결정론적 시스템도 테스트가 얕으면 검증되지 않는다
화자들이 설명한 GBA Eval은 모델에 24시간을 주고 Game Boy Advance 에뮬레이터를 처음부터 만들게 한다. GBA 하드웨어는 결정론적이어서 같은 입력과 ROM에는 같은 프레임 순서가 나와야 한다. 기준 에뮬레이터와 출력도 비교할 수 있다. 24시간은 이 대화에서 소개한 과제의 제작 예산이며, 보편적인 평가 기준이나 독립 측정치는 아니다. 이 조건은 정답을 정의할 수 있게 해 주지만, 구현 전체를 쉽게 검증해 준다는 뜻은 아니다. 새 하이라이트 00:00–00:45
화자들에 따르면 모델이 스스로 만드는 테스트는 대개 얕다. 대부분은 입력 없이 게임이 부팅되는지만 확인한다. 더 정교한 모델은 A 버튼을 눌러 시작 메뉴를 넘기기도 하지만, 실제 플레이를 이어 가며 다양한 입력과 상태를 탐색하지는 않는다. 그래서 부팅에는 성공한 에뮬레이터도 사람이 게임을 시작하면 크게 실패할 수 있다. 00:45–01:49
여기서 확인해야 할 것은 결정성, 정답표, 테스트 커버리지의 차이다. 결정성은 같은 조건을 반복할 수 있게 하고, 기준 구현은 비교 대상을 제공한다. 하지만 어떤 입력과 상태를 실제로 비교할지는 별도 문제다. 테스트가 시작 화면 주변만 훑으면 결정론적 시스템에서도 긴 플레이 도중의 오류는 보이지 않는다. 이 구분은 GBA 사례를 평가 설계 원칙으로 풀어 쓴 해석이다.
눈에 띄는 버그를 고친 뒤부터 긴 꼬리의 실패가 남는다
영상은 복잡한 소프트웨어의 실패가 멱법칙에 가까운 긴 꼬리를 보인다고 설명한다. 처음에는 적은 노력으로 부팅 실패처럼 뚜렷한 문제를 고칠 수 있다. 이후에는 약 1,000프레임을 플레이해야 드러나는 버그처럼 드문 실패가 남는다. 한 버그를 패치해도 기준 에뮬레이터나 실제 하드웨어와 다르게 동작하는 다른 경로는 계속 존재한다. 02:04–02:58
이 단계에서는 실제 사용이 데이터 수집 장치가 된다. 개발자가 게임을 플레이하고, 사용자 커뮤니티가 버그를 제보하며, 여러 게임에서 수백만 또는 수천만 프레임에 한 번 나타나는 실패를 재현한다. 화자는 10억 프레임에 한 번 생기는 오류까지 예로 든다. 이 숫자들은 특정 에뮬레이터의 공개 실패율을 측정한 값이 아니라 긴 꼬리의 규모를 설명하는 사례다. 02:58–03:48
논리를 개념적으로 이해했다고 완벽한 복제가 따라오지는 않는다. 어떤 실패가 남았는지 관찰하고, 재현 테스트를 만들고, 설계를 고치는 순환이 필요하다. 이 주장은 뒤에서 다룰 사용자의 예외 상황과도 연결된다. 모델이 떠올린 테스트만 반복하면 실제 플레이어가 만드는 상태 분포를 충분히 덮지 못한다. 03:48–04:34
47.12초 Short는 버그 하나를 고쳐도 다른 차이가 남는다는 가상 사례에서 시작해, 개발자의 직접 플레이와 사용자 제보가 필요한 이유까지 담는다. 화자는 일정 규모를 넘으면 충분한 실패 데이터를 얻으려면 사용자 커뮤니티의 제보에 의존해야 한다고 본다. 뒤에 이어지는 수백만 프레임 단위의 예시나 보안 시험 논의는 이 Short에 들어 있지 않다.
10시간 무오류는 1만 시간 무오류의 증거가 아니다
GBA 사례는 보안 시험의 비유로 확장된다. 한 번도 공격적으로 검토하지 않은 소프트웨어는 몇 시간만 살펴봐도 눈에 띄는 취약점을 찾을 수 있다. 그 문제를 고친 뒤에는 더 많은 연산과 사람의 작업 시간이 필요하다. 코드에 접근해 복잡한 익스플로잇 체인을 찾거나 수백만 달러를 들여 분석하면, 2~3시간 시험에서는 떠올리지 못한 경로를 발견할 수 있다는 설명이다. 04:34–06:18
화자의 결론은 관찰한 시간보다 훨씬 긴 무오류 구간을 자신 있게 추론할 수 없다는 것이다. 복잡한 시스템에서 10시간 동안 문제를 찾지 못했다면 다음 10~20시간에 관한 제한된 근거는 될 수 있다. 다음 1만 시간에도 문제가 없을 것이라는 강한 근거는 되지 않는다. 이는 모든 소프트웨어가 반드시 같은 고장 분포를 따른다는 실험 법칙이 아니라, 검증 예산과 주장 범위를 맞추라는 논증이다. 06:18–06:49
평가 보고서에는 성공률과 함께 탐색한 입력 분포, 총 실행 시간, 상태 수, 반복 횟수, 아직 시험하지 않은 영역을 남겨야 한다. 모델 두 개가 같은 점수를 받아도 한쪽을 10시간, 다른 쪽을 1만 시간 시험했다면 증거의 강도가 다르다. 더 긴 시험에서 새 실패가 얼마나 나타나는지 곡선으로 기록해야 품질이 포화됐는지 판단할 수 있다. 이는 영상의 사례에서 도출한 추가 설계 제안이다.
모델이 만든 테스트는 모델이 상상한 사용자까지만 덮는다
코딩 agent는 코드를 쓰고 자체 테스트를 만든 뒤, 테스트가 통과할 때까지 수정할 수 있다. 이 루프만 보면 자율적인 검증처럼 보인다. 그러나 모델이 긴 문자열이나 비정상 입력을 상상하지 못하면 테스트에도 그 사례가 없다. 구현과 검증이 같은 시야를 공유하므로, 놓친 가정이 그대로 남는다. 영상은 비밀번호 입력란에 매우 긴 문자열을 넣거나, 실제 사용자가 예상하지 못한 순서로 상호작용하면 웹사이트가 멈추거나 충돌할 수 있다고 설명한다. 07:44–10:37
이 문제는 테스트의 개수보다 분포에 가깝다. 익숙한 요구를 문장만 바꿔 여러 번 제시해도 실제 사용자의 새로운 행동을 덮지 못한다. API 계약이나 제품 요구사항도 마찬가지다. 모델은 학습 데이터에서 본 표현을 조합할 수 있지만, 특정 사용자가 왜 그 기능을 필요로 하는지까지 자동으로 아는 것은 아니다. 10:37–13:11
따라서 eval을 만들 때는 실패 사례를 그대로 복사하는 단계와 그 실패가 드러낸 일반 능력을 추출하는 단계를 나눌 필요가 있다. 한 사용자가 긴 입력으로 페이지를 멈췄다면, 그 문자열만 테스트에 추가하는 것으로 끝낼 수 있다. 더 강한 평가는 입력 크기, 이벤트 순서, 상태 복구처럼 같은 원인을 가진 변형을 만든다. 이것은 본문의 설계 해석이며, 영상이 특정 생성 절차를 검증했다는 뜻은 아니다.
회귀 테스트에 합격했다고 다른 구현과 동등한 것은 아니다
테스트가 모두 초록색인데 사용자는 기능을 쓸 수 없다. 새로 공개된 12분 27초 대화는 이 간극을 설명한다. 한 화자가 “이건 RL 환경이 아니라 평가인데, 적대적으로 최적화한다는 말은 무슨 뜻인가”라고 묻는다. 다른 화자는 제출물의 실제 품질을 점수에 담아야 하는데, 단순한 테스트만 있으면 기능이 제대로 작동하지 않아도 만점을 받을 수 있다는 뜻이라고 답한다. 의도적으로 채점기를 공략하지 않아도 생기는 문제다. 새 영상 00:00–00:56
화자는 자신이 PR에 넣는 테스트의 목적을 구분한다. 나중에 누군가 코드를 바꿔 기존 기능을 깨뜨렸을 때 알아내는 것과, 다른 사람이 새로 만든 구현이 원래 기능과 동등한지 평가하는 것은 다르다. 회귀를 잡으려고 작성한 테스트는 실제로 노출된 기능과 가능한 상호작용 전체를 덮지 않을 수 있다. 따라서 기존 저장소의 테스트를 그대로 가져왔다고 포괄적인 품질 채점기가 되지는 않는다. 00:56–01:34
대화는 이 차이가 학습에도 영향을 준다고 본다. 비슷한 환경에서 점수를 높이도록 반복 훈련하면, 모델은 어떤 테스트가 나올지 예상하고 그 테스트를 통과할 법한 구현을 만드는 방향으로 압력을 받는다. 화자들이 지적하는 것은 ‘테스트 통과’와 ‘사람이 기대한 기능을 완성하기’ 사이의 틈이다. 모든 모델이 의도적으로 속임수를 쓴다는 주장은 아니다. 01:34–02:08
글의 기술적 해석: 회귀 테스트는 그대로 쓸 가치가 있다. 다만 이를 학습 보상이나 모델 비교에 사용하려면 어떤 요구를 판정하고 무엇을 보지 못하는지 다시 따져야 한다. 기존 구현이 특정 테스트를 통과한다는 사실과, 그 테스트를 통과한 모든 구현이 충분히 좋다는 명제는 같지 않다.
팝업 테스트는 통과했는데 글을 선택하자 입력이 사라졌다
화자는 모델이 만든 기능이 제한된 조건에서는 작동해도 사람이 기대하는 편의성과 예외 처리가 빠질 수 있다고 말한다. 비밀번호 입력창에 긴 문서를 붙여 넣는 예를 들고는, 그 사례가 다소 인위적이라고 스스로 한정한다. 이어 자신이 자주 봤다고 설명하는 팝업 문제로 옮겨 간다. 이 빈도는 화자의 관측이며, 별도의 오류율 실험은 제시되지 않는다. 02:08–03:12
버튼을 누르면 팝업이 열리고, 글을 입력한 뒤 저장할 수 있다. 사용자는 입력한 글을 선택하려고 상자 안에서 마우스를 누른 채 오른쪽으로 끈다. 커서가 팝업 바깥까지 나간 상태에서 버튼을 놓으면, 구현은 이 동작을 ‘팝업 밖을 클릭했다’고 해석한다. 창이 닫히고 입력도 사라진다. 다시 열어도 글은 돌아오지 않는다. 03:12–03:50
반면 테스트는 ‘팝업 열기 → 글 입력 → 저장 → 등록 확인’만 수행할 수 있다. 이 테스트에서는 같은 구현이 합격한다. 다른 화자는 드래그를 재현하려면 레이아웃마다 커서의 시작점과 끝점, 이동 경로까지 다뤄야 한다고 덧붙인다. 요소를 찾아 글을 넣고 버튼을 누르는 테스트보다 작성하기 까다롭다. 대화가 말하는 차이는 막연한 실사용의 복잡함이 아니라, 테스트 작성자가 생략하기 쉬운 행동의 연속이다. 03:50–04:48
글의 기술적 해석: 이 사례를 평가로 옮긴다면 저장 결과뿐 아니라 입력 도중의 상태 보존도 확인해야 한다. 마우스를 누른 위치와 놓은 위치가 다른 상황, 창을 닫았다가 다시 여는 상황을 실제로 실행해 볼 수 있다. 이는 예시에서 도출한 점검 방법이다. 대화는 모든 UI 오류를 잡는 테스트 목록이나 특정 브라우저 API 구현을 제공하지 않는다.
문제에 없는 테스트 ID까지 추측하게 만드는 평가
대화는 모델이 작성하기 쉬운 테스트에 맞춰 기능을 구현하는 데서 더 나아가, 테스트 작성자의 관행까지 추측할 수 있다고 지적한다. 예를 들어 폼 필드를 추가하라는 과제에서 테스트가 사용할 식별자를 짐작하는 행동이다. 화자 한 명은 이를 모델이 ‘생각한다’고 표현했다가 의인화가 섞였다고 바로 한정한다. 04:48–05:27
다른 화자는 두 경우를 나눈다. 어떤 작업 기록에서는 명시적인 추론 없이 사람들이 흔히 쓰는 것과 비슷한 분포에서 식별자가 뽑혀 우연히 맞는다. 다른 기록에서는 모델이 식별자를 지시받지 않았음을 알아차리고, 찾아보려다 실패한 뒤 합리적으로 추측하겠다고 명시한다. 우연히 맞는 관행적 선택과, 빠진 정보를 알아내려는 추론을 같은 행동으로 뭉뚱그릴 수 없다. 05:27–06:22
글의 기술적 해석: 테스트가 특정 식별자를 요구한다면 모델이 그 요구를 어디서 알 수 있었는지도 확인해야 한다. 요청이나 접근 가능한 문서에 없는 이름을 맞혀야 통과하는 문제는 기능 구현 능력과 출제자의 숨은 관행 맞히기를 섞는다. 식별자를 관측 가능한 계약으로 제공하거나, 이름 대신 요구한 기능을 판정할 수 있는지 검토할 이유가 있다. 뒤의 사용자 의도 평가에서도 출제자만 아는 뜻을 정답으로 강제하는 문제가 반복된다.
테스트가 보지 않는 품질에는 보상이 돌아오지 않는다
화자는 이런 행동의 원인을 인터넷에서 수집한 낮은 품질의 학습 과제에서 찾는다. 기본적인 필터를 거쳐도, 이슈 설명만으로 추론할 수 없는 특정 답을 테스트가 요구하는 환경이 남는다는 설명이다. 그 환경에서 높은 점수를 받아야 한다면 테스트가 무엇을 원할지 알아내는 행동이 강화된다. 이는 화자의 인과 설명이며, 어떤 모델의 비공개 학습 데이터와 보상 설정을 직접 확인한 결과는 아니다. 06:22–07:13
이때 테스트가 재지 않는 품질에 시간을 쓰는 일에는 기회비용이 생긴다. 한정된 컨텍스트를 편의성이나 예외 처리에 쓰면, 점수를 받을 것이 확실한 항목에 쓸 토큰이 줄어든다. 화자들은 이를 직원에게 특정 과제의 성과, 더 좁게는 단위 테스트 통과만으로 보너스를 주는 상황에 빗댄다. 그 기준에서 보상받는 행동과 좋은 제품을 만드는 행동이 어긋날 수 있다는 비유다. 07:13–08:05
대화는 이 행동이 명시적인 속임수 계획으로 나타나지 않을 수도 있다고 강조한다. 이미 강화된 방식이 자연스럽게 선택된다면 작업 기록에 의도가 적혀 있지 않아도 같은 문제가 생긴다. 그래서 ‘평가자를 일부러 공격한다’는 설명만으로는 충분하지 않다. 화자의 관점에서는 잘못된 유인 아래 익숙해진 기본 행동도 살펴야 한다. 08:05–08:42
글의 기술적 해석: 학습 과제를 검토할 때는 높은 점수를 얻는 가장 쉬운 방법과 사용자가 원하는 결과를 나란히 비교할 수 있다. 테스트를 통과한 제출물의 기능 누락과 사용 불편을 따로 조사해야, 점수가 놓치는 품질을 찾을 수 있다. 이는 대화에서 도출한 검토 관점이며, 현재 모델의 행동 원인이 하나로 입증됐다는 뜻은 아니다.
토큰은 아끼면서 10분짜리 명령은 다시 실행하는 이유
화자는 지시를 거듭해도 되돌아오는 비슷한 행동으로 명령 출력 처리를 든다. 약 10분 걸리는 명령의 출력을 tail -10으로 보내 마지막 열 줄만 읽는다. 필요한 정보가 없으면 이번에는 마지막 서른 줄을 보려고 명령을 다시 실행하고 또 기다린다. 그래도 못 찾으면 grep으로 검색하려 한다. 10분과 줄 수는 화자가 제시한 예시이며 특정 모델의 평균 실행 시간을 측정한 값이 아니다. 08:42–09:33
화자는 훈련에서 실제 경과 시간을 아끼라는 압력보다 토큰과 컨텍스트를 아끼라는 압력이 강하면 이 행동을 설명할 수 있다고 본다. 출력을 파일에 저장한 뒤 필요한 부분만 검색하면 명령을 반복 실행하지 않아도 되지만, 모델은 그 선택을 하지 않는다는 것이다. 한 화자가 말을 잇다가 다른 화자가 ‘파일을 쓰는 방법은 토큰을 더 쓴다’고 끼어든다. 답변자는 그 지적을 받아들여, 시간을 많이 아끼더라도 토큰이 조금 더 드는 선택을 피하게 된다고 설명한다. 09:33–10:19
여기에는 명시적인 토큰 벌점만 필요한 것은 아니다. 화자는 RL에서 컨텍스트 크기가 고정돼 있다면 부수적인 작업에 쓴 토큰만큼 높은 점수를 얻는 데 쓸 몫이 줄어드는 암묵적 비용이 생긴다고 말한다. 이 설명은 화자의 학습 유인 가설이다. 모든 모델이 실행 시간을 무시한다거나 특정 연구소가 같은 보상식을 쓴다고 확인된 것은 아니다. 10:19–10:40
글의 기술적 해석: 에이전트의 효율을 비교할 때 토큰 수만 보면 이 손실을 놓칠 수 있다. 같은 결과를 얻기까지 도구를 몇 번 실행했는지, 얼마나 기다렸는지, 필요한 출력이 보존됐는지를 함께 볼 필요가 있다. 파일 저장은 이 사례의 대안이지 모든 작업의 의무는 아니다. 어떤 작업에서는 추가 저장 없이 바로 읽는 편이 더 적절할 수 있다.
한 번 따른 지시가 긴 작업에서도 유지되는가
대화는 CLAUDE.md 같은 지시 문서에 ‘명령 출력을 tail에 연결하지 말라’고 써도, 지시 직후 몇 차례만 따르다가 긴 에이전트 작업에서 예전 행동으로 돌아올 수 있다고 말한다. 화자는 이를 RL에서 익힌 강한 사전 경향으로 설명하고, 단순한 테스트에만 그럴듯해 보이는 편법 구현도 같은 문제와 연결한다. 특정 제품의 최신 성능이나 모든 프롬프트의 효과를 판정한 실험은 아니다. 10:40–11:55
마지막 비유는 걷기다. 사람에게 완전히 다른 방식으로 걸으라고 하면 지시는 이해하고 한두 걸음은 바꿀 수 있다. 하지만 통화처럼 다른 일을 함께 하면 곧 평소 걸음으로 돌아갈 수 있다. 화자들이 설명하려는 것은 지시를 이해하는 능력과, 주의가 다른 곳으로 향한 뒤에도 배운 행동을 유지하는 능력의 차이다. 이는 모델의 내부 기제를 입증하는 결과가 아니라 습관을 설명하는 비유다. 11:55–12:27
글의 기술적 해석: 지시를 추가한 직후 한 번 성공한 것만 확인하면 효과를 과대평가할 수 있다. 다른 도구 호출과 여러 단계의 작업을 거친 뒤에도 지켜지는지 살펴야 한다. 앞서 팝업에서 정상 저장 한 번만 시험했던 문제와 닮아 있다. 필요한 것은 지시문이 있다는 사실보다, 실제 행동이 필요한 시점까지 유지됐다는 근거다.
사용자의 실패를 바로 학습 문제로 옮길 수는 없다
“이 일을 시켰는데 안 됐다.” 사용자의 제보에는 모델이 배워야 할 것이 숨어 있다. 하지만 제보를 그대로 문제집에 넣는다고 부족한 능력이 드러나지는 않는다. 뒤이어 공개된 23분 38초 영상에서 Mechanize 대화는 이 간극부터 짚는다. 실제 실패에서 출발해, 무엇을 측정하고 훈련할지 정하는 과정이다.
화자는 창업자가 자신도 원하지 않는 제품을 “누군가는 원하겠지” 하고 만드는 상황에 빗댄다. 모델을 직접 쓰다가 겪은 문제는 적어도 한 사용자의 실제 필요다. 비슷한 사람이 더 있을 것이라는 추측도 그때부터 할 수 있다. 다만 한 사람의 불편이 전체 사용자를 대표한다는 증명은 아니다. 기업 고객이 전한 실패 역시 출발점이지, 원인에 대한 완성된 진단은 아니다. 고객은 원하는 결과를 알더라도 모델에 어떤 능력이 부족한지까지 설명하기는 어렵다. 영상 00:00–02:01
이때 연구자가 해야 할 일은 사례에서 더 근본적인 능력을 추려내는 것이다. 화면에 드러난 실패와 그 실패를 일으킨 능력의 부족은 다를 수 있다. 글의 해석: 실패한 작업, 당시 모델이 볼 수 있던 정보, 실패 원인에 대한 가설을 분리해 두면 도움이 된다. 이후 조건을 바꾼 문제에서도 같은 약점이 나타나는지 살펴야 한다. 원본 사례를 외워 맞히는 것과 그 사례에서 드러난 능력을 갖추는 것은 별도로 확인해야 하기 때문이다.
현실을 줄여도 어려운 이유는 남아 있어야 한다
실제 업무를 평가에 옮기려면 무엇을 덜어낼지 정해야 한다. 현실의 모든 조건을 빠짐없이 복제하는 일은 어렵다. 반대로 복잡한 부분을 지우다 보면, 처음 해결하려던 어려움까지 사라질 수 있다. 화자가 제시하는 기준은 문제를 어렵게 만드는 세부 조건을 남기고, 그 능력과 무관하면서 재현만 어려운 부분을 덜어내는 것이다. 영상 02:01–03:21
어떤 조건이 중요한지는 미리 정해진 공식으로 판별하기 어렵다고 화자는 말한다. 실제 사용자에게 필요한 제품을 설계하는 일처럼 판단이 필요하다. 그는 모델 성능이 좋아지고 연구소 매출도 늘고 있다는 점을 이런 작업이 어느 정도 성과를 내는 근거로 든다. 이는 화자의 추론이다. 이 구간에는 특정 평가 설계가 매출에 미친 영향을 분리해 측정한 결과가 제시되지 않는다.
이 원칙을 기술적으로 읽으면 환경을 작게 만드는 일에도 검증이 필요하다는 뜻이다. 예를 들어 모델이 직접 찾아야 할 의존 관계를 문제 설명에 써 주면 실행은 쉬워지지만, 원래 측정하려던 탐색 능력은 평가하지 못한다. 반대로 판단에 꼭 필요한 기록을 빼면 추론 문제가 아니라 정보가 없는 문제가 된다. 이 두 예시는 글의 해석이며, 영상 속 회사의 실제 작업 사례를 옮긴 것은 아니다.
데이터를 많이 만드는 일과 배울 거리를 정하는 일
AI 학습 데이터 작업을 단순한 외주 업무로만 보면, 무엇을 만들어야 하는지 정하는 사람의 역할을 놓치기 쉽다. 화자는 대규모 작업자에게 데이터 제작을 맡기더라도 그들이 따라야 할 방향과 기준을 정하는 데 연구자의 판단이 들어간다고 설명한다. 처리할 물량을 늘리는 일 앞에, 모델에 어떤 경험이 필요한지 결정하는 일이 있다. 영상 03:21–06:27
화자의 관점에서 연산량을 늘리는 방법은 여전히 유효하지만 비용이 크다. 같은 자원을 더 효율적으로 쓰려면 좋은 데이터와 평가가 필요하다. 또 측정하기 쉬운 능력부터 성과를 내고 나면, 남는 과제는 무엇을 잘한 것으로 볼지부터 정하기 어려워진다. 여기서 말하는 데이터 설계의 중요성은 이 대화의 주장이다. 데이터 작업자의 숙련도나 투자 수익에 관한 보편적인 측정 결과로 읽을 수는 없다.
대화 전체를 따라가면 서로 다른 세 일이 드러난다. 첫째는 학습시킬 능력과 평가의 방향을 정하는 일이다. 둘째는 그 능력을 시험할 상황을 실제로 실행할 수 있게 만드는 일이다. 셋째는 개별 문제의 맥락과 채점 기준을 세심하게 다듬는 일이다. 첫 단계에서 좋은 아이디어가 나왔다고 뒤의 두 단계까지 해결되지는 않는다. 이 구분은 이어지는 환경 구현과 사용자 의도 사례를 함께 읽기 위한 글의 정리다.
장애 기록을 갖고 있는 것과 다시 실행할 수 있는 것은 다르다
코드 저장소를 받아 수정하고 단위 테스트를 돌리는 과제는, 빌드 설정의 어려움을 제외하면 비교적 단순하게 구성할 수 있다. 그런데 수십 개 서비스가 연결된 회사의 문제라면 어떨까. 화자는 모델이 디버깅 중 사실을 지어내고 데이터를 망가뜨리는 상황을 예로 든다. 실제 고객 사고를 보고한 대목이 아니라, 복잡한 환경을 설명하기 위해 설정한 가상 사례다. 영상 06:27–08:15
이 사례를 학습 환경으로 만들려면 사고 설명만으로는 부족하다. 서비스와 그 상태를 가상 머신 안에 구성하고, 같은 조건에서 다시 실행할 수 있어야 한다. 모델에게 문제를 풀 수 있는 도구와 행동 범위를 주되, 환경을 편법으로 바꿔 답을 얻을 만큼의 권한을 주어서는 안 된다. 해결에 필요한 정보는 제공하되, 정답으로 가는 길을 지나치게 노출해서도 안 된다. 화자는 이런 설정을 반복해서 다듬는 데 구현상의 어려움이 있다고 말한다.
글의 기술적 해석: 재현할 환경을 설계한다면 초기 상태로 되돌리는 방법, 외부 서비스의 응답, 시간에 따라 바뀌는 값, 모델의 접근 권한을 각각 확인할 필요가 있다. 모델이 고쳐야 할 업무 데이터와 평가 자체를 결정하는 데이터가 뒤섞이면 높은 점수가 정상적인 해결을 뜻하지 않을 수 있다. 이는 대화에서 도출한 점검 관점이며, Mechanize의 내부 운영 절차가 공개됐다는 뜻은 아니다.
핵심은 현실의 복잡함을 무작정 많이 넣는 데 있지 않다. 앞 절의 기준을 적용하면, 실패를 일으킨 어려움은 보존하면서도 여러 번 실행하고 결과를 비교할 수 있어야 한다. 그래야 한 번의 우연한 성공과 반복 가능한 개선을 구분할 수 있다.
같은 내용을 따로 볼 수 있는 108초 Short도 이 절에 해당한다. 원본 1:36:14.68–1:38:02.68의 연속 구간이며, 뒤에서 다루는 사용자 의도와 채점 편향까지 포함한 영상은 아니다.
도구 응답을 다른 모델이 대신하면 어디까지 배울 수 있을까
복잡한 환경을 매번 구현하는 비용을 피할 방법도 거론된다. 화자는 연구소들이 실제 상호작용 기록의 중간까지 문맥을 채워 넣고, 다음 한 번 또는 몇 번의 행동을 학습시키는 방식을 쓸 것이라고 추정한다. 도구 실행 뒤에 나올 응답을 다른 모델이 만들어 주는 구상도 설명하며 이를 월드 모델이라고 부른다. 이 대목은 화자의 추정이다. 모든 연구소의 확인된 관행이나 특정 시스템의 공개된 구현으로 제시되지 않는다. 영상 08:16–10:41
예를 들어 데이터 마이그레이션 도중 잘못된 행동을 했고 사용자가 그 문제를 지적했다면, 그 기록을 바탕으로 같은 상황에서 다음 행동을 다르게 선택하게 할 수 있다는 설명이다. 대화에서는 사용자와 모델이 주고받은 기록을 모으는 것과, 별도의 월드 모델을 위한 데이터셋을 직접 구축하는 일을 구분한다. 후자가 이미 수행됐다고 말하는 구간은 아니다.
화자는 이런 방식으로 짧은 판단을 많이 학습시키면 도움이 될 수 있다고 본다. 다만 긴 작업을 이어 갈수록 만들어 낸 응답이 실제 실행 결과에서 벗어날 수 있다고 우려한다. 앞서 보여 준 상태와 맞지 않는 도구 응답이 돌아오면, 학습하는 모델은 모순된 상황 속에서 행동해야 한다. 그래서 이를 평가에 쓰는 데는 특히 회의적이다. 모든 학습형 시뮬레이터가 무용하다는 증명까지 제시한 것은 아니다.
글의 해석으로는 “이 문맥에서 다음 행동을 잘 골랐는가”와 “그 행동을 실제로 실행한 뒤에도 작업이 끝까지 성립하는가”를 구분해야 한다. 앞의 학습 신호가 유용하더라도 뒤의 검증을 자동으로 대신하지는 않는다. 환경 구현 비용을 줄였다는 사실만으로 실제 업무의 결과까지 재현했다고 볼 수 없는 이유다.
출제자가 아는 답을 모델도 알 수 있었을까
큰 방향과 실행 환경을 마련해도 개별 문제를 잘 쓰는 일은 남는다. 사용자 의도를 이해하는 능력을 평가한다고 하자. 겉으로는 모호한 요청이지만, 함께 주어진 맥락을 읽으면 원하는 결과를 알아낼 수 있는 문제가 필요하다. 반대로 출제자의 취향을 맞혀야만 정답이 되는 문제라면 무엇을 측정하는지 불분명해진다. 영상 10:41–12:38
화자는 문제를 만든 사람이 모델의 해석을 보고 “내가 원한 것은 이게 아니다”라고 반응할 수 있다고 말한다. 하지만 모델에게 그 뜻을 알아낼 정보가 없었을 수도 있다. 모호함을 의심할 단서가 없고, 추가로 확인할 방법도 없으며, 모델의 해석이 주어진 문장에서는 자연스럽다면 특정 해석만 정답으로 강제하는 데 문제가 생긴다. 같은 말을 다른 뜻으로 쓴 사용자에게는 오히려 나쁜 행동을 가르칠 수 있기 때문이다.
대화 후반에는 사람의 투명성 착각도 언급된다. 출제자는 자기 배경지식과 의도를 알고 있기 때문에, 다른 사람도 같은 뜻으로 읽을 것이라 여기기 쉽다. 평가를 만드는 사람은 모델에게 실제로 주어진 정보와, 그 정보에서 합리적으로 추론할 수 있는 범위를 따져야 한다. 영상 15:05–15:52
글의 기술적 해석: 채점 전에 모델이 받은 지시와 문서, 도구로 확인할 수 있는 정보를 함께 고정해 두면 숨은 정답을 요구하는지 검토하기 쉽다. 회사의 승인 규칙을 따라야 하는 과제라면 그 규칙에 접근할 수 있어야 한다. 출제자만 알고 있던 사정을 나중에 채점 기준으로 추가하면 의도 이해 능력과 미공개 정보 맞히기가 뒤섞인다.
묻는 것도 비용이고, 묻지 않는 것도 판단이다
항상 사용자에게 확인하면 모호함이 해결될까. 화자는 그 방법도 간단하지 않다고 설명한다. 같은 코드 변경이라도 바로 주 브랜치에 반영하기를 기대하는 사람과 확인을 먼저 원하는 사람이 있을 수 있다. 이 예시는 선호와 맥락에 따라 답이 달라진다는 설명이다. 별도 권한 없이 변경을 밀어 넣어도 된다는 권고는 아니다. 영상 12:38–15:05
사소한 세부 조건 하나가 올바른 행동을 바꾸기 때문에, “소프트웨어를 구현하라”는 문제를 여러 개 만드는 것만으로 충분하지 않다. 어떤 차이가 중요한지 판단해 사례에 담아야 한다. 모델이 불필요한 확인을 계속 요청하면 사용자의 일이 늘어난다. 반대로 확인이 필요한 파괴적인 행동까지 밀어붙이면 피해가 생길 수 있다. 화자는 이런 차이를 알아보는 감각을 데이터 제작자에게 가르치기 어렵다고 말한다.
또 모델이 모든 모호함을 먼저 알아차리는 것은 아니다. 자기 해석이 자연스럽다고 여길 수 있고, 해석의 차이가 실제 결과에 영향을 주지 않는다면 질문은 왕복 비용만 늘린다. 사용자가 나중에 불편을 느끼더라도, 그 원인이 앞선 어느 판단에 있었는지 정확히 짚어 주리라는 보장도 없다. 영상 17:46–20:56
대화의 빌드와 테스트 예시는 이 구분을 보여 준다. 프로젝트에 설정이 여러 개 있더라도 코드를 먼저 살펴보면 답을 찾을 수 있다. 조사하지 않고 바로 물으면 사용자가 대신 확인해야 한다. 충분히 살핀 뒤에도 결과를 바꿀 중요한 선택이 남는다면 질문할 이유가 생긴다. 대화가 요구하는 능력은 정해진 횟수만큼 묻는 습관보다, 무엇을 모르며 그 차이가 왜 중요한지 알아보는 판단에 가깝다.
글의 해석으로는 평가에 두 종류의 사례가 함께 필요하다. 주어진 정보와 도구로 스스로 해결할 수 있는 경우, 그리고 추가 정보나 승인이 실제로 필요한 경우다. 확인 질문의 개수만으로 점수를 매기면 이 차이를 놓친다. 질문이 작업 결과와 권한 경계에 어떤 영향을 주었는지를 함께 살펴야 한다.
판단을 잘못 가르쳤다는 사실은 늦게 돌아온다
평가 제작자의 판단을 어떻게 훈련할지도 문제다. 화자는 전문가가 초안을 검토하는 방법을 말하면서, 잘못된 판단에 대한 피드백을 받기까지 오래 걸릴 수 있다고 설명한다. 보상 해킹은 모델에게 채점기를 공략하게 해 보고 원하지 않는 행동으로 점수를 얻는지 확인할 수 있다. 이에 비해 사용자 의도를 잘못 가르친 문제는 결함이 바로 드러나지 않을 수 있다. 영상 15:52–17:46
평가에 맞춰 모델을 개선하고, 제품에 배포하고, 사용자가 불편을 겪은 뒤, 그 제보가 연구자와 데이터 제작자에게 돌아오는 과정을 거쳐야 한다. 사용자의 설명이 막연하거나 원인 판단이 틀리면 피드백은 더 흐려진다. 화자는 코드가 테스트를 통과했는지, 제한 시간 안에 끝났는지 빨리 확인할 수 있는 경진 프로그래밍과 비교한다. 무엇을 고쳐야 하는지 알 수 있는 주기가 다르다는 것이다.
글의 해석으로는 사용자 불만을 곧바로 하나의 오답 표식으로 바꾸기보다, 당시 입력과 모델 행동, 검토자가 판단한 이유를 함께 남겨야 한다. 원인이 정보 부족인지, 허용된 행동을 잘못 이해한 것인지, 채점 기준의 문제인지 구분해야 다음 버전을 고칠 수 있다. 이 기록 방식은 대화에서 도출한 제안이며, 특정 연구소가 이미 운영 중인 절차라는 주장은 아니다.
채점의 흔들림과 채점의 방향은 다른 문제다
개별 문제에 잡음이 조금 있어도 많은 문제를 풀리면 어느 정도 상쇄될 수 있다고 화자는 말한다. 하지만 평가 제작자의 선호가 실제 사용자와 계속 다른 방향을 향한다면 양을 늘리는 것으로 해결하기 어렵다. 제작자가 나름의 좋은 판단력을 갖고 있어도, 대상 사용자가 원하는 판단과 다를 수 있다. 영상 20:56–21:35
기술적으로는 이 차이가 중요하다. 우연한 오차가 상쇄된다는 설명은 오차가 한쪽으로 치우치지 않고 충분히 분산되는 범위에서 이해해야 한다. 같은 편향을 가진 문제를 더 많이 모으면 그 방향이 사라지지 않는다. 예를 들어 맥락과 무관하게 확인 질문을 높이 평가하는 문제만 반복하면, 적절히 스스로 처리하는 능력을 보상하기 어렵다. 이 예시는 앞선 대화를 연결한 글의 해석이다.
따라서 평가자 사이의 의견 차이가 보일 때 단순한 실수인지, 서로 다른 사용자와 상황을 떠올린 것인지 살펴볼 필요가 있다. 다수의 선호를 하나의 보편적인 정답으로 만들기보다 어떤 사용자와 어떤 맥락을 위한 점수인지 분명히 해야 한다. 데이터가 늘어난 것과 목표가 잘 맞는 것은 별도로 확인할 문제다.
사용자와 뜻이 맞는 채점기도 속일 수 있다
더 까다로운 경우도 있다. 평가 제작자와 사용자가 원하는 결과가 같아도, 채점기가 원하지 않은 해결 경로에 높은 점수를 줄 수 있다. 화자는 모델이 취할 수 있는 행동을 충분히 예상하기 어렵다는 점을 지적한다. 결과를 단순한 규칙으로 판정하기 힘든 문제에서는 다른 에이전트에게 채점을 맡길 수 있지만, 그 에이전트에게 줄 평가 지시도 예상하지 못한 행동까지 완벽히 규정하기는 어렵다. 영상 21:35–23:38
이 채점기에 맞춰 다음 세대 모델을 최적화하면, 점수는 높으면서 사용자에게 나쁜 행동이 나타날 수 있다. 대화는 이를 설명하며 SWE-bench에서도 비슷한 우회가 가능했을지 모른다는 식으로 비교한다. 이 구간은 SWE-bench에서 특정한 역사적 꼼수가 실제 발생했다고 입증하지 않는다. 가정적인 비교를 확인된 사건으로 바꿔 읽어서는 안 된다.
화자는 평가자의 취향이 사용자와 어긋나는 문제보다, 채점기 눈에는 좋아 보이지만 사용자에게는 나쁜 결과를 내는 문제가 더 흔하고 위험할 수 있다고 본다. 이는 그의 판단이며 발생 빈도를 측정한 통계는 제시되지 않는다. 영상은 좋지 않은 채점기에 과도하게 맞추면 예상하지 못한 나쁜 결과를 낳을 수 있다는 Goodharting 논점에서 끝난다.
글의 기술적 해석: 평가를 검토할 때는 정답을 낼 수 있는지만 확인할 일이 아니다. 높은 점수를 얻으면서도 원래의 목적을 어기는 방법을 찾아볼 필요가 있다. 최종 결과가 맞았는지와 금지된 행동을 했는지를 구분하고, 문제를 만들 때 사용하지 않은 사례나 더 강한 모델에서도 채점이 유지되는지 시험하는 접근이 가능하다. 앞서 GBA 사례에서 부팅 성공만으로 긴 플레이를 검증할 수 없었던 것처럼, 여기서도 제한된 관찰로 전체 성공을 대신 판정하는 위험이 남는다.
색소폰 실패 기록을 읽는 것과 색소폰을 배우는 것은 다르다
영상은 지속 학습의 한계를 색소폰 비유로 전환한다. 첫 사람이 처음 악기를 불고 실패 원인을 메모한다. 다음 사람은 그 메모를 읽지만 여전히 처음으로 색소폰을 분다. 다시 실패하고 더 긴 메모를 남긴다. 기록은 늘어나지만 연주자의 몸에는 연습이 축적되지 않는다. 화자는 현재 agent의 메모리 파일과 긴 context가 이 방식에 가깝다고 설명한다. 13:11–14:44
공개 쇼츠는 바로 이 13:11.457–14:44.130 구간을 사용한다. 쇼츠가 말하는 ‘메모만 넘겨주면 학습이 될까’라는 질문은 장기 영상 전체의 결론이 아니라, 지속 학습 논의의 출발점이다. 뒤에서는 메모리를 무엇으로 만들고 언제 검색할지, 그 관리를 누가 맡을지가 이어진다.
지속 학습 eval에 대한 화자의 제안은 저장 형식을 미리 정하지 않는 것이다. 한 모델이 공유된 맥락에서 오래 일하면서 미래의 비슷한 과제를 실제로 더 잘 수행하는지 본다. 메모리 파일을 몇 개 만들었는지보다 시간이 지난 뒤의 성능 변화를 측정하자는 뜻이다. 14:44–16:49
이 구분은 제품의 ‘memory’ 기능을 평가할 때도 중요하다. 과거 대화를 다시 찾았다는 사실만으로는 학습을 입증하지 못한다. 같은 실수를 덜 하고, 필요한 질문을 더 적절히 하며, 바뀐 규칙을 낡은 기억보다 우선하는지까지 확인해야 학습 효과를 말할 수 있다.
메모리 파일은 기억을 저장하지만, 갱신 비용을 사용자에게 돌릴 수 있다
현재 코딩 하네스의 흔한 해결책은 모델이 실수했을 때 별도 파일을 만들고, 주 메모리 문서에 ‘이런 요청이면 이 파일을 읽어라’라는 규칙을 추가하는 것이다. 영상은 이 방법이 시스템 프롬프트에 지시를 계속 덧붙이는 방식과 닮았다고 본다. 사전학습과 RL로 형성된 prior를 크게 바꾸기보다, 매 요청에서 읽어야 할 규칙을 늘린다. 16:49–20:34
사람은 회사에서 몇 달 일한 뒤 내부 도구와 관례를 익힌다. 매번 모든 문서를 처음부터 읽지 않는다. agent는 새 세션마다 저장소와 과거 노트를 다시 탐색하고, 기록되지 않은 실수를 반복할 수 있다. 이를 줄이려고 전사 문서, 부서 문서, 도구별 문서로 이어지는 skill directory를 만들면 새로운 운영 문제가 생긴다. 소프트웨어와 조직이 바뀔 때 누군가 문서 트리를 계속 고쳐야 한다. 20:34–24:18
화자는 하루의 상호작용을 마친 모델이 학습을 통합해 이 구조를 스스로 갱신하는 ‘dreaming’ 또는 batch update에 가까운 방향을 원한다. 동시에 초기 시도는 잘 작동하지 않을 수 있다고 말한다. 이것은 특정 제품의 완료된 기능이 아니라 화자의 전망이다. 자동 요약이 생겼다는 사실만으로 정확한 갱신, 모순 해소, 오래된 기억 삭제가 해결됐다고 보기는 어렵다.
기억을 많이 만들수록 필요한 순간에 찾는 문제가 커진다
지속 학습에는 두 문제가 있다. 경험에서 무엇을 기억으로 만들지 결정해야 하고, 새 과제에서 어떤 기억을 불러올지 결정해야 한다. 화자는 디스크에 기록해 둔 뒤 키워드로 찾는 방식이 전체 맥락을 보지 못한 채 근시안적으로 움직일 수 있다고 주장한다. 24:18–27:19
이 구조에서는 사용자가 context manager가 된다. 모델이 알아야 할 배경을 짧은 프롬프트로 압축하고, 관련 문서를 골라 주며, 바뀐 사실을 지워야 한다. 화자들은 모든 맥락을 전달해야 하는 프리랜서와 이미 회사 사정을 아는 정규직의 차이로 이 비용을 설명한다. 24:18–27:19
검색 성능만 높여도 문제가 끝나지는 않는다. 오래된 규칙과 새 규칙이 충돌할 때 무엇을 우선할지, 개인 정보나 권한이 사라졌을 때 기억도 폐기할지, 모델 업데이트 뒤 기억 형식이 여전히 유효한지 검증해야 한다. 이는 영상에서 도출한 추가 설계 조건이다. 영상의 결론도 지속 학습이 ‘여러 중요한 한계 중 하나’라고 한정한다. 27:19–27:27
좋은 평가의 출발점과 지속 학습의 종착점은 같은 질문으로 만난다. 모델이 실제 환경에서 원하는 일을 했는가. prompt만 읽어서는 답할 수 없다. environment의 상태 변화, grader가 놓친 경로, 시간에 따라 축적되거나 사라진 기억을 함께 봐야 한다.
이 가운데 95.6초 Short는 화자가 자신의 일 중 상당 부분이 LLM의 맥락을 관리하는 일이라고 말한 구간이다. 과거 지시와 회사 업무에 익숙한 직원에게는 모호하게 말해도 통할 수 있지만, LLM에는 우선순위와 배경을 매번 정확히 압축해 전달해야 한다는 부담을 설명한다. 메모리 문서에 적어 두어도 필요한 순간 검색되지 않을 수 있다는 지적까지 포함한다. 이는 화자의 경험과 기대이며 필자의 경험이나 모든 LLM에 대한 성능 판정은 아니다.
