🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

The Most AI-Pilled CEO We Know의 핵심은 AI 전환이 도구 도입이 아니라 CEO가 회사 구조, 보안, 고객 이해, 실행 방식을 처음부터 다시 설계해야 하는 경영 과제라는 점이다.

📌 핵심 요점

1. AI는 엔지니어링 팀의 생산성 도구에 그치지 않고, 회사가 무엇을 할 수 있는지에 대한 자기정체성을 바꾸는 변화로 다뤄진다.
2. 좋은 AI 제품과 내부 시스템은 LLM을 아껴 쓰며 좁게 통제하는 방식보다, 모델·도구·스킬·에이전트 루프를 결합해 실제 업무를 끝까지 수행하게 하는 방향에 가깝다.
3. 기업용 에이전트 도입의 핵심 병목은 단순한 도구 권한 제한이 아니라, HTTP 프록시와 감사 가능한 네트워크 경계, LLM 판정 등을 통해 프로덕션 신뢰를 확보하는 문제다.
4. AI 시대에도 창업자와 CEO가 직접 해야 하는 일은 남는다. 특히 풀 문제를 고르는 판단, 고객이 말하지 않는 신호를 읽는 공감, 모델에 없는 맥락을 주입하는 역할은 여전히 중요하다.
5. AI 네이티브 회사는 기존 프로세스 위에 AI를 붙이는 수준이 아니라, 온보딩·KYC·고객 이해·내부 운영·제품 로드맵까지 “오늘 회사를 다시 만든다면 어떻게 설계할 것인가”라는 관점에서 재구성해야 한다.

🧩 배경과 문제 정의

• AI를 비싼 도구처럼 아껴 쓰거나 지나치게 통제하는 접근은 에이전트의 활용 범위를 좁히고, 더 큰 생산성 전환을 가로막는다.
• 기업의 AI 전환은 엔지니어링 팀만의 과제가 아니다. CEO가 기술의 한계와 가능성을 직접 이해해야 하는 경영 과제에 가깝다.
• 좋은 AI 제품의 핵심은 복잡한 하네스 자체보다 모델, 도구, 스킬, 에이전트 루프를 어떻게 조합하느냐에 있다. 중요한 것은 이를 조직과 제품 운영 방식에 자연스럽게 통합하는 일이다.
• 보안과 권한 문제가 해결되지 않으면 기업 내부에서 에이전트를 적극적으로 활용하기 어렵다. 특히 금융 서비스처럼 민감한 데이터를 다루는 환경에서는 네트워크 경계 통제가 핵심 리스크가 된다.

🕒 시간순 섹션별 상세정리

1. AI 전환은 CEO가 직접 다뤄야 하는 회사 정체성의 문제

• 일상에서 마주치는 문제를 AI로 해결할 수 있는지부터 출발해야 하며, CEO는 기술의 경계와 가능성을 누구보다 깊이 이해해야 한다 [00:06]
• AI는 특정 엔지니어링 팀이나 제품 팀의 업무로 분리하기 어렵고, 회사가 무엇을 할 수 있는지에 대한 자기정체성 자체를 다시 세우는 변화다 [00:21]

2. LLM을 아껴 쓰는 통제형 접근에서 에이전트 루프 중심 접근으로 이동

• 많은 소프트웨어 조직은 LLM을 비싸고 희소한 자원처럼 다루며, 그 결과 에이전트가 좁은 컨텍스트와 세밀한 조건문 안에 갇히는 구조가 생긴다 [01:53]
• 기존 접근은 LLM이 볼 수 있는 정보를 사람이 과도하게 제한하고, 반응 경로까지 일일이 설계하려는 방식에 가깝다 [02:14]

3. 추론 모델과 코딩 하네스가 AI 활용의 임계점을 넘긴 순간

• GPT-3 API는 가능성은 보여줬지만, 오래 지속되는 실용 제품이라기보다 잠깐 실험해보는 연구 결과물에 가까웠다 [03:16]
• 추론 모델과 도구가 결합되며 AI 활용의 흥미가 커졌고, 12월의 모델 진전은 코딩 하네스가 실제로 작동하기 시작한 전환점이 됐다 [03:40]

4. 개인 OpenClaw 실험은 읽기 권한과 자동화 가능성에서 시작됐다

