How To Build The Future: Paul Graham & Amjad Masad

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

How To Build The Future: Paul Graham & Amjad Masad를 중심으로, 사용자의 반복 작업이 제품의 출발점이었다. Replit은 비개발자가 ChatGPT와 개발 환경 사이에서 코드와 오류를 복사를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 사용자의 반복 작업이 제품의 출발점이었다. Replit은 비개발자가 ChatGPT와 개발 환경 사이에서 코드와 오류를 복사하는 모습을 관찰하고, 오류 수정부터 실행·인프라 준비까지 이어지는 개발 자동화 기회를 찾았다.
2. 에이전트의 완료 기준은 작동하는 프로그램이다. 한 번의 답변으로 끝내지 않고 실행 결과를 확인하며 수정해야 한다. 모델 성능이 높아질수록 이를 구현하는 기술은 보편화되므로, 초기 구현만으로 경쟁력을 유지하기 어렵다.
3. 오래 쌓은 인프라가 새로운 제품의 기반이 됐다. Replit은 기존 클라우드·배포·협업 기능을 에이전트의 도구로 연결했다. 보안, 샌드박싱, 파일 시스템의 되돌리기 기능도 기업 고객을 확보하는 요소로 제시됐다.
4. 개발 자동화는 기업의 구매와 성과 평가까지 바꾼다. 직원이 직접 내부 도구와 기존 시스템을 대체하기 시작하면서, 사용자의 편의와 관리자의 통제 사이에 긴장이 생긴다. 마사드는 균등한 토큰 배분보다 실제로 창출한 가치를 평가해야 한다고 주장한다.
5. 미래 예측은 장기적인 몰입과 반복적인 수정에서 나온다. 두 사람은 Replit의 전환을 오랜 문제의식과 점진적 개선이 누적된 결과로 해석한다. 기술의 지수적 변화를 예상하되 고객 관찰과 직접 사용을 통해 판단과 제품을 계속 수정하는 태도가 강조된다.

🧩 배경과 문제 정의

• Replit의 AI 개발 기능은 사용자가 챗봇과 개발 환경 사이에서 코드와 오류를 복사하며 앱을 만드는 행동에서 출발했다. 핵심 과제는 코드 생성뿐 아니라 오류 수정, 실행, 인프라 준비까지 자동화하는 것이었다.
• 모델 성능이 높아질수록 에이전트를 구현하는 기술은 빠르게 보편화된다. Replit은 오랫동안 구축한 실행·배포·협업 인프라와 보안·신뢰성에서 경쟁력을 찾는다.
• 소프트웨어 제작의 접근성이 높아지면서 기업 내부 직원도 업무 도구와 기존 시스템을 직접 만들기 시작했다. 이에 따라 제품의 과제도 개발 자동화에서 기업의 통제 방식, 성과 평가, 업무 조직의 변화로 확장된다.

🕒 시간순 섹션별 상세정리

1. 비개발자의 수작업에서 발견한 개발 자동화 수요

• 자연어로 개발 전체를 맡기기 전에도 자동완성이 코드의 약 50~60%를 생성하고 있었다. 일부 사용자는 이미 AI로 코드 전부를 작성했다 [02:13]
• 코딩 경험이 없는 사용자는 ChatGPT에서 받은 코드를 Replit에 붙여넣고, 실행 오류를 다시 챗봇에 전달한 뒤 수정 코드를 옮겼다. 사무실에 초대한 사용자의 작업을 직접 관찰하면서 이 반복 과정을 자동화할 기회를 발견했다 [02:55]

2. 한 번의 응답에서 프로그램 완성까지 이어지는 에이전트

• 자동화에는 대화의 왕복뿐 아니라 오류 이해와 반복 수정이 필요했다. 종료 조건도 한 차례 응답을 마치는 것이 아니라 프로그램이 실제로 작동하는 상태여야 했다 [03:38]
• Replit이 LLM을 작업 완료까지 실행하자 모델 회사들도 구현 방법에 관심을 보였다. 모델이 덜 유능했던 2024년의 실행 제어 장치는 현재보다 열 배 복잡했다는 설명이다 [04:12]

