Peter Steinberger: What Happens When 4.7 Million People Let It Cook

URL: https://www.youtube.com/watch?v=whcfSGN6CAU
날짜: 2026-08-13
채널: Y Combinator
발표자: Peter Steinberger
영상 길이: 41분 53초
영상 맥락: 「The OpenClaw Story」 — OpenClaw의 탄생·폭발적 성장·오픈소스 운영 위기와 다음 단계에 관한 강연 및 Q&A

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==한 개발자의 짜증에서 출발한 개인용 에이전트가 어떻게 OpenClaw라는 오픈소스 생태계로 커졌고, 그 과정에서 무엇을 잃고 무엇을 배웠는가?==

• Peter는 2025년 11월, 주방에 가 있는 동안 휴대폰에서 컴퓨터의 코딩 에이전트를 확인하고 싶다는 불편을 해결하려고 WhatsApp 릴레이를 만들었다.
• 친구들의 강한 감정적 반응과 Discord 공개 실험이 제품 시장 적합성(Product-Market Fit)과 바이럴의 신호가 되었지만, 동시에 보안·지원·법률·커뮤니티 운영의 부담을 한꺼번에 가져왔다.
• 프로젝트가 특정 모델과 구독에 과도하게 최적화되면서 의존성이 곧 사업 모델이 된다는 사실을 경험했고, 67,000개 스킬 보안 검증, 약 9,500개 설정 옵션, 주간 다운로드 835,000에서 470만으로의 급등을 겪었다.
• 그가 남기는 세 가지 원칙은 재미를 잃지 말 것, 직감을 듣고 짜증 나는 문제를 고칠 것, 다른 팟캐스트보다 실제로 빠진 것을 만들며 집중할 것이다.

OpenClaw의 이야기는 단순히 “AI 에이전트가 빠르게 성장했다”는 성공담이 아니다. 사용자가 실제로 매일 쓰는 도구를 만든 창업자가, 사용자가 생긴 소프트웨어의 복잡성·보안·의존성·거버넌스를 감당하며 다시 “내가 재미있게 쓰는 것”으로 방향을 되돌린 기록이다. Peter에게 AI 시대의 경쟁력은 거창한 예측보다 미래에 먼저 도착해 자신을 괴롭히는 문제를 직접 고치는 데서 나온다.

1. 여덟 달 만에 네 살이 된 프로젝트

OpenClaw의 여덟 달은 달력의 여덟 달이 아니라 AI 생태계의 몇 년에 해당하는 압축된 시간이었다.

1.1. 발표의 시작: 미래였던 사람과 “모델을 요리하게 두기”

1. 현재의 자신을 놀리는 도입부

   1. Peter는 “6개월 전만 해도 나는 미래였는데, 요즘에는 애니메이션 소녀에게 놀림받았다는 이야기를 듣는다”고 농담한다.
   2. 이런 질문을 거의 매일 받지만 보통은 무시하거나 언론용 답변으로 넘겼고, 이날은 다섯 질문을 40분 동안 실제로 답하겠다고 했다.

2. 관객이 기대한 것과 그가 하려는 이야기

   1. 관객은 루프(loops), 그래프(graphs), Codex를 작동시키는 방법을 기대했을 것이다. 그는 관련 자료가 자신의 Twitter에 무료로 있다고 말한다.
   2. 그 자료는 앞으로 닥칠 롤러코스터를 버티는 데 도움이 될 것이며, 전날 Boris가 말한 “모델을 요리하게 두라(let the model cook)”는 표현을 이어받는다.
   3. Peter는 수만 명이 동시에 모델을 요리하게 두었을 때 실제로 무슨 일이 생기는지 알아낸 사람이라고 자신을 소개한다.

1.2. 출발점은 배고픔과 짜증이었다

1. AI 시간과 인간 시간의 차이

   1. OpenClaw는 인간 시간으로는 겨우 8개월이지만, AI 시간으로는 약 4년처럼 느껴진다고 말한다.
   2. 그의 영감의 원천은 대개 “짜증 나는 상황”이다. 거대한 비전에서 시작했다기보다 반복되는 마찰을 참지 못할 때 무언가를 만든다.

2. 2025년 11월의 비 오는 날

   1. Peter는 여러 에이전트를 동시에 다루고 있었고, 한편으로는 배가 고파 주방으로 음식을 가지러 가고 싶었다.
   2. 휴대폰에서 컴퓨터로 프롬프트를 보내 에이전트가 현재 작업을 어떻게 진행하는지 확인할 좋은 방법이 없었다.
   3. 토큰을 낭비하지 않고 자신이 주방을 터는 동안에도 유용하게 쓰고 싶다는 지극히 개인적인 필요가 문제의 출발점이 되었다.

3. 당시의 모델 환경

   1. 그는 2025년 초의 모델을 회상하며 Opus 계열과 OpenAI의 o3를 언급한다. o3는 매우 인상적이었지만 때로는 느리고 비쌌다.
   2. 에이전트가 일을 제대로 해냈을 때 도파민을 느끼던 시기였지만, 지금은 에이전트가 실패하면 곧바로 모델 탓을 하지 않는다.
   3. 대신 “루프를 잘못 설계했나?”, “작업을 검증할 자료를 충분히 줬나?”, “내 사고에 오류가 있나?”, “애초에 불가능한 일을 요구했나?”라고 자신에게 묻는다.

1.3. WhatsApp 릴레이: 터미널이 아닌 경험

1. 한 시간 만에 만든 원격 인터페이스

   1. 주방에서 돌아왔을 때 코딩 에이전트가 사소한 이유로 멈춰 있었고, Peter는 짜증이 나 새 터미널 세션을 열었다.
   2. 아이디어를 두서없이 말하듯 프롬프트에 넣고 모델이 요리하도록 두었다.
   3. 모델은 WhatsApp 릴레이를 만들었고, 약 한 시간 뒤 Peter는 Mac에서 WhatsApp으로 메시지를 보내고 다시 받을 수 있었다.

2. 기술적으로 새롭지 않아도 마법처럼 느껴진 이유

   1. 터미널에 입력하고 답을 받는 일 자체는 이미 수개월 동안 해오던 일이므로, 기능만 보면 혁명적이지 않았다.
   2. 그러나 결과물은 터미널처럼 느껴지지 않았다. 답변은 간결했고, 때로는 먼저 상태를 확인하는 등 선제적(proactive)이었다.
   3. 모델 선택, 컨텍스트 크기, 세션을 언제 새로 열지 같은 복잡성이 사용자에게서 녹아내렸다.
   4. Peter는 기본 분포에서 가중치를 약간 벗어나도록 프롬프트해 에이전트가 좀 더 친구처럼 느껴지게 만들었다.

3. AGI처럼 느껴진 순간과 무관심

   1. 자신이 만든 것을 사용하며 “이것이 미래다”, “이것이 AGI다”라고 느낀 순간이 많았다고 말한다.
   2. 하지만 당시 Twitter에서 이미 많은 팔로워를 갖고 있었음에도 사람들은 이해하지 못했다. 그는 X라는 이름 대신 계속 Twitter라고 부르겠다는 농담도 덧붙인다.
   3. 매주 사람들에게 이 경험이 얼마나 마법 같은지 설명하려 했지만 계속 실패했다. 반복된 무관심이 다시 그를 짜증나게 했다.

