앱인토스 웨비나 분석: 혼자 만든 미니앱으로 하루 150만 원 매출까지

토스 iOS 개발자 박효준이 본업 외 시간에 앱인토스 미니앱을 만들고 운영하면서, ‘인스타 언팔한 사람 찾기’ 미니앱을 하루 150만 원 이상의 피크 매출까지 성장시킨 과정을 다룬 웨비나다.

표면적으로는 “AI로 혼자 앱을 만들어 돈을 벌었다”는 사례처럼 보이지만, 내용을 뜯어보면 핵심은 AI 코딩보다 플랫폼 유통력 활용, 빠른 출시, 로그 설계, 퍼널 개선, 반복적인 마케팅과 운영 자동화에 있다.

한 문장으로 요약하면: 코드는 AI가 빠르게 만들었지만, 매출은 유저가 어디서 들어오고 어디서 이탈하는지 집요하게 관찰하고 고친 결과였다.

핵심 숫자

중요한 점은 하루 150만 원이 평균 매출이라는 이야기가 아니라 피크 매출 사례라는 것이다. 월 매출 4,500만 원처럼 단순 환산할 근거는 웨비나에 없다.

1. 아이디어를 찾은 방식: 대단한 아이디어보다 ‘비어 있는 수요’

처음부터 ‘인스타 언팔한 사람 찾기’를 만든 것은 아니다. 발표자는 여러 개의 미니앱을 만들어 보면서 모든 앱이 성공하는 것은 아니라는 사실을 경험했다.

그 뒤 접근법을 바꿨다.

1. 일상에서 작은 불편을 찾는다.
2. 화면 한두 개짜리여도 해결 가능하면 만든다.
3. 이미 외부 시장에서 수요가 검증된 기능도 살펴본다.
4. 그 기능이 앱인토스 생태계에 비어 있으면 빠르게 넣어본다.

‘인스타 언팔한 사람 찾기’ 자체는 세상에 없던 아이디어가 아니었다. 외부에는 이미 비슷한 기능이 있었지만 앱인토스 안에는 대중적인 대안이 비어 있었다.

이 사례에서 중요한 것은 독창성이 아니라 플랫폼 안의 빈자리였다.

처음 목표가 DAU 10명이었던 이유

일반 앱스토어에 독립 앱을 내면 신규 앱은 노출을 거의 받지 못한다. 검색이나 유료 마케팅, 외부 바이럴 없이는 하루 한 명을 데려오는 것조차 쉽지 않다는 것이 발표자의 경험이었다.

반면 앱인토스는 토스라는 큰 생태계 안에서 실행되는 미니앱이기 때문에, 플랫폼 내부의 배포 수단을 활용할 여지가 있었다.

그래서 시작부터 거대한 사업을 설계하지 않았다.

“일단 하루 10명이라도 쓰는 앱을 만들자.”

이 작은 목표가 빠른 출시로 이어졌다.

2. MVP는 10시간, 진짜 작업은 출시 이후 시작됐다

‘인스타 언팔한 사람 찾기’의 첫 버전은 순수 작업 시간으로 약 10시간, 날짜로는 약 3일 만에 만들어졌다.

하지만 이후 빌드와 테스트 기록은 약 200회에 달했다.

발표자가 반복적으로 손본 것은 거대한 신규 기능보다 오히려 이런 것들이었다.

• 버튼을 눌렀을 때 다음 단계가 직관적인가
• 문구 하나가 유저에게 충분히 이해되는가
• 중간 과정에서 막히는 지점은 없는가
• 결제 전에 유저가 가치에 도달하는가
• 화면을 실제 휴대폰에서 봤을 때 어색하지 않은가

즉, 첫 버전을 빨리 만드는 능력보다 출시 이후 수백 번 고칠 수 있는 운영 습관이 더 중요했다.

이 웨비나를 관통하는 개발 원칙

최소한의 기능으로 시장에 먼저 내놓고, 유저 반응이 좋으면 그때부터 계속 개선한다.

완벽한 앱을 만든 뒤 공개하는 것이 아니라,

