AI 에이전트를 그만 만들고 AI 직원을 만들어라 — Pedro Franceschi 라이브 데모

URL: https://www.youtube.com/watch?v=LE0LNULrsEM
날짜: 2026-09-15
채널: Peter Yang
출연: Pedro Franceschi(Brex 공동 창립자 겸 CEO)
원문 게시일: 2026-09-13
영상 길이: 약 47분 39초

자동 생성 자막의 고유명사 오인식을 문맥에 따라 보정했다. 예를 들어 Brex, OpenClaw, Greenhouse, CrabTrap, Magpby/MacPI의 표기가 자막에서 흔들린다. Magpby/MacPI는 영상에서 AI 토큰 비용 관리 도구를 가리키는 명칭으로 기록한다.

---

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

==범용 에이전트 하나에 수많은 일을 맡기기보다, 특정 직무·목표·스킬·상태·관리 체계를 가진 가상 직원(virtual employee)을 만들고 실제 업무 결과를 판매해야 한다.==

• Brex는 비엔지니어링 팀의 생산성 격차를 줄이기 위해 채용 담당자 Jim을 가상 직원으로 운영한다.
• 프로덕션 에이전트는 네트워크 경계의 CrabTrap 프록시로 모든 요청을 감사·허용·차단해야 한다.
• 토큰은 향후 기업의 핵심 비용이 되므로 모델·직원·호출자·고객별 사용량과 실제 결제액을 함께 추적해야 한다.
• AI 도입은 아직 초기 단계이며, 대부분의 조직은 사람의 도움을 받아 AI 전환을 거쳐야 하므로 역할은 융합되고 ‘10배 직원’의 격차가 커진다.

이 대화는 PM의 역할 변화에서 시작해 Brex의 Jim 채용 직원, CrabTrap 보안 프록시, Magpby/MacPI 토큰 비용 분석, Pedro의 개인용 OpenClaw 기반 Autopilot, 그리고 AI 시대의 비즈니스 모델과 고용 전망으로 이어진다. 공통된 결론은 에이전트를 단순한 기능이나 도구로 포장하는 데 그치지 말고, 경계가 분명한 업무 주체로 설계해 신뢰 가능한 결과물을 내도록 하라는 것이다.

1. PM의 역할은 문서 작성자에서 문제·결과의 책임자로 바뀐다

제품 조직의 품질은 고객 신호를 포착하고, 이를 제품 가설로 바꾸고, 실제로 작동하는 해결책을 고객에게 출시하는 루프를 얼마나 빠르게 압축하느냐로 측정해야 한다.

1.1. 전통적인 PM 플레이북의 약화

1. PRD와 이해관계자 조율만으로는 충분하지 않다

   1. Peter Yang은 Pedro가 “PRD를 쓰고 이해관계자를 조율하는 PM 플레이북은 끝났다”고 쓴 트윗을 꺼내며, 전통적인 PM 역할이 정말 사라지는지 질문한다.
   2. Pedro는 과거 PM이 대량의 정보를 수집하고, 트레이드오프를 정하고, 프로토타입과 제품 구축을 주도했지만 그 역할이 지난 몇 년 사이 크게 바뀌었다고 말한다.
   3. 약 5년 전까지는 PM이 제품 조직을 운영하고 제품을 설계하며, 기능의 장단점과 기회를 논의하는 ‘미니 CEO’라는 인식이 강했다.

2. 전문 직군의 경계가 흐려진다

   1. Brex는 엔지니어링·디자인의 전문성이 PM과 동등한 위치에 있어야 제품 모델이 작동한다고 본다.
   2. AI 시대에는 PM도 코드를 쓰고, 디자이너도 코드를 쓰며, 엔지니어도 데이터와 맥락을 바탕으로 과거 PM 영역의 결정을 내린다.
   3. PM의 가치는 문서 자체보다 고객과 시장에서 들어오는 맥락을 이해하고 무엇을 만들지 우선순위를 정하는 판단에 더 가까워진다.

1.2. Brex PM의 앞부분과 뒷부분

1. 앞부분은 시장 진출(GTM) 맥락을 제품으로 연결하는 일이다

   1. Brex의 PM은 제품을 직접 만드는 장인 역할보다 시장 진출 팀과 제품 조직 사이의 다리 역할에 더 많은 시간을 쓴다.
   2. 영업팀이 고객과 현장에서 어떻게 상호작용하는지, 어떤 문제가 거래를 막는지, 제품 내부의 변화가 시장 현실에 어떤 영향을 주는지를 파악한다.
   3. 승리는 제품을 쓰는 순간에만 발생하는 것이 아니라 훨씬 상류(upstream)의 시장·문제 정의에서 시작되므로, 그 지점의 정보를 제품 결정에 반영한다.

2. 뒷부분은 만든 것이 실제 문제를 해결하는지 검증하는 일이다

   1. PM은 Gong 같은 통화 기록을 6개월에서 수년치까지 모으고, 비정형 데이터에서 반복 신호와 통찰을 꺼낸다.
   2. 꺼낸 가설을 저렴하고 빠르게 만들 수 있는 프로토타입으로 제시하고 검증한다.
   3. 문제를 올바르게 이해했다는 확신이 쌓이면 개발 주기를 압축하고 처음부터 고객의 고통을 해결하는 제품을 출시할 가능성이 높아진다.

1.3. AI가 바꾸는 문제 정의와 판단

1. 비정형 신호를 문제 후보로 만든다

   1. 영업 담당자가 고객 앞에서 거래를 잃을 때 어떤 기능이 직접 언급됐는지 확인한다.
   2. 고객이 직접 말하지 않았더라도 RFP의 요구사항, 다른 질문, 행동 패턴 등으로 중요하게 여긴 요소를 추론한다.
   3. 과거 PM이 접근하기 어려웠던 자료를 AI가 읽고 연결하면서, 문제를 어느 정도 풀어야 하는지가 더 잘 보이게 된다.

2. LLM은 자료를 소화하지만 최종 정렬은 사람의 판단이다

   1. LLM은 많은 자료를 읽고 가설을 구성하는 데 도움을 주지만, 그 가설이 회사가 추구하는 더 큰 방향과 맞는지는 사람이 판단해야 한다.
   2. 리뷰는 단순히 서류를 정리하거나 데이터를 회사가 듣고 싶은 말에 맞추는 작업이 아니라, 왜 지금 이 문제가 중요한지와 어떤 결과를 낼지를 설명하는 작업이다.
   3. 핵심은 다섯 가지나 열 가지를 만들 수 있다는 이유로 모두 만드는 것이 아니라 진짜 레버가 무엇인지 판별해 한 가지 문제에 집중하는 것이다.

