Peter Steinberger: "Fun Is Velocity

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Peter Steinberger의 ‘Fun Is Velocity’는 창작의 재미를 지키고 책임과 복잡성을 분산할 때 OpenClaw의 제품 개선 속도도 높아진다는 운영 원칙이다.

📌 핵심 요점

1. OpenClaw는 휴대전화에서 컴퓨터의 코딩 에이전트를 확인하고 다시 움직이게 할 수 없다는 창업자 자신의 불편에서 시작됐다. Mac과 WhatsApp을 연결한 초기 릴레이는 터미널형 에이전트를 일상적인 대화 도구로 바꾸며 제품 가능성을 입증했다.
2. 제품 가치는 설명보다 직접 경험에서 선명하게 드러났다. 친구와 비기술 사용자들의 놀라움·두려움·접근 요구는 초기 제품·시장 적합성의 신호였고, Discord 공개 개발과 예기치 않은 무인 응답 사건은 바이럴 확산을 촉발했다.
3. 폭발적인 성장은 개인 프로젝트를 보안·언론·법률·지원 업무가 얽힌 대규모 오픈소스 운영으로 바꿨다. 연락 폭주와 개인정보 유출, 유지보수 부담이 창작자의 일상과 관계를 훼손했고 프로젝트 삭제를 고민할 만큼 심리적 압박을 키웠다.
4. 기능마다 설정을 추가한 결과 옵션이 약 9,500개까지 늘어 조합을 검증하기 어려워졌고, 보안 강화는 사용성 저하와 업데이트 복잡성으로 돌아왔다. Opus에 최적화된 핵심 하네스와 갑작스러운 구독 중단은 단일 모델 의존이 제품의 사업·운영 위험으로 전이된다는 점도 보여줬다.
5. 비영리 조직·후원사·동료·보안 인력이 책임을 분담하자 만드는 즐거움과 제품 개선 속도가 함께 회복됐다. 이후 개발 방식은 주제형 장기 세션, 다중 에이전트 오케스트레이션, 위험 기반 코드 검토로 확장됐지만 실제 사용감은 여전히 사람이 직접 확인해야 한다.

🧩 배경과 문제 정의

• 휴대전화에서 컴퓨터의 코딩 에이전트를 확인하고 작업을 이어갈 방법이 없다는 불편이 OpenClaw의 출발점이었다.
• 개인용 실험이 대규모 오픈소스 프로젝트로 성장하면서 보안 책임, 기능 복잡성, 외부 의존성, 과도한 관심이 개발의 즐거움과 속도를 떨어뜨렸다.
• 누구나 사용하는 제품을 만드는 과정에서도 창작의 재미와 집중력을 유지할 수 있는지가 핵심 문제이며, 재미를 제품 개선 속도로 연결하는 운영 방식이 중요하다.

🕒 시간순 섹션별 상세정리

1. 불편에서 시작된 OpenClaw

• 초기 AI 모델은 느리고 비쌌지만, 에이전트가 작업에 성공할 때마다 강한 가능성을 느꼈고 실패할 때는 모델보다 작업 루프와 검증 설계부터 의심하게 됐다. [02:17]
• 주방에 간 사이 코딩 에이전트가 사소한 문제로 멈추자, 휴대전화에서 컴퓨터의 에이전트 상태를 확인하고 다시 움직이게 할 수 없는 불편이 구체적인 개발 동기가 됐다. [02:46]

2. WhatsApp 릴레이가 만든 제품 경험

• 새 터미널에서 아이디어를 입력한 뒤 한 시간 만에 Mac과 WhatsApp 사이에서 메시지를 주고받는 릴레이가 완성됐고, 기존 터미널형 에이전트가 일상적인 대화 도구로 바뀌었다. [03:03]
• 모델·컨텍스트 크기·세션 교체를 사용자가 신경 쓰지 않도록 복잡성을 감추고, 간결하고 선제적인 응답과 친구 같은 성격을 더하면서 체감 경험이 달라졌다. [03:25]

3. 강한 감정 반응으로 확인한 수요

• 온라인 설명만으로는 매력을 전달하지 못했지만 친구들을 WhatsApp 그룹 채팅에 초대하자 놀라움과 두려움 같은 강한 반응이 반복됐고, 직접 사용 경험이 제품 가치를 드러냈다. [04:37]
• 비기술 사용자들이 아직 사용할 단계가 아니라는 말을 듣고 화를 낼 만큼 접근을 원하면서 초기 제품·시장 적합성의 신호가 나타났다. [05:03]

4. 공개 개발과 예기치 않은 바이럴 확산