문제 정의 → 최소 기능 → 출시 → 반응 확인 → 개선

의 사이클을 최대한 빨리 반복한다.

3. AI 개발의 본질: ‘코드를 안 짠다’보다 ‘개발 비용을 낮춘다’

발표자는 해당 미니앱을 만들 때 직접 코드를 거의 입력하지 않고, 자연어로 AI에 지시해 개발했다고 설명한다.

주로 사용한 방식은 다음과 같다.

• Claude: 디자인 초안
• Codex: 개발
• 월 AI 비용: 합계 약 5~6만 원
• 앱인토스 MCP: 플랫폼 지식 학습
• TDS(Toss Design System): 토스 스타일의 UI 구성
• PRD: 앱의 범위와 목적을 AI에게 전달하는 기준 문서

툴 조합 자체는 정답이 아니라고 강조한다. 어떤 모델을 디자인에 쓰고 어떤 모델을 개발에 쓸지는 취향과 작업 방식에 따라 바뀔 수 있다.

핵심은 AI 모델 선택이 아니라 작업의 구조화다.

PRD를 AI의 장기 기억처럼 활용

여러 앱을 동시에 만들면 매번 “앱인토스가 무엇인지”, “이 앱의 목적이 무엇인지”를 처음부터 설명하는 것은 비효율적이다.

그래서 공통 지식을 별도 문서로 관리하고, 각 프로젝트에는 PRD를 둔다.

PRD에는 대략 다음 내용이 들어간다.

• 이 앱이 해결하는 문제
• 주요 사용자
• 핵심 화면
• 현재 구현할 기능
• 다음 버전으로 미룰 기능
• 구현 시 지켜야 할 기준

PRD를 처음부터 정교하게 직접 쓰는 것도 아니다.

발표자는 노트북 마이크를 켜고 약 5분 동안 친구에게 설명하듯 아이디어를 말한 뒤, AI에게 정리시키는 방식을 사용했다.

생각을 완벽하게 정리한 다음 AI를 쓰는 것이 아니라, AI와 대화하면서 기획을 정리한다.

4. AI가 개발해도 QA와 로그는 사람이 책임져야 한다

발표자가 특히 강조한 것은 두 가지다.

4-1. QA

AI가 코드를 만들더라도 최종 검증은 사람이 직접 한다.

• 버튼이 실제로 동작하는가
• 화면 전환이 정상인가
• 결제 성공 후 결과가 제대로 보이는가
• 예외 상황에서 깨지지 않는가

발표자의 표현을 요약하면 다음과 같다.

개발은 AI가 해도 검증은 내가 한다.

4-2. 로그

더 중요한 것은 출시 전부터 로그를 심는 것이다.

예를 들어 다음 행동을 이벤트로 기록한다.

• 화면 진입
• 버튼 클릭
• 단계 이동
• 결제 진입
• 결제 완료
• 특정 화면에서 일정 시간 이상 체류
• 앱을 이탈하기 직전의 마지막 행동

유저는 앱을 끌 때 “여기서 불편해서 나갑니다”라고 알려주지 않는다.

그래서 로그가 유저의 행동을 대신 설명하게 만들어야 한다.

이 로그가 뒤에서 매출 퍼널을 개선하는 가장 중요한 도구가 된다.

5. 초기 유입: 앱인토스의 유통 기능을 거의 전부 사용했다

첫 출시 후 약 보름 동안은 반응이 크지 않았다. 초기 DAU 10명은 주로 지인들에게 앱을 보내면서 만들었다.

그 다음부터 앱인토스의 내부 마케팅 기능을 적극적으로 활용하기 시작한다.

5-1. 광고성 스마트 발송

앱을 한 번도 사용하지 않은 토스 유저에게 미니앱을 알리는 푸시 수단이다.

발표 당시 기준으로 별도의 광고비 없이 사용할 수 있는 기능으로 소개됐다.

신규 유입을 만드는 가장 직접적인 수단이었다.

5-2. 기능성 스마트 발송

