Photopea — 무료·무설치·PSD 호환을 14년 복리로 쌓아 연매출 300만 달러에 도달한 솔로 앱
이번 사례는 Photopea다. 최근 사례였던 PEAK, Tiny Glade, Animal Well, Against the Storm, Dorfromantik, Stacklands, Schedule I 등과 겹치지 않으면서, 게임이 아닌 초소형 웹앱이 어떻게 거대한 기존 시장에서 살아남았는지 보여주는 사례다.
Photopea는 Ivan Kutskir가 2012년 학생 시절 시작한 브라우저 기반 이미지 편집기다. 2026년 3월 Ivan은 Photopea가 2025년 한 해 3억 5천만 회 사용됐고 10억 개의 파일이 열렸다고 밝혔다. 최신 공개 자료에서도 핵심 개발자는 여전히 사실상 한 명이며, 일부 PeaDrive·필터 기능 등에 외부 기여가 있었던 정도다. 2024년 매출은 Ivan의 설명을 바탕으로 한 Indie Hackers 인터뷰에서 300만 달러로 공개됐고, 매출의 약 90%가 광고였다. 2026년에도 Ivan은 광고가 소득의 90%라고 다시 확인했다. (Reddit AMA, 2026-03-18 , Indie Hackers, 2025-05-09 )
이 사례의 핵심은 “Photoshop을 무료로 복제했다”가 아니다. 더 정확하게는 다음 네 가지를 한 제품에 묶었다.
설치 없음 + 계정 없이 즉시 사용 + Photoshop 사용자가 이미 아는 UX + PSD를 포함한 광범위한 파일 호환성
그리고 기술적으로는 편집 연산 대부분을 서버가 아니라 사용자의 CPU/GPU에서 실행하도록 만들었다. 이 구조 때문에 사용자 수가 커져도 서버비가 사용량에 비례해 폭증하지 않았고, 무료 사용자를 대규모로 수용할 수 있었다. 공식 사이트도 파일이 서버로 업로드되지 않으며 작업이 기기 안에서 수행된다고 명시한다. (Photopea 공식 사이트, 2026년 확인 , Photopea Learn, 2026년 확인 )
1. 핵심 공개 지표
| 시점 | 공개 지표·사건 | 출처 성격 |
|---|---|---|
| 2012 | 학생 시절 PSD 웹 뷰어 프로젝트 시작 | 창업자 직접 회고 |
| 2013 | 첫 공개 버전 출시 | 창업자 직접 회고 |
| 초기 버전 | 현재 기능의 약 1%, 저장 기능도 없었음 | 2025 인터뷰 |
| 2016 | 대학 졸업 후 Photopea 풀타임 전환 | 창업자 직접 회고 |
| 2016-09 | Premium 도입, 당시 $5/월, 핵심 기능 차이는 거의 없음 | 공식 블로그 |
| 2017 | 일 방문자 약 5,000명 시점에 광고 수익화 시작 | 2025 인터뷰 |
| 2018-11 | 월 방문자 약 150만 명 | 창업자 Reddit AMA |
| 2018 | 첫 7,000시간 동안 사실상 매출 0이었다고 회고 | 창업자 Reddit AMA |
| 2019-07 | 6월 방문자 약 300만 명 | 창업자 Reddit AMA |
| 2019 | 광고 사업자 교체 후 소득이 전년 대비 크게 증가, 38개 언어를 사용자들이 번역 | 창업자 Reddit AMA |
| 2020-08 | 7월 방문자 약 700만 명 | 창업자 Reddit AMA |
| 2020 | GitHub에서 해결한 이슈가 2,300건에 도달했다고 공개 | 창업자 Reddit AMA |
| 2021 전체 | 1억 2천만 회 사용, 2천만 시간 사용, 5억 개 파일 오픈 | 2022 창업자 AMA |
| 2024 | 약 일 100만 명 사용, 연매출 $3M | 2025 Indie Hackers |
| 2024 | 매출 구성 약 광고 90% / Premium·라이선싱 10% | 2025 Indie Hackers |
| 2024 | 공개한 핵심 웹 비용: 도메인 약 $20/년, 호스팅 약 $600/년 | 2025 Indie Hackers |
| 2025 전체 | 3억 5천만 회 사용, 10억 개 파일 오픈 | 2026 창업자 AMA |
| 2026-03 | 광고가 여전히 소득의 90% | 2026 창업자 AMA |
| 2026-03 | Premium 이용자는 전체의 0.1% 미만이라고 창업자가 설명 | 2026 창업자 AMA |
| 2026-03 | 광고 사용자 1시간당 수익이 대략 $0.02~$0.20, 평균을 약 $0.10 수준으로 설명 | 2026 창업자 AMA |
| 2026-03 | 핵심 개발은 여전히 사실상 1인, 일부 기능만 외부 기여 | 2026 창업자 AMA |
| 현재 | Self-hosted 버전 월 $500~$2,000, 연 단위 선결제 | 공식 API 문서 |
출처: Indie Hackers, 2025-05-09 , Reddit AMA, 2018-11-06 , Reddit AMA, 2019-07-03 , Reddit AMA, 2020-08-12 , Reddit AMA, 2022-01-12 , Reddit AMA, 2026-03-18 , Photopea API , Photopea Premium, 2016-09-17 .
공개되지 않은 수치
최신 2025년 또는 2026년 정확한 연매출, 월간 순수 사용자 수, CAC, LTV, 유료 광고비, 지역별 ARPU, D1/D7/D30 리텐션, 유료 전환 후 유지율, 환불률, 정확한 순이익, 세금·결제수수료·외주비를 포함한 총 OPEX는 공개 자료에서 확인되지 않았다. 따라서 2024년 $3M 이후 매출을 임의로 성장률을 적용해 추정하지 않는다.
또한 2026년 AMA 제목의 “한 달에 3천만 번 사용”은 3천만 명의 월간 사용자라는 뜻이 아니다. 최신 독립적인 MAU 수치는 공개되지 않았다.
2. 창업자 배경: 성공의 시작점은 ‘창업’보다 개인 기술 프로젝트였다
[사실]
Ivan Kutskir는 우크라이나에서 태어나 체코에서 성장했고, 컴퓨터과학을 공부했다. 2012년 학생 시절 “브라우저에서 PSD 파일 구조를 볼 수 있는 간단한 뷰어”를 몇 주 정도 만들어볼 생각으로 프로젝트를 시작했다. 그는 2026년 AMA에서 당시에는 PSD 구조를 무료로 볼 수 있는 웹 도구가 사실상 없었다고 회고했다. (Reddit AMA, 2026-03-18 )
처음부터 “Photoshop 경쟁사를 만들겠다”는 거대한 계획으로 시작한 것도 아니다. 2025년 인터뷰에서 그는 학생 시절 월 약 10시간 정도씩 취미로 계속 개발했고, 2016년 졸업 뒤 풀타임으로 전환했다고 설명했다. (Indie Hackers, 2025-05-09 )
[분석]
여기서 중요한 부분은 “학생이 Adobe를 이겼다”는 서사가 아니다.
더 재현 가능한 구조는:
작은 호환성 문제를 해결한다 → 사용자가 생긴다 → 다음 기능을 한 단계 추가한다 → 다시 공개한다 → 몇 년간 복리로 쌓는다
이다.
초기 질문은 “완전한 이미지 편집기를 어떻게 만들까?”가 아니라:
“PSD 파일을 브라우저에서 열어볼 수 있게 할 수 있는가?”
였다.
제품 범위를 아주 작게 시작했기 때문에 한 명이 시장에 빨리 진입할 수 있었다.
3. ‘첫 출시’는 사실상 MVP조차 아니었다
[사실]
Ivan은 2025년 인터뷰에서 첫 공개 버전이 현재 기능의 약 1% 수준이었고, 심지어 작업을 저장할 수도 없었다고 밝혔다. 그 뒤 최소 월 1회 이상 새 버전을 냈다. (Indie Hackers, 2025-05-09 )
2026년 AMA에서도 그는 최초의 PSD 뷰어가 완성된 뒤 작은 기능을 1주~1개월 단위로 추가했고, 여러 차례 릴리스한 뒤에야 “전체 편집기로 확장해볼 수 있겠다”고 판단했다고 설명했다. (Reddit AMA, 2026-03-18 )
[분석]
이 사례는 “MVP를 빨리 내라”보다 더 극단적이다.
일반적인 MVP:
최소한 핵심 작업은 처음부터 끝까지 완료 가능.
초기 Photopea:
핵심 파일은 열 수 있지만 저장은 못함.
즉 제품이 완전하지 않아도 사용자에게 이미 희소한 가치가 있으면 출시할 수 있다.
이는 특히 다음 유형의 제품에 적용하기 쉽다.
- 파일 뷰어
- 변환기
- 분석 도구
- 개발자 도구
- 호환성 도구
- 데이터 마이그레이션 툴
전체 workflow보다 가장 비싼 한 단계를 먼저 해결하는 방식이다.
4. 제품 thesis: ‘Photoshop보다 새롭다’가 아니라 ‘Photoshop 사용자가 다시 배울 필요가 없다’
[사실]
2026년 AMA에서 Ivan은 Photopea의 UI가 Photoshop과 비슷한 것은 의도적이라고 명확히 말했다. PSD를 편집하는 사용자가 이미 익숙한 개념과 메뉴를 그대로 찾을 수 있도록 하기 위해서였다. (Reddit AMA, 2026-03-18 )
Photopea 공식 사이트는 레이어, 마스크, 블렌딩, PSD 저장·열기뿐 아니라 PNG, JPG, SVG, PDF, AI, HEIC, TIFF, Figma, INDD 등 다양한 형식을 지원한다고 설명한다. (Photopea 공식 사이트 )
[분석]
많은 스타트업은 경쟁자와 달라 보이려고 UX를 새로 만든다.
Photopea는 반대다.
제품의 차별화는 UX 문법이 아니라 접근성·가격·호환성에 둔다.
그래서 기존 Photoshop 사용자의 전환비용을 크게 줄였다.
이 전략은 특히 거대한 incumbent가 있는 시장에서 강하다.
새 사용자에게:
“우리 UX를 배우세요.”
라고 하지 않고,
“이미 알고 있는 UX로 바로 작업하세요.”
라고 말한다.
5. 핵심 포지셔닝: 무료보다 더 중요한 것은 ‘즉시 접근 가능’
공식 사이트 기준 Photopea는 브라우저에서 바로 실행되며 별도 설치가 필요 없다. 계정은 설정 동기화·Premium·PeaDrive 등에 필요하지만 편집 자체에는 필수가 아니다. (Photopea 공식 사이트 , Photopea Accounts API )
[분석]
Photopea의 activation funnel은 일반 SaaS보다 짧다.
일반 SaaS:
검색 → 랜딩페이지 → 가입 → 이메일 인증 → onboarding → 파일 업로드 → 작업
Photopea:
검색 → 브라우저에서 열기 → 파일 드래그 → 작업
여기서 무료는 한 요소일 뿐이다.
더 큰 경쟁력은:
- 설치 없음
- 계정 없음
- 신용카드 없음
- 파일 업로드 대기 없음
- 익숙한 UI
을 동시에 제거한 것이다.
6. 타깃 사용자: 한 시장을 여러 ‘긴급한 작업’으로 쪼갰다
공식적인 세그먼트별 사용자 비중은 공개되지 않았다. 아래는 제품 구조와 기능을 기반으로 한 분석이다.
| 사용자 | 즉시 해결해야 하는 문제 | Photopea의 가치 |
|---|---|---|
| Photoshop이 없는 사용자 | PSD를 열어야 함 | 브라우저에서 즉시 열기 |
| 학생·개인 사용자 | 비용 부담 | 핵심 편집 기능 무료 |
| Linux·Chromebook 사용자 | Adobe 앱 설치 어려움 | OS보다 브라우저 중심 |
| 회사·학교의 제한된 PC | 설치 권한 없음 | 설치 없이 사용 |
| 디자이너·프리랜서 | 클라이언트 PSD 수정 | familiar workflow |
| 개인정보 민감 사용자 | 파일 업로드 불안 | 파일을 기기 안에서 처리 |
| 포맷 변환 사용자 | AI/INDD/Figma/RAW 등을 PSD 등으로 변환 | 광범위한 import/export |
| 웹서비스·기업 | 편집기를 자사 서비스 안에 넣고 싶음 | API·Distributor·Self-hosted |
[분석]
Photopea가 강한 이유는 “전문 포토샵 대안”이라는 거대한 메시지뿐 아니라 수많은 고의도(high-intent) 단기 작업을 잡는다는 점이다.
예:
“PSD 열기”
“Figma를 PSD로 변환”
“INDD 열기”
“HEIC JPG 변환”
“RAW 브라우저에서 열기”
사용자는 장기적으로 Photopea를 채택하려고 검색하지 않아도, 단 한 번의 급한 작업 때문에 진입할 수 있다.
이 단기 utility가 반복되면서 장기 사용자로 전환될 수 있다.
7. 핵심 기술 선택: 서버가 아니라 사용자의 컴퓨터가 계산한다
[사실]
Photopea 공식 문서는 편집 작업이 사용자의 기기에서 실행되며, 파일이 서버에 업로드되지 않는다고 명시한다. 인터넷을 끊은 뒤에도 이미 로드된 Photopea를 계속 사용할 수 있다. (Photopea Learn )
2025년 Ivan은 Photopea의 대부분이 JavaScript와 GPU 계산용 GLSL 코드이며, 웹앱을 로드한 뒤 서버가 필요하지 않다고 설명했다. 계정·PeaDrive 등에 일부 서버 기능이 있지만 대부분 사용자에게는 선택사항이다. (Indie Hackers, 2025-05-09 )
2026년에는 첫 10년 동안 호스팅비가 연 $50 정도였고, 이후 트래픽이 커져 연 $600 플랜으로 바꿨다고 밝혔다. (Reddit AMA, 2026-03-18 )
[분석]
이것이 Photopea의 가장 강력한 operational leverage다.
일반 cloud editor:
사용자 증가 → 업로드 증가 → 저장비 증가 → 서버 연산 증가 → 비용 증가.
Photopea:
사용자 증가 → 대부분의 계산비용을 사용자의 CPU/GPU가 부담.
그래서 무료 사용자 1명이 추가될 때의 marginal infrastructure cost가 매우 낮다.
즉 “무료”가 가능했던 것은 pricing 철학만이 아니라 architecture 덕분이다.
8. Privacy가 비용절감과 동시에 제품가치가 됐다
[사실]
Photopea는 공식적으로 “파일이 기기를 떠나지 않는다”고 안내한다. (Photopea 공식 사이트 )
[분석]
같은 기술 결정이 두 가지 가치를 동시에 만든다.
- 서버비 절감
- 개인정보·보안 우려 감소
보통 비용최적화와 사용자 신뢰는 별개의 목표다.
Photopea에서는:
local-first architecture가 cost moat이면서 trust feature
다.
인디 개발자가 특히 벤치마킹할 가치가 높은 패턴이다.
9. 수익화: 핵심 기능을 막지 않고 ‘무료 사용시간’을 광고로 수익화
[사실]
Ivan은 2017년 일 방문자 약 5,000명일 때 광고를 넣기 시작했다. 2024년 기준 매출의 약 90%가 광고, 10%가 Premium과 licensing에서 나왔다. (Indie Hackers, 2025-05-09 )
2026년에도 구조는 거의 같다. Ivan은 광고를 본 사용자가 Photopea를 1시간 쓸 때 국가에 따라 약 $0.02~$0.20, 평균 개념으로는 약 $0.10 정도를 벌 수 있다고 설명했다. Premium 사용자는 전체의 0.1% 미만이라고 말했다. (Reddit AMA, 2026-03-18 )
공식 튜토리얼에 따르면 광고는 화면 크기에 따라 화면의 약 **5~15%**를 차지한다. (Photopea, “How Photopea displays ads”, 2024-07-08 )
[분석]
Photopea의 free tier는 trial이 아니다.
실제 작업을 끝낼 수 있는 제품이다.
그래서 free user는 “나중에 돈 낼 후보”이기 전에 이미 수익원이다.
일반 freemium:
무료 → 기능 제한 → paid conversion.
Photopea:
무료 → 오래 사용 → 광고수익.
일부 heavy user → 광고 제거 Premium.
일부 기업 → licensing/self-host.
이 구조는 conversion이 0.1% 미만이어도 사업이 성립하게 만든다.
10. Premium은 ‘기능을 인질로 잡는’ 방식보다 불편 제거에 가깝다
[사실]
Photopea Premium은 2016년 처음 출시됐을 때 월 $5였고, 당시에는 사실상 추가 기능이 없이 개발을 지원하는 성격이었다. (Photopea Premium, 2016-09-17 )
2026년 Ivan은 수천 명 정도가 $5를 내고 한 달 Premium을 사용한다고 설명했다. 그는 이를 자동갱신 구독보다 기간제 권한을 한 번 결제하는 방식으로 설명하며, 사용자가 다시 원할 때만 새 결제를 한다고 강조했다. (Reddit AMA, 2026-03-18 )
[분석]
이 monetization boundary도 제품 철학과 맞는다.
무료 사용자는:
편집 자체는 가능.
돈을 내는 사용자는:
광고·일부 제한을 없애고 더 편안하게 사용.
핵심 작업을 막아서 conversion을 강제하기보다 사용량이 많아질수록 광고의 불편이 커지고 자연스럽게 Premium 가치가 커지는 구조다.
11. B2B monetization은 소비자 경험을 망치지 않고 추가됐다
[사실]
Photopea API 문서는 Distributor account와 Self-hosted 버전을 별도로 제공한다. Self-hosted 버전은 월 $500~$2,000 수준이며 1년 선결제, 연 2회의 무료 업데이트를 포함한다. (Photopea API )
[분석]
좋은 수익화 확장이다.
consumer에서 더 많이 받아내기보다:
소비자: 무료+광고 / 저가 Premium
기업: 배포권·white-label·self-host에 높은 가격
으로 지불의사가 다른 세그먼트를 분리했다.
작은 앱이 ARPU를 올릴 때 반드시 일반 사용자 가격부터 올릴 필요는 없다.
12. 출시 전략: 큰 launch가 없었다
[사실]
Ivan은 Photopea에 별도의 “development phase → launch event”가 없었다고 밝혔다. 첫 버전을 거의 즉시 공개하고 계속 월간 이상 빈도로 업데이트했다. 초기에 Google Experiments에 제출했을 때 하루 1020명 정도, 몇몇 블로그에서 다뤘을 때 또 하루 1020명 정도가 유입됐다. (Indie Hackers, 2025-05-09 )
[분석]
Photopea는 Product Hunt형 launch가 아니라 compounding launch다.
출시일 한 번의 spike
대신:
기능 하나 → 새로운 사용사례 → 새로운 검색·언급 → 새 사용자
가 10년 넘게 반복됐다.
특히 utility 제품에서는 launch day보다 “오늘 급하게 필요한 사람”을 매일 잡는 것이 더 중요할 수 있다.
13. 초기 distribution: 광고비보다 word of mouth
[사실]
Ivan은 2025년 인터뷰에서 초반 성장의 상당 부분을 사용자들의 친구 추천과 인터넷 언급으로 설명했다. Hacker News·Reddit 등에 직접 홍보도 시도했지만 self-promotion으로 삭제되는 경우가 많아 초기에는 큰 효과가 없었다고 말했다. 반면 몇 년 뒤 진행한 Reddit AMA는 많은 신규 사용자를 가져왔다고 했다. (Indie Hackers, 2025-05-09 )
2019년 AMA는 실제로 대규모 반응을 얻었고, Ivan은 그 사이 사용자 수가 두 배가 됐다고 당시 공개했다. (Reddit AMA, 2019-07-03 )
[분석]
여기서 중요한 점은 “Reddit 마케팅”이 아니다.
AMAs가 강했던 이유는 이미:
“한 사람이 무료 Photoshop 대안을 만들었다”
는 이야깃거리 자체가 존재했기 때문이다.
제품의 실제 효용과 founder narrative가 콘텐츠가 됐다.
14. SEO는 중요한 결과였지만, 창업자가 말한 인과관계는 단순하지 않다
[사실]
Ivan은 SEO를 위해 사이트 구조와 콘텐츠를 여러 번 바꿨지만 큰 효과를 느끼지 못했다고 밝혔다. Google에서 높은 순위를 얻기까지 수년이 걸렸고, 그 시기는 웹 전체에서 Photopea 언급이 늘어난 흐름과 맞물렸다고 설명했다. (Indie Hackers, 2025-05-09 )
현재 공식 Tutorials에는 “Open INDD files”, “Convert Sketch to PSD”, “Convert HEIC to JPG”, “Bulk Generate Mockups”, “Open RAW Photos”처럼 구체적인 작업 의도를 겨냥한 문서가 다수 존재한다. (Photopea Tutorials )
[분석]
따라서 “SEO를 잘해서 성공했다”라고 말하면 과도하다.
더 설득력 있는 순서는:
실제 utility → 사용자 언급 → backlink·브랜드 검색 → 검색노출 상승 → 더 많은 utility 사용자
이다.
Tutorial 콘텐츠는 이 flywheel을 보조했을 가능성이 높지만, 공개된 channel attribution이 없으므로 정확한 기여율은 추정하지 않는다.
15. 파일 포맷 자체가 acquisition channel이다
[분석]
Photopea의 각 포맷 지원은 단순 기능이 아니라 새로운 entry point다.
예:
- PSD
- Sketch
- Figma
- Affinity Photo
- INDD
- RAW
- HEIC
- AI
각 파일은 사용자가 이미 가지고 있는 문제의 증거다.
파일을 받았다 → 열 수 없다 → 검색한다 → Photopea를 발견한다.
즉 일반적인 SaaS처럼 먼저 category demand를 교육할 필요가 없다.
사용자가 가진 파일 자체가 intent signal이다.
16. 하지만 호환성 기능은 ROI가 크게 다르다
[사실]
2026년 AMA에서 Ivan은 INDD 포맷을 reverse-engineering하는 데 PSD와 AI를 합친 것보다 약 10배 많은 시간이 들었고, 개인적으로는 “구현할 가치가 없었다”고 평가했다. (Reddit AMA, 2026-03-18 )
[분석]
호환성이 성장 엔진이라고 모든 포맷을 지원하면 안 된다.
제품마다:
지원 구현비 / 해당 포맷이 만드는 유입·리텐션
을 비교해야 한다.
Photopea 성공의 표면을 복제해 “파일 형식을 최대한 많이 지원한다”로 가면 작은 팀은 바로 무너질 수 있다.
17. 사용자 커뮤니티가 localization 비용을 대신했다
[사실]
2016년 Photopea 2.0부터 사용자 번역 시스템을 열었다. 공식 블로그는 팀에 번역할 여력이 없다며 사용자들이 함께 번역할 수 있는 도구를 제공했다. (Photopea 2.0, 2016-08-24 )
2019년 Ivan은 Photopea가 38개 언어로 완전히 번역됐고 이를 사용자들이 수행했다고 밝혔다. (Reddit AMA, 2019-07-03 )
[분석]
이것은 단순 비용절감이 아니다.
영어가 약한 지역에서도:
제품을 쓰는 사용자 → 번역 기여 → 같은 언어 사용자의 activation 개선 → 더 많은 사용자
라는 community distribution loop를 만든다.
작은 팀이 글로벌 시장에 들어가는 좋은 방식이다.
18. Support가 community와 product development를 동시에 담당
[사실]
2020년 Ivan은 GitHub에서 해결한 이슈가 2,300건에 도달했다고 밝혔다. 2026년에도 대부분의 버그는 GitHub, 이메일, Reddit, Twitter 등을 통해 사용자에게서 받는다고 설명했다. (Reddit AMA, 2020-08-12 , Reddit AMA, 2026-03-18 )
[분석]
한 명이 PM·QA·support를 따로 운영하기 어렵다.
Photopea에서는 issue tracker가:
- 고객지원
- 버그 DB
- feature request
- regression detection
- public roadmap signal
을 동시에 담당한다.
조직을 만드는 대신 공개 작업흐름을 만든 셈이다.
19. Retention 메커니즘 ①: 사용자가 이미 가진 muscle memory
[분석]
새 도구를 반복 사용하게 만드는 가장 큰 비용 중 하나는 학습이다.
Photopea는 Photoshop 사용자가 알고 있는:
- 메뉴 구조
- layer 개념
- blend mode
- shortcut
- PSD workflow
를 최대한 유지한다.
따라서 리텐션을 위한 별도의 streak·notification이 없어도:
기존 습관이 그대로 Photopea의 습관이 된다.
이것은 “borrowed retention”이라고 볼 수 있다.
20. Retention 메커니즘 ②: 계정이 아니라 파일이 다시 사용자를 데려온다
[분석]
많은 SaaS는 이메일·notification으로 재방문을 만든다.
Photopea에는 더 강한 외부 trigger가 있다.
또 PSD를 받음 → Photopea에 다시 감.
사용자의 업무환경에서 생성되는 파일이 reactivation trigger가 된다.
이 때문에 강한 CRM 시스템이 없어도 재사용이 가능하다.
21. Retention 메커니즘 ③: 웹 배포로 개선 속도를 극단적으로 높임
[사실]
2026년 Ivan은 웹의 장점으로 빠른 업데이트를 들며, 어떤 날은 Photopea를 하루 15번 업데이트하기도 한다고 설명했다. 설치형 앱은 여러 버전이 동시에 남아 bug 대응이 복잡해지는 점을 싫어한다고 말했다. (Reddit AMA, 2026-03-18 )
[분석]
웹앱은 단순 distribution channel이 아니라 development velocity architecture다.
한 명의 개발자에게:
build → app store review → update adoption
과정은 매우 비싸다.
Photopea는:
fix → deploy → 모든 사용자에게 즉시 적용
이 가능하다.
작은 팀에 특히 큰 레버리지다.
22. 성장 속도를 보여주는 가장 좋은 숫자는 매출보다 usage history다
[사실]
- 2018-10: 약 150만 월 방문자
- 2019-06: 약 300만
- 2020-07: 약 700만
- 2021: 1억 2천만 회 사용
- 2024: 약 일 100만 명
- 2025: 3억 5천만 회 사용, 10억 파일 오픈
(2018 AMA , 2019 AMA , 2020 AMA , 2022 AMA , Indie Hackers, 2025 , 2026 AMA )
[분석]
이 곡선은 “한 번 바이럴돼서 끝난 서비스”와 다르다.
Photopea의 moat 중 하나는 기능 개수보다 14년 동안 쌓인 문제 해결 범위와 인지도다.
이 시간은 복제하기 가장 어려운 자산이다.
23. 개발 기간과 팀 규모: ‘1인 성공’의 진짜 비용
[사실]
2018년 Ivan은 수익이 발생하기 전까지 약 7,000시간을 썼다고 밝혔다. 2020년 AMA에서는 당시까지 전체 투입시간을 대략 12,000~20,000시간 정도로 추정했다. (Reddit AMA, 2018-11-06 , Reddit AMA, 2020-08-12 )
2026년에도 Ivan은 보통 혼자 개발한다고 밝혔다. 사람을 채용해본 적은 있지만 자신이 원하는 것을 설명하고 리뷰하는 과정이 오히려 어렵다고 느꼈고, PeaDrive나 일부 필터처럼 특정 부분에는 다른 사람의 기여가 있었다고 설명했다. (Reddit AMA, 2026-03-18 )
[분석]
따라서 “혼자 하면 인건비가 0”은 틀린 설명이다.
Photopea의 가장 큰 초기 투자자산은:
창업자 자신의 수천~수만 시간
이었다.
현금 burn은 작았지만 opportunity cost는 매우 컸다.
24. 운영 레버리지 ①: 사용자 수가 늘어도 서버비가 거의 늘지 않는 구조
[분석]
Photopea를 일반 SaaS처럼 해석하면 극단적으로 높은 효율이 이상해 보인다.
하지만 architecture를 보면 자연스럽다.
서버가 하는 일:
- 정적 앱 전달
- 계정 일부
- PeaDrive 일부
- 결제/라이선스 관련 기능
사용자의 기기가 하는 일:
- 이미지 디코딩
- 레이어 연산
- 렌더링
- 다수의 필터
- 편집 상태
즉 서버 비용을 “사용자 증가율”에서 크게 분리했다.
25. 운영 레버리지 ②: 한 codebase가 거의 모든 OS를 커버
공식 사이트는 데스크톱·노트북·태블릿·폰 등 브라우저가 있는 기기에서 실행할 수 있다고 설명한다. (Photopea Learn )
[분석]
한 명의 개발자가:
- Windows 앱
- macOS 앱
- Linux 앱
- Chromebook 앱
을 별도로 유지했다면 Photopea의 조직구조는 성립하기 어렵다.
브라우저가 cross-platform runtime 역할을 한다.
26. 운영 레버리지 ③: 광고가 free-support 비용을 직접 충당
[분석]
무료 사용자가 많아질수록 support와 개발 요구도 늘어난다.
일반 freemium에서는 free user가 비용만 만들 수 있다.
Photopea는 free user의 사용시간이 광고수익으로 바뀐다.
즉:
free usage → revenue → 개발 지속 → 더 많은 free usage
라는 self-financing loop가 가능하다.
27. Product scope: 모든 경쟁기능을 따라가지는 않는다
[사실]
2026년 Ivan은 Photoshop의 가장 큰 기술적 우위 중 하나로 대용량 파일을 RAM보다 크게 다룰 수 있는 memory model을 들었다. Photopea는 브라우저·기기 RAM 제약을 더 직접적으로 받는다. Adobe처럼 자체 AI 데이터센터와 모델 개발에 큰 자금을 투입할 수도 없다고 말했다. (Reddit AMA, 2026-03-18 )
[분석]
좋은 incumbent challenger는 모든 축에서 경쟁하지 않는다.
Photopea가 선택한 축:
- 가격
- 접근성
- 설치 없음
- 호환성
- 익숙함
- local processing
Photoshop이 강한 축:
- 극대형 파일
- 대규모 R&D
- 독자 AI infrastructure
- 조직·기업 생태계
즉 “Photoshop보다 모든 면에서 낫다”가 아니라 특정 사용자 상황에서 압도적으로 편하다가 포지셔닝이다.
28. 가장 강한 제품 포지셔닝 문장
[분석]
Photopea를 기능 목록으로 설명하면:
브라우저 이미지 에디터, PSD, 레이어, 필터, RAW, AI…
가 된다.
사용자 관점에서는 더 단순하다.
“지금 이 컴퓨터에서 Photoshop 파일을 바로 열고 수정해야 한다.”
Photopea는 그 순간의 friction을 거의 모두 제거한다.
좋은 인디 제품의 wedge는 거대한 category보다 이런 구체적인 순간인 경우가 많다.
29. 대안 가설 A — “Photoshop이 비싸서 성공했다”
[분석]
가격은 분명 강한 요인이다.
하지만 무료 편집기는 Photopea 이전에도 존재했다.
무료만으로는 다음을 설명하기 어렵다.
- PSD fidelity
- Photoshop과 유사한 UX
- 브라우저 실행
- 설치 없음
- 다양한 포맷 변환
- local privacy
따라서 더 좋은 인과 설명은:
무료가 진입장벽을 없앴고, 호환성과 익숙함이 실제 전환비용을 없앴다.
이다.
30. 대안 가설 B — “SEO가 성공을 만들었다”
[분석]
창업자 본인이 SEO 변경은 큰 효과가 없었다고 말했다.
검색 순위가 올라간 것은 수년간 늘어난 언급과 제품 사용의 결과와 함께 발생했다. (Indie Hackers, 2025-05-09 )
따라서 SEO는:
원인 단독
보다:
제품 만족과 word-of-mouth가 검색에서 복리로 재활용되는 채널
에 가깝다.
31. 대안 가설 C — “Reddit 바이럴이 만들었다”
2018~2020 AMA는 매우 큰 관심을 받았다.
[분석]
하지만 AMA 이전에도 이미 수백만 명이 사용했다.
따라서 Reddit은:
PMF 생성기
보다:
이미 흥미로운 founder story와 제품을 증폭하는 amplifier
였다.
32. 대안 가설 D — “무료 광고모델이면 누구나 가능하다”
[분석]
2026년 Premium 비중이 0.1% 미만이라는 점은 오히려 반대 교훈을 준다.
Photopea형 모델은:
전환율이 매우 낮아도 될 만큼 엄청난 무료 사용량
이 있어야 한다.
사용시간이 짧거나 월 방문자가 적은 앱이 같은 광고모델을 복제하면 수익이 거의 나오지 않을 수 있다.
33. 대안 가설 E — “서버비가 싸서 수익성이 좋다”
[분석]
맞지만 결과일 뿐이다.
서버비가 낮은 이유는:
핵심 계산을 클라이언트에서 처리하도록 제품을 설계했기 때문이다.
즉 좋은 unit economics가 pricing 이후에 만들어진 것이 아니라 architecture 단계에서 결정됐다.
34. 대안 가설 F — “Photoshop UI를 비슷하게 만들면 된다”
[분석]
표면 복제다.
익숙한 UI는 onboarding을 줄여준다.
하지만 Photopea에서는 동시에:
- PSD 호환성
- 단축키·개념 호환
- 브라우저 접근성
- 가격
이 맞물린다.
UI만 비슷한 제품은 incumbent switching value를 만들지 못한다.
35. 대안 가설 G — “혼자 개발해서 의사결정이 빨랐다”
[분석]
맞지만 반대 비용도 있다.
Ivan은 팀 관리를 어려워하고 혼자 하는 쪽을 선호한다고 공개적으로 밝혔다. 이는 일반적인 startup optimization이라기보다 founder preference다. (Reddit AMA, 2026-03-18 )
따라서 재현할 것은:
무조건 혼자 일한다.
가 아니라:
조직을 키워야 한다는 관성에 휩쓸리지 않고, 제품 economics가 허용하면 작은 팀 구조를 유지한다.
이다.
36. 실패 위험 ①: 광고와 UX가 구조적으로 충돌
[사실]
2026년 Ivan은 광고 기술 자체가 오래되고 비효율적이며, 특히 오래된 컴퓨터를 쓰는 15~30%의 사용자 경험을 나쁘게 만든다고 말했다. 동시에 광고가 소득의 90%라 쉽게 제거할 수도 없다고 설명했다. (Reddit AMA, 2026-03-18 )
[분석]
Photopea의 가장 큰 monetization strength가 동시에 가장 큰 product debt다.
광고가 돈을 벌어줌
→ 광고가 성능을 낮춤
→ Premium은 이 불편을 제거
→ 그러나 Premium 비율은 매우 낮음.
수익모델과 UX가 완전히 정렬돼 있지 않다.
37. 실패 위험 ②: 브라우저 vendor가 사실상 platform owner
[사실]
2026년 Ivan은 Chrome 계열의 특정 버그 때문에 레이어당 5억 픽셀 수준의 제약이 있고, Safari는 iOS/iPadOS에서 웹사이트에 2GB RAM 제한을 둔다고 불만을 밝혔다. (Reddit AMA, 2026-03-18 )
[분석]
앱스토어 수수료는 피했지만 다른 platform dependency가 생겼다.
- 브라우저 API
- 메모리 정책
- 광고 정책
- WebGL/WebGPU/Vulkan 계열 지원
- 브라우저 버그
을 통제할 수 없다.
38. 실패 위험 ③: Bus factor = 1에 가깝다
[분석]
핵심 code·UX·제품결정이 한 사람에게 집중돼 있다.
장점은:
- 결정속도
- 일관된 taste
- 낮은 coordination cost.
단점은:
- 건강·휴가·사고
- 지식전수 부족
- 대규모 리팩터링
- security response
- support overload
다.
성공이 커질수록 이 리스크의 절대 크기도 커진다.
39. 실패 위험 ④: 광고 차단기·광고 생태계 변화
공식 광고 문서는 ad blocker가 감지되면 Photopea가 광고 수익을 얻지 못한다고 직접 설명한다. (Photopea, 2024-07-08 )
[분석]
매출 90%가 광고인 구조에서는:
- 브라우저 정책
- ad blocker 보급
- 개인정보 규제
- CPM 하락
- 광고 공급자 정책
이 큰 사업 리스크다.
40. 실패 위험 ⑤: massive traffic이 전제인 낮은 paid conversion
[사실]
2026년 Ivan은 Premium을 쓰는 사용자가 전체의 0.1% 미만이라고 밝혔다. (Reddit AMA, 2026-03-18 )
[분석]
이 모델은 많은 스타트업의 일반적인 “2~5% paid conversion”과 전혀 다르다.
Photopea에는 수억 회의 usage가 있기 때문에 가능하다.
따라서 다른 인디 앱이 똑같이 기능을 무료로 풀면:
광고가 충분한가?
free user의 marginal cost가 낮은가?
유입 볼륨이 수익모델과 맞는가?
를 먼저 계산해야 한다.
41. 실패 위험 ⑥: format compatibility가 끝없는 maintenance가 될 수 있음
[분석]
지원 포맷이 많아질수록:
- 오래된 변형
- 버전 차이
- edge case
- font/color profile
- export fidelity
문제가 쌓인다.
INDD 사례처럼 어떤 포맷은 acquisition 가치보다 유지비가 클 수 있다.
42. 실패 위험 ⑦: AI 경쟁은 규모경제가 다르다
[사실]
2026년 Ivan은 Adobe가 자체 데이터센터와 모델에 큰 예산을 쓸 수 있는 반면 자신은 같은 방식으로 경쟁할 수 없으며, Photopea의 AI 기능은 무료·오픈소스 모델을 활용한다고 설명했다. (Reddit AMA, 2026-03-18 )
[분석]
기존 경쟁축에서는 solo architecture가 강점이지만, 대규모 foundation model 경쟁에서는 자본이 중요해진다.
작은 팀은 여기서:
모델 자체
보다:
workflow 통합·UX·compatibility
에 집중하는 편이 현실적이다.
43. 주요 인플렉션 타임라인
| 시기 | 인플렉션 | 의미 |
|---|---|---|
| 2012 | PSD viewer 실험 | 좁은 호환성 문제 선택 |
| 2013 | 저장도 안 되는 초기 공개 | 완성 전 시장진입 |
| 2016 | 졸업·풀타임 | founder commitment 증가 |
| 2016 | Premium 실험 | 수익화 첫 시도 |
| 2017 | 5K daily에서 광고 추가 | 사용량을 revenue로 전환 |
| 2018 | 1.5M monthly visitors | product-market fit 가시화 |
| 2019 | 3M monthly visitors·38개 언어 | community localization |
| 2020 | 7M monthly visitors | 대중적 확산 |
| 2021 | 120M uses·20M hours | usage depth 확인 |
| 2024 | $3M revenue·1M daily users | 1인 사업의 규모 확장 |
| 2025 | 350M uses·1B files | global utility infrastructure 수준 |
| 2026 | 90% ads·<0.1% Premium 재확인 | monetization 구조의 지속성과 위험 동시 확인 |
44. 왜 성공했는가: 가장 설득력 있는 인과관계
[분석]
Photopea의 성공을 한 줄로 “무료 Photoshop”이라고 하면 중요한 연결고리가 빠진다.
더 설득력 있는 경로는 다음과 같다.
2012년 PSD viewer라는 좁은 문제
↓
아주 불완전한 첫 버전을 공개
↓
작은 기능을 매달 추가
↓
Photoshop과 유사한 interaction grammar 유지
↓
사용자가 재학습하지 않아도 됨
↓
PSD·다양한 파일포맷이 검색·추천의 entry point가 됨
↓
브라우저 실행으로 install/signup friction 제거
↓
local compute로 server cost 극소화
↓
무료 사용자를 대규모로 감당 가능
↓
광고가 free usage 자체를 revenue로 전환
↓
사용자 번역·GitHub issues·word of mouth가 작은 팀의 운영능력을 확장
↓
Reddit·웹 언급이 브랜드·검색노출을 강화
↓
2024 $3M revenue
↓
2025 350M uses·1B files
핵심은:
무료 가격정책이 아니라, 무료를 감당할 수 있는 architecture와 무료에서도 돈을 버는 monetization이 같이 있었다.
는 점이다.
45. 운·맥락과 통제 가능한 요소
| 요소 | 통제 가능성 | 해석 |
|---|---|---|
| PSD라는 거대한 기존 표준 | 낮음 | incumbent ecosystem 활용 |
| 2012년 당시 브라우저 편집기 공백 | 낮음 | 시장 timing |
| Photoshop 사용자 기반 | 낮음 | 거대한 addressable market |
| 검색엔진 순위 변화 | 낮음~중간 | 제품 언급의 결과 |
| Reddit AMA 대형 반응 | 낮음 | 외부 증폭 |
| 14년의 시간 | 즉시 재현 불가 | compounding asset |
| 좁은 viewer부터 시작 | 매우 높음 | scope 전략 |
| 불완전한 제품 조기 공개 | 매우 높음 | shipping 전략 |
| 익숙한 incumbent UX 사용 | 높음 | switching friction 감소 |
| core 기능에 signup 요구하지 않기 | 매우 높음 | activation |
| local-first compute | 조건부 높음 | 제품/기술에 따라 적용 |
| free user monetization | 높음 | economics 필요 |
| community translation | 매우 높음 | 운영 |
| 공개 issue tracker | 매우 높음 | support leverage |
| web-based rapid deploy | 높음 | 플랫폼 선택 |
| B2B self-host licensing | 높음 | 세그먼트 확장 |
46. 재현 가능한 요인 vs 재현하기 어려운 요인
| 요소 | 재현성 | 이유 |
|---|---|---|
| 큰 제품을 file viewer 같은 작은 wedge로 쪼개기 | 매우 높음 | 제품설계 원칙 |
| 첫 end-to-end workflow가 완성되기 전에도 utility 공개 | 높음 | utility product에 적합 |
| incumbent의 UX grammar 차용 | 높음 | switching friction 감소 |
| no-signup first value | 매우 높음 | 대부분 웹앱에 적용 가능 |
| client-side compute로 unit economics 개선 | 높음 | 브라우저 API·제품 특성 필요 |
| free user도 직접 수익화 | 조건부 높음 | 트래픽 규모 필요 |
| task-specific tutorial/content 축적 | 매우 높음 | 장기 검색자산 |
| user translation 시스템 | 높음 | global product에 적합 |
| public issue tracker | 매우 높음 | 운영 leverage |
| enterprise self-host upsell | 조건부 높음 | B2B need 필요 |
| 2012 PSD 시장 공백 | 매우 낮음 | timing |
| 14년간 한 제품 집중 | 낮음 | founder temperament |
| 이 정도의 이미지 처리 전문성 | 낮음 | 누적 기술역량 |
| 수억 회 usage | 극히 낮음 | 결과 |
| 대형 Reddit AMA 바이럴 | 낮음 | 외부 반응 |
47. 다른 인디 개발자가 우선 벤치마킹할 항목
| 우선순위 | 항목 | 이유 |
|---|---|---|
| P0 | 제품 전체보다 ‘기존 파일/데이터를 여는 한 기능’부터 시작 | wedge를 작게 만들 수 있음 |
| P0 | signup 없이 첫 결과까지 도달하도록 설계 | activation friction 최소화 |
| P0 | incumbent 사용자가 이미 아는 UX·단축키·개념을 얼마나 재사용할지 결정 | 학습비용 감소 |
| P0 | 서버 연산 중 사용자의 기기로 옮길 수 있는 부분을 찾기 | free-tier economics 개선 |
| P0 | free user 1시간의 실제 비용과 수익 계산 | 무료 전략의 지속가능성 검증 |
| P0 | 1% 기능 버전을 실제로 공개 | sunk cost 감소 |
| P0 | 사용자에게 이미 존재하는 파일·데이터 표준을 acquisition wedge로 사용 | high-intent 유입 |
| P1 | 사용자 issue tracker를 support+roadmap DB로 통합 | 작은 팀 운영 |
| P1 | community translation tooling 공개 | 글로벌 확장 |
| P1 | ‘Open X / Convert X / Fix X’형 task 페이지를 체계적으로 축적 | intent-based distribution |
| P1 | consumer free와 B2B licensing을 분리 | ARPU 확대 |
| P1 | web/PWA로 update latency를 낮추기 | iteration speed |
| P1 | 기능별 구현시간 대비 신규 유입·리텐션을 측정 | compatibility scope 제어 |
| P2 | 광고 의존도를 별도로 스트레스테스트 | platform/CPM risk |
| P2 | bus factor 1 대응 문서화·backup plan | 운영 지속성 |
| P2 | browser/vendor dependency를 quarterly audit | 기술리스크 |
48. 이번 사례에서 바로 적용할 수 있는 실행 아이디어
| 우선순위 | 실험 | 구체적 실행 | 핵심 지표 |
|---|---|---|---|
| P0 | No-Signup First Task Test | A: 가입 후 작업 / B: 즉시 작업 후 저장·동기화 시 가입 | first-success rate |
| P0 | Compatibility Wedge Test | 경쟁제품 파일형식 1개만 완벽히 열거나 변환하는 mini-tool 출시 | organic visits·repeat use |
| P0 | Borrowed UX Test | 기존 제품 사용자 20명에게 설명 없이 prototype 제공 | task completion·time-to-value |
| P0 | Client-Side Cost Shift Test | 서버에서 하는 계산 1개를 WebAssembly/WebGPU/local로 옮김 | cost/task·latency |
| P0 | 1%-Feature Release | 전체 roadmap에서 가장 희소한 기능 1개만 공개 | weekly users·feedback density |
| P0 | Free-User Economics Test | free user 1시간당 infra·support cost와 ads/referral value 계산 | contribution/hour |
| P0 | File-Intent Landing Test | ‘open/convert/edit {format}’ landing 10개 제작 | qualified organic activation |
| P1 | Community Translation Sprint | 번역 UI를 열고 상위 5개 미지원 언어에 volunteer 모집 | translated strings·activation by locale |
| P1 | Public Issue Flywheel | support 문의를 공개 issue tracker로 통합 | duplicate rate·resolution time |
| P1 | Rapid Deploy Week | 웹앱에서 1주간 작은 UX fix를 매일 배포 | bug-close→release latency |
| P1 | Premium-as-Comfort Test | 핵심 기능은 무료 유지, 속도·광고·history 같은 comfort만 paid | usage vs paid conversion |
| P1 | B2B Packaging Test | self-host/white-label mock offer를 기존 power user에게 제안 | qualified leads·WTP |
| P1 | Format ROI Score | 각 import/export 포맷별 dev-hours와 유입·재사용 기여 비교 | activated users/dev-hour |
| P2 | Ad Dependency Stress Test | CPM -30%, adblock +20% 시 현금흐름 시뮬레이션 | revenue resilience |
| P2 | Browser Risk Matrix | Chrome/Safari/Firefox API·RAM·GPU 제약표 작성 | critical dependencies |
| P2 | Bus-Factor Drill | 핵심 운영 문서를 만들고 1주 founder 부재 상황 시뮬레이션 | recovery time |
49. 실행 아이디어 ①: ‘로그인’을 activation 뒤로 밀어본다
Photopea의 핵심 편집은 계정 없이 시작할 수 있다. (Photopea Accounts API )
[분석]
A/B 테스트:
A
랜딩 → 가입 → 파일 업로드 → 작업
B
랜딩 → 파일 열기 → 첫 결과 → 저장/동기화 시 가입
측정:
- 첫 작업 성공률
- 5분 activation
- 가입률
- 재방문률
가입률이 조금 떨어져도 실제 작업 성공이 크게 오르면 B가 더 좋은 funnel일 수 있다.
50. 실행 아이디어 ②: 전체 앱 대신 ‘호환성 utility’ 하나만 먼저 출시
Photopea는 처음부터 full editor가 아니라 PSD viewer였다.
[분석]
예를 들어 경쟁 시장이 프로젝트 관리라면 전체 대안을 만들기 전에:
“Notion export를 완벽히 읽는 viewer”
“Figma 파일의 특정 데이터를 추출”
“Excel의 깨진 파일을 복구”
같은 제품을 먼저 만든다.
측정:
- 검색 유입
- upload/open 성공률
- 재방문
- “다음으로 원하는 기능”
핵심은 기존 사용자가 이미 가지고 있는 artifact를 wedge로 사용하는 것이다.
51. 실행 아이디어 ③: 서버비를 가격 문제가 아니라 product architecture 문제로 본다
[분석]
현재 서버에서 처리하는 기능을 목록화한다.
각 기능마다:
- 브라우저
- WebAssembly
- WebGPU
- 로컬 DB
- 사용자 device storage
로 옮길 수 있는지 평가한다.
한 기능만 옮겨도:
free tier cost ↓
privacy ↑
latency ↓
가 동시에 발생할 수 있다.
Photopea에서 가장 강력한 벤치마크 중 하나다.
52. 실행 아이디어 ④: Premium을 기능 잠금이 아니라 ‘불편 제거’로 테스트
Photopea에서는 핵심 편집 자체를 무료로 제공하면서 광고 제거가 Premium의 가장 이해하기 쉬운 가치다.
[분석]
현재 유료 기능 중 핵심 가치 하나를 무료로 풀고, 대신 다음을 paid 후보로 실험한다.
- 광고 제거
- 긴 history
- larger workspace
- priority processing
- 팀 기능
- self-host
- custom branding
측정:
free activation 증가분 × 장기 monetization
이 기존 paywall revenue 감소분보다 큰지 본다.
53. 실행 아이디어 ⑤: feature backlog 대신 ‘파일/표준 backlog’를 만든다
Photopea의 호환성은 수많은 entry point를 만들었다.
[분석]
타깃 사용자가 주고받는 artifact 20개를 적는다.
예:
- CSV
- Figma
- Sketch
- Excel
- JSON
- Slack export
- Notion export
- Adobe formats
각 artifact에 대해:
사용자 빈도 × 현재 불편 × 구현비용 × 검색 의도
를 점수화한다.
가장 좋은 1개를 지원한다.
54. 실행 아이디어 ⑥: 사용자 번역을 제품기능으로 만든다
Photopea는 번역을 외주 프로젝트가 아니라 사용자 참여 tool로 만들었다. (Photopea 2.0, 2016-08-24 )
[분석]
다음 구조를 만든다.
미번역 문장 → 웹 UI에서 번역 → review → 즉시 제품 반영
그리고 locale별:
- activation
- first-success
- support tickets
변화를 본다.
작은 팀이 글로벌화를 시도할 때 가장 비용효율적인 실험 중 하나다.
55. 실행 아이디어 ⑦: 광고를 넣기 전에 ‘사용시간 경제성’을 계산
Ivan은 평균적으로 광고 사용시간 1시간당 약 $0.10라는 단순 모델을 설명했다. (Reddit AMA, 2026-03-18 )
[분석]
자신의 제품에서도 먼저 계산한다.
예:
월 활성 100,000명 × 평균 20분 × 예상 광고수익/시간
그 값이:
- infra
- support
- 결제수수료
- 개발비
을 감당하는지 본다.
광고는 “사용자가 많으면 언젠가 돈이 된다”가 아니라 engaged hours 사업이다.
56. 실행 아이디어 ⑧: 검색키워드보다 실제 작업문장을 쌓는다
Photopea Tutorials의 강점은 “image editing tips” 같은 넓은 키워드보다 구체적인 작업을 다룬다는 점이다. (Photopea Tutorials )
[분석]
고객지원·검색로그에서 다음 형태의 문장을 100개 수집한다.
“X를 Y로 바꾸고 싶다.”
“X 파일을 열 수 없다.”
“X에서 Y를 제거하고 싶다.”
그중 상위 10개를:
- landing page
- tutorial
- mini-tool
로 만든다.
content marketing이 제품 discovery와 직접 연결된다.
57. 실행 아이디어 ⑨: 기능별 ROI를 ‘dev-hour당 activated user’로 본다
INDD 지원은 Ivan 본인이 구현비가 너무 컸다고 평가한 기능이다.
[분석]
각 큰 기능에:
신규 활성 사용자 + 기존 사용자 재활성 / 개발시간
을 기록한다.
특히 import/export, integration, AI feature는 겉보기 가치와 실제 사용량 차이가 크다.
작은 팀은 “멋진 기능”보다 leverage가 높은 기능을 선택해야 한다.
58. 가장 재현하기 어려운 부분: 14년의 복리
Photopea의 2024 $3M 매출은 첫해 결과가 아니다.
- 2012 시작
- 2013 첫 공개
- 2017 광고 수익화
- 2018 월 1.5M 방문자
- 2020 월 7M 방문자
- 2024 $3M 매출
- 2025 350M uses
로 이어졌다.
[분석]
많은 인디 개발자가 복제할 수 없는 것은 코딩 난이도만이 아니다.
가장 어려운 것은:
같은 문제에 10년 이상 머무르며 작은 개선을 복리로 쌓는 것
이다.
검색랭킹, 브랜드, 파일 호환성, community trust, tutorial corpus 모두 시간이 쌓여 만들어졌다.
59. 가장 복제하면 안 되는 표면: ‘무료 Photoshop을 혼자 만든다’
표면을 따라가면:
거대 incumbent의 기능을 1인으로 복제
- 무료
- 광고
가 된다.
이것은 대부분의 개발자에게 최악의 전략일 수 있다.
[분석]
재현할 구조는 다음이다.
incumbent의 거대한 workflow 중 가장 아픈 한 단계만 고른다.
→ 완전하지 않아도 공개한다.
→ 사용자가 이미 아는 UX를 최대한 재사용한다.
→ 설치·가입·업로드 friction을 제거한다.
→ free user의 marginal cost를 architecture로 낮춘다.
→ 사용자 artifact 자체가 acquisition trigger가 되게 한다.
→ community가 번역·QA·support 일부를 확장한다.
→ 기업용 라이선스로 높은 지불의사를 별도 수익화한다.
이것이 Photopea 사례의 본질에 더 가깝다.
60. 최종 결론
Photopea에서 가장 화려한 숫자는 2024년 $3M 매출과 2025년 3억 5천만 회 사용이다. (Indie Hackers, 2025-05-09 , Reddit AMA, 2026-03-18 )
하지만 다른 인디 개발자가 더 주목해야 할 숫자는:
약 7,000시간의 무수익 개발,
첫 버전의 기능 약 1%,
2017년 일 5,000명에서 광고 시작,
Premium 이용자 0.1% 미만,
핵심 개발자 사실상 1명,
호스팅 연 $600 수준의 client-heavy architecture
이다.
이 숫자들을 연결하면 Photopea의 성공은 단순한 가격경쟁이 아니다.
무료 사용자가 수억 회 늘어도 서버비가 비례해 폭증하지 않는 구조를 만들고, 무료 사용자의 시간 자체를 광고로 monetization했다.
사용자는 새 UX를 배우지 않아도 되고, 앱을 설치하지 않아도 되고, 계정을 만들지 않아도 되고, 파일을 외부 서버에 올리지 않아도 된다.
그리고 PSD·AI·INDD·Figma 같은 기존 ecosystem의 artifact가 계속 새로운 사용자를 데려온다.
즉 Photopea의 growth loop는 다음에 가깝다.
기존 파일 때문에 긴급한 문제 발생
→ 검색·추천으로 Photopea 발견
→ 가입·설치 없이 즉시 해결
→ 익숙한 UX 때문에 재사용
→ 광고로 free usage가 수익화
→ 개발자가 기능·호환성 추가
→ 더 많은 작업·파일 형식이 entry point가 됨
→ word of mouth와 검색 인지도 누적
이번 사례에서 다른 인디 개발자가 가장 먼저 물어볼 질문은 세 가지다.
“내가 경쟁하려는 거대한 제품의 전체를 만들지 않고도, 사용자가 오늘 당장 겪는 한 단계만 해결할 수 있는가?”
“사용자가 이미 익숙한 workflow를 유지해서 학습비용을 거의 0으로 만들 수 있는가?”
그리고:
“무료 사용자가 늘어날수록 비용도 같은 비율로 늘어나는 구조인지, 아니면 architecture를 바꿔 marginal cost를 낮출 수 있는가?”
Photopea는 “혼자서 Photoshop을 만든 기적”이라기보다 호환성이라는 작은 wedge에서 시작해, 낮은 activation friction·client-side economics·광고 수익화·14년의 꾸준한 shipping을 결합한 사례로 보는 편이 더 정확하다.
주요 출처 및 게시일
| 게시일 | 출처 | 핵심 정보 |
|---|---|---|
| 2016-08-24 | Photopea 2.0 | localization 시스템·사용자 번역 구조 |
| 2016-09-17 | Photopea Premium | 초기 $5 Premium·초기 수익화 철학 |
| 2018-11-06 | Ivan Kutskir Reddit AMA | 월 1.5M 방문자·7,000시간·1인 개발 |
| 2019-07-03 | Ivan Kutskir Reddit AMA | 월 3M 방문자·38개 사용자 번역 언어·광고수익 개선 |
| 2020-08-12 | Ivan Kutskir Reddit AMA | 월 7M 방문자·GitHub 이슈 2,300건·개발시간 |
| 2022-01-12 | Ivan Kutskir Reddit AMA | 2021년 120M uses·20M hours·500M files |
| 2024-07-08 | How Photopea displays ads | 광고가 차지하는 화면·ad blocker 처리 |
| 2024-04-22 | Photopea 5.6 | 16/32-bit·GPU 가속·당시 138,541 LOC |
| 2025-05-09 | Indie Hackers — Making $3M+ per year with a free product | $3M 2024 revenue·1M daily users·90% ads·$600 hosting·organic growth |
| 2026-03-18 | Ivan Kutskir Reddit AMA | 2025 350M uses·1B files·90% ads·<0.1% Premium·solo operation·browser limits |
| 2026-09 확인 | Photopea 공식 사이트 | local processing·no upload·현재 product positioning·formats |
| 2026-09 확인 | Photopea Learn | 브라우저 실행·offline 가능·파일이 기기를 떠나지 않음 |
| 2026-09 확인 | Photopea API — Accounts | 계정 구조·Premium·Distributor·Self-host $500~$2,000/mo |
| 2026-09 확인 | Photopea Tutorials | task-specific content·file-format utility 사례 |