1.4. 친구 실험과 초기 제품 시장 적합성

1. 그룹 채팅에서 확인한 반응

   1. Peter는 친구들과 그룹 채팅을 만들고 WhatsApp 릴레이를 추가해 직접 사용하게 했다.
   2. 누군가는 놀라워했고, 누군가는 무서워하거나 겁을 먹었다. 중요한 것은 반응이 무관심이 아니라 강한 감정이었다는 점이다.

2. 비기술 사용자들의 분노

   1. 특히 비기술 친구들이 제품을 원했지만 Peter가 “아직 당신들을 위한 것은 아니다”라고 말하자 그들은 화를 냈다.
   2. 그는 사람들이 당장 쓰고 싶어 하는데 사용을 막았을 때의 분노야말로 제품 시장 적합성의 강력한 신호라고 본다.

3. 이름과 범위가 바뀌기 시작하다

   1. 세상에 이 경험을 어떻게 설명할지 몇 달 동안 세부를 다듬던 중, 누군가 WhatsApp 릴레이에 Discord 지원을 추가하는 pull request를 보냈다.
   2. “WhatsApp 릴레이”라는 이름에서 무엇을 이해하지 못했느냐고 생각하며 PR을 한동안 방치했지만, 결국 “뭐 어때”라고 받아들였다.
   3. 그 결과 릴레이는 여러 이름을 거쳐 초기 에이전트 프로젝트로 확장되었다. 이때는 메시지 채널조차 하나뿐이었고, 컨텍스트 압축(compaction)도 내장되어 있지 않았다.
   4. Discord 지원에 맞추기 위해 Peter는 임시로 매우 해킹에 가까운 압축 기능을 넣었고, 이후 Mario가 Raspberry Pi에서 더 나은 버전을 만들 수 있는 발판이 되었다.

2. 공개 실험이 바이럴이 되다

OpenClaw는 완성된 제품을 출시해서 퍼진 것이 아니라, 사람들이 지켜보는 가운데 위험한 초기 프로토타입을 함께 만지면서 퍼졌다.

2.1. 새해 전야와 Discord 공개

1. 코딩 에이전트가 대중화되던 시점

   1. 새해 전날 Peter는 집에 일찍 돌아가 프로젝트를 더 해킹했다.
   2. 1월 첫째 주, IT 세계가 코딩 에이전트를 집단적으로 알아가기 시작할 무렵 Discord 방·서버·길드를 만들고 에이전트를 그 안에 넣었다.

2. 사람들이 에이전트와 함께 만들기 시작하다

   1. 사람들은 Discord에 들어와 Peter가 공개적으로 만드는 모습을 지켜봤다.
   2. 에이전트를 해킹해 보거나 말을 걸고, 에이전트의 건방진 답변을 확인하며 무엇을 할 수 있는지 시험했다.
   3. Peter는 사람들이 마침내 이 경험을 “이해한” 순간이라고 회상하며, 그날 밤 계속 깨어 에이전트와 사람들의 상호작용을 지켜봤다.

2.2. 초기 안전장치와 그 한계

1. Peter의 메시지만 위험한 호출을 허용하는 프롬프트

   1. 에이전트의 agents.md에는 Peter가 보낸 프롬프트가 아니면 위험한 도구 호출을 하지 말라는 지시가 있었다.
   2. 약 6개월 전 당시에는 에이전트에 적은 지시가 강제 정책이라기보다 제안에 가까웠다. 따라서 Peter는 작업을 매우 주의 깊게 관찰했고, 언제든 플러그를 뽑을 수 있게 했다.

2. Ctrl-C가 종료가 아니었던 이유

   1. 오전 7시쯤 실험을 마치고 “잘 자”라고 인사한 뒤 Ctrl-C를 누르고 잠자리에 들었다.
   2. 소프트웨어를 복원력 있게 만들기 위해 launchd 데몬으로 실행했기 때문에, Ctrl-C를 눌러도 약 5초 뒤 프로세스가 다시 시작되었다.
   3. Peter가 침실로 걸어가는 동안 에이전트는 세상의 사람들에게 답하기 시작했고, 그는 약 10시간을 잤다.

3. 800개의 메시지와 바이럴의 순간

   1. 아침에 일어나 보니 약 800개의 메시지가 쌓여 있었다. 사람들이 해킹을 시도했지만 실제로 사고가 난 것은 없었다.
   2. 그는 놀라서 에이전트를 끄고 모든 기록을 읽었다. 역설적으로 아무 일도 일어나지 않았다는 사실을 확인한 바로 그 순간 프로젝트가 바이럴이 되었다.

2.3. 갑자기 도착한 세계의 관심

1. 기자와 인프라의 반응

   1. 이메일 수신함은 폭포처럼 쏟아졌고 기자들은 한밤중에 전화를 걸었다.
   2. iPhone의 방해금지 모드에서도 같은 사람이 연속으로 여러 번 전화하면 긴급전화로 간주해 연결하는 기능을 기자들이 활용했다. Peter는 그 기능을 몰랐지만 기자들은 알고 있었다.
   3. Mac Mini가 품절되었고, 영상 시점에도 여전히 품절 상태라고 말했다.
   4. 한 달 동안 받은 팟캐스트 초대 수가 이전 39년 동안 받은 것보다 많았다.

2. 이름이 여러 번 탈피하다

   1. Anthropic이 이름 변경을 요구하는 이메일을 보냈고, 프로젝트는 로브스터 이미지를 내려놓는 등 여러 차례 이름을 바꾸며 탈피했다.
   2. 초기 이름은 여러 변형을 거쳐 Clawdbot이 되었고, 잠깐 언급하지 않는 이름을 거친 뒤 OpenClaw로 정착했다.
   3. Jensen Huang은 이를 인류 역사상 가장 성공적인 오픈소스 프로젝트라고 불렀다.

3. 규모가 현실처럼 느껴지지 않는 수치

   1. 8개월 동안 18,000명 이상이 이슈나 pull request를 열었다.
   2. 이슈와 PR은 합계 111,000건을 넘었다.
   3. 저장소에 커밋한 사람은 거의 3,000명에 이르렀다.
   4. Peter는 수치 계산을 에이전트에게 시켰다고 농담한다. “내가 계산했다”가 아니라 “내 에이전트가 계산했다”는 점이 프로젝트의 성격을 보여준다.

2.4. 숭배와 비난 사이의 창업자

1. 아이디어를 훔쳤다는 비판과 과장된 서사

   1. 어떤 사람들은 이미 자신들이 먼저 만들었다며 Peter가 아이디어를 훔쳤다고 비난했고, Peter가 본 적 없는 프로젝트 링크를 보내기도 했다.
   2. 어떤 사람들은 그를 예수라고 부르고, 다른 사람들은 인류의 적그리스도라고 불렀다.

2. “부고(obituary)”를 모으는 사람

   1. 그는 몇 주마다 새로운 OpenClaw 사망 선언이 나온다고 말하며, 그런 부고를 모으기 시작했다.
   2. 가장 최근의 부고는 강연 전날 나온 것이었다.
   3. 여기서 얻는 교훈은 “바라는 것을 조심하라”는 것이다. 관심을 원했지만 이렇게 많은 관심을 받을 준비는 되어 있지 않았다.