3. 코드 생성과 인프라 준비를 연결한 제품

• Replit은 AI가 데이터베이스와 Redis를 생성하고 앱을 호스팅하는 등 인프라도 준비할 수 있음을 구현했다. 기존에 구축한 클라우드 기능을 도구 호출로 연결할 수 있었던 점이 차별점이었다 [05:03]
• 폴 그레이엄은 2024년 7월 제품을 봤고, 정식 출시는 같은 해 9월이었다. 아므자드 마사드는 당시 안드레이 카르파티가 이를 AGI를 체감한 순간으로 표현했다고 회고했다 [05:25]

4. 개발 장벽을 끝까지 낮추겠다는 초기 구상

• 프로그래밍이 쉬워지는 정도와 참여자 증가 사이에는 초선형 관계가 있다는 관점이 제품의 기반이었다. 그레이엄은 소비자 제품이 10% 쉬워지면 사용자가 10% 늘어나는 수준을 넘어 두 배가 될 수도 있다는 예를 들었다 [06:11]
• 마사드는 Replit이 성공하려면 개발을 충분히 쉽게 만드는 데까지 나아가야 한다고 판단했다. 2015~2016년 초기 투자 자료에도 수백만 명의 코딩 활동을 바탕으로 예측 모델을 학습한다는 구상이 있었으며, 이는 Transformer 등장 이전이었다 [06:57]

5. 미래 예측을 뒷받침한 오랜 문제의식

• 마사드는 어릴 때 Nokia 휴대전화를 사용하며 휴대전화가 새로운 컴퓨터가 될 것으로 생각했다. 이후 Replit의 모바일 프로그래밍 앱도 비웃음을 샀지만, 모바일에서 개발하려는 방향을 이어갔다 [07:39]
• 온라인 개발 환경에 대한 개인적인 필요는 2008년 수업 중 Symbian 스마트폰으로 프로그래밍하고 싶었던 경험으로 거슬러 올라간다 [08:45]

6. 직접 코드를 만드는 기술에 대한 상실감과 AI 수용

• 2024년 시연에서 생성된 코드를 ‘목적 코드’처럼 취급하라는 말은 그레이엄에게 충격이었다. 수십 년간 직접 만들어 온 코드가 사람이 들여다볼 필요가 적은 결과물로 바뀌는 경험이었기 때문이다 [09:41]
• 마사드는 AI를 받아들이는 과정에 부정, 우울, 수용의 단계가 있을 것으로 봤다. 자신도 2020년 무렵 사랑하던 기술을 잃는 듯한 슬픔을 먼저 겪었다고 했다 [10:35]

7. 에이전트의 능력을 체감하게 만드는 사용 방식

• 마사드는 Claude Code도 영향을 줬겠지만, OpenClaw가 작업을 끝까지 수행하는 LLM을 대중이 경험하게 한 주요 계기라고 봤다. 문자로 지시할 수 있는 사용 방식의 힘도 자신이 과소평가했다고 했다 [11:42]
• 명확한 비전과 제품만으로 사용자가 가치를 바로 이해하는 것은 아니다. 사람들이 기술을 어떻게 경험하는지 반복해서 조정해야 하며, 이 교훈이 향후 Replit에도 영향을 줄 것으로 예상했다 [12:06]

8. 사용자 관찰과 강한 디자인이 만든 제품 문화

• 마사드는 사용자가 혼란을 겪거나 버그에 막히는 모습을 보는 일이 고통스러워 관찰을 꺼렸다. 하야의 독려로 사용자와 계속 대화하고 가까이 지내는 문화가 자리 잡았다 [13:04]
• 초기의 두드러진 그래픽 디자인은 십대 해커가 많았던 사용자층에 매력적으로 작용했고, Replit만의 개성을 형성했다 [13:27]

