측정할 수 없는 AI 에이전트는 관리할 수도 없습니다: 마우스파워의 가치 측정법

URL: https://www.youtube.com/watch?v=PZZ4aNF-O2E
날짜: 2026-09-12
채널: Tech Bridge
발표자: Maximillian Piros (Max Millian Piros), Yutori 창립 디자이너
영상 길이: 약 20분 25초

---

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

==AI 에이전트를 많이 실행하는 것만으로는 가치가 증명되지 않는다. 에이전트가 쓴 토큰을 실제 결과와 연결하고, 고객이 결과의 품질을 빠르게 검증할 수 있는 측정 멘탈 모델까지 제공해야 한다.==

• 에이전트는 병렬로 여러 개를 띄울 수 있지만, 사용자는 곧 토큰 청구서와 검증 병목을 만난다.
• 토큰(token)은 시스템 내부의 투입량 또는 출력량일 뿐이며, 해결한 버그·종료한 지원 요청·달성한 목표 같은 결과(outcome)와 연결돼야 ROI가 된다.
• James Watt가 말 방아(horse gin)를 기준으로 증기기관의 효율을 설명하기 위해 horsepower를 만든 것처럼, 에이전트 시대에도 사람의 기존 멘탈 모델에 닿는 가치 기준이 필요하다.
• mousepower는 실제 커서 이동량을 재는 표준 단위가 아니라, 에이전트가 일을 잘했다는 것을 검증하는 평가 기준(rubric)을 함께 설계해야 한다는 사고 실험이다.
• 작업 수행 단계의 불확실성과 결과 수용 기준의 불확실성을 함께 보면, 스크립트보다 에이전트가 적합하면서도 실행보다 검증이 쉬운 ‘스위트 스팟’을 찾을 수 있다.

에이전트의 도입을 가로막는 문제는 모델의 능력만이 아니다. 무엇을 시켰는지, 얼마나 많은 토큰을 썼는지, 결과가 실제 목적에 얼마나 기여했는지, 그 결과를 사람이 얼마나 저렴하게 확인할 수 있는지가 한 묶음으로 측정되지 않는 것이 핵심 문제다. 따라서 에이전트를 만드는 사람은 실행 에이전트뿐 아니라 결과를 평가하는 방법, 필요하다면 결과를 평가하는 에이전트까지 설계해야 한다.

1. 병렬 에이전트의 매력과 비용

에이전트는 주의력을 빼앗지 않고 주변 작업을 병렬 처리하게 해주지만, 병렬성은 곧바로 가치로 환산되지 않는다.

1.1. 발표의 출발점과 일상적인 에이전트 사용

1. World's Fair에서 시작한 문제 제기

   1. 발표자의 인사: Max Millian Piros는 시간을 내준 청중에게 감사하고 World's Fair에서 이야기할 수 있어 영광이라고 말한다.
   2. 발표 목표: 청중에게 가치 있는 통찰을 주고 시간을 아깝지 않게 만들겠다고 약속하며, 주제를 ‘mouse power’와 ‘멘탈 모델을 통한 에이전트 측정’으로 제시한다.

2. 능동적 주의와 주변 작업의 분리

   1. 주의력의 본업: 발표처럼 능동적인 주의(active attention)가 필요한 한 가지 일에 집중하면서도 주변 작업(peripheral tasks)은 진척시키고 싶어 한다.
   2. 배경 실행: 발표자는 자신의 슬라이드가 조금 더 다듬어져야 한다고 판단하고, 본인은 발표에 집중하는 동안 에이전트가 디자인 탐색을 배경에서 진행하게 한다.
   3. 이미 준비된 조건: 디자인 시스템(design system)을 이미 마련했고 에이전트에 줄 가이드도 준비했기 때문에, 에이전트는 백지에서 헤매지 않고 정해진 시각 언어 안에서 작업할 수 있다.

1.2. 슬라이드 탐색에서 청구서까지

1. 병렬 디자인 탐색

   1. 탐색 대상: 에이전트에게 타이포그래피 처리(type treatment)와 레이아웃의 여러 방향을 시도하게 한다.
   2. 여러 결과의 필요성: 한 에이전트만으로는 충분하지 않다고 보고, 가능한 한 많은 탐색 결과를 얻기 위해 여러 에이전트를 동시에 시작한다.
   3. 시간 압박: 처리해야 할 슬라이드가 많고 발표 마감 시간이 다가오기 때문에, 모든 에이전트가 각기 다른 방향으로 계속 탐색하기를 기대한다.
   4. 기대와 한계: 흥미로운 결과가 슬라이드를 개선해주기를 바라지만, 발표라는 데드라인 때문에 에이전트가 빨리 작업을 끝내야 한다.

2. 병렬성이 주는 즉각적인 효용

   1. 시간 극대화: 주된 초점이 한 가지에 묶여 있을 때 다른 에이전트를 병렬로 띄우면 조사와 디자인 탐색의 양을 늘릴 수 있다.
   2. 철저함의 유혹: 더 많은 연구와 탐색을 병렬로 수행하면 더 철저해질 것처럼 느껴지므로, 에이전트를 가능한 한 많이 켜게 된다.
   3. 익숙한 작업 방식: 이 방식은 에이전트를 활용하는 사람이라면 익숙할 만한 일상적인 워크플로로 제시된다.