이미 앱에서 특정 행동을 한 사용자에게 조건 기반으로 보내는 푸시다.

예를 들어 분석 결과가 준비됐을 때

“분석 결과가 나왔어요.”

라고 알려 다시 앱으로 돌아오게 만든다.

광고성 메시지보다 사용자의 실제 행동과 연결되어 있기 때문에 클릭률이 더 높게 나타났다.

5-3. 프로모션

특정 행동을 완료하면 토스 포인트 같은 보상을 주는 방식이다.

예:

• 분석 결과를 확인하면 100원 지급
• 핵심 기능을 체험하면 포인트 지급

토스 혜택 영역에서 발견될 수 있기 때문에 유입 채널이 된다.

단, 이 방식은 비즈머니가 필요한 구조로 소개된다.

5-4. 공유 리워드

친구에게 앱을 공유하면 유료 기능이나 혜택을 제공한다.

예:

• 친구에게 공유하면 광고 제거
• 공유하면 원래 과금해야 하는 기능 제공

유저 한 명을 단순 소비자가 아니라 다음 사용자를 데려오는 배포 채널로 바꾸는 구조다.

5-5. 공유 미리보기 이미지까지 수정

카카오톡이나 SNS에 링크를 공유했을 때 나타나는 미리보기 이미지도 직접 커스텀했다.

기본 썸네일 대신 앱이 어떤 가치를 주는지 바로 알 수 있는 이미지를 넣었다.

아주 작은 디테일이지만, 이 사례는 이런 세부 요소까지 모두 손봤다는 점이 중요하다.

6. 리뷰도 기다리지 않고 ‘좋은 순간’에 요청했다

해당 앱은 발표 당시 약 7,000개의 리뷰와 4.5 이상의 평점을 확보했다고 설명한다.

처음부터 리뷰가 많았던 것은 아니다.

발표자는 앱인토스에서 제공하는 리뷰 요청 기능을 이용해, 유저가 별도의 리뷰 화면으로 이동하지 않아도 현재 화면에서 바로 별점을 남길 수 있게 했다.

더 중요한 것은 리뷰를 요청하는 타이밍이다.

아무 때나 띄우는 것이 아니라 사용자가 앱의 가치를 경험하고 만족했을 가능성이 높은 순간에 요청했다.

리뷰가 자발적으로 생기기를 기다리는 대신,

좋은 경험 → 즉시 리뷰 요청

이라는 흐름을 설계했다.

7. 외부 마케팅: 잘 만드는 것보다 가능한 모든 곳에 뿌렸다

앱인토스 내부 기능만 사용한 것도 아니다.

발표자는 자신의 여러 미니앱을 모아 소개하는 SNS 계정과 링크 허브를 만들고 다음 채널에 콘텐츠를 배포했다.

• Instagram
• Threads
• TikTok
• X
• 대학생 커뮤니티 에브리타임 등

릴스나 게시물을 아주 높은 완성도로 만드는 데 집착하지 않았다. CapCut 같은 도구로 빠르게 만든 뒤 일단 배포했다.

여기에서도 같은 철학이 반복된다.

잘 만들기 위해 늦추지 말고, 일단 배포해서 반응을 본다.

360만 조회의 바이럴

가장 큰 외부 바이럴은 발표자가 직접 만든 게시물이 아니었다.

다른 X 사용자가 “토스에 이런 기능이 있더라”는 취지로 올린 게시물이 약 360만 조회를 기록했고, 다음 날 앱 검색 유입이 약 2만 명 수준까지 뛰었다고 설명한다.

중요한 점은 바이럴 자체를 통제할 수 없었다는 것이다.

하지만 이미 앱이 존재하고, 공유 링크와 미리보기, 검색 노출, 리뷰, 결제 구조가 준비돼 있었기 때문에 바이럴이 발생했을 때 트래픽을 받아낼 수 있었다.

8. 타깃 마케팅도 거창하지 않았다

대시보드를 보니 핵심 사용자가 10대와 20대에 집중돼 있었다.

그러자 발표자는 단순하게 생각했다.

