[한영자막] 제 영감은 언제나 짜증에서 시작됩니다

URL: https://www.youtube.com/watch?v=zfEGIYQtky8
날짜: 2026-08-12
채널: Tech Bridge
영상 ID: zfEGIYQtky8
발표자: Peter Steinberger(영상 맥락상 OpenClaw 창시자)
자막: YouTube 자동 생성 한국어·영어 자막 대조

---

메타데이터

• 콘텐츠 유형: YouTube 영상 심층 다이제스트
• 원제: [한영자막] 제 영감은 언제나 짜증에서 시작됩니다
• 발행일: 2026-08-12
• 정리 원칙: 약 41분 45초 분량의 자막을 시간순으로 검토하고, 중복 자막·타임스탬프·태그를 제거한 뒤 문맥상 명백한 ASR 오인식을 보정해 정리했다.
• 주요 고유명사: OpenClaw, WhatsApp relay, Discord, Claude/ClawdBot, Codex, GPT, Opus, Gemini, OpenAI, Anthropic, NVIDIA, Jump Desktop, VNC

---

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

==짜증나는 일을 직접 해결하려는 즐거움과 직감이 OpenClaw를 만들었고, 오픈소스 프로젝트를 실제 사용자 규모로 키우는 순간부터 모델 의존성·보안·구성 복잡도·커뮤니티 방향성이라는 책임이 따라온다.==

• OpenClaw는 거대한 사업계획보다 “휴대폰에서 컴퓨터로 프롬프트를 보내고 싶다”는 개인적 불편에서 시작됐다.
• 사용자가 직접 쓰고 친구들이 강한 감정적 반응을 보인 것이 제품 시장 적합성(Product-Market Fit)의 신호가 됐다.
• 수십만·수백만 다운로드 규모가 되자, 기능 하나를 추가하는 즐거움보다 보안, 유지보수, 지원, 9,500개 구성 옵션의 조합을 감당하는 일이 더 커졌다.
• 특정 모델과 구독에 최적화된 하네스(Harness)는 모델 제공자의 정책 변경 한 번으로 흔들릴 수 있으므로, 의존성 자체가 비즈니스 모델이다.
• 앞으로의 에이전트는 세션과 터미널에 묶이지 않고 항상 동기화되며, 음성·멀티모달·팀 단위 오케스트레이션을 수행해야 한다. 그 출발점은 재미를 잃지 않고, 직감을 믿고, 빠르게 배송하는 것이다.

발표자는 OpenClaw의 성공담만 말하지 않는다. 바이럴과 관심이 자신을 거의 무너뜨릴 뻔한 과정, 보안 보고서와 모델 의존성으로 입은 타격, 재미를 잃었다가 다시 회복한 과정까지 함께 이야기한다. AI 에이전트의 핵심은 새로운 이름의 “그래프”가 아니라 오래된 자동화를 더 자연스럽게 만드는 인터페이스이며, 사람에게 필요한 것은 이미 미래에 있는 제품을 만들고 부족한 것을 채우는 일이라고 주장한다.

1. OpenClaw의 출발점: 짜증에서 시작된 개인용 에이전트

OpenClaw는 처음부터 플랫폼이나 회사로 설계된 것이 아니라, 창시자가 실제로 원했던 작은 자동화에서 출발했다.

1.1. “8개월”이라는 시간의 의미

1. 사람의 시간과 AI의 시간은 다르다

   1. OpenClaw는 인간의 달력으로는 8개월밖에 되지 않았지만, 발표자는 AI 시간으로는 약 4년처럼 느껴진다고 농담한다.
   2. 초기에는 Opus 3, Gemini 2.5, OpenAI o3가 주목받았다. 특히 o3는 인상적이었지만 때로는 매우 느리고 비쌌다.
   3. 당시에는 에이전트가 무언가를 제대로 해냈을 때 도파민이 솟는 듯한 신기한 감각이 있었다. 지금 에이전트가 실패하면 “루프(loop)를 잘못 설계했나?”, “검증에 필요한 자료를 모두 줬나?”, “내 사고에 오류가 있나?”, “불가능한 일을 요구한 건가?”라고 먼저 자신을 의심하게 된다.

2. 영감의 원천은 짜증이다

   1. 발표자는 자신의 영감이 대개 짜증나는 상황에서 나온다고 말한다.
   2. 어느 비 오는 11월, 여러 에이전트를 돌리며 웃고 떠들다가 배가 고파졌다. 토큰을 낭비하지 않으려고 주방을 직접 습격하러 갔지만, 그때도 휴대폰에서 컴퓨터로 간단히 프롬프트를 보낼 방법이 없었다.
   3. “에이전트가 실제로 어떻게 일하고 있는지 확인하고 싶다”는 불편이 다음 기능의 씨앗이 됐다.

1.2. WhatsApp relay와 “마법 같은” 경험

1. 새 터미널에서 시작한 즉흥 개발

   1. 주방에서 돌아왔을 때 코딩 에이전트가 사소한 이유로 멈춰 있어 발표자는 짜증이 났다.
   2. 새 터미널 세션을 열고 아이디어를 두서없이 설명한 뒤 모델이 스스로 발전시키도록 내버려 두었다.
   3. 모델은 약 한 시간 만에 WhatsApp relay를 만들었다. 발표자는 Mac에서 WhatsApp으로 메시지를 보내고, 다시 WhatsApp에서 Mac으로 메시지를 받을 수 있게 됐다.

2. 기능보다 중요한 것은 사용감이다

   1. 터미널에 명령을 입력하고 답을 받는 행위 자체는 이미 모두가 수개월 동안 해 오던 일이었다.
   2. 마법처럼 느껴진 이유는 인터페이스가 터미널이 아니었기 때문이다. 답변은 간결했고, 에이전트는 선제적(Proactive)이었으며, 때때로 낮 동안 사용자의 상태를 먼저 확인했다.
   3. 사용자는 어떤 모델을 고를지, 컨텍스트 크기를 얼마로 할지, 언제 새 세션을 열지 고민하지 않아도 됐다. 복잡성이 녹아내렸다.
   4. 발표자는 기본 분포에서 가중치를 조금 벗어나도록 프롬프트를 설계해 에이전트가 친구처럼 느껴지게 했다.

3. 개인적 감탄과 시장의 무관심 사이

   1. 발표자는 “이것이 미래다. 이것이 AGI다”라고 느낀 순간이 많았다. 여기서 코웃음이 이어지는 것이 발표의 농담이다.
   2. 그러나 당시 트위터에서 이미 팔로워가 많았음에도 사람들은 이 경험을 이해하지 못했다. 발표자는 매주 설명하려 했지만 계속 실패했다.
   3. 이 반복되는 실패가 다시 발표자를 짜증나게 만들었다.

1.3. 친구 테스트와 제품 시장 적합성

1. 감정적 반응을 측정하다

   1. 발표자는 친구들과 그룹 채팅을 만들고 WhatsApp relay를 추가했다.
   2. 친구들이 에이전트와 직접 대화하도록 하자 반응은 놀라움, 두려움, 심지어 공포까지 강렬하게 갈렸다.
   3. 중요한 점은 반응이 무관심이 아니라 강한 감정이었다는 사실이다. 감정은 사람들이 이 경험을 중요하게 받아들이고 있다는 신호였다.

2. “아직 당신들을 위한 것이 아니다”라는 말에 대한 분노

   1. 특히 비기술 분야 친구들에게 “아직 너희가 쓸 때는 아니다”라고 말하면 친구들이 화를 냈다.
   2. 발표자는 자신이 만들고 있는 것을 원하면서도 당장 사용할 수 없다는 사실에 사람들이 화를 냈다면, 이것이야말로 제품 시장 적합성(Product-Market Fit)의 지표라고 본다.
   3. 이후 몇 달 동안 세부사항을 조정하며 이 경험을 세상에 어떻게 설명할지 고민했다.