3. 관심이 사람을 무너뜨리는 방식

   1. 관심은 Peter를 거의 부술 뻔했고, 프로젝트 전체를 삭제할 생각에 가까워질 정도였다.
   2. 친구들에게 답하지 않았고 휴대폰을 보는 것조차 싫어졌다. 휴대폰이 끊임없는 스트림으로 변했기 때문이다.
   3. 전화번호와 사적인 정보도 유출되었다. 그는 단지 멋진 것을 만들고 싶었을 뿐인데, 자신이 인류의 적이라는 식의 비난까지 받게 되었다.

3. “팔아버린 것인가?” — 번아웃, 오픈소스, 의존성

Peter의 두 번째 질문은 프로젝트를 팔았는지에 관한 것이지만, 답변의 핵심은 돈보다 자신의 욕망과 오픈소스 방향을 어떻게 지킬 것인가에 있다.

3.1. 과거의 B2B 회사와 은퇴

1. 20대와 30대의 창업

   1. Peter는 20대와 30대 대부분을 B2B 소프트웨어 회사 만드는 데 썼다.
   2. PDF 프레임워크를 “동물처럼” 손으로 직접 작성했고, 회사를 부트스트랩했다.
   3. 약 80명 규모까지 키웠고 경쟁사를 무시한 채 성장해 대부분의 기업이 구매하는 제품이 되었다.
   4. 결국 공동창업자에게 운영을 넘기고 지분을 매각했으며, 심하게 번아웃됐다.

2. 3년간의 은퇴와 자기 발견

   1. 은퇴라는 말은 훌륭하게 들렸고, 약 3년 동안 목적 없이 돌아다니며 파티를 하고 그동안 놓친 삶을 따라잡았다.
   2. 몇 달 동안 컴퓨터를 열지 않고 휴대폰으로 인터넷을 가볍게 확인하며 “일반인(normie)”처럼 지낸 기간도 있었다.
   3. 언젠가 다시 욕망이 돌아올 것이라고 믿었다. 처음에는 그 욕망이 당연히 코딩일 거라고 생각했다.

3. 코딩보다 만들기를 사랑한다는 깨달음

   1. 그는 프로그래밍을 사랑하지만, 프로그래밍은 목적을 위한 수단이었다.
   2. 진짜로 사랑하는 것은 무언가를 만드는 일(building)이라는 사실을 이해하는 데 1년이 걸렸다.
   3. OpenClaw를 통해 8개월 만에 다시 창작의 불꽃을 찾았고, 돈을 달라는 제안과 영수증을 보내는 투자자·기관의 연락이 받은편지함을 채웠다.

3.2. 대형 랩의 제안과 개인 브랜드

1. 팔아야 할지 모르는 상태

   1. 여러 대형 AI 랩이 찾아오면서 Mark, Sam 등과 통화하게 되었지만, Peter는 돈을 받고 싶은지조차 확신하지 못했다.
   2. 모든 일이 비현실적으로 느껴졌고, 그 상황은 강한 임포스터 신드롬을 불러왔다.

2. 복제 가능한 제품과 복제할 수 없는 이름

   1. 그가 강조한 중요한 교훈은 “만들 수 있는 것은 무엇이든 포크되거나 복제될 수 있지만, 자신의 이름은 복제되지 않는다”는 것이다.
   2. 개인 브랜드는 한 제품보다 오래간다. 제품을 시작하기 전에 개인 브랜드와 가시성을 쌓아야 한다.
   3. AI로 구현물이 빨리 복제되는 시대일수록 누가 무엇을 만들었고 왜 믿을 만한지가 중요한 분배 자산이 된다.

3. 영혼을 파는 일과 직감

   1. Peter는 오픈소스 프로젝트를 대형 회사에 넘기는 것이 “자신의 soul.md를 파는 것”과 같다고 농담한다.
   2. 결정을 쉽게 내린 것은 아니지만, 번아웃 이후 배운 것은 자신의 직감을 신뢰하는 일이었다.
   3. 그의 직감은 OpenClaw를 가장 개방적인 방식으로 유지하고 싶다고 말했다. 따라서 이 장면의 답은 단순한 매각 여부가 아니라 “오픈을 선택했다”는 것이다.

3.3. 보안 폭풍과 0.3%라는 실제 수치

1. 오픈소스 프로젝트가 맞닥뜨린 현실

   1. 출시 후 몇 달 동안 OpenClaw는 보안 보고서에 완전히 짓눌렸다.
   2. Peter는 이것이 당시 많은 오픈소스 프로젝트가 겪는 문제의 프로토타입이었다고 본다.
   3. 보안 연구자와 언론의 압박이 컸고, 그는 “아주 강한 압박을 느꼈다”고 말한다.

2. 20% 악성 스킬이라는 보도와 실제 검증

   1. 언론은 OpenClaw 스킬의 20%가 악성이라고 보도했다.
   2. 팀은 직접 논문을 작성해 67,000개 스킬을 스캔했고, 실제 수치는 약 0.3%에 가까웠다.
   3. 그러나 정정 기사는 공포를 퍼뜨린 기사만큼 멀리 도달하지 않았다. “정정은 공포만큼 빠르게 퍼지지 않는다”는 미디어 현실을 체감한 셈이다.

3. 문서를 읽지 않는 사용자를 위한 방어층

   1. 설치 화면에는 큰 보안 경고가 있었지만, Peter는 많은 사용자가 문서를 읽지 않을 것을 알고 있었다.
   2. 그래서 샌드박싱(sandboxing), 허용 목록(allowlist), 권한이 내장된 웹 프로토콜을 추가했다.
   3. TypeScript에 부족한 파일 시스템 원시 기능을 보완하기 위해 Python을 외부 호출하기도 했다.
   4. 에이전트가 작업공간 밖으로 나가지 않도록 하고, 심볼릭 링크를 따라가지 않게 했으며, 설정 파일을 원자적으로 쓰도록 만들었다.

4. 보안 강화의 사용자 비용

   1. 사용자는 추상적인 “보안”이라는 말에는 동의했지만, 실제로는 업데이트가 의존하던 기능을 깨뜨리고 속도를 늦추며 업데이트를 어렵게 만드는 것을 싫어했다.
   2. 보안 경계를 명확히 하지 않은 채 모든 가능성을 막으려 하면 보안 작업이 곧 제품 경험 악화로 이어진다.

3.4. 유지보수와 설정 폭발

1. 분산된 시간과 책임

   1. Peter의 시간은 오픈소스 개발, 언론 대응, 변호사와의 통화, 미국 501(c)(3) 비영리단체 설립으로 분산됐다.
   2. 다른 제품·프로젝트 세계의 요구도 있었고, OpenAI 쪽의 일도 흥미롭고 demanding했다.
   3. 그는 도움을 받기 시작했지만, 커뮤니티의 뛰어난 메인테이너들이 각자 기능을 추가하는 상황이 빠르게 커졌다.

