Mercor Head of Product on Revenue Concentration from Frontier Labs

URL: https://www.youtube.com/watch?v=rlY1mHhJKvs 날짜: 2026-07-26 (영상 업로드: 2026-07-25) 채널: 20VC with Harry Stebbings

⚠️ 메타 참고: 게스트는 Mercor의 Head of Product(CPO)이며, 자동 자막(ASR)상 이름이 "Oswald Nitski"로 표기되나 정확한 로마자 표기는 확인되지 않았다(공식 자료로 교차검증 실패). 본문에서는 "게스트"로 지칭한다. 자동 자막이 회사명 "Mercor"를 Mcore/Mekor/Merkle/Recur/Brex/Mckool 등으로 계속 오인식했기에 문맥상 모두 Mercor로 통일 보정했다. "moving away from Figma in favor of cloud design"이라는 표현도 ASR 오인식 가능성이 있어(Figma를 대체하는 AI 기반 디자인/코딩 툴을 지칭하는 것으로 추정) 원문 표현을 그대로 살리되 이 점을 명시한다.

---

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

Mercor는 ==프론티어 랩(OpenAI, Anthropic 등)에 대한 매출 집중도가 극도로 높은 회사==이지만, 정작 회사 내부에서는 "우리는 돈을 다 못 쓸 정도로 현금이 넘친다"고 말할 만큼 압도적으로 건강한 비즈니스를 운영 중이다. 이 영상은 (1) 오픈소스 모델이 Mercor의 데이터 비즈니스를 잠식할 것인가, (2) 대기업이 왜 프론티어 모델 제공사와 파트너링을 두려워하는가, (3) 매출 집중 리스크를 어떻게 낮출 것인가를 Mercor 프로덕트 총괄의 시선으로 파헤친다.

• Mercor는 오픈소스 모델의 발전이 자사 핵심 비즈니스를 잠식(cannibalize)하지 않는다고 본다 — 데이터는 "모델 성능의 프론티어"에서 가장 가치가 크기 때문
• 엔터프라이즈 워크플로우의 90%가 오픈/프론티어 모델로 커버된다는 통념에 반박하며, Mercor 자체 Apex 벤치마크 기준으로는 장기 과업(long-horizon workflow) 처리율이 약 50%에 불과하다고 주장
• 프론티어 모델 제공사에 대한 매출 집중도가 매우 높지만(고객사 상당수가 랩), 다운마켓(일반 엔터프라이즈)으로 확장하는 것이 회사의 최우선 전략 방향

Mercor는 랩 대상 "화이트글러브 서비스"에서 출발해, 이제는 AI 프로젝트 매니저 등을 통해 셀프서브 방식으로 일반 엔터프라이즈까지 인간 데이터(annotation/eval/training data) 서비스를 확장하려 하며, 이 과정에서 매출 집중도 완화 · PM 조직 구조 변화 · 신규 데이터 유형(RL 환경, 로보틱스, 사이버보안) 발굴을 동시에 추진하고 있다.

---

1. 오픈소스 vs 프론티어 — Mercor 비즈니스는 잠식되는가

오픈소스 모델의 급속한 발전(예: Kimi의 신모델 출시)에도 불구하고, 게스트는 오픈소스가 Mercor의 핵심 비즈니스를 잠식한다고 보지 않는다.

1.1. 데이터는 "모델 성능의 프론티어"에서만 가치가 있다

1. 오픈소스는 바닥(floor)만 높인다
   1. 오픈 모델의 역할: 오픈 모델이 좋아질수록 "이미 오픈 모델이 할 수 있는 것"에는 아무도 돈을 쓰지 않게 되지만, 이는 Mercor의 매출원이 아니다
   2. 각 고객사의 목표는 서로 다르다: 모든 Mercor 고객사는 "현재 모델 능력의 공백(gap)"을 메우기 위해 eval/training 데이터셋을 구매하며, 이 공백은 오픈소스가 발전해도 계속 새로 생긴다
2. 여전히 새로운 능력을 원하는 한 성장한다
   1. 결론: 고객이 "더 나아지고 싶은 새 역량"을 계속 원하는 한 Mercor의 사업은 계속 성장한다

1.2. "엔터프라이즈 워크플로우 90%가 이미 해결됐다"는 통념에 대한 반박

1. 90/10 프레이밍은 현재 수요만 반영한 계산
   1. 하비스팅 편향: 90% 자동화 주장은 기존에 사람들이 이미 시도하고 있던 작업(수요가 드러난 것)만 계산에 넣은 것이며, "아직 아무도 시도조차 하지 않는" 잠재 수요(latent demand)는 빠져 있다
   2. 예시 — 장기 과업(long-horizon task): 조달(procurement) 에이전트를 세팅해 몇 달간 조달팀 업무를 완전 자동화하고 주 1회만 체크하는 식의 작업은 현재 통계에 아예 잡히지 않는다
2. Mercor 자체 벤치마크(Apex) 수치
   1. 실측치: Mercor의 Apex 벤치마크 기준, 최고 모델들의 장기 과업(long-horizon workflow) 처리 비율은 약 50% 수준이라고 밝힘 (90%라는 통념보다 훨씬 낮음)
   2. "완료/미완료" 이분법이 안 맞는 작업군: CRM 업데이트처럼 "하면 끝(sufficiency-based)"인 작업은 이분법이 맞지만, 법률 자문·의료 조언처럼 "항상 더 잘할 수 있는(continuous, uncapped reward)" 작업군은 %(퍼센트) 프레이밍 자체가 틀렸다고 지적

1.3. 회사 전용 특화 모델의 미래