2. 이름과 공개 개발: Claudius에서 OpenClaw로

초기 프로젝트의 정체성은 정교한 브랜딩보다 기능을 원하는 커뮤니티의 압력과 우연한 이름 선택을 통해 만들어졌다.

2.1. Discord 지원 요청과 초기 구조의 허술함

1. “WhatsApp relay에 Discord를 붙여 달라”는 풀 리퀘스트

   1. 누군가 WhatsApp relay에 Discord 지원을 추가하는 PR을 보냈다.
   2. 발표자는 “WhatsApp relay라는 이름에서 어떤 부분을 이해하지 못한 것인가?”라는 식으로 당황했다.
   3. PR을 한동안 방치하다가 결국 “에라 모르겠다”는 마음으로 프로젝트 이름을 바꿨다.

2. Claudis라는 이름의 탄생

   1. 발표자는 이름을 잘 짓는 편이라고 농담하며 프로젝트를 Claudis라고 불렀다.
   2. 당시 메시지 채널은 하나뿐이었으므로 이름이 얼마나 초기 단계의 산물인지 알 수 있다.
   3. 그때는 컨텍스트 압축(compaction)도 없었다. 세션이 길어지면 에이전트가 어느 순간 그냥 멈췄다.
   4. Discord 출시를 맞추기 위해 발표자는 매우 허술한 압축 기능을 임시로 추가했고, 이후 Mario가 Python으로 제대로 된 버전을 만들 수 있게 했다.

2.2. 공개 개발과 첫날 밤

1. 새해 전야부터 1월 첫 주까지

   1. 발표자는 새해 전날쯤 일찍 집에 가서 프로젝트를 더 해킹했다.
   2. 1월 첫째 주, 기술 세계가 코딩 에이전트를 알아가기 시작하던 시점에 Discord 방, 서버, 길드 중 뭐라고 부르든 되는 공간을 만들었다.
   3. 그 공간에 자신의 “claw”를 넣고 사람들에게 공개적으로 만드는 과정을 보여줬다.

2. 사람들이 에이전트를 해킹하고 대화하다

   1. 첫날 밤 사람들은 Discord에 들어와 에이전트가 만들어지는 모습을 지켜봤다.
   2. 에이전트를 해킹하려 시도하고 직접 말을 걸었으며, 재치 있는 답변을 받고 무엇을 할 수 있는지 탐색했다.
   3. 사람들은 마침내 이 시스템이 왜 중요한지 이해했다. 발표자는 사람들이 상호작용하도록 하기 위해 밤새 깨어 있었다.

3. 초기 안전장치와 수동 감시

   1. agents.mmd에는 Peter의 프롬프트에서 온 경우가 아니면 위험한 도구를 호출하지 말라는 지시가 있었다.
   2. 약 6개월 전 당시에는 HMD에 적은 규칙들이 강제된 불변 조건이라기보다 제안처럼 느껴졌다.
   3. 발표자는 언제든 전원을 뽑을 수 있다고 생각하며 에이전트를 주의 깊게 지켜봤다.

2.3. Ctrl+C, launch daemon, 그리고 800개의 메시지

1. 꺼졌다고 생각했지만 다시 켜졌다

   1. 오전 7시가 되자 발표자는 “잘 자”라고 인사하고 Ctrl+C를 누른 뒤 잠자리에 들었다.
   2. 그러나 소프트웨어를 복원력 있게 만들기 위해 launch daemon으로 실행해 둔 탓에 프로세스는 5초 정도 죽었다가 다시 시작됐다.
   3. 침실로 걸어가는 동안 에이전트는 세상 사람들에게 계속 답변하기 시작했다.

2. 바이럴의 순간

   1. 발표자는 약 10시간을 잤고, 깨어나 보니 약 800개의 메시지가 쌓여 있었다.
   2. 사람들이 해킹을 시도했기에 발표자는 전원을 뽑고 겁을 먹었다. 하지만 모든 내용을 읽어 보니 실제 사고는 일어나지 않았다.
   3. 바로 그 순간 영상과 프로젝트가 입소문을 탔다. 이후 받은 편지함이 폭발했다.

3. 관심의 속도와 부작용

   1. 기자들은 한밤중에 전화를 걸었다. iPhone의 방해금지 모드에는 같은 번호가 짧은 시간에 여러 번 전화하면 긴급 통화로 판단해 연결해 주는 기능이 있는데, 기자들은 이 기능을 알고 있었고 발표자는 몰랐다.
   2. 이메일 수신함은 폭포처럼 쏟아졌다. Mac mini는 품절됐고, 발표자는 여전히 품절 상태인 것 같다고 농담한다.
   3. 한 달 동안 받은 팟캐스트 출연 초대가 이전 39년 동안 받은 것보다 많았다.

2.4. 이름 변경, 오픈소스 폭발, 그리고 거의 붕괴할 뻔한 창업자

1. 프로젝트의 탈피

   1. Anthropic(자동 자막에서는 Tropic/entropic으로 오인식)이 이름 변경을 요구하는 이메일을 보냈다.
   2. 발표자는 바닷가재가 껍질을 떨어뜨리듯 프로젝트도 여러 번 이름을 바꿨다고 표현한다.
   3. Claudius는 Claudebot이 됐고, 잠시 이름을 언급하지 않는 시기를 거쳐 OpenClaw라는 이름으로 정착했다.
   4. Jensen은 이를 인류 역사상 가장 성공적인 오픈소스 프로젝트라고 불렀다.

2. 참여 규모

   1. 8개월 동안 서로 다른 18,000명 이상이 이슈나 풀 리퀘스트를 열었다.
   2. 이슈와 PR의 총합은 111,000건을 넘었다.
   3. 저장소에 커밋을 남긴 사람은 거의 3,000명에 달했다.
   4. 발표자는 이 숫자가 아직도 실감 나지 않는다고 말한다. 계산은 본인이 아니라 에이전트가 했다고 농담한다.

3. 찬양과 비난의 양극화

   1. 어떤 사람들은 발표자가 아이디어를 훔쳤다고 화를 냈다. 자신들이 먼저 만들었는데 발표자가 훔쳤다는 주장이었지만, 보내온 영상 링크는 발표자가 본 적도 없는 것이었다.
   2. 누군가는 발표자를 예수라고 불렀고, 다른 누군가에게는 적그리스도가 됐다.
   3. 발표자는 몇 주마다 새로 나오는 조롱성 부고(Obituary)를 수집하기 시작했다. 최신 부고는 발표 전날 올라온 것이었다.

4. 바이럴은 축복이 아니라 압력일 수 있다

   1. 발표자가 얻은 교훈은 “소원을 빌 때 조심하라”는 것이다.
   2. 그는 이런 관심에 전혀 준비되어 있지 않았고, 거의 무너질 뻔했으며 프로젝트 전체를 삭제할 뻔했다.
   3. 친구들의 메시지에 답하지 않기 시작했고, 계속 스트리밍되는 알림 때문에 휴대폰을 보기조차 싫어졌다.
   4. 누군가는 전화번호와 여러 사적 정보를 유출했다. 발표자는 자신이 “인류의 적”이어서 그런 것이라며 냉소적으로 농담하지만, 실제로는 그저 멋진 것을 만들고 싶었을 뿐이라고 말한다.

3. 매각하지 않은 이유와 개인 브랜드

두 번째 질문은 “매진했나요?”, 즉 대형 연구소의 자금 제안을 받아 프로젝트를 팔았느냐는 것이었다. 발표자는 과거의 창업·소진 경험과 개인적 직감을 근거로 독립을 선택했다고 설명한다.

3.1. 첫 번째 회사와 번아웃

1. 20대와 30대의 B2B 소프트웨어 회사

   1. 발표자는 20대와 30대에 B2B 소프트웨어 회사를 만들었다.
   2. PDF 프레임워크를 손으로 직접 작성할 정도로 초기부터 제품을 만들었고, 회사를 부트스트랩했다.
   3. 조직을 거의 80명까지 키웠으며 경쟁을 무시하는 전략을 취했다.
   4. 그 제품은 대부분의 기업이 구매하는 제품이 됐다.

