Mechanize, 다음 태스크에 남는 연구

Mechanize는 태스크 하나를 구상해 제출하기까지 보통 약 일주일이 걸린다고 설명합니다. 그 시간을 들여 다음 태스크에도 쓸 수 있는 것이 얼마나 남는지 궁금합니다. 회사가 공개한 근무 방식을 보면 그 시간을 어디에 쓰는지 알 수 있습니다.

가장 많은 시간이 드는 단계는 QA입니다. 채점기를 고치고 실행 기록을 읽으며, AI가 일을 못해서 실패했는지 문제를 잘못 내서 실패했는지 구분합니다.

태스크를 만들어 팔면 판매가로 인건비와 실행 비용을 회수해야 합니다. 약 일주일이라는 소요 기간만으로 실제 투입한 노동시간이나 총원가를 알 수는 없습니다. 여기에 제작하면서 배운 것이 다음 태스크의 검수에도 쓰인다면 계산할 것이 하나 더 생깁니다. 이번에 납품한 결과물과, 다음 결과물을 만드는 능력을 함께 봐야 합니다.

Mechanize를 통해 보고 싶은 것은 이 두 번째 가치입니다. 작은 팀이 한 분야의 환경을 계속 만들고 고치는 일이 어떻게 연구가 되고, 그 연구가 어떤 조건에서 사업의 자산으로 남는가.

1. 일주일 동안 고치는 것은 문제만이 아니다

Mechanize에서는 한 엔지니어가 태스크 하나의 구상부터 제출까지 맡고, 여러 태스크를 환경으로 묶습니다. 약 일주일은 태스크 하나의 전형적인 제작 기간입니다. 이 근무 설명만으로 고객 검수와 재작업까지 마친 최종 납품 기간은 알 수 없습니다.

태스크에는 AI에게 시킬 일, 작업할 공간, 결과에 점수를 주는 채점기가 들어갑니다. 그 점수를 능력 평가에 쓰면 eval이고, 모델을 학습시키는 신호로 쓰면 RL 과정의 일부가 됩니다. 같은 형태의 과제라도 어떻게 쓰였는지에 따라 증명하는 것이 달라집니다. Mechanize 팟캐스트, Stephen Yang, 00:18

엔지니어는 모델이 실제로 어려워하는 일을 찾고, 여러 실행 기록을 읽으며 채점 기준을 고칩니다. 출제자가 알려주지 않은 조건을 채점기에 몰래 넣었다면 모델의 0점은 능력 부족의 증거가 아닙니다. 반대로 핵심 작업을 하지 않아도 점수가 나온다면 학습은 엉뚱한 방향으로 진행될 수 있습니다.

이때 사람에게 필요한 전문성은 ‘정답을 알고 있다’보다 넓습니다. 무엇을 실패라고 불러야 하는지, 모델에게 어떤 정보가 주어졌는지, 채점기의 허점을 이용한 성공은 없는지까지 판단해야 합니다. Mechanize가 공개한 제작 과정은 이 판단을 한 사람이 끝까지 책임지도록 설계돼 있습니다. 근무 방식의 QA와 실패 분석

2. 잘 돌아가도 거의 0점이 되는 채점법

GBA Eval은 코딩 에이전트에게 24시간을 주고 Game Boy Advance 에뮬레이터를 만들게 하는 과제입니다. 모델이 만든 에뮬레이터와 기준 에뮬레이터에 같은 버튼 입력을 넣어 게임이 어떻게 동작하는지 비교합니다. GBA Eval 소개, 2026년 5월 2일, 24시간 과제에 대한 공식 발표

처음 생각한 채점법은 엄격했습니다. 화면의 픽셀이 처음 달라지는 순간까지 얼마나 오래 버텼는지 세는 방식입니다. 그런데 실제로 게임을 하는 데 별문제가 없어도 작은 렌더링 차이가 일찍 나오면 점수가 거의 0이 됩니다. 배경의 눈송이가 조금 다르다는 이유로, 잘 돌아가는 프로그램과 고장 난 프로그램이 비슷한 점수를 받는 셈입니다.

픽셀이 얼마나 많이 일치하는지 세는 방법도 문제가 있었습니다. 글에서 든 예시는 흰 화면 위에 검은 점이 있는 게임입니다. 점을 전혀 구현하지 않고 흰 화면만 출력해도 대부분의 픽셀이 맞습니다. 간단한 숫자로 바꿨더니 게임의 핵심을 놓칩니다.