1. 경쟁사(Filecoin 창업자 언급)의 주장에 대한 견해
   1. 인용된 주장: 20VC에 출연한 Filecoin 창업자 Lynn Qual은 "회사마다 우선순위(성장 vs 마진 vs 워라밸 등)가 다르기 때문에 회사별 특화 모델이 필요해질 것"이라 주장함
   2. 게스트의 동의: 게스트도 이 주장에 동의하며, 이는 Mercor에도 유리한 흐름이라고 인정 — 특화 모델마다 기업별 특화 eval/training 데이터가 필요해지기 때문
   3. 단, 조건부: ROI가 실제로 정당화되는 케이스에서만 특화 모델 수요가 생기며, 그런 케이스는 시간이 갈수록 늘어날 것으로 전망

---

2. 대기업이 프론티어 모델 제공사와의 협업을 두려워하는 이유

Palantir CEO Alex Karp가 최근 무대에서 "대기업들이 데이터를 프론티어 모델 제공사와 공유하는 것에 극심한 회의(skepticism)를 느낀다"고 언급한 것에 대한 질문.

2.1. 민감도는 "그 워크플로우가 핵심 사업인지"에 달려 있다

1. 덜 민감한 영역: HR, 조달처럼 모든 회사가 공통으로 하는 일반적 업무는 민감도가 낮아 프로프라이어터리(폐쇄형) 모델에 맡기는 데 개방적
2. 더 민감한 영역: 회사의 핵심 경쟁력과 직결되는 업무(예: 로펌이 실제로 작성하는 메모, 고객에게 주는 법률 자문 내용)는 민감도가 훨씬 높음

2.2. 아이러니 — 민감한 데이터는 오픈소스(중국 모델)에, 덜 민감한 데이터는 폐쇄 모델에

1. 진행자의 지적: "가장 민감한 데이터는 오픈소스(대부분 중국계) 모델에, HR·조달 데이터는 폐쇄 모델에 올린다"는 것은 아이러니하지 않냐는 질문
2. 게스트의 답변 — 배치 위치가 핵심
   1. 오픈 웨이트의 장점: 오픈 웨이트 모델의 장점은 추론(inference)을 여러 장소에서 실행할 수 있다는 것 — 즉 자체 인프라에 배치하면 데이터가 외부로 나가지 않음
   2. 결론: 오픈소스 자체가 문제가 아니라 어디서 실행하느냐가 관건이며, 잘못 쓰면 실수할 수 있지만 통제권은 더 크다

---

3. 엔터프라이즈 AI ROI 문제

3.1. "지금 AI ROI 문제가 있는가?"에 대한 답

1. 현재는 탐색·실험 국면
   1. 관용도(tolerance): 지금은 ROI 계산을 맞춰가는 탐색·실험 단계이며 인내심(tolerance)이 있는 시기
   2. 압박은 시작됨: 토큰 가격·성능 전망이 엇갈리는 가운데, 지출에 대한 나사 조이기(tightening of the screws)가 부분적으로 시작되고 있음
   3. 패러다임: 변화가 너무 빨라 ROI 계산 자체가 급격히 바뀔 수 있어, 지금은 "일단 지켜보자"는 국면

3.2. 지출 최적화 — 성장 vs 비용(COGS) 구분이 핵심

1. 하이퍼그로스 기업의 관점(게스트의 경력 배경)
   1. 성장 최우선 문화: 게스트는 커리어 대부분을 하이퍼그로스 기업에서 보냈으며, 단위 경제(unit economics)만 맞는다면 성장을 위한 지출에는 관대함
2. 코딩 에이전트 지출 vs 고객서비스 에이전트 지출은 완전히 다른 문제
   1. 엔지니어용 코딩 에이전트: 매출원가(COGS)가 아니며, 지출이 높아도 복리로 쌓이는 이득(compounding gains)일 수 있어 괜찮음
   2. 고객서비스 에이전트: 토큰 지출이 고객에게서 나오는 매출보다 훨씬 낮으면 명백히 나쁜 포지션
3. 결론: 하이퍼그로스 단계 기업들에게 성장·효율화를 위한 토큰 지출은 폭증하는 수요를 감당하기 위해 "해야만 하는 일"

3.3. 세일즈포스 사례로 본 AI 지출의 미래 비중

1. 인용된 수치: 세일즈포스 CEO 마크 베니오프가 앤트로픽에 연 3억 달러를 지출하며, 이는 개발자 평균 급여의 약 3.8%에 해당한다고 공개
2. 게스트의 전망
   1. 비중 증가 예상: 회사 규모가 큰 세일즈포스 같은 곳도 팀별로 지출 프로파일이 다를 수밖에 없다(솔루션 엔지니어링/포워드 디플로이드 팀은 단위 경제를 따져야 하지만, R&D 팀은 더 관대할 수 있음)
   2. 매크로 전망: 거시적으로 이 비중은 시간이 갈수록 3%보다 더 커질 것으로 전망
3. 20VC 진행자의 추가 정보: 진행자는 이전에 Mercor CEO 브렌든 푸디(Brendan Foody)가 같은 쇼에서 "이 비율이 결국 100%까지 갈 것"이라며 "Mercor는 이미 급여보다 AI 지출이 더 많다"고 말했다고 전함
4. 게스트의 확인: 게스트도 이를 확인하며, Mercor는 입사 이후 인원이 10배 이상 늘었고 매출도 함께 늘었지만, 수요가 너무 많아 "돈을 다 못 쓸 정도"라 100% 비중도 합리적이라고 답함

---

4. AI 시대의 프로덕트 매니지먼트 — 무엇이 달라졌나

4.1. "10배 더 많은 제품을 만들어야 하는가?"에 대한 답 — 오히려 반대