2. 리뷰 시스템은 사람을 통제하는 장치가 아니라 업무 품질을 복제하는 장치다

Pedro는 리더가 모든 사람을 직접 만나 승인해야 하는 병목을 만들지 않으면서도 높은 기준을 유지하려면, 반복 가능한 리뷰 원칙과 업무 참여가 필요하다고 설명한다.

2.1. 회사 안에 판례(case law) 시스템 만들기

1. 리더 리뷰는 회사의 대법원 역할을 한다

   1. Pedro는 자신의 업무 시간 중 절반 정도를 결과물 리뷰에 쓴다고 말한다.
   2. 자신에게 올라오는 리뷰는 회사에서 ‘무엇이 훌륭한 결과물인가’의 기준을 세우는 대법원 같은 역할을 한다.
   3. 그 기준은 팀 내부 리뷰로 내려가고, 최종적으로 개인 기여자(IC)가 직접 무언가를 만들 때도 결과물이 견뎌야 할 과제를 이해하도록 만든다.

2. 리더는 사람보다 업무를 관리한다

   1. Brex의 원칙은 “사람을 관리하는 것이 아니라 업무를 관리하고, 사람을 업무 주변에서 관리한다”는 것이다.
   2. 직급이나 사람의 인상보다 실제 문제와 결과물을 직접 들여다보면, 리더를 만나기 위해 한 달씩 기다리는 조율 병목을 줄일 수 있다.
   3. 이 방식은 자율성을 허용하면서도 조직 전체의 품질 기준을 일관되게 유지한다.

2.2. 문제 정렬과 해결책 정렬

1. 문제 정렬(problem alignment)

   1. 리뷰의 첫 질문은 “우리가 해결하려는 문제가 무엇인가”이다.
   2. 예를 들어 특정 기능이나 제품의 유지율이 기대보다 낮다면, 먼저 그 현상이 정말 해결할 가치가 있는 문제인지 합의해야 한다.
   3. Pedro는 문제를 고르는 일이 문제 해결의 약 50%라고 본다. 같은 영역에도 해결할 수 있는 문제가 여러 개이기 때문이다.

2. 해결책 정렬(solution alignment)

   1. 문제에 합의한 뒤에는 여러 대안 중 무엇을 선택했는지, 선택하지 않은 대안은 무엇인지, 트레이드오프를 어떻게 생각했는지를 검토한다.
   2. “이 프로젝트의 진행 속도를 제한하는 실제 병목은 무엇인가?”, “왜 이 작업이 그 병목의 처리량을 높이는가?”를 반복해서 묻는다.
   3. 회의록과 과거 리뷰 기록을 축적하면 조직에 반복되는 패턴을 명확히 하고, 매번 처음부터 조율하는 비용을 줄일 수 있다.

2.3. 스킬 저장소와 문제 특화 판단

1. 사전 소화된 PM 스킬

   1. Brex는 제품과 서비스에 사용되는 스킬을 저장소(repository)에 모아 두고 최신 상태로 유지한다.
   2. Pedro와 제품 책임자는 스킬의 내용이 실제 원칙과 맞는지 점검한다.
   3. 리뷰 대상자는 리뷰를 받기 전에 ‘문제가 명확히 진술됐는가’, ‘원칙에 맞는가’ 같은 기본 점검을 이미 수행한다.

2. 일반 알고리즘보다 문제의 특수성이 중요해진다

   1. 기본 원칙은 스킬로 코드화할 수 있지만, 리뷰에서 진짜 시간을 써야 하는 부분은 각 문제의 고유한 맥락이다.
   2. 어떤 문제든 똑같은 알고리즘을 적용하는 대신, 이미 정리된 규칙을 빠르게 통과하고 해당 문제만의 트레이드오프와 병목에 집중한다.
   3. AI는 반복적인 정리와 비교를 맡고, 사람은 회사의 방향·고객 가치·실행 가능성 사이의 정렬을 책임진다.

3. 가상 직원은 범용 에이전트가 아니라 특정 직무를 맡은 업무 주체다

Brex는 비엔지니어링 팀의 생산성을 엔지니어 수준으로 끌어올리려면, 무엇이든 할 수 있는 열린 에이전트보다 한 가지 직무를 맡은 가상 직원을 만드는 편이 낫다고 판단했다.

3.1. 범용 에이전트와 가상 직원의 차이

1. 생산성 격차를 줄이는 설계 목표

   1. AI 분야에는 코딩 하네스에서 토큰을 극도로 활용해 생산성을 높인 ‘10배 엔지니어’가 이미 등장했다.
   2. 반면 비엔지니어링 팀은 엔지니어 팀만큼 도구와 하네스를 활용하지 못할 수 있으므로, 두 집단 사이의 생산성 격차를 줄이는 것이 과제다.
   3. Brex는 이를 위해 비엔지니어가 직접 복잡한 하네스를 다루지 않아도 특정 업무를 맡길 수 있는 가상 직원을 설계했다.

2. 사람처럼 행동·외관·감각을 갖추기

   1. 가상 직원은 수백만 가지 일을 할 수 있다는 인상을 주는 대신, 실제 동료처럼 행동하고 보이고 느껴져야 한다.
   2. 직무명, 업무 범위, 스킬, 현재 상태, 연결된 시스템, 상호작용 채널이 하나의 업무 맥락으로 묶여야 한다.
   3. 이 설계가 되면 회사는 도구 사용권만 파는 것이 아니라 직원이 수행한 업무 결과 자체를 판매할 수 있다.

3.2. Jim의 역할과 3단계 파이프라인

1. Jim은 OpenClaw 기반 채용 담당자다

   1. Jim은 Brex의 OpenClaw 채용 담당자이며, 신입 사원을 환영하는 Slack 채널 ‘Welcome to Brex’에 실제 동료처럼 환영 글을 올린다.
   2. 사람들은 Jim과 대화하고 일반적인 채용 담당자와 상호작용하듯 질문할 수 있다.
   3. Jim은 2026년 2월부터 운영되고 있으며, 영상 시점에도 실제 채용 업무를 수행하고 있다.

2. 채용 정보를 한 번에 통합한다

   1. 1단계는 지원자 관리 시스템(ATS)인 Greenhouse와 동기화하고, 채용 공고·역할·지원서·기존 메모를 가져오는 것이다.
   2. 2단계는 지원자를 수집하고 이력서, 풍부한 LinkedIn 프로필, GitHub 데이터를 분석해 지원자의 전체 맥락을 완성하는 것이다.
   3. 3단계는 채용 관리자가 직무별 기준으로 지원자를 평가하고, 점수와 근거를 제공하는 분석 계층으로 기능하는 것이다.

3.3. Jim의 웹 UI와 실제 업무 흐름

