'Build to learn what to buy' since Build vs Buy is Dead — AI just killed it (by Siqi Chen, Runway) summary w/ lilys.ai and some random notes added

아래 아티클 읽고 릴리스 요약과 덧붙여 쓴 생각 메모

https://venturebeat.com/ai/build-vs-buy-is-dead-ai-just-killed-it

Build vs buy is dead — AI just killed it

 

위 사이트에 아티클 업로드 날짜: December 14, 2025

 

who is Siqi Chen? 

CEO @ Runway Financial Inc. Siqi is the founder and CEO of Runway, a next-gen Financial Planning and Analysis platform making finance accessible to entire teams. His past roles include CEO of Sandbox VR (a16z), VP at Postmates (acquired by Uber), CEO of Hey (acquired by Postmates), and executive at Zynga.

 

* 영어 공부 

visceral : '내장의', '창자의'라는 기본적인 의학적 의미와 함께, '지능이나 이성보다는 본능적이고 깊은 감정에서 우러나오는', '거칠고 세련되지 않은' 감각이나 반응을 나타내는 형용사로 주로 사용됩니다. 논리적 사고가 아닌, 가슴 속 깊은 곳에서 즉각적으로 느껴지는 감정.

bolted: 'Bolted'는 동사 'bolt'의 과거형으로, '볼트로 고정된' (빗장처럼 잠긴), '볼트가 채워진', 또는 (동물 등이) '갑자기 뛰쳐나간', '쏜살같이 달아난' 등의 뜻을 가집니다. 주로 문이나 창문이 빗장으로 잠겨 있거나, 볼트(나사)를 이용해 단단히 고정된 상황을 묘사하며, 빠르게 달아나는 행동을 나타내기도 합니다.

customer rep : 고객 담당자 

 

 

// AI 시대로 들어서면서 작은 솔루션 벤더사들은 더욱 높은 퀄리티를 요구받게 될 듯. 쉽고 적당한건 고객들이 AI로 직접 해결해버릴 수 있는 시대가 와서. 

// 근데 어떻게 생각하면 원래 존재하지 않던 또는 깨닫지 못하고 있던 고객의 니즈를 발굴해주고 (이 글에선 이런 부분을 " which is solving a problem you never really had. "라고 부정적인 시각에서 다뤘지만 ㅎㅎ), 새로운 SW를 사용하도록 설득해주던 (다른 고객사의 베스트 프랙티스를 설명해준다던가 / 이 SW의 새로운 기능을 설명해서) 사실 이게 컨설턴트들이 하던 역할인데 이게 고객들이 직접 하게 되는 방향인듯. 외부 컨설팅이나 외부 기술영업의 내재화. 

 

Does this solve the problem better than what we already proved we can build?

 

 

​아래는 릴리스 요약노트

https://lilys.ai/digest/7677586/8441647?s=1&noteVersionId=4876782

Build vs buy is dead — AI just killed it | VentureBeat

 

 

AI의 등장으로 'Build vs Buy(직접 구축 vs 구매)'의 전통적인 의사결정 프레임워크가 완전히 무너졌습니다. 이제는 외부 벤더의 제안에 의존하기보다, 누구나 AI를 활용해 'Build to learn what to buy(배우기 위해 구축하라)'는 새로운 패러다임으로 전환해야 합니다. 이 콘텐츠는 기술 지식이 없는 팀원조차 몇 시간 만에 작동하는 프로토타입을 만들 수 있음을 보여주며, 구매 결정을 내리기 전에 직접 실험하고 진짜 필요한 기능이 무엇인지 파악하는 실용적인 방법을 제시합니다.

1. AI 등장으로 무너진 'Build vs Buy' 프레임워크 1.1. 전통적인 'Build vs Buy' 의사결정 상황

1. 전통적인 벤더 미팅 상황: 회의실에서 벤더의 시연(데모)을 보고 있으며, 가격과 일정이 모두 적절해 보일 때, 구매 결정을 내리기 직전의 상황이다.

1. 재무팀의 개입: 재무팀 직원이 들어와서 직접 만든 프로토타입을 보여준다.
   1. 이 직원은 코드를 작성할 줄 모르는 사람이다.
   2. 하지만 2시간 만에 Cursor라는 도구를 사용하여 벤더가 시연한 것과 거의 동일하게 작동하는 프로토타입을 만들었다.
   3. 이 프로토타입은 수십만 달러의 비용 없이 2시간의 시간만으로 만들어졌다.