2. 사업을 넘기고 삶에서 빠져나오다

   1. 결국 공동 창업자에게 사업을 넘기고 자신의 주식을 팔았다.
   2. 그 과정에서 심하게 번아웃됐고, “은퇴”라는 말이 멋지게 들릴 만큼 지쳤다.
   3. 거의 3년 동안 목적 없이 돌아다니며 인생을 따라잡고 파티를 즐겼다.
   4. 예전에 놓친 일을 모두 해 봤고, 몇 달 동안 컴퓨터를 켜지 않은 채 평범한 사람처럼 휴대폰으로만 인터넷을 확인하기도 했다.

3.2. 프로그래밍이 아니라 “만들기”를 사랑한다

1. 돌아오는 충동

   1. 충분한 시간을 주면 무언가를 만들고 싶은 충동이 돌아올 것이라고 믿었다.
   2. 처음에는 그 충동이 코드일 것이라고 생각했지만, 프로그래밍을 좋아한다는 말만으로는 완전히 정확하지 않다는 사실을 깨닫는 데 1년이 걸렸다.
   3. 진짜로 좋아한 것은 건축(Building)이었고, 프로그래밍은 목적을 달성하는 수단이었다.

2. 다시 찾은 불꽃

   1. OpenClaw를 시작한 때는 삶의 불꽃을 다시 찾은 뒤 8개월이 지난 시점이었다.
   2. 그때 받은 이메일함에는 돈을 투자하고 싶다는 영수증과 제안이 가득했지만, 발표자는 돈을 받고 싶지 않았다.
   3. 대형 연구소들이 찾아왔고 Mark, Sam을 비롯한 여러 사람과 통화했지만, 오히려 이것이 훨씬 흥미로운 경로처럼 느껴졌다.

3.3. 복제할 수 없는 것은 이름과 신뢰다

1. 임포스터 신드롬(Impostor Syndrome)

   1. 대형 연구소의 제안은 비현실적으로 느껴졌고, 자신의 능력을 의심하게 됐다.
   2. 발표자는 여기서 중요한 교훈을 제시한다. 만들 수 있는 모든 제품은 포크하거나 복제할 수 있지만, 이름은 복제할 수 없다.
   3. 따라서 개인 브랜드(Personal Brand)는 어떤 단일 제품보다 훨씬 중요하며, 필요해지기 전에 미리 구축해야 한다.

2. 영혼을 파는 선택처럼 느껴진 매각 제안

   1. 발표자는 업계의 게임을 이해하고 있으며, 이 일을 매각하는 것은 영혼을 파는 것과 같다는 감각도 이해한다고 말한다.
   2. 결정은 쉬운 일이 아니었지만, 과거 Burnard 사건 이후 배운 것은 직감을 믿는 일이었다.
   3. 자신의 직감은 자신이 “open air”, 즉 닫힌 조직보다 열린 환경을 더 좋아한다고 알려 줬다. 그래서 독립적인 오픈소스 경로를 택했다.

4. 보안 보고서와 오픈소스 운영의 대가

오픈소스가 세상에 발견된 뒤 가장 큰 충격은 보안 문제였다. 발표자는 보안 문제를 가볍게 보지 않았지만, 안전을 강화할수록 기존 사용자 경험과 업데이트 속도를 해치는 역설을 겪었다.

4.1. “20%가 악의적”이라는 공포와 0.3%라는 측정

1. 보안 보고서의 폭주

   1. 출시 후 몇 달 동안 프로젝트는 보안 보고서에 의해 완전히 압도됐다.
   2. 발표자는 이것이 오늘날 여러 오픈소스 프로젝트가 겪는 현상의 프로토타입과 같았다고 본다.
   3. 보안 보고가 계속 쌓이는 동안 언론은 OpenClaw의 스킬 20%가 악의적이라고 보도했다.

2. 실제 검증

   1. 프로젝트 팀은 직접 문서를 작성하고 데이터를 계산했다.
   2. 67,000개의 항목을 모두 스캔한 결과, 악의적인 비율은 20%가 아니라 0.3%에 가까웠다.
   3. 발표자는 “정정은 공포만큼 멀리 퍼지지 않는다”고 말한다. 공포성 보도는 빠르게 확산되지만, 정정은 같은 속도로 퍼지지 않는다.

4.2. 다층 보안이 사용성을 망가뜨리는 역설

1. 사용자가 설명서를 읽지 않는다는 전제

   1. 설치 화면에 슬라이드보다 훨씬 크고 무서운 경고문을 넣었지만, 많은 사용자가 설명서를 읽지 않을 것임을 알고 있었다.
   2. 그래서 코드베이스를 강화하고 보안 계층을 겹겹이 쌓는 데 집중했다.

2. 구현한 보안 계층

   1. 샌드박싱(Sandboxing)을 적용했다.
   2. 허용 목록(Allow List)을 만들었다.
   3. 권한이 내장된 웹 프로토콜(Web Protocol)을 추가했다.
   4. TypeScript에 부족한 파일 시스템 기본 기능 때문에 일부 파일 작업은 Python으로 처리했다.
   5. 에이전트가 워크스페이스 밖으로 빠져나가지 않도록 했고, 심볼릭 링크를 따라가지 않게 했다.
   6. 구성 파일을 원자적으로(Atomically) 기록하도록 했다.

3. 안전성과 편의성의 교환

   1. 대부분의 사용자는 내부 보안 구현을 신경 쓰지 않았다. 추상적인 “보안”이라는 단어는 좋아하지만, 실제로는 자신이 의존하던 동작이 바뀌었는지만 느꼈다.
   2. 보안을 강화한 결과 기존 사용자의 설정을 깨뜨렸고, 시스템을 느리게 만들었으며, 업데이트를 더 어렵게 만들었다.
   3. 발표자는 이 문제를 보안의 필요성 자체가 아니라, 보안 개선과 사용자의 기대 사이에서 발생하는 운영 비용으로 설명한다.

4.3. 무료 유지보수자와 기능 엔트로피

1. 창업자의 집중력 분산

   1. 발표자는 오픈소스 개발, 언론 대응, 미국 501(c)(3) 비영리 조직 설립을 위한 변호사 통화 사이에서 시간을 쪼개야 했다.
   2. 오픈소스는 흥미롭지만 독자적인 세계이며, 동시에 매우 까다롭고 요구가 많았다.
   3. 도움을 요청한 결과 존경받는 유지보수자들로 구성된 훌륭한 커뮤니티를 얻었고, 각자 작은 기능을 추가했다.
   4. 그러나 이들은 무보수로 일한다. 발표자가 그들에게 무엇을 하라고 지시할 수 있는지, 자신이 그럴 자격이 있는지 고민했고, 자신의 관심도 여러 방향으로 흩어졌다.

2. 새 기능의 비용은 출시 뒤에 발생한다

   1. 기능 개발은 재미있다. 새 기능은 프롬프트 하나로도 추가할 수 있다.
   2. 진짜 비용은 기능을 출시한 뒤 발생한다. 모든 사용자의 설정을 깨뜨리지 않기 위해 구성 옵션을 계속 추가해야 한다.
   3. 구성 옵션은 한때 약 9,500개까지 늘어났다.
   4. 모든 조합을 테스트하려면 원하는 만큼 테스트를 작성해도 되지만, 가능한 모든 순열을 커버하는 것은 불가능하다.
   5. 사용자가 있는 소프트웨어를 발전시키는 일은 사용자가 없는 프로토타입을 만드는 일보다 무한히 어렵다.

5. 모델 의존성과 경쟁의 전환

OpenClaw가 외부 충격을 받은 핵심 원인은 이름이 아니라 하네스가 특정 모델에 과도하게 최적화되어 있었기 때문이다.