2. 무료로 기여하는 사람들에게 “안 된다”고 말하기 어려운 문제

   1. 메인테이너들은 무료로 일하고 있었으므로 Peter는 자신이 그들에게 무엇을 하라고 말할 자격이 있는지 망설였다.
   2. 그 결과 방향을 가진 제품보다 각자의 기능이 더해지는 프로젝트가 되기 쉬웠고, Peter 자신의 주의력도 사방으로 흩어졌다.

3. 기능은 프롬프트 하나지만 비용은 누적된다

   1. 새 기능을 추가하는 일은 프롬프트 하나로 빠르게 할 수 있어 재미있다.
   2. 하지만 사용자의 설정을 깨뜨리지 않기 위해 거의 모든 기능에 설정 옵션을 추가했고, 최고점에서는 설정 옵션이 약 9,500개에 이르렀다.
   3. 모든 조합을 테스트하는 것은 불가능하다. 테스트를 아무리 많이 작성해도 때때로 무언가를 깨뜨릴 수밖에 없다.
   4. 사용자가 있는 소프트웨어는 사용자가 없는 소프트웨어보다 진화시키기가 무한히 어렵다. 코드 작성보다 호환성·마이그레이션·지원이 핵심 비용이 된다.

3.5. 경쟁사보다 더 아팠던 것은 모델 의존성이었다

1. VC 자금과 단순한 이야기

   1. 다른 회사들은 VC 자금으로 앞서 나갔다.
   2. Peter가 “애니메이션 소녀 회사”라고 부르는 경쟁사는 공격적 마케팅을 특히 잘했다.
   3. Twitter의 거의 모든 대화에 자신을 끼워 넣었고, 단순한 이야기와 기존 클로를 옮기는 한 줄짜리 마이그레이션을 제시했다.

2. Anthropic 모델에 대한 과도한 최적화

   1. 이름 변경 요구 자체는 스트레스였지만, 상대가 친절하게 대응했기 때문에 Peter는 이해할 수 있었다.
   2. 진짜 치명타는 OpenClaw의 하네스가 특정 Anthropic 모델에 너무 최적화되어 있었다는 사실이었다.
   3. Peter는 Codex와 GPT로 OpenClaw를 만들었지만, 오랫동안 하네스는 Opus에서 가장 잘 작동하도록 조정되어 있었다.
   4. Anthropic이 약 24시간의 통지만 주고 모든 사용자의 구독을 비활성화하겠다고 했을 때, 방향을 바꿀 시간이 거의 없었다.

3. 오픈 웨이트 모델의 미성숙

   1. OpenClaw는 오픈 웨이트 모델도 지원했고 상당한 작업을 해왔지만 당시에는 품질이 충분히 좋지 않았다.
   2. 초기 오픈 모델은 특히 “캐릭터”가 부족했다. 답은 할 수 있어도 Peter가 만들고 싶었던 친근하고 주도적인 경험을 만들기 어려웠다.
   3. 그가 적어두라고 한 문장은 **“의존성의 비즈니스 모델이 곧 당신의 비즈니스 모델이다”**이다.
   4. 이후 모델과 오픈 웨이트 생태계는 좋아졌고 이 문제는 해결되었지만, 그 사이 사용자는 이미 다른 곳으로 이동했다.

4. 하네스 엔지니어링의 학습

   1. 이 사건을 통해 Peter는 모델 자체보다 모델을 둘러싼 하네스(harness)를 설계하는 일이 얼마나 중요한지 배웠다.
   2. 제품의 핵심 기능이 외부 모델의 정책·가격·구독에 묶이면, 모델 공급자의 결정이 곧 제품의 생존 문제로 바뀐다.

3.6. 다운로드 그래프와 통제할 수 없는 날씨

1. 동시에 참인 두 수치

   1. OpenClaw의 주간 다운로드는 5월 약 835,000건까지 내려갔다.
   2. 6월 “죽었다”는 선언이 나온 뒤 오히려 역대 최고인 470만 건까지 올라갔다.
   3. 침체와 최고점은 서로 모순되지 않는다. 둘 다 실제로 일어났다.

2. 하이프는 날씨다

   1. Peter는 하이프를 날씨에 비유한다. 다가오는 것을 볼 수는 있지만 통제할 수는 없다.
   2. 자신의 경우 하이프는 폭풍이었다. 창업자는 성장 곡선을 통제한다고 착각하기 쉽지만, 관심의 방향과 속도는 제품팀의 의지와 별개로 움직인다.

4. 다시 재미를 찾기까지

성공의 정점에서 Peter는 자신이 만든 제품을 더 이상 쓰지 않는 상태가 되었다. 회복은 기능을 더하는 것이 아니라 다시 자신이 쓰고 싶은 것을 만드는 데서 시작됐다.

4.1. 2월: 재미가 책임으로 변한 시점

1. 두 개의 직업, 하나의 소명

   1. 2월쯤 프로젝트가 더는 재미있지 않게 되었다.
   2. 다른 회사를 만들고 싶지 않았던 사람이 직업 하나와 소명 하나, 사실상 두 개의 일을 가진 상태가 되었다.

2. 자기 제품을 멈춰 쓰다

   1. 최악의 변화는 Peter가 자신의 제품을 사용하지 않게 된 것이었다.
   2. 매일 자신이 쓰는 제품을 만드는 대신 모든 사람을 위한 무언가를 만들기 시작했다.
   3. 제품은 일상에서 쓰는 도구가 아니라 자신이 보고 느끼는 “업무”가 되었다.

3. 사용자와 운영자의 요구가 충돌하다

   1. 어떤 사용자는 식료품을 사주는 에이전트를 갖고 있었고, 다른 사용자는 Peter의 봇을 사회공학적으로 조종하려 했다.
   2. 커뮤니티가 기능을 추가하고 조직 업무가 늘면서 Peter는 버그 수정, 보안 이슈 처리, 지원, 기반 구축을 모두 맡는 사람이 되었다.
   3. OpenClaw가 OpenAI 소유라는 소문 때문에 OpenAI의 도움을 지나치게 받지 않으려 했지만, 토큰 지원은 많이 사용했다고 솔직히 인정한다.

4.2. 위임과 지원을 배운 과정

1. 뒤늦게 깨달은 선택지

   1. 돌이켜 보면 더 일찍 도움을 요청하고 자신의 책임을 다른 사람에게 옮겼어야 했다.
   2. 그러나 모든 일에 깊이 들어가 있어 전략적으로 생각할 시간을 만들지 못했다.

2. 조직 기반이 맞춰지다

   1. 비자 문제를 해결했고, 결국 비영리단체를 만들었다.
   2. 좋은 회사들이 기부자가 되었고 오픈소스를 믿는 사람들이 함께 일하기 시작했다.

3. NVIDIA의 이른 지원

   1. NVIDIA는 초기에 특별한 지원을 해준 회사로 언급된다.
   2. 그들은 Peter에게 필요한 것을 물었고, 이후 사람들을 보내 보안 업무의 상당 부분을 인수했다.
   3. 중요한 점은 단순한 토큰·홍보 지원이 아니라 실제 운영 부담을 덜어주는 능력과 인력을 제공했다는 것이다.

4.3. 재미가 돌아오자 속도도 돌아왔다