3. 청구서가 바꾸는 질문

   1. 즐거움의 종료: 여러 에이전트를 띄우는 일은 청구서를 받기 전까지는 재미있다.
   2. 가치 재검토: 청구서가 도착하면 ‘그만한 가치가 있었는가?’라는 질문이 생긴다.
   3. 효율성 점검: 너무 강하게 vibe coding을 한 것은 아닌지, token maxing을 과하게 한 것은 아닌지, 에이전트 실행 순서를 더 효율적으로 설계할 수 있었는지 되묻게 된다.
   4. 발표의 본론: 이 질문이 토큰 비용(token cost)을 어떻게 평가하고, 고객이 그 비용의 가치를 어떻게 판단하도록 도울 것인가라는 본론으로 이어진다.

2. Yutori와 컴퓨터 사용 모델

API나 MCP로 접근할 수 없는 정보와 작업을 위해 컴퓨터를 직접 조작하는 모델이 등장했지만, 그 유용성도 결과와 비용을 설명할 수 있어야 한다.

2.1. Yutori에서 다루는 computer-use 모델

1. 회사와 역할

   1. 근무 기간: 발표자는 지난 1년 반 동안 Yutori의 창립 디자이너(founding designer)로 일해왔다.
   2. 제품 초점: Yutori는 computer-use model, 즉 사람이 하듯 컴퓨터를 사용하는 법을 학습하는 모델에 집중한다.
   3. 디자이너의 질문: 창립 디자이너로서 고객과 대화하고, 고객이 에이전트를 최대한 직관적으로 사용하도록 만드는 방법을 탐색한다.

2. API와 MCP의 바깥을 다루는 방식

   1. 접근 가능한 경우: 필요한 정보를 API나 MCP(Model Context Protocol)로 얻을 수 있다면 그 방식이 일반적으로 더 효율적이다.
   2. 접근 불가능한 경우: API나 MCP에서 정보를 가져올 수 없다면 사람이 하듯 컴퓨터를 사용하도록 에이전트를 보내는 방법이 있다.
   3. 얻는 결과: 에이전트는 기존에는 접근할 수 없었던 정보를 추출하고, 그 정보를 여러 방식으로 조작할 수 있게 한다.
   4. 효율성의 위치: computer-use는 API와 MCP보다 분명히 덜 효율적이지만, 다른 방법이 없을 때 컴퓨터를 직접 사용하게 하는 최후의 수단(last resort)으로 기능한다.

3. 자기 자신을 평가하는 에이전트

   1. 시연 장면: Yutori 에이전트가 Yutori 웹사이트를 사용하면서 자신의 benchmark를 확인한다.
   2. 자기 감탄의 농담: 에이전트가 자기 자신의 성능 평가를 들여다보는 모습이어서, 발표자는 이것을 에이전트가 스스로를 감탄하며 바라보는 것처럼 표현한다.
   3. 기묘함: 에이전트가 자기 benchmark를 검사하는 장면은 약간 이상하고 어색한 상황이라는 농담으로 처리된다.

2.2. 고객이 아직 발견하지 못한 에이전트의 사용법

1. 고객 멘탈 모델 파악

   1. 직관성의 목표: 고객이 에이전트를 어떻게 이해하고 무엇에 쓰려 하는지를 파악해야 제품을 직관적으로 만들 수 있다.
   2. 가치 판단 방식: 고객이 특정 사용 사례(use case)에 에이전트를 보낼 때 어떤 멘탈 모델로 가치를 계산하는지 이해해야 한다.
   3. 반복되는 질문: 고객 대화는 ‘에이전트를 가장 잘 쓰는 방법은 무엇인가?’, ‘에이전트에 가장 적합한 사용 사례는 무엇인가?’, ‘토큰 비용과 가치의 트레이드오프를 어떻게 생각해야 하는가?’로 자주 수렴한다.

2. 얼마나 익숙해졌는가

   1. 표면만 긁는 느낌: 많은 사람이 에이전트에 흥미를 느끼지만, 아직은 에이전트의 표면만 긁고 있을 뿐이라는 표현을 자주 쓴다.
   2. 직관성의 부족: 에이전트를 어디에 보내야 최선인지, 어떤 일을 맡겨야 하는지가 아직 충분히 직관적이지 않다.
   3. 새로운 근육: 에이전트의 사용법과 비용 대비 가치를 판단하는 능력은 현재 업계가 함께 길러가는 근육에 가깝다.

3. 에이전트의 측정 문제와 얼리어답터 편향

현재 에이전트를 능숙하게 측정하는 사람들의 경험은 아직 에이전트를 써보지 않은 대다수 사용자의 경험을 대표하지 않는다.

3.1. ‘측정 문제’라는 논지

1. 핵심 테제

   1. 측정의 부족: 에이전트에는 measurement problem, 즉 측정 문제가 있다.
   2. 현장의 장면: 발표자는 여러 에이전트를 측정하려고 일하는 자신의 사진을 보여주며, 동료가 그 사진을 보고 영화나 시트콤의 ‘Pepe Silvia의 미스터리’를 풀려는 사람처럼 보인다고 했던 일화를 소개한다.
   3. 난이도의 강조: 사진 속 복잡한 모습은 에이전트를 측정하는 일이 결코 쉽지 않다는 점을 시각적인 농담으로 보여준다.

2. 반론에 대한 인정

   1. 능숙한 청중의 반론: 일부 청중은 이미 에이전트 fleet을 운영하며 다음 백만 달러짜리 앱을 만들고 있고, 에이전트를 아주 잘 측정하고 있다고 말할 수 있다.
   2. 발표자의 동의: 발표자는 그 반론에 동의한다. 현재 방 안의 많은 사람은 실제로 에이전트를 잘 측정할 수 있다.
   3. 동의의 한계: 그러나 그 경험이 앞으로 에이전트를 도입할 모든 사람을 대표하는 것은 아니다.

3.2. Upton Sinclair가 상기시키는 편향