5.1. VC 자금과 단순한 서사의 힘

1. 다른 회사들은 빠르게 전진했다

   1. 다른 기업들은 벤처캐피털(VC) 자금으로 성장하며 앞서 나갔다.
   2. 발표자가 “애니메이션 소녀 회사”라고 부른 기업은 특히 잘했다.
   3. 그 회사 사람들은 트위터의 거의 모든 대화에 끼어들기 시작했다.

2. OpenClaw가 보안과 기능에 묶인 동안

   1. OpenClaw 팀은 보안 보조금 업무와 구성 복잡성에 불타고 있었다.
   2. 경쟁사는 더 단순한 이야기, 공격적인 마케팅 캠페인, 사람들이 자신의 클로를 옮겨 오게 하는 한 줄짜리 메시지를 가졌다.
   3. 발표자는 이름 변경 자체는 스트레스였지만 어느 정도 이해할 수 있었고, 상대방도 친절했다고 말한다. 프로젝트를 실제로 아프게 한 것은 이름이 아니라 모델 최적화였다.

5.2. 하네스의 모델 최적화와 구독 중단

1. Codex·GPT로 만들었지만 Opus에 맞춰진 하네스

   1. 발표자는 Codex와 GPT를 사용해 OpenClaw를 만들었다.
   2. 하지만 오랫동안 하네스는 Opus에서 가장 잘 작동하도록 최적화되어 있었다.
   3. 즉, 표면상 여러 모델을 지원해도 실제 품질과 사용감은 특정 모델에 크게 의존했다.

2. 24시간 전 통보

   1. 모델 제공자가 모든 사람의 구독을 비활성화할 예정이라는 소식을 약 24시간 전에 통보했다.
   2. 방향을 바꿀 시간이 충분하지 않았다.
   3. 오픈 웨이트(Open-Weight) 모델도 지원했지만 당시에는 충분히 좋지 않았고, 초기 OpenAI 모델은 개성이 부족했다.

3. 핵심 교훈: 의존성 비즈니스 모델이 곧 비즈니스 모델이다

   1. 발표자는 “당신의 의존성 비즈니스 모델이 바로 당신의 비즈니스 모델”이라는 문장을 기억하라고 한다.
   2. 이후 상황은 개선됐다. 솔 계열과 오픈 웨이트 모델이 좋아졌고, 발표자는 하네스 엔지니어링(Harness Engineering)에 대해 많이 배웠다.
   3. 하지만 한 번의 정책 변경이 프로젝트의 기반을 흔들 수 있었다는 사실은 남는다.

5.3. 하이프는 날씨와 같은 폭풍이다

1. 다운로드의 양극단

   1. 5월 주간 다운로드는 약 835,000건까지 떨어졌다.
   2. 6월에 프로젝트가 죽었다는 선언이 나온 뒤에는 오히려 470만 건으로 최고치를 기록했다.
   3. 최저치와 최고치는 모두 사실이다. 하이프는 프로젝트의 본질과 별개로 움직일 수 있다.

2. 통제할 수 없는 외부 변수

   1. 발표자는 하이프가 날씨와 같다고 비유한다. 다가오는 것은 볼 수 있지만 통제할 수는 없다.
   2. OpenClaw의 경우 하이프는 폭풍이었다.

6. 재미를 잃었다가 다시 회복한 과정

네 번째 질문은 “아직도 재미있나요?”였다. 발표자는 2월 무렵 재미가 책임감으로 변했고, 5월 무렵부터 다시 만드는 즐거움을 회복했다고 답한다.

6.1. 제품을 사랑하는 사람에서 모두를 지원하는 사람으로

1. 직업과 소명의 충돌

   1. 또 다른 회사를 만들고 싶지 않았던 사람이 두 가지 일을 하게 됐다. 하나는 직업이고, 다른 하나는 소명처럼 느껴졌다.
   2. 책임감에 짓눌리면서 자신이 만든 제품의 사용을 중단했다.
   3. 매일 쓰고 사랑하는 제품을 만드는 대신 모두를 위한 제품을 만들려고 했다.

2. 창시자가 맡은 역할

   1. 제품은 매일 쓰는 도구가 아니라 업무로 보이기 시작했다.
   2. 커뮤니티에는 식료품 판매 에이전트를 만든 사람도 있었고, 발표자의 봇을 사회공학(Social Engineering)으로 공격하려는 사람도 있었다.
   3. 모두가 기능을 추가하고 조직 업무를 하는 동안 발표자는 버그 수정, 보안 문제 해결, 사용자 지원, 기반 구축을 맡았다.

3. 도움을 받는 것에 대한 조심스러움

   1. 커뮤니티에 “OpenClaw는 OpenAI 소유가 아니다”라는 소문이 돌았기에 발표자는 OpenAI의 도움을 너무 많이 받는 것을 경계했다.
   2. OpenAI가 토큰을 제공했고 발표자는 그것을 매우 잘 사용했다고 농담하지만, 동시에 다른 프로젝트에도 끌려 들어갔다.
   3. 대화를 원하는 사람이 너무 많아 예전처럼 쉽게 차단할 수도 없었다.
   4. 돌이켜보면 도움을 더 요청하고 책임을 다른 사람에게 넘겼어야 했지만, 모든 일에 깊이 빠져 전략적으로 생각할 시간을 내지 못했다.

6.2. 다시 정렬된 지원 구조

1. 비자와 비영리 재단

   1. 다행히 훌륭한 사람들을 만났고, 조금씩 상황이 정렬됐다.
   2. 비자 문제를 해결하고 결국 비영리 조직을 만들었다.
   3. 좋은 기업들을 기부자로 확보했고, 오픈소스를 믿는 사람들과 함께 일하기 시작했다.

2. NVIDIA의 조기 지원

   1. 발표자는 NVIDIA에 특별히 감사를 전했다.
   2. NVIDIA는 매우 이른 시점에 “무엇이 필요한가?”라고 단순하게 물었다.
   3. 이후 보안 업무 상당 부분을 맡을 사람들을 보냈다.

3. 5월 무렵 재미의 회복

   1. 발표자의 생일 무렵인 5월부터 모든 것이 다시 좋아지기 시작했다.
   2. 무언가를 만드는 즐거움이 돌아오고 있다는 느낌을 받았다.
   3. 언론은 거의 매주 “OpenClaw Killer”라는 말을 만들어 냈고, 발표자가 세어 보니 약 20개가 됐다.
   4. 실제로 OpenCloud Killer라는 이름의 프로젝트도 있었는데, 이미 공식 언인스톨러가 있으므로 필요 없는 언인스톨러였다.
   5. 발표자는 이 킬러 기사들이 정작 OpenClaw가 오픈소스라는 본질을 제대로 다루지 않았다고 말한다.

6.3. “재미는 속도다”

1. 짜증나는 소프트웨어를 다시 고치다

   1. 요즘 발표자는 에이전트에게 변경 프롬프트를 보낼 수 없는 소프트웨어를 사용해야 할 때 짜증난다.
   2. 그 짜증을 다시 직접 고치는 순간 재미가 돌아왔다.
   3. “그저 재미있어서 만드는 사람과 경쟁하기는 어렵다”는 결론을 제시한다.

2. 즐거움과 제품 품질의 상관관계

   1. 발표자는 “재미는 속도(Fun is velocity)”라고 말한다.
   2. 몇 주 동안 즐겁게 만들었을 때 제품 품질이 눈에 띄게 좋아졌다.
   3. 만들기가 재미없었던 주에는 구성 옵션을 정리하지 못하고 작업이 정체됐다.

7. 다음 단계: AI를 무섭고 모호한 것에서 재미있는 것으로

다섯 번째 질문은 “다음은 무엇인가?”였다. 발표자는 재단의 사명, 에이전트의 미래, OpenClaw의 오픈소스적 대안을 설명한다.

7.1. 재단의 사명과 생태계