1. PM의 새로운 임무는 확장이 아니라 축소
   1. 표면적 폭증의 위험: 엔지니어들이 "이런 기능 다 빨리 만들 수 있다"며 수천 줄짜리 PR을 밀어붙이는 순간 제품 표면적(surface area)이 급격히 팽창해 혼돈이 생김
   2. PM의 역할 변화: 프로덕트팀은 오히려 지속적으로 제품 표면적을 줄이고 단순화하며, 가장 확장 가능한 상호작용·워크플로우를 찾아내는 싸움을 벌이고 있음
2. PM 대 엔지니어 비율의 변화
   1. PM 비중 증가: 엔지니어링이 코딩 에이전트로 인해 병목이 덜해지면서, 사용자 니즈 이해와 "어떤 제품이 실제로 매출을 이끄는가" 파악이 새로운 병목이 됨에 따라 PM 대 엔지니어 비율이 높아지는 추세

4.2. 좋은 PM의 조건 변화 — 두 가지 핵심 변화

1. 툴 학습 부담 감소
   1. 툴 다양성 축소: 코딩 에이전트 같은 몇 가지 도구만 잘 쓰면 되고, 배워야 할 툴 종류 자체가 줄어듦
   2. 디자인 툴 변화 사례: Figma조차 점점 덜 쓰고 있으며, 원문 표현으로는 "cloud design"으로 옮겨가는 추세라고 언급(팀이 원하는 대로 알아서 선택하게 하며, 라이선스 관리 부담이 줄고 사용이 쉬워 자연스럽게 이 흐름으로 이동했다고 설명)
2. 비즈니스 임팩트 판단력이 훨씬 더 중요해짐
   1. 업무 수준 상향: 세세한 디테일은 훨씬 빨리 처리되므로, 모든 일이 더 높은 레벨(higher level)에서 이루어지기 시작함
   2. 판단력이 새로운 병목: "스킬 이슈"는 거의 사라졌고, 이제 중요한 건 "내가 지금 옳은 일에 시간을 쓰고 있는가"라는 판단력(judgment)

---

5. 실패담과 교훈 — 애노테이션 플랫폼의 과잉 유연성

5.1. 무엇을 후회하는가

1. 문제의 발단
   1. 수요의 이질성: 인간 데이터 수요가 매우 크고 다양했고, 딜리버리팀이 프로젝트 수주를 워낙 잘해서, 지나치게 많은 워크플로우를 지원하는 애노테이션 플랫폼을 만들게 됨
   2. 데이터 형태의 급변: InstructGPT 시절의 지도 미세조정(SFT)에서 선호도 랭킹(preference ranking), 이후 여러 형식의 멀티모달 프로젝트, 그리고 지금의 RL 환경까지 데이터 형태가 계속 바뀜
2. 결과 — 관리 불가능한 혼돈
   1. 극단적 유연성의 대가: 최대한 유연한 툴을 만든 결과 수백 개의 서로 다른 프로젝트가 그 위에서 동시에 돌아가는 관리 불가능한 상태가 됨

5.2. 배운 교훈 — 더 일찍 가드레일을 세웠어야 했다

1. 가드레일의 필요성
   1. 운영팀과의 협업: 지원하는 서비스 유형에 가드레일을 두고 운영팀과 함께 "이건 우리가 할 수 있지만, 해야 하는가?"를 판단했어야 했다고 회고
   2. 지속가능한 수요(enduring demand) 기준: 특정 워크플로우에 지속적인 수요가 없다면 투자할 가치가 없다고 판단
2. 지속가능한 수요는 어떻게 판단하나
   1. 판단 근거: 데이터가 1~2년 뒤 어떤 모습일지 정확히 예측하기는 매우 어려워, 결국 다양한 랩의 리더들과 끊임없이 소통하며 가설을 검증하는 방식으로 판단 — "결국은 일종의 추측(guess)"이라고 솔직히 인정

---

6. 서비스화(Services) 트렌드 — AI 엔터프라이즈 배포의 미래인가

Microsoft가 서비스 부서를 신설하고 Palantir의 서비스 매출 비중이 커지는 것에 대한 질문.

6.1. 단기적으로는 지식 확산의 문제

1. 지금은 지식이 SF에 집중
   1. 지역 편중: 에이전트를 배포하고 평가하고 AI-first로 일하는 법을 아는 사람들은 지금 샌프란시스코에 집중돼 있고, 이 지식이 아직 산업 전반에 퍼지지 않음
2. 장기적으로는 소프트웨어 엔지니어링과 같은 하나의 직군이 될 것
   1. 전망: 지식이 확산되면 매번 에이전트를 세팅해주는 팀이 필요 없어지고, 결국 소프트웨어 엔지니어링과 비슷한 하나의 직군이 될 것

6.2. "서비스는 나쁜 제품의 변명일 뿐"이라는 비판에 대한 응답

1. 진행자가 전한 Factory CEO 매트(Matt)의 발언: "서비스는 결국 부실한 제품에 대한 변명일 뿐"
2. 게스트의 반박: 이는 지식 확산 문제이지 제품 문제가 아니며, 지금 시점에서 모든 엔터프라이즈가 자체적으로 에이전트 배포 전문성을 갖추는 것은 아직 불가능 — 이는 "10년 단위"의 장기적 변화

---

7. 인재 — FD(포워드 디플로이드), 창업자 유출, 채용 기준 변화

7.1. 좋은 엔지니어는 FD가 되고 싶어하는가

1. 좋은 엔지니어의 여러 유형
   1. 커뮤니케이터형: 훌륭한 커뮤니케이터이자 문제의 근원을 파고들어 단순화하는 능력을 가진 엔지니어가 FD(Forward Deployed)에 적합
   2. 창업가형과 동일선상: 같은 유형의 엔지니어가 향후 창업자가 되기에도 적합한 인재이며, Mercor가 일반적으로 채용 시 찾는 프로필이기도 함