1. 얼리어답터라는 위치

   1. 편향된 표본: 청중은 얼리어답터(early adopter)이고 새 기술을 탐색하는 데 큰 흥미를 느끼는 사람들이다.
   2. 대표성의 문제: 자신들이 에이전트를 잘 측정한다는 사실은 에이전트를 도입하게 될 일반 사용자들이 같은 방식으로 측정할 수 있다는 뜻이 아니다.
   3. 토큰 판매의 관점: 에이전트 제품을 만드는 사람은 직간접적으로 결국 토큰을 팔고 있다. 따라서 자신의 토큰 사용량이 아직 에이전트를 한 번도 만져보지 않은 사람들의 사용량을 대표하는지 물어야 한다.

2. 현실의 사용자와 가족의 사례

   1. 기존 습관: 세상에는 아직도 ChatGPT에 내용을 복사하고 붙여넣는 방식으로만 사용하는 사람이 많다.
   2. 가까운 사례: 발표자의 배우자도 그런 사람 중 하나일 수 있다. 발표자가 아무리 에이전트를 써보라고 권해도, 배우자는 아직 에이전트 설정을 맡기지 않았다.
   3. 시사점: 에이전트에 열광하는 사람들의 병렬 실행 경험과, 복사·붙여넣기에 머무는 사람 사이에는 큰 채택 장벽이 있다.

3. Upton Sinclair의 인용이 하는 일

   1. 인용의 목적: 발표자는 Upton Sinclair의 유명한 경구를 의무적으로 상기해야 한다고 말한다.
   2. 핵심 의미: 사람은 자신이 이미 믿고 있는 방식과 이해관계의 영향을 받으므로, 에이전트에 익숙한 청중이 느끼는 가치 판단을 보편적인 기준으로 착각해서는 안 된다.
   3. 채택 관점: 전 세계의 잠재 고객에게도 병렬 에이전트의 흥분과 가치를 전달하려면, 얼리어답터의 경험을 넘어서는 측정 기준이 필요하다.

4. James Watt와 horsepower의 교훈

새 기술을 팔려면 기술 자체의 우수성보다 고객이 이미 가진 멘탈 모델에 연결되는 비교 기준과 ROI가 필요하다.

4.1. 1700년대의 증기기관과 말 방아

1. 새 기술의 오래된 문제

   1. 역사의 반복: 새 기술이 등장했지만 그것을 전달하는 올바른 방법을 아직 찾지 못하는 문제는 오래된 기술 산업의 문제다.
   2. 참고할 역사: 발표자는 1700년대로 돌아가 James Watt가 증기기관을 판매하려 했던 상황을 살펴본다.
   3. 인지 부조화: 사람들에게 익숙한 세계와 차갑고 위협적으로 보이는 기계 사이에는 cognitive dissonance, 즉 인지 부조화가 생긴다.

2. 말 방아(horse gin)의 실제 사용

   1. 당시의 동력원: 당시에는 말 방아가 제분소(mill)의 동력원이었다.
   2. 양조장의 예시: 양조장에서 보리(barley)를 갈려면 동력원이 필요했고, 발표자는 자신이 양조 전문가가 아니라 정확한 제조 과정은 모른다고 농담하면서도 동력의 작동 방식을 설명한다.
   3. 회전 운동: 말은 회전하는 팔(rotary arm)에 연결되고, 원을 그리며 걸었다.
   4. 동력 생성: 말이 원을 따라 걸으면 회전 팔이 움직이고, 그 회전이 보리를 갈거나 다른 기계를 작동시킬 힘을 만들었다.
   5. 현대와의 거리: 오늘날에는 말이 동력원이라는 방식이 이상하게 보이지만 당시에는 일상적인 방식이었다.

4.2. Horsepower가 만든 비교 가능성

1. 증기기관이 부딪힌 장벽

   1. 기계의 효율: Watt는 말이 매우 효율적인 기계라는 점을 인정하면서도, 증기기관이 말보다 나은 동력원이 될 수 있다고 보았다.
   2. 차가운 기계의 인상: 말에 익숙한 사람에게 증기기관은 차갑고 무섭고 이해하기 어려운 기계였다.
   3. 비전의 부재: 누군가 증기기관이 모든 문제를 해결한다고 말해도, 고객은 아직 그 장면을 머릿속으로 볼 수 없었다.

2. 기존 멘탈 모델 연구

   1. 고객의 기준 파악: Watt는 증기기관을 설명하기 전에 사람들이 ‘말’의 관점에서 동력을 생각한다는 사실을 이해해야 했다.
   2. 말 방아 연구: 그는 말 방아를 직접 연구하고, 작동 역학과 평균 성능을 대략적인 실측으로 파악했다.
   3. 기준의 발명: 그 결과 말의 동력과 증기기관의 동력을 비교할 수 있는 horsepower라는 지표가 만들어졌다.

3. 부정확하지만 작동한 지표

   1. 과학적 완벽성의 부재: 당시 horsepower는 매우 과학적인 측정이 아니었고, 정확하지 않았다고 볼 수 있다.
   2. 가치 증가의 전달: 그럼에도 지표는 증기기관이 기존 말 방아보다 얼마나 큰 효율 배수를 제공하는지 보여주는 기준이 됐다.
   3. 익숙한 언어: 말에 익숙한 사람은 자신의 기존 기준으로 증기기관의 개선 폭을 가늠할 수 있었다.
   4. 채택 임계값: horsepower가 실제 사용 결과를 완벽하게 예측한 것은 아니지만, 최소한 증기기관을 한 번 시도해보게 만드는 채택 임계값을 넘기는 데 기여했다.