1. 채용 공고에서 후보자 평가까지

   1. Jim의 웹 UI에서는 조치가 필요한 사람, Brex를 어떻게 알게 됐는지, 지원자, 채용 공고를 한곳에서 볼 수 있다.
   2. Staff Rock Designer 같은 디자인 직무나 엔지니어링 직무를 고르고, 공고마다 맞춤 평가 기준과 소싱 기준을 설정할 수 있다.
   3. 지원자 화면에서는 신뢰도 점수나 기준 점수로 정렬하고, 점수가 나온 근거와 경력 타임라인의 출처, 지원 당시의 원본 이력서를 확인할 수 있다.

2. 채용 담당자의 시간을 아웃바운드 업무에 쓴다

   1. Jim은 많은 지원자 정보를 미리 모으고, 채용 담당자가 검토할 후보자와 후속 조치가 필요한 항목을 표시한다.
   2. 채용 담당자는 Greenhouse의 복잡한 UI를 직접 돌아다니는 대신 Slack에서 “이 직무의 평균 후보자 점수가 가장 높은가?”, “이상치가 있는가?”, “상위 30명은 누구인가?”를 Jim에게 질문한다.
   3. 뛰어난 후보자에게는 LinkedIn 링크와 함께 눈에 띄는 후보자라는 신호를 게시한다.

3.4. Jim이 만드는 루프와 가상 직원의 범위

1. 소싱·인바운드 필터·분석

   1. Jim의 첫 번째 역할은 채용 공고에 맞는 사람을 발굴하는 소싱이다.
   2. 두 번째 역할은 들어오는 모든 지원 정보를 필터링하고 신호를 찾는 것이다.
   3. 세 번째 역할은 역할별 평균 점수, 이상치, 후보자 분포를 보여주는 분석 계층이다.

2. 주간 자동 소싱과 인간의 마지막 판단

   1. 채용 공고에서 ‘이 직무 후보자를 매주 소싱’ 옵션을 켜면 직무 설명, 평가 기준, 소싱 기준으로 적합한 후보자를 계속 찾는다.
   2. 기준을 통과한 사람에게만 연락하도록 해 채용 담당자의 아웃바운드 시간을 줄인다.
   3. Jim이 사람을 자동으로 채용하는 것이 아니라, 소싱·평가·연락을 준비하고 사람이 최종 판단과 관계 형성을 맡는다.

3. 사람처럼 보이는 이메일과 채널

   1. Jim은 LinkedIn에서 후보자에게 DM을 보내고, 채용 담당자나 소싱 담당자를 대신해 이메일을 보내고 답장을 처리한다.
   2. 메시지가 실제 사람이 보낸 것처럼 느껴지도록 발신자가 누구인지, 모집 담당자인지 소싱 담당자인지 구분하는 장치를 둔다.
   3. Peter Yang은 “Greenhouse가 원래 이런 모습이어야 했다”고 말하며, 채용팀이 Greenhouse 대신 Slack에서 일할 수 있는 점을 높이 평가한다.

3.5. 자기 개선과 성과 측정

1. 스킬과 크론 작업이 하네스보다 중요하다

   1. Jim은 여러 스킬과 상태(state)를 가진 시스템이며, 이를 실제로 올바르게 작동시키는 인프라가 주변에 있다.
   2. Brex는 OpenClaw를 사용하지만, Pedro는 특정 하네스 브랜드보다 적절한 스킬과 크론 작업을 구성하는 일이 더 중요하다고 말한다.
   3. 자기 개선 루프는 더 자동화해야 할 단계를 찾아 “다음에 이 기능을 구현하자”는 작업 항목으로 만든다.

2. 사람과 Jim의 합의율을 비교한다

   1. 채용 담당자가 통과시켰지만 Jim이 거절한 지원자 수를 측정한다.
   2. 반대로 Jim이 뛰어난 후보자로 표시했지만 채용 담당자가 연락하지 않은 사람도 추적한다.
   3. 두 판단의 합의율을 모니터링하고 시간이 지나면서 오류를 고쳐, Jim이 내부 직원에게 만드는 레버리지를 계속 키운다.

3. 오픈 소스와 엔지니어 평가

   1. Pedro는 오픈 소스 기여가 있으면 좋은 신호일 수 있지만, 없다는 사실 자체는 부정적 신호가 아니라고 말한다.
   2. Brex의 엔지니어 면접은 ‘빌더 루프’에 가깝고, 지원자가 실제로 무언가를 만들어야 한다.
   3. AI 도구를 다루지 못해 수작업으로만 문제를 풀거나 생산성을 10배 높일 방법을 모르면, 면접에서 요구되는 작업량을 감당하기 어렵다.

4. CrabTrap은 프로덕션 에이전트의 네트워크 경계를 통제한다

에이전트에게 코드를 실행할 권한이 있다면 도구 제한만으로는 충분하지 않다. Brex는 모든 네트워크 요청을 감시하고 정책에 따라 허용하는 오픈 소스 HTTP 프록시 CrabTrap을 구축했다.

4.1. 왜 네트워크 경계가 필요한가

1. 도구 제한의 근본적인 한계

   1. 커뮤니티에서는 NemoClaw 같은 프로젝트를 통해 사용할 수 있는 도구를 제한하려고 하지만, 에이전트가 코드를 실행할 수 있다면 다른 경로로 네트워크를 넘을 수 있다.
   2. 에이전트가 코드 실행을 할 수 있어야 한다고 보는 Brex의 관점에서는, 프롬프트만으로 에이전트의 모든 위험한 행동을 막기 어렵다.
   3. 따라서 에이전트 바깥의 네트워크 경계에서 모든 HTTP 트래픽을 통제해야 한다.

2. CrabTrap의 기본 설계

   1. CrabTrap은 오픈 소스 프록시로 요청을 가로채고, 어느 사용자·어느 에이전트가 어떤 네트워크 요청을 했는지 기록한다.
   2. Jim 주변에 배치하면 이메일, GitHub, 데이터 소스 등 Jim이 사용하는 모든 트래픽을 감사 추적할 수 있다.
   3. 제품으로 배포되는 에이전트는 정상 업무를 수행하면서도 허가받지 않은 외부 행동은 경계를 넘지 못하도록 해야 한다.

4.2. 감사 추적과 정책 평가

1. 실시간 감사 추적

   1. CrabTrap의 감사 추적 모드에서 여러 사용자 중 Jim을 필터링하면 Jim을 통과하는 거의 모든 네트워크 요청을 실시간으로 볼 수 있다.
   2. 각 거래에는 정적 규칙(static rule)이나 LLM 게이트웨이 같은 승인자가 표시된다.
   3. 이메일 계정 목록을 읽는 GET 요청처럼 Jim의 채용 업무에 필요한 요청은 사전에 정의한 정책과 일치하는지 확인한다.