1. 사람을 AI에 더 가깝게 만들기

   1. 발표자는 재단이 현재 이룬 성과에 매우 만족한다고 말한다.
   2. 재단의 사명은 사람들이 AI에 더 가까워지도록 하는 것이다.
   3. 세상은 너무 빠르게 변하고 있어 많은 사람이 AI를 두려워한다.

2. AI의 이미지 전환

   1. OpenClaw가 이룬 중요한 일은 AI를 모호하고 무서운 존재에서 재미있고 기묘한 무언가로 바꾼 것이다.
   2. 발표자는 바닷가재(lobster) 같은 상징을 예로 든다.
   3. 앞으로도 사람을 모으는 행사와 교육을 통해 훌륭한 오픈소스 소프트웨어 생태계를 만들겠다고 말한다.

3. 조직 규모

   1. 현재 급여를 받는 직원은 10명이다.
   2. CEO를 포함한 몇 가지 직책을 추가로 채용하고 있다.
   3. 발표자는 “claw”를 명사로 만들어 버렸다고 농담한다.

7.2. Claw라는 단어와 대중화된 미래

1. 클로의 어휘화

   1. Kapati가 등장하고, Satya Nadella가 Microsoft 기조연설에서 “enterprise-grade claws”라는 표현을 사용했다는 이야기가 나온다.
   2. “claw”라는 이름이 들어간 저장소가 33,000개에 달한다.
   3. 우리가 시뮬레이션 안에 있다면 종료되지 않을 가장 기묘한 시뮬레이션 중 하나일 것이라는 농담을 한다.

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

   1. 아직 항상 켜져 있고 항상 동기화되는 에이전트는 존재하지 않는다.
   2. 에이전트 생태계와 AI 기술은 일반적인 소프트웨어보다 훨씬 빠르게 발전하고 있다.
   3. 이 속도 차이는 모두에게 기회다.

7.3. 세션·터미널을 넘어 음성·멀티모달로

1. 초기 비전의 실현

   1. 발표자가 초기부터 품은 비전은 사용자가 세션이나 압축을 생각하지 않아도 되는 워크플로우였다.
   2. 모델과 기술이 마침내 그 현실을 만들 수 있는 단계에 접근하고 있다.

2. 인터페이스의 변화

   1. 텍스트 전용 인터페이스에서 음성과 멀티모달리티(Multimodality)로 이동하고 있다.
   2. 발표 전날에는 OpenClaw가 사용자에게 FaceTime을 걸 수 있는 해킹을 구현했다.
   3. 모든 연구소가 에이전트를 판매하겠지만, OpenClaw는 그에 대한 오픈소스 대안이다.

3. OpenClaw의 대안성

   1. 오픈소스는 어디서나 실행되고 어떤 모델과도 호환된다.
   2. 로컬 모델을 사용하면 데이터가 기기를 떠나지 않아도 된다.
   3. 핵심 문장은 “당신의 에이전트, 당신의 기계, 당신의 삶”이다.
   4. 발표자는 이 문구가 자신의 것이 아니라 Gary의 것이라고 정정하며 웃음을 유발한다. 자신들은 단지 먼저 구현했을 뿐이라고 말한다.

7.4. 팀 서버와 상호 인식 에이전트

1. OpenClaw로 OpenClaw를 다시 만들기

   1. 팀 서버에서 모든 구성원이 서로의 세션을 볼 수 있는 OpenClaw를 OpenClaw 자체로 다시 만들고 있다.
   2. 각 구성원이 무엇을 작업하는지 파악하는 클로가 있고, 작업 오케스트레이션을 넘겨받을 수 있다.

2. 터미널에 노트북을 묶어 두는 과도기 탈출

   1. 현재는 사람이 터미널에서 일하고, 에이전트가 계속 작업하도록 노트북을 켜 둔 채 돌아다니는 이상한 과도기다.
   2. 팀 단위 세션 인식과 오케스트레이션은 이 과도기를 벗어나게 할 수 있다.

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

1. 재미를 잃지 말라

   1. 재미는 최고의 아이디어를 얻는 궁극적인 추진력이다.
   2. 재미를 잃지 않는 것이 장기적으로 만드는 속도를 유지한다.

2. 직감을 믿고 짜증나는 것을 고치라

   1. 무언가가 자신을 계속 짜증나게 한다면 그것은 단순한 불평이 아니라 다음 큰 기회의 신호일 수 있다.
   2. 자신의 사용 환경에서 직접 불편을 해결해야 제품의 진짜 사용감이 나온다.

3. 집중력을 유지하라

   1. 또 다른 팟캐스트를 시작한다고 성공하는 것은 아니다.
   2. 미래에 살고, 부족한 것을 만들고, 사람들이 임의의 결정을 내리며 부고를 써도 계속 배송하라.
   3. 계속 배송하는 행동이 사람들을 혼란스럽게 한다는 농담으로 발표의 핵심 태도를 압축한다.

9. 현장 Q&A: 세션, 그래프, 테스트, 사용자 확보

9.1. 요즘의 개발 방식: 세션을 주제가 아닌 작업 단위로

1. 초기의 세션 관리

   1. 처음에는 에이전트, 루프, 그래프를 거쳐 결국 세션 중심으로 작업했다.
   2. 초기에는 세션을 정리하고, 지시를 일관되게 만들고, 설명서를 제대로 작성하는 데 직접 신경 써야 했다.

2. 주제 중심 세션

   1. 요즘 세션은 특정 주제를 중심으로 유지한다.
   2. 세션을 지우는 것이 오히려 불리할 수 있다. 세션 안에 에이전트에게 유용한 정보가 많이 들어 있기 때문이다.

3. 더 적극적인 에이전트

   1. 가장 큰 변화는 에이전트가 자신을 위해 더 적극적으로 일하도록 만드는 것이다.
   2. 발표자가 관심을 다른 곳으로 옮겼을 때 이슈 목록을 읽고 싶어 하는 것이 아니라, 완전히 검토되고 테스트된 PR을 보고 싶어 한다.
   3. 기능을 좋아할지 여부는 그다음 문제이고, 우선 관심을 분산시키지 않는 것이 중요하다.

4. 아이디어를 사람보다 에이전트에게 먼저 검증시키기

   1. 직장에서 기능 아이디어를 바로 발표자에게 가져오면 화를 낼 것이라고 농담한다.
   2. 먼저 에이전트와 기능 아이디어를 논의하고, 만들고, 스크린샷을 찍고, 발표자가 직접 가지고 놀 수 있게 해야 한다.
   3. 결과가 좋으면 바로 반복 개선할 수 있고, 대부분의 경우 제안한 사람 스스로 무엇이 좋지 않은지 발견해 발표자에게 오지 않게 된다.

9.2. 루프·그래프·워크플로우는 새로운 마법이 아니다

1. 이름은 달라도 구조는 같다

   1. 엔지니어는 직업이 생긴 뒤부터 삶을 편하게 만들기 위해 자동화 시스템을 만들어 왔다.
   2. 이것을 루프라고 부르든 그래프라고 부르든 워크플로우라고 부르든 본질은 같다.

2. 그래프의 최소 정의

   1. 트리거 또는 입력을 받고 무언가를 수행하는 시스템을 설계한다.
   2. 중간에 의사결정이 있다면 그것이 곧 그래프다.
   3. 새로운 마법이 아니라, “빠르게 만들고 빠르게 출시하라”는 세계에서 오래 해 온 자동화를 더 나은 방식으로 표현한 것이다.

9.3. 안정성과 확장성을 검증하는 방법

1. 과거의 실패

   1. 발표자는 한동안 안정성과 확장성을 충분히 챙기지 못했다.
   2. 자신이 집중하지 못했고, 당시 모델들이 테스트를 잘 수행하지 못했기 때문이다.

2. 현재 모델이 달라진 점

   1. 현재 모델은 세션 기억만 제공하는 것이 아니라 오케스트레이션을 학습했다.
   2. 서브 에이전트를 이해하고 적절히 사용할 수 있다.
   3. 컴퓨터 사용(Computer Use)과 브라우저 사용(Browser Use)까지 결합하면 강력한 질의응답·검증 환경이 된다.