1. 기존 가정의 붕괴: 이 사건으로 인해 소프트웨어 개발 방식, 개발 주체, 의사결정 방식에 대한 기존의 모든 가정이 무너지기 시작한다.

1. 과거의 의사결정 논리: 수십 년 동안 기업들은 "핵심 비즈니스라면 직접 구축(Build)하고, 그렇지 않다면 구매(Buy)하라"는 명확한 규칙을 따랐다.
   1. 구축(Build)은 엔지니어의 시간을 소모하고, 사양 작성, 스프린트 계획, 인프라 관리, 유지보수 등 비용이 많이 들었다.
   2. 구매(Buy)는 더 빠르고 안전하며, 지원과 심리적 안정감을 제공했다.

1.2. AI가 가져온 근본적인 변화

1. 구축 비용의 극적인 하락: AI의 등장으로 구축의 비용과 복잡성이 극적으로 감소했다.
   1. 예전에는 몇 주가 걸리던 작업이 이제 몇 시간 만에 가능하다.
   2. 프로그래밍 언어에 대한 숙련도가 필요했던 작업이 이제 일반 영어(plain English)에 대한 숙련도로 대체되었다.

1. 프레임워크의 소멸: 구축 비용과 복잡성이 급격히 무너지면서, 기존의 'Build vs Buy' 프레임워크는 더 이상 유효하지 않게 되었다.
   1. 이제는 이 변화를 설명할 적절한 용어를 아직 찾지 못한 상태이다.

2. 시장이 아직 필요를 모를 때의 구축 경험 2.1. 필요에 의해 직접 구축하며 얻은 이해도

1. 필요성 기반 구축: 필자의 회사는 필요했던 도구가 존재하지 않았기 때문에 직접 구축할 수밖에 없었다.

1. 실질적인 이해 형성: 이 과정을 통해 기업은 벤더의 제안서나 분석 보고서가 아닌, 실제로 비즈니스에 변화를 가져오는 것이 무엇인지에 대한 본질적인 이해를 개발했다.
   1. 어떤 문제가 해결할 가치가 있는지, AI가 어디서 실질적인 이점을 제공하는지 파악했다.

1. 구매 시점의 명확성: 이러한 명확성을 확보한 후에야 비로소 구매를 시작했다.
   1. 이때는 무엇을 찾고 있는지 정확히 알았기 때문에, 5분 만에 제품의 실질적인 내용과 마케팅을 구별할 수 있었다.
   2. 벤더에게는 이미 그들이 판매하는 것의 기초 버전을 구축해 보았기 때문에, 벤더를 긴장시키는 질문을 할 수 있었다.

3. 비기술 직원이 AI로 문제를 해결하는 사례 3.1. CX팀 직원의 15분 만의 버그 수정

1. 사소한 고객 피드백 포착: CX(고객 경험) 팀 직원이 Slack에서 슬랙의 버그에 대한 사소한 고객 불만을 발견했다.

1. 신속한 문제 해결: 일반적인 회사라면 지원 티켓을 생성하고 다른 사람이 처리하기를 기다렸을 것이다.
   1. 하지만 이 회사는 Cursor를 열고 변경 사항을 설명하자 AI가 수정 코드를 작성했다.
   2. 엔지니어링팀의 검토와 병합을 거쳐, 불만이 접수된 지 단 15분 만에 수정 사항이 프로덕션 환경에 반영되었다.

1. 비기술 직원의 문제 해결: 이 일을 수행한 직원은 기술적인 배경이 전혀 없으며, Python과 JavaScript의 차이도 모를 정도이다.

3.2. AI가 기술 경계를 허물다

1. 80% 문제 해결: AI는 비교적 간단한 코드를 생성하는 데 매우 능숙해져서, 과거에 2주간의 스프린트 계획 회의가 필요했던 문제의 80%를 처리한다.

1. 경계의 소멸: AI는 기술적인 사람과 비기술적인 사람 사이의 경계를 허물고 있다.
   1. 과거에는 엔지니어링에 의해 병목 현상이 발생했던 작업이 이제는 문제에 가장 가까운 사람들에 의해 수행되고 있다.