7.2. "코어 마피아"(창업자로 유출되는 인재) — 긍정적으로 본다

1. 게스트의 자부심: 가장 가깝게 일한 팀원들 중 이직으로 잃은 사람은 없고, 오직 "창업"으로만 잃었다고 자부
2. 관리 난이도는 오히려 높아짐: 이런 고주도성(high-agency)·야심 있는 인재들을 관리하는 것은 더 어렵지만, 모두가 안주하는 조직보다 이런 환경을 선호한다고 밝힘

7.3. 채용 기준 변화 — 더 시니어한 인재로 편중

1. 시니어 선호 이유: 비즈니스 임팩트 이해, 매출 창출 메커니즘 파악(revenue driver, customer happiness 등)을 더 빨리 체득하는 것은 시니어 후보들이라고 관찰
2. "주니어 스킬"의 가치 하락: 툴 사용법 같은 주니어급 역량은 갈수록 덜 중요해짐
3. 적정 시니어리티: 완전한 임원급이 아니라, 여전히 배고프고(hungry) 커리어의 전성기(prime)에 있는 지점을 찾음 — 게스트는 그 프라임을 25~35세로 봄
4. 채용 프로세스 변화
   1. 테이크홈 과제 축소: 과거 방식의 테이크홈 과제는 줄이고, 에이전트를 활용해 결과물을 만들어보게 하는 과제 1개로 "AI 툴에 능숙한지"만 확인
   2. 화이트보드 중심 전환: 이후에는 좋은 실험 설계, 통계 이해, 판단력, 시스템 디자인 역량을 화이트보딩으로 평가

---

8. 판단력을 지키는 법 — 모델에 위임하지 말아야 할 것

8.1. 실험과 판단력의 경계선

1. 좋은 실험 설계·시스템 디자인을 중시하는 이유: AI 도구로 사고 자체를 아웃소싱하기 쉬워졌기 때문에, 팀이 정보를 실제로 드러내는 실험을 설계하는 능력과 결과를 조작(fudge)하지 않는 능력을 유지하는 게 중요
2. "Claude가 뱉어낸 걸 그대로 되뇌지 않기": 사람들이 AI 도구가 내놓은 결과를 그대로 반복(regurgitate)하지 않고 실제 판단력을 유지하는지 확인하고 싶다고 밝힘

8.2. 판단력·의사결정을 모델에 위임하지 않는다는 원칙

1. 개인 원칙: 판단력(judgment)이나 의사결정(decision-making)은 절대 모델에 위임하지 않는다는 원칙을 지킴 — 모델이 옳은 일을 하고 있다고 착각하게 만들 수 있어 항상 편집증적으로(paranoid) 다시 확인해야 함
2. 팀에 전하는 메시지: 자신의 실제 업무(진짜 의사결정)를 모델에 위임하면 그 능력 자체를 잃게 되고, 결국 "정신적으로 무너진다(psychosis)"고 강하게 경고

---

9. 조직 구조 — 마켓플레이스 vs 애노테이션/Eval 플랫폼

9.1. 두 개의 독립된 제품 영역

1. 마켓플레이스(Marketplace): 전문가(experts)를 채용 기업(고객)과 매칭하는 제품
2. 스튜디오/애노테이션(Studio/Annotation & Eval Platform): 전문가들이 로그인해 eval·training 데이터셋을 위한 애노테이션을 수행하고, 운영팀과 고객사도 로그인해 프로젝트를 실행·데이터 확인·eval을 진행하는 제품

9.2. 두 가지 참여 모드

1. Talent-only 모델: Mercor가 전문가만 고객사에 보내고, 고객사가 프로젝트를 직접 운영(급여·성과관리는 고객사 책임)
2. Managed Service 모델: 마켓플레이스로 사람을 보낸 뒤 Mercor가 프로젝트를 직접 운영해 전체 데이터셋을 고객사에 전달

9.3. 팀 규모와 운영 리듬

1. 팀 크기: 제품 영역당 PM 2~3명 + 데이터 사이언티스트(영역별 전담) + 디자이너(영역 간 유동적으로 배치) — 총 4~5명 규모의 "포드(pod)" 단위
2. PM 대 엔지니어 비율 전망: 코딩 에이전트로 엔지니어링 속도가 빨라질수록 PM당 엔지니어 수는 줄어들 전망 — 다만 헤드카운트가 1년새 10배 이상 늘어난 상황에서 한쪽만 과도하게 키우지 않도록 신중하게 관리 중
3. 회의 구조: 제품 영역별로 3명 정도의 PM이 각자 포드를 맡아 스프린트 플래닝을 하고, 주간 "제품 영역(PA) 회의"에서 로드맵 정렬을 확인 — 금요일 늦은 시간에 회의를 잡아 "주말에 일찍 못 빠지게" 함
4. 가장 어려운 점: 팀이 급성장하며 커뮤니케이션 채널이 폭발적으로 늘어, 마켓플레이스팀과 스튜디오팀 사이의 정보 공유·크로스 제품 영역 협업을 유지하는 것이 가장 큰 난제

---

10. 마켓플레이스 공급 확장의 비결

10.1. 세 가지 요인

1. 탁월한 전문가 경험(expert experience)
   1. 제때, 후하게, 투명하게 지급: 전문가들이 정시에, 잘, 투명하게 급여를 받도록 함
   2. 추천 프로그램의 전제조건: 좋은 경험 없이는 아무도 동료를 추천하지 않기 때문에, 이 경험이 강력한 추천 프로그램의 필수 전제