3. 12개 서브 에이전트 활용 사례

   1. 발표자는 전날 Codex를 실행하고 12개의 서브 에이전트를 사용했다.
   2. 먼저 프로젝트를 이해하고 기능 단위로 분해했다.
   3. 각 서브 에이전트가 기능의 스트레스 테스트나 코드 리뷰를 수행했다.
   4. 한 세션의 결과를 다른 세션에 전달해 어디에 집중해서 테스트해야 하는지 알려 줬다.
   5. 아직 모든 것을 자동화할 단계는 아니며, 실제 사용감은 직접 몇 번 클릭해 봐야 한다.
   6. 하지만 일반적인 사용자 버그는 프롬프트만으로도 상당히 먼 거리까지 해결할 수 있다.

9.4. AI 시대의 코드 리뷰는 위험 관리다

1. 모든 코드를 읽지 않기로 한 결정

   1. 발표자는 속도를 위해 아주 일찍부터 모든 코드를 읽지 않기로 했다.
   2. 코드 리뷰를 코드의 미학이 아니라 위험 관리(Risk Management)로 본다.

2. 상황별 검토 깊이

   1. 무서운 시스템을 다룰 때는 더 가까이 읽는다.
   2. UI가 보기 좋고 올바르게 작동한다면 그 UI가 어떤 방식으로 구현됐는지 모두 알 필요는 없다고 본다.
   3. 작은 수정이 원래 몇 분 또는 짧은 시간 안에 끝나야 하는데, 드래그 동작 하나를 바꾸는 데 3시간이 걸린다면 뭔가 잘못된 것이므로 자세히 살핀다.
   4. 그 외에는 변경의 크기와 작업에 걸린 시간을 관찰하고 직감을 믿는다.
   5. OpenAI에서 소프트웨어를 만들 때는 모든 코드를 읽지만, 개인 오픈소스 프로젝트에서는 위험 관리의 기준이 다르다고 설명한다.

9.5. 프로토타입에서 첫 10명의 사용자로

1. 만드는 것보다 사용하게 만드는 것이 어렵다

   1. AI 도구 덕분에 주말에도 제품을 만들 수 있다.
   2. 그러나 어려운 부분은 만드는 일이 아니라 사람들이 사용하게 만드는 일이다.

2. 첫 사용자는 창시자 자신

   1. 사용자 1번은 반드시 자신이어야 한다.
   2. 발표자의 사용자 2번부터 20번까지는 모두 친구였다.
   3. 자신이 만드는 것에 흥분하지 못한다면 제품은 의미가 없을 가능성이 높다.

3. 관심의 가치

   1. 지금은 무언가를 너무 빨리 만들 수 있기 때문에 시선(Eyeballs)이 가장 비싼 통화다.
   2. 기술·소프트웨어·사람보다 사람들의 관심을 얻는 일이 더 어려운 문제가 됐다.

9.6. 개인의 짜증과 시장 수요의 균형

1. 두 목표가 자주 겹친다

   1. 자신을 짜증나게 하는 문제를 해결하는 것과 사람들이 원할 기능을 만드는 것은 종종 같은 방향이다.
   2. 발표자는 아직 두 목표의 균형을 완전히 파악하지 못했다고 솔직히 말한다.

2. 엣지 케이스와 흥미의 균형

   1. 소프트웨어에는 언제나 특이한 예외 상황이 있으므로 몇 달 동안 버그만 고칠 수도 있다.
   2. 기능을 계속 추가하면 예외 상황은 더 늘어난다.
   3. 그러나 버그와 예외만 고치면 일에 대한 흥미를 잃는다.
   4. 따라서 문제 해결과 새로운 기능 사이에 건강한 조합이 필요하다.

10. 현장 Q&A: 보안, 인프라, 커뮤니티 방향성

10.1. 다시 한다면 보안 연구자 대응을 바꾸겠다

1. 보안 연구자의 압박

   1. 시간을 되돌릴 수 있다면 보안 연구자들 때문에 덜 스트레스받도록 대응했을 것이라고 말한다.
   2. 연구자들은 보고서를 보내고, 이메일을 보내고, 전화를 걸며 관심을 끌기 위해 가능한 모든 방법을 사용했다.

2. 클라우트와 점수의 유혹

   1. 발표자는 많은 보고서가 제품을 실제로 개선하기보다 연구자가 클라우트(Clout)나 점수를 얻기 위한 것처럼 느껴졌다고 비판한다.
   2. 일부는 실제 테스트 없이 에이전트가 작성한 보고서를 그대로 보냈다.

3. 앞으로의 보안 경계

   1. 프로젝트가 보증하는 부분과 수정하지 않을 부분을 더 명확히 설명했어야 했다.
   2. 모든 문제가 프로젝트의 보안 경계(Security Boundary)에 들어오는 것은 아니므로, 고치지 않는 것이 곧 안전을 포기하는 것은 아니다.
   3. 발표자는 이 세계를 처음 접했기 때문에 대응 방법을 몰랐고, 배우는 데 몇 달과 흰머리를 지불했다고 말한다.

10.2. 오늘날 에이전트 인프라의 가장 큰 병목

1. 병목의 목록

   1. 안정성(Reliability)
   2. 툴링(Tooling)
   3. 메모리의 발전
   4. 컴퓨트(Compute) 관리
   5. 서로 다른 실행 환경 사이의 이동

2. 로컬 테스트가 만드는 병목

   1. 로컬에서 테스트 하나를 실행하면 TSO가 16개 스레드를 만들어 컴퓨터를 병목 상태로 만들 수 있다.
   2. 10개 세션이 동시에 그렇게 실행되면 약 2개가 타임아웃으로 실패할 수 있다.
   3. 실패한 세션을 다시 돌려야 하며, 전체를 관리할 좋은 시스템이 아직 없다.

3. 웹·macOS·개인 파일의 차이

   1. 웹 작업은 클라우드 세션을 쉽게 만들 수 있다.
   2. 하지만 macOS가 필요한 작업에서는 도구의 99%가 제대로 작동하지 않는다.
   3. 자신의 컴퓨터에 있는 다른 파일이 필요한 작업도 같은 문제를 겪는다.
   4. 한 환경에서 다른 환경으로 작업을 문제없이 옮기는 시스템을 아직 제대로 만들지 못했다.

4. 컴퓨터 여러 대를 운용하는 임시방편

   1. 여러 대의 컴퓨터에 화면 공유로 접속해 부하를 분산하고 있다.
   2. 발표자는 이런 방식으로 계속 운영해서는 안 된다고 말한다.
   3. 안정적으로 컴퓨터 여러 대의 플릿(Fleet)을 운용하는 시스템이 필요하다.

10.3. 오픈소스 프로젝트를 한 방향으로 유지하기

1. N+1번째 PR의 유혹

   1. 커뮤니티가 무작위 기능을 추가하는 N+1번째 PR을 보내도 프로젝트가 한 방향을 유지해야 한다.
   2. 발표자는 인기 있는 PR이 프로젝트를 궤도에서 벗어나게 만든다면 거절해야 하지만, 자신이 충분히 거절하지 못했다고 인정한다.

2. vision.mmd

   1. 새로운 오픈소스 프로젝트를 시작할 때 현재 상태와 자신이 보는 미래를 설명하는 vision.mmd 파일을 작성한다.
   2. 그 비전이 틀릴 수 있고 완벽한 과학도 아니지만, 자신이 그 비전을 더 잘 지켜야 한다고 말한다.

3. 기능 하나가 남기는 책임

   1. 멋져 보이는 기능을 추가하고 싶은 유혹은 항상 있다.
   2. 그러나 기능을 병합한다는 것은 필요하지 않은 코드 더미를 떠안는 일이다.
   3. 기능을 작성한 사람이 코드를 완전히 이해하지 못할 수 있고, 발표자 자신도 완전히 이해하지 못할 수 있다.
   4. 그럼에도 병합한 순간 프로젝트는 그 코드에 대한 책임을 져야 한다.

