2-3년전 Chat GPT Wrapper로 시작한 기업들 중 고유 데이터를 가지고 Agent first로 전환한 곳들은 살아남고 그렇지 않은 곳들은 더 많은 성장을 만들기 어려울 것 같다. 프론티어 모델을 활용한 비즈니스가 살아남는 건 결국 고유한 데이터와 그것을 기반으로한 워크플로우 장악(AI Agent 배포)이 아닐까?
기존 AI Wrapper가 RAG+ AI API+제품개발이었다면 이젠 고객이 업무하는 기능별로 Agent 기획/개발, 고객이 사용하는 맥락 데이터 구축, Agent의 성능을 높일 수 있는 평가를 사용해서 이터레이션 돌면서 정말 쓸만한 수준을 제공할 수 있는가(Claude Code 쓰는 것보다 좋은가?)를 통과하는 곳들이 각 버티컬을 리딩할 수 있다.
Anthropic이 Claude Code+ Cowork 로 개발자+비개발자까지 커버하는 Horizontal Layer를 차지하겠지만 산업은 너무 크다. 막상 미국, 캐나다, 영국 로펌 변호사들 만나서 이야기해보면 AI Wrapper Tool도 이제 막 쓰고 있는 상황인 곳들도 많고.
올해는 정말 Agent의 세상이고 또 어떤 새로운 제품/회사들이 나올까 기대되고 내가 풀 문제도 기대된다. 이번 웨이브 재밌게 타봅시다!
Q: AI 인재 전쟁은 얼마나 심각하며, 윈스턴은 AI 애플리케이션 기업의 미래를 어떻게 예측하나요?
A: 인재 전쟁은 "놀랍도록 치열합니다." 그는 처음에 모델을 감싸는 "래퍼"였던 AI 애플리케이션 기업들이 두 가지 방식으로 진화할 것이라고 예측합니다. 1. 그들은 차별화된 핵심 비(非) AI 소프트웨어를 더 많이 구축할 것입니다. 2. 그들은 독점 데이터에 접근하게 될 것이며, 이는 모델이 더 이상 전체 제품이 아니므로 맞춤형 솔루션과 차별화된 제품을 만들기 위해 더 많은 AI 인재를 고용해야 함을 의미합니다.
https://www.youtube.com/watch?v=PhbVnUBmygA
기존 AI Wrapper가 RAG+ AI API+제품개발이었다면 이젠 고객이 업무하는 기능별로 Agent 기획/개발, 고객이 사용하는 맥락 데이터 구축, Agent의 성능을 높일 수 있는 평가를 사용해서 이터레이션 돌면서 정말 쓸만한 수준을 제공할 수 있는가(Claude Code 쓰는 것보다 좋은가?)를 통과하는 곳들이 각 버티컬을 리딩할 수 있다.
Anthropic이 Claude Code+ Cowork 로 개발자+비개발자까지 커버하는 Horizontal Layer를 차지하겠지만 산업은 너무 크다. 막상 미국, 캐나다, 영국 로펌 변호사들 만나서 이야기해보면 AI Wrapper Tool도 이제 막 쓰고 있는 상황인 곳들도 많고.
올해는 정말 Agent의 세상이고 또 어떤 새로운 제품/회사들이 나올까 기대되고 내가 풀 문제도 기대된다. 이번 웨이브 재밌게 타봅시다!
Q: AI 인재 전쟁은 얼마나 심각하며, 윈스턴은 AI 애플리케이션 기업의 미래를 어떻게 예측하나요?
A: 인재 전쟁은 "놀랍도록 치열합니다." 그는 처음에 모델을 감싸는 "래퍼"였던 AI 애플리케이션 기업들이 두 가지 방식으로 진화할 것이라고 예측합니다. 1. 그들은 차별화된 핵심 비(非) AI 소프트웨어를 더 많이 구축할 것입니다. 2. 그들은 독점 데이터에 접근하게 될 것이며, 이는 모델이 더 이상 전체 제품이 아니므로 맞춤형 솔루션과 차별화된 제품을 만들기 위해 더 많은 AI 인재를 고용해야 함을 의미합니다.
https://www.youtube.com/watch?v=PhbVnUBmygA
YouTube
Harvey CEO Winston Weinberg: How to Make Mega Deals | Lessons from Rabois, Halligan & Grady
Winston Weinberg is the CEO and Co-Founder of Harvey, the leading professional services platform engineered with AI for law, tax, and finance. Winston has raised over $980M for Harvey from Sequoia, a16z, GV, Elad Gil and more with a last round price of $9.2BN…
❤1
배워라! 돈 보다 성장/ 임팩트. 같이하는 사람을 통해서 내가 완전히 새로운 관점, 역량을 갖출 수 있는가?
성실히 오래. 죽음만이 은퇴인 삶을 살고싶다!
변화의 물결에 기대기. 블룸버그도 40대 초반 회사가 인수되면서 얻은 자금으로 월가가 “즉시성·정확성·계산 가능성”이 있는 고품질 시장정보에 프리미엄을 낼 것이라는 가설으로 회사를 시작했다.
초기 제품은 단순 뉴스가 아니라 실시간 시장데이터 + 분석/계산 + 화면/키보드 중심의 조작 UX를 제공했고 그게 성장과 변화를 거쳐 지금의 블과장이 되었다.
지금처럼 에이전트에게 일을 시키고 관리하고 음성으로 컴퓨터에게 일을 시키는 세상에서 새로운 기회들이 생겨나고 있다.
실패를 두려워 말자.
성실히 오래. 죽음만이 은퇴인 삶을 살고싶다!
변화의 물결에 기대기. 블룸버그도 40대 초반 회사가 인수되면서 얻은 자금으로 월가가 “즉시성·정확성·계산 가능성”이 있는 고품질 시장정보에 프리미엄을 낼 것이라는 가설으로 회사를 시작했다.
초기 제품은 단순 뉴스가 아니라 실시간 시장데이터 + 분석/계산 + 화면/키보드 중심의 조작 UX를 제공했고 그게 성장과 변화를 거쳐 지금의 블과장이 되었다.
지금처럼 에이전트에게 일을 시키고 관리하고 음성으로 컴퓨터에게 일을 시키는 세상에서 새로운 기회들이 생겨나고 있다.
실패를 두려워 말자.
Forwarded from BZCF | 비즈까페
블룸버그 터미널 할 때, 그 블룸버그 만든 마이클 블룸버그 맞습니다. 뉴욕 전 시장이기도 하고요. 나이가 있지만 활기가 엄청납니다. (1942년생)
눈길 조심하시길 바랍니다. 즐거운 주말들 되세요.
https://youtu.be/GBNBN4K-Osc?si=4MUV4quu_hqudSIR
눈길 조심하시길 바랍니다. 즐거운 주말들 되세요.
https://youtu.be/GBNBN4K-Osc?si=4MUV4quu_hqudSIR
YouTube
"돈이 전부가 아니야" (마이클 블룸버그)
Translated by A
DISCLAIMER
- The copyright of the original video belongs to the original copyright holder.
- We check the copyright permission through the YouTube system, and if it is not confirmed within the system, we proceed with the translation work…
DISCLAIMER
- The copyright of the original video belongs to the original copyright holder.
- We check the copyright permission through the YouTube system, and if it is not confirmed within the system, we proceed with the translation work…
👍1
최근 X에서 바이럴 되는 Clawdbot.
내 기기(로컬/서버)에서 직접 돌리는 개인 AI 비서다. 핵심은 두 가지: (1) Claude/GPT/Gemini 같은 모델을 붙여 “에이전트”로 쓰고, (2) 그 에이전트와의 대화를 Telegram/iMessage/WhatsApp/Slack/Discord 같은 메신저에서 하게 만드는 “게이트웨이”를 제공한다.
클로드 코드를 보면서 AI 모델은 이미 똑똑하니 제대로 된 컨텍스트와 쓸만한 하니스를 주는게 중요하다는 것을 알았다.
Clawdbot은 로컬에서 돌아가니 설정/기억/스킬이 파일(폴더·Markdown)로 남아 사용자가 직접 고치거나, 봇에게 고치게 하면서 계속 진화시킬 수 있다(=내가 만드는 비서 느낌).
그리고 메신저 UI + 음성 + 개인 컨텍스트(캘린더/노션/투두 등) + 크론/자동화 + 도구 실행이 결합되면, 사람들이 Siri에 기대했던 “내 맥락을 이해하고 내 의도대로 움직일 수 있는 실행 파트너” 경험을 줄 수 있다.
뭐든 다 되는 건 아니지만 이런 경험도 지금 수준에서 제공할 수 있고 그정도로도 고객은 와우할 수 있다는 거.
세상은 여기저기 흩뜨러진 데이터로 이루어져있고 이런 데이터를 문제 정의와 솔루션으로 엮어내는 것이 사람들이 해왔던 일이다.
예전엔 사람이 가서 문제 정의하고 데이터 모으고 클렌징하고 모델 학습시키는 이런 것들을 AI 모델을 풀어놓으면 얘네가 알아서 문제 정의하고 데이터 클렌징하고 파이프라인 만들고 모델 가져와서 원하는 의도대로 파인튜닝하고 이 루프를 돌리는 게 지금도 가능하네?
모델이 더 좋아지면? 컨텍스트 데이터 관리가 더 편해지면? 의도만 주면 그 의도에 맞게 데이터 세팅하고 모델 파인튜닝/강화학습하는 파이프라인/툴을 스스로 이용해서 개선할 수 있다면?
미래가 멀리 있지 않구나. 물론 현실과 연구 그리고 제품과 갭이 있고 그걸 잘 엮는 사람들에게 새로운 기회들이 있는 시기다.
https://news.hada.io/topic?id=26122
https://x.com/heyshrutimishra/status/2015327280911073789?s=46&t=h5Byg6Wosg8MJb4pbPSDow
내 기기(로컬/서버)에서 직접 돌리는 개인 AI 비서다. 핵심은 두 가지: (1) Claude/GPT/Gemini 같은 모델을 붙여 “에이전트”로 쓰고, (2) 그 에이전트와의 대화를 Telegram/iMessage/WhatsApp/Slack/Discord 같은 메신저에서 하게 만드는 “게이트웨이”를 제공한다.
클로드 코드를 보면서 AI 모델은 이미 똑똑하니 제대로 된 컨텍스트와 쓸만한 하니스를 주는게 중요하다는 것을 알았다.
Clawdbot은 로컬에서 돌아가니 설정/기억/스킬이 파일(폴더·Markdown)로 남아 사용자가 직접 고치거나, 봇에게 고치게 하면서 계속 진화시킬 수 있다(=내가 만드는 비서 느낌).
그리고 메신저 UI + 음성 + 개인 컨텍스트(캘린더/노션/투두 등) + 크론/자동화 + 도구 실행이 결합되면, 사람들이 Siri에 기대했던 “내 맥락을 이해하고 내 의도대로 움직일 수 있는 실행 파트너” 경험을 줄 수 있다.
뭐든 다 되는 건 아니지만 이런 경험도 지금 수준에서 제공할 수 있고 그정도로도 고객은 와우할 수 있다는 거.
세상은 여기저기 흩뜨러진 데이터로 이루어져있고 이런 데이터를 문제 정의와 솔루션으로 엮어내는 것이 사람들이 해왔던 일이다.
예전엔 사람이 가서 문제 정의하고 데이터 모으고 클렌징하고 모델 학습시키는 이런 것들을 AI 모델을 풀어놓으면 얘네가 알아서 문제 정의하고 데이터 클렌징하고 파이프라인 만들고 모델 가져와서 원하는 의도대로 파인튜닝하고 이 루프를 돌리는 게 지금도 가능하네?
모델이 더 좋아지면? 컨텍스트 데이터 관리가 더 편해지면? 의도만 주면 그 의도에 맞게 데이터 세팅하고 모델 파인튜닝/강화학습하는 파이프라인/툴을 스스로 이용해서 개선할 수 있다면?
미래가 멀리 있지 않구나. 물론 현실과 연구 그리고 제품과 갭이 있고 그걸 잘 엮는 사람들에게 새로운 기회들이 있는 시기다.
https://news.hada.io/topic?id=26122
https://x.com/heyshrutimishra/status/2015327280911073789?s=46&t=h5Byg6Wosg8MJb4pbPSDow
GeekNews
OpenClaw - 모든 OS와 플랫폼에서 작동하는 개인용 AI 비서 | GeekNews
사용자 컴퓨터에서 실행되어 쉘 & 파일 시스템 접근권한 및 컴퓨터 제어 능력을 가진 LLM 기반 에이전트인박스 정리, 메일 보내기, 캘린더 관리, 브라우징(입력 & 데이터 추출) 등 모든 제어 가능별도 앱 설치 없이 기존에 사용하던 대부분의 메시징 플랫폼을 통해 대화 가능 (슬랙, 텔레그램, 디스코드, 왓츠앱, ..)모든 설정·선호도·사용자 메모리·지침이
❤1
Continuous Learning_Startup & Investment
AI Agent Orchestration: 지식노동의 새로운 컨베이어 벨트 개인이 군단을 이끄는 시대 "Claude Code 쓰면 생산성 5-10배 올라요." 6개월 전만 해도 이런 말에 "과장 아니야?"라는 반응이 많았다. 지금은 다르다. 다들 고개를 끄덕이는 걸 넘어서, 개발자로서의 정체성을 고민하고 앞으로 살아남을 수 있을지 걱정하는 분위기다. Copilot에서 Cursor로, 다시 Claude Code로. 코딩 도구의 진화는 자동완성 수준을…
2,000개의 AI 에이전트는 어떻게 1주일 만에 브라우저를 만들었나?
Cursor 팀은 최근 최대 2,000개의 AI 에이전트를 동시에 가동하여, 약 1주일(실제 연구 기간 포함 3-4주) 만에 100만 라인이 넘는 Rust 코드 기반의 브라우저 엔진을 만들어내는 실험에 성공했습니다.
프로젝트의 핵심 목표: "선형적 확장(Linear Scaling)"
현재의 단일 코딩 에이전트(Single Agent)는 특정 작업은 잘 수행하지만, 복잡하고 거대한 소프트웨어를 구축하기에는 속도가 너무 느립니다.
가설: 에이전트(컴퓨팅 자원)를 10개, 100개, 1,000개로 늘리면 개발 속도도 그에 비례해서 빨라질까?
도전 과제: 수천 개의 에이전트가 서로의 발을 밟지 않고 하나의 코드베이스에서 작업하게 만드는 '조직화(Coordination)' 문제 해결.
2. 아키텍처의 진화: 수평 구조에서 위계 구조로
연구팀은 에이전트를 조직하는 방식에서 큰 시행착오를 겪었습니다.
초기 시도 (수평 구조 - 실패):
모든 에이전트에게 동등한 권한을 주고, 공유 파일(Lock)을 통해 작업을 선점하게 했습니다.
결과: 에이전트들이 서로 Lock을 걸고 기다리느라 병목이 생겼습니다. 또한, 책임자가 없다 보니 어려운 작업은 피하고 쉽고 안전한 수정만 하려는 '위험 회피(Risk-averse)' 성향을 보였습니다. 20개를 돌렸는데 실제 속도는 2~3개 수준으로 떨어졌습니다.
최종 해결책 (Planner-Worker 위계 구조 - 성공):
기획자(Planners): 코드를 직접 짜지 않고 전체적인 설계를 하고 하위 작업을 생성합니다. 재귀적으로 하위 기획자를 또 만들어서 업무 범위를 쪼갭니다.
작업자(Workers): 전체 그림을 신경 쓰지 않습니다. 할당받은 아주 구체적이고 좁은 작업 하나만 수행하고 코드를 푸시합니다.
결과: 이 구조를 통해 최대 2,000개의 에이전트가 충돌 없이 병렬로 작업할 수 있었습니다.
3. 실행 환경 및 기술 스택
수천 개의 에이전트를 제어하기 위해 독자적인 'Harness(제어 장치)'를 구축했습니다.
1. 모델 선택: GPT-5.2가 주로 사용되었습니다. Opus 4.5도 테스트했으나, Opus는 작업을 너무 일찍 끝내버리거나 편한 지름길을 택하는 경향이 있어, 끈기 있게 지시를 따르는 GPT-5.2가 장기 자율 작업에 더 적합했습니다.
2. 컨텍스트 관리: 복잡한 To-Do 리스트 대신 '스크래치패드(Scratchpad)'라는 단순한 파일을 사용하여, 에이전트들이 현재 상태와 진행 상황을 지속적으로 기록하게 했습니다.
3. 충돌 해결 (Optimistic Concurrency): '통합 관리자(Integrator)' 에이전트를 두어 병합을 관리하려 했으나 이것 역시 병목이 되었습니다. 대신 낙관적 동시성 방식을 택해, 각 작업자가 코드를 푸시할 때 충돌이 나면 해당 작업자가 알아서 해결하도록 했습니다.
4. 피드백 루프: 왜 하필 '브라우저'를 만들었나?
에이전트가 장시간 혼자 작업하면 코드가 엉뚱한 방향으로 흘러가는 'Drift(표류)' 현상이 발생합니다. 이를 막기 위해 확실한 외부 기준(Grounding)이 필요했습니다.
명확한 스펙(Spec): 브라우저는 HTML, CSS 같은 국제 표준 문서가 명확히 존재합니다. 에이전트에게 "이 스펙 문서를 참고해"라고 지시하면 환각을 줄일 수 있습니다.
시각적 검증: 렌더링 된 화면을 캡처하여 원본과 비교(Visual Diff)하는 방식으로 에이전트 스스로 디버깅이 가능합니다.
Rust 컴파일러: Rust 언어의 엄격함이 오히려 도움이 되었습니다. 컴파일이 된다는 것 자체가 강력한 1차 검증(Guardrail) 역할을 해주기 때문입니다.
5. 흥미로운 에이전트의 행동 패턴 (Emergent Behaviors)
수천 개의 에이전트가 돌아가면서 사람 개발팀과 유사하거나 놀라운 행동들이 관찰되었습니다.
1. 완벽보다는 속도: 모든 커밋이 100% 완벽하게 컴파일될 필요는 없었습니다. 작은 오류가 발생해도, 뒤따르는 에이전트들이 엄청난 속도로 고쳐나가는 것이 전체 프로젝트 속도(Throughput) 면에서 훨씬 유리했습니다.
2. 스스로 내리는 의사결정:
JavaScript 엔진을 직접 구현하는 작업이 지지부진하자, 한 에이전트가 자신의 작업을 끝내기 위해 스스로 외부 오픈소스 C 라이브러리(QuickJS)를 가져와서 연결해버렸습니다. (동료가 일을 안 하니 외부 솔루션을 도입해버린 셈)
기능 구현이 덜 된 부분은 스스로 판단하여 'Feature Flag(기능 스위치)'를 만들어 비활성화 처리했습니다.
타이트한 시간 제한(Timeout)을 걸어두자, 시간 내에 작업을 마치기 위해 에이전트들이 강제로 코드를 최적화하는 현상도 보였습니다.
6. 최종 성과
이 프로젝트의 결과물인 FastRender는 단순한 데모가 아닙니다.
규모: 100만 라인 이상의 Rust 코드, 30,000개 이상의 커밋.
기능: 위키피디아, 깃허브, CNN 같은 실제 웹사이트를 렌더링할 수 있으며, CSS 레이아웃, 테이블, HTML 파싱 등을 수행합니다.
확장성: 이 시스템은 브라우저뿐만 아니라, 윈도우 7 에뮬레이터(120만 라인), 엑셀 클론(160만 라인) 제작 등 다른 대규모 프로젝트에도 성공적으로 적용되었습니다.
이 실험은 AI 코딩의 미래가 단순히 "더 똑똑한 모델 하나"에 있지 않음을 보여줍니다.
핵심은 "수많은 모델을 어떻게 조직화(Organization)하고, 어떻게 일을 나누며(Planning), 어떻게 검증(Feedback)할 것인가"에 있습니다. 적절한 구조만 갖춰진다면, AI 에이전트 군단은 이미 수개월 치의 엔지니어링 작업을 단 며칠 만에 해치울 수 있는 단계에 와 있습니다.
https://cursor.com/blog/scaling-agents
https://www.youtube.com/watch?v=bKrAcTf2pL4
Cursor 팀은 최근 최대 2,000개의 AI 에이전트를 동시에 가동하여, 약 1주일(실제 연구 기간 포함 3-4주) 만에 100만 라인이 넘는 Rust 코드 기반의 브라우저 엔진을 만들어내는 실험에 성공했습니다.
프로젝트의 핵심 목표: "선형적 확장(Linear Scaling)"
현재의 단일 코딩 에이전트(Single Agent)는 특정 작업은 잘 수행하지만, 복잡하고 거대한 소프트웨어를 구축하기에는 속도가 너무 느립니다.
가설: 에이전트(컴퓨팅 자원)를 10개, 100개, 1,000개로 늘리면 개발 속도도 그에 비례해서 빨라질까?
도전 과제: 수천 개의 에이전트가 서로의 발을 밟지 않고 하나의 코드베이스에서 작업하게 만드는 '조직화(Coordination)' 문제 해결.
2. 아키텍처의 진화: 수평 구조에서 위계 구조로
연구팀은 에이전트를 조직하는 방식에서 큰 시행착오를 겪었습니다.
초기 시도 (수평 구조 - 실패):
모든 에이전트에게 동등한 권한을 주고, 공유 파일(Lock)을 통해 작업을 선점하게 했습니다.
결과: 에이전트들이 서로 Lock을 걸고 기다리느라 병목이 생겼습니다. 또한, 책임자가 없다 보니 어려운 작업은 피하고 쉽고 안전한 수정만 하려는 '위험 회피(Risk-averse)' 성향을 보였습니다. 20개를 돌렸는데 실제 속도는 2~3개 수준으로 떨어졌습니다.
최종 해결책 (Planner-Worker 위계 구조 - 성공):
기획자(Planners): 코드를 직접 짜지 않고 전체적인 설계를 하고 하위 작업을 생성합니다. 재귀적으로 하위 기획자를 또 만들어서 업무 범위를 쪼갭니다.
작업자(Workers): 전체 그림을 신경 쓰지 않습니다. 할당받은 아주 구체적이고 좁은 작업 하나만 수행하고 코드를 푸시합니다.
결과: 이 구조를 통해 최대 2,000개의 에이전트가 충돌 없이 병렬로 작업할 수 있었습니다.
3. 실행 환경 및 기술 스택
수천 개의 에이전트를 제어하기 위해 독자적인 'Harness(제어 장치)'를 구축했습니다.
1. 모델 선택: GPT-5.2가 주로 사용되었습니다. Opus 4.5도 테스트했으나, Opus는 작업을 너무 일찍 끝내버리거나 편한 지름길을 택하는 경향이 있어, 끈기 있게 지시를 따르는 GPT-5.2가 장기 자율 작업에 더 적합했습니다.
2. 컨텍스트 관리: 복잡한 To-Do 리스트 대신 '스크래치패드(Scratchpad)'라는 단순한 파일을 사용하여, 에이전트들이 현재 상태와 진행 상황을 지속적으로 기록하게 했습니다.
3. 충돌 해결 (Optimistic Concurrency): '통합 관리자(Integrator)' 에이전트를 두어 병합을 관리하려 했으나 이것 역시 병목이 되었습니다. 대신 낙관적 동시성 방식을 택해, 각 작업자가 코드를 푸시할 때 충돌이 나면 해당 작업자가 알아서 해결하도록 했습니다.
4. 피드백 루프: 왜 하필 '브라우저'를 만들었나?
에이전트가 장시간 혼자 작업하면 코드가 엉뚱한 방향으로 흘러가는 'Drift(표류)' 현상이 발생합니다. 이를 막기 위해 확실한 외부 기준(Grounding)이 필요했습니다.
명확한 스펙(Spec): 브라우저는 HTML, CSS 같은 국제 표준 문서가 명확히 존재합니다. 에이전트에게 "이 스펙 문서를 참고해"라고 지시하면 환각을 줄일 수 있습니다.
시각적 검증: 렌더링 된 화면을 캡처하여 원본과 비교(Visual Diff)하는 방식으로 에이전트 스스로 디버깅이 가능합니다.
Rust 컴파일러: Rust 언어의 엄격함이 오히려 도움이 되었습니다. 컴파일이 된다는 것 자체가 강력한 1차 검증(Guardrail) 역할을 해주기 때문입니다.
5. 흥미로운 에이전트의 행동 패턴 (Emergent Behaviors)
수천 개의 에이전트가 돌아가면서 사람 개발팀과 유사하거나 놀라운 행동들이 관찰되었습니다.
1. 완벽보다는 속도: 모든 커밋이 100% 완벽하게 컴파일될 필요는 없었습니다. 작은 오류가 발생해도, 뒤따르는 에이전트들이 엄청난 속도로 고쳐나가는 것이 전체 프로젝트 속도(Throughput) 면에서 훨씬 유리했습니다.
2. 스스로 내리는 의사결정:
JavaScript 엔진을 직접 구현하는 작업이 지지부진하자, 한 에이전트가 자신의 작업을 끝내기 위해 스스로 외부 오픈소스 C 라이브러리(QuickJS)를 가져와서 연결해버렸습니다. (동료가 일을 안 하니 외부 솔루션을 도입해버린 셈)
기능 구현이 덜 된 부분은 스스로 판단하여 'Feature Flag(기능 스위치)'를 만들어 비활성화 처리했습니다.
타이트한 시간 제한(Timeout)을 걸어두자, 시간 내에 작업을 마치기 위해 에이전트들이 강제로 코드를 최적화하는 현상도 보였습니다.
6. 최종 성과
이 프로젝트의 결과물인 FastRender는 단순한 데모가 아닙니다.
규모: 100만 라인 이상의 Rust 코드, 30,000개 이상의 커밋.
기능: 위키피디아, 깃허브, CNN 같은 실제 웹사이트를 렌더링할 수 있으며, CSS 레이아웃, 테이블, HTML 파싱 등을 수행합니다.
확장성: 이 시스템은 브라우저뿐만 아니라, 윈도우 7 에뮬레이터(120만 라인), 엑셀 클론(160만 라인) 제작 등 다른 대규모 프로젝트에도 성공적으로 적용되었습니다.
이 실험은 AI 코딩의 미래가 단순히 "더 똑똑한 모델 하나"에 있지 않음을 보여줍니다.
핵심은 "수많은 모델을 어떻게 조직화(Organization)하고, 어떻게 일을 나누며(Planning), 어떻게 검증(Feedback)할 것인가"에 있습니다. 적절한 구조만 갖춰진다면, AI 에이전트 군단은 이미 수개월 치의 엔지니어링 작업을 단 며칠 만에 해치울 수 있는 단계에 와 있습니다.
https://cursor.com/blog/scaling-agents
https://www.youtube.com/watch?v=bKrAcTf2pL4
Cursor
Scaling long-running autonomous coding
We've been experimenting with running coding agents autonomously for weeks at a time.
❤3
Continuous Learning_Startup & Investment
🤯 딜레마: 왜 내 코드는 자꾸 '쓸려나갈까'? 컴퓨팅과 데이터의 힘이 알고리즘을 이긴다는 "The Bitter Lesson"은 현실입니다. 특정 모델(예: GPT-4)의 단점을 보완하려 만든 복잡한 '하니스(harness)'는, 더 똑똑한 다음 모델에겐 불필요해지죠. 이것이 우리 코드가 '쓸려나가는' 이유입니다. 👉 핵심: 모델의 약점을 임시로 때우는 게 아니라, 모델을 언제든 갈아 끼울 수 있는 시스템을 만들어야 합니다. 핵심…
모델이 3개월 6개월마다 바뀔 때 하니스를 어떻게 구현할 것인가?
현대 agent 시스템에서 “지능”이 들어갈 곳은 두 군데:
1. 모델(사전학습+RL 등으로 학습된 능력)
2. 하니스(워크플로, 라우터, 서브에이전트, 도구, 핸드오프, 코드 실행 등)
많은 팀이 “모델이 아직 불안정 → 하니스에 신뢰성을 박자”로 가는데, 이는 장기적으로 “스케일되는 곳(모델)”에서 “스케일 안 되는 곳(맞춤 scaffolding)”로 복잡도를 이동시키는 위험이 있다.
모델 성능이 2배 좋아졌을 때, 하니스가 급격히 단순/저렴/안정**해지는가? 아니면 그래프/규칙/역할이 그대로 남는가?
안티패턴
Workflow Trap (워크플로 함정)
- Anthropic은 “워크플로(사전정의된 경로)”와 “에이전트(모델이 동적으로 도구/과정을 결정)”를 구분하며, 워크플로는 예측 가능하지만 에이전트는 더 유연하다고 정리한다.
- 드래그앤드롭 그래프(“research→summarize→draft”)는 지금의 모델 실패모드에 맞춰 **조직/코드가 고착**되기 쉬워, 모델이 좋아져도 시스템이 덜 복잡해지지 않는다.
Specialized Subagent Illusion (고정 역할 서브에이전트 환상)
- Researcher/Coder/Writer 같은 **고정 역할**은 인간 조직의 제약(인지 한계/커뮤니케이션 비용)을 그대로 수입할 위험이 있다.
- “전문가 구성을 아키텍처에 ‘고정’하지 말라”
단순 루프의 확장 한계
- “LLM+while loop+tools면 충분”은 단기엔 단순하지만, 스케일링 노브가 반복 횟수로 단일화되면 병렬화/구조화/컴퓨트 배분이 어려워 토큰 낭비가 커질 수 있다.
- 태스크 난이도↑에 따라 (a) 평균 iteration 수, (b) 성공률, (c) 비용이 어떻게 스케일되는지—특히 병렬 분기 없이 감당 가능한지.
Bitter Lesson Align인가?
Dynamic Subagent Spawning (동적 서브에이전트 생성)
- Anthropic의 멀티 에이전트 리서치 시스템은 리드 에이전트가 계획을 세우고, 병렬 서브에이전트를 만들어 탐색/수집을 수행하는 구조를 설명한다.
- LangChain의 Deep Agents는 서브에이전트/파일시스템/프롬프트/툴을 조합해 “더 길고 깊은 작업”을 수행하는 패턴을 제시한다.
- 핵심은 “팀 구조를 미리 정해두는 것”이 아니라, 추론-시간(inference-time) 탐색으로 분해를 ‘찾게’ 하여 컴퓨트를 더 좋은 의사결정으로 바꾸는 것.
RLM(Recursive Language Models): 긴 컨텍스트를 ‘환경’으로 보고 재귀적으로 다룸
- RLM 논문은 긴 프롬프트를 외부 환경으로 두고, 모델이 코드/재귀 호출로 필요한 부분을 선택적으로 조사·분해하는 일반 추론 전략을 제안한다.
- Prime Intellect는 RLM을 “2026 패러다임”으로 강조하며 자체 구현/환경을 언급한다.
- 에세이는 RLM을 “워크플로 고정”보다 Bitter Lesson에 더 맞는 예로 본다: 더 많은 컴퓨트가 재귀 깊이/분해 granularity/선택적 읽기 같은 다차원 노브로 연결되기 때문.
https://x.com/buckeyevn/status/2014171253045960803
현대 agent 시스템에서 “지능”이 들어갈 곳은 두 군데:
1. 모델(사전학습+RL 등으로 학습된 능력)
2. 하니스(워크플로, 라우터, 서브에이전트, 도구, 핸드오프, 코드 실행 등)
많은 팀이 “모델이 아직 불안정 → 하니스에 신뢰성을 박자”로 가는데, 이는 장기적으로 “스케일되는 곳(모델)”에서 “스케일 안 되는 곳(맞춤 scaffolding)”로 복잡도를 이동시키는 위험이 있다.
모델 성능이 2배 좋아졌을 때, 하니스가 급격히 단순/저렴/안정**해지는가? 아니면 그래프/규칙/역할이 그대로 남는가?
안티패턴
Workflow Trap (워크플로 함정)
- Anthropic은 “워크플로(사전정의된 경로)”와 “에이전트(모델이 동적으로 도구/과정을 결정)”를 구분하며, 워크플로는 예측 가능하지만 에이전트는 더 유연하다고 정리한다.
- 드래그앤드롭 그래프(“research→summarize→draft”)는 지금의 모델 실패모드에 맞춰 **조직/코드가 고착**되기 쉬워, 모델이 좋아져도 시스템이 덜 복잡해지지 않는다.
Specialized Subagent Illusion (고정 역할 서브에이전트 환상)
- Researcher/Coder/Writer 같은 **고정 역할**은 인간 조직의 제약(인지 한계/커뮤니케이션 비용)을 그대로 수입할 위험이 있다.
- “전문가 구성을 아키텍처에 ‘고정’하지 말라”
단순 루프의 확장 한계
- “LLM+while loop+tools면 충분”은 단기엔 단순하지만, 스케일링 노브가 반복 횟수로 단일화되면 병렬화/구조화/컴퓨트 배분이 어려워 토큰 낭비가 커질 수 있다.
- 태스크 난이도↑에 따라 (a) 평균 iteration 수, (b) 성공률, (c) 비용이 어떻게 스케일되는지—특히 병렬 분기 없이 감당 가능한지.
Bitter Lesson Align인가?
Dynamic Subagent Spawning (동적 서브에이전트 생성)
- Anthropic의 멀티 에이전트 리서치 시스템은 리드 에이전트가 계획을 세우고, 병렬 서브에이전트를 만들어 탐색/수집을 수행하는 구조를 설명한다.
- LangChain의 Deep Agents는 서브에이전트/파일시스템/프롬프트/툴을 조합해 “더 길고 깊은 작업”을 수행하는 패턴을 제시한다.
- 핵심은 “팀 구조를 미리 정해두는 것”이 아니라, 추론-시간(inference-time) 탐색으로 분해를 ‘찾게’ 하여 컴퓨트를 더 좋은 의사결정으로 바꾸는 것.
RLM(Recursive Language Models): 긴 컨텍스트를 ‘환경’으로 보고 재귀적으로 다룸
- RLM 논문은 긴 프롬프트를 외부 환경으로 두고, 모델이 코드/재귀 호출로 필요한 부분을 선택적으로 조사·분해하는 일반 추론 전략을 제안한다.
- Prime Intellect는 RLM을 “2026 패러다임”으로 강조하며 자체 구현/환경을 언급한다.
- 에세이는 RLM을 “워크플로 고정”보다 Bitter Lesson에 더 맞는 예로 본다: 더 많은 컴퓨트가 재귀 깊이/분해 granularity/선택적 읽기 같은 다차원 노브로 연결되기 때문.
https://x.com/buckeyevn/status/2014171253045960803
X (formerly Twitter)
Minh Pham (@buckeyevn) on X
Why Most Agent Harnesses Are Not Bitter Lesson Pilled
Continuous Learning_Startup & Investment
최근 X에서 바이럴 되는 Clawdbot. 내 기기(로컬/서버)에서 직접 돌리는 개인 AI 비서다. 핵심은 두 가지: (1) Claude/GPT/Gemini 같은 모델을 붙여 “에이전트”로 쓰고, (2) 그 에이전트와의 대화를 Telegram/iMessage/WhatsApp/Slack/Discord 같은 메신저에서 하게 만드는 “게이트웨이”를 제공한다. 클로드 코드를 보면서 AI 모델은 이미 똑똑하니 제대로 된 컨텍스트와 쓸만한 하니스를 주는게 중요하다는…
Claude code - 개발자
claude code for designer 제품들도 계속 나오는중
https://www.pencil.dev/
https://x.com/variantui
Claude code for Marketer
https://hightouch.com/
결국 코드는 언어였고, 언어로 저장된 파일 시스템에 적절한 하니스들을 구축하면 AI Agent들이 일을 알아서 내 입맛에 맞게 해주는 게 가능하다는 게 증명되었으니까. 올해는 Agent for 특정 직군(Marketer, Designer, Doctor, Lawyer etc)가 쏟아져 나올듯.
사실 GPT나온 뒤에 이게 쏟아져나왔었는데 당시에 이런 것들이 부족해서 고객에게 와우를 주지 못했는데.
1. 모델 성능(리즈닝 그리고 도구 사용)이 워낙 좋지 않았고
2. Unstructural Data들을 어떤식으로 가공하고 컨텍스트 엔지니어링을 어떻게 해야하는지
그래도 GPT+RAG를 붙여주는 것만으로도 꽤 쓸만함을 느꼈었다. 덕분에 Vertical AI(Legal, Medical, CS)들이 빠르게 컸다.
1. 지금은 모델이 아주 좋아지고 있고
2. 컴퓨팅 비용 더 낮아지고 있고 -> 더 오래 리즈닝하거나 더 많은 agents를 더 싸게
3. 컨텍스트 엔지니어링/하니스 너무 다양해지고 있고
코딩 에이전트가 꽤 좋아져서 위에 세가지가 가속화되고 있어서
물어보고 답변받는 채팅의 시대에서 알아서 내 의도를 파악하고 여러개의 agent끼리 협업하면서 잠도 안자고 내 목적을 알아서 완수해주는 Agent 제품들이 쏟아져나오고 있다.
2년전에 너무 일찍 시작해서 망한 제품/사업들이 지금 모델과 하니스면 꽤 Wow한 경험들을 줄 수 있을 것 같다.
그런 점에서 올해는 AI Agents for Vertical, AI Agents orchestration 제품들이 벌써부터 주목 받는중.
클로드 코드에서 에이전트 5개정도 넘어가면 여러 부서 미팅을 연달아 하는 기분을 받을 수 있는데 이런 distraction을 관리해주는 제품들이 사용자들에게 좋은 피드백을 받는 중.
https://www.conductor.build/
claude code for designer 제품들도 계속 나오는중
https://www.pencil.dev/
https://x.com/variantui
Claude code for Marketer
https://hightouch.com/
결국 코드는 언어였고, 언어로 저장된 파일 시스템에 적절한 하니스들을 구축하면 AI Agent들이 일을 알아서 내 입맛에 맞게 해주는 게 가능하다는 게 증명되었으니까. 올해는 Agent for 특정 직군(Marketer, Designer, Doctor, Lawyer etc)가 쏟아져 나올듯.
사실 GPT나온 뒤에 이게 쏟아져나왔었는데 당시에 이런 것들이 부족해서 고객에게 와우를 주지 못했는데.
1. 모델 성능(리즈닝 그리고 도구 사용)이 워낙 좋지 않았고
2. Unstructural Data들을 어떤식으로 가공하고 컨텍스트 엔지니어링을 어떻게 해야하는지
그래도 GPT+RAG를 붙여주는 것만으로도 꽤 쓸만함을 느꼈었다. 덕분에 Vertical AI(Legal, Medical, CS)들이 빠르게 컸다.
1. 지금은 모델이 아주 좋아지고 있고
2. 컴퓨팅 비용 더 낮아지고 있고 -> 더 오래 리즈닝하거나 더 많은 agents를 더 싸게
3. 컨텍스트 엔지니어링/하니스 너무 다양해지고 있고
코딩 에이전트가 꽤 좋아져서 위에 세가지가 가속화되고 있어서
물어보고 답변받는 채팅의 시대에서 알아서 내 의도를 파악하고 여러개의 agent끼리 협업하면서 잠도 안자고 내 목적을 알아서 완수해주는 Agent 제품들이 쏟아져나오고 있다.
2년전에 너무 일찍 시작해서 망한 제품/사업들이 지금 모델과 하니스면 꽤 Wow한 경험들을 줄 수 있을 것 같다.
그런 점에서 올해는 AI Agents for Vertical, AI Agents orchestration 제품들이 벌써부터 주목 받는중.
클로드 코드에서 에이전트 5개정도 넘어가면 여러 부서 미팅을 연달아 하는 기분을 받을 수 있는데 이런 distraction을 관리해주는 제품들이 사용자들에게 좋은 피드백을 받는 중.
https://www.conductor.build/
Pencil
Pencil – Design on canvas. Land in code.
Pencil fundamentally increases your engineering speed by bringing designing directly into your preferred IDE.
❤1
직무 변화는 현실인듯. 이제 PM/디자이너의 비중이 확줄고 개발자들이 PM하는 게 일반화될 것 같네. 스포티파이도 계층 다 없애고 빌더+의사결정권자로 바꿨던데 조직을 AI Agent First로 설계하지 않으면 살아남을수 없다.
—
제품 관리자(PM): 더 이상 정확히 무엇을 만들지 지시하지 않습니다. 대신 고객의 니즈를 가장 높은 수준에서 명확히 하고 "Why(이유)의 수호자" 역할을 합니다. 그들은 직접 프로토타이핑을 하고 엔지니어와 함께 코드를 확인하는 등 실무에 참여해야 합니다.
엔지니어 & 디자이너: 역할이 합쳐지고 있습니다. 모델이 너무 빠르게 진화하기 때문에 엄격한 명세서는 작동하지 않습니다. 제품은 엔지니어, 연구원, PM이 코드 상에서 직접 작업하며 만들어집니다.
디자이너의 경우: 기업들은 엔지니어 대비 디자이너 채용을 줄이고 있습니다. 디자인 시스템이 확립되면 AI가 그 언어를 활용해 작업을 수행할 수 있기 때문입니다. PM/디자이너 대 엔지니어의 비율은 1:3 또는 1:10에서 1:20으로 이동하고 있습니다.
소프트웨어가 "비결정론적(non-deterministic)"이 되고 있다고 언급했습니다. 이것이 제품 관리에 의미하는 바는 무엇입니까?
과거에 소프트웨어는 결정론적이었습니다. 사용자가 X를 하면 Y가 발생했죠. 지금은 사용자가 X를 하면 Y가 발생하지만, 미세한 차이로 인해 완전히 다른 결과가 나올 수도 있습니다. 이로 인해 평가(Evals)가 필요합니다. 다양한 사용 사례에서 소프트웨어의 출력이 합리적인지 누군가 평가해야 합니다. PM은 이제 이러한 평가를 담당하며, 사람이 수동으로 확장할 수 없기 때문에 다른 AI의 결과를 평가하기 위한 AI 스크립트를 직접 작성하기도 합니다.
AI 생성 속도가 빨라짐에 따라, 미래에도 유효한 인간의 기술은 무엇입니까?
판단력(Judgment)입니다. AI 엔진이 무한한 양의 코드("AI slop" - AI가 쏟아내는 저질 코드/부산물)를 생산해낼 때, 중요한 질문은 "이 중 무엇이 중요한가?"가 됩니다.
제품 측면: 무엇을 만들지 결정하고 결과물의 품질을 평가하는 데 판단력이 필요합니다.
엔지니어링 측면: AI가 작성했더라도 버그와 취약점을 검토하기 위해 판단력이 필요합니다.
디자인 측면: 결과물이 더 넓은 디자인 시스템에 부합하는지 확인하기 위해 판단력이 필요합니다.
무한한 생산성의 시대에, 판단력은 우리가 '무엇에' 생산적이어야 하는지를 결정합니다.
Q: 제품 관리에 대한 당신의 핵심 철학은 무엇입니까?
A: 제품 관리자의 업무는 고객의 니즈와 비즈니스 니즈의 균형을 맞추는 것입니다. 그들은 "Why"의 파수꾼입니다.
왜 이것을 만드는가? (고통의 강도와 깊이)
이것이 회사에 어떻게 가치를 더하는가?
고객은 좋아하지만 비즈니스 가치를 파괴하는 것이나, 비즈니스에는 도움이 되지만(예: 가격 인상) 고객에게 해를 끼치는 것을 만드는 것은 피해야 합니다.
Q: 제품의 성공을 어떻게 정의합니까?
A: 성공은 결과(Outcomes), 구체적으로는 고객 행동(Customer Behavior)으로 정의됩니다. 고객 행동은 비즈니스 성과의 선행 지표입니다. 모든 기능 출시는 행동 변화에 근거한 가설(예: "이것을 출시하면 고객이 X를 하던 것에서 Y를 하는 것으로 바뀔 것이다")을 가지고 있어야 합니다.
Q: 오늘날 창업자들은 새로운 AI 애플리케이션 구축을 어떻게 공략해야 합니까?
깊고 설득력 있는 문제 찾기: 고임금을 받는 사람들이 반복적인 업무를 하는 산업(예: 법률, 건축)을 찾으세요.
고가치 워크플로우 타겟팅: 워크플로우는 깊고 복잡하며 맞춤형 데이터가 필요해야 합니다.
내구성(Durability) 목표: 만약 "가벼운" 것을 만든다면, 파운데이션 모델(Gemini나 ChatGPT 등)이나 수평적 도구들이 당신을 집어삼킬 것입니다. 당신의 솔루션이 상당히 깊지 않다면, CIO들은 자체 엔지니어와 수평적 도구를 사용할 것입니다.
Q: AI 시대에 "내구성" 또는 "접착성(Stickiness)"을 구성하는 요소는 무엇입니까?
A: 넷-뉴(net-new) 소프트웨어를 만드는 마찰이 매우 낮아졌기 때문에 생존하려면 다음과 같은 특정 자산이 필요합니다.
희소 자산 소유: 라이선스, 특정 규제에 대한 통찰력, 또는 독보적인 인재(예: 누구와도 미팅을 잡을 수 있는 Brett Taylor를 보유한 Sierra).
통제 지점(Control Points): 사람들이 돈이나 데이터와 상호작용하는 방식을 통제하는 것.
하드웨어: 교체하기 어려운 것(예: Toast의 POS 기기).
필수 워크플로우: 운영 깊숙이 내재화되는 것.
네트워크 효과: DoorDash(소비자, 식당, 배달원)와 같은 것.
Q: 레거시 "기록 시스템(System of Record)" 기업들(Salesforce, Slack 등)은 AI 스타트업에 어떻게 반응하고 있습니까?
A: 그들은 AI 스타트업이 자신들을 "멍청한 데이터베이스" 취급하는 것을 막기 위해 반격하고 있습니다. 그들은 다음과 같은 조치를 취합니다.
API 접근 차단(예: Slack이 Glean을 차단).
자체 AI 에이전트 무료 번들링 제공.
데이터 접근에 높은 비용 부과.
결과: AI 스타트업은 더 이상 레거시 소프트웨어 위에 "행동 시스템(System of Action)"만 구축할 수 없습니다. 기록 시스템 전체를 대체하는 것을 목표로 해야 합니다.
Q: 레거시 소프트웨어 기업들의 리스크는 무엇입니까?
고위험: 유틸리티/좌석(seat) 기반으로 가격을 책정하는 기업(예: Zendesk). AI 에이전트가 인간 상담원의 필요성을 줄이면 매출이 급감합니다. 그들은 성과 기반 가격 책정으로 전환해야 하는데, 상장 기업으로서 이는 어려운 전환입니다.
저위험: 불변의 데이터를 보유한 기업(예: NetSuite 같은 ERP). CIO가 ERP를 뜯어고치는 것은 커리어에 치명적일 수 있으므로 접착성이 높습니다.
Q: AI 스타트업은 어떻게 Salesforce처럼 접착성 높은 레거시 시스템과 경쟁합니까?
A: 마이그레이션 도구를 구축해야 합니다. 기존 시스템의 데이터를 당신의 시스템으로 매끄럽게 옮기는 스크립트를 만드는 것은 엄청난 노력(종종 1~2년의 엔지니어링)이 듭니다. 고객은 자신의 기록을 남겨두고 떠나야 한다면 움직이지 않을 것입니다.
Q: 리더는 팀과 어떻게 소통해야 합니까?
주간 전체 회의(All-Hands): 작은 팀이라도 문화 형성에 필수적입니다.
주간 CEO 이메일: 이것은 매우 중요합니다. 세 부분으로 구성되어야 합니다.
화두(Top of Mind): 제품, 비즈니스, 팀과 관련해 CEO가 고민하는 것 (이메일의 60-70% 할애).
성과 업데이트: 회사가 어떻게 하고 있는지 투명한 지표 공유.
기타: 팀원 인정, 고객 인용구 등.
조언: 솔직해지세요. 메시지가 스며들기 위해서는 반복이 필요합니다.
Q: 이 새로운 시대에 어떤 유형의 사람이 성공합니까?
A: 실행가(Doers)와 빌더(Builders). 가장 가치 있는 기술은 수많은 AI 에이전트를 지휘할 수 있는 기능 전문가가 되는 것입니다.
기업은 사람 관리만 하는 관리자 채용을 중단해야 합니다.
관리 범위(Span of Control): 관리자는 10명 이상을 관리하거나, 개별 기여자(IC)가 되어야 합니다. 좁은 관리 범위는 비효율적입니다.
Q: 이러한 특성을 어떻게 면접에서 확인합니까?
A: 실무 과제(Work Projects)를 부여하세요(엔지니어뿐만 아니라).
예시: 기업 개발(Corp Dev) 후보자에게 인수할 회사를 식별하고 시너지를 분석하도록 요청하세요.
찾아야 할 것: 주체성(Agency)과 고객의 목소리를 보여주는 후보자.
최고의 답변: 직접 고객과 대화해 보니 그 기능을 원하지 않는다고 말하며, 과제의 전제 자체를 거부하는 후보자.
https://youtu.be/JUsb1FYOstA
—
제품 관리자(PM): 더 이상 정확히 무엇을 만들지 지시하지 않습니다. 대신 고객의 니즈를 가장 높은 수준에서 명확히 하고 "Why(이유)의 수호자" 역할을 합니다. 그들은 직접 프로토타이핑을 하고 엔지니어와 함께 코드를 확인하는 등 실무에 참여해야 합니다.
엔지니어 & 디자이너: 역할이 합쳐지고 있습니다. 모델이 너무 빠르게 진화하기 때문에 엄격한 명세서는 작동하지 않습니다. 제품은 엔지니어, 연구원, PM이 코드 상에서 직접 작업하며 만들어집니다.
디자이너의 경우: 기업들은 엔지니어 대비 디자이너 채용을 줄이고 있습니다. 디자인 시스템이 확립되면 AI가 그 언어를 활용해 작업을 수행할 수 있기 때문입니다. PM/디자이너 대 엔지니어의 비율은 1:3 또는 1:10에서 1:20으로 이동하고 있습니다.
소프트웨어가 "비결정론적(non-deterministic)"이 되고 있다고 언급했습니다. 이것이 제품 관리에 의미하는 바는 무엇입니까?
과거에 소프트웨어는 결정론적이었습니다. 사용자가 X를 하면 Y가 발생했죠. 지금은 사용자가 X를 하면 Y가 발생하지만, 미세한 차이로 인해 완전히 다른 결과가 나올 수도 있습니다. 이로 인해 평가(Evals)가 필요합니다. 다양한 사용 사례에서 소프트웨어의 출력이 합리적인지 누군가 평가해야 합니다. PM은 이제 이러한 평가를 담당하며, 사람이 수동으로 확장할 수 없기 때문에 다른 AI의 결과를 평가하기 위한 AI 스크립트를 직접 작성하기도 합니다.
AI 생성 속도가 빨라짐에 따라, 미래에도 유효한 인간의 기술은 무엇입니까?
판단력(Judgment)입니다. AI 엔진이 무한한 양의 코드("AI slop" - AI가 쏟아내는 저질 코드/부산물)를 생산해낼 때, 중요한 질문은 "이 중 무엇이 중요한가?"가 됩니다.
제품 측면: 무엇을 만들지 결정하고 결과물의 품질을 평가하는 데 판단력이 필요합니다.
엔지니어링 측면: AI가 작성했더라도 버그와 취약점을 검토하기 위해 판단력이 필요합니다.
디자인 측면: 결과물이 더 넓은 디자인 시스템에 부합하는지 확인하기 위해 판단력이 필요합니다.
무한한 생산성의 시대에, 판단력은 우리가 '무엇에' 생산적이어야 하는지를 결정합니다.
Q: 제품 관리에 대한 당신의 핵심 철학은 무엇입니까?
A: 제품 관리자의 업무는 고객의 니즈와 비즈니스 니즈의 균형을 맞추는 것입니다. 그들은 "Why"의 파수꾼입니다.
왜 이것을 만드는가? (고통의 강도와 깊이)
이것이 회사에 어떻게 가치를 더하는가?
고객은 좋아하지만 비즈니스 가치를 파괴하는 것이나, 비즈니스에는 도움이 되지만(예: 가격 인상) 고객에게 해를 끼치는 것을 만드는 것은 피해야 합니다.
Q: 제품의 성공을 어떻게 정의합니까?
A: 성공은 결과(Outcomes), 구체적으로는 고객 행동(Customer Behavior)으로 정의됩니다. 고객 행동은 비즈니스 성과의 선행 지표입니다. 모든 기능 출시는 행동 변화에 근거한 가설(예: "이것을 출시하면 고객이 X를 하던 것에서 Y를 하는 것으로 바뀔 것이다")을 가지고 있어야 합니다.
Q: 오늘날 창업자들은 새로운 AI 애플리케이션 구축을 어떻게 공략해야 합니까?
깊고 설득력 있는 문제 찾기: 고임금을 받는 사람들이 반복적인 업무를 하는 산업(예: 법률, 건축)을 찾으세요.
고가치 워크플로우 타겟팅: 워크플로우는 깊고 복잡하며 맞춤형 데이터가 필요해야 합니다.
내구성(Durability) 목표: 만약 "가벼운" 것을 만든다면, 파운데이션 모델(Gemini나 ChatGPT 등)이나 수평적 도구들이 당신을 집어삼킬 것입니다. 당신의 솔루션이 상당히 깊지 않다면, CIO들은 자체 엔지니어와 수평적 도구를 사용할 것입니다.
Q: AI 시대에 "내구성" 또는 "접착성(Stickiness)"을 구성하는 요소는 무엇입니까?
A: 넷-뉴(net-new) 소프트웨어를 만드는 마찰이 매우 낮아졌기 때문에 생존하려면 다음과 같은 특정 자산이 필요합니다.
희소 자산 소유: 라이선스, 특정 규제에 대한 통찰력, 또는 독보적인 인재(예: 누구와도 미팅을 잡을 수 있는 Brett Taylor를 보유한 Sierra).
통제 지점(Control Points): 사람들이 돈이나 데이터와 상호작용하는 방식을 통제하는 것.
하드웨어: 교체하기 어려운 것(예: Toast의 POS 기기).
필수 워크플로우: 운영 깊숙이 내재화되는 것.
네트워크 효과: DoorDash(소비자, 식당, 배달원)와 같은 것.
Q: 레거시 "기록 시스템(System of Record)" 기업들(Salesforce, Slack 등)은 AI 스타트업에 어떻게 반응하고 있습니까?
A: 그들은 AI 스타트업이 자신들을 "멍청한 데이터베이스" 취급하는 것을 막기 위해 반격하고 있습니다. 그들은 다음과 같은 조치를 취합니다.
API 접근 차단(예: Slack이 Glean을 차단).
자체 AI 에이전트 무료 번들링 제공.
데이터 접근에 높은 비용 부과.
결과: AI 스타트업은 더 이상 레거시 소프트웨어 위에 "행동 시스템(System of Action)"만 구축할 수 없습니다. 기록 시스템 전체를 대체하는 것을 목표로 해야 합니다.
Q: 레거시 소프트웨어 기업들의 리스크는 무엇입니까?
고위험: 유틸리티/좌석(seat) 기반으로 가격을 책정하는 기업(예: Zendesk). AI 에이전트가 인간 상담원의 필요성을 줄이면 매출이 급감합니다. 그들은 성과 기반 가격 책정으로 전환해야 하는데, 상장 기업으로서 이는 어려운 전환입니다.
저위험: 불변의 데이터를 보유한 기업(예: NetSuite 같은 ERP). CIO가 ERP를 뜯어고치는 것은 커리어에 치명적일 수 있으므로 접착성이 높습니다.
Q: AI 스타트업은 어떻게 Salesforce처럼 접착성 높은 레거시 시스템과 경쟁합니까?
A: 마이그레이션 도구를 구축해야 합니다. 기존 시스템의 데이터를 당신의 시스템으로 매끄럽게 옮기는 스크립트를 만드는 것은 엄청난 노력(종종 1~2년의 엔지니어링)이 듭니다. 고객은 자신의 기록을 남겨두고 떠나야 한다면 움직이지 않을 것입니다.
Q: 리더는 팀과 어떻게 소통해야 합니까?
주간 전체 회의(All-Hands): 작은 팀이라도 문화 형성에 필수적입니다.
주간 CEO 이메일: 이것은 매우 중요합니다. 세 부분으로 구성되어야 합니다.
화두(Top of Mind): 제품, 비즈니스, 팀과 관련해 CEO가 고민하는 것 (이메일의 60-70% 할애).
성과 업데이트: 회사가 어떻게 하고 있는지 투명한 지표 공유.
기타: 팀원 인정, 고객 인용구 등.
조언: 솔직해지세요. 메시지가 스며들기 위해서는 반복이 필요합니다.
Q: 이 새로운 시대에 어떤 유형의 사람이 성공합니까?
A: 실행가(Doers)와 빌더(Builders). 가장 가치 있는 기술은 수많은 AI 에이전트를 지휘할 수 있는 기능 전문가가 되는 것입니다.
기업은 사람 관리만 하는 관리자 채용을 중단해야 합니다.
관리 범위(Span of Control): 관리자는 10명 이상을 관리하거나, 개별 기여자(IC)가 되어야 합니다. 좁은 관리 범위는 비효율적입니다.
Q: 이러한 특성을 어떻게 면접에서 확인합니까?
A: 실무 과제(Work Projects)를 부여하세요(엔지니어뿐만 아니라).
예시: 기업 개발(Corp Dev) 후보자에게 인수할 회사를 식별하고 시너지를 분석하도록 요청하세요.
찾아야 할 것: 주체성(Agency)과 고객의 목소리를 보여주는 후보자.
최고의 답변: 직접 고객과 대화해 보니 그 기능을 원하지 않는다고 말하며, 과제의 전제 자체를 거부하는 후보자.
https://youtu.be/JUsb1FYOstA
YouTube
He Built The Revenue Engines for Google, Facebook & Square
Gokul Rajaram joins Patrick to discuss the seismic shift in product building driven by AI. As a legendary operator (Google, Facebook, Square, DoorDash) and prolific investor, Gokul breaks down how tools like Claude are merging design and engineering roles…
❤2
AI Agent/LLM 관련 연구를 하거나 제품을 만드는 분들끼리 점심 먹어요!
최근까지 Manus에서 Agent Research/Building을 했던 Ivan Leo (https://ivanleo.com/)이 한국에 머물러서 LLM, AI Agents Research, Engineering하는 분들끼리 소규모로 모일 예정입니다! 행사는 아니고 금요일 점심 먹으면서 각자 연구/개발하는 거 공유해요!
몇자리가 남아서 관심있는 분들 신청해주시면 감사하겠습니다!
https://lnkd.in/gHbX_ZzA
최근까지 Manus에서 Agent Research/Building을 했던 Ivan Leo (https://ivanleo.com/)이 한국에 머물러서 LLM, AI Agents Research, Engineering하는 분들끼리 소규모로 모일 예정입니다! 행사는 아니고 금요일 점심 먹으면서 각자 연구/개발하는 거 공유해요!
몇자리가 남아서 관심있는 분들 신청해주시면 감사하겠습니다!
https://lnkd.in/gHbX_ZzA
Ivanleo
Ivan Leo - Blog
Ivan rambles on about LLM reliability, evals and UX design
소프트웨어의 신문화: Aggregation Theory 2.0과 가치 이동
신문과 SaaS — 같은 구조, 다른 시대
신문 산업과 SaaS 산업은 놀라울 만큼 같은 궤적을 따르고 있다.
신문의 경제학은 지리적 희소성 위에 세워졌다. 한 도시에서 인쇄기와 배달망을 가진 자가 독점적 수익을 거둘 수 있었다.
고성장 → 지역 통합 → 과점적 수익성. 그러나 TV, 라디오, 그리고 인터넷이라는 환경 변화가 이 구조를 무너뜨렸다.
배포(distribution) 비용이 0에 수렴하면서, 누구나 퍼블리셔가 될 수 있게 되었다. 개별 퍼블리셔에게는 기회였지만, 집단적으로는 경제적 파괴였다.
SaaS의 경제학은 코드의 희소성 위에 세워져 있다. 소프트웨어를 만들 수 있는 엔지니어가 희소하기 때문에, 잘 만든 소프트웨어는 per-seat 구독료를 받을 수 있었다. 그런데 지금, AI가 코드 생성 비용(cost of code)을 구조적으로 0에 수렴시키고 있다. 누구나 소프트웨어를 만들 수 있는 시대. SaaS의 경쟁 환경이 "희소"에서 "풍요(abundance)"로 재편되고 있다.
핵심 투입 요소가 희소 → 풍요로 바뀌는 순간, 가치(수익 풀)는 반드시 '다른 희소'로 이동한다.
이번엔 다르다: Interface 자체가 사라진다
신문이 무너질 때, 새로운 인터페이스가 등장해서 가치를 흡수했다. 웹사이트, 앱, 뉴스피드. 이것이 Aggregation Theory 1.0이다.
Google은 검색으로, Facebook은 피드로, Uber는 모바일 앱으로 — 인터넷 위에서 공급자를 모으고, 더 나은 UX로 수요를 장악했다. 공급자가 많아질수록 사용자에게 가치가 커지는 네트워크 효과가 핵심 해자였다.
이번엔 인터페이스 자체가 통합되고 있다. 사용자가 앱을 열고, 키워드를 입력하고, 결과를 비교하는 행위가 — 음성 또는 자연어로 AI Agent에게 의도를 말하면, 뒷단에 연결된 여러 앱, 문서, 서비스를 알아서 처리하는 행위로 바뀐다.
이것이 Aggregation Theory 2.0이다.
1.0이 인터넷 위에서 UX(검색/피드/앱)로 공급자를 모았다면, 2.0은 자연어와 음성으로 애플리케이션 소프트웨어 자체를 모아서, 고객에게 결과만 가져다준다.
해자도 바뀐다. 1.0의 해자가 네트워크 효과와 UX였다면, 2.0의 해자는 고객의 개인 맥락을 얼마나 깊이 이해하는가, 그리고 신뢰할 만한 결과물을 가져다주는가이다.
새로운 희소: 가치는 어디로 이동하는가
코드가 풍요로워지면, 경쟁은 "기능 수"에서 다른 곳으로 이동한다. 토큰, 컴퓨트, 지연시간, 신뢰성, 보안 — 실행 제약이 새로운 병목이 된다. 유지보수, 보안 패치, 컴플라이언스, 시스템 통합, 고객 지원 같은 제품의 전체 수명주기를 책임지는 레이어에 가치가 집중된다.
코딩이 아무리 빨라져도, 누군가는 결제에 책임을 져야 하고, 규제를 준수해야 하고, 자금을 조달해야 하고, 자산을 평가해야 하고, 대출을 실행해야 한다. 이런 것들을 쥐고 있는 비즈니스는 AI 때문에 위축되는 것이 아니라, AI 덕분에 더 효율적으로 확장할 수 있다.
Vertical AI의 생존 조건: 3가지 질문
Nihar Bobba가 제시한 프레임워크가 여기서 핵심이 된다.
Foundation model 회사들(Anthropic, OpenAI, Google)이 빠르게 수직 확장하고 있는 지금, Vertical AI 회사가 살아남으려면 아래 세 질문에 모두 "우리"라고 답할 수 있어야 한다:
1. 누가 주체(principal)인가? — 고객의 도구인가, 결과의 책임자인가?
2. 누가 liability를 소유하는가? — 일이 잘못되면 누구의 문제인가?
3. 누가 규제 기관과의 관계를 갖고 있는가? — 감사관이 전화할 곳은 어디인가?
셋 다 "고객"이라면, foundation model이 당신을 대체할 수 있다. 셋 다 "우리"라면, 당신이 가진 것은 AI로 복제할 수 없는 구조적 방어력이다.
Frontier lab과 경쟁하지 말고, 그들의 고객이 되어라. 변호사를 위한 AI 도구가 아니라, AI-native 로펌을 만들어라. 세무사를 위한 소프트웨어가 아니라, 세금을 대신 신고하고 감사를 대신 받는 서비스를 만들어라.
고성장이 나올 4가지 영역
1. Outcome-as-a-Service: 도구가 아닌 결과를 파는 기업
세금/법률/회계 소프트웨어는 commodity가 된다. 세금/법률/회계 대행 — AI Agent가 업무를 수행하고, 결과에 대한 보장료를 청구하는 모델 — 은 프리미엄을 받는다. Per-seat 구독료에서 insurance pricing으로의 전환. 고객은 소프트웨어가 아니라
확실성(certainty)에 돈을 낸다.
2. Agent Infrastructure: 에이전트 시대의 인프라
개인과 기업이 수백에서 수천 개의 Agent를 운용하는 세상에서, 현재의 인프라는 여전히 인간이 소프트웨어를 조작하는 구조로 되어있다. Agent 간 통신(MCP/A2A), Agent 관리, Agent 보안, Agent 과금 — 이 모든 인프라가 새로 필요하다. 결제(Stripe), 물류(Amazon), 컴퓨팅(AWS/Azure) 같은 기존 인프라 위에, Agent-native 계층이 쌓인다.
3. Trust Layer: 신뢰가 새로운 해자
AI Agent에게 금융, 의료, 법적 결정을 위임하려면 신뢰가 필요하다. 신뢰할 만한 사람을 찾듯, 신뢰할 만한 Agent에 고객 수요가 몰린다. 이 신뢰를 구축하는 데는 시간이 걸리고, 한번 깨지면 복구가 어렵다. 디바이스 레벨(Apple의 on-device privacy), 금융 레벨(규제 라이선스, 자본시장 관계), 의료 레벨(FDA/HIPAA compliance) — 각 영역에서 신뢰를 먼저 확보한 자가 수요를 독점한다.
4. Physical World Coordination: 디지털 바깥의 자산
DoorDash의 레스토랑 네트워크와 배달원, Opendoor의 부동산 매물과 현장 방문 데이터, Amazon의 물류 창고. 디지털 세상 바깥에 존재하는 자산과 관계는 AI Agent가 코드로 복제할 수 없다. 이 물리적 실행력을 가진 기업은 AI로 운영 비용을 줄이면서도, 그 해자 오히려 강화된다.
결론: 코드가 무료가 되는 것이지, 결과가 무료가 되는 것이 아니다
인간의 눈을 위한 정보 시스템 — SEO, per-seat SaaS, 디스플레이 광고, 마케팅 카피 생성 도구, 기본적 소프트웨어 도구 — 은 사라진다. 살아남는 것은 현실 세계의 결과와 연결된 것뿐이다.
지금까지 고품질 서비스를 보장하는 비즈니스는 대부분 확장이 어려웠다. 변호사, 세무사, 의사의 시간은 유한했기 때문이다. 그러나 AI Agent 덕분에, 결과를 보장하는 서비스가 처음으로 소프트웨어처럼 확장 가능해지고 있다. 신뢰를 스케일시킬 수 있는 시대가 열린
것이다.
신문이 무너졌을 때 배포가 무료가 되었지, 저널리즘이 무료가 된 것은 아니었다. SaaS가 무너지는 지금, 코드가 무료가 되는 것이지, 결과가 무료가 되는 것이 아니다.
https://csunerd.substack.com/p/software-as-a-newspaper
https://stratechery.com/2026/microsoft-and-software-survival/
https://m.blog.naver.com/mynameisdj/224178076111
https://stratechery.com/aggregation-theory/
https://x.com/nbobba/status/2020200100300009797
신문과 SaaS — 같은 구조, 다른 시대
신문 산업과 SaaS 산업은 놀라울 만큼 같은 궤적을 따르고 있다.
신문의 경제학은 지리적 희소성 위에 세워졌다. 한 도시에서 인쇄기와 배달망을 가진 자가 독점적 수익을 거둘 수 있었다.
고성장 → 지역 통합 → 과점적 수익성. 그러나 TV, 라디오, 그리고 인터넷이라는 환경 변화가 이 구조를 무너뜨렸다.
배포(distribution) 비용이 0에 수렴하면서, 누구나 퍼블리셔가 될 수 있게 되었다. 개별 퍼블리셔에게는 기회였지만, 집단적으로는 경제적 파괴였다.
SaaS의 경제학은 코드의 희소성 위에 세워져 있다. 소프트웨어를 만들 수 있는 엔지니어가 희소하기 때문에, 잘 만든 소프트웨어는 per-seat 구독료를 받을 수 있었다. 그런데 지금, AI가 코드 생성 비용(cost of code)을 구조적으로 0에 수렴시키고 있다. 누구나 소프트웨어를 만들 수 있는 시대. SaaS의 경쟁 환경이 "희소"에서 "풍요(abundance)"로 재편되고 있다.
핵심 투입 요소가 희소 → 풍요로 바뀌는 순간, 가치(수익 풀)는 반드시 '다른 희소'로 이동한다.
이번엔 다르다: Interface 자체가 사라진다
신문이 무너질 때, 새로운 인터페이스가 등장해서 가치를 흡수했다. 웹사이트, 앱, 뉴스피드. 이것이 Aggregation Theory 1.0이다.
Google은 검색으로, Facebook은 피드로, Uber는 모바일 앱으로 — 인터넷 위에서 공급자를 모으고, 더 나은 UX로 수요를 장악했다. 공급자가 많아질수록 사용자에게 가치가 커지는 네트워크 효과가 핵심 해자였다.
이번엔 인터페이스 자체가 통합되고 있다. 사용자가 앱을 열고, 키워드를 입력하고, 결과를 비교하는 행위가 — 음성 또는 자연어로 AI Agent에게 의도를 말하면, 뒷단에 연결된 여러 앱, 문서, 서비스를 알아서 처리하는 행위로 바뀐다.
이것이 Aggregation Theory 2.0이다.
1.0이 인터넷 위에서 UX(검색/피드/앱)로 공급자를 모았다면, 2.0은 자연어와 음성으로 애플리케이션 소프트웨어 자체를 모아서, 고객에게 결과만 가져다준다.
해자도 바뀐다. 1.0의 해자가 네트워크 효과와 UX였다면, 2.0의 해자는 고객의 개인 맥락을 얼마나 깊이 이해하는가, 그리고 신뢰할 만한 결과물을 가져다주는가이다.
새로운 희소: 가치는 어디로 이동하는가
코드가 풍요로워지면, 경쟁은 "기능 수"에서 다른 곳으로 이동한다. 토큰, 컴퓨트, 지연시간, 신뢰성, 보안 — 실행 제약이 새로운 병목이 된다. 유지보수, 보안 패치, 컴플라이언스, 시스템 통합, 고객 지원 같은 제품의 전체 수명주기를 책임지는 레이어에 가치가 집중된다.
코딩이 아무리 빨라져도, 누군가는 결제에 책임을 져야 하고, 규제를 준수해야 하고, 자금을 조달해야 하고, 자산을 평가해야 하고, 대출을 실행해야 한다. 이런 것들을 쥐고 있는 비즈니스는 AI 때문에 위축되는 것이 아니라, AI 덕분에 더 효율적으로 확장할 수 있다.
Vertical AI의 생존 조건: 3가지 질문
Nihar Bobba가 제시한 프레임워크가 여기서 핵심이 된다.
Foundation model 회사들(Anthropic, OpenAI, Google)이 빠르게 수직 확장하고 있는 지금, Vertical AI 회사가 살아남으려면 아래 세 질문에 모두 "우리"라고 답할 수 있어야 한다:
1. 누가 주체(principal)인가? — 고객의 도구인가, 결과의 책임자인가?
2. 누가 liability를 소유하는가? — 일이 잘못되면 누구의 문제인가?
3. 누가 규제 기관과의 관계를 갖고 있는가? — 감사관이 전화할 곳은 어디인가?
셋 다 "고객"이라면, foundation model이 당신을 대체할 수 있다. 셋 다 "우리"라면, 당신이 가진 것은 AI로 복제할 수 없는 구조적 방어력이다.
Frontier lab과 경쟁하지 말고, 그들의 고객이 되어라. 변호사를 위한 AI 도구가 아니라, AI-native 로펌을 만들어라. 세무사를 위한 소프트웨어가 아니라, 세금을 대신 신고하고 감사를 대신 받는 서비스를 만들어라.
고성장이 나올 4가지 영역
1. Outcome-as-a-Service: 도구가 아닌 결과를 파는 기업
세금/법률/회계 소프트웨어는 commodity가 된다. 세금/법률/회계 대행 — AI Agent가 업무를 수행하고, 결과에 대한 보장료를 청구하는 모델 — 은 프리미엄을 받는다. Per-seat 구독료에서 insurance pricing으로의 전환. 고객은 소프트웨어가 아니라
확실성(certainty)에 돈을 낸다.
2. Agent Infrastructure: 에이전트 시대의 인프라
개인과 기업이 수백에서 수천 개의 Agent를 운용하는 세상에서, 현재의 인프라는 여전히 인간이 소프트웨어를 조작하는 구조로 되어있다. Agent 간 통신(MCP/A2A), Agent 관리, Agent 보안, Agent 과금 — 이 모든 인프라가 새로 필요하다. 결제(Stripe), 물류(Amazon), 컴퓨팅(AWS/Azure) 같은 기존 인프라 위에, Agent-native 계층이 쌓인다.
3. Trust Layer: 신뢰가 새로운 해자
AI Agent에게 금융, 의료, 법적 결정을 위임하려면 신뢰가 필요하다. 신뢰할 만한 사람을 찾듯, 신뢰할 만한 Agent에 고객 수요가 몰린다. 이 신뢰를 구축하는 데는 시간이 걸리고, 한번 깨지면 복구가 어렵다. 디바이스 레벨(Apple의 on-device privacy), 금융 레벨(규제 라이선스, 자본시장 관계), 의료 레벨(FDA/HIPAA compliance) — 각 영역에서 신뢰를 먼저 확보한 자가 수요를 독점한다.
4. Physical World Coordination: 디지털 바깥의 자산
DoorDash의 레스토랑 네트워크와 배달원, Opendoor의 부동산 매물과 현장 방문 데이터, Amazon의 물류 창고. 디지털 세상 바깥에 존재하는 자산과 관계는 AI Agent가 코드로 복제할 수 없다. 이 물리적 실행력을 가진 기업은 AI로 운영 비용을 줄이면서도, 그 해자 오히려 강화된다.
결론: 코드가 무료가 되는 것이지, 결과가 무료가 되는 것이 아니다
인간의 눈을 위한 정보 시스템 — SEO, per-seat SaaS, 디스플레이 광고, 마케팅 카피 생성 도구, 기본적 소프트웨어 도구 — 은 사라진다. 살아남는 것은 현실 세계의 결과와 연결된 것뿐이다.
지금까지 고품질 서비스를 보장하는 비즈니스는 대부분 확장이 어려웠다. 변호사, 세무사, 의사의 시간은 유한했기 때문이다. 그러나 AI Agent 덕분에, 결과를 보장하는 서비스가 처음으로 소프트웨어처럼 확장 가능해지고 있다. 신뢰를 스케일시킬 수 있는 시대가 열린
것이다.
신문이 무너졌을 때 배포가 무료가 되었지, 저널리즘이 무료가 된 것은 아니었다. SaaS가 무너지는 지금, 코드가 무료가 되는 것이지, 결과가 무료가 되는 것이 아니다.
https://csunerd.substack.com/p/software-as-a-newspaper
https://stratechery.com/2026/microsoft-and-software-survival/
https://m.blog.naver.com/mynameisdj/224178076111
https://stratechery.com/aggregation-theory/
https://x.com/nbobba/status/2020200100300009797
Substack
Software-as-a-Newspaper
Mark Leonard and Ben Thompson referencing the newspaper biz and how that may be a harbinger of times ahead for software
❤3
전력, 컴퓨터, 데이터, 모델 중에서 모델은 이미 중국에 있는 중국인과 미국에 있는 중국인들이 만드는 것이 되었고 이제 컴퓨터만이 병목이고 전력과 데이터는 중국이 앞서 있다.
중국이 칩까지 만들거나 안정적으로 수급할 수 있다면 과거 일본 자동차가 자동차 시장을 석권했던 것처럼 토큰 x 하드웨어까지 정복할지도 모르겠다.
일본의 자동차 산업과 중국의 AI: '제약'이 만든 경쟁력
1970년대만 해도 일본의 자동차 산업이 승자가 될 것이라 예상하는 사람은 많지 않았습니다. 일본은 자국 내 석유 자원이 거의 없었고, 엔진 기술력 또한 뒤처져 있었기 때문입니다. 하지만 바로 그 자원의 부족이라는 제약 때문에 일본 자동차 제조사들은 단 한 방울의 연료에서도 최대의 효율을 짜내야만 하는 명확한 선택의 기로에 섰습니다.
그들은 소배기량 고효율 엔진을 최적화하기 시작했고, 더 가벼운 설계와 정밀한 제조 공정 제어 기술을 도입했습니다. 마침내 1973년 오일쇼크가 발생하고 연료 가격이 폭등하자, 마력만 높은 미국의 대형차들은 가계에 큰 부담이 되었습니다. 반면, 과거 일본이 제약에 떠밀려 어쩔 수 없이 선택했던 효율 지향적 전략은 뜻밖의 강력한 이점이 되었습니다. 그 결과 일본 자동차 산업은 이후 약 50년 동안 눈부신 전성기를 누리게 됩니다.
오늘날 중국의 AI 기업들도 오랫동안 GPU 수급 제한이라는 제약을 겪어왔습니다. 하지만 이러한 제약은 오히려 그들이 모델 경량화에 더 공격적으로 매달리고, 추론 효율성을 최적화하며, 공학적 실행력을 극한까지 끌어올리게 만드는 동력이 되었습니다. 동일한 대화를 처리하더라도 더 적은 컴퓨팅 자원을 사용함으로써 토큰당 비용을 낮춘 것입니다.
향후 전력 인프라와 데이터 센터 구축 측면에서도 중국은 태양광, 철강, 가전 분야에서 그랬던 것처럼 강력한 비용 우위를 점할 가능성이 높습니다. 미래에 중국은 세계 최대의 '토큰(Token) 수출국'이 될지도 모릅니다.
https://x.com/mablejiang/status/2020904698321174864?s=46&t=h5Byg6Wosg8MJb4pbPSDow
중국이 칩까지 만들거나 안정적으로 수급할 수 있다면 과거 일본 자동차가 자동차 시장을 석권했던 것처럼 토큰 x 하드웨어까지 정복할지도 모르겠다.
일본의 자동차 산업과 중국의 AI: '제약'이 만든 경쟁력
1970년대만 해도 일본의 자동차 산업이 승자가 될 것이라 예상하는 사람은 많지 않았습니다. 일본은 자국 내 석유 자원이 거의 없었고, 엔진 기술력 또한 뒤처져 있었기 때문입니다. 하지만 바로 그 자원의 부족이라는 제약 때문에 일본 자동차 제조사들은 단 한 방울의 연료에서도 최대의 효율을 짜내야만 하는 명확한 선택의 기로에 섰습니다.
그들은 소배기량 고효율 엔진을 최적화하기 시작했고, 더 가벼운 설계와 정밀한 제조 공정 제어 기술을 도입했습니다. 마침내 1973년 오일쇼크가 발생하고 연료 가격이 폭등하자, 마력만 높은 미국의 대형차들은 가계에 큰 부담이 되었습니다. 반면, 과거 일본이 제약에 떠밀려 어쩔 수 없이 선택했던 효율 지향적 전략은 뜻밖의 강력한 이점이 되었습니다. 그 결과 일본 자동차 산업은 이후 약 50년 동안 눈부신 전성기를 누리게 됩니다.
오늘날 중국의 AI 기업들도 오랫동안 GPU 수급 제한이라는 제약을 겪어왔습니다. 하지만 이러한 제약은 오히려 그들이 모델 경량화에 더 공격적으로 매달리고, 추론 효율성을 최적화하며, 공학적 실행력을 극한까지 끌어올리게 만드는 동력이 되었습니다. 동일한 대화를 처리하더라도 더 적은 컴퓨팅 자원을 사용함으로써 토큰당 비용을 낮춘 것입니다.
향후 전력 인프라와 데이터 센터 구축 측면에서도 중국은 태양광, 철강, 가전 분야에서 그랬던 것처럼 강력한 비용 우위를 점할 가능성이 높습니다. 미래에 중국은 세계 최대의 '토큰(Token) 수출국'이 될지도 모릅니다.
https://x.com/mablejiang/status/2020904698321174864?s=46&t=h5Byg6Wosg8MJb4pbPSDow
X (formerly Twitter)
mable.sol (join our TG community! (@mablejiang) on X
Their token is cheaper than yours, at a very Chinese time of your life
요즘 코딩하는 방식이 완전히 달라졌습니다.
주변 개발자들을 보면 지난 10월쯤부터 확 바뀌었어요. CLAUDE.md에 에이전트 행동 규칙을 적어두고, 태스크를 나눠서 여러 에이전트에게 분배하고, 그 결과물도 에이전트가 리뷰하게 하더라고요. 한명이 코딩 Agent 공장을 돌리면서 몇개월 걸릴 일을 몇시간만에 합니다.
직접 코드를 짜는 시간보다 에이전트들이 잘 움직이게 판을 짜는 시간이 훨씬 길어진 거죠. 한 명이 수십 개 에이전트를 돌리면서 소프트웨어를 만드는 게 꽤 일반화됐습니다. 펀치카드로 코딩하던 사람들이 GUI를 처음 봤을 때 이런 기분이었을까 싶어요.
근데 이게 아직은 개발자들만의 이야기거든요.
최근에 OpenClaw 써보신 분들은 아시겠지만, 비개발자분들 반응이 장난 아니었습니다. 채팅으로 AI에게 일을 시키면 여러 웹사이트랑 소프트웨어를 오가면서 결과를 가져오는데, 이걸 보고 "AGI 체감했다"는 말이 나올 정도였어요. 개발자들이 터미널에서 하네스 짜서 겨우 하던 걸, 채팅창 하나로 하니까 그런 반응이 나온 거죠.
OpenClaw를 보면서 느낀 게 있습니다. 사람들이 원하는 건 에이전트 기술 자체가 아니라, 자기가 익숙한 방식으로 에이전트를 부리는 것이더라고요. 터미널이 어려운 사람이 대부분인데, 그 허들만 넘겨줘도 가치를 확 느낍니다.
시장을 보면 흐름이 꽤 선명합니다. Lovable, Bolt, Manus나 Genspark 같은 바이브코딩 도구가 "코드를 대신 짜준다"는 가치를 증명했고 거기서 한 발 더 나아가서 "일을 대신 해준다"는 걸 보여줬습니다. 실제로 연 천억 이상 매출을 만들고 있고요.
다음 스텝이 뭘까 생각해보면, 결국 내 맥락을 깊이 이해하면서 여러 도구를 넘나들며 진짜 내 일을 처리해주는 에이전트인 것 같습니다. "만들어줘"에서 "알아서 해줘"로 넘어가는 거죠. 개인이 여러 AI 에이전트에게 업무도 시키고 상담도 받고 일상의 일들을 맡기는 게 올해 안에 훨씬 보편화될 거라고 봅니다.
이걸 만들려면 재밌는 기술 문제들이 있습니다. 에이전트한테 자율성을 충분히 주면서도 안전하게 돌아가는 샌드박싱을 어떻게 설계할 건지. 모델마다 잘하는 게 다른데 유저 요청에 맞춰서 최적 조합을 어떻게 찾을 건지. 에이전트가 맥락을 잃지 않으면서 이 앱 저 앱을 넘나들게 하려면 구조를 어떻게 잡아야 하는지. 기술적으로 되는 것과 사람들이 진짜 쓰는 것 사이의 갭을 어떻게 빠르게 좁힐 건지.
한국에 이미 자기만의 에이전트 오케스트레이션을 깎고 계신 분들이 꽤 많다는 걸 알고 있습니다. 근데 대부분 본인 작업용이거나 사내에서만 쓰고 계시더라고요. 그 경험이면 전 세계 유저들의 일상을 바꾸는 제품을 만들 수 있다고 생각합니다.
저는 2번 창업을 했습니다. 블록체인 지갑 회사랑 제조업 대상 AI 솔루션 회사를 했고, 외부 투자 없이 누적 120억 매출을 만들었습니다. 솔직히 그 과정에서 첫 창업자가 할 수 있는 실수란 실수는 다 해본 것 같아요. PMF를 찾겠다고 여러 번 방향을 틀었고, 그때마다 배운 게 결국 지금의 판단력이 됐습니다.
이번에 새로 시작하게 된 건 주변 비개발자분들 때문입니다. OpenClaw로 회사 업무를 자동화하거나, 이전에는 개발자한테 부탁해야 했던 일들을 직접 AI에게 시키는 걸 보면서 — 이 사람들이 ChatGPT 쓸 때랑은 확실히 다른 가치를 느끼고 있다는 걸 알게 됐어요. 이건 단순한 도구가 아니라 일하는 방식 자체가 바뀌는 거구나, 싶었습니다.
지금은 AI 에이전트의 새로운 인터페이스를 찾아가는 시기라고 생각합니다. 엄청나게 빠르게 실험하면서 비개발자들의 일상에 실제 변화를 만들 수 있는 타이밍이에요. 당신이 오늘 만든 것이 그게 필요한 사람에게 바로 임팩트를 줄 수 있는, 그런 시기입니다.
이런 분이랑 이야기해보고 싶습니다.
에이전트 오케스트레이션이나 프롬프트 설계를 깊이 파보신 분
샌드박싱이나 권한 설계처럼 "안전하지만 유용한" 실행 환경을 고민해보신 분
기술 가능성보다 사람들이 실제로 쓰는 제품을 만드는 데 집중하시는 분
초기 스타트업에서 빠르게 실험하고 방향을 잡아가는 과정을 즐기시는 분
편하게 커피 한 잔 하면서 이야기 나눠보면 좋겠습니다.
혹시 주변에 이 사람은 꼭 만나야한다고 생각하는 분을 소개해주시면 사례하겠습니다. 널리 퍼질 수 있게 좋아요. 댓글 부탁드려요!
스웨덴, 싱가폴 회사 말고 한국 사람들도 글로벌 서비스를 만들어볼 수 있는 시기입니다 🙂
주변 개발자들을 보면 지난 10월쯤부터 확 바뀌었어요. CLAUDE.md에 에이전트 행동 규칙을 적어두고, 태스크를 나눠서 여러 에이전트에게 분배하고, 그 결과물도 에이전트가 리뷰하게 하더라고요. 한명이 코딩 Agent 공장을 돌리면서 몇개월 걸릴 일을 몇시간만에 합니다.
직접 코드를 짜는 시간보다 에이전트들이 잘 움직이게 판을 짜는 시간이 훨씬 길어진 거죠. 한 명이 수십 개 에이전트를 돌리면서 소프트웨어를 만드는 게 꽤 일반화됐습니다. 펀치카드로 코딩하던 사람들이 GUI를 처음 봤을 때 이런 기분이었을까 싶어요.
근데 이게 아직은 개발자들만의 이야기거든요.
최근에 OpenClaw 써보신 분들은 아시겠지만, 비개발자분들 반응이 장난 아니었습니다. 채팅으로 AI에게 일을 시키면 여러 웹사이트랑 소프트웨어를 오가면서 결과를 가져오는데, 이걸 보고 "AGI 체감했다"는 말이 나올 정도였어요. 개발자들이 터미널에서 하네스 짜서 겨우 하던 걸, 채팅창 하나로 하니까 그런 반응이 나온 거죠.
OpenClaw를 보면서 느낀 게 있습니다. 사람들이 원하는 건 에이전트 기술 자체가 아니라, 자기가 익숙한 방식으로 에이전트를 부리는 것이더라고요. 터미널이 어려운 사람이 대부분인데, 그 허들만 넘겨줘도 가치를 확 느낍니다.
시장을 보면 흐름이 꽤 선명합니다. Lovable, Bolt, Manus나 Genspark 같은 바이브코딩 도구가 "코드를 대신 짜준다"는 가치를 증명했고 거기서 한 발 더 나아가서 "일을 대신 해준다"는 걸 보여줬습니다. 실제로 연 천억 이상 매출을 만들고 있고요.
다음 스텝이 뭘까 생각해보면, 결국 내 맥락을 깊이 이해하면서 여러 도구를 넘나들며 진짜 내 일을 처리해주는 에이전트인 것 같습니다. "만들어줘"에서 "알아서 해줘"로 넘어가는 거죠. 개인이 여러 AI 에이전트에게 업무도 시키고 상담도 받고 일상의 일들을 맡기는 게 올해 안에 훨씬 보편화될 거라고 봅니다.
이걸 만들려면 재밌는 기술 문제들이 있습니다. 에이전트한테 자율성을 충분히 주면서도 안전하게 돌아가는 샌드박싱을 어떻게 설계할 건지. 모델마다 잘하는 게 다른데 유저 요청에 맞춰서 최적 조합을 어떻게 찾을 건지. 에이전트가 맥락을 잃지 않으면서 이 앱 저 앱을 넘나들게 하려면 구조를 어떻게 잡아야 하는지. 기술적으로 되는 것과 사람들이 진짜 쓰는 것 사이의 갭을 어떻게 빠르게 좁힐 건지.
한국에 이미 자기만의 에이전트 오케스트레이션을 깎고 계신 분들이 꽤 많다는 걸 알고 있습니다. 근데 대부분 본인 작업용이거나 사내에서만 쓰고 계시더라고요. 그 경험이면 전 세계 유저들의 일상을 바꾸는 제품을 만들 수 있다고 생각합니다.
저는 2번 창업을 했습니다. 블록체인 지갑 회사랑 제조업 대상 AI 솔루션 회사를 했고, 외부 투자 없이 누적 120억 매출을 만들었습니다. 솔직히 그 과정에서 첫 창업자가 할 수 있는 실수란 실수는 다 해본 것 같아요. PMF를 찾겠다고 여러 번 방향을 틀었고, 그때마다 배운 게 결국 지금의 판단력이 됐습니다.
이번에 새로 시작하게 된 건 주변 비개발자분들 때문입니다. OpenClaw로 회사 업무를 자동화하거나, 이전에는 개발자한테 부탁해야 했던 일들을 직접 AI에게 시키는 걸 보면서 — 이 사람들이 ChatGPT 쓸 때랑은 확실히 다른 가치를 느끼고 있다는 걸 알게 됐어요. 이건 단순한 도구가 아니라 일하는 방식 자체가 바뀌는 거구나, 싶었습니다.
지금은 AI 에이전트의 새로운 인터페이스를 찾아가는 시기라고 생각합니다. 엄청나게 빠르게 실험하면서 비개발자들의 일상에 실제 변화를 만들 수 있는 타이밍이에요. 당신이 오늘 만든 것이 그게 필요한 사람에게 바로 임팩트를 줄 수 있는, 그런 시기입니다.
이런 분이랑 이야기해보고 싶습니다.
에이전트 오케스트레이션이나 프롬프트 설계를 깊이 파보신 분
샌드박싱이나 권한 설계처럼 "안전하지만 유용한" 실행 환경을 고민해보신 분
기술 가능성보다 사람들이 실제로 쓰는 제품을 만드는 데 집중하시는 분
초기 스타트업에서 빠르게 실험하고 방향을 잡아가는 과정을 즐기시는 분
편하게 커피 한 잔 하면서 이야기 나눠보면 좋겠습니다.
혹시 주변에 이 사람은 꼭 만나야한다고 생각하는 분을 소개해주시면 사례하겠습니다. 널리 퍼질 수 있게 좋아요. 댓글 부탁드려요!
스웨덴, 싱가폴 회사 말고 한국 사람들도 글로벌 서비스를 만들어볼 수 있는 시기입니다 🙂
❤11