“10대·20대가 많이 있는 곳에 가서 알리자.”

그래서 대학생이 많은 에브리타임 같은 커뮤니티에도 직접 홍보했다.

이 사례에서 마케팅은 복잡한 브랜드 전략이라기보다,

누가 쓰는지 본다 → 그 사람들이 모인 곳을 찾는다 → 직접 알린다

라는 매우 단순한 구조였다.

9. 매출 구조: 광고 + 990원 결제

‘인스타 언팔한 사람 찾기’는 광고와 인앱 결제를 함께 사용한다.

결제

분석 결과 전체를 보려면 990원을 결제하는 구조다.

처음에는 2,000원 정도를 생각했지만 주변 사람들의 반응이 좋지 않았다.

결국 심리적 부담이 낮은 990원으로 조정했고, 실제 시장 반응을 보면서 가격을 맞춰갔다.

가격을 이론적으로 계산했다기보다 사용자 피드백으로 테스트했다.

결과 일부만 먼저 보여주기

예를 들어 결과가 100명이라면 전부 잠그는 대신 일부를 먼저 보여준다.

사용자가 결과의 존재와 가치를 확인한 뒤,

“나머지도 보고 싶으면 결제하세요.”

라는 구조로 만든다.

결제 전에 가치를 전혀 보여주지 않는 방식보다 호기심과 신뢰를 동시에 만들 수 있다.

단일 결제와 구독 등 여러 선택지

사용자에게 한 가지 결제 방식만 제시하지 않고, 앱의 성격에 따라 단일 결제와 정기 구독 같은 선택지를 줄 수 있다고 설명한다.

무료 체험, 첫 결제 할인, 재구독 할인 등 심리적 진입장벽을 낮추는 기능도 활용 가능하다고 소개한다.

10. 광고는 eCPM보다 사용자 경험과 보상의 납득 가능성이 먼저다

발표자의 앱에서 관찰한 예시로,

• 배너 계열 광고: eCPM 약 2,000원 이상
• 리워드 광고: eCPM 약 3만 원 수준

이라고 설명한다.

이 숫자는 앱, 기간, 광고 지면, 사용자 등에 따라 크게 변하므로 일반화할 수 없다.

처음에는 사용자 경험을 해치지 않기 위해 비교적 짧은 광고를 사용했지만, 실험 결과 사용자가 보상에 충분히 납득하면 더 긴 리워드 광고도 끝까지 본다는 사실을 확인했다.

그래서 최종적으로 더 높은 eCPM을 제공하는 리워드 광고를 활용했다.

핵심은 단순히 “단가가 높은 광고를 넣자”가 아니다.

사용자가 30초를 써도 얻는 가치가 충분하다고 느끼는 위치에 광고를 배치해야 한다.

11. 매출을 만든 결정적 부분: 퍼널에서 가장 큰 이탈 하나를 잡았다

이 앱의 사용 과정은 꽤 번거롭다.

1. 토스에서 미니앱 실행
2. Instagram으로 이동
3. Instagram에서 자신의 팔로워 데이터를 요청
4. 약 10~15분 대기
5. 이메일로 파일 수신
6. 다시 토스 미니앱으로 돌아옴
7. 파일 업로드
8. 분석 결과 확인
9. 결제

문제는 4번이었다.

Instagram이 데이터를 준비하는 10~15분 동안 사용자가 앱을 잊어버렸다.

로그를 보니 바로 이 구간에서 대규모 이탈이 발생했다.

해결: 15분 뒤 기능성 푸시

사용자에게 동의를 받은 뒤,

“15분 뒤에 알려드릴게요.”

라는 푸시를 예약했다.

결과는 강했다.

• 약 3만 명에게 발송
• 1만 명 이상이 다시 앱으로 복귀
• 클릭률 약 40%

발표자는 이 변경 이후 퍼널 지표가 눈에 띄게 개선됐다고 설명한다.

여기서 중요한 것은 푸시 자체가 아니다.

로그로 문제를 발견했고, 가장 큰 이탈 원인에 정확히 기능을 하나 추가했다는 점이다.