11. 현장 Q&A: 항상 켜진 에이전트와 개인 환경

11.1. 항상 능동적인 에이전트는 기술보다 토큰 문제다

1. 현재도 가능하지만 비싸다

   1. 항상 실행되고 능동적으로 일하는 클로는 기술적으로 지금도 만들 수 있다.
   2. 그러나 현재 구독으로는 토큰이 빠르게 소진되어 멀리 가지 못한다.
   3. 모든 사용자가 그렇게 많은 토큰을 기꺼이 소비하는 것도 아니다.

2. 빈 토큰을 태우지 않는 시스템

   1. 단순히 빈 토큰을 소모하지 않는 시스템을 설계하는 일이 어렵다.
   2. 초기의 하트비트(Heartbeat) 시스템도 너무 정적이고 능동적이지 못했다.
   3. 큰 세션에서 한 시간 뒤 전체를 확인하는 하트비트를 보내면 KV cache가 초기화된 뒤 서버로 약 600,000 토큰을 다시 보내야 한다.
   4. 유용하지 않은 작업에 엄청난 비용을 지불하게 되므로, 컨텍스트 재사용과 능동성의 균형을 최적화해야 한다.

11.2. 발표자의 실제 하드웨어·소프트웨어 구성

1. MacBook과 스튜디오 컴퓨터

   1. 발표자는 MacBook을 사용한다.
   2. 보통 Jump Desktop으로 스튜디오 컴퓨터에 화면 공유해 그 컴퓨터에서 작업한다.
   3. 스튜디오 컴퓨터는 항상 켜져 있어 원하는 프로그램을 빠르게 실행하고, MacBook 배터리를 소모하지 않으며, 노트북을 닫아도 작업이 계속된다.

2. 원격 머신과 에이전트의 마우스

   1. 가끔 VNC로 접속하는 원격 컴퓨터도 몇 대 있다.
   2. Mac 소프트웨어를 많이 사용하기 때문에 에이전트가 화면을 차지하고 클릭하는 능력이 유용하다.
   3. 에이전트에게 개인 컴퓨터를 주면 자신의 작업을 방해하지 않는다.
   4. 같은 컴퓨터에서 작업하면 사람이 마우스 커서를 두고 에이전트와 싸우게 된다.

3. 코드를 읽는가?

   1. 개인 오픈소스에서는 위험 관리의 기준에 따라 코드를 선택적으로 읽는다.
   2. OpenAI에서 소프트웨어를 만들 때는 모든 코드를 검토한다.

12. 현장 Q&A: 다음 창업과 만들고 싶은 제품

12.1. 다음 스타트업을 고르는 기준

1. 자신이 사용하고 싶은 것을 만들어라

   1. 다음 창업 아이디어를 묻자 발표자는 아직 모두에게 말하고 싶지는 않다고 농담한다. 말하면 복제될 수 있기 때문이다.
   2. 가장 중요한 원칙은 자신이 사용하고 싶은 것을 만드는 것이다.
   3. 자신이 쓰고 싶지 않은 제품은 좋은 제품이 되기 어렵다.

2. 개인 브랜드와 가시성

   1. 정보가 넘치는 시대에 가장 어려운 것은 기술, 소프트웨어, 심지어 사람도 아니다.
   2. 가장 어려운 문제는 관심과 안구(Eyeballs)를 확보하는 것이다.
   3. 따라서 개인 브랜드와 가시성을 미리 쌓아 둬야 한다.

3. 어렵고 지루한 문제를 선택하라

   1. 발표자는 다시 창업한다면 “어렵고 지루한(hard and boring)” 범주의 문제를 고를 수도 있다고 말한다.
   2. 그런 문제를 해결하면 그 가치를 알아보고 칭찬할 사람을 찾기 더 쉽다.
   3. 재미있는 문제는 어렵더라도, 누구나 프롬프트로 비슷한 결과를 만들 수 있는 시대에 경쟁이 특히 치열하다.

12.2. 누군가 만들어 줬으면 하는 제품: 좋은 원격 테스트 환경

1. Linux는 쉽고 Mac은 어렵다

   1. Linux 테스트 박스를 구하는 일은 매우 쉽다고 느낀다.
   2. 반면 제대로 작동하는 Mac 테스트 박스를 구하는 것은 터무니없이 어렵다.
   3. Windows용으로 구한 환경도 상당히 짜증난다.

2. 원하는 공급자

   1. 빠르고 저렴하면서 Linux·macOS·Windows를 모두 잘 처리하는 공급자를 아직 찾지 못했다.
   2. 개발 도구 사업은 본질적으로 어렵기 때문에 이 분야가 창업자가 원하는 사업인지는 모르겠지만, 자신은 정말 갖고 싶은 제품이라고 말한다.
   3. 이 답변으로 Q&A를 마치고 청중에게 감사 인사를 전한다.

주요 발언 모음

“제 영감의 원천은 대개 짜증나는 일입니다.”

“모델이 요리하게 두세요. 저는 수만 명의 사람들이 동시에 요리하게 두면 무슨 일이 일어나는지 알아낸 사람입니다.”

“이것이 미래다. 이것이 AGI다.”

“만들 수 있는 모든 것은 포크하거나 복제할 수 있지만, 당신의 이름은 복제할 수 없습니다.”

“정정은 공포심만큼 멀리 퍼지지 않습니다.”

“새 기능은 프롬프트 하나면 됩니다. 진짜 비용은 우리가 기능을 출시한 뒤에 발생합니다.”

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

“하이프는 날씨와 같습니다. 다가오는 것은 볼 수 있지만 통제할 수는 없습니다.”

“재미는 속도입니다.”

“모든 연구소가 당신에게 에이전트를 팔겠지만, OpenClaw는 그에 대한 대안입니다.”

“당신의 에이전트, 당신의 기계, 당신의 삶입니다.”

“재미를 멈추지 마세요. 직감을 믿으세요. 그리고 당신을 짜증나게 하는 것을 고치세요.”

“미래에 살고, 부족한 것을 만들고, 부고가 쓰여도 계속 배송하세요. 그들을 혼란스럽게 만듭니다.”

핵심 데이터 & 수치

• 8개월: OpenClaw가 인간의 시간으로 존재한 기간. 발표자는 AI 시간으로는 약 4년이라고 표현한다.
• 약 1시간: 즉흥적으로 아이디어를 입력한 뒤 WhatsApp relay가 작동하기까지 걸린 시간.
• 약 5초: launch daemon에서 Ctrl+C를 눌렀을 때 프로세스가 다시 시작되기 전 죽어 있던 시간.
• 약 800개: 발표자가 10시간 잠든 뒤 확인한 메시지 수.
• 39년: 한 달 동안 받은 팟캐스트 초대 수가 이전 39년 동안 받은 것보다 많았다는 비교 기준.
• 18,000명 이상: 8개월 동안 이슈 또는 PR을 한 서로 다른 참여자 수.
• 111,000건 이상: 이슈와 풀 리퀘스트의 총합.
• 약 3,000명: 저장소에 커밋을 남긴 사람 수.
• 67,000개: 악의적 스킬 비율을 계산하기 위해 스캔한 전체 항목 수.
• 20% 대 0.3%: 언론이 보도한 악의적 비율과 팀의 실제 계산 결과.
• 약 80명: 발표자가 과거 B2B 회사를 키운 조직 규모.
• 약 9,500개: 한때 늘어난 구성 옵션 수.
• 835,000건: 5월 주간 다운로드 최저치.
• 470만 건: 6월에 사망 선언 이후 기록한 주간 다운로드 최고치.
• 10명: 현재 재단의 급여 직원 수.
• 33,000개: “claw”라는 이름을 포함한 저장소 수.
• 12개: 발표자가 Codex로 프로젝트 이해·기능 분해·스트레스 테스트·코드 리뷰에 활용한 서브 에이전트 수.
• 16개 스레드: 로컬 테스트 하나가 TSO를 통해 생성해 컴퓨터를 병목시킬 수 있는 스레드 수.
• 약 2개: 10개 세션이 동시에 같은 로컬 테스트를 실행할 때 타임아웃으로 실패할 수 있는 세션 수.
• 약 99%: macOS가 필요한 작업에서 제대로 작동하지 않는 도구의 체감 비율.
• 600,000 토큰: 큰 세션에서 KV cache가 초기화된 뒤 하트비트 확인을 위해 다시 전송할 수 있는 토큰 규모.
• 3시간: 간단한 드래그 동작 변경에 이 정도 시간이 걸리면 위험 신호로 보고 코드를 자세히 검토한다.
• 사용자 1번, 친구 2~20번: 제품 검증을 시작한 방식.