9. 기업 고객을 확보하는 보안과 시스템 기반

• 기업 고객은 신뢰성과 보안에 민감하다. Replit의 보호 장치는 제품을 느리거나 비싸게 만들기도 하지만, 기업은 이를 긍정적으로 평가한다는 설명이다 [15:51]
• 자연어로 코드를 생성하는 화면 아래에는 배포와 샌드박싱 인프라가 있다. 커널·운영체제 엔지니어를 두고 트랜잭션 처리와 완전한 되돌리기를 지원하는 파일 시스템도 직접 구축했다 [16:20]

10. 사람 간 협업 인프라를 에이전트에 재사용

• 기존 협업 환경에서는 에이전트를 또 다른 사용자로 추가할 수 있었다. 초기 버전부터 사람과 에이전트가 같은 프로젝트에서 함께 작업할 수 있어, 협업용으로 만든 기반을 AI 개발에 그대로 활용했다 [17:19]
• 코드 실행·샌드박싱, 배포·클라우드 서비스, 인프라와 IDE의 연결, IDE를 담당하던 조직 사이에 에이전트 팀을 신설했다. 기존 팀들은 에이전트가 사용할 인프라 도구와 편집 도구를 만드는 방향으로 전환했다 [18:20]

11. 초기 모델의 약점을 보완했던 편집 도구

• 2024년에는 코드 편집 자체가 어려웠다. 모델이 줄 번호를 잘못 만들어낼 수 있어 번호에 의존하기 어려웠고, 텍스트의 교체 위치를 안정적으로 찾는 자체 편집 도구가 필요했다 [19:00]
• 모델이 함수 중간을 나중에 완성하라는 표시로 남겨 실행할 수 없는 코드를 내놓기도 했다. 마사드는 채팅 모델이 응답을 일찍 끝내려는 성향의 영향일 수 있다고 추정했으며, Replit은 이를 감지해 다시 작업시키는 절차를 구현했다 [19:36]

12. 불완전한 베타도 가치가 있었던 비용 구조

• 출시 당시에는 겨우 작동하는 수준이었으며, 마사드는 실패 비율을 처음 언급한 50%에서 약 30%로 수정했다. 코딩을 전혀 못하던 사용자에게는 약 70%의 성공 가능성도 큰 개선이었다 [20:56]
• 초기에 많은 비용을 지불한 고객은 외주 개발자를 찾던 사람들이었다. 마사드는 앱 개발에 외주로 10만 달러를 쓰는 경우와 Replit에 1,000달러를 쓰는 경우를 비교하며 약 100배의 비용 차이를 강조했다 [21:25]

13. 성장하던 Bounties를 중단한 이유

• Replit Bounties는 플랫폼의 십대 개발자들이 의뢰를 수행하도록 연결해 외주 수요를 충족하려는 시도였다. 참여자들은 당시의 기초적인 AI 기능만으로도 경쟁 우위를 얻고 있었다 [22:23]
• 서비스는 빠르게 성장했지만, 마사드는 결국 고객이 에이전트에 전체 작업을 직접 맡기게 될 것으로 판단했다. 사람이 대신 에이전트에 요청하는 중간 단계의 사업은 지속하기 어렵다고 보고 중단했다 [22:44]

14. 기업 내부 직원이 주도하는 소프트웨어 대체

• 다국적 기업과 은행에서는 Replit을 채택한 소수 직원이 내부 시스템부터 바꾸고 있었다. 마사드는 고객들이 연간 1,000만 달러를 지불하는 SaaS나 오래된 소프트웨어를 대체하는 사례를 언급했다 [23:13]
• 별도의 프로젝트 사례에서는 기존 예상 비용이 1,000만 달러였지만 Replit에 25만 달러를 썼다는 고객의 설명을 전했다. 기술 기업도 고객이지만, 자체 개발 역량이 부족한 은행·제조업체 등에서 영향이 더 크다고 봤다 [23:59]