이들은 여러 기준을 거쳐 화면의 구조적 유사성을 비교하는 SSIM을 사용합니다. 각 화면의 점수를 모아, 잠깐의 사소한 차이와 계속 어긋나는 동작을 구분하려고 했습니다. 사람이 두 결과를 비교한 판단으로 채점 설정을 조정하고, 검증용으로 따로 생성한 에뮬레이터의 결과도 보며 최종 설정을 골랐습니다. 다만 평정자는 한 명이었고, 아주 작은 결함을 충분히 벌하지 못하는 한계는 남았습니다. 채점 기준을 바꾼 과정, 최종 replay 채점 방식

이 과정에서 생긴 것은 에뮬레이터 문제 하나와 채점 코드만이 아닙니다. 어떤 기준이 잘못된 결과를 높게 평가하는지, 작은 차이를 얼마나 허용해야 하는지에 관한 지식도 생겼습니다. 다른 시각적 작업에 그대로 적용할 수 있는지는 다시 시험해야 하지만, 다음 채점기를 만들 때 검토할 실패 사례는 남습니다.

GBA Eval은 공개 평가와 시연을 위한 단일 과제입니다. 제작자는 이 공개 사례에서 RL의 반복 최적화 압력까지 견디는지를 다루지 않았다고 명시합니다. 채점기를 잘 고쳤다는 사례와, 그 채점기로 학습한 모델이 실제 업무를 더 잘하게 됐다는 증거는 다릅니다.

3. 비싼 학습에 싼 문제가 들어갈 때

창업자들은 2025년 8월 글에서 고품질 태스크에 돈을 쓸 이유를 compute 비용으로 설명했습니다. 모델을 학습시키는 비용이 커지면, 잘못된 신호 때문에 그 학습을 낭비하는 비용도 커진다는 주장입니다. Cheap RL tasks will waste compute

그 글은 태스크를 한 번 시도한 전체 실행 기록에 출력 50만 토큰이 쌓인다고 가정합니다. 당시 Grok 4의 API 가격인 100만 토큰당 15달러와 그룹 크기 64를 적용하면, 한 차례 RL 실행의 태스크당 compute 지출은 480달러입니다. 여기에 다섯 번의 재사용을 가정해 누적 2,400달러를 계산합니다. 50만 토큰은 미래 실행 기록 길이의 외삽이고, API 가격은 compute 기회비용의 대용입니다. 내부 훈련원가나 Mechanize의 제작 원가, 고객에게 받은 태스크 가격이 아닙니다. ‘1년 안에 연구소들이 태스크 하나에 수천 달러를 지불할 것’이라는 문장도 당시의 예측입니다.

이 논증은 좋은 태스크를 살 이유를 설명합니다. 하지만 얼마나 비싸게 살지까지 정해주지는 않습니다. 제작에 한 주를 더 썼을 때 모델이 얼마나 더 배우는지, 같은 개선을 다른 방법으로 더 싸게 얻을 수는 없는지를 알아야 가격을 논할 수 있습니다.

환경을 공급하는 회사는 이 결과를 바로 보기도 어렵습니다. Ege Erdil은 2026년 6월 공식 팟캐스트에서 모델을 학습하고 배포한 뒤 사용자의 불만이 태스크 제작자에게 돌아오는 과정이 길고 추적하기 어렵다고 설명합니다. 사용자는 모델이 별로라고 느낄 수 있지만, 어느 훈련 과제의 무엇이 잘못됐는지까지 알려주지는 않습니다. Ege Erdil, 1:45:39

앞서 본 GBA의 채점 개선은 제작자가 자기 과제를 고친 사례입니다. 이 공개 평가 사례만으로는 고객의 모델 훈련에서 얻은 성능 향상이나 비용 절감까지 확인할 수 없습니다.

4. 고객의 재사용과 회사의 반복 매출은 다르다

태스크를 한 번 만들어 여러 학습에 쓰면 가치가 커질 수 있습니다. 여기에는 서로 다른 세 가지 이야기가 섞이기 쉽습니다.

