Pieter Levels (levels.io)는 대부분의 인디 해커(indie hackers)들에게 설명이 거의 필요 없는 인물입니다. Nomad List, Remote OK, Photo AI를 운영하며 2024년에는 월 최고 매출 420,000달러를 기록했으며, 이 모든 것을 혼자서 운영합니다. 만약 그 이름을 잘 모르더라도, 그가 스트리밍을 통해 실시간으로 제작하며 17일 만에 ARR(연간 반복 매출) 100만 달러를 달성했던 2025년의 AI 코딩 비행 시뮬레이터 이야기는 기억하실지도 모릅니다. 바로 그 사람이 그입니다.

먼저 분명히 밝혀둘 점은, 이것은 회사가 아니라 한 개인이라는 사실입니다. 2014년 이후로 공동 창업자도, 직원도 없었습니다. 그가 외주를 주는 유일한 업무는 고객 지원(customer support)과 서버 모니터링뿐이며, 본인의 설명에 따르면 이는 자금 제약 때문이 아니라 선택의 결과입니다. 월 420,000달러는 연간으로 환산하면 약 500만 달러에 달하며, 이는 보통 수십 명의 인원이 필요한 매출 규모입니다. 그는 또한 X에 대부분의 수치를 게시하는, 가장 저명한 "빌드 인 퍼블릭(build in public)" 인물 중 한 명입니다.

저는 RSS를 통해 그의 블로그 포스트 751개 전체(2008–2026)를 저장했고, AI의 도움을 받아 이를 검토했습니다. 41개의 포스트는 정독하였고, 나머지는 검색 가능한 참조 자료로 처리했습니다. 아래의 모든 수치는 원문 포스트와 대조하여 사람이 직접 확인했습니다. 이 확인 과정은 단순히 형식적인 것이 아니었습니다. AI가 그럴듯하게 들리는 격언을 지어내거나 의역을 직접 인용구처럼 꾸미는 것을 잡아냈으며, 그런 부분들은 원본을 바탕으로 수정되었습니다. 따라서 이 글은 AI가 작성한 글이 아니라, AI를 활용하여 만들고 사람이 검수한 글입니다.

솔직히 말씀드리면, 시작하기 전에는 그가 누구인지 거의 몰랐습니다. 비행 시뮬레이터 이야기에 대해 막연히 알고 있었을 뿐 그 이상은 아니었습니다. 그래서 저는 어떠한 사전 정보 없이, 공개적으로 게시된 내용만을 바탕으로 읽어나갔습니다. 마지막에 제 기억에 남은 것은 "와, 월 42만 달러라니"가 아니라, 실패의 횟수였습니다. 이 보고서는 그가 공개한 성공 사례와 실패 사례, 두 가지 수치 모두에 관한 기록입니다.

성공 수치

잘 알려진 측면부터 시작하겠습니다. 그가 공개적으로 게시한 내용들을 시간 순서대로 나열하면 다음과 같습니다:

기간	수치
2008–2013	첫 수익원: YouTube 음악 채널. 월 약 $8,000로 정점을 찍었으나, 저작권 주장 분쟁이 쌓이면서 월 $500–900로 감소
...

세 번째 행의 $202,785가 마치 아무런 준비 없이 시작된 것처럼 보이지 않도록 의도적으로 처음 두 행을 포함했습니다. 2015년은 프로젝트의 7년 차였으며, 수익이 2년 동안 감소한 직후였습니다. 이것은 즉시 큰 성공을 거둔 사람에 대한 이야기가 아닙니다. 순서대로 읽어보면, 7년이 걸렸고, 한 번의 힘든 시기가 있었으며, 그다음 해에 급성장한 이야기입니다.

두 가지 각주가 있습니다. "$1M까지 17일"은 실제로 수집된 $1M이 아니라 ARR (해당 월의 매출로 암시되는 연간 반복 매출)을 의미합니다. 그리고 40,870줄에 달하는 index.php는 농담이 아닙니다. 그는 프레임워크 없이 순수 PHP (plain PHP)만을 10년 넘게 고수해 온 결과라고 직접 밝히고 있습니다.