4. Build vs Buy 의사결정의 전략적 역전 4.1. 전략적 논리의 뒤집힘

1. 전략적 논리의 전환: AI는 'Build vs Buy' 결정의 전체 전략적 논리를 뒤집어 놓았다.

1. 과거 모델의 순서:
   1. 필요 정의 (Define the need).
   2. 구축 또는 구매 결정.

문제점: 필요를 정의하는 데 시간이 오래 걸렸고, 깊은 기술적 전문성이 필요했거나, 시행착오를 통해 돈을 낭비했다.

결과: 수많은 데모를 거치고, 협상, 구현, 데이터 및 워크플로우 이전을 거친 후 6개월과 수십만 달러 후에야 실제로 도움이 되었는지 알 수 있었다.

4.2. 새로운 순서: Build to learn what to buy

1. 새로운 순서: 이제 전체 순서가 뒤바뀐다.
   1. AI로 가벼운 프로토타입을 구축한다.
   2. 이를 사용하여 실제로 필요한 것이 무엇인지 이해한다.
   3. 그런 다음 구매 여부를 결정한다 (이때는 왜 구매해야 하는지 정확히 알게 된다).

1. 실험을 통한 가치 파악: 이 접근 방식은 통제된 실험을 가능하게 한다.
   1. 문제가 실제로 중요한지 파악할 수 있다.
   2. 데모에서 좋아 보이는 기능과 실제 가치를 제공하는 기능을 구분할 수 있다.
   3. 이후에 쇼핑을 시작한다.

1. 구매 결정의 주도권 확보: 외부 벤더가 필요성을 설득하는 대신, 기업 스스로 그 필요성이 존재하는지 여부를 먼저 파악할 수 있게 된다.

4.3. 구매 시점의 변화와 협상력 강화

1. 과거의 후회: 많은 소프트웨어 구매가 실제로 필요하지 않은 문제를 해결하는 데 사용되었을 수 있다.
   1. 구현 3개월 후에 "이것이 정말 도움이 되는가, 아니면 지출을 정당화하려는 것인가?"라고 생각하게 되는 경우가 많았다.

1. 구매 시점의 질문 변화: 이제 구매를 할 때의 질문은 "우리가 이미 구축할 수 있음을 증명한 것보다 이 솔루션이 문제를 더 잘 해결하는가?"로 바뀐다.

1. 협상력 강화: 이 재정의는 대화 전체를 변화시킨다.
   1. 기업은 정보를 갖춘 상태로 벤더 미팅에 임하게 된다.
   2. 더 날카로운 질문을 하고, 강한 위치에서 협상할 수 있다.
   3. 가장 중요한 것은, 실제로 없었던 문제를 해결하는 가장 비싼 실수를 피할 수 있다.

5. 피해야 할 함정: 카고 컬트 AI 5.1. 잘못된 방향으로의 질주: 카고 컬트 사이언스

1. 잘못된 방향으로의 질주: 새로운 AI 역량이 등장하자, 많은 기업이 잘못된 방향으로 질주하고 있다.
   1. AI 네이티브가 되어야 한다는 생각에 GPT 통합, 챗봇 UI, 또는 마케팅 사이트에 'AI'를 붙인 제품들을 대량으로 구매한다.
   2. 이는 변혁이 아니라, 겉모습만 흉내 내는 것이다.

1. 카고 컬트 사이언스 비유: 물리학자 리처드 파인만이 언급한 '카고 컬트 사이언스(Cargo Cult Science)'와 같다.
   1. 제2차 세계대전 후 남태평양 섬 주민들이 비행기 화물을 다시 받기 위해 가짜 활주로와 관제탑을 만들었으나, 기능이 아닌 겉모습만 모방했기 때문에 비행기는 오지 않았다.

1. AI 변혁의 현실: 현재 기업의 이사회에서 일어나는 AI 변혁도 이와 같다.
   1. 리더들은 AI 도구를 구매하지만, 그것이 업무 수행 방식을 실질적으로 바꾸는지, 누구에게 권한을 주는지, 어떤 프로세스를 여는지 묻지 않는다.
   2. 그들은 활주로를 만들었지만, 비행기는 오지 않고 있다.

5.2. 의미를 잃은 AI 라벨링