2. 정적 규칙과 LLM 심사의 결합

   1. 모든 요청에는 먼저 항상 허용해도 된다고 판단한 정적 규칙 집합을 적용한다.
   2. 정적 규칙에 없는 요청은 정책 프롬프트를 거쳐 LLM이 요청의 성격과 허용 여부를 판단한다.
   3. 즉 단순한 도메인 허용 목록이 아니라, “GitHub에서 후보자를 검색할 수 있지만 다른 저장소에 게시하거나 Claw가 지정되지 않은 저장소에 push할 수는 없다”처럼 요청의 목적까지 심사한다.

4.3. 트래픽으로부터 정책을 자동 생성한다

1. 처음부터 정책을 손으로 쓰지 않는다

   1. Jim 사용자 계정에서 “HTTP 트래픽을 바탕으로 정책을 제안하라”고 요청할 수 있다.
   2. 시스템은 Jim을 통과한 네트워크 트래픽을 재생하고, 다른 LLM으로 요청 흐름을 요약해 관찰된 정상 행동을 정책으로 만든다.
   3. 실행에는 약 30분이 걸릴 수 있으며, 결과는 에이전트가 실제로 관찰한 트래픽에 맞춘 규칙 집합이다.

2. 정책이 시간이 지나며 강해지는 방식

   1. 실제 트래픽을 관찰한 뒤 재생하고, 허용되지 않은 요청을 차단하면 처음의 단순한 에이전트 배포보다 훨씬 견고한 통제가 된다.
   2. 기본적으로 특정 도메인을 차단하거나 허용하는 규칙에서 시작하지만, 요청의 의도와 작업 대상을 함께 판단하는 방향으로 발전한다.
   3. CrabTrap과 관리 UI 자체가 오픈 소스라서 다른 회사도 같은 방식으로 프로덕션 에이전트를 보호할 수 있다.

4.4. 차단 사례와 실제 판정

1. GitHub와 위험한 변경을 차단한다

   1. Jim은 후보자를 검색할 수 있지만, 임의의 저장소에 게시하거나 지정된 저장소가 아닌 곳에 push할 수 없다.
   2. GitHub 저장소를 삭제하거나 Okta 설정을 바꾸거나 정책 자체를 수정하는 요청도 허용하지 않는다.
   3. Jim이 Pirate Bay 같은 허용되지 않은 도메인에 접근하면 요청은 차단된다.

2. Granola 접근 사례

   1. Jim이 Granola 노드에 접근하려 했지만 Granola가 정책상 차단되어 요청이 거절됐다.
   2. 인터페이스에서 Granola를 허용 목록에 넣을 수는 있지만, 당시에는 왜 허용해야 하는지 판단할 근거가 없어 허용하지 않았다.
   3. Sonnet 기반 LLM 심사는 약 2초가 걸렸고 입력 1,000토큰, 출력 104토큰을 사용한 뒤 요청을 차단했다.
   4. 이 사례는 비용이 작은 요청이라도 프로덕션 네트워크 경계에서 구체적 목적을 심사해야 한다는 점을 보여준다.

5. 토큰은 기업의 새로운 비용 단위가 되며 분석 계층이 필요하다

Brex는 지출 관리 회사이므로 AI 사용량을 실제 돈의 흐름과 연결하는 문제를 특히 중요하게 본다. 토큰을 얼마나 쓰는지뿐 아니라 무엇이 비용을 만들었고 어떤 성과를 냈는지를 봐야 한다.

5.1. AI 비용의 세 가지 축

1. Corporate AI

   1. Brex 직원이 내부 업무를 더 잘하기 위해 AI를 어떻게 쓰는지 측정한다.
   2. Cloud Code, Codex, Cursor 같은 개발 도구 사용도 이 축의 비용과 생산성에 포함된다.

2. Operational AI

   1. 고객을 더 잘 지원하거나 성장시키고, 내부·외부 프로세스를 자동화하기 위해 AI를 사용하는 방식이다.
   2. 거래 태깅(transaction tagging), 보험 인수 심사(underwriting), 사기 방지(fraud)처럼 비정형 거래를 해석하는 제품 업무가 예시다.

3. Product AI

   1. 고객에게 실제로 출시하는 제품과 그 안의 AI 기능을 측정한다.
   2. 고객 한 명에게 해당 기능을 제공하는 비용과, 어떤 고객을 서비스하는 데 비용이 많이 드는지를 볼 수 있어야 한다.

5.2. Magpby/MacPI의 세밀한 비용 분석

1. 호출자·작업·모델별로 파고든다

   1. Brex는 토큰 비용을 관리하기 위해 Magpby/MacPI라는 도구를 만들었고, 데모 화면은 일부 데모 데이터를 사용한다.
   2. 특정 모델을 누가 호출하는지, 어떤 작업이 호출을 만들었는지, 사용량과 결과가 어떻게 연결되는지를 깊이 파고든다.
   3. 순위표(leaderboard)로 토큰을 많이 쓰는 사람을 볼 수도 있지만, Pedro가 말하는 진짜 가치는 사용 사례 전체를 연결하는 분석 계층이다.

2. 거래 태깅과 분쟁 처리의 비용 차이

   1. 거래 태깅은 현재 호출당 약 10센트이며, 한 달에 대략 2만 8,000달러를 쓴다.
   2. 분쟁(disputes) 처리 호출은 약 2달러로 표시되어 약 240배 차이가 난다.
   3. 다른 데모 화면에서는 329회 호출의 호출당 비용이 약 15달러 또는 9달러로 보이고, 최근 2주 동안 특정 작업 비용이 급증한 현상이 나타난다.
   4. 거래 태깅의 호출당 비용은 시간에 따라 비교적 안정적이므로, 전체 비용 상승이 호출 수 때문인지 모델·프롬프트·캐싱 변화 때문인지 추가로 분리해야 한다.

5.3. 사용량을 실제 결제액과 조정한다

1. 토큰 대시보드만으로는 충분하지 않다

   1. 사용량 화면은 모델, 직원, 호출자, 제품, 고객별 비용을 보여줄 수 있다.
   2. 그러나 최종적으로 중요한 것은 회사 은행 계좌에서 실제로 빠져나간 금액과 사용량을 대조하는 것이다.
   3. Brex는 카드 발급사이자 결제 레일을 갖고 있어 고객의 실제 지출 데이터를 보유하므로, AI 사용량과 결제액을 연결할 수 있다.