2. 탁월한 소싱팀: 전 세계 구석구석에서 특정 스킬을 가진 인재를 찾아내는 소싱 역량이 수요가 튀는(spiky demand) 특정 스킬 공백을 메움
3. 단기 보너스가 아닌 장기 신뢰: 경쟁사들의 파격적 단기 보너스는 재방문율을 높이지 못하며, 미래 업무 가시성·성장 기회·다양한 프로젝트 선택권·좋은 커뮤니케이션이 있어야 사람들이 계속 남는다고 설명

10.2. 마진 구조

1. 가치 전달이 먼저, 마진은 사후 결정: 프로덕트팀은 고객에게 최고 가치를 전달하는 방법(자동 품질관리, synthetic data 개선, 스태핑 최적화 등)을 먼저 고민하고, 마진은 그 이후 비용을 고려해 결정됨
2. 원가 구조: 최근 프로젝트들의 비용은 전문가 지급 비용과, synthetic data·자동 품질관리에 들어가는 LLM 지출이 거의 동등한 비중을 차지

---

11. 매출 집중도 문제 — 다운마켓 확장이 핵심 과제

11.1. 프론티어 랩에 대한 매출 의존, 어떻게 볼 것인가

1. 집중도는 인정: 프론티어 모델 제공사가 압도적으로 큰 고객이라는 점은 인정하지만, "그것이 매출(revenue)이 아니다"라는 외부 비판에는 개의치 않는다는 입장 — 매주 은행 잔고가 수백만 달러씩 늘어나는 실제 현금흐름이 있기 때문
2. 다운마켓 확장이 최우선 과제: 프로덕트팀의 최대 도전 과제는 모든 개별 엔터프라이즈가 효율적으로 인간 데이터(eval/training) 프로젝트를 수행할 수 있게 만드는 것 — 랩보다 훨씬 많은 수의 일반 기업이 존재하므로 자연히 매출이 분산됨
3. 셀프서브 + AI 프로젝트 매니저: 셀프서브 프로젝트 운영과 AI 프로젝트 매니저를 통해 소규모 고객사도 쉽게 이용할 수 있도록 만드는 방향으로 회사 전체가 움직이고 있으며, 실제로 이 방향으로 집중도가 낮아지는 추세라고 밝힘

11.2. 인간 데이터 프로젝트가 어려운 이유

1. 정보 전달의 난이도: 고객사→고객사의 최종 사용자→전문가(annotator)까지 전달돼야 할 정보가 방대하며, 엣지 케이스가 끊임없이 튀어나오고 그 처리 방식이 결과 품질을 좌우함
2. 필요한 두 가지 역량
   1. 극도의 편집증(paranoia): 모든 데이터 포인트가 가이드라인에 완벽히 부합하고 일정대로 진행되도록 운영팀이 지속적으로 확인해야 함
   2. 빠른 정렬(alignment): 고객·고객의 고객·다른 분야 전문가·애노테이터 사이의 신속한 정렬이 필요
3. 데이터 형태가 계속 바뀜: SFT → preference ranking → rubric 기반 애노테이션 → 지금의 RL 환경까지, 프로젝트마다 그리고 프로젝트 간에도 복잡성이 계속 달라짐

---

12. 성장하는 신규 데이터 유형 — RL 환경(Environments)과 로보틱스

12.1. RL 환경(Environments) — 현재 가장 빠르게 성장하는 데이터 유형

1. 정의: Mercor는 이를 "에이전트가 사용할 앱들의 시뮬레이션"으로 정의하며, 스스로를 이 카테고리의 리더로 인식
2. 구성 요소
   1. 시작 상태(start state): 노트북 안에 있을 법한 모든 데이터를 대표하는 "세계"에 해당 — 수백~수천 개 파일 규모가 될 수 있음
   2. 과업(tasks): 에이전트가 그 도구들을 활용해 유용한 것을 해내도록 훈련시키는 과업
3. 왜 복잡한가: 배포 환경과 흡사한 고충실도(high-fidelity) 목업이 필요 — 예를 들어 세일즈포스 사용법을 학습시키려면 세일즈포스와 거의 똑같이 동작하는 목업이 필요하며, 이는 과거 preference ranking이나 SFT가 처음 등장했을 때만큼 지금은 셋업이 어려운 프론티어 영역
4. 전망: 랩들이 지금 이 방법을 알아내는 중이며, 결국 충분히 매끄러워지면 일반 엔터프라이즈도 가능해질 것

12.2. 랩들은 데이터 구매에 가격 민감한가

1. 협상은 항상 존재: 조달팀이 더 나은 조건을 얻으려 협상하는 것은 늘 있는 일
2. 핵심 논리 — 지출 대비 매출: eval 세트를 사는 것은 결국 고객이 원하는 것을 더 잘하기 위한 것이고, training 세트는 그 eval 세트를 향해 힐클라이밍(hill-climbing)하는 것이므로, 데이터에 쓰는 돈이 그로 인해 벌어들일 매출보다 적은 한 랩들은 오히려 더 세게 레버를 당기고 싶어한다고 설명

12.3. 데이터 제공업체 생태계의 파편화 — "창업자 주도 애노테이션"이라는 코티지 산업

1. 현상: 애노테이션 난이도가 높아질수록, 창업자 본인이 직접 데이터를 만드는 스타트업들이 늘고 있음 — 랩 입장에서는 "완전히 저평가된(mispriced)" 값싼 노동력이라 선호
2. 한계: VC 투자금으로 보조되는 이런 방식은 소수의 데이터 포인트, 한두 명의 창업자/풀타임 직원 수준을 넘어 확장(10배 처리량, 10배 프로젝트 규모)하지 못한다는 것이 명확한 한계이며, Mercor 고객들도 이를 알고 있다고 강조
3. 시사점: 이런 흐름은 결국 업계가 "더 숙련된 전문가", "세계 최고 수준의 인력"이 애노테이션을 수행해야 하는 방향으로 가고 있음을 보여준다고 해석