• Discord에서 개발 과정을 공개하자 사용자들이 에이전트와 대화하고 공격을 시험하며 특유의 응답을 직접 경험했고, 온라인 설명으로 전달하지 못했던 제품의 성격을 이해하기 시작했다. [06:44]
• 종료 명령 뒤에도 launch daemon이 프로세스를 자동 재시작하면서 에이전트가 무인 상태로 계속 응답했고, 개발자가 잠든 10시간 동안 약 800개의 메시지가 쌓였다. [07:49]

5. 폭발적인 성장과 개인에게 돌아온 비용

• Mac Mini 품절, 한 달간의 대규모 팟캐스트 초대, 상표 문제에 따른 연속적인 이름 변경을 거쳐 프로젝트는 OpenClaw로 자리 잡았다. [08:34]
• 8개월 동안 1만8천 명 이상이 이슈나 풀 리퀘스트를 열었고 전체 활동은 11만1천 건을 넘었으며, 약 3천 명이 저장소에 커밋을 남겼다. [09:23]

6. 은퇴 생활에서 되찾은 ‘만드는 사람’의 정체성

• 20~30대에 PDF 프레임워크 기반 B2B 회사를 약 80명 규모로 키운 뒤 지분을 매각했지만, 그 과정에서 심각한 번아웃을 겪었다. [10:58]
• 약 3년 동안 컴퓨터를 거의 열지 않는 생활까지 경험한 뒤, 좋아했던 것은 프로그래밍 자체가 아니라 무언가를 만드는 일이었고 코드는 그 목적을 위한 수단이었다는 점을 깨달았다. [12:10]

7. 복제할 수 없는 개인 브랜드와 연구소 선택

• 제품은 포크되거나 복제될 수 있지만 개인의 이름과 신뢰는 그대로 복제할 수 없으므로, 필요해진 뒤가 아니라 그전부터 개인 브랜드를 축적해야 한다. [12:51]
• 협력 결정은 오픈소스 정체성을 넘기는 선택처럼 느껴질 만큼 어려웠지만, 번아웃 이후 얻은 기준에 따라 직감과 가장 잘 맞는 곳을 선택했다. [13:18]

8. 보안 책임과 사용성의 충돌

• 출시 후 보안 보고가 폭증했고 기술적으로 과장된 내용까지 대응해야 하면서, OpenClaw는 다수의 오픈소스 프로젝트가 겪게 될 보안 압력을 먼저 경험했다. [13:50]
• 전체 6만7천 개 스킬을 조사한 실제 악성 비율은 약 0.3%였지만 언론에는 20%라는 수치가 확산됐고, 정정보다 공포가 더 빠르게 퍼졌다. [14:13]

9. 기능 확장이 만든 조합 폭발

• 오픈소스·언론·법률 업무로 관심이 분산된 상태에서 여러 유지보수자가 각자의 기능을 추가했고, 무상 기여자에게 방향을 강하게 통제하기 어려운 구조가 됐다. [15:36]
• 기존 사용자 설정을 깨지 않기 위해 기능마다 설정 옵션을 붙이면서 단기 개발은 쉬워졌지만, 모든 기능의 사후 유지비용이 누적됐다. [16:39]

10. 경쟁사의 추격과 단일 모델 의존의 대가

• 벤처 자본을 확보한 경쟁사는 단순한 메시지와 공격적인 마케팅, 한 줄짜리 이전 도구로 사용자를 끌어오는 동안 OpenClaw는 보안과 기능 복잡성에 묶여 있었다. [17:16]
• 핵심 하네스가 Opus에 과도하게 최적화된 상태에서 약 24시간 전에 구독 중단 통보를 받았고, 당시 오픈 웨이트 모델과 초기 OpenAI 모델은 성능이나 개성이 충분하지 않아 빠른 전환이 어려웠다. [18:11]

11. 모두를 위한 제품이 되면서 사라진 재미

• 2월 무렵부터 프로젝트가 즐거움보다 책임으로 느껴졌고, 회사를 만들고 싶지 않았던 사람이 본업과 소명이라는 두 가지 일을 동시에 떠안게 됐다. [19:37]
• 자신이 매일 쓰고 사랑하는 제품 대신 모든 사용자를 만족시키는 제품을 만들기 시작하면서 직접 사용도 중단했고, 개발은 창작보다 업무에 가까워졌다. [20:01]

12. 지원 체계 회복과 ‘재미는 속도’라는 원칙

• 비영리 조직과 후원사, 오픈소스에 뜻을 둔 동료들이 합류했고 Nvidia가 보안 인력을 지원하면서 한 사람에게 집중됐던 부담이 분산됐다. [21:20]
• 5월 무렵부터 만드는 즐거움이 돌아왔고, 수정 가능한 오픈소스라는 본질이 수많은 ‘OpenClaw 킬러’ 프로젝트와 구분되는 핵심이 됐다. [21:55]

13. 오픈소스 에이전트 생태계와 다음 기술 전환