2. AI 네이티브 지출 관리로 확장한다

   1. 어떤 회사가 가장 많은 AI 트래픽을 소비하는지, 어떤 모델이 잘 수행하는지, 어느 고객을 서비스하는 데 비용이 많이 드는지 하나의 분석 계층에서 본다.
   2. 회사가 Brex를 통해 지출하면 곧 자체 AI 지출에도 이 기능을 적용할 수 있도록 상용 제품으로 발전시킬 계획이다.
   3. 토큰 비용이 통제 불능이 되면 이 계층으로 근본 원인을 고립하고 캐싱, 모델 선택, 프롬프트, 사용 사례를 최적화한다.

5.4. 무제한 사용과 사후 최적화

1. 생산성을 위해 초기에는 제약을 줄인다

   1. Brex는 엔지니어에게 기본적으로 무제한 토큰 예산을 제공하며, 악용을 막기 위한 일부 상한선만 둔다.
   2. 실제 생산성 향상을 위해 쓰는 경우에는 최대한 제약 없이 깊이 탐색하도록 한다.
   3. 무료 토큰을 마음껏 쓰는 창업자와 API 비용을 직접 부담하는 직원 사이에는 경제적 차이가 있지만, 그 차이를 먼저 막으면 학습과 생산성 향상을 놓칠 수 있다.

2. 먼저 깊이 사용하고 나중에 정밀하게 줄인다

   1. Brex의 학습은 먼저 사람들이 AI를 깊이 사용하고 배우고 구축할 수 있게 한 뒤, 실제 사용 데이터를 바탕으로 최적화해야 한다는 것이다.
   2. 처음부터 비용을 통제했다면 원하는 생산성 결과를 얻지 못했을 가능성이 크다.
   3. 이제는 어느 부분의 생산성이 낮은지 도구로 정밀하게 찾아 캐싱을 효율화하고, 모든 작업을 최고가 모델에서 돌릴지 더 저렴한 모델로 일부를 옮길지 판단할 수 있다.
   4. 영상에서는 고사양 모델의 예로 Opus 4.8과 향후 Table Five가 언급되며, 모든 작업을 가장 비싼 모델에서 실행할 필요가 있는지 분석해야 한다고 말한다.

5.5. 단일 모델 회사가 아닌 토큰 소비 전체를 관리한다

1. 멀티 모델이 필요한 이유

   1. 기업이 Anthropic 전용이나 OpenAI 전용이 되는 것은 현명하지 않으며, 여러 모델을 조율해 작업에 맞는 성능·비용 조합을 찾아야 한다.
   2. 어떤 작업은 최고 모델이 필요하고, 어떤 작업은 저렴한 모델로 충분하므로 사용 사례별 선택이 중요하다.

2. 토큰은 제품의 간접 비용이기도 하다

   1. 과거 소프트웨어는 좌석당 과금이 일반적이었지만, Cursor처럼 사실상 토큰을 감싼 제품이 토큰 사용량을 가격의 기준으로 삼는 사례가 늘어난다.
   2. 회사가 직접 Anthropic이나 OpenAI API를 부르지 않아도, 사용하는 제품을 통해 간접적으로 토큰 비용을 낸다.
   3. 따라서 “어느 모델을 쓰는가”보다 “어떤 제품·호출·고객·작업이 토큰을 소비하는가”를 전체적으로 이해해야 한다.

6. AI 시대의 고용은 역할 융합과 10배 직원의 등장으로 재편된다

Pedro는 대규모 실업 위험을 인정하면서도 새 역할이 생기고 모든 사람이 어느 정도 빌더가 될 것이라고 전망한다. AI가 생산성의 하한과 상한을 모두 높이지만, 상한을 훨씬 더 크게 높일 가능성이 있다고 본다.

6.1. 사람과 AI의 역할 변화

1. 일자리는 사라짐과 생성이 함께 일어난다

   1. 대기업의 해고가 기술 업계 인력 감소로 이어질 수 있지만, 아직 이름조차 모르는 새로운 역할도 훨씬 많이 생길 수 있다.
   2. 역할 사이의 경계가 섞이고, 모든 구성원이 어느 정도 직접 만들고 구현하는 빌더가 된다.
   3. 조직은 사람을 AI로 단순 대체하기보다 AI를 업무에 붙이고 전환을 진행할 사람을 필요로 한다.

2. 시장에 필요한 것은 10배 직원이다

   1. 뛰어난 사람은 AI 사용법을 배우고, 좋은 사람은 뛰어난 사람이 하는 방식을 관찰해 일부를 재현한다.
   2. 기존에도 10배 엔지니어와 1배 엔지니어 사이에 성과 차이가 있었듯 AI 활용에서도 생산성 분산이 생긴다.
   3. AI는 생산성의 바닥을 끌어올리면서 천장도 올리지만, Pedro는 특히 천장을 훨씬 더 많이 올릴 것이라고 본다.

6.2. AI 도입은 아직 초기 단계다

1. 2,500개 상자 이미지

   1. Pedro는 세계를 2,500개의 상자로 나눈 이미지를 AI 도입의 현재 위치를 설명하는 비유로 사용한다.
   2. 이미지의 점 하나는 약 320만 명을 나타낸다.
   3. 빨간 상자는 AI를 한 번도 써보지 않은 사람, 초록 상자는 무료 채팅 사용자, 주황 상자는 월 20달러를 내고 AI를 쓰는 사람을 뜻한다.
   4. 에이전트를 효과적으로 사용하는 사람은 작은 빨간 상자로 표현될 만큼 아직 극소수다.

2. 전환에는 사람이 필요하다

   1. 사람들이 “모든 것이 바뀐다”고 말할 때 실제 변화가 얼마나 초기 단계인지 놓치는 경우가 있다.
   2. 대부분의 기업과 사람은 AI 전환을 혼자 해낼 수 없고, 도입·교육·업무 재설계를 함께 수행할 사람이 필요하다.
   3. 따라서 AI가 사람을 없애는 단선적인 그림보다, 사람 한 명이 처리할 수 있는 생산량이 크게 늘어나는 그림이 현실에 가깝다.

6.3. 창업가의 생산성과 100배 격차

1. 미뤄두던 일을 바로 처리한다

   1. AI를 쓰면 창업가가 할 수 있는 일이 늘었다는 확신을 얻어, 구석에 쌓아 두던 일을 계속 꺼내 해결하게 된다.
   2. 시간이 남으면 해변에 가겠다고 미루던 태도보다, 만드는 과정 자체에서 에너지를 얻어 다음 문제를 처리하는 태도가 강해진다.
   3. 이는 단순히 근무 시간이 늘어난다는 뜻이 아니라, 아이디어를 실행 가능한 결과로 바꾸는 마찰이 줄어든다는 뜻이다.