• OpenClaw 활용의 초기 인사이트는 마크다운 설정만으로도 생활과 업무의 여러 흐름을 자동화할 수 있다는 점이었고, 복잡한 시스템 없이도 상당한 범위까지 도달했다 [05:24]
• 영화 티켓 구매를 OpenClaw와 Brex 카드 API로 처리한 사례는 단순한 온라인 예매 대체가 아니라, 에이전트가 실제 작업 흐름을 끝까지 수행할 수 있음을 보여준다 [05:33]

5. 기업용 에이전트 보안은 도구 제한보다 네트워크 경계 통제가 핵심

• Brex 내부의 다음 과제는 에이전트가 실제 시스템에 쓰기 작업을 할 수 있게 만드는 것이었고, 가장 어려운 보안 문제를 해결하는 데 약 4주가 투입됐다 [06:40]
• 도구 호출을 통제하는 OpenShell Pro류 포크만으로는 충분하지 않으며, 에이전트가 잘못된 HTTP 요청을 만들 수 있기 때문에 네트워크 계층의 통제가 필요하다 [07:28]

6. 프로덕션 신뢰를 위해 AI 프록시가 필요해진 배경

• 자격 증명 브로커링 같은 기능은 다른 도구로도 가능하지만, 실제 프로덕션 신뢰 여부를 가르는 핵심은 LLM-as-a-judge 역량이었다 [10:08]
• 보안팀은 엄격한 기준 때문에 초기에는 충분히 신뢰하지 않았고, 프로덕션 사용이 가능하다는 내부 합의를 얻는 과정이 중요한 전환점이 됐다 [10:16]

7. 회사 내부 AI 도입의 세 계층과 비기술 조직용 하네스

• 회사 내부 AI 사용자는 코드를 대량으로 밀어 넣는 토큰 맥서 엔지니어, 평균적 엔지니어, 그리고 검색형 챗봇처럼 AI를 쓰는 나머지 조직으로 나뉜다 [11:07]
• 토큰 맥서의 생산성 상당 부분은 모델 자체보다 코딩 하네스에서 나오며, 비기술 팀에도 그에 상응하는 실행 환경이 필요하다 [11:51]

8. 대화형 업무 실행 사례와 하네스의 역할

• Aqua Voice와 Telegram 또는 Slack의 Claw를 함께 쓰면 여러 사람이 말로 논의한 내용을 에이전트가 받아 실제 작업으로 전환할 수 있다 [13:04]
• Startup School 참석자 20명씩 60개 저녁 모임을 21명의 YC 파트너·방문 파트너와 배정하는 복잡한 운영 문제가 대화 기반 작업 사례로 드러난다 [13:21]

9. 토큰 맥싱이 아직 확산되지 않은 이유와 AI-first 사고방식

• 많은 창업자는 토큰 비용 때문에 사용량을 아끼지만, 저렴한 모델·로컬 LLM·GPU 장비를 활용해 고강도 사용을 실험하는 커뮤니티도 있다 [14:18]
• 비용 부담이 있음에도 Max 플랜 한도에 대한 불만이 거의 없다는 점은, 실제로 토큰을 극단적으로 많이 쓰는 사용자가 아직 많지 않다는 신호에 가깝다 [15:28]

10. AI 시대 회사 구조와 MVP 표면적의 재해석

• 지금 회사를 새로 만든다면 처음부터 “왜 나 혼자서는 안 되는가”라는 질문을 전제로 삼을 수 있고, 이 경우 토큰 소비는 기존 3명·5명·7명 팀 모델보다 훨씬 커질 수 있다 [16:38]
• AI의 핵심 가치는 단순한 비용 절감이 아니라, 회사의 경계가 사람 중심에서 타입 시스템·인터페이스·에이전트 간 상호작용 중심으로 재편되는 데 있다 [17:05]

11. 아이디어 압축과 창업자 판단의 병목

• 좋은 아이디어는 작은 면적에 압축될 수 있어야 하며, AI가 문제를 더 작게 정리하는 데 도움을 줄 수는 있어도 명확한 문제 정의를 대신할 수는 없다 [20:00]
• 회사 안의 아이디어는 “냅킨에 들어갈 정도”로 압축되어야 하며, 설명이 지나치게 크다면 아직 지능적인 압축이 부족하다는 신호다 [20:16]

12. AI 시대에도 고객 신호와 선택의 지혜가 남는다

• 실행은 점점 모델이 더 잘 처리하는 영역으로 이동하지만, 무엇을 선택할지 판단하는 지혜는 여전히 핵심 병목으로 남는다 [21:40]
• AI 시대의 탐색은 초기에 더 넓은 후보군을 볼 수 있게 하지만, 핵심 질문은 “왜 AI가 이 문제를 풀 수 없는가”와 “모델 안에 없는 신호가 무엇인가”로 좁혀진다 [22:14]