15. 기업 구매자의 통제와 사용자의 편의 사이의 긴장

• 기업용 제품에는 관리자와 IT 부서가 권한을 통제하고 예산을 설정하는 기능이 필요하다. 실제 사용자와 구매 결정권자가 다른 구조가 제품에 영향을 준다 [25:55]
• 사용자가 원하는 도구를 선택할 여지는 커졌지만, IT·보안 부서의 요구 때문에 사용자 경험이 나빠지는 문제는 남아 있다. 조직 내부의 적극적인 사용자를 돕는 일과 구매자의 통제 요구를 충족하는 일 사이에 긴장이 생긴다 [26:36]

16. 토큰 균등 배분보다 중요한 성과의 가시화

• 마사드는 직원마다 월 100달러어치 토큰을 배정하는 식의 제한에 반대했다. 투자수익률을 봐야 하며, 고객사에서는 한 사람이 다른 사람보다 100배의 가치를 만들 수도 있다는 설명이다 [27:03]
• 단기적으로는 기업이 요구하는 지출 통제를 제공해야 도입할 수 있다. 이후에는 어느 곳에서 가치 있는 결과가 나오는지 보여주는 더 나은 방식을 개발해야 한다는 방향이다 [27:37]

17. 개발 자동화에서 ‘스스로 운영되는 회사’로 확장

• Replit은 자신을 바이브 코딩으로만 설명하지 않으며, ‘셀프 드라이빙 컴퍼니’로의 전환을 지원하는 플랫폼을 지향한다. 회사 자체를 첫 고객이자 실험실로 삼아 AI가 업무와 조직을 어떻게 바꾸는지 탐색하고 있다 [29:07]
• 마사드는 소프트웨어 제작의 접근성이 큰 변화를 일으킬 것은 예상했지만, 일하는 방식 자체를 근본적으로 바꿀 정도일지는 충분히 인식하지 못했다고 했다. 프로그래밍이 이제 기업 업무의 중심이 될 수 있다는 가능성을 제기했다 [29:40]

18. AI 시대의 재창조와 모방을 앞서는 경쟁력

• AI는 기존 제품과 기능을 범용화하는 강력한 힘이므로, 기업의 자기 재창조는 선택에서 사실상 필수로 바뀌고 있다. Replit이 기업에 AI가 들어가는 통로가 되겠다는 목표도 누구나 내세울 수 있는 모호한 구호를 넘어 구체화해야 한다. [30:11]
• 아이디어를 빠르게 앱으로 구현한다는 Replit의 방향은 경쟁사에 복제되고 있다. 그러나 경쟁사가 모방하는 것이 6개월 전의 모습이라면, Replit은 계속 진화해 앞서갈 수 있다. 경쟁 때문에 가만히 있을 수 없는 모든 기업에 Replit을 확산하는 것이 목표다. [30:55]

19. 고객의 개별 문제를 해결하며 만드는 큰 전환

• 큰 전략을 발표하는 것보다 고객의 실제 사용 사례가 전략을 입증해야 한다. 전체 방향을 정해 두고, 그 방향에 맞는 일을 하는 고객을 도운 뒤 다른 고객도 같은 일을 할 수 있도록 확장하는 방식이다. [31:33]
• 그동안 쌓은 시스템 프로그래밍 역량은 고객 내부로 들어가 새로운 요구를 발견할 기반이 된다. Replit Agent도 외부에서는 급격한 전환처럼 보였지만, 내부에서는 여러 점진적 변화가 누적된 결과였다. [32:08]

20. 대규모 에이전트 사용이 요구하는 클라우드 전환

