🔥이번 Deep Dive에서 다루는 핵심 내용
- 수작업 광고 제작 병목을 찾은 법
- 작은 제품 실패를 API 전환으로 바꾼 법
- 낮은 운영비로 버틴 부트스트랩 구조
- 트위터·프로덕트헌트로 첫 수요를 만든 법
- 고객 대화로 포지셔닝을 다시 잡은 법
Bannerbear는 처음부터 “이미지 생성 API”로 태어난 제품이 아니었어요. Jon Yongfook은 먼저 오픈그래프 이미지 생성기와 Shopify 쪽 실험을 했고, 둘 다 충분한 시장 반응을 만들지 못했어요. 그런데 고객 메일이 반복해서 같은 방향을 가리켰어요. “이걸 다른 용도로 쓸 수 있나요?”, “내 템플릿을 올릴 수 있나요?” 그래서 제품의 중심을 템플릿 몇 개가 아니라 API로 옮겼어요. 2020년 Open Startup List 인터뷰 시점에는 $500 MRR 케이스로 소개됐고, 이후 Hacker News에 공유된 공식 글 제목은 $10K MRR까지의 여정을 다뤘어요. 출처 출처
🧩 오늘 볼 케이스 — Jon Yongfook / Bannerbear
- 무슨 제품인가 — 템플릿 에디터에서 이미지를 설계하고, API로 전자상거래 광고·소셜 이미지·마케팅 이미지를 자동 생성하는 서비스예요. 출처
- 어떻게 돈 버나 — 공개 자료 안에서는 구체적인 플랜 가격보다 “이미지 생성 API를 쓰는 고객에게 자동화 가치를 파는 SaaS”라는 구조가 확인돼요. 2020년 인터뷰는 $500 MRR, 별도 공식 글 제목은 $10K MRR 여정을 가리켜요. 출처 출처
- 어디서 고객을 모으나 — 초반에는 Jon이 쌓아온 트위터 오디언스와 Product Hunt 출시가 컸고, 이후에는 튜토리얼형 콘텐츠 마케팅을 주요 전략으로 잡았어요. 출처
🎙 인터뷰로 뜯어보기
Q. 원래 어떤 일을 하다가 이 사업을 시작했어요?
저는 20년 정도 테크 쪽에서 일했고, 디자이너이자 프로그래머로 살아왔어요. 이전에도 작은 스타트업 몇 개를 만들고 팔아본 경험이 있었지만, Bannerbear는 첫 “오픈 스타트업”이었어요. 출처
Bannerbear에서 잡은 문제는 디자인을 더 많은 사람이 쉽게 쓰게 만드는 거였어요. 디자인을 가르치는 방법도 있고, 더 좋은 디자인 툴을 만드는 방법도 있어요. 그런데 저는 엔지니어 관점에서 “디자인 접근성을 스케일하려면 어떻게 해야 하지?”를 봤어요. 그 답이 이미지 생성 API였어요. 출처
Q. 이 아이디어는 어디서 찾았어요?
전자상거래 일을 할 때 배너 광고를 반복해서 만드는 일이 정말 싫었어요. 마케팅팀은 같은 템플릿을 여러 제품 리스트에 적용하고 싶어 했고, 그때는 그걸 자동화할 쉬운 방법이 없었어요. Bannerbear라면 제품 데이터가 담긴 스프레드시트를 템플릿에 연결해서 이미지를 자동으로 만들 수 있어요. 출처
처음 제품은 지금의 Bannerbear보다 좁았어요. Previewmojo라는 오픈그래프 이미지 생성기였고, 블로그를 스캔해서 오픈그래프 이미지를 만들어주는 방식이었어요. Product Hunt 반응은 나쁘지 않았지만, 시장이 충분하지 않았어요. “블로그 글을 낼 때 몇 분 아껴준다”는 가치 제안은 강하지 않았어요. 출처
Q. 제품도 없을 때 어떻게 먼저 팔 수 있었어요?
이 케이스는 제품 없이 선판매한 사례라기보다, 작은 버전을 빨리 내고 고객 대화로 방향을 바꾼 사례예요. Previewmojo 이후 Shopify 앱도 실험했지만 잘 안 됐어요. 특히 사용자가 사이트에 코드를 추가해야 하는 앱은 Shopify 생태계에서 힘들 수 있다는 걸 배웠어요. 출처
결정적인 신호는 사용자 메일이었어요. 사람들은 “오픈그래프 이미지가 뭔지는 잘 모르겠는데, 이걸 다른 목적의 이미지 생성에 쓸 수 있나요?”라고 물었어요. 또 “내 템플릿을 업로드할 수 있나요?”라는 요구가 반복됐어요. 저는 여기서 제품이 API가 되어야 한다고 봤어요. 그래야 더 많은 사용 사례를 받을 수 있고, 더 높은 가치 문제를 풀 수 있으니까요. 출처
Q. 실제로 돈 버는 구조는 어떻게 만들었어요?
처음부터 복잡한 엔터프라이즈 세일즈로 간 게 아니에요. 제품의 단위가 “템플릿을 설계하고 API로 이미지 변형을 생성하는 일”로 바뀌었어요. 고객 입장에서는 반복 디자인 작업을 줄이는 자동화 도구를 사는 거예요. 전자상거래 광고를 대량으로 만들거나, 소셜 이미지를 자동 생성하거나, 마케팅 운영에 연결하는 구조였어요. 출처
수익 숫자는 시점을 분명히 봐야 해요. Open Startup List 인터뷰는 2020년 4월의 $500 MRR 케이스로 소개돼요. 이후 Hacker News에 잡힌 공식 글 제목은 “My 2 Year Journey to $10K MRR”였어요. 이 글에서 확정적으로 읽을 수 있는 건 “작게 시작한 API 제품이 시간이 지나 $10K MRR 여정으로 이어졌다”는 정도예요. 출처 출처
Q. 고객은 어디서 모았어요?
초반 유입은 거창한 마케팅 시스템이 아니었어요. 이미 몇 년 동안 쌓아온 트위터 오디언스가 있었고, Product Hunt 출시도 몇 번 성공했어요. Jon은 이걸 전략이라기보다 “초기에 알리는 방식”에 가깝다고 봤어요. 출처
그 다음 방향은 콘텐츠였어요. 마케팅 사이트를 튜토리얼형 콘텐츠로 채우려 했어요. API 제품은 고객이 “이걸 내 워크플로에 어떻게 붙이지?”를 이해해야 사요. 그래서 기능 홍보보다 사용법과 노하우를 쌓는 쪽이 맞았어요. 출처
Q. 혼자 운영하려면 무엇을 자동화했어요?
저는 Ruby on Rails를 10년 넘게 써왔고, 익숙한 도구로 만들었어요. 여기서 중요한 건 기술 자랑이 아니에요. 혼자라면 도구 선택이 곧 출시 속도예요. 모르는 스택을 배우느라 시간을 쓰기보다, 이미 손에 익은 도구로 고객이 만질 수 있는 버전을 빨리 내야 해요. 출처
운영 구조도 “내가 모든 템플릿을 만들어주는 서비스”가 아니라, 사용자가 템플릿을 만들고 API로 반복 생성하는 구조로 바뀌었어요. 이전 버전에서는 템플릿을 더 추가하는 일이 관리자 작업이었고 느렸어요. API 전환 후에는 고객이 자기 템플릿과 자기 데이터를 연결하는 방향으로 열렸어요. 출처
Q. 이 모델의 약점은 뭐예요?
첫 번째 약점은 방향 전환 전까지 고객 문제의 크기를 과소평가하기 쉽다는 거예요. Previewmojo는 작동했지만, 고객이 크게 돈 낼 문제는 아니었어요. Shopify 앱도 시장 진입 방식이 맞지 않았어요. 만들 줄 아는 것과 고객이 반복적으로 돈 내는 것은 달라요. 출처
두 번째 약점은 API 제품의 설명 비용이에요. API는 가능성이 넓지만, 고객이 자기 업무에 붙이는 장면을 떠올리지 못하면 구매로 이어지지 않아요. 그래서 튜토리얼형 콘텐츠가 필요해요. “무엇을 할 수 있다”보다 “이 업무를 이렇게 자동화한다”를 보여줘야 해요. 출처
세 번째는 오픈 스타트업 숫자의 착시예요. Jon은 숫자를 공개하는 전통에서 도움을 받았고, 자신도 그 전통을 이어가고 싶었다고 했어요. 다만 초기 숫자는 대부분 사람에게 큰 이야기를 말하지 못할 수도 있다고 봤어요. 숫자 공개만으로 채널이 생기는 게 아니라, 고객에게 쓸모 있는 지식과 사용 사례가 같이 있어야 해요. 출처
🛠 이번 주 바로 실험할 것
- 오늘 바로 베낄 1가지 — 내 제품을 “기능 묶음”이 아니라 반복 업무 하나를 자동화하는 API나 워크플로로 다시 써보세요. Bannerbear는 오픈그래프 이미지 도구에서 “템플릿 + API로 이미지 변형 생성”으로 초점을 바꿨어요. 출처
- 7일 안에 테스트할 1가지 — 사용자가 보낸 질문과 기능 요청을 20개만 모아서, “더 많은 템플릿을 원한다”와 “다른 앱에 연결하고 싶다”처럼 같은 방향으로 묶어보세요. Bannerbear의 API 전환은 바로 그 반복 신호에서 나왔어요. 출처
- 하면 안 되는 실수 1가지 — 작은 실패를 “이 시장은 없다”로 바로 결론 내리지 마세요. Previewmojo와 Shopify 앱은 실패했지만, 그 실패 안에서 더 큰 고객 문제와 더 나은 포지셔닝이 나왔어요. 출처
📎 같이 볼 만한 숫자 / 케이스
- Simple Analytics의 공개 대시보드 루프 — 공개 대시보드를 제품 노출과 신뢰 장치로 쓴 프라이버시 분석 SaaS예요. 출처
- Simple Analytics의 $30K ARR 이정표 — 익숙한 기술과 공개 운영으로 초반 신뢰를 만든 사례예요. 출처
- ShowMRR의 검증 매출 데이터베이스 — Stripe·LemonSqueezy·Polar 연결로 MRR을 검증하는 데이터베이스 모델이에요. 출처
한 줄 결론: 작은 제품이 약할 때는 기능을 더 붙이기보다, 고객이 반복해서 묻는 더 큰 사용 장면으로 제품의 단위를 다시 잡아야 한다.
매일 아침 이런 브리프를 받아보세요
한국 AI 빌더를 위한 일간 브리핑. 무료, 월~금 발행.