12. 결과 화면에 도달한 사용자 중 약 23%가 결제했다

발표자가 로그를 통해 확인한 중요한 숫자가 있다.

결과 화면까지 도달한 유저 가운데 약 23%가 결제로 전환됐다.

이 숫자를 본 순간 전략이 명확해졌다.

결제 버튼 디자인을 계속 바꾸는 것보다,

더 많은 사용자를 결과 화면까지 데려가는 것이 매출에 직접적으로 연결된다.

즉,

유입 증가 → 퍼널 이탈 감소 → 결과 도달 증가 → 결제 증가

라는 구조를 데이터로 확인한 것이다.

이 사고방식이 하루 피크 매출을 만든 핵심에 가깝다.

13. 일회성 앱을 반복 사용 앱으로 바꾸기

‘누가 나를 언팔했는지’는 한 번 확인하면 끝날 수 있는 기능이다.

발표자도 이 문제를 인식했다.

주간 리텐션 푸시

다음 주 토요일 오전처럼 사용자가 다시 확인할 법한 시점에

“이번 주 팔로우 변화를 확인해 보세요.”

라는 기능성 알림을 보냈다.

발표에서 제시된 수치는 다음과 같다.

• 약 5만 명 발송
• 약 3만 명 클릭
• 클릭률 약 60%

과거 변화 기록 기능

사용자 리뷰와 문의를 보니 단순히 ‘현재 언팔 목록’만 원하는 것이 아니었다.

사용자들은 이런 것도 알고 싶어 했다.

• 지난번과 비교해 누가 사라졌는가
• 언제 변화가 생겼는가
• 새롭게 팔로우한 사람은 누구인가
• 기간별 변화는 어떤가

그래서 변화 기록 기능을 추가했다.

일회성 도구를 주기적으로 확인할 이유가 있는 제품으로 바꾸는 과정이다.

14. 8개 앱을 혼자 운영한 방법: 공통화, 문서화, 자동화

발표 당시 운영 중인 미니앱은 8개였고 9번째 앱을 준비하고 있었다.

여러 앱을 동시에 운영할 수 있었던 이유를 크게 세 가지로 정리할 수 있다.

14-1. 플랫폼 지식을 공통 문서로 관리

앱인토스의 결제, 광고, 배포, 디자인 시스템 같은 공통 지식을 매번 AI에게 새로 학습시키지 않는다.

한 곳에 정리해 두고 모든 프로젝트가 참조하게 한다.

14-2. 프로젝트 범위는 PRD로 잠근다

AI가 이것저것 추가하다 프로젝트가 커지지 않도록 앱별 PRD로 범위를 명확히 한다.

14-3. 운영은 최대한 자동화한다

앱이 크게 성장했을 때 문의가 시간당 약 50건까지 들어왔다.

문의 내용과 답변이 반복된다는 것을 확인한 뒤, 집에 남는 컴퓨터에서 로컬 AI를 돌려 문의 유형을 분류하고 답변 초안을 자동 생성하는 구조를 만들었다.

최종 발송만 사람이 확인하는 형태다.

이 자동화 덕분에 여러 앱을 동시에 유지할 수 있었다고 설명한다.

이 사례가 실제로 성공한 이유

1. AI가 아니라 ‘출시 단가’가 내려갔다

AI는 성공을 보장하지 않았다.

대신 한 번의 실험을 만드는 비용을 극단적으로 낮췄다.

예전에는 앱 하나를 만들기 위해 여러 직군과 팀이 필요했지만, 이 사례에서는 한 사람이 기획·디자인·개발 대부분을 AI에 위임했다.

그래서 실패해도 다시 만들 수 있었다.

AI의 가장 큰 효과는 정답을 만들어준 것이 아니라, 시행착오 가격을 낮춘 것이다.

2. 독립 앱이 아니라 플랫폼 안에서 시작했다

이 사례는 일반 앱스토어 앱과 동일하게 보면 안 된다.

앱인토스에는 토스 내부에서 사용할 수 있는 다음 유통 수단이 존재했다.