1. 5월의 전환점

   1. 5월, 자신의 생일 무렵부터 상황이 다시 좋아지고 있다는 느낌이 들었다.
   2. 만들기를 즐기는 기쁨이 돌아왔고, 제품을 직접 사용하며 개선할 수 있게 됐다.

2. “OpenClaw 킬러”와 본질의 누락

   1. 언론은 격주로 새로운 “OpenClaw killer”를 만들어냈고, Peter가 세어본 것만 약 20개였다.
   2. 실제로 OpenCloud Killer라는 프로젝트도 있었는데, OpenClaw를 지우는 언인스톨러였다. OpenClaw에는 이미 언인스톨러가 있어 불필요하지만, 그런 이름 자체가 하이프의 기묘함을 보여준다.
   3. 킬러 서사는 OpenClaw의 실제 본질인 오픈소스와 사람을 AI에 가깝게 만드는 일을 거의 다루지 않았다.

3. 재미와 속도의 관계

   1. 이제 Peter는 자신이 소프트웨어를 마음대로 바꾸지 못할 때 짜증 난다. 에이전트에게 프롬프트를 보내 바로 바꿀 수 있어야 한다고 느낀다.
   2. “재미있게 하고 있는 사람과 경쟁하기는 어렵다.” 재미는 곧 속도(velocity)다.
   3. 자신이 만드는 것을 즐긴 주에는 제품이 눈에 보이게 좋아졌고, 즐기지 못한 주에는 설정 옵션만 늘어났다.

5. 다음 단계: 에이전트를 사람의 삶에 더 가깝게

Peter가 말하는 다음 단계는 또 다른 기능 목록보다 AI를 낯설고 무서운 기술에서 일상적인 동료로 바꾸는 오픈소스 인프라다.

5.1. OpenClaw의 사명과 생태계

1. 기반이 안정된 것에 대한 만족

   1. Peter는 현재 기반(foundation)이 안정된 상태에 만족한다고 말한다.
   2. 사명은 사람을 AI에 더 가깝게 만드는 것이다. AI는 너무 빠르게 변해 많은 사람에게 무섭고 모호하게 느껴진다.

2. 무섭고 모호한 것을 재미있고 이상한 것으로

   1. OpenClaw가 이룬 가장 자랑스러운 일은 AI를 “정체를 알 수 없고 무서운 것”에서 재미있고 이상한 것으로 옮겨놓은 점이다.
   2. 로브스터 같은 유머와 기묘함은 기술에 대한 심리적 거리를 줄이고 사람들이 직접 만져보게 만든다.

3. 생태계, 행사, 교육

   1. 앞으로도 좋은 오픈소스 소프트웨어 생태계를 만들 것이다.
   2. 사람들을 모으는 행사와 교육을 함께 추진할 계획이다.
   3. 현재 급여를 받는 사람은 10명이며, CEO를 포함해 몇 개의 역할을 추가 채용하고 있다.

5.2. “claw”가 명사가 된 세계

1. 언어의 변화

   1. Peter는 자신이 “claw”를 명사로 만들어버린 것 같다고 말한다.
   2. Kapati가 open을 붙인 표현을 내놓고, Satya Nadella가 Microsoft 키노트에서 “엔터프라이즈급 claws”를 언급했다.

2. 33,000개의 저장소

   1. claw라는 이름을 포함한 저장소가 33,000개에 이른다.
   2. 이런 현상을 보면 시뮬레이션 속에 있다면 아주 이상한 시뮬레이션일 것이라고 농담한다. 그래도 자신은 이 미래의 일부가 마음에 든다.

5.3. 항상 켜져 있고 항상 동기화되는 에이전트

1. 아직 해결되지 않은 핵심

   1. OpenClaw에는 아직 항상 켜져 있고(always on), 늘 동기화되는(always syncing) 에이전트가 없다.
   2. AI 모델과 기술은 주변에서 만드는 소프트웨어보다 빠르게 발전하고 있으며, 그 간극이 모두에게 기회다.

2. 세션과 컴팩션을 의식하지 않는 워크플로

   1. 초기부터 Peter가 원한 것은 사용자가 세션이나 컴팩션을 신경 쓰지 않는 경험이었다.
   2. 모델과 관련 기술이 마침내 그 비전을 현실로 만들 수준에 접근하고 있다.

3. 텍스트를 넘어 음성·멀티모달로

   1. 인터페이스는 텍스트 전용에서 음성과 멀티모달로 이동하고 있다.
   2. 강연 전날에는 OpenClaw가 FaceTime으로 사용자에게 전화를 걸 수 있는 해킹을 성공시켰다.

5.4. 모든 랩의 에이전트에 대한 오픈소스 대안

1. OpenClaw가 존재하는 이유

   1. 모든 AI 랩이 에이전트를 팔겠지만, OpenClaw는 그에 대한 대안이다.
   2. 오픈소스는 어디에서나 실행되고 어떤 모델과도 작동해야 하며, 로컬 모델을 사용하면 데이터가 기기를 떠나지 않는다.
   3. 핵심 문장은 “당신의 에이전트, 당신의 기계, 당신의 삶”이다.
   4. Peter는 이것이 자신의 C thesis가 아니라 Gary의 문구라고 농담한다. 자신들은 그 아이디어를 먼저 구현했을 뿐이다.

2. OpenClaw로 OpenClaw를 만드는 팀 서버

   1. 팀 서버에서 모두가 서로의 세션을 볼 수 있고, 각자의 작업을 아는 Claw를 만들고 있다.
   2. 이 Claw는 작업을 인수하거나 전체 작업의 오케스트레이션을 맡을 수도 있다.
   3. 그 결과 사람들은 에이전트가 계속 돌아가도록 터미널과 노트북을 열어둔 채 돌아다니는 이상한 과도기를 벗어나게 된다.

5.5. 발표자가 남긴 세 가지 원칙

1. 재미를 멈추지 말 것

   1. 재미는 최고의 동력이며, 최고의 아이디어를 얻는 원천이다.
   2. 자신이 즐기지 않는 일을 억지로 확장하면 기능과 설정만 쌓이고 속도는 떨어진다.

2. 직감을 듣고 짜증을 고칠 것

   1. 무언가가 계속 짜증 난다면 단순한 불평이 아니라 다음 큰 제품의 신호일 수 있다.
   2. Peter의 OpenClaw도 배고픈 채 주방에 가야 했던 개인적 짜증에서 시작했다.

3. 집중하고 실제로 빠진 것을 만들 것

   1. 또 다른 팟캐스트 출연이 승리를 가져다주지 않는다.
   2. 미래에 살고, 아직 없는 것을 만들고, 부고 기사가 나와도 계속 shipping하라. 계속 출시하면 사람들은 창업자를 이해하지 못해 혼란스러워한다는 농담으로 마무리한다.

6. Q&A: 에이전트 시대의 실제 운영법

강연 뒤 Q&A에서 Peter는 “에이전트 → 루프 → 그래프”라는 유행어보다, 실제로 일을 위임하고 검증하는 방법을 설명한다.

6.1. 요즘은 세션을 어떻게 쓰는가

1. 세션은 주제 단위가 되었다

   1. 초창기에는 세션을 정리하고 지시가 일관적인지 신경 써야 했다.
   2. 요즘 Peter의 세션은 각각 하나의 주제(topic)처럼 쓰인다.
   3. 세션을 지우는 것이 오히려 불리할 때도 있다. 그 안에 에이전트에게 도움이 되는 정보가 많이 남아 있기 때문이다.