12.4. 경쟁 구도 — 경쟁사보다 고객에 집중

1. 경쟁사를 크게 신경 쓰지 않음: 경쟁사가 낸 블로그·웹사이트 업데이트가 몇 주~몇 달 전 Mercor가 이미 했던 것과 똑같다고 지적하며, 경쟁사보다 고객에 훨씬 많은 시간을 쓴다고 강조
2. Surge에 대한 평가: Surge는 Mercor를 따라하지 않는 편이고 업계에서 좀 더 독자적인 노선을 걷는 것 같다고 평가(왜 그런지는 모르겠다며 "매우 비밀스럽다"고 언급)
3. 모니터링은 함: 경쟁 인텔리전스는 지속적으로 수행하며, 고객사들도 정보를 자발적으로 공유해줌 — 누군가 더 잘하면 배워서 뛰어넘겠다는 태도이며, "Mercor가 이기는 한" 이런 경쟁 압력은 건강하다고 평가

---

13. Anthropic의 버티컬 진출(Legora, Figma 경쟁) 논쟁

13.1. 진행자의 질문 — Anthropic이 법률(Legora)·디자인(Figma) 시장까지 진출하는 게 맞는가

1. 진행자의 우려: Anthropic이 진짜 노려야 할 건 암 치료·기후변화 같은 인류의 근본 문제이지, Cooley·Goodwin 같은 로펌 계약을 따내는 게 아니지 않냐는 문제 제기

13.2. 게스트의 답 — 빅테크 역사에서 선례를 찾을 수 있다

1. 구글·마이크로소프트의 선례: 두 회사 모두 우연히 기후변화·암 치료 해결을 시도하지만 그게 본업은 아니며, 다양한 영역에 손을 뻗지만 결국 경쟁자는 계속 등장한다는 점을 지적
2. 실패 사례 인용: 구글 플러스(Google Plus)는 결국 사라졌고, 스레드(Threads)도 (마케팅상 4억 사용자라고 하지만) 실제 참여도(engagement)는 알 수 없다며 회의적 태도
3. 결론: 대기업은 종종 새로운 베팅과 다각화를 시도하지만, 시장에 강한 집중력을 가진 회사에게 결국 밀리는 경향이 있다는 역사적 패턴을 언급하며, 다양한 사업부를 가진 대기업이라도 매출을 견인하는 핵심 사업은 따로 있었다는 점을 강조

---

14. 보안 해킹 사건 이후의 변화와 사이버 보안 데이터 수요

14.1. 과거 해킹 사건이 프로덕트 마인드셋에 미친 영향

1. 전문가 영입과 위임: 스스로 보안 전문가는 아니지만 다수의 보안 전문가를 영입했고 그들의 판단을 신뢰하며 따르는 것이 가장 큰 변화라고 답함
2. 더 큰 투자: 사내에 영입한 전문가들로부터 배우는 데 더 크게 투자하는 방향으로 조직을 바꿈

14.2. AI 생성 코드 증가 → "사이버 보안의 황금기"가 오는가

1. 동의: 진행자가 언급한 "AI 생성 코드가 늘면서 보안 취약점(hole)도 늘고, 위협이 예상보다 훨씬 빠르게 커질 것"이라는 전망에 동의
2. 경쟁적 데이터 유형이라는 특성
   1. AlphaGo형 구도: 사이버 공격·방어는 경쟁적 성격을 띠고 있어 무한 보상(uncapped reward)이 가능한 "게임"에 가까운 데이터 유형이라 Mercor가 선호하는 영역이라고 밝힘
   2. 급증하는 방어 데이터 수요: 사이버 방어 역량에 대한 데이터 수요가 매우 빠르게 늘고 있으며 흥미로운 데이터 유형이 등장 중
3. 왜 90%가 통하지 않는 영역인가: 보안은 공격·방어가 끊임없이 서로를 뒤쫓는 적대적(adversarial) 게임이라 골대(goal post)가 계속 움직이기 때문에, 다른 워크플로우처럼 "90%가 완료됐다"는 개념 자체가 성립하지 않는다고 설명

---

15. 샌프란시스코 인재 전쟁과 조직 문화

15.1. SF에서 인재를 구하는 건 실제로 그렇게 잔혹한가

1. 인정: 채용도 어렵고 리텐션도 어렵다고 인정하며, 과거보다 더 어려워졌다고 평가
2. 로켓십 효과: 회사가 로켓십(급성장 궤도)에 올라 있으면 사람을 구하는 것 자체는 오히려 쉬워지지만, "누구를 뽑을지 올바르게 결정하는 것"이 더 어렵다고 구분

15.2. 나쁜 채용에서 배운 것 — 주도성과 오너십은 면접에서 평가하기 매우 어렵다

1. 평가의 어려움: 지원자의 주도성(agency)과 오너십(ownership)을 면접 과정에서 파악하는 것이 특히 힘들다고 답변
2. 문화 원칙: 회사 문화는 높은 주도성·높은 성과·높은 오너십을 중시하며, "성격은 고칠 수 있어도, 진심으로 신경 쓰는 태도(give a shit)"는 코칭으로 만들기 어렵다고 강조 — 반대로 동료 관계를 부드럽게 만드는 건 술자리 몇 번으로도 해결된다고 비유

15.3. 팀 문화 사례 — Tofino 오프사이트

1. 최근 오프사이트: 애노테이션팀과 함께 캐나다 서부 해안의 토피노(Tofino)로 오프사이트를 다녀왔으며, 전 직원이 서핑 레슨을 받고 플로팅 사우나(floating sauna)를 체험함
2. 평가: 팀에 실질적으로 좋았고 돈을 잘 쓴 사례라고 평가하며, 사람들이 몸을 움직이는 야외 활동이 좋다고 생각한다고 밝힘

---