• Replit의 핵심 성향은 미래의 작업 방식을 먼저 경험하는 데 있다. 다만 기술이 아직 제대로 작동하지 않거나 사람들의 습관이 천천히 바뀌기 때문에, 이런 접근에는 답답함도 따른다. 클라우드 개발도 여전히 설득이 필요한 사례다. [33:55]
• Replit 내부에서는 개인이 사용하는 에이전트 수가 하나에서 10개, 100개를 거쳐 언젠가 1만 개까지 늘어날 것으로 예상한다. 이 규모를 맥북에서 실행하기는 어렵다는 판단이 로컬 작업에서 클라우드로 이동하리라는 전망의 근거다. 현재는 여전히 데스크톱 중심의 작업이 많다. [34:29]

21. 기술 변화에 맞춰 정체성과 작업 방식을 바꾸는 능력

• 마사드는 컴퓨터가 어떤 일을 충분히 잘하게 되면 그 일을 붙잡기보다 다음 과제로 옮겨가는 태도를 갖고 있다. 기존 작업을 버리고 다시 시작하거나 Replit 내부의 코드를 재작성해 온 경험도 이 태도와 연결된다. [35:57]
• 자신의 정체성을 특정 업무에 고정하면 변화에 적응하기 어려워진다. 아이들에게 AI 시대를 준비시키는 데에도 유연성, 적응력, 평생 학습하는 태도가 핵심이라는 관점이다. [36:31]

22. 직접 사용한 경험이 줄이는 불안과 기업 도입의 격차

• 한 대형 통신사 해커톤의 전후 설문에서는 Replit 사용 전 약 80%가 AI와 일자리에 불안을 느꼈지만, 한 시간 사용한 뒤에는 약 80%가 낙관적인 태도로 바뀌었다. 이 사례는 짧은 직접 경험만으로도 AI에 대한 인식이 크게 달라질 수 있음을 보여준다. [37:50]
• 실리콘밸리와 다른 기업들의 AI 경험 사이에는 큰 시차가 있다. 마사드가 보기에 많은 은행의 비개발 부문은 아직 2023년 무렵의 ChatGPT와 비슷한, 다른 시스템에 거의 연결되지 않은 LLM을 사용한다. 반면 실리콘밸리에서는 이미 실제 작업을 수행하는 에이전트로 활용이 이동했다. [38:26]

23. 예측을 수정하는 습관과 연산 자원의 성장 추세

• 마사드는 미래를 예측하고, 기존 예측을 다시 살펴 수정하는 일을 의식적으로 반복한다. 미래 예측은 연습으로 발전시킬 수 있는 기술이며, 일정한 원칙도 활용할 수 있다는 입장이다. [40:27]
• 그가 레이 커즈와일에게서 얻은 관점은 세계의 연산량을 로그 척도로 보면 증가 추세가 직선에 가깝다는 것이다. AI가 이 추세를 새로 만들었다기보다 연산 자원의 증가가 AI를 가능하게 했다는 해석으로 계속된다. [40:54]

24. 지수적 변화를 기본값으로 삼고 미래를 향해 구축하기

• 미래를 예상하는 출발점은 세상을 정적인 상태로 보지 않고 지수적으로 변하는 환경으로 받아들이는 데 있다. 마사드는 2019년 GPT-2를 처음 봤을 때 이런 관점으로 채팅, 에이전트, 개인 비서의 가능성을 상상했다고 회고한다. [42:00]
• 현재의 한계만 보면 기술이 작동하지 않을 이유를 찾기 쉽다. 마사드는 변화가 계속될 것이라는 전제를 받아들이면서, 컴퓨터가 자신의 기술 영역을 점점 더 수행하게 되는 상황도 예상하고 그 방향으로 제품을 만들어야 한다고 본다. [42:34]

🧾 결론