2. 더 많은 선제적 일을 맡기다

   1. 가장 큰 변화는 에이전트가 자신을 위해 더 많은 일을 먼저 하게 만든 것이다.
   2. 관심을 다른 곳으로 옮길 때 이슈 목록을 읽고 싶지 않다. 완전히 검토하고 테스트한 PR을 보고 싶다.
   3. 그 기능이 마음에 들든 들지 않든, 주의력을 쪼개지 않고 결과물을 판단하려 한다.

3. 아이디어를 사람에게 바로 가져오지 않는 방식

   1. 직장에서 누군가 기능 아이디어만 들고 오면 Peter는 화가 난다고 말한다.
   2. 먼저 에이전트와 아이디어를 논의하고, 구현하고, 스크린샷을 만들고, 직접 플레이해봐야 한다.
   3. 대부분의 아이디어는 그 과정에서 왜 좋지 않은지 드러나므로, Peter에게 오기 전에 걸러진다. 좋은 아이디어만 즉시 반복 개선할 수 있다.

6.2. 그래프 다음에 오는 것: 자동화의 이름만 바뀌었을 뿐

1. 루프·그래프·워크플로는 같은 계보다

   1. 엔지니어는 직업이 생긴 이래 삶을 편하게 하려고 자동화를 만들어왔다.
   2. 이를 루프라 부르든 그래프라 부르든 워크플로라 부르든 본질은 비슷하다.

2. 가장 단순한 그래프의 정의

   1. 어떤 트리거 또는 입력을 받는다.
   2. 입력에 대해 일을 수행하고, 중간에 의사결정이 들어갈 수 있다.
   3. 그 구조가 바로 그래프다. 신비한 새 개념이라기보다 오랫동안 이어온 자동화 이야기를 더 나은 방식으로 설명하는 이름이다.

6.3. 빠르게 만들면서 신뢰성과 확장성을 지키는 법

1. Peter가 한동안 실패했던 부분

   1. 그는 한동안 집중하지 못했고, 당시 모델은 테스트를 잘하지 못했다.
   2. 그래서 빠르게 만든 코드가 안정적으로 확장되는지 확인하는 부분을 제대로 다루지 못했다.

2. 현재 모델이 제공하는 조합

   1. 이제 모델은 더 강해졌고, 단순히 기억하는 세션을 넘어 오케스트레이션을 학습했다.
   2. 모델은 서브에이전트를 언제 어떻게 사용하는지 더 잘 이해한다.
   3. 컴퓨터 사용(computer use)과 브라우저 사용(browser use)까지 합쳐지면 꽤 완전한 QA 환경이 된다.

3. 12개 서브에이전트로 프로젝트를 스트레스 테스트한 사례

   1. Peter는 전날 Codex 세션을 띄우고 12개의 서브에이전트를 사용했다.
   2. 각 에이전트가 프로젝트를 이해하고 기능으로 분해했다.
   3. 기능별로 스트레스 테스트와 코드 리뷰를 수행했으며, 한 세션의 결과가 다른 세션에게 어디에 테스트를 집중할지 알려주게 했다.
   4. 아직 모든 것을 자동화할 단계는 아니다. 사용자가 실제로 어떻게 느끼는지 확인하려면 수동 클릭스루가 필요하다.
   5. 그러나 전형적인 버그 상당수는 이제 프롬프트만으로도 상당히 멀리까지 검증할 수 있다.

6.4. 속도를 위해 내린 결정: 코드를 모두 읽지 않는 코드 리뷰

1. 코드 리뷰는 위험 관리다

   1. Peter는 초기부터 모든 코드를 직접 읽지 않기로 했다.
   2. 코드 리뷰는 코드의 미학을 평가하는 일이 아니라 위험을 관리하는 일로 본다.

2. 상황별 검토 깊이

   1. 무서운 시스템을 건드릴 때는 코드를 더 가까이 읽고 확인한다.
   2. UI를 만들 때는 화면이 올바르게 보이면 내부 구현을 일일이 읽을 필요가 없다고 생각한다.
   3. 작은 드래그 동작 변경이 원래 몇 분 걸릴 일인데 세 시간이 걸렸다면 무언가 잘못된 신호이므로 면밀히 검토한다.
   4. 그 밖의 경우에는 변경 규모, 예상 소요 시간, 결과를 관찰하며 직감을 신뢰한다.

3. 오픈소스와 회사 소프트웨어의 위험 차이

   1. 혼자 오픈소스를 만들 때의 위험 관리와 OpenAI에서 소프트웨어를 만들 때의 위험 관리는 다르다.
   2. OpenAI 쪽에서는 여전히 모든 코드를 읽지만, 개인 프로젝트에서는 결과·변경 범위·실패 비용을 기준으로 검토 강도를 조절한다.

6.5. 첫 10명의 실제 사용자를 얻는 방법

1. 사용자 1번은 자기 자신이어야 한다

   1. Peter의 첫 번째 규칙은 “사용자 1번은 당신이어야 한다”이다.
   2. 자신이 만들고 있는 것에 흥분하지 못하면 다른 사람에게도 의미가 없을 가능성이 크다.

2. 사용자 2번부터 20번까지는 친구

   1. 그가 실제로 얻은 2~20번 사용자는 친구들이었다.
   2. 제품을 테스트해줄 사람이 주변에 있어야 하고, 창업자가 직접 쓰는 상태에서 친구에게 사용 경험을 확장해야 한다.

3. 오늘날 가장 비싼 자원은 눈길이다

   1. AI로 무언가를 만드는 비용이 급격히 낮아졌기 때문에, 관심(eyeballs)을 얻는 일이 가장 비싼 통화가 되었다.
   2. 작동하는 프로토타입을 만드는 것보다 사람들이 발견하고 신뢰하고 계속 쓰게 하는 것이 어렵다.

6.6. 짜증 나는 문제와 원하는 기능 사이의 균형

1. 두 가지가 자주 겹친다

   1. Peter는 원하는 기능이 없어서 짜증 나는 경우가 많으므로, 개인적 불편과 다른 사람이 원하는 기능이 자연스럽게 겹칠 때가 많다고 말한다.

2. 버그만 고치면 창작 의욕이 사라진다

   1. 소프트웨어에는 특히 기능이 많아질수록 이상한 엣지 케이스가 계속 생긴다.
   2. 모든 시간을 문제 해결에만 쓰면 몇 달은 버틸 수 있지만 결국 흥미를 잃는다.
   3. 반대로 새 기능만 만들면 기반이 무너진다. 따라서 버그·엣지 케이스 해결과 새로 만들기의 건강한 혼합이 필요하다.

6.7. 다시 한다면 보안 연구자 대응을 다르게 하겠다

1. 관심을 끌기 위한 보고서의 압박

   1. Peter는 보안 연구자들에게 덜 스트레스를 받았어야 한다고 말한다.
   2. 일부 연구자는 보고서를 보내고 이메일을 하고 전화를 하는 등 가능한 모든 방식으로 관심을 끌었지만, 실제 제품을 돕기 위한 행동은 아닌 경우가 많았다.
   3. 보고서 상당수는 연구자가 직접 테스트하지 않고 자신의 에이전트가 생성한 결과를 보낸 것이었다.