13. 암묵지를 읽는 공감 능력과 모델 의존의 한계

• 성공적으로 피벗한 창업자에게는 타인이 무엇을 생각하는지 시뮬레이션하는 루프가 있으며, 고객이 말로 표현하지 못한 욕구를 읽는 공감 능력이 중요하다 [23:30]
• 고객의 미세한 신호는 종종 중얼거림이나 불완전한 표현으로 나타나며, 창업자는 그 안에서 실제 문제가 존재하는지 판단해야 한다 [24:03]

14. 분포 밖 지식 보강과 데이터 회사의 역할

• 질문이 모델의 분포 밖에 있다는 점을 인식할 수 있다면, 사용자는 그 빈틈을 직접 보강해 더 유용한 답을 만들 수 있다 [25:30]
• 데이터 회사들은 LLM의 blind spot을 찾아 보완하려 하지만, 어떤 답이 부족한지 판별하려면 결국 해당 분야 전문가가 필요하다 [25:41]

15. 고객 월드모델과 모델 편향, AI 인프라의 초기성

• Brex는 고객의 대시보드 클릭, 이메일, 통화, 상담 기록 등 모든 접점을 모아 고객 월드모델을 만들고, 고객이 다음에 무엇을 필요로 할지 예측하려 한다 [27:27]
• 고객이 아직 겪지 않은 문제까지 예측하려면 분포 문제를 다뤄야 하며, 모델 내부에 모든 가능한 맥락을 담기에는 메모리와 파라미터의 한계가 있다 [27:53]

16. AI 추론 수요와 토큰 비용 관리의 초기 시장

• 전 세계 인구를 2,500개 점으로 나눈 비유에서 84%는 AI를 한 번도 쓰지 않았고, 16%만 무료 챗봇을 써봤으며, 월 20달러를 내는 사용자는 0.3%에 그친다 [30:10]
• 2,500개 중 한 칸 정도만 에이전트를 실제로 쓰는 수준이기 때문에, 추론 수요에 장기적으로 베팅하는 논리는 현재 침투율이 극히 낮다는 사실에서 출발한다 [30:28]

17. 토큰 소비 격차와 AI 도입의 지역·조직 편차

• Brex 데이터에서 토큰 소비는 증가하고 있으며, 내부 비용 경계가 얼마나 촘촘한지에 따라 토큰 사용량 자체가 달라진다 [31:46]
• 현재 있는 10마일 반경과 뉴욕까지 포함한 일부 지역에서는 토큰 소비가 많고, 데이터상 더 빠른 매출 성장과도 연결될 가능성이 보인다 [32:07]

18. KYC 사례와 문제 경계의 재설계

• AI 도입의 핵심은 기존 문제를 더 잘 푸는 데 그치지 않고, 문제의 정의와 경계가 달라졌는지 한 걸음 물러서서 다시 보는 데 있다 [33:36]
• KYC는 과거에 80% 자동화와 20% 수작업 구조였고, 즉각적인 접근은 남은 수작업을 처리하는 에이전트를 붙이는 방식이었다 [33:58]

19. 맞춤형 AI 워크플로와 생산성 측정의 한계

• Arch Linux와 Ubuntu의 차이처럼, AI도 기본 기능을 쓰는 단계와 자신의 사용 사례에 맞게 깊게 커스터마이즈하는 단계 사이에 문화적 차이가 크다 [35:29]
• OpenClaw와 Hermes는 개인의 사용 사례에 맞춘 설정, 스킬 유지, 마크다운 기반 운영이 필요하고, 제대로 작동하면 매우 강력한 맞춤형 시스템을 만들 수 있다 [35:51]

20. 전기 초기 도입기 비유와 CEO의 AI 리더십

• AI 토큰 비용을 현재 ROI만으로 줄이려는 태도는 전기 발명 6개월 뒤 전기요금이 비싸다는 이유로 증기기관을 더 오래 쓰자는 판단과 비슷한 위험을 가진다 [37:21]
• 전기도 초기에는 성능과 ROI가 좋지 않았고, 사람들을 붙잡은 핵심은 단기 비용 절감이 아니라 새로운 가능성에 대한 호기심과 탐험 욕구였다 [37:52]

21. AI 네이티브 회사는 기존 회사를 처음부터 다시 세우는 문제다