4. 효율과 감정의 동시 설득

   1. 말의 ‘분위기’: 발표자는 증기기관이 아무리 효율적이어도 말은 ‘vibe’가 훌륭하다는 농담을 한다.
   2. 감정의 장벽: 기술의 효율만 제시해서는 사람들이 정서적으로 좋아하는 기존 대상을 넘기 어렵다.
   3. ROI의 역할: horsepower는 효율 수치인 동시에, 감정적인 애착을 잠시 제쳐두고 투자수익률(ROI)을 계산하게 해주는 언어였다.

5. 토큰 비용에서 성과 ROI로

토큰 사용량을 줄이거나 늘리는 최적화만으로는 고객 가치를 설명할 수 없으며, 지출이 어떤 결과를 만들었는지 추적해야 한다.

5.1. 측정되지 않는 기술 투자의 문제

1. 명확한 ROI의 필요성

   1. 가치 전달 조건: 고객에게 유형적이고 만질 수 있는 ROI(tangible ROI)를 제시하지 못하면 기술의 가치를 전달하기 어렵다.
   2. 업계 전체의 문제: AI 업계뿐 아니라 기술 산업 전반에서도 좋은 ROI를 계산하지 못하는 사례가 많다.
   3. 스마트함과 측정 능력의 분리: AI에 아직 깊이 빠지지 않은 엔지니어도 이론적으로는 똑똑하고 비용을 계산할 능력이 있지만, 실제 조직의 인센티브가 그 계산과 맞지 않을 수 있다.

2. 토큰 예산과 리더보드

   1. 예산의 조기 소진: 어떤 사람들은 1년 동안 사용할 토큰 예산을 한 분기 만에 모두 써버린다.
   2. 토큰 리더보드: 누가 더 많은 토큰을 사용했는지를 보여주는 토큰 리더보드 같은 현상도 나타난다.
   3. 엇갈린 동기: 이런 현상은 토큰을 많이 쓴 것이 좋은 결과를 만들었다는 증거가 아닌데도, 사용량이 성과처럼 취급되고 있음을 보여준다.

5.2. ‘과소비와 활용 부족’의 doom loop

1. Ramp에서 빌린 개념

   1. 용어의 출처: 발표자는 Ramp의 훌륭한 블로그 글에서 overspending and underusing, 즉 과도한 지출과 낮은 활용의 악순환이라는 표현을 빌린다.
   2. 현재의 위치: 에이전트 사용은 높은 비용과 낮은 활용이 서로를 강화하는 doom loop에 놓여 있다.

2. 악순환의 단계

   1. 과잉 실행: 사용자는 토큰을 최대한 많이 쓰는 token maxing에 빠진다.
   2. 긴축으로의 반동: 청구서가 커지면 사용자는 자신을 토큰 긴축(austerity)으로 몰아간다.
   3. 사용 중단: 결국 에이전트를 충분히 활용하지 못한 채 루프에서 이탈한다.
   4. FOMO에 의한 재진입: 새로운 FOMO가 생길 정도로 자극을 받을 때까지 기다렸다가 다시 에이전트를 시도한다.
   5. 루프의 원인: 비용 대비 성과를 설명하는 측정 기준이 없기 때문에 과소비와 과소사용 사이를 오간다.

3. 루프를 끊는 방법

   1. 가치의 측정: 이 악순환을 끊으려면 에이전트가 만든 가치의 더 나은 측정값이 필요하다.
   2. 채택까지 고려: 측정값은 실제 결과를 설명해야 할 뿐 아니라, 처음 에이전트를 시도해보려는 사람의 진입장벽도 낮춰야 한다.

5.3. 토큰과 결과를 연결하기

1. Coinbase의 모델 기본값 실험

   1. 사례의 출처: Coinbase CEO가 X에 공유한 차트가 소개된다.
   2. 기본 모델 변경: Coinbase는 내부적으로 처음 시작할 모델의 기본값을 바꾸기 시작했다.
   3. 난이도별 모델 배정: 가장 어려운 작업에만 frontier model을 아껴 쓰고, 쉬운 작업은 더 저렴한 모델로 시작했다.
   4. 관찰된 변화: 그 결과 AI 지출(AI spend)이 토큰 사용량(token usage)과 서로 다른 방향으로 움직이기 시작했다.
   5. 의미: 토큰을 줄이는 것과 비용을 줄이거나 가치를 높이는 것은 같지 않으며, 모델 선택 전략만으로도 두 지표를 분리할 수 있다.

2. 토큰은 내부 시스템의 출력이다

   1. 쓸모 있는 내부 지표: 토큰은 내부 시스템을 측정하는 데 유용하다.
   2. 최종 목적이 아님: 하지만 토큰은 결국 출력(output)일 뿐이며, 고객이 진짜로 원하는 결과 자체가 아니다.
   3. 필요한 추적: 토큰을 목표와 연결해 토큰 사용이 실제 진척으로 이어지는지를 깨끗하게 추적해야 한다.

3. 결과 기반 질문

   1. 개발 결과: 구매한 토큰으로 버그를 몇 개 해결했는가를 물어야 한다.
   2. 지원 결과: 토큰 사용으로 고객 지원 요청(support request)을 몇 건 종료했는가를 물어야 한다.
   3. 목표 진척: 조직의 목표(objectives)에 대해 토큰이 얼마나 진척을 만들었는지 연결해야 한다.
   4. ROI의 조건: 결과를 깨끗하게 정의하고 토큰 지출을 그 결과에 명확히 연결하지 않으면 ROI를 계산하기 어렵다.

6. 코드 생성 이후에 드러난 검증 병목