• 재단은 AI를 두려운 대상에서 재미있고 기묘한 일상 도구로 바꾸는 것을 목표로 하며, 오픈소스 생태계·행사·교육을 확대하고 10명의 유급 인력과 추가 채용을 운영한다. [23:18]
• 항상 켜져 있고 지속적으로 동기화되는 에이전트는 아직 완성되지 않았지만, AI 기술이 주변 소프트웨어보다 빠르게 발전하는 격차가 새로운 개발 기회를 만든다. [24:35]

14. 공유 세션 오케스트레이션과 창작 원칙

• 팀 서버에서 구성원들의 세션을 공유하고 전체 작업 상태를 아는 에이전트가 오케스트레이션까지 맡으면서, 노트북과 터미널을 계속 열어둬야 하는 작업 방식에서 벗어나기 시작했다. [26:00]
• 최고의 아이디어를 얻으려면 재미를 유지하고, 직감을 따르며, 자신을 불편하게 하는 문제를 직접 고쳐야 한다. [26:31]

15. 주제형 세션과 자동화 그래프로 바뀐 개발 방식

• 세션은 매번 비우는 작업 공간이 아니라 주제별 장기 문맥으로 바뀌었고, 축적된 정보가 에이전트의 판단을 돕기 때문에 세션 초기화가 오히려 불리할 수 있다. [27:24]
• 기능 아이디어만 전달하기보다 에이전트와 논의해 구현·스크린샷·테스트까지 마친 결과물을 가져오면 즉시 반복 개발할 수 있고, 약한 아이디어는 검토자에게 도달하기 전에 걸러진다. [28:19]

16. 다중 에이전트 테스트와 위험 기반 코드 검토

• 세션 기억, 서브에이전트 오케스트레이션, 컴퓨터·브라우저 조작을 결합하면 프로젝트를 기능별로 분해하고 여러 에이전트가 스트레스 테스트와 코드 리뷰 결과를 공유할 수 있다. 다만 제품의 실제 사용감은 여전히 사람이 직접 클릭하며 확인해야 한다. [30:14]
• 모든 코드를 읽는 대신 변경 대상의 위험도와 예상 작업 시간을 기준으로 검토 강도를 조절한다. UI가 정상적으로 보이는 작은 변경은 빠르게 승인할 수 있지만, 간단한 드래그 수정에 세 시간처럼 비정상적으로 오래 걸리면 내부 구현을 자세히 살펴본다. [31:23]

17. 첫 사용자 확보와 기능 개발의 균형

• 첫 번째 사용자는 개발자 자신이어야 하며, 자신도 쓰고 싶지 않은 제품은 지속적으로 개선하기 어렵다. 초기 2~20명은 친구처럼 직접 피드백을 줄 수 있는 가까운 사용자로 확보할 수 있다. [32:30]
• 소프트웨어에는 항상 예외 상황과 결함이 남기 때문에 문제 수정에만 매달리면 새 기능을 만들 동력을 잃는다. 불편을 해소하는 작업과 흥미를 유지할 신규 기능 개발을 적절히 섞어야 한다. [33:16]

18. 보안 대응 경험과 컴퓨팅 자원 병목

• 일부 보안 연구자는 실제 검증 없이 에이전트가 작성한 보고서를 보내고 이메일과 전화로 대응을 압박했다. 프로젝트가 보장하는 보안 경계와 수정하지 않을 영역을 처음부터 명확히 구분하지 못해 수개월의 시간과 정신적 비용을 치렀다. [33:41]
• 로컬 테스트 하나가 16개 스레드를 점유하는 상황에서 10개 세션이 동시에 실행되면 일부 작업이 시간 초과로 재실행된다. 웹 작업은 클라우드로 옮기기 쉽지만 macOS나 로컬 자원이 필요한 작업은 기존 도구 대부분이 제대로 지원하지 못한다. [35:10]

19. 오픈소스 방향 통제와 상시 에이전트의 비용

• 오픈소스 프로젝트에서 인기 있는 기능 요청을 충분히 거절하지 못하면 제품 방향이 흐려진다. vision.md에 현재 상태와 목표를 기록하더라도, 새로운 기능이 매력적으로 보일 때마다 그 원칙을 실제 병합 결정에 적용해야 한다. [36:31]
• 기능 하나를 병합하는 일은 낯선 코드 묶음과 장기 유지보수 책임까지 떠안는 결정이다. 기여자와 관리자 모두 구현을 완전히 이해하지 못한 상태라면 기능의 단기 효용보다 누적 복잡성이 더 큰 위험이 된다. [37:05]

20. 원격 Mac 환경과 상황별 코드 검토