2. 코딩 하네스가 생산성의 분기점이 된다

   1. 코딩 하네스 안에서 AI를 적극적으로 활용하는 사람은 AI를 전혀 쓰지 않는 사람보다 100배 더 생산적일 수 있다고 Peter Yang이 말한다.
   2. Pedro는 이런 순간을 반드시 포착해야 한다고 동의한다.
   3. 다만 이 격차를 조직 전체로 확장하려면 엔지니어만이 아니라 비엔지니어도 역할 단위의 가상 직원과 스킬을 통해 같은 레버리지를 얻어야 한다.

7. Pedro의 개인용 Autopilot은 삶 전체를 Markdown 상태 시스템으로 만든다

Pedro는 자신의 민감한 정보는 가려야 한다고 전제한 뒤, OpenClaw 하네스가 업무와 삶을 조종하는 개인 시스템 ‘Autopilot’을 시연한다.

7.1. 사람·프로그램·신호라는 세 가지 구성

1. 사람과 프로그램을 업무의 기본 단위로 삼는다

   1. Autopilot에는 Pedro가 관심을 갖는 프로그램(programs)과 팀에서 실제로 많은 시간을 함께 보내는 사람(people)이 있다.
   2. 각 프로그램과 사람은 별도의 맥락과 상태를 가지며, 그 맥락 안에서 해야 할 일과 상호작용을 정리한다.
   3. 이 구조는 단순한 할 일 목록이 아니라 사람·프로그램·업무 신호를 연결한 상태 모델이다.

2. 모든 것은 신호에서 시작된다

   1. 신호(signal)는 Slack 메시지, 이메일, 회의록처럼 Pedro의 업무 맥락에 실제로 들어오는 정보다.
   2. 신호 수집기는 받은 편지함, 회의, Slack을 읽고 어떤 사람이나 프로그램과 관련되는지 찾아낸다.
   3. 중요한 것은 신호를 단독 문장으로 저장하는 것이 아니라, Pedro가 진행 중인 일과 연결된 맥락으로 저장하는 것이다.

7.2. 수집과 집계로 업무 상태를 갱신한다

1. Signal Collector와 Aggregate

   1. Signal Collector가 이메일·회의록·Slack 메시지를 모은다.
   2. Aggregate 작업은 Pedro가 가진 모든 사람과 프로그램을 순회하며 관련 파일을 업데이트한다.
   3. 결과적으로 PR과 소셜 같은 프로그램 화면에서 현재 상태, 진행 중인 마케팅 캠페인, 위험과 방해 요소를 한눈에 볼 수 있다.

2. 팟캐스트 준비 사례

   1. Autopilot은 이 팟캐스트를 준비하는 과정에서 누군가가 카메라 문제를 도왔다는 정보와 준비 상태를 기록했다.
   2. Pedro가 팀의 Kobe에게 Magpby/MacPI 데모 스크립트를 작성해 달라고 한 일과 이미 완료된 상태도 표시한다.
   3. 노란색 항목은 신호 주입(signal injection)이 자동으로 만든 초안이며, 예를 들어 누군가 컨퍼런스 참석 여부를 묻는 Slack DM에서 “참석할지 결정해야 한다”는 작업을 추출한다.

7.3. 상호작용 로그와 통합 문서

1. 모든 행동을 한 화면에서 추적한다

   1. 상호작용 로그에서 오늘이나 어제 발생한 일만 필터링하고, 각 작업의 출처가 된 원래 DM이나 신호를 열어 볼 수 있다.
   2. 신호와 작업은 관련 프로그램의 맥락 안에서 표시되므로 Slack·이메일·회의록을 각각 뒤지지 않아도 된다.
   3. 여러 프로그램과 여러 사람에 대해 같은 구조를 적용하면 모든 진행 상황, 추적해야 할 작업, 대화 기록을 한곳에 내려받을 수 있다.

2. 문서도 시스템 안에 넣는다

   1. Autopilot은 시스템을 만들기 위해 사용한 문서를 모아 요약해 보여준다.
   2. 프로그램별로 무엇이 진행 중인지와 그 프로그램의 업무를 위해 어떤 문서가 참고됐는지를 함께 확인할 수 있다.
   3. 이는 개인의 기억과 주의력을 대체하는 외부 상태(state) 저장소로 기능한다.

7.4. 전부 Markdown 파일로 관리한다

1. 프롬프트가 아닌 편집 가능한 업무 정의

   1. 각 프로그램은 특정 정보를 추출하는 프롬프트처럼 동작하지만 실제 구현은 Markdown 파일이다.
   2. Pedro는 파일 안에서 프로그램의 정의를 직접 수정하고, 신호 주입이 나머지 내용을 채우도록 할 수 있다.
   3. 상호작용 로그도 직접 편집할 수 있고, 검색·편집이 쉬운 UI는 별도의 스크립트가 Markdown 위에 제공한다.

2. 데이터베이스 대신 저장소와 UI를 조합한다

   1. 데이터베이스나 QMD 같은 별도 저장 계층 없이 사람, 프로그램, 로그, 상태가 모두 Markdown 파일로 남는다.
   2. 이 파일들은 실행 중인 저장소(repository)에 커밋된다.
   3. 실제 기반은 텍스트 파일이고, UI와 작업 관리 기능은 그 파일을 읽고 편집하기 편하게 만드는 층이다.
   4. Pedro가 말하는 결과는 삶 전체의 상태를 하나의 시스템에서 소비할 수 있게 하는 개인용 업무 운영체제다.

3. OpenClaw는 학습과 숙련이 필요한 도구다

   1. Peter Yang이 OpenClaw를 안정적으로 작동시키는 것조차 어렵다고 하자, Pedro는 OpenClaw가 ‘배워서 익숙해져야 하는 취향(acquired taste)’이라고 답한다.
   2. 안정적으로 만들려면 상당한 시간과 학습이 필요하지만, 제대로 익히면 그만한 가치가 있다고 말한다.

8. SaaS의 종말이 아니라 결과물 중심 과금으로의 이동

AI가 소프트웨어를 쉽게 복제하게 만들었어도 고객이 가진 문제를 해결하는 가치는 사라지지 않는다. 다만 판매 단위가 도구에서 결과물과 작업 자체로 이동한다.

8.1. 통화(currency)는 바뀌어도 문제 해결의 가치는 남는다

1. SaaS의 진입장벽이 높아진 이유

   1. Peter Yang은 특정 분야의 SaaS에 구독료를 받던 시절이 약해지고, 이제는 스킬과 API를 연결해 비슷한 결과를 직접 만들 수 있다고 말한다.
   2. 틈새 제품을 만들고 돈을 버는 일은 예전보다 어려워졌지만, 이는 사람들이 더 이상 문제 해결에 돈을 내지 않아서가 아니다.
   3. Pedro는 단지 사물의 ‘통화’를 바꾼 것이라고 설명한다. SaaS 구독료 대신 토큰을 소비하는 에이전트와 토큰 마크업이 새로운 가격 구조가 될 수 있다.