에이전트가 코드를 빠르게 생산할수록 사람이 결과를 검토하는 속도가 따라가지 못해, 효율성의 병목이 실행에서 검증으로 이동한다.

6.1. ‘천 번의 pull request’ 문제

1. 에이전트 코딩의 체감 효율

   1. 능력의 증가: 에이전트와 코딩하면 능력과 효율이 증가하는 느낌이 분명히 있다.
   2. 잔여 문제: 그러나 많은 사람이 ‘천 번의 pull request에 죽어가는(dying by thousand pull requests)’ 상황을 겪는다. ASR의 ‘poll requests’ 표현은 문맥상 pull requests로 보정한다.
   3. 생산과 검토의 비대칭: 코드를 만들어내는 속도는 올라갔지만, 그 코드가 좋은지 확인하는 속도는 같은 비율로 올라가지 않았다.

2. Anthropic 사례

   1. 강한 주장: Anthropic 팀의 일부 인원은 코딩 문제를 해결했다고 주장한 적이 있다.
   2. 남은 미해결 문제: 그러나 Anthropic조차 code review, 즉 코드 리뷰 문제는 해결하지 못했다고 인정했다.
   3. 병목 이동: 생성이 빨라지자 병목은 인간 리뷰로 이동했고, 코딩 에이전트의 효율성은 실제 조직 성과로 아직 충분히 나타나지 않는다.

6.2. 코드 리뷰의 전제와 평가 기준

1. 검증 속도의 한계

   1. 사람의 재작업: 코드 생성량이 늘어날수록 사람은 생성된 코드를 읽고, 이해하고, 오류를 확인해야 한다.
   2. 속도의 불일치: 생성 속도와 같은 속도로 검증을 확장하지 못하면, 생성한 코드의 상당 부분이 실제로 좋은지 판단할 수 없다.
   3. 지출 정당화의 실패: 코드가 많이 생겼다는 사실만으로 토큰 지출이 정당화되지는 않는다.

2. Noah Hine의 문제 제기

   1. 기존 코드 리뷰의 결함: 코드 리뷰는 에이전트가 등장하기 전부터 완벽하지 않았을 수 있다.
   2. 에이전트가 드러낸 것: 에이전트는 기존 관행의 표면을 덮고 있던 진짜 검증 문제를 드러냈다.
   3. 재검토할 전제: Noah Hine이 코드 리뷰를 해결하는 방법에 관한 글에서 지적하듯, 코드 리뷰 밑에 깔린 가정(assumptions)을 다시 살펴야 한다.
   4. 선입견 점검: 에이전트 시대에는 코드 리뷰의 기준과 방법에 관한 기존 priors를 확인하고 새 근거를 세워야 한다.

3. 발표의 범위 제한

   1. 해법 자체는 별도 주제: 발표자는 코드 리뷰를 어떻게 해결할지는 이 자리에서 다루지 않는다.
   2. 다른 발표에 적합: 그 문제는 다른 사람이 별도 발표로 다루는 편이 낫고, 현재 발표의 주제와도 완전히 다르다.
   3. 이번 논점: 대신 코드 리뷰가 왜 해결 가능한 문제처럼 느껴지는지에 초점을 맞춘다.

6.3. 공유된 가정과 compute 속도의 측정

1. 코드 리뷰가 가능해 보이는 이유

   1. 문화적 수렴: 개발 문화는 코드 리뷰를 둘러싼 공유 가정(shared assumptions)에 상당히 수렴해 있다.
   2. 공통 루브릭: 모두가 비슷한 측정 기준과 품질 루브릭(rubric)에 동의하면 결과를 일정한 방식으로 평가할 수 있다.
   3. 규모화의 조건: 측정 기준에 대한 합의가 있기 때문에 코드 리뷰는 조직 규모가 커져도 어느 정도 확장 가능한 일처럼 느껴진다.

2. 에이전트 시대의 과제

   1. 가정의 적응: 해야 할 일은 코드 리뷰의 모든 전제를 그대로 유지하는 것이 아니라 agentic age에 맞게 가정을 적응시키는 것이다.
   2. 실행과 측정의 균형: 에이전트를 compute 속도로 실행하는 데 성공했다면, 측정과 검증도 compute 속도로 수행할 방법을 찾아야 한다.
   3. 명확한 ROI: 실행만 빠르게 만들고 검증 방법을 제공하지 않으면 고객은 지출을 정당화할 수 없다.

7. Mousepower라는 사고 실험

mousepower는 horsepower처럼 계산 가능한 실제 단위를 만들겠다는 제안이 아니라, 에이전트의 결과를 검증할 수 있는 고객별 루브릭을 함께 제공하자는 이름이다.

7.1. 에이전트용 horsepower를 찾기

1. 기존 컴퓨터 사용을 기준으로 삼기

   1. 사람의 기준선: James Watt가 말 방아를 기준으로 삼았듯이, 컴퓨터를 사용하는 현재 사람의 작업 방식을 기준선(baseline)으로 볼 수 있다.
   2. 상대적 성능: 그 기준선과 비교해 에이전트가 특정 작업에서 얼마나 더 나은지, 또는 어떤 성능 벡터에서 더 뛰어난지를 보여줄 수 있다.
   3. 고객의 번역 언어: 고객이 이미 알고 있는 컴퓨터 작업과 비교하면, 에이전트의 성능 증가를 낯선 토큰 숫자보다 이해하기 쉽게 전달할 수 있다.