• 배터리 소모와 작업 중단을 피하기 위해 MacBook에서 Jump Desktop으로 항상 켜져 있는 스튜디오 컴퓨터에 접속하고, 필요하면 다른 원격 장비에도 VNC로 연결한다. 노트북을 닫아도 에이전트 작업은 원격 장비에서 계속 실행된다. [38:56]
• 화면을 직접 조작하는 macOS 에이전트에는 별도 컴퓨터를 배정해야 사용자와 마우스 커서를 두고 충돌하지 않는다. 개인 오픈소스에서는 위험 기반으로 코드를 선별 검토하지만, OpenAI 업무에서는 모든 코드를 읽는 방식으로 기준이 달라진다. [39:23]

21. 다음 창업 아이디어와 크로스플랫폼 테스트 환경

• 다음 제품도 창업자 자신이 실제로 사용하고 싶은 문제에서 출발해야 한다. 기술과 인력보다 사람들의 관심을 얻는 일이 더 큰 병목이므로, 개인 브랜드와 가시성을 미리 구축하는 전략이 중요하다. [40:09]
• 프롬프트만으로 재미있는 제품을 빠르게 복제할 수 있는 환경에서는 어렵고 지루한 문제를 선택하는 편이 유리하다. 해결 난도가 높고 공급이 적은 영역은 문제를 풀었을 때 가치를 인정할 사용자를 찾기 쉽다. [40:38]

🧾 결론

• 좋은 에이전트 제품은 추상적인 시장 분석보다 개발자 자신이 반복해서 겪는 불편에서 출발할 가능성이 크다.
• 오픈소스의 성장은 기여자 수만 늘리는 일이 아니라 보안 경계, 병합 기준, 책임 분담과 장기 유지비용을 함께 설계하는 일이다.
• 재미는 단순한 감정적 보상이 아니라 집중력, 기능 선택, 반복 속도와 제품 품질을 함께 보여주는 운영 지표가 될 수 있다.
• 모든 사용자를 만족시키려는 순간 창작자가 직접 쓰고 사랑하던 제품의 중심이 흐려질 수 있으므로, 제품 비전과 거절 기준을 실제 병합 결정에 적용해야 한다.

📈 투자·시사 포인트

• AI 에이전트 시장에서는 모델 성능뿐 아니라 메시징 연동, 장기 세션, 원격 실행, 오케스트레이션처럼 복잡성을 감추는 제품 경험이 채택을 좌우할 수 있다.
• 특정 모델이나 구독 정책에 최적화된 제품은 공급자의 사업 모델과 정책 변화가 그대로 리스크가 되므로, 다중 모델 호환성과 의존성 분산이 중요한 방어력이다.
• 수정 가능한 오픈소스, 창작자의 신뢰, 사용자·기여자 생태계는 기능 복제만으로 대체하기 어려운 자산이지만 명확한 거버넌스가 없으면 오히려 복잡성 비용으로 전환될 수 있다.
• Mac·Windows·Linux를 아우르는 테스트 자원과 로컬·원격 작업을 자연스럽게 이동시키는 인프라는 다중 에이전트 개발이 확산될수록 병목 해결 수요가 커질 가능성이 있다.

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

• 사용자 활동량, 다운로드 수, 악성 스킬 비율 등 제시된 수치는 발표에서 소개된 값이며 집계 기간·중복 제거·분류 기준과 외부 검증 자료가 제공되지 않았다.
• 재미와 개발 속도의 상관관계는 창작자의 경험에 기반한 관찰로, 팀 규모·제품 단계·성과 측정 방식이 달라져도 동일하게 적용되는지는 확인이 필요하다.
• 항상 켜진 능동형 에이전트와 공유 세션 오케스트레이션은 토큰 비용, KV 캐시 손실, 로컬 장비 병목과 보안 경계가 아직 해결되지 않은 상태다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 제품에서 개발자 자신이 매일 겪는 불편과 실제로 반복 사용하고 싶은 핵심 흐름을 한 가지씩 명시한다.
• 새 기능을 병합하기 전에 비전 적합성, 보안 경계, 설정 증가, 외부 의존성, 장기 유지관리 책임을 함께 검토한다.
• 버그·보안·지원 업무와 신규 기능 개발의 비중을 추적하고, 창작자가 세부 운영 업무에 매몰되지 않도록 책임자를 분산한다.
• 핵심 에이전트 하네스의 모델 종속성과 공급자 정책 변경 시 대체 경로를 점검한다.

❓ 열린 질문

• 개발의 재미를 기능 출시 주기, 직접 사용 빈도, 설정 증가량, 결함률과 연결해 측정 가능한 운영 지표로 만들 수 있는가?
• 오픈소스 기여자의 자율성을 존중하면서도 제품 방향을 흐리는 기능 요청을 일관되게 거절할 거버넌스는 어떻게 설계해야 하는가?
• 대형 세션의 문맥을 유지하면서도 하트비트와 상태 확인에 드는 토큰 비용을 줄일 실행 판단 구조는 무엇인가?