1. 시장의 함정: 시장 자체가 기업들이 이 함정에 빠지도록 설정되어 있다.
   1. 모든 SaaS 제품이 챗봇이나 자동 완성 기능을 덧붙이고 AI 라벨을 붙이지만, 제품이 실제로 무엇을 하는지는 아무도 신경 쓰지 않는다.
   2. 벤더들은 고객에게 실제 가치를 창출하는지와 관계없이, 체크해야 할 항목으로 AI 라벨을 붙이고 있다.

6. 재무팀의 새로운 초능력과 새로운 패러다임 6.1. 재무팀의 새로운 역량

1. 추측의 종식: 재무팀은 더 이상 추측하거나 영업 제안서에 수십만 달러를 걸 필요가 없다.
   1. 지출하기 전에 테스트하고 실제로 학습할 수 있다.

1. 평가 프로세스의 변화: 예를 들어, 벤더 관리 소프트웨어를 평가할 때 다음과 같이 할 수 있다.
   1. AI 도구로 핵심 워크플로우를 프로토타입해 본다.
   2. 이것이 툴링 문제인지 프로세스 문제인지 파악한다.
   3. 소프트웨어가 아예 필요한지 여부를 파악한다.

1. 구매의 목적 변화: 이것이 모든 것을 내부적으로 구축해야 한다는 의미는 아니다.
   1. 대부분의 경우 여전히 구매하게 될 것이며, 이는 엔터프라이즈 도구가 규모, 지원, 보안, 유지보수 등의 이유로 존재하기 때문이다.
   2. 하지만 이제는 눈을 뜨고 구매하게 된다.
      1. '좋은 것'이 무엇인지 알게 된다.
      2. 데모에 참석하여 엣지 케이스(edge cases)를 이미 이해하고 있으며, 5분 만에 벤더가 특정 문제를 해결하는지 알 수 있다.
      3. 구현 속도가 빨라진다.
      4. 벤더 솔루션에 완전히 의존하지 않으므로 협상이 유리해진다.
      5. 스스로 구축할 수 있는 것보다 진정으로 더 낫기 때문에 도구를 선택하게 된다.
      6. 필요한 것의 형태를 이미 파악했으므로, 단지 그것의 가장 좋은 버전을 찾게 된다.

6.2. 새로운 패러다임: Build to learn what to buy

1. 새로운 모토: 수년간의 모토는 'Build or buy'였지만, 이제는 "Build to learn what to buy (구매할 것을 배우기 위해 구축하라)"로 더 우아하고 스마트하게 바뀌었다.

1. 현재 진행형: 이는 미래의 상태가 아니라 이미 일어나고 있는 일이다.
   1. 고객 담당자가 몇 분 전에 발견한 제품 문제를 AI로 수정하고 있다.
   2. 재무팀은 엔지니어링에 요구사항을 작성하는 것보다 AI 도구로 분석 툴을 더 빠르게 반복할 수 있음을 깨닫고 자체 분석 툴을 프로토타입하고 있다.
   3. 기술적인 것과 비기술적인 것 사이의 경계가 문화적인 것이었음을 깨닫고 있다.

1. 변화를 수용하는 기업의 이점: 이 변화를 수용하는 기업은 더 빠르고 스마트하게 지출할 것이다.
   1. 그들은 어떤 벤더보다도 운영을 더 깊이 이해할 것이다.
   2. 덜 비싼 실수를 저지르고, 도구를 좋게 만드는 것이 무엇인지 이해하기 때문에 더 나은 도구를 구매할 것이다.

6.3. 구식 플레이북을 고수하는 기업의 미래

1. 구식 플레이북 고수: 구식 방식을 고수하는 기업은 계속해서 벤더 피치를 듣고, 예산 친화적인 제안에 고개를 끄덕일 것이다.
   1. 그들은 타임라인을 논의하고, 전문적인 제안서를 실제 해결책으로 착각할 것이다.

1. 결정적인 순간: 그러다가 팀원 중 한 명이 노트북을 열고 "어젯밤에 이 버전의 프로토타입을 만들었는데, 한번 볼래요?"라고 말하며, 6만 달러를 지불하려던 것의 80%를 2시간 만에 만든 결과물을 보여줄 것이다.
   1. 이 순간, 규칙은 영원히 바뀐다.