2. Mousepower의 이름

   1. 시대의 대응물: horsepower가 말의 힘을 기준으로 증기기관의 효율을 전달했다면, mousepower는 컴퓨터를 사용하는 사람의 기준에 대응하는 에이전트 가치의 이름이다.
   2. 핵심 질문: 에이전트를 판매하는 사람은 에이전트를 만드는 데서 끝나지 말고, 고객이 ‘이 토큰이 그만한 가치가 있었다’고 판단할 방법도 만들어야 한다.
   3. 루브릭의 역할: 고객이 결과가 좋은지 실제로 확인할 수 있는 평가 기준이 mousepower의 실질적인 내용이다.

7.2. 커서 측정 장치 농담과 한계

1. 문자 그대로 측정하려는 시도

   1. 직관적인 발상: 마우스파워를 정말로 재려면 커서가 화면에서 얼마나 이동했는지, 사람이 하는 것보다 에이전트가 얼마나 빨리 움직였는지를 측정할 수 있을 것처럼 보인다.
   2. 실제 시도: 발표자는 Claude에게 vibe coding으로 이런 측정 장치를 만들어보라고 했다.
   3. 가설: 화면을 가로지르는 잠재적인 커서 움직임과 이동 속도의 차이를 측정하면, 깔끔한 mousepower 수치가 나올 것이라고 생각했다.

2. 왜 실패하는가

   1. 측정의 불충분함: 커서 이동량과 속도는 에이전트 작업의 가치 전체를 대변하지 않는다.
   2. 고차원 정보 공간: 작업이 다루는 정보 공간(information space)은 너무 고차원적이어서, 화면 위의 마우스 움직임 하나로 성능을 환원할 수 없다.
   3. 문자 그대로의 단위 불가능성: 따라서 mousepower가 실제로 통용되는 측정 단위가 될 가능성은 없으며, 화면 이동량을 재는 일은 어리석은 시도에 가깝다.
   4. 농담의 정리: Claude에게 만든 측정 장치를 이야기한 부분은 문자 그대로의 지표 제안이 아니라 발표자 자신도 그 한계를 알고 있다는 농담이다.

3. 비유로서의 Mousepower

   1. metric이 아닌 idea: mousepower는 앞으로 모든 에이전트를 같은 숫자로 평가하는 metric이 아니라 아이디어다.
   2. 판매와 검증의 결합: 에이전트를 판매할 때는 그 에이전트가 잘 일하는지 확인할 수 있는 rubric을 함께 판매해야 한다.
   3. 가치 판단의 연결: 그 루브릭이 토큰 비용과 실제 성과를 연결하고, 고객이 지출을 납득하게 만든다.
   4. 정답의 부재: 발표자는 모든 종류의 에이전트에 맞는 정답 프레임워크를 갖고 있지 않으며, 각자 자신이 만드는 에이전트에 맞는 측정 방법을 찾아야 한다고 인정한다.

8. 엔트로피 매트릭스로 작업을 고르는 법

에이전트를 만들 작업은 가치만으로 고르지 말고, 수행 과정의 불확실성과 결과를 받아들일 기준의 불확실성을 함께 평가해야 한다.

8.1. 정보이론에서 출발한 사고

1. Claude Shannon의 entropy

   1. 엔트로피의 뜻: 정보이론에서 entropy는 확률분포의 불확실성(uncertainty)을 측정하는 개념이다.
   2. 모델 학습과의 연결: cross-entropy 같은 개념은 오늘날 에이전트 학습에서 모델이 얼마나 유능한지를 결정하는 중요한 요소다.
   3. 확장된 질문: 엔트로피를 에이전트의 성능에만 적용하지 말고, 에이전트에게 시킬 task 자체의 불확실성을 생각하는 데도 사용할 수 있다.

2. 두 축의 매트릭스

   1. 가로축: 작업을 수행하는 데 필요한 단계(step)의 불확실성을 놓는다.
   2. 세로축 또는 다른 축: 에이전트 결과를 수용할 acceptance criteria, 즉 합격 기준 자체의 불확실성을 놓는다.
   3. 선정 원칙: 가치가 있어 보이는 작업이라는 이유만으로 에이전트를 만들지 말고, 두 축에서 작업이 어디에 놓이는지를 먼저 검토한다.

8.2. 수행 단계의 불확실성

1. 낮은 단계 불확실성

   1. 예측 가능한 경로: 작업 단계의 불확실성이 낮으면 목표를 이루는 경로가 매우 예측 가능하다.
   2. 스크립트의 적합성: 이런 작업에 토큰을 쓰며 에이전트를 만들 이유가 적고, 일반적인 스크립트를 작성하는 편이 낫다.
   3. 왼쪽 영역: 발표자의 도식에서 왼쪽은 단계 불확실성이 낮은 영역으로, 스크립트와 에이전트의 경계를 보여준다.

2. 높은 단계 불확실성

   1. 예측 불가능한 정보: 수행 단계의 불확실성이 높으면 에이전트가 마주칠 정보가 매우 예측하기 어렵다.
   2. 분포 밖 위험: 모델의 사전학습(pre-training) 분포 밖에 놓일 위험이 커진다.
   3. 희소한 보상: 강화학습(reinforcement learning)에서 얻을 수 있는 보상(reward)도 희소해질 가능성이 높다.
   4. 에이전트 부적합성: 모델이 데이터를 제대로 모델링하기 어려워질 수 있으므로, 이런 작업은 에이전트에 좋은 대상이 아닐 수 있다.
   5. 오른쪽 영역: 도식의 오른쪽은 단계 불확실성이 높은 영역이다. 발표자는 좌우를 설명하다가 ‘왼쪽은 여러분의 왼쪽이기도 하다’는 식으로 앞선 발표자도 방향을 헷갈렸다는 농담을 덧붙인다.

