Base44는 어떻게 6개월 만에 800억에 팔렸나: Lenny's Podcast (youtube.com) ↗

• 혼자, 외부 투자 0원, 6개월. 결과는 Wix에 8천만 달러(+성과급) 매각. 첫 직원 채용은 매각 1.5개월 전. 창업자 Maor가 직접 회고
• 시작 동기 두 가지. 여자친구의 작은 사업용 웹앱이 필요했는데 기존 도구가 너무 불편했음. 그리고 이스라엘 스카우트 단체에 자원봉사 갔더니 “에이전시는 1억 부른다” 상황. 둘 다 “LLM은 코드 짤 수 있는데, 일반인이 쓸 환경이 없을 뿐”이라는 같은 진단
• 첫 사용자 10명은 친한 친구 3명을 매주 옆에 앉혀 놓고 직접 빌드해줌. 쓰다가 막히면 본인이 노트북으로 코드 고쳐서 바로 배포. ProductHunt 1차 런칭은 망함(15명만 가입)
• 성장 채널은 LinkedIn 하나. Twitter, 인플루언서 광고($2K), 페이드 광고 전부 실패. “한 채널에서 통하기 시작하면 거기에 다 걸어라”가 결론
• 활성화의 반직관: 사용자 의도를 더 정확히 파악하던 중간 단계를 일부러 지움. “더 좋은 결과물”보다 “더 빨리 놀라게 하기”를 택함

1인 부트스트랩이 모든 회사에 맞는 건 아님

• 회사에 파는 B2B 제품이면 비추. 어차피 영업 인력 뽑아야 막힘이 풀리는 구조
• 입소문으로 퍼지는 일반 소비자 제품이면 오히려 자금 없는 게 유리함. 첫날부터 흑자라는 상태(영어로 “default alive”)가 마라톤을 가능하게 함
• 단점도 큼. 서버 관리 인력 없음, 야간 장애 받을 사람 없음, 같이 욕할 동료도 없음. 동생 결혼식 사진 촬영 중에 “Base44가 해킹당했다” 전화 받고 화장실에서 노트북 켰던 일화가 대표적
• 매일 아침 “오늘 하고 싶은 일(코드)“과 “오늘 해야 할 일(마케팅)“이 부딪히는 게 진짜 적. 둘 다 잘하기 쉽지 않음

사용자 0명에서 하루 4,000명까지의 단계

• 첫 3명: 마침 실직 상태였던 친구 둘 + 한 명. 매주 같은 테이블에 앉혀서 옆에서 같이 만들어줌
• 다음 7명: 친구한테 부탁. “이 사람이 다른 사람을 데려오는지”가 마케팅 시작 신호. 본인이 안 끌어들였는데 새 가입자가 보이기 시작하면 이제 외부로 뿌려도 됨
• 첫 50명 + 첫 결제: 1차 ProductHunt(15명 획득). “런칭은 회사의 운명을 가르는 것”이 아니라 “다음 30명을 위한 도구”라고 재정의한 게 전환점
• 이륙: 친구 조언으로 LinkedIn에 빌드 과정을 솔직하게 쓰기 시작. 일주일 만에 하루 신규 20명 → 4,000명까지 폭발. 서버가 터져서 새로 배워가며 막음

이런 조언은 따르지 말라는 것

흔한 조언	Maor의 결론	이유
타깃 고객을 좁게 정해라	무시해도 됨	”누가” 쓰는지(직군·회사 크기)보다 “뭘 하려고” 쓰는지가 중요. 다양한 사람이 같은 일(앱 만들기) 하러 옴
일단 최소 기능 제품을 내라	비추	요즘은 소프트웨어가 너무 많아서 사람들 인내심이 짧음. “겨우 돌아가는 것”엔 아예 신뢰를 안 줌
채널 여러 개에 뿌려라	비효율	한 채널에서 효과 보일 때까지 테스트하고, 보이면 거기에 올인. Maor는 LinkedIn
광고로 사용자 확보해라	비효율	부트스트랩은 광고비 못 씀. 입소문 외엔 길이 없음
사용자에게 더 가치를 줘라	효과적	”빌드한 거 SNS에 공유하면 추가 크레딧 줌” 프로그램. 친구가 “쟤네 돈 받고 쓰는 거냐”고 물을 정도로 확산

기술 스택과 “AI한테 시키기 쉬운 코드”라는 발상

복잡한 기술 얘기지만 핵심은 “혼자서 AI한테 시켜서 빠르게 만들려면 코드 구조를 어떻게 짜야 하나”임.