2. 고객은 여전히 문제 해결에 돈을 낸다

   1. 제품이 SaaS인지 토큰 기반 에이전트인지와 무관하게, 핵심은 사람의 문제를 해결하는 것이다.
   2. 토큰을 얼마나 쓰는지는 비용 구조이지만, 고객이 기꺼이 돈을 내는 이유는 토큰 자체가 아니라 달성된 결과다.
   3. 따라서 토큰 가격을 단순히 전가하는 제품보다 결과의 품질·신뢰성·운영 비용을 함께 관리하는 제품이 살아남는다.

8.2. 도구가 아닌 작업을 판매하는 높은 기준

1. AI 제품의 기준이 높아진다

   1. 소프트웨어만 판매할 때보다 AI 제품의 기준이 훨씬 높아진다.
   2. 고객은 UI나 기능 목록이 아니라, 에이전트가 대신 처리해 준 실제 업무와 결과를 비교하게 된다.
   3. Jim이 채용 후보자를 발굴하고 정리해 주는 것처럼, “이 도구로 직접 하라”가 아니라 “이 담당자가 대신 처리한다”고 말할 수 있어야 한다.

2. 좋은 AI 제품의 공통 구조

   1. Pedro는 좋은 AI 제품의 본질이 모델에 도구를 노출하고, 에이전트 루프(agentic loop)로 반복 실행하는 구조라고 말한다.
   2. 문제 영역에 필요한 도구를 연결하고 모델이 결과를 확인하며 다음 작업을 수행하게 하면, 다양한 산업과 직무에 적용할 수 있다.
   3. 제품 차별화의 핵심은 단순히 모델을 호출하는 것이 아니라 어떤 업무를 책임지고 어떤 결과 기준을 통과하게 할지에 있다.

9. 영상에 포함된 스폰서 메시지와 마무리

9.1. Riverside 스폰서 구간

1. 녹음 품질

   1. Peter Yang은 Riverside를 수년간 팟캐스트 녹음에 사용해 왔다고 소개한다.
   2. 각 사람의 음성을 로컬에서 4K로 녹음하므로 게스트의 Wi-Fi가 불안정해도 오디오와 영상이 깨끗하게 남는다고 설명한다.

2. 녹음 후 AI 편집

   1. Riverside의 AI 도구는 녹음에서 멈춤과 필러(filler)를 제거하고 전체 녹음을 정리한다.
   2. transcript를 직접 편집하면 YouTube·Spotify·소셜 미디어에 올릴 수 있는 자막 포함 클립을 자동으로 만든다.
   3. 1인 창작자에게 녹음부터 편집·클립 제작·게시까지 한곳에서 처리하는 점이 중요하다고 말한다.
   4. 영상에는 creators.riverside.com/peteryang 또는 riverside.com/peteryang 방문과 결제 시 peteryang 코드 입력 시 한 달 무료라는 안내가 들어간다.

9.2. Pedro의 최종 메시지

1. 온라인에서의 활동

   1. Pedro는 X에서 Pedro age 96이라는 이름으로 찾을 수 있다고 농담한다.
   2. 자신이 만드는 것과 Brex가 만드는 것을 세상에 알리려 한다고 말한다.

2. Brex가 만들려는 가치

   1. 기업이 AI 지출을 더 잘 관리하고 토큰을 책임 있게 활용해 훌륭한 것을 만들도록 돕는 일이 Brex가 할 수 있는 가장 가치 있는 일이라고 말한다.
   2. Peter Yang은 대화를 눈이 번쩍 뜨이는 경험이라고 평가하고, Pedro는 AI 토큰을 매우 책임감 있게 최대한 활용하는 것이 Brex의 모델이라고 재확인한다.

주요 발언 모음

“왜 당신과 에이전트만으로 회사를 시작하면 안 되는가?”

“수백만 가지 일을 할 수 있는 열린 에이전트가 아니라 가상 직원을 만드는 데 집중해야 한다.”

“가장 근본적인 과제는 실제 사람처럼 행동하고, 보이고, 느껴지게 만드는 것이었다.”

“이제 도구만 파는 것이 아니라 작업물 자체를 팔 수 있게 됐다.”

“우리는 사람을 관리하는 것이 아니라 업무를 관리하고, 업무를 중심으로 사람을 관리한다.”

“문제의 50%는 어떤 문제가 해결할 가치가 있는지 정하는 일이다.”

“에이전트가 코드를 실행할 수 있다면 네트워크 경계를 넘어 잘못된 일을 할 수 있다.”

“토큰 비용이 통제 불능이 되면 근본 원인을 고립하고 최적화할 수 있어야 한다.”

“먼저 사람들이 AI를 깊이 사용하고 구축하게 한 다음 나중에 최적화해야 한다.”

“앞으로 시장이 원하는 것은 10배 직원이다.”

“모든 사람이 어느 정도 빌더가 될 것이며, 대부분의 기업은 그 전환을 혼자 해낼 수 없다.”

“이제 소프트웨어가 아니라 작업 자체를 팔 수 있다.”

핵심 데이터 & 수치

• 약 47분 39초: 영상 전체 길이다.
• 2026년 2월: Brex의 가상 채용 직원 Jim이 운영되기 시작한 시점으로 소개된다.
• 절반: Pedro가 업무 시간 중 결과물 리뷰에 쓰는 비중이다.
• 약 50%: Pedro가 문제를 고르는 일이 문제 해결의 절반이라고 설명한 비중이다.
• 6개월~수년: PM이 Gong 통화 기록을 분석할 수 있는 기간의 예시다.
• 약 30분: 실제 네트워크 트래픽을 재생해 정책을 제안하는 작업에 걸릴 수 있는 시간이다.
• 2초: Granola 접근 요청에 대한 Sonnet 기반 LLM 심사 시간이다.
• 1,000토큰 입력 / 104토큰 출력: Granola 요청을 심사한 데모 호출의 토큰 수다.
• 호출당 약 10센트: 거래 태깅의 데모 비용이다.
• 월 약 2만 8,000달러: 거래 태깅의 데모 월 지출이다.
• 약 2달러/호출: 분쟁 처리의 데모 비용이다.
• 약 240배: 거래 태깅과 분쟁 처리 사이에 표시된 비용 차이다.
• 329회 호출: 비용 급증을 보여주는 특정 데모 작업의 호출 수다.
• 약 15달러 또는 9달러/호출: 해당 데모 화면에서 표시된 호출당 비용이다.
• 2,500개 상자: 전 세계 AI 사용 상태를 설명하는 Pedro의 이미지 비유다.
• 약 320만 명/점: 2,500개 상자 이미지에서 점 하나가 나타내는 인구다.
• 월 20달러: 주황색 상자로 표현된 유료 AI 채팅 사용자의 기준이다.
• 100배: AI 코딩 하네스를 쓰는 사람이 AI를 쓰지 않는 사람보다 생산적일 수 있다는 Peter Yang의 표현이다.
• 4K 로컬 녹음: Riverside가 소개한 사용자별 녹음 방식이다.