3. 중간 단계 불확실성

   1. 흥미로운 난이도: 중간 영역의 작업은 단순히 스크립트로 끝날 만큼 결정적이지도 않고, 학습 분포 밖으로 튈 만큼 무작위적이지도 않다.
   2. 모델이 탐색할 여지: 에이전트가 탐색하고 판단할 정도의 불확실성이 있어 에이전트 사용의 의미가 생긴다.
   3. 첫 번째 조건: 이 중간 영역은 에이전트가 실제로 유용할 수 있는 후보 영역이 된다.

8.3. 수용 기준의 불확실성

1. 낮은 수용 기준 불확실성

   1. 검증 가능한 결과: 결과가 좋은지 나쁜지를 비교적 명확한 기준으로 판단할 수 있다.
   2. 검증의 비용: 반복 가능한 검증 절차를 만들 수 있으면 에이전트의 결과를 빠르게 평가할 수 있다.
   3. 스위트 스팟의 한 축: 단계에는 충분한 불확실성이 있지만 수용 기준은 비교적 명확한 작업이 에이전트의 좋은 후보가 된다.

2. 높은 수용 기준 불확실성

   1. 검증과 실행의 동일화: 무엇이 가치 있는 결과인지 판단하는 기준이 불확실하면, 검증 자체가 실행과 구별되지 않게 된다.
   2. 사람의 재수행: 결과가 유용했는지 확인하려면 사람이 에이전트가 한 일을 거의 다시 수행해야 한다.
   3. 토큰 낭비: 사람이 작업을 다시 할 것이라면 에이전트에 토큰을 쓴 이점이 사라진다.
   4. 에이전트 부적합성: 높은 수용 기준 불확실성은 에이전트를 도입하기에 위험한 영역을 만든다.

8.4. 두 불확실성이 만나는 스위트 스팟

1. 좋은 에이전트 작업의 모양

   1. 너무 결정적이지 않음: 작업 단계가 너무 예측 가능해서 스크립트로 충분한 일은 제외한다.
   2. 분포 밖이 아님: 단계가 너무 불확실해 사전학습과 강화학습이 모두 어려운 일도 제외한다.
   3. 충분히 흥미로움: 적당한 불확실성이 있어 에이전트의 판단과 탐색이 실제 가치를 만들 수 있어야 한다.
   4. 검증은 상대적으로 쉬움: 동시에 결과의 가치를 비교적 반복 가능한 방식으로 확인할 수 있어야 한다.

2. NP-style 문제라는 비유

   1. 검증이 실행보다 쉬운 구조: 이 영역의 작업은 실행하는 것보다 결과를 검증하는 것이 쉬운, NP 문제 같은 모양을 가진다.
   2. 에이전트 투입의 근거: 실행은 어렵지만 검증 패턴이 반복 가능하다면, 실행 자체에 에이전트를 대량으로 투입할 수 있다.
   3. 검증 에이전트: 실행 에이전트만 만드는 것이 아니라, 첫 번째 에이전트의 작업을 검증하는 두 번째 에이전트도 만들 수 있다.
   4. 확장 가능한 품질 관리: 검증 절차가 컴퓨터 속도로 확장되면 실행 속도만 빠른 시스템보다 실제 ROI를 훨씬 명확하게 계산할 수 있다.

3. 프레임워크의 현재 상태

   1. 사고의 출발점: 발표자는 엔트로피 매트릭스를 완성된 방법론이 아니라 생각을 시작하기 위한 thought starter라고 부른다.
   2. 진행 중인 아이디어: 이 개념은 아직 발전 중이며, 발표자도 모든 상황에 적용할 수 있는 완성된 해법이라고 주장하지 않는다.
   3. 청중의 참여: 발표자는 청중의 의견을 듣고 싶다고 말하며, 다음 에이전트를 만들 때 그 에이전트의 mousepower도 함께 찾아보기를 권한다.

주요 발언 모음

“에이전트에는 measurement problem이 있다.”

“토큰은 내부 시스템을 측정하는 데는 유용하지만, 결국 출력일 뿐이다.”

“우리는 토큰을 깨끗하게 결과에 연결해야 한다. 토큰으로 버그를 몇 개 해결했고, 지원 요청을 몇 개 종료했는가?”

“실행을 compute 속도로 할 수 있다면, 측정도 compute 속도로 할 수 있어야 한다.”

“에이전트를 만들 생각이라면, 고객이 그 결과가 좋은지 검증하는 방법도 함께 생각해야 한다.”

“Mousepower는 실제 metric이 되지는 않을 것이다. 그것은 아이디어에 가깝다.”

“에이전트를 만드는 것만으로는 충분하지 않다. 그 에이전트의 작업을 검증하는 에이전트도 만들 수 있다.”

“다음 에이전트를 만들 때 그것의 mousepower도 함께 찾아보기 바란다.”

핵심 데이터 & 수치

• 영상 길이: 약 20분 25초다.
• 발표자의 Yutori 근무 기간: 창립 디자이너로 약 1년 반 동안 computer-use 모델을 다뤘다.
• 역사적 배경: James Watt와 horsepower의 사례는 1700년대의 증기기관 판매 문제에서 출발한다.
• 토큰 예산 사례: 일부 사용자는 1년치로 생각한 토큰 예산을 한 분기 만에 소진한다.
• 엔트로피 매트릭스의 두 축: 작업 수행 단계의 불확실성과 결과 수용 기준의 불확실성이다.
• 작업 분류의 세 영역: 단계 불확실성이 낮으면 스크립트가 적합하고, 너무 높으면 분포 밖·희소 보상 위험이 커지며, 중간 영역이 에이전트의 후보가 된다.
• 검증의 핵심 조건: 실행보다 검증이 쉬워야 에이전트와 검증 에이전트를 함께 확장할 수 있다.