16. 퀵파이어 라운드

16.1. 지난 12개월간 생각이 가장 많이 바뀐 것

1. 환경(Environments) 시장: 작년 초 시작할 때는 딜리버리가 너무 복잡하고 어려워 "이건 안 될 것 같다"고 생각했지만, 수요가 워낙 높아 여러 방법을 시도한 끝에 결국 작동시켰다고 밝힘 — 스스로도 놀랄 만큼 잘 됐다고 평가

16.2. 대학생 동생에게 해줄 조언

1. 학교보다 실전: 학교에서 배우는 건 금방 업데이트되니, 가능한 한 빨리 실제 인턴십을 구하라고 조언
2. 어디에 조인해야 하나: 자신이 편향돼 있을 수 있음을 인정하면서도, "샌프란시스코의 급성장 기업"에 조인하라고 권함 — 반드시 대기업일 필요는 없지만 최소 10명보다는 큰, 업계 프론티어에 있는 회사를 골라 "어디로도 못 갈 회사"를 걸러내라고 조언
3. Mercor에 지원하기엔 너무 늦었나?: 아니다 — Mercor는 여전히 스타트업처럼 행동하며, 현재 인원 약 500명 규모에도 편집증적이고, 상시 오피스 근무를 하며 빠르게 움직이는 "컬트" 같은 문화를 최대한 유지하려 한다고 밝힘

16.3. 가장 존중하는 경쟁사와 Mercor의 불 케이스($200B 기업론)

1. 경쟁사 평가: 특정 경쟁사를 딱히 존중한다기보다, Mercor는 고객에 훨씬 더 집중하며 경쟁사들의 움직임은 대개 Mercor가 몇 주~몇 달 전에 이미 했던 것을 뒤따르는 정도라고 평가. Surge만은 좀 더 독자적으로 움직이는 것 같다고 언급
2. Mercor가 거대 기업이 될 수 있는 이유(Bull Case)
   1. 테크 기반 서비스 기업: Mercor는 사실상 기술 기반 서비스(tech-enabled services) 기업이며, 서비스의 핵심 가치는 더 나은 모델 성능을 통해 고객사의 실제 매출을 견인하는 것
   2. Eval·training 데이터가 병목: 지금 모델 성능의 가장 큰 병목은 eval과 training 데이터이며, 모든 엔터프라이즈가 특화 모델을 필요로 하게 되면 eval은 "PRD이자 최적화 목표"로 계속 핵심적 역할을 함
   3. 성장 벡터: 인간 데이터 기반 eval/training 수요, 그리고 갈수록 커지는 에이전트 배포(agent deployment) 엔터프라이즈 사업부까지 매출 확대 여지가 크다고 설명

16.4. 3년 뒤 유의미해질 새로운 매출 라인 — 로보틱스

1. 전망: 실물(physical) 데이터가 향후 3년간 크게 성장할 것으로 전망하며, 로보틱스를 흥미로운 영역으로 지목
2. 근거: 로보틱스 데이터 시장은 생성 AI(GenAI)나 자율주행(자율주행차) 대비 아직 초기 단계(nascent)이며, 앞으로 크게 성장할 것이라고 설명

16.5. 수요보다 앞서 공급을 확보하는가

1. 선제적 인재 확보: 미래에 가치가 있을 법한 작업을 위해 우수 인재를 미리 확보(retain)하는 경우가 있음
2. 재고형 데이터 생산: 수요가 낮을 때 기성(off-the-shelf) 데이터를 미리 만들어두고 이후 재판매하는 경우도 있으나, 이런 경우가 아니라면 보통은 공급을 미리 늘리지 않는다고 답함

16.6. 가장 좋았던 조언 & 마지막으로 흥분되는 것

1. 최고의 조언: 작은 회사, 스타트업에 조인하고 샌프란시스코로 이주하라는 조언을 받아 실제로 따랐고, 매우 좋은 선택이었다고 회고(캐나다 토론토에서 학교를 다님)
2. 가장 저평가된 기회: 3년 뒤를 내다보면 여전히 로보틱스라고 재차 강조

---

17. 로보틱스 — "챗GPT 모멘트"가 올까

17.1. 진행자의 회의론 — 로봇 시연은 아직 사람이 뒤에서 조종하는 수준 아닌가

1. 비유: 로봇이 냉장고에서 물 한 병 꺼내는 데 15분 걸리는 시연을 본 뒤 "브렌든(Mercor CEO)이 다른 방에서 조종하고 있었다"는 식의 농담으로, 현재 로보틱스 데모의 한계를 지적

17.2. 게스트의 답 — 자율주행차의 궤적과 유사할 것

1. 자율주행 유사 사례: 10년 전 크루즈(Cruise)가 샌프란시스코를 달릴 때도 항상 사람이 타고 있었지만, 지금은 웨이모(Waymo)를 우버보다 더 자주 이용한다며 진전을 설명
2. 한계 인정: 웨이모는 아직 한 도시(SF 등 일부 도시)에서만 매우 모호한(ambiguous) 데이터에 대응하지 못하는 등 한계가 있지만, 지난 10년간 샌프란시스코·오스틴·피닉스에서 눈에 띄게 발전했다고 평가하며, 지리적 분포 불균형과 규제·확장성 과제는 남아 있다고 인정
3. 최종 전망: "챗GPT 모멘트"보다는 웨이모·크루즈식 로보택시 모멘트에 가까울 가능성이 크다고 전망 — 물리적인 것은 소프트웨어보다 확장이 훨씬 어렵기 때문. 다만 발전 자체는 계속될 것이라고 확신

---

주요 발언 모음