• 인프라는 Render.com 하나로 끝: 서버·배포·관리 다 해주는 클라우드. AWS 위에 더 쉬운 껍질을 씌운 형태. 본인이 서버 관리 전문이 아닌데도 안 터졌다고
• 데이터베이스는 MongoDB: 데이터 형태(컬럼 구조 같은 것)를 자주 바꿔도 잘 견딤. AI가 코드 짜다 보면 데이터 모양이 자주 바뀌어서 이게 잘 맞음
• 백엔드는 Python: 사람들이 “느리지 않냐”고 의심하는데 트래픽 많아도 문제 없었음
• 프론트엔드는 TypeScript 안 씀: 좀 논쟁적인 입장인데, “AI 모델이 그냥 JavaScript에서 코드를 더 잘 쓴다”는 본인 경험. 타입 시스템이 모델한테 부담을 줌
• 앞단·뒷단을 한 폴더에: 보통은 분리하는데, AI한테 한 번에 양쪽 맥락을 줄 수 있게 합쳐 둠
• AI한테 코드를 적게 쓰게 만드는 것이 핵심: 자주 쓰는 부품(로그인, 데이터 저장, 데이터 가져오기)을 미리 다 만들어 두고, AI는 정말 작은 조각만 쓰게 함. 적게 쓰면 버그도 적고 속도도 빠름
• 작업별로 다른 AI 모델 쓰기: 사용자 요청을 분석해서 종류별로 보냄. 디자인이나 첫 앱 만들기는 Claude, 복잡한 알고리즘이나 Claude가 같은 버그를 반복할 땐 Gemini, 자잘한 코드 수정은 빠르고 싼 모델(Flash·o4-mini). Cursor도 안 하는 걸 본인 제품에 직접 구현

”더 좋은 앱”을 포기하고 얻은 활성화

• 초기 Base44는 “할 일 관리 앱 만들어줘”라고 하면, 코드 짜기 전에 먼저 “이런 화면, 이런 흐름으로 만들 건데 맞아요?”라고 확인 단계를 넣었음. 결과물 품질은 더 좋았음
• 그런데 거기서 사용자가 많이 떨어졌음. 일반 소비자는 인내심이 짧아서, 중간 단계가 끼면 “내 말을 알아들었다”는 놀라움이 사라짐
• 결론: “1~3분 안에 첫 결과물 보여주기”가 더 중요함. 디테일은 그 뒤에 추가. 좋은 제품이 곧 좋은 활성화는 아님

1인기업이 거대 자금 경쟁사를 이길 수 있나?

모든 분야는 아님. 입소문으로 퍼지는 소비자 제품이고 본인만의 각이 있다면 가능. Maor는 Lovable·Bolt·Replit·v0 같은 막대한 투자받은 경쟁사들 사이에서도 5월에 한 달 순이익 20만 달러를 냈음. AI 시대엔 팀 크기와 자금이 결정적이지 않고, “AI를 잘 부리는 사람 한 명이 예전 10명 몫을 함”이라는 게 본인 관찰.

Build in public이 누구한테나 통하는 전략인가?

아님. 듣는 사람이 “본인도 뭔가 만드는 사람”일 때만 작동한다고 본인이 명시함. 변호사 대상 제품이면 같은 전략 안 통했을 거라고. 핵심은 “내 콘텐츠를 보는 사람과 내 제품을 살 사람이 같은가”. 그리고 잘난 척 메트릭(우상향 그래프 자랑)보다 “잘된 것·안 된 것·창피한 것”을 솔직히 쓰는 게 핵심.

인수 협상을 잘 하려면 어떻게 해야 하나?

“안 팔려도 괜찮은 상태”를 만드는 것. Base44는 이미 충분히 수익 나고 있어서 협상에서 절박하지 않았음. Wix CEO와 처음엔 그냥 스테이크 먹으며 조언 받는 자리로 시작. “데이트랑 비슷하다, 첫 몇 번 만남에 너무 관심 보이면 진다”는 본인 비유.

1인기업 관점

확인 단계를 지운 결정이 제일 인상적임. “결과물 품질 ↑” vs “첫 놀람 속도 ↑“에서 후자를 택한 건데, 1인 SaaS에서도 똑같이 적용될 듯. usedesktop도 첫 30초 안에 “어 이거 진짜 되네”가 안 오면 그 뒤에 기능이 아무리 좋아도 안 보는 게 느껴짐. 그리고 채널 한 곳에 다 거는 부분, 한국 1인기업가라면 LinkedIn 대신 X나 스레드, 디스코드 커뮤니티 중에 하나만 진짜 깊게 파는 게 맞는 듯. 멀티 채널은 사람 많은 팀이 하는 거지 혼자서 다 하면 어디도 임팩트 안 나오지 않나 싶음.

---

관련: 같은 “AI 시대에 1인이 어떻게 경쟁하는가”의 다른 각도로 토큰 아무리 태우고 에이전트 수십 개 돌려도 제품이 안 팔리는 이유와 AI 시대의 슬롭 vs 크래프트도 같이 보면 좋습니다.