결론 및 시사점

1. 사용량을 성과로 착각하지 말아야 한다: 병렬 실행 수와 토큰 수는 활동량을 보여줄 뿐, 고객 가치나 ROI를 보장하지 않는다.
2. 토큰을 결과에 연결해야 한다: 버그 해결 수, 종료된 지원 요청 수, 조직 목표의 진척처럼 관찰 가능한 outcome을 정하고 토큰 지출과 연결해야 한다.
3. 고객의 기존 기준에서 출발해야 한다: horsepower가 말 방아를 기준으로 증기기관을 설명했듯이, 에이전트도 고객이 이미 이해하는 컴퓨터 작업을 기준으로 성능 증가를 번역해야 한다.
4. 에이전트 채택에는 감정과 계산이 함께 필요하다: 새 기술의 멋짐이나 FOMO만으로는 지속적인 사용을 만들 수 없고, 시도할 가치가 있는지 계산할 수 있어야 한다.
5. 생성보다 검증이 먼저 병목이 된다: 코드 생성 속도가 아무리 빨라도 리뷰와 품질 확인이 따라오지 않으면 실제 생산성은 늘지 않는다.
6. 기존 평가 가정을 다시 설계해야 한다: 에이전트 시대에는 과거의 코드 리뷰와 작업 평가에 깔린 가정을 확인하고, compute 속도에 맞는 공통 루브릭을 다시 만들어야 한다.
7. 작업을 두 불확실성으로 선별해야 한다: 단계가 너무 결정적이면 스크립트를 쓰고, 단계가 너무 불확실하면 모델 분포와 보상 문제를 의심하며, 중간 영역을 우선 탐색한다.
8. 검증이 실행보다 쉬운 작업을 찾아야 한다: 결과의 합격 기준이 반복 가능하면 실행 에이전트와 검증 에이전트를 함께 확장할 수 있다.
9. Mousepower는 제품 기능이 아니라 설계 질문이다: ‘이 에이전트가 얼마나 빨리 움직이는가?’보다 ‘고객은 어떤 근거로 이 결과가 가치 있다고 판단하는가?’를 묻는 이름이다.
10. 에이전트마다 고유한 측정 기준이 필요하다: 모든 정보 공간을 하나의 커서 지표로 환원할 수 없으므로, 작업의 목적과 고객의 멘탈 모델에 맞는 ROI 루브릭을 설계해야 한다.

핵심 요약 (20줄)

1. 병렬 에이전트는 한 가지 일에 집중하면서 주변의 조사와 디자인 탐색을 동시에 진행하게 한다.
2. 여러 에이전트를 켜는 즐거움은 토큰 청구서를 마주하는 순간 비용 대비 가치의 질문으로 바뀐다.
3. Max Millian Piros는 Yutori에서 사람이 컴퓨터를 사용하듯 작동하는 computer-use 모델을 설계해왔다.
4. API나 MCP로 접근할 수 없는 정보는 컴퓨터를 직접 조작하는 에이전트로 다룰 수 있다.
5. 에이전트에 흥미를 느끼는 얼리어답터의 경험은 아직 ChatGPT에 복사·붙여넣기하는 일반 사용자를 대표하지 않는다.
6. 새 기술을 확산하려면 기술의 우수성뿐 아니라 사용자가 이미 가진 멘탈 모델에 닿는 기준이 필요하다.
7. James Watt는 말 방아를 연구해 증기기관의 효율을 horsepower라는 익숙한 비교값으로 번역했다.
8. Horsepower는 당시 과학적으로 완벽하지 않았지만 사람들이 증기기관을 시험할 만큼의 ROI를 상상하게 했다.
9. 에이전트 업계는 토큰을 과도하게 쓰고 곧 긴축으로 물러나는 doom loop에 빠지기 쉽다.
10. Coinbase의 모델 기본값 변경은 frontier model을 어려운 작업에만 쓰며 AI 지출과 토큰 사용량을 분리한 사례다.
11. 토큰은 내부 시스템의 투입량 또는 출력량일 뿐이며 고객이 얻은 최종 성과가 아니다.
12. 토큰 비용은 해결한 버그, 종료한 지원 요청, 목표 진척 같은 결과와 연결돼야 ROI가 된다.
13. 에이전트 코딩이 빨라질수록 인간 코드 리뷰가 병목이 되어 생성 속도의 이익이 검증 단계에서 사라진다.
14. 에이전트 시대에는 코드 리뷰와 품질 평가를 지탱하는 기존 가정을 다시 점검해야 한다.
15. Mousepower는 커서 이동 속도를 재는 단위가 아니라 에이전트 성과를 검증하는 루브릭을 함께 만들자는 비유다.
16. 커서 움직임을 측정하는 Claude 제작 장치는 정보 공간이 너무 고차원적이라는 이유로 가치 측정에 실패한다.
17. 엔트로피 매트릭스는 작업 단계의 불확실성과 결과 수용 기준의 불확실성을 두 축으로 놓는다.
18. 단계가 결정적이면 스크립트가 낫고, 단계가 지나치게 불확실하면 사전학습 분포 밖과 희소 보상 문제가 커진다.
19. 적당히 불확실하면서 수용 기준이 명확한 작업은 실행보다 검증이 쉬운 에이전트 스위트 스팟이 된다.
20. 실행 에이전트와 그 결과를 검증하는 에이전트를 함께 설계해야 토큰 지출을 실제 ROI로 확장할 수 있다.