Don''t build more AI agents until you watch this

🖼️ 인포그래픽

Don''t build more AI agents until you watch this 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Don't build more AI agents until you watch this를 중심으로, Vercel 사례의 핵심은 더 많은 도구가 아니라 실제 우수 직원의 워크플로를 관찰해 반복 가능한 업무만 에이전트화하고, 이후 불를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

Vercel 사례의 핵심은 더 많은 도구가 아니라 실제 우수 직원의 워크플로를 관찰해 반복 가능한 업무만 에이전트화하고, 이후 불필요한 도구를 줄여 성능을 높였다는 점이다.
에이전트 운영의 병목은 이제 “만들 수 있느냐”보다 모델, 문서, 업무 프로세스, 외부 도구가 바뀔 때 하네스를 계속 건강하게 유지할 수 있느냐에 있다.
모델이 좋아질수록 기존 하네스가 오히려 방해가 될 수 있다. 약한 모델을 보완하던 도구와 규칙은 더 강한 모델에는 혼란, 제약, 과도한 권한 문제를 만들 수 있다.
오래된 위키, SOP, 대시보드, CRM 필드, 프롬프트는 에이전트에게 특히 위험하다. 에이전트는 낡은 정보를 읽고 멈추는 것이 아니라 요약, 추천, 라우팅, 실행까지 이어가기 때문이다.
진지한 에이전트 운영은 입력 소스, 권한, 목적, 증거, 실제 가치까지 반복 점검해야 하며, 필요하면 기능 추가가 아니라 삭제·재구축·폐기도 선택해야 한다.

🧩 배경과 문제 정의

이 영상은 AI 에이전트의 성능을 높이려면 도구, 메모리, 통합, 예외 처리, 워크플로를 계속 추가해야 한다는 통념을 문제 삼는다.
Vercel 사례는 오히려 에이전트 도구의 상당 부분을 삭제한 뒤 성능이 좋아졌다는 반례로 제시된다.
핵심 문제는 “에이전트를 얼마나 많이 만들 것인가”가 아니라, 실제 업무에서 반복 가능하고 검증 가능한 부분만 에이전트화하고, 이후에도 계속 유지보수할 수 있는가에 있다.
에이전트는 단일 앱이 아니라 모델, 문서, 업무 프로세스, 외부 도구, 권한, 로그, 승인 흐름이 함께 움직이는 시스템이므로, 출시보다 지속적인 하네스 관리가 중요하다.
OpenAI와 Anthropic 같은 플랫폼 기업의 경쟁력도 모델 자체만이 아니라 터미널, 브라우저, 승인, 샌드박스, 로그, 메모리, 설정 관리처럼 에이전트가 일하는 작업 환경을 계속 개선하는 데서 나온다.
검증 필요: 제공된 section-detail에는 16:02 이후의 구체 타임라인이 포함되어 있지 않으므로, 영상 말미의 추가 결론이나 콜투액션은 원 transcript 확인 전에는 단정하지 않는다.

🕒 시간순 섹션별 상세정리

Vercel 사례와 도구 추가 통념의 반례

Vercel은 에이전트 도구의 80%를 삭제한 뒤 성능을 개선했고, 이는 에이전트가 더 많은 도구와 맥락과 통합을 받을수록 좋아진다는 일반적 기대와 충돌한다 [00:37]
인바운드 메시지에는 실제 리드, 스팸, 영업처럼 보이는 지원 문의, 중요한 계정, 빠른 답변이 필요한 건, 리서치와 라우팅이 필요한 건이 섞여 있었고, 문제는 단순 자동화가 아니라 지저분한 업무 분류였다 [00:52]

에이전트 유지보수의 핵심은 추가가 아니라 제거

에이전트는 도구를 계속 쌓을 때보다 도구를 덜어낼 때 더 좋아졌고, 스킬과 도구가 많은 Codex나 Claude 환경에서도 같은 문제가 생긴다 [01:43]
많은 구축자는 작업 하나에 도구, 메모리 파일, Slack, 브라우저, CRM 액션, 예외 처리를 계속 붙이며 겉보기에는 강력하지만 점점 신뢰하기 어려운 에이전트를 만든다 [02:02]

모델 개선이 기존 harness를 망가뜨리는 역설