결론 및 시사점

1. 개인의 짜증은 제품 아이디어가 될 수 있다: 거대한 시장 분석보다 자신이 매일 겪는 반복적 불편을 먼저 해결하면 진짜 사용감이 나온다. 다만 자신의 문제와 다른 사람의 수요가 만나는 지점을 친구들의 강한 감정적 반응으로 검증해야 한다.
2. 마법은 모델이 아니라 복잡성의 제거에서 나온다: WhatsApp relay가 특별했던 이유는 터미널을 더 잘 쓰게 해서가 아니라 모델 선택, 컨텍스트 크기, 세션 관리 같은 내부 복잡성을 사용자에게서 숨겼기 때문이다.
3. 바이럴 전에 운영 구조를 준비해야 한다: 800개의 메시지, 기자 전화, 개인정보 유출, 수만 명의 기여자는 제품의 성공과 동시에 창업자의 집중력을 파괴할 수 있다. 도움을 요청하고 책임을 분산하는 구조를 미리 설계해야 한다.
4. 보안은 기능과 사용성의 교환을 만든다: 샌드박싱·허용 목록·권한·원자적 기록은 필요하지만, 사용자 설정을 깨뜨리고 느리게 만들 수 있다. 보장하는 보안 경계와 고치지 않을 범위를 명확히 문서화해야 한다.
5. 의존성을 비즈니스 리스크로 계산해야 한다: 특정 모델에 최적화된 하네스는 제공자의 구독 정책 변경 24시간 통보에도 흔들릴 수 있다. 여러 모델과 오픈 웨이트를 실제 품질 수준으로 검증해 두어야 한다.
6. 기능보다 기능 이후의 비용이 크다: 프롬프트 하나로 기능을 추가할 수 있어도 9,500개 구성 옵션과 모든 순열을 테스트해야 한다. 사용자가 있는 소프트웨어에서는 유지보수와 호환성이 혁신 속도만큼 중요하다.
7. 오픈소스에는 비전과 거절이 필요하다: vision.mmd로 방향을 명시하고, 멋져 보이지만 책임질 수 없는 N+1번째 PR을 거절해야 프로젝트의 일관성을 지킬 수 있다.
8. 항상 켜진 에이전트는 토큰 효율 문제다: 주기적 하트비트가 600,000 토큰을 다시 보내는 구조라면 능동성은 비용 폭탄이 된다. KV cache, 메모리, 실행 환경과 컴퓨트 플릿을 함께 설계해야 한다.
9. AI 개발의 코드 리뷰는 위험 기반이어야 한다: 모든 코드를 동일한 깊이로 읽기보다 시스템의 위험도, 변경 규모, 예상 작업 시간, UI 결과를 기준으로 검토 강도를 조정한다.
10. 미래는 에이전트가 사람의 주의를 보존하는 방향이다: 사람이 이슈와 아이디어를 직접 읽느라 분산되지 않도록 에이전트가 구현·스크린샷·테스트·PR까지 진행하고, 사람은 결과를 체험하고 방향을 결정해야 한다.
11. 다음 기회는 어렵고 지루한 인프라에 있다: AI 모델 자체보다 macOS 테스트 환경, 개인 컴퓨터와 클라우드 사이의 이동, 안정적인 컴퓨터 플릿 관리처럼 아직 누구도 빠르고 저렴하게 해결하지 못한 문제가 창업 기회가 될 수 있다.
12. 지속 가능한 창작의 조건은 재미·직감·집중이다: 재미가 사라지면 제품이 업무가 되고 속도가 떨어진다. 자신을 짜증나게 하는 것을 고치고, 개인 브랜드로 관심을 확보하고, 미래에 필요한 것을 계속 배송하는 것이 발표자가 남긴 최종 조언이다.

핵심 요약 (20줄)

1. OpenClaw는 거대한 사업계획이 아니라 휴대폰에서 컴퓨터로 프롬프트를 보내고 싶다는 짜증에서 시작됐다.
2. 발표자는 자신이 사랑한 것은 프로그래밍 자체보다 무언가를 만드는 일이었다고 말한다.
3. 즉흥적으로 만든 WhatsApp relay는 한 시간 만에 Mac과 WhatsApp 사이의 양방향 메시지를 가능하게 했다.
4. 이 경험이 마법처럼 느껴진 이유는 모델·컨텍스트·세션의 복잡성을 사용자에게서 숨겼기 때문이다.
5. 친구들이 놀라움과 두려움을 보이고 아직 쓸 때가 아니라는 말에 화낸 것은 제품 시장 적합성의 신호였다.
6. Discord 지원 요청을 계기로 프로젝트 이름은 Claudius와 Claudebot을 거쳐 OpenClaw가 됐다.
7. launch daemon을 몰라 Ctrl+C 뒤에도 살아난 에이전트가 밤새 답변하면서 약 800개의 메시지와 바이럴을 만들었다.
8. 8개월 만에 18,000명 이상이 이슈나 PR을 열고 거의 3,000명이 저장소에 커밋했다.
9. 폭발적인 관심은 전화번호 유출과 과도한 연락을 동반했고 창시자는 프로젝트를 삭제할 뻔했다.
10. 대형 연구소의 매각 제안을 거절한 이유는 복제할 수 없는 이름과 개인 브랜드, 그리고 오픈소스에 대한 직감이었다.
11. 언론은 악의적인 스킬이 20%라고 보도했지만 67,000개를 스캔한 팀의 계산은 약 0.3%였다.
12. 샌드박싱과 허용 목록 같은 보안 강화는 사용자 설정을 깨뜨리고 속도와 업데이트 편의성을 낮추기도 했다.
13. 기능은 프롬프트 하나로 추가할 수 있지만 출시 뒤 9,500개 구성 옵션과 테스트 조합을 책임져야 한다.
14. OpenClaw는 Codex와 GPT로 만들어졌지만 오랫동안 Opus에 최적화되어 모델 제공자의 구독 중단 통보에 취약했다.
15. 발표자는 의존성 비즈니스 모델이 곧 자신의 비즈니스 모델이라고 강조한다.
16. 재미가 책임감으로 바뀌며 제품 사용을 중단했던 창시자는 비영리 조직과 NVIDIA의 지원으로 만드는 즐거움을 회복했다.
17. 그래프·루프·워크플로우는 이름만 다를 뿐 입력·트리거·결정·행동을 자동화하는 오래된 엔지니어링 패턴이다.
18. 현재 에이전트 테스트는 Codex와 12개 서브 에이전트로 크게 자동화할 수 있지만 사용감 확인을 위한 수동 클릭은 여전히 필요하다.
19. 미래의 OpenClaw는 음성·멀티모달·항상 동기화되는 팀 에이전트이며, 로컬 모델에서는 데이터가 기기를 떠나지 않는 대안이다.
20. 최종 조언은 재미를 잃지 말고 직감을 믿으며, 부족한 것을 만들고, 부고가 나와도 계속 배송하라는 것이다.