"We end every week with so much more money in the bank. Like the business is very healthy and we can't spend money fast enough to service all of the demand that we have." (우리는 매주 은행 잔고가 훨씬 더 늘어난 채로 끝난다. 사업은 매우 건강하고, 우리가 가진 수요를 다 감당할 만큼 빨리 돈을 쓸 수가 없다.)

"I wouldn't say that open source model improvements cannibalize our core business because data is most valuable on the frontier of model performance." (오픈소스 모델의 발전이 우리 핵심 사업을 잠식한다고 보지 않는다. 데이터는 모델 성능의 프론티어에서 가장 가치가 크기 때문이다.)

"We think that's just not even captured in these calculations... The market for data to support those use cases is growing." (그런 건 이 계산에 아예 잡히지도 않는다고 본다... 그런 유스케이스를 뒷받침하는 데이터 시장은 계속 성장하고 있다.)

"I was very careful never to delegate judgment or decision-making to models... you have to be paranoid with them still. You still have to double-check everything." (나는 판단이나 의사결정을 절대 모델에 위임하지 않도록 매우 조심했다... 여전히 그것들에 대해 편집증적이어야 한다. 여전히 모든 것을 다시 확인해야 한다.)

"Don't delegate your decision-making, like your actual job, to a model because you're going to lose that ability and then you're going to get psychosis." (당신의 실제 업무인 의사결정을 모델에 위임하지 말라. 그 능력을 잃게 되고, 결국 정신적으로 무너지게 된다.)

"As long as Mercor's winning [it's a totally healthy thing to happen]." (Mercor가 이기고 있는 한, [이런 경쟁 압력이 생기는 것은] 완전히 건강한 일이다.)

"It doesn't scale though... vendors, our customers, know this that it won't scale when you want to 10x the throughput, 10x the amount of projects." (하지만 그건 확장이 안 된다... 우리 고객들도 처리량을 10배, 프로젝트 수를 10배로 늘리려 할 때 확장되지 않는다는 걸 알고 있다.)

"We're culturally we're a startup. We're paranoid, we're in office all the time, we're fast moving. We want to hold on to that as long as possible." (우리는 문화적으로는 여전히 스타트업이다. 편집증적이고, 항상 사무실에 있고, 빠르게 움직인다. 우리는 이걸 최대한 오래 유지하고 싶다.)

핵심 데이터 & 수치

• Apex 벤치마크 장기 과업 처리율: 최고 모델 기준 약 50% (통념상 "90% 자동화"보다 훨씬 낮음)
• 세일즈포스의 Anthropic 지출: 연 3억 달러, 이는 평균 개발자 급여의 약 **3.8%**에 해당 — 게스트는 이 비중이 거시적으로 3%보다 더 커질 것으로 전망
• Mercor CEO 브렌든 푸디의 발언(진행자 인용): AI 지출 비중이 결국 **100%**에 도달할 것이며, Mercor는 이미 급여보다 AI 지출이 더 많다고 언급 — 게스트도 이를 확인
• Mercor 인원 규모: 게스트 합류 이후 헤드카운트 10배 이상 증가, 현재 약 500명 규모
• 팀 구조: 제품 영역당 PM 2~3명 + 데이터 사이언티스트 + 디자이너로 구성된 4~5인 "포드(pod)" 단위
• 채용 기준: 커리어 전성기(prime)로 보는 연령대는 25~35세
• 웨이모 vs 자율주행 발전 타임라인: 10년 전 크루즈는 항상 사람이 탑승했지만, 현재는 웨이모를 우버보다 더 자주 이용하는 수준까지 발전(단, SF·오스틴·피닉스 등 일부 지역에 한정)
• 오프사이트 사례: 캐나다 토피노(Tofino)에서 애노테이션팀 전체 서핑 레슨 + 플로팅 사우나 오프사이트 진행

결론 및 시사점

1. 오픈소스 확산은 위협이 아니라 "바닥을 높이는" 요인이다 — 데이터 비즈니스는 항상 "모델이 아직 못하는 것"을 쫓아가므로, 오픈소스가 발전할수록 오히려 새로운 공백이 계속 생겨난다.
2. "엔터프라이즈 업무 X%가 AI로 대체됐다"는 통계는 항상 액면 그대로 믿지 말 것 — 이는 기존에 시도되던 작업만 반영한 수치이며, 아직 아무도 시도하지 않은 잠재 수요(long-horizon task 등)는 빠져 있다.
3. AI 지출을 코스트센터로만 보지 말고, 성장 지출인지 비용인지 구분해서 판단하라 — 엔지니어 생산성처럼 복리 효과가 있는 지출과, 고객서비스처럼 명확한 단위 경제가 필요한 지출은 다르게 다뤄야 한다.
4. AI 시대의 좋은 PM은 "무엇을 만들지"보다 "무엇을 안 만들지, 무엇을 단순화할지"를 더 많이 고민해야 한다 — 엔지니어링 병목이 사라지면 판단력과 비즈니스 임팩트 이해가 새로운 차별화 포인트가 된다.
5. AI 도구를 쓰더라도 실제 의사결정·판단력은 절대 위임하지 말 것 — 이는 조직 문화와 개인 역량 모두에 적용되는 원칙이며, 장기적으로 이 근육을 잃으면 회복이 어렵다.
6. 매출 집중 리스크는 다운마켓 확장으로 해소한다 — 소수의 대형 고객(프론티어 랩)에 의존하는 비즈니스라면, 셀프서브·AI 자동화를 통해 훨씬 많은 수의 중소형 고객으로 저변을 넓히는 전략이 유효하다.
7. RL 환경(environments)과 로보틱스는 다음 데이터 프론티어다 — 특히 로보틱스는 자율주행차의 발전 궤적(느리지만 꾸준한 확장)을 따라갈 가능성이 높으며, 3년 뒤를 내다본다면 지금부터 준비할 가치가 있는 영역이다.