2. 보안 보장 범위를 먼저 정의했어야 한다

   1. 어떤 부분을 보장하고 어떤 부분은 자신의 보안 경계 밖이라 고치지 않을 것인지 더 강하게 설명했어야 한다.
   2. Peter는 이 세계에 처음 노출되었고 대응 방법을 몰랐기 때문에 몇 달과 흰머리를 대가로 배웠다.

6.8. 현재 에이전트 인프라의 가장 큰 병목

1. 신뢰성·도구·메모리·컴퓨트 관리

   1. Peter가 꼽은 병목은 reliability, tooling, memory, compute 관리가 서로 얽힌 문제다.
   2. 로컬에서 테스트 하나만 실행해도 TSGO가 16개 스레드를 사용해 컴퓨터를 병목으로 만들 수 있다.
   3. 세션 10개가 동시에 실행되면 그중 두 개는 타임아웃되어 다시 돌려야 할 가능성이 높다.

2. 웹과 macOS의 차이

   1. 웹 작업은 클라우드 세션을 만들기 쉽지만 macOS가 필요한 순간 도구의 99%가 실패한다.
   2. 자신의 컴퓨터에 있는 다른 프로그램·파일·환경이 필요한 작업도 마찬가지다.
   3. 작업을 한 환경에서 다른 환경으로 문제없이 옮기는 시스템이 아직 충분히 만들어지지 않았다.

3. 에이전트 컴퓨터 fleet 운영

   1. 컴퓨터 여러 대를 신뢰성 있게 운용하는 방법도 부족하다.
   2. Peter는 지금도 여러 시스템에 화면 공유로 접속해 부하를 분산하지만, 이런 방식은 장기적으로 해서는 안 되는 임시 해결책이라고 본다.

6.9. 오픈소스 프로젝트를 한 방향으로 유지하는 법

1. “아니오”를 충분히 말하지 못했다

   1. Peter는 인기 있는 PR이 프로젝트를 옆길로 끌고 가는 것을 막기 위해 더 자주 거절했어야 한다고 인정한다.
   2. 오픈소스에서는 기여자의 열정을 존중하는 것과 프로젝트 방향을 지키는 것이 계속 충돌한다.

2. vision.md를 헌법처럼 활용하기

   1. 새 오픈소스 프로젝트를 시작할 때 vision.md 파일을 작성해 현재 무엇이고 어디로 가는지 설명한다.
   2. 그 비전은 완벽한 과학이 아니고 틀릴 수 있지만, 기능을 받을지 말지 판단하는 기준으로 더 잘 따라야 한다.

3. 기능 하나의 숨겨진 비용

   1. “멋져 보이는 기능 하나”를 추가하고 싶은 유혹은 강하다.
   2. 그러나 그 기능을 병합하는 순간, 작성자가 완전히 이해하지 못할 수 있고 Peter도 완전히 이해하지 못하는 코드 더미를 프로젝트가 책임져야 한다.
   3. 기능을 받는 결정은 코드뿐 아니라 미래의 버그·지원·호환성까지 떠안는 결정이다.

6.10. 언제 항상 실행되는 능동형 에이전트가 가능한가

1. 기술보다 토큰 문제

   1. 항상 켜져 있고 능동적으로 일하는 에이전트는 기술적으로 오늘도 만들 수 있다.
   2. 하지만 현재 구독으로는 토큰을 너무 많이 소모해 멀리 가지 못하고, 모든 사용자가 그 비용을 감당할 수 있는 것도 아니다.

2. 빈 토큰을 태우지 않는 설계

   1. 핵심은 단순히 heartbeat를 자주 보내는 것이 아니라 유용한 변화가 있을 때만 일하는 시스템을 설계하는 것이다.
   2. 초기 heartbeat 시스템은 정적이고 충분히 능동적이지 못했다.

3. KV 캐시가 지워진 뒤의 비용

   1. 큰 세션을 유지한 상태에서 한 시간 뒤 모든 것을 확인하라고 heartbeat를 호출하면, KV 캐시가 지워진 뒤 600,000 토큰을 서버로 다시 보내야 할 수 있다.
   2. 그 결과 유용하지 않은 작업에 터무니없이 많은 돈을 지불하게 된다.
   3. 컨텍스트를 요약·분할·재사용하고 필요한 변화만 감지하는 최적화가 필요하지만, 구현은 매우 어렵다.

6.11. Peter의 개인적인 에이전트 구성

1. 항상 켜진 Studio Mac

   1. 주로 MacBook을 사용하지만, Jump Desktop으로 자신의 Studio에 있는 Mac에 화면 공유로 접속한다.
   2. Studio의 컴퓨터는 항상 켜져 있어 원하는 작업을 빠르게 실행하고 MacBook 배터리를 소모하지 않는다.
   3. 노트북을 닫아도 작업은 계속된다.

2. 원격 컴퓨터와 에이전트의 마우스

   1. 때때로 다른 원격 기계에도 VNC로 접속한다.
   2. Mac 소프트웨어를 많이 만들기 때문에 에이전트가 화면을 직접 인수해 클릭하는 방식이 유용하다.
   3. 에이전트에게 별도의 컴퓨터를 주면 사용자의 마우스 커서와 싸우지 않아도 된다. 한 컴퓨터에서 같이 작업하면 사람이 커서를 움직이려는 순간 에이전트와 충돌한다.

6.12. 다음 스타트업을 시작한다면

1. 스스로 쓰고 싶은 것을 만들기

   1. 가장 중요한 원칙은 자신이 실제로 사용하고 싶은 것을 만드는 것이다.
   2. 그렇지 않으면 제품은 충분히 좋아지기 어렵다.

2. 기술보다 가시성

   1. 개인 브랜드와 가시성을 미리 쌓아야 한다.
   2. 지금은 소음이 너무 많아 가장 어려운 문제는 기술도 소프트웨어도 사람도 아니라 사람들의 눈길을 얻는 일이다.

3. 어렵고 지루한 문제를 고르기

   1. 다시 시작한다면 “hard and boring”, 즉 어렵지만 지루한 범주의 문제를 고를 수도 있다고 말한다.
   2. 그런 시장에서는 문제를 해결해준 사람을 고맙게 여길 사용자를 찾기가 오히려 쉽다.
   3. 재미있고 어려운 제품은 이제 누구나 프롬프트로 만들어낼 수 있어, 사람들이 알아차리게 만들기가 훨씬 더 어렵다.

6.13. 누군가 만들어주길 바라는 제품

1. Linux 테스트 박스

   1. Linux용 테스트 박스는 비교적 쉽게 구할 수 있다.

2. Mac 개발 환경의 공백

   1. 제대로 작동하는 Mac용 환경을 구하는 것은 터무니없이 어렵다.
   2. Windows 쪽에서 사용해본 서비스들도 상당히 불편했다.
   3. 빠르고 저렴하며 안정적으로 이런 환경을 제공하는 사업자를 아직 찾지 못했다.