첫째, 고객이 같은 태스크를 여러 번 사용하는 것입니다. 고객은 매번 새 과제를 만드는 비용을 아낄 수 있습니다. 하지만 이미 익힌 과제를 계속 풀면 추가로 배울 것이 줄어들 수 있습니다. Ege도 같은 팟캐스트에서 과도한 재사용이 다양성과 일반화의 부족으로 이어질 수 있다고 말합니다. Ege Erdil, 02:05

둘째, 공급자가 같은 결과물을 여러 고객에게 판매하는 것입니다. 이는 계약과 권리에 달려 있습니다. 고객이 다섯 번 학습한다고 공급자가 다섯 번 돈을 받는 것은 아닙니다. 독점 납품인지, 재판매가 가능한지, 모델과 도구가 바뀔 때 누가 유지 비용을 부담하는지 알아야 공급자의 경제성을 계산할 수 있습니다. Mechanize의 공개 자료만으로 이 조건을 채울 수는 없습니다.

셋째, 팀이 제작 방법을 재사용하는 것입니다. 실행 환경을 준비하는 도구, 실패 기록을 읽는 방법, 잘못된 채점을 찾아내는 검수 절차를 다음 과제에 쓰는 경우입니다. 회사는 컨테이너 빌드와 QA 자동화를 공통 인프라 작업으로 소개합니다. 공유 인프라 설명

저는 작은 전담팀의 가능성을 이 세 번째에서 봅니다. 개별 결과물의 사용권을 고객에게 넘기더라도 다음 과제를 만드는 기술과 판단이 팀에 남을 수 있습니다. 새 엔지니어가 같은 실수를 반복하지 않고, 검수 도구가 결함을 일찍 잡고, 이전 실패에서 다음 문제의 아이디어를 얻는 것입니다.

모델이 발전하면 그동안 어려웠던 태스크가 쉬워질 수 있습니다. 같은 과제를 반복 사용하는 동안의 포화에 더해, 새 모델이 처음부터 높은 점수를 받는 문제도 생깁니다. 난도를 다시 설계하고 채점기를 고치는 비용이 계속 든다면, 오래 만든 태스크가 오히려 유지 부담이 될 수 있습니다. 모델의 발전과 과제의 난도에 대한 Ege의 설명, 1:33:30

팀의 경험도 저절로 자산이 되지는 않습니다. 다음 과제도 똑같이 오래 걸릴 수 있고, 특정 엔지니어가 떠나면 판단의 근거를 아무도 설명하지 못할 수도 있습니다. 연구자산이라고 부르려면 다른 사람이 다시 사용해도 도움이 되는 형태로 남아야 합니다.

5. 수작업 연구와 대량 생성은 함께 갈 수 있다

Mechanize의 2025년 글은 대량의 저가 태스크보다 전담 전문가의 지속적인 작업에 무게를 둡니다. Sweatshop data is over

하지만 정교한 설계와 자동 생성은 함께 쓸 수 있습니다. RLVE 연구진은 수작업으로 400개 환경을 설계하고, 각 환경에서 문제를 절차적으로 생성하며 모델 능력에 맞춰 난도를 조절했습니다. 이는 제한된 추론모델 실험이며 실제 기업의 장기 업무나 Mechanize의 사업성을 입증하지 않습니다. 그래도 ‘연구자가 깊이 설계하는 일’과 ‘많은 문제를 자동으로 만드는 일’이 서로를 밀어낼 필요는 없다는 사례입니다. RLVE 논문, 2026년 6월 수정본

전담팀이 집중할 위치는 사람이 계속 해야만 하는 작업의 양을 늘리는 데 있지 않습니다. 어떤 실패를 시험해야 하는지, 자동으로 생성해도 품질을 지킬 수 있는 부분이 어디인지 찾아야 합니다. 좋은 제작 도구가 나오면 태스크 수가 늘어나는 동시에 사람의 검수가 더 어려운 문제로 옮겨갈 수 있습니다.

저는 이런 조직을 Data Lab이라고 부르고 싶습니다. 데이터를 만들면서 무엇을 측정하고 어떻게 학습시켜야 하는지도 연구하는 조직입니다. 납품 결과물과 함께 다음 실험을 위한 방법을 축적합니다.

6. 처음부터 환경 제작을 내건 회사

Mechanize의 창업자는 Matthew Barnett, Tamay Besiroglu, Ege Erdil입니다. 세 사람은 Epoch에서 AI의 스케일링을 연구했고, 2024년에는 Chinchilla scaling law를 재검토한 논문을 함께 썼습니다. Tamay의 배경에는 컴퓨팅 경제학이 있고 Ege는 수학, 통계, 경제와 예측에 관심을 둔 연구자입니다. Epoch의 공동 연구와 저자 소개

