답안을 모방하는 데이터에서 일할 수 있는 환경으로 이동한다
Foody는 먼저 자신이 본 데이터 시장의 변화를 설명한다. 2020년 무렵에는 입력과 모범 출력을 모으는 SFT 데이터, 여러 응답 중 선호하는 것을 고르는 RLHF 데이터가 중심이었다. 그는 이를 행동을 모방하도록 가르치는 데이터의 시기라고 부른다. 2024년으로 넘어가며 최고 수준의 전문가가 협업해 평가와 RL 환경을 만드는 방향으로 수요가 옮겨 갔다고 주장한다. 00:53–01:59
이 구분은 SFT나 RLHF가 사라졌다는 뜻이 아니다. 답변 한 개를 보여 주거나 두 답을 비교하는 일에서, 모델이 여러 단계의 일을 수행할 장소와 채점 기준을 만드는 일로 공급 범위가 넓어졌다는 설명이다. 법률가, 개발자, 의사, 금융 전문가가 필요한 이유도 모델이 이미 잘하는 응답을 고르는 것만으로는 능력의 한계를 측정하기 어렵기 때문이다.
Mercor는 deep research를 첫 큰 프로젝트로 소개하고, 이후 검증 가능한 보상으로 학습하는 RLVR이 풍부한 앱과 업무 세계를 포함하는 환경으로 확장됐다고 설명한다. 이러한 변화가 프런티어 연구소에서 실제 응용 제품으로 퍼지고 있다는 것이 발표의 출발점이다. 주요 연구소의 공급자가 됐다는 규모와 지위는 Mercor의 회사 자기보고로 읽어야 한다. 01:59–02:54
environment는 데이터 묶음이 아니라 world, app, task의 결합이다
Foody가 말하는 RL environment에는 세 층이 있다. 첫째, 메시지, 슬라이드, 문서, 스프레드시트처럼 일을 둘러싼 상태를 담은 world다. 둘째, Salesforce, ServiceNow, Microsoft 365 같은 실제 업무 도구를 충실하게 복제한 app이다. agent는 MCP, CLI, computer use를 통해 이 app에 행동한다. 셋째, 무엇을 해야 하는지 적은 prompt와 결과를 판단하는 verifier로 이뤄진 task다. 세 요소를 정의하는 구간은 정적인 질문과 답변 쌍만으로는 업무 환경이 완성되지 않는 이유를 보여 준다.
world가 초기 상태를 제공하고, app이 가능한 행동과 상태 전이를 만들며, task와 verifier가 종료와 보상을 정한다. 여기에 reset과 replay 규칙까지 있어야 같은 과제를 여러 정책에 반복할 수 있다. 따라서 업무 문서가 많다는 사실만으로 environment라 부를 수 없다. agent가 무엇을 보고, 어떻게 행동하며, 어떤 상태 변화 뒤에 성공으로 판정되는지가 명시돼야 한다.
모델 능력의 바깥을 재려면 전문가가 rubric을 써야 한다
발표에서 가장 큰 병목은 도메인 범위다. GDPval만 해도 205개 도메인을 다루고, 각 직업에는 서로 다른 앱과 시나리오, 과제가 필요하다. Mercor는 발표 당시 2분기에 전문가 250만 시간이 environment 구축에 투입됐다고 주장한다. 이 수치와 205개 도메인 설명은 회사의 규모 주장이며, 영상 밖의 독립 자료로 검증된 값은 아니다.
수학처럼 답을 자동 확인할 수 있는 simulation은 예외에 가깝다. 법률 메모나 슬라이드 덱에서는 개선 대상 모델에게 자기 결과를 채점하게 하면 같은 빈틈을 반복할 수 있다. 교수는 에세이를 채점할 rubric을 만들고 조교는 그 기준을 적용하듯, 사람이 모델 능력의 최전선을 정의해야 한다는 것이 Foody의 주장이다.
전문가의 역할은 정답 문장을 직접 쓰는 데 그치지 않는다. 현실적인 의뢰가 무엇인지, 어떤 파일과 메시지가 선행 상태여야 하는지, 답변의 어떤 특징이 성공인지, 부분 점수는 어떻게 나눌지를 결정한다. 이 판단을 빼면 모델이 이미 잘하는 과제만 대량 생산하거나, 실제 고객 가치와 무관한 proxy를 최적화하기 쉽다.
법률 과제 하나에도 data room, 앱 복제, prompt, verifier가 함께 들어간다
Foody는 대형 로펌 변호사가 실제 프로젝트를 바탕으로 시나리오를 만들고, 이메일, 메시지, 파일이 들어 있는 방대한 data room을 구성하는 예를 든다. 모델은 자료 채우기와 생산성 향상에 쓰이지만, 전문가는 시나리오의 현실성을 이끈다. 그 자료를 Google Workspace 복제 앱에 넣고, agent가 Oil Pollution Act 아래 두 회사의 최대 책임을 평가하도록 task를 만든다. 법률 environment의 조립 과정이다.
마지막 단계가 verifier다. 정확한 답변이 갖춰야 할 기준을 rubric으로 쓰되, 표현만 흉내 내고 실제 법률 분석은 하지 않는 답에 점수를 주지 않아야 한다. 발표자는 100개의 trajectory를 돌렸을 때 모든 점수가 정확하도록 만드는 일이 어렵다고 말한다. 여기서 품질은 그럴듯한 샘플 한 개가 아니라 다양한 행동 경로에서도 점수의 순서가 전문가 판단과 맞는지에 달렸다.
이 사례를 일반화할 때에는 권리도 별도로 봐야 한다. 현실의 data room을 닮았다는 것과 실제 고객 자료를 쓸 권리가 있다는 것은 다르다. 접근, 평가, 훈련, 파생물, 보존, 삭제 범위를 각각 확인하고, 공개 영상의 사례만으로 실제 원문 자료의 권리 상태를 추정해서는 안 된다.
데이터 품질은 realism과 verifier 정확도로 나눠 검사한다
질의응답에서 Foody는 품질을 두 축으로 나눈다. 첫째는 environment, app, task가 목표 업무 분포를 얼마나 현실적으로 반영하는지다. 전문가가 개요와 taxonomy를 잡고, 생성 모델은 자료를 채우는 속도를 높인다. 둘째는 verifier가 실제 수행을 올바르게 순위화하는지다.
검사 방법도 trajectory 단위다. 개선하려는 모델로 여러 경로를 실행하고 rubric으로 채점한 뒤, agent 기반 품질 관리와 사람 검토를 조합해 점수를 맞춘다. 100개 trajectory의 순위가 사람 판단과 같아야 한다는 설명은 정답 하나를 대조하는 전통적 라벨링과 다르다. agent가 우연히 정답 문자열에 도달했는지, 중간 행동에서 금지된 우회로를 썼는지까지 봐야 하기 때문이다.
현실성과 채점 정확성은 서로 대체하지 않는다. 현실적인 사무실을 복제해도 verifier가 허술하면 reward hacking이 생긴다. 채점이 정교해도 엉뚱한 과제를 풀면 제품 성능을 예측하지 못한다. 이 글의 기술적 해석을 덧붙이면, 재실행 평가의 순위가 앞으로 실제 업무에서 얻을 결과와 맞는지 확인해야 한다. 그렇기 전에는 현실 성능을 예측하는 시뮬레이터라고 단정하기 어렵다.
과제 가격은 제작 시간보다 고객 목표의 가치에서 역산한다
Mercor의 가격 설명은 일반 라벨링 단가와 다르다. 고객이 특정 leaderboard에서 얻고 싶은 성능과 그 가치에서 출발해, 목표에 필요한 task 수와 task당 가격을 역산한다. 발표자가 제시한 범위는 과제당 50달러에서 1만 달러다. 일부 frontier lab이 월 5만 과제를 구매하고, 복잡한 과제는 사람이 한 달까지 작업한다고도 말한다. 모두 발표자의 고객 및 가격 자기보고다.
Apex Agents 사례에서는 1,800개 과제와 약 50만 규모의 compute로 GLM-4.7의 기업 법률 점수가 4.7%에서 26.6%로 올랐다고 주장한다. 다른 benchmark에도 일반화됐다는 설명이 붙지만, compute의 정확한 단위, baseline 조건, 반복 수, 데이터 오염 검사는 영상에서 충분히 공개되지 않는다. 수치가 제시되는 구간은 가능성의 사례이지, 1,800개 과제가 어느 모델에나 같은 향상을 낸다는 법칙이 아니다.
경제성을 판단하려면 task 가격만 볼 수 없다. app과 world 유지, 모델 업데이트에 따른 verifier 회귀, 전문가 재검토, 권리 관리, 실패한 rollout 비용까지 포함해야 한다. 고객 가치에서 역산한 가격은 판매 논리를 설명하지만, 구매자의 실제 ROI는 배포 후 업무 지표로 다시 검증해야 한다.
제공 방식도 세 가지다. 고객 목적에 맞춘 과제를 건별로 제작해 판매하는 방식, 한 번 만든 기성 데이터셋을 여러 고객에게 제공하는 방식, 전문가의 시간을 제공하고 고객이 작업을 직접 조직하는 방식이다. Foody는 첫 번째가 가장 흔하고, 새 연구소들은 같은 데이터셋을 각각 만들기보다 두 번째를 쓰는 경향이 있으며, 세 번째는 자사에서 예전보다 비중이 작아졌다고 설명한다. 10:37–12:00
이 차이는 구매자가 무엇을 받는지 결정한다. 맞춤 과제를 사는 것과 공용 데이터셋을 쓰는 것, 전문가와 직접 제작하는 것은 범위와 유지 책임이 다르다. 발표는 세 가지 사업 형태를 설명할 뿐, 모든 건별 과제가 독점 제공되거나 기성 데이터의 모든 재사용 권리가 구매자에게 이전된다고 말하지 않는다.
합성 데이터는 사람을 없애기보다 사람이 정한 환경 안에서 rollout을 늘린다
Foody는 RLVR 자체를 합성 데이터에 대한 베팅으로 설명한다. 사람이 SFT 답안을 모두 쓰는 대신 모델 trajectory를 대량 생성하고 verifier로 채점해 학습하는 방식이다. 생성 모델은 data room을 채우고 task 초안을 만드는 데도 쓰인다. 하지만 모델 능력의 경계를 넘어선 것을 측정하려면 사람이 필요하다는 조건이 붙는다.
병목은 특히 task 생성에 남는다. 개선 대상 모델에게 자신이 틀리는 지점의 rubric을 쓰게 하면 절반은 맞고 절반은 틀리는 잡음이 생길 수 있다. 전문가는 trajectory를 함께 보며 실패를 규정하고, copilot은 그 작업 속도를 높인다. 코드나 사이버처럼 실행 가능한 검증기, 공격 agent와 방어 agent를 둘 수 있는 분야는 사람 verifier 비중을 더 줄일 수 있다. 사이버의 예외는 자동화 가능성이 도메인의 검증 구조에 달렸음을 보여 준다.
따라서 합성과 사람의 비율을 일률적으로 정할 수 없다. 상태 전이와 성공 조건을 자동 검증할 수 있을수록 합성 rollout을 넓힐 수 있다. 반대로 가치 판단, 사실관계, 장기 결과가 얽힐수록 전문가가 과제 분포와 rubric을 책임져야 한다.
pass@1은 실패하고 pass@16은 가끔 성공하는 과제가 학습 경계다
모든 어려운 과제가 좋은 훈련 데이터는 아니다. Foody가 제시한 heuristic은 pass@1과 pass@16의 차이다. 16번 실행해도 전부 틀리면 현재 base model이 그 데이터에서 배울 가능성이 낮다. 반대로 한 번에는 실패하지만 16번 중 한두 번은 성공하면, 성공 trajectory에서 개선할 여지가 있다. 이 설명은 난이도를 정답률 하나로 보지 않고 탐색 과정에서 유효한 행동이 나타나는지 보게 한다.
이 기준은 절대 법칙이 아니다. 더 많은 rollout에서 우연히 성공할 수도 있고, verifier가 잘못된 성공을 인정할 수도 있다. task별 pass@k, 성공 경로의 다양성, reward 안정성, 훈련 뒤 held-out 환경의 향상을 함께 확인해야 한다.
발표가 꼽는 다음 frontier는 10시간을 넘는 ultra long-horizon 업무와 다른 사람 또는 agent와 협업하는 과제다. 사람은 직장에서 60~70%의 일을 상호작용과 함께 한다고 답하지만, 이를 재는 eval은 약 1%라는 발표자의 추정이 나온다. 100시간과 1,000시간 과제, 사회적 상호작용의 격차는 미래 방향을 제시하지만 아직 해결됐다는 증거는 아니다. 장기 과제는 상태 보존, 중간 실패 복구, 비용 제한, 사람 개입 규칙까지 설계해야 한다.
긴 업무는 최종 답보다 중간 상태와 복구 능력을 평가해야 한다
다음은 발표의 방향을 실제 시스템에 적용하기 위해 이 글에서 덧붙인 기술적 해석이다.
10시간, 100시간, 1,000시간짜리 과제로 갈수록 마지막 산출물 하나만 채점해서는 원인을 알기 어렵다. 중간 checkpoint마다 어떤 근거를 읽었고, 어떤 도구로 상태를 바꿨으며, 오류를 발견한 뒤 어디까지 되돌렸는지를 기록해야 한다. 사람이나 다른 agent에게 도움을 요청하는 행동도 명시적인 행동 항목으로 포함돼야 한다.
사회적 상호작용을 평가할 때는 말투의 자연스러움만 볼 수 없다. 필요한 정보를 올바른 주체에게 요청했는지, 권한이 없는 자료를 넘기지 않았는지, 합의가 필요한 결정을 임의로 실행하지 않았는지, 상대의 답을 이후 계획에 정확히 반영했는지를 채점해야 한다. 여러 agent가 얽히면 각자의 기억과 권한 경계를 분리해야 한다.
장기 eval은 비용 제한과 종료 규칙도 필요하다. 무한 재시도로 정답에 도달한 정책은 실제 업무에서 쓸 수 없다. wall-clock time, model call, tool 비용, 사람 개입 횟수를 함께 보고, 중간 상태에서 reset하거나 재개할 수 있어야 한다. 발표가 제시한 미래 방향을 실제 environment로 만들려면 이런 운영 의미가 추가돼야 한다.
구축 순서는 업무 경계, 권리, 상태, 행동, 채점, 학습 가능성이다
다음은 발표의 방향을 실제 시스템에 적용하기 위해 이 글에서 덧붙인 기술적 해석이다.
이 발표를 실행 절차로 바꾸면 먼저 하나의 업무 결과를 고르고 모델에게 보여 줄 정보를 제한한다. 그 업무에 필요한 자료의 접근, 평가, 훈련, 파생, 보존과 삭제 권리를 확인한다. 다음으로 world의 초기 상태와 app에서 허용할 명시적인 행동 항목을 정의한다. task의 종료 조건과 전문가 rubric을 만들고, 여러 trajectory를 실행해 사람의 순위와 verifier의 순위가 맞는지 확인한다.
그 뒤 pass@1과 pass@k로 현재 모델이 가끔이라도 유효한 경로를 찾는지 본다. 학습 후에는 같은 world를 외운 결과가 아닌지 held-out 시나리오와 다른 app 상태에서 검사한다. 배포에서는 업무 시간, 오류율, 사람 수정량처럼 실제 지표가 움직이는지 본다. 이 증거가 이어질 때만 synthetic trajectory의 양을 늘린다.
Mercor의 발표는 전문가 네트워크와 인프라를 결합한 회사 전략도 소개한다. 전담 팀이 고객에게 독점 데이터셋을 만든다는 마지막 주장 역시 구체적인 계약과 사용 권한까지 공개한 것은 아니다. 공개 발표가 보여 주는 것은 environment를 조립하는 메커니즘과 회사가 주장하는 규모다. 특정 고객 데이터의 독점성, 권리 범위, benchmark 재현성은 별도 증거가 필요하다.