포함할 가치가 있는 인프라 수치 하나는 다음과 같습니다: 2026년 기준으로, 그는 연간 $2,932의 비용으로 직접 관리하는 VPS (Virtual Private Server) 인프라를 통해 모든 사이트에서 연간 40억 건의 요청을 처리하고 있습니다. 그의 추산에 따르면, 관리형 클라우드 서비스 (managed cloud services)에서 동일한 설정을 운영할 경우 연간 $338,913가 소요될 것이며, 이는 115배의 차이입니다.

실패 수치

이 부분이 중요한 대목입니다. "내가 만든 모든 프로젝트 목록 (List of all my projects ever)"이라는 제목의 포스트에서, 그는 자신이 만든 총 113개의 모든 프로젝트를 스스로 분류했습니다. 그중 19개는 "실패 (Failed)"로 태그되어 있습니다 (성장하지 못했거나 수익을 내지 못함). 이는 약 17%에 해당합니다.

이를

• Tubelytics (2013–2014) — YouTube 분석 대시보드 (YouTube analytics dashboard). 약 1년 동안 개발되었으며, 인터페이스는 세련되었으나 그의 표현을 빌리자면 "아무도 돈을 내지 않았습니다." 그는 "이 일로 너무 트라우마를 입어서" 다음과 같은 원칙을 세웠다고 말합니다: "고객이 생기기 전까지는 아무것도 만들지 않겠다."
• Uber Clone for Netherlands (2010) — 그와 친구가 자금 조달을 위해 부유한 투자자들에게 피칭(pitch)을 했습니다. 그의 요약에 따르면: "결국 엄청난 시간 낭비로 끝났고, 그들은 누구에게도 투자하지 않았으며 꽤 굴욕적이었습니다." 이것이 벤처 캐피털 (VC) 자금 조달에 대한 그의 불신의 기원으로 보입니다.
• Panda Mix Show (2008–2014) — 그의 첫 번째 성공작인 YouTube 음악 채널입니다. 월 수익 약 8,000달러로 정점을 찍었으나, 저작권 주장 (copyright claim) 처리가 어려워지면서 5,000달러로 감소한 뒤 종료되었습니다. 그는 이 수익 감소가 우울한 시기와 맞물려, 유명한 "12개월 동안 12개의 스타트업 만들기 (12 Startups in 12 Months)" 프로젝트의 **직접적인 트리거 (direct trigger)**가 되었다고 기록했습니다. 그 프로젝트는 여유로운 사이드 실험이 아니었습니다. 본인의 설명에 따르면, 스스로를 움직이게 만들기 위한 방법으로서 힘든 시기에서 비롯된 것이었습니다.
• Hoodmaps (2017–) — 스스로 "실패 (Failed)"라고 태그를 달았지만, 2026년 현재까지도 운영 중입니다. 그가 밝힌 원칙의 생생한 사례입니다: 유지 관리 비용이 거의 제로에 가깝다면, 실패한 프로젝트라도 종료하기보다는 그대로 두는 것입니다.

나머지 약 15개는 제대로 된 사후 분석 (postmortem) 없이 "전혀 궤도에 오르지 못함"과 같은 한 줄 평으로 일축되었습니다. 여기서 언급할 만한 비대칭성이 존재합니다: 제품이 성공적일수록 사후에 더 많은 세부 정보를 제공하며, 실패한 것들은 단 한 문장으로 끝납니다. 스스로 보고한 데이터를 읽을 때는 이러한 편향 (skew)을 반드시 고려해야 합니다.

전이되지 않는 7가지 전제 조건

751개의 포스트를 순서대로 읽다 보면 이 접근 방식이 작동했던 조건들, 즉 이를 모방하기 전에 제거해야 할 요소들도 드러납니다:

1. 300,000명 이상의 X 팔로워, 2013년부터 약 10년에 걸쳐 구축된 배포 채널(distribution channel). "여러 채널에 동시에 출시한다"는 레버리지(leverage)는 이미 이를 보유하고 있다는 전제하에 작동합니다.
2. 2013년 시대의 시장 상황. 그는 사실상 당시에는 경쟁자가 거의 없는 공간이었다고 말했습니다. 지금은 대기업을 포함한 모든 이들이 동일한 영역에서 경쟁하고 있습니다.
3. 동남아시아의 저렴한 생활비가 그의 런웨이(runway) 계산을 뒷받침합니다 (방콕 기준 월 약 240달러, 3,000달러의 저축으로 1년 버티기).
4. 10년간 다듬어온 순수 PHP 실력. "프레임워크가 필요 없다"는 말은 초보자를 위한 조언이 아닙니다. 이는 10년 동안 동일한 패턴을 반복해 온 사람의 최종 단계(endpoint)입니다.
5. 1인 운영에 따른 낮은 리스크. 운영 서버에서 권한을 우회하여 AI 에이전트(AI agents)를 실행하는 것이 가능한 이유는, 그의 위치에서는 실수가 치명적이지 않기 때문이기도 합니다.
6. VC(벤처 캐피털)에 대한 불신은 단 한 번의 나쁜 경험에서 비롯된 일반화일 뿐, 산업 전반에 대한 분석은 아닙니다.
7. AI 제품의 마진은 GPU 가격과 직접적으로 연동됩니다 — 그는 자신의 매출 수치가 공개된 것을 본 공급업체들이 가격을 인상했다고 언급했습니다.

여전히 배울 가치가 있는 것들

위의 모든 요소를 제외하더라도, 어디에서든 인디 개발자(indie developer)가 실제로 적용할 수 있는 몇 가지 요소가 있습니다:

고객이 있다는 것을 알기 전까지는 만들지 마세요. 이 조언은 특히 Tubelytics에서 1년을 허비한 경험에서 나왔기에 무게감이 있습니다. 실무적으로는: 코드를 작성하기 전에 결제 링크와 가입 양식을 먼저 올려두고, 누군가 실제로 지불할 의사가 있는지 먼저 확인하십시오.

유지 비용이 거의 들지 않는다면, 실패한 프로젝트를 폐기하지 마세요. Hoodmaps 패턴입니다. "프로젝트를 종료했는가"가 아니라 "계속 실행하는 데 비용이 드는가"로 "실패"의 정의를 재정립하면, 게임에 계속 머무는 비용을 낮출 수 있습니다.

실패를 셀 수 있게 만들고, 이를 공개하세요. 113개의 프로젝트 중 19개의 "실패 (Failed)" 태그를 스스로 보고하는 사람은 공개적으로 성공한 사람들 사이에서도 드문 사례입니다. 성공담을 쓰는 사람은 아주 많습니다. 하지만 실패의 분모를 공개하는 사람은 훨씬 적으며, 확률에 대해 실제로 이야기하기 위해서는 바로 그것이 필요합니다.

마지막으로 한 가지 더 있습니다. 체계적인 트레이딩 (Systematic trading)에는 잘 알려진 원칙이 있습니다. 그것이 실력인지 운인지 확인하기 전까지는 좋은 트랙 레코드 (Track record)를 믿지 말라는 것입니다. 저는 공개된 수익 수치도 동일한 취급을 받아야 한다고 생각합니다. 월 42만 달러는 스스로 보고한 수치이지, 감사 (Audited)를 거친 재무제표가 아닙니다. 저는 그 수치를 의심하는 것이 아닙니다. 다만 이런 종류의 자료를 읽을 때 올바른 방식은 **공개된 수치는 생존자의 자기 보고 (Survivor's self-report)**라는 전제를 깔고 가는 것이라고 생각합니다. 751개의 포스트를 모두 읽은 것은 부분적으로 저 스스로 그 전제를 확인하기 위한 방법이었습니다.

모든 수치는 그의 개인 블로그인 levels.io에서 가져왔습니다 (구체적인 포스트 제목은 위 본문에 기재되어 있습니다). 수치는 현재 수치가 아니라 각 포스트가 작성된 당시의 가치를 반영합니다.

원문은 Zenn에 일본어로 게시되었습니다: https://zenn.dev/idonthaveapen/articles/levelsio-751posts-19-failures