2025년 4월 창업 발표부터 이들이 내건 제품은 가상 업무 환경, 벤치마크와 학습 데이터였습니다. AI의 발전을 연구하던 사람들이 그 발전에 필요한 환경을 직접 공급하겠다고 나선 것입니다. 전담 전문가가 오래 맥락을 유지하며 만드는 방식도 이후 글에서 명시했습니다. 창업 발표

데이터 공급과 환경 제작에는 선행 사례가 있습니다. Scale은 2016년부터 사람의 작업을 API로 제공하는 사업을 소개했고, Mercor는 Deeptune이 2024년 무렵부터 업무 앱을 재현해 왔다고 설명합니다. 더 오래된 기술 선례로는 게임과 웹 애플리케이션을 RL 환경에 연결한 2016년 OpenAI Universe도 있습니다. 사업 형태와 기술 범위는 서로 다릅니다. Data Lab의 정의와 시작점을 정하지 않은 채 Mechanize를 최초라고 부를 근거는 부족합니다. Scale의 초기 사업, Mercor의 Deeptune 발표, Universe

이 팀은 AI의 발전을 분석하던 연구에서, AI에게 시킬 일과 그 일을 평가하는 방법을 만드는 쪽으로 넘어왔습니다. 소규모 팀의 전문성이 어디에 쓰이는지를 보여주는 선택입니다.

7. 15억 달러 보도가 답해주지 않는 것

Google과의 거래도 정확히 나눠 봐야 합니다. Business Insider는 2026년 8월 5일, 15억 달러를 넘을 수 있는 인력 영입과 기술 라이선스 협상을 보도했습니다. 9월 11일에는 LinkedIn을 근거로 Tamay와 다수 직원의 Google 합류를 전했습니다. 9월 후속 보도에도 최종 계약 조건과 지급액은 나오지 않았습니다. ‘Google이 Mechanize 전체를 15억 달러에 인수했다’고 확정할 근거는 이 보도에 없습니다. 8월 원보도, 9월 후속 보도

사람과 기술을 확보하려는 수요가 있다는 신호로는 읽을 수 있습니다. 하지만 Google이 무엇에 얼마를 지불했고, 그중 환경 개선의 가치가 얼마였는지는 알 수 없습니다. 창업자의 재사용 전략이 높은 가격으로 보상받았다는 인과를 붙이면 공개 근거를 넘어갑니다.

오히려 인력 이동은 새 질문을 남깁니다. 제작과 검수의 지식이 문서와 도구에 남아 있는지, 특정한 사람을 따라 이동하는지에 따라 남은 회사의 가치는 달라질 수 있습니다. 과거 채용 안내의 팀 규모는 인력 이동 뒤의 조직을 설명해주지 못합니다.

8. 다음 태스크에서 확인할 것

회사는 월간 태스크 납품량을 생산성의 주요 기준으로 삼는다고 설명합니다. 저는 그 수량과 함께 다음 과제를 만드는 조건도 보고 싶습니다. 회사의 생산성 기준

같은 품질 기준을 지키면서 제출과 검수에 드는 시간이 줄었는가. 고친 채점기로 학습했을 때 별도로 남겨둔 과제와 실제 업무에서도 성과가 나아졌는가. 유지와 재작업 비용까지 감안해 계약이 돈을 남기는가.

태스크 하나를 구상해 제출하기까지 보통 약 일주일이 걸린다는 설명만으로는 이 질문들에 답할 수 없습니다. 그 기간만으로 소규모 환경 회사의 가능성을 버릴 이유도 없습니다.

작은 팀이 집중적으로 환경을 연구하는 일에는 값어치가 있을 수 있습니다. 한정된 분야의 실패를 오래 관찰하고, 잘못된 점수를 고치고, 그 방법을 다음 제작에 다시 쓰는 팀이라면 그렇습니다. 그 효과가 포화와 유지 비용보다 큰지는 확인해야 합니다.

태스크 한 개를 팔고 난 뒤에도 다음 태스크를 더 잘 만들 수 있는가. Mechanize에서 이어서 볼 것은 그 능력이 어디에 남는지입니다.