• 스마트 발송
• 기능성 푸시
• 혜택 영역 프로모션
• 공유 리워드
• 토스 계정 기반 접근
• 플랫폼 내부 노출

독립 앱이라면 직접 구축하거나 돈을 내고 확보해야 할 배포 기능을 이미 플랫폼이 제공했다.

따라서 이 사례의 성과를 단순히 “AI로 앱을 만들면 하루 150만 원 벌 수 있다”로 일반화하면 잘못된 해석이다.

오히려 더 정확한 해석은 다음과 같다.

AI로 제작 비용을 낮추고, 이미 유저가 많은 플랫폼에 올라타고, 그 플랫폼의 배포 수단을 끝까지 활용했다.

3. 기능보다 유통과 퍼널에 더 많은 노력을 썼다

MVP 개발은 약 10시간이었다.

반면 출시 후에는 약 200번의 수정, 여러 마케팅 채널, 푸시 실험, 리뷰 요청, 광고 실험, 가격 실험, 리텐션 기능 추가가 이어졌다.

코드를 만드는 데 쓴 시간보다 유저를 데려오고 전환시키는 데 쓴 사고와 반복이 훨씬 컸다.

4. ‘느낌’이 아니라 로그로 다음 작업을 정했다

무엇을 고쳐야 할지 회의로 결정하지 않았다.

퍼널을 보고 가장 많이 떨어지는 지점을 찾았다.

그 이탈의 이유를 해석하고, 기능 하나를 넣은 뒤 지표가 실제로 개선되는지 다시 확인했다.

이 과정이 반복되면서 개발 우선순위가 자연스럽게 정해졌다.

5. 수익 모델과 핵심 가치가 아주 가까웠다

사용자가 원하는 것은 명확하다.

“누가 나를 언팔했는지 알고 싶다.”

그리고 결제는 바로 그 결과를 더 보여주는 곳에 붙어 있다.

서비스의 핵심 가치와 결제 지점 사이가 멀지 않다.

이 때문에 990원이라는 낮은 가격과 결합하면서 충동 구매에 가까운 전환도 가능했을 것으로 해석할 수 있다.

1인 개발자가 벤치마킹할 것

이 사례에서 복제할 것은 ‘인스타 언팔 앱’이 아니라 운영 방식이다.

1. 플랫폼 안의 빈자리를 찾는다

완전히 새로운 문제보다 다음 조건을 찾는 편이 유리하다.

• 이미 다른 시장에서 사람들이 돈을 쓰거나 자주 찾는 기능
• 특정 플랫폼 안에서는 아직 좋은 대안이 없는 기능
• 사용 목적을 한 문장으로 설명할 수 있는 기능
• 첫 버전을 며칠 안에 만들 수 있는 기능

2. 첫 버전은 한 가지 핵심 행동만 완성한다

처음부터 계정 시스템, 커뮤니티, 복잡한 설정, 관리자 기능까지 만들지 않는다.

사용자가 가장 원하는 결과 하나까지 도달하는 경로를 먼저 만든다.

3. 코딩보다 먼저 이벤트 로그를 설계한다

출시 전에 다음 이벤트는 최소한 정의하는 것이 좋다.

• 진입
• 핵심 기능 시작
• 주요 단계별 통과
• 핵심 결과 도달
• 광고 노출·완료
• 결제 화면 진입
• 결제 성공
• 공유
• 재방문

앱이 뜬 뒤에 로그를 넣으려 하면 가장 중요한 초기 데이터를 잃는다.

4. 유입 채널을 하나만 믿지 않는다

플랫폼 내부 유입과 외부 유입을 동시에 돌린다.

• 플랫폼 푸시
• 추천·혜택 영역
• 공유
• 리뷰
• 커뮤니티
• SNS
• 검색

한 채널이 막혀도 다른 채널이 살아 있는 구조를 만든다.

5. 퍼널의 가장 큰 구멍 하나만 먼저 막는다

전체 UX를 한 번에 뜯어고치지 않는다.