• CEO에게 중요한 질문은 지금의 기술을 창업 당시로 가져갈 수 있다면 회사를 어떻게 다시 만들 것인지이며, 이 비교는 기존 조직 구조와 운영 방식의 차이를 선명하게 드러낸다 [40:13]
• 온보딩, 성장 엔진, 고객 획득, 사용자 커뮤니케이션, 데이터 종합 방식은 처음부터 다시 설계될 수 있으며, 회사의 자기정체성과 기능별 성공 기준까지 재정의된다 [40:40]

22. 조직의 항체를 넘지 못하면 AI 전환은 기존 방식으로 되돌아간다

• 조직 변화에는 일정한 “깨진 유리”가 필요하며, 장애물 제거는 CEO에게 가장 쉽고, 임원에게는 그보다 어렵고, 직원에게는 더 어렵다 [42:15]
• 리스크와 가드레일을 이해한 AI 사용 사례도 회의와 승인 절차에 막히면, 10초 만에 풀릴 일이 10시간의 회의나 영구 보류로 바뀐다 [42:29]

23. 회사형 AGI보다 도메인별 가상 직원 구조가 현실적이다

• 모든 데이터를 단일 회사 모델에 무차별적으로 넣는 방식보다, 특정 고객을 깊이 이해하는 가상 직원처럼 경계와 API가 분명한 도메인별 에이전트가 더 적합하다 [43:57]
• 고객 전체의 문제를 바탕으로 제품 로드맵을 관리하는 에이전트는 고객 이해 에이전트 위에 쌓일 수 있으며, 기능별·도메인별 지식 구조는 여전히 핵심적이다 [44:35]

24. 에이전트는 매일 개선되는 평가 루프를 회사 운영 안에 가져야 한다

• 고객 세계 모델이 영업팀 운영과 CEO의 고객 미팅 준비에 쓰이면, 지원 티켓이나 여행 중 카드 문제 같은 세부 정보까지 계정 이해에 반영된다 [45:38]
• 잘 정의된 고객 이해 문제는 신뢰 가능한 빌딩블록이 되며, 회사 전체 모델은 이런 작은 도메인 모델들을 분해하고 조립하는 방식으로 만들어진다 [46:04]

25. 인간의 병목은 입력 속도와 컨텍스트 구성으로 이동한다

• 개인용 에이전트와 GBrain 실험은 수십만 개의 마크다운 페이지를 다루는 방향으로 확장되며, 과거에는 공상처럼 보였던 개인 지식 기반 AI가 현실적인 도구로 바뀐다 [48:00]
• AI 사용 경험은 Neuralink 같은 인터페이스의 필요성을 다르게 보이게 만들고, 인간의 타이핑 속도와 입력 방식 자체가 병목으로 드러난다 [48:22]

26. 개인 데이터가 에이전트의 판단 재료가 되는 방식

• 서로 직교하거나 무작위처럼 보이는 개념 조합을 수백 개 시도한 뒤 가장 일관된 결과를 순위화하면, 상위 몇 개가 강한 트윗 아이디어로 남는다 [50:01]
• 별도로 건조한 톤을 지시하지 않아도, 과거 상호작용을 바탕으로 만든 soul MD 파일은 개인이 원하는 에이전트 성격을 매우 정확하게 반영한다 [50:22]

27. 창업자는 AI를 전제로 회사와 자신의 역할을 재설계해야 한다

• 전기가 막 발명된 시점에 미래의 전력 소비와 데이터센터까지 안다면 많은 선택이 달라지듯, 현재 AI의 초기 국면도 창업 방식과 의사결정 기준을 바꾸는 출발점이 된다 [51:38]
• 매일 마주치는 문제마다 “왜 AI로 풀 수 없는가”를 먼저 묻고, 챗봇으로 해결되는 80%를 넘어 해결되지 않는 20%의 이유를 파고들 때 기술 가능성의 질감이 분명해진다 [52:08]

🧾 결론