• Replit 사례에서 미래를 만드는 일은 거대한 전략을 선언하는 것보다, 고객이 겪는 구체적인 문제를 해결하고 그 해결책을 다른 고객에게 확장하는 과정에 가깝다.
• 모델의 발전은 기존 구현의 가치를 빠르게 낮추지만, 실행·배포·보안·협업을 연결해 실제 작업을 완수하는 제품의 중요성을 높인다.
• 소프트웨어 제작의 접근성이 높아지면 변화는 개발 부서에 머물지 않는다. 내부 시스템, 예산 통제, 직원의 성과 평가와 조직 운영까지 제품의 과제가 확장된다.
• 특정 기술이나 업무에 정체성을 고정하기보다 AI를 직접 사용하고 다음 문제로 이동하는 유연성이 두 사람의 논의를 관통한다.

📈 투자·시사 포인트

• 경쟁력의 지속성을 확인필요가 있다. 에이전트 구현이 쉬워진다는 논의를 따르면, 기능 시연뿐 아니라 실행 인프라·보안·신뢰성과 고객 문제를 해결하는 속도를 함께 살펴야 한다.
• 외주 개발과 기존 소프트웨어 지출이 대체 대상이 될 수 있다. 인터뷰의 비용 절감 사례는 이런 수요를 보여주지만, 개별 사례를 시장 전체의 절감률이나 수익성으로 일반화할 수는 없다.
• 기업 도입에는 편의와 통제를 함께 충족하는 제품이 필요하다. 현업 직원의 자발적인 사용이 확산되더라도 권한·예산·보안 요구를 해결해야 조직 차원의 도입으로 이어질 수 있다.
• 사용량보다 성과를 보여주는 기능이 중요해질 수 있다. 토큰 지출을 제한하는 데서 나아가 어떤 업무에서 가치가 발생했는지 설명하는 능력이 기업 고객의 투자 판단에 영향을 줄 수 있다.
• 대규모 에이전트 사용은 클라우드 수요로 이어질 가능성이 있다. 다만 개인이 수많은 에이전트를 사용한다는 전망은 Replit 내부의 예상이며, 실제 확산 속도는 별도로 확인해야 한다.

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

• 출시 초기 실패율 약 30%는 마사드가 대화 중 기존 발언을 수정한 수치다. 평가 대상, 작업 난도, 성공 판정 기준이 제시되지 않아 현재 제품의 성능 지표로 사용할 수 없다.
• 외주 개발 10만 달러와 Replit 1,000달러의 비교, 예상 비용 1,000만 달러와 실제 지출 25만 달러의 비교는 인터뷰에서 소개한 사례다. 기능 범위, 유지보수, 검증 비용이 같은 조건인지 확인되지 않았다.
• 대형 통신사 해커톤에서 불안과 낙관 응답이 각각 약 80%였다는 설명에는 표본 규모와 설문 방식이 제시되지 않았다. 짧은 사용 경험에 따른 인식 변화를 장기적인 고용 전망으로 해석하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복적으로 코드를 옮기거나 오류를 전달하는 업무를 하나 골라, 실제 사용 과정을 관찰하고 자동화할 단계를 기록한다.
• 에이전트의 완료 기준을 답변 생성이 아니라 프로그램 실행, 오류 수정, 필요한 배포까지 포함한 결과로 정의한다.
• 작은 내부 도구를 시범 제작하고 제작 시간·지출·수정 횟수·실제 사용 결과를 기록해 기존 방식과 비교한다.
• 기업 도입을 검토할 때 현업 사용자의 편의와 함께 권한 관리·예산 통제·보안·되돌리기 기능을 확인한다.

❓ 열린 질문

• 모델이 에이전트 구현을 계속 단순화할 때, Replit의 기존 인프라는 얼마나 오래 차별화 요소로 남을 수 있을까?
• 직원의 자율적인 도구 제작과 기업의 보안·예산 통제를 사용자 경험을 해치지 않으면서 어떻게 연결할 수 있을까?
• 개인이 만든 업무 성과를 어떤 기준으로 측정해야 AI 지출과 창출 가치를 설득력 있게 연결할 수 있을까?