가장 많이 이탈하는 한 구간을 찾고, 그곳만 고친 뒤 지표를 다시 본다.

6. 가격도 기능처럼 실험한다

처음 정한 가격을 정답으로 생각하지 않는다.

사용자 인터뷰, 결제 전환, 환불·이탈 등을 보면서 조정한다.

7. 일회성 도구라면 ‘다시 올 이유’를 만든다

• 변화 기록
• 주간 리포트
• 상태 업데이트
• 히스토리
• 비교
• 리마인더

같은 장치를 통해 반복 사용 이유를 추가할 수 있다.

8. 반복 업무가 세 번 이상 보이면 자동화 후보로 본다

여러 앱을 운영하려면 코드보다 운영 자동화가 더 중요해진다.

• 고객 문의
• 리뷰 분류
• 공통 문서
• 배포 체크리스트
• 지표 리포트
• 마케팅 소재 재활용

같은 반복 작업을 줄여야 앱 개수를 늘려도 운영 비용이 폭증하지 않는다.

벤치마킹하면 안 되는 것

1. 하루 150만 원을 평균 수익으로 해석하기

웨비나는 피크 하루 매출을 중심으로 소개한다.

전체 기간의 평균 매출, 월 순이익, 세금, 플랫폼 수수료, 프로모션 비용, 환불 등을 포함한 손익계산서는 공개되지 않았다.

따라서 이 숫자만으로 월 수익성을 추정해서는 안 된다.

2. 990원이 모든 앱의 정답이라고 생각하기

990원이 효과적이었던 것은 이 앱의 사용 동기, 결과의 즉시성, 호기심, 낮은 심리적 부담이 결합했기 때문이다.

다른 서비스에서는 전혀 다른 가격이 맞을 수 있다.

3. 리워드 광고 eCPM을 그대로 기대하기

발표자가 보여준 광고 단가는 특정 앱과 시점의 사례다.

광고 단가는 기간, 유저, 광고 수요, 지면에 따라 달라진다.

4. X 바이럴을 재현 가능한 전략으로 보기

360만 조회 바이럴은 제3자가 자발적으로 올린 게시물에서 발생했다.

바이럴 자체는 통제하기 어렵다.

재현 가능한 부분은 바이럴이 왔을 때 받을 준비를 해두는 것이다.

5. 앱인토스의 유통 우위를 일반 앱에 그대로 적용하기

이 사례의 가장 큰 구조적 장점은 토스 플랫폼 내부의 배포 기능이다.

독립 앱에서는 같은 유입을 만들기 위해 ASO, 광고비, 콘텐츠, 크리에이터 협업 등이 추가로 필요할 수 있다.

이 사례의 진짜 공식

이 웨비나를 하나의 공식으로 압축하면 다음과 같다.

작은 문제 → 10시간 수준의 MVP → 플랫폼에 빠른 출시 → 초기 유입 확보 → 로그로 퍼널 측정 → 가장 큰 이탈 지점 수정 → 결제와 광고 실험 → 리텐션 기능 추가 → 외부 바이럴 → 운영 자동화 → 다음 앱 반복

하루 150만 원이라는 숫자는 마지막 결과일 뿐이다.

실제로 재현 가능한 부분은 그 앞의 사이클이다.

빠르게 만든 것보다 빠르게 배우고, 빠르게 고친 것이 더 중요했다.

그리고 AI 시대의 1인 개발에서 경쟁력은 단순 코딩 속도보다 점점 다음 영역으로 이동하고 있다.

• 어떤 문제를 고를 것인가
• 어디에 출시할 것인가
• 어떻게 첫 유저를 데려올 것인가
• 무엇을 측정할 것인가
• 어디에서 이탈하는가
• 어떤 순간에 돈을 받을 것인가
• 어떻게 다시 오게 할 것인가
• 운영을 어디까지 자동화할 것인가

이 사례는 ‘혼자서 앱을 만들 수 있는 시대’보다 한 단계 더 나아가, 한 사람이 작은 제품 회사를 운영할 수 있는 방식을 보여준 사례에 가깝다.