결론 및 시사점

1. 범용 에이전트를 만들기 전에 한 사람이 맡을 직무를 정의하고, 목표·스킬·상태·권한·성과 기준을 하나의 가상 직원으로 묶어야 한다.
2. 가상 직원의 품질은 사람처럼 보이는 페르소나보다 특정 업무를 끝까지 책임지고 결과물을 돌려주는 운영 루프에서 나온다.
3. PM은 PRD와 조율을 독점하는 역할에서 벗어나 고객·영업 신호를 문제로 정의하고, 결과물이 실제로 문제를 해결하는지 검증하는 역할로 이동한다.
4. 문제 정렬과 해결책 정렬을 분리하고, 리뷰 기록을 회사의 판례 시스템으로 축적하면 리더가 모든 사람을 직접 승인하지 않아도 높은 기준을 복제할 수 있다.
5. 엔지니어링·디자인·PM의 경계가 흐려지는 만큼 모든 구성원이 일정 수준의 빌더가 되어야 하며, 조직은 이를 위한 스킬 저장소를 관리해야 한다.
6. 에이전트가 코드를 실행할 수 있다면 프롬프트와 도구 제한만으로는 부족하므로 네트워크 경계에서 모든 요청을 감사하고 의도까지 심사해야 한다.
7. 실제 트래픽을 관찰하고 재생해 정책을 제안하게 하면 에이전트가 정상 업무에서 필요로 하는 네트워크 권한을 점진적으로 좁힐 수 있다.
8. AI 비용은 API 청구서만의 문제가 아니라 제품·모델·직원·호출자·고객별 사용량과 실제 계좌 지출을 연결하는 지출 관리 문제다.
9. 초기에는 토큰을 아끼기보다 사람들이 AI를 깊이 사용하게 하고, 데이터가 쌓인 뒤 캐싱과 모델 선택을 통해 생산성이 낮은 비용부터 정밀하게 최적화해야 한다.
10. 기업은 특정 모델 하나에 종속되기보다 직접·간접적으로 토큰을 소비하는 모든 제품과 업무를 분석해야 한다.
11. AI는 역할을 없애는 동시에 새로운 역할을 만들고, 사람 한 명이 처리할 수 있는 업무량의 상한을 특히 크게 높여 생산성 분산을 확대할 수 있다.
12. AI를 효과적으로 사용하는 사람과 사용하지 않는 사람 사이의 격차를 줄이려면 비엔지니어링 직무에도 Jim 같은 업무 단위의 가상 직원을 제공해야 한다.
13. Pedro의 Autopilot 사례는 Slack·이메일·회의록을 신호로 모아 사람·프로그램별 Markdown 상태 파일로 갱신하면 개인의 업무 맥락을 검색 가능한 시스템으로 만들 수 있음을 보여준다.
14. SaaS의 가치가 사라지는 것이 아니라, 도구의 기능 목록을 판매하던 방식에서 에이전트가 실제로 완료한 결과와 책임을 판매하는 방식으로 기준이 높아진다.
15. 좋은 AI 제품은 모델·도구·에이전트 루프를 조합하되, 고객이 직접 조작할 도구가 아니라 신뢰할 수 있는 업무 결과를 제공해야 한다.

핵심 요약 (20줄)

1. 범용 에이전트보다 직무·스킬·상태·권한을 갖춘 가상 직원이 실제 업무를 안정적으로 수행한다.
2. Brex는 비엔지니어링 팀의 생산성 격차를 줄이기 위해 OpenClaw 기반 채용 직원 Jim을 운영한다.
3. Jim은 Greenhouse와 동기화하고 이력서·LinkedIn·GitHub 정보를 모아 지원자 맥락을 완성한다.
4. Jim은 후보자를 소싱하고 인바운드 지원자를 필터링하며 채용 데이터를 분석하는 세 가지 역할을 수행한다.
5. 채용 담당자는 Greenhouse UI 대신 Slack에서 Jim에게 평균 점수와 상위 후보자 정보를 질문할 수 있다.
6. Jim은 직무 기준에 따라 후보자를 평가하고 적합한 사람에게 LinkedIn DM과 이메일을 보내는 업무를 준비한다.
7. 사람과 Jim의 합의율을 측정하면 자동화의 오류를 찾고 시간이 지나며 채용 품질을 개선할 수 있다.
8. 오픈 소스 기여는 있으면 좋은 신호지만 없다는 사실은 부정적 신호가 아니며 실제 빌더 역량이 더 중요하다.
9. 에이전트에게 코드 실행 권한이 있다면 도구 제한만으로 부족하므로 네트워크 경계 통제가 필요하다.
10. 오픈 소스 CrabTrap은 에이전트의 HTTP 요청을 감사하고 정적 규칙과 LLM 심사로 허용 여부를 판정한다.
11. CrabTrap은 실제 트래픽을 재생해 에이전트 업무에 맞는 정책을 자동 제안하고 위험한 요청을 차단한다.
12. Brex는 Corporate AI·Operational AI·Product AI 세 축으로 기업의 AI 사용량을 분석한다.
13. 거래 태깅은 호출당 약 10센트와 월 2만 8,000달러인 반면 분쟁 처리는 약 2달러로 240배 비싸게 표시된다.
14. AI 비용은 모델·직원·호출자·고객별 사용량과 실제 회사 계좌에서 빠져나간 지출을 함께 봐야 한다.
15. Brex는 초기에 엔지니어에게 무제한 토큰 예산을 주고 충분히 탐색한 뒤 캐싱과 모델 선택을 최적화한다.
16. 토큰 과금은 API뿐 아니라 Cursor처럼 토큰을 감싼 제품으로도 발생하므로 단일 모델 전략은 충분하지 않다.
17. AI는 역할을 융합하고 모든 사람을 어느 정도 빌더로 만들며 10배 직원 사이의 생산성 격차를 키울 수 있다.
18. 세계 2,500개 상자 이미지에서 에이전트를 효과적으로 쓰는 사람은 아직 작은 일부에 불과하다.
19. Pedro의 Autopilot은 Slack·이메일·회의록을 신호로 모아 사람과 프로그램별 Markdown 파일을 갱신한다.
20. AI 제품의 높은 기준은 소프트웨어 기능이 아니라 에이전트가 대신 완료한 신뢰할 수 있는 업무 결과를 판매하는 데 있다.