에이전트 밑의 모델은 고정되어 있지 않고 도구 사용, 다단계 추론, 지저분한 지시 이해, 파일 읽기, 중요한 정보 기억, 세부 단계 없이 업무를 진행하는 능력이 계속 좋아진다 [03:31]
약한 모델을 돕던 도구는 강한 모델을 혼란스럽게 만들 수 있고, 신뢰 낮은 모델을 보호하던 규칙은 더 나은 모델을 가두며, 둔한 에이전트용 workflow는 더 유능해진 모델에는 drag가 된다 [03:58]

오래된 문서와 프로세스가 에이전트의 위험을 키운다

프롬프트, 위키, 대시보드, 자동화, SOP, Slack 채널, 템플릿은 업무 변화 뒤에도 오래 남고, 기업은 AI 이전부터 이런 systems drift 문제를 안고 있었다 [05:32]
제품 위키, CRM 필드, activation 정의, 지원 태그, roadmap, owner, process가 바뀌어도 문서가 따라오지 않으면 일반 소프트웨어에서는 성가신 정도지만 에이전트에게는 훨씬 위험하다 [05:50]

에이전트는 앱보다 움직이는 운송수단에 가깝다

Stewart Brand의 유지보수 관점은 출시 이후 중요한 시스템을 살리는 작업에 초점을 맞추며, 에이전트는 한 번 배포하고 떠나는 앱보다 sailboat와 더 비슷하다 [07:18]
날씨가 바뀌고 줄이 느슨해지고 소금이 스며드는 것처럼, 어제 작동한 setup도 내일 틀릴 수 있으며 유지보수는 나쁜 설계의 보상이 아니라 움직이는 시스템의 조건이다 [07:38]

플랫폼 경쟁의 핵심은 모델이 아니라 계속 진화하는 작업 환경

frontier lab과 platform company의 암묵적 베팅은 모델 개선만이 아니라 더 나은 모델로 harness를 더 빠르게 ship하고 evolve하는 능력에 있다 [08:17]
Codex의 강점은 강한 모델만이 아니라 터미널, desktop app, IDE, browser, computer use, files, plugins, memory, approvals, sandboxing, network controls, keychain storage, managed configs, logs로 구성된 유지보수된 workbench에 있다 [08:42]

커스텀 하네스가 프롬프트를 넘어 유지보수 책임으로 바뀐다

간단한 위임에는 소스 폴더, 반복 가능한 방법, 작업 범위, 건드리면 안 되는 영역, 필요한 증거, 사람이 판단할 지점만으로도 충분할 수 있다 [12:01]
깊은 커스텀 하네스에는 데이터 피드, 리뷰 화면, 권한 수준, 로그, 모델 선택, 에스컬레이션 경로, 승인 규칙, 모델 변경 시 대응 계획이 포함되며 장기 유지보수 책임이 커진다 [12:15]

하네스는 직무별 작업장이고, 개선만큼 삭제와 재구축도 필요하다

ChatGPT, Claude, Codex 같은 도구를 실제 업무에 쓸 때 하네스는 프로젝트 폴더, 기억, 프롬프트, 소스 문서, 승인 습관, 브라우저 접근, 파일 규칙, 도구, 검증 루프, 증거 요청 방식으로 구성된다 [13:46]
제품 리더에게는 계획 전 읽는 소스가, 영업에는 CRM 필드와 통화 메모와 승인 단계가, 지원에는 정책 저장소와 에스컬레이션·환불 규칙이 하네스가 된다 [14:13]

진지한 에이전트는 입력, 권한, 목적, 증거, 가치까지 계속 점검해야 한다

에이전트가 무엇을 읽는지 먼저 확인해야 하며, 소스가 최신인지, 워크플로가 이동했는지, 새로 중요해진 소스나 오히려 오해를 만드는 오래된 소스가 있는지가 성능과 안전성을 좌우한다 [15:52]
읽기, 초안 작성, 티켓 생성, Slack 게시, 기록 업데이트, 지출, 발행 권한의 범위를 점검해야 하며, 약한 모델에 무해했던 권한은 강한 모델에는 과도할 수 있고 낡은 제한은 더 나은 모델을 막을 수 있다 [16:02]

에이전트의 역할 변경, 증거, 가치까지 의도적으로 점검한다

역할이 요약인지, 계획·주제 발견·트레이드오프 추천·업무 라우팅으로 바뀌는지 확인하고, 바꿀 거라면 조용히 변하게 두지 말고 의도적으로 바꿔야 한다 [16:21]
고객 불만 같은 결론은 말로 끝내지 말고 티켓, 영업 노트, 고객 표현 인용 등 사람이 확인할 수 있는 출처와 연결되어야 한다 [16:41]
에이전트는 어떤 소스를 확인했고 무엇에는 접근하지 못했는지도 말해야 하며, 증거는 사람이 검토할 수 있는 추적 가능한 기록이어야 한다 [16:54]
출력이 실제로 읽히고 일을 바꾸며 검토 후 시간을 절약하는지, 아니면 일을 더 만들거나 기존 보고서를 중복하는지 가치까지 확인해야 한다 [17:05]