3. 기회이지만 어려운 사업

   1. 개발자 도구는 본질적으로 어렵기 때문에 좋은 비즈니스인지 확신할 수는 없다.
   2. 그래도 에이전트·CI·원격 macOS 작업을 위해 빠르고 저렴한 테스트 인프라는 그가 실제로 원하는 제품이다.

주요 발언 모음

“8개월의 인간 시간일 수 있지만, AI 시간으로는 4년 정도다.”

“내 영감의 원천은 대개 짜증 나는 상황이다.”

“의존성의 비즈니스 모델이 곧 당신의 비즈니스 모델이다.”

“만들 수 있는 것은 무엇이든 포크되거나 복제될 수 있지만, 당신의 이름은 복제될 수 없다.”

“재미있게 하고 있는 사람과 경쟁하기는 어렵다. 재미는 속도다.”

“사용자 1번은 당신이어야 한다.”

“다른 팟캐스트가 당신을 승리하게 만들지는 않는다. 미래에 살고, 빠진 것을 만들어라.”

“부고 기사를 쓸 때도 계속 출시하라. 그러면 사람들이 당신을 이해하지 못해 혼란스러워한다.”

핵심 데이터 & 수치

• 프로젝트 경과: 인간 시간으로 8개월, Peter의 표현으로 AI 시간 약 4년.
• 초기 프로토타입: WhatsApp 릴레이를 약 1시간 만에 구축.
• 바이럴 직후: 하룻밤 사이 약 800개 메시지 수신.
• 커뮤니티 참여: 8개월 동안 이슈·PR를 연 사람 18,000명 이상.
• 누적 활동: 이슈·pull request 합계 111,000건 이상.
• 커밋 기여자: 약 3,000명.
• 보안 스캔: 스킬 67,000개 검사.
• 악성 스킬 비율: 언론 보도 20% 대 팀 분석 약 0.3%.
• 설정 복잡도: 최고점에서 약 9,500개 설정 옵션.
• 다운로드 저점: 5월 주간 약 835,000건.
• 다운로드 고점: 6월 “사망” 선언 이후 주간 470만 건.
• 조직 규모: 급여를 받는 사람 10명, CEO 포함 추가 채용 진행.
• 생태계: claw 명칭을 포함한 저장소 약 33,000개.
• QA 사례: Codex 세션 하나에서 서브에이전트 12개를 활용해 프로젝트 분해·스트레스 테스트·코드 리뷰 수행.
• 컴퓨트 병목 사례: 로컬 테스트 하나가 TSGO 16개 스레드를 사용하며, 10개 세션 동시 실행 시 일부 타임아웃 발생.
• Heartbeat 비용 사례: KV 캐시가 사라진 뒤 큰 세션을 다시 보내면 약 600,000 토큰이 소모될 수 있음.

결론 및 시사점

1. 불편을 제품 신호로 해석하라: “주방에 가 있는 동안 에이전트를 확인할 수 없다”는 사소한 짜증이 WhatsApp 릴레이와 OpenClaw의 출발점이 되었다.
2. 사용자에게 강한 감정을 일으키는지 보라: 친구들이 놀라거나 무서워하거나 아직 쓸 수 없다는 말에 화를 냈다면, 무관심보다 제품 시장 적합성에 가까운 신호다.
3. 사용자 1번은 창업자여야 한다: 자신이 매일 쓰지 않는 제품은 빠르게 만들 수 있어도 지속적으로 개선하기 어렵다.
4. 개인 브랜드는 복제 방지 자산이다: 기능과 코드는 복제되지만, 신뢰·이름·가시성은 제품보다 오래 남는다.
5. 의존성을 곧 사업 모델로 관리하라: 특정 모델의 구독과 정책에 최적화하면 공급자의 24시간 통보가 제품의 생존을 흔든다.
6. 보안은 사용자 비용과 함께 설계하라: 샌드박스·허용 목록·권한 모델이 필요하지만, 업데이트를 깨뜨리고 느리게 만들면 사용자는 추상적인 안전보다 불편을 먼저 느낀다.
7. 사용자가 생긴 뒤의 기능은 부채다: 새 기능은 프롬프트 하나로 추가할 수 있지만, 설정 옵션·호환성·테스트·지원이 장기 비용으로 누적된다.
8. 오픈소스에는 비전과 거절이 필요하다: vision.md를 작성하고, 기여자가 무료로 일한다는 이유로 방향과 맞지 않는 PR을 모두 병합하지 말아야 한다.
9. 재미는 운영 지표다: Peter의 경험에서 즐겁게 만든 주에는 제품이 좋아졌고, 재미가 사라진 주에는 설정과 운영 부담만 늘었다.
10. 에이전트에게 결과물까지 맡겨라: 이슈를 읽는 데 주의를 쪼개기보다 에이전트가 구현·스크린샷·테스트·리뷰를 끝낸 PR을 가져오게 해야 한다.
11. 루프·그래프·워크플로의 본질은 자동화다: 입력과 트리거를 받고 판단을 거쳐 일을 수행하는 구조를 유행어보다 실제 문제 해결 관점에서 설계해야 한다.
12. 자동 QA는 강력하지만 체감 테스트를 대체하지 못한다: 서브에이전트 여러 개로 코드 리뷰와 스트레스 테스트를 수행할 수 있어도, 최종 사용자의 느낌은 수동 클릭스루로 확인해야 한다.
13. 코드 리뷰는 위험 관리다: 시스템의 위험도·변경 규모·예상 소요 시간에 따라 읽는 깊이를 조절하고, 이상 신호가 보이면 직감을 따라 깊게 들어가야 한다.
14. 항상 켜진 에이전트의 핵심은 토큰 효율이다: 단순 heartbeat는 KV 캐시가 사라질 때 수십만 토큰을 낭비하므로 변화 감지와 컨텍스트 재사용이 필요하다.
15. 컴퓨터·브라우저·macOS를 함께 다루는 인프라가 비어 있다: 웹 클라우드 세션은 쉽지만 로컬 환경과 Mac 앱을 안정적으로 이동·분산 실행하는 도구는 아직 부족하다.
16. 오픈소스의 다음 단계는 공유 세션과 오케스트레이션이다: 팀의 모든 세션을 이해하고 작업을 넘겨받는 에이전트가 개발 흐름을 터미널 중심에서 협업 중심으로 바꿀 수 있다.
17. 관심이 가장 비싼 통화가 되었다: 구현 비용이 낮아진 AI 시대에는 첫 사용자를 발견하고 신뢰를 얻고 계속 쓰게 만드는 분배가 가장 어렵다.
18. 어렵고 지루한 문제를 고려하라: 모두가 프롬프트로 만들 수 있는 재미있는 도구보다, 해결하기 어렵지만 해결되면 고마워할 사용자가 있는 문제에서 차별화가 쉬울 수 있다.
19. 지역·기기별 에이전트 실행 환경이 기회다: 빠르고 저렴한 Mac/Linux/Windows 테스트 박스와 원격 컴퓨트 fleet는 아직 개발자들이 직접 화면 공유로 버티는 영역이다.
20. 최종 원칙은 미래에 살며 계속 ship하는 것이다: 재미를 유지하고 직감을 듣고 집중하면서, 설명보다 실제로 빠진 것을 먼저 만들고 계속 출시해야 한다.