• 이 영상의 중심 메시지는 AI 활용을 비용 절감이나 챗봇 도입으로 축소하지 말고, 회사 운영체제 자체를 바꾸는 문제로 봐야 한다는 것이다.
• CEO는 AI의 가능성과 한계를 매일 직접 경험해야 하며, 조직의 기존 승인 절차와 사회적 마찰을 넘어서는 결정을 끝까지 밀어붙일 수 있는 위치에 있다.
• 에이전트가 실제 업무에 들어오려면 보안, 권한, 네트워크 통제, 평가 루프가 함께 설계되어야 하며, 단순히 모델 성능이 좋아지는 것만으로는 충분하지 않다.
• AI가 실행을 더 많이 맡게 될수록 인간의 병목은 “무엇을 만들 것인가”, “어떤 고객 신호를 믿을 것인가”, “모델이 모르는 맥락을 어떻게 채울 것인가”로 이동한다.
• 검증이 필요한 부분은 Brex 내부 수치, 예컨대 특정 에이전트 요청의 98% 자동 통과, 토큰 소비와 매출 성장의 연결 가능성, 장기 inference 수요 전망 등이다. 이는 영상 속 주장으로 정리할 수는 있지만 외부 데이터로 확인되지는 않았다.

📈 투자·시사 포인트

• AI 인프라의 장기 수요는 단순 사용자 수보다 실제 에이전트 사용량, 토큰 소비, 기업 내부 워크플로 자동화 깊이에 따라 커질 가능성이 있다.
• 기업용 AI 시장에서는 모델 자체뿐 아니라 보안 프록시, 권한 관리, 감사 로그, LLM-as-a-judge, 토큰 비용 귀속, ROI 분석 같은 운영 계층이 중요한 투자 영역으로 부각된다.
• AI 도입 수준이 높은 조직과 낮은 조직 사이에는 생산성뿐 아니라 문제 정의 방식, 고객 온보딩, 내부 의사결정 속도에서 격차가 벌어질 수 있다.
• 단기 ROI만으로 토큰 비용을 줄이려는 접근은 초기 전기 도입기의 가능성을 놓치는 것과 비슷한 위험이 있다는 관점이 제시된다.
• 창업자에게는 “AI로 기존 일을 더 싸게 할 수 있는가”보다 “AI가 가능해진 지금, 문제의 경계와 회사 구조를 어떻게 다시 그릴 것인가”가 더 중요한 질문이 된다.

⚠️ 불확실하거나 확인이 필요한 부분

• “OpenClaw”, “Claw”, “Cloud Code”, “OpenShell Pro”, “Crab Trap”, “Magpie”, “GBrain”, “LSD 모드” 등 여러 도구·프로젝트명이 언급되지만, 입력 정보만으로는 각각이 실제 공개 제품인지, 내부 도구인지, 별칭인지 명확히 구분하기 어렵다.
• Brex 내부 사례로 제시된 채용 에이전트 Jim, KYC 재설계, 고객 월드모델, 토큰 비용 귀속 시스템 Magpie는 영상 내 발화 기반 설명으로 보이며, 실제 운영 규모·정확한 성과·보안 검증 수준은 별도 확인이 필요하다.
• “요청의 98%는 자동 통과하고 2%는 LLM 판정을 거친다”는 수치는 특정 내부 시스템 사례로 제시되었지만, 어떤 기간·트래픽 유형·정책 기준에서 측정된 값인지는 입력 정보만으로 확인되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 조직이나 프로젝트에서 AI를 “비싼 도구”처럼 아껴 쓰고 있는 영역과, 실제로는 더 큰 컨텍스트와 권한을 줘야 효과가 날 수 있는 영역을 구분해 목록화한다.
• 반복 업무 하나를 골라 “챗봇 질의”가 아니라 도구·스킬·권한·에이전트 루프가 포함된 실행형 워크플로로 재설계해본다.
• AI 에이전트에 쓰기 권한을 부여하기 전, 도구 단위 제한뿐 아니라 HTTP 프록시·네트워크 경계·감사 로그·승인 정책을 포함한 보안 구조를 검토한다.
• 팀 내부 사용자를 고강도 AI 사용자, 평균적 엔지니어, 검색형 챗봇 사용자로 나누고 각 그룹에 필요한 하네스와 교육 방식을 다르게 설계한다.

❓ 열린 질문

• AI 에이전트에게 더 큰 권한과 컨텍스트를 주는 것과, 보안·프라이버시·규제 리스크를 통제하는 것 사이의 적정 균형은 어디에 있어야 할까?
• 조직 내에서 CEO가 직접 AI 활용의 한계와 가능성을 체험하지 않으면, AI 전환은 어느 지점에서 기존 프로세스에 흡수되어 멈추게 될까?
• 비기술 조직을 위한 “코딩 하네스에 해당하는 AI 실행 환경”은 구체적으로 어떤 인터페이스와 권한 구조를 가져야 할까?