에이전트 유지보수의 미래는 더 강한 능력이 아니라 잘 관리되는 능력이다

모델이 좋아졌거나 사업이 바뀌었다면 에이전트는 재구축되거나 은퇴해야 할 수도 있다 [17:19]
에이전트는 주변 세계가 변해서도 깨지고 내부 모델이 개선되어서도 깨지며, 유지보수는 이 두 변화 사이에 하네스를 맞추는 일이다 [17:28]
미래의 에이전트는 더 많은 능력만이 아니라 더 잘 유지되는 능력이 중요하며, 둘 중 하나라도 무시하면 조용히 위험해질 수 있다 [17:42]
저자는 에이전트를 이해하는 AI 바깥의 책으로 Stewart Brand의 『The Maintenance of Everything』을 추천하며, 기술 시스템의 유지보수를 생각하는 법을 배울 수 있다고 마무리한다 [18:03]

🧾 결론

이 영상의 중심 주장은 “AI 에이전트를 더 많이 만들기”보다 “이미 만든 에이전트가 변화 속에서도 안전하고 유용하게 작동하도록 유지하기”가 더 중요하다는 것이다.
하네스는 단순한 프롬프트나 래퍼가 아니라 에이전트가 무엇을 읽고, 어떤 도구를 쓰며, 어디까지 실행하고, 어떤 증거를 남기고, 언제 사람에게 넘기는지를 정하는 작업 환경이다.
에이전트는 내부적으로는 모델 성능 변화, 외부적으로는 회사의 문서·프로세스·업무 우선순위 변화 때문에 조용히 망가질 수 있다.
따라서 좋은 에이전트 운영은 도구를 계속 붙이는 방식이 아니라, 오래된 소스와 불필요한 권한을 줄이고, 실제 업무 흐름에 맞게 하네스를 계속 조정하는 방식에 가깝다.
검증이 필요한 부분: Vercel이 실제로 어떤 내부 지표에서 얼마나 개선됐는지, 도구 80% 삭제가 구체적으로 어떤 범위였는지는 이 입력만으로는 독립 검증할 수 없다.

📈 투자·시사 포인트

AI 에이전트 시장에서 장기 경쟁력은 단순 모델 성능뿐 아니라 터미널, 브라우저, 파일, 승인, 샌드박스, 로그, 메모리 같은 작업 환경을 얼마나 잘 유지·진화시키느냐에 달릴 수 있다.
기업이 에이전트를 도입할 때는 “어떤 모델을 쓸 것인가”와 함께 “하네스 유지보수를 내부 역량으로 가질 것인가, 플랫폼에 맡길 것인가”를 전략적으로 판단해야 한다.
에이전트 도입 효과를 평가할 때는 자동화 범위보다 실제로 사람이 읽고 쓰는 시간이 줄었는지, 잘못된 작업을 늘리지 않았는지, 기존 보고서나 업무와 중복되지 않는지를 봐야 한다.
플랫폼 기업에는 모델 자체보다 모델을 둘러싼 workbench, 권한 관리, 감사 로그, 외부 시스템 통합, 업데이트 속도가 차별화 요소가 될 수 있다.
검증이 필요한 부분: 특정 플랫폼이나 기업이 이 접근법으로 시장 점유율, 매출, 고객 유지율에서 우위를 확보했다는 투자 판단은 이 transcript만으로는 단정할 수 없다.

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

Vercel이 “도구의 80%를 삭제했다”는 수치와 실제 개선 폭은 영상 내 주장으로 제시되지만, 구체적인 측정 기준·기간·성과 지표는 별도 확인이 필요하다.
Vercel 사례가 모든 조직의 에이전트 운영에 일반화될 수 있는지는 불확실하다. 업무 유형, 데이터 품질, 승인 체계, 기존 문서 상태에 따라 결과가 달라질 수 있다.
“모델이 좋아질수록 기존 하네스가 오히려 방해가 될 수 있다”는 논지는 설득력 있지만, 실제로 어느 시점에 도구·규칙·권한을 줄여야 하는지는 조직별 실험과 로그 검토가 필요하다.
자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.