한 줄 요약

TinyPilot은 어떻게 반복 매출을 늘릴 수 있을까?

하이라이트

• TinyPilot Pro에 정기 구독을 추가하려면 무엇이 필요할지 고민했습니다.
• 개발 환경 관리를 위해 Nix를 더 깊이 탐색해 봤습니다.

목표 달성 평가

매달 초에 이루고 싶은 목표를 정합니다. 이번 달 목표 달성 결과는 다음과 같습니다.

매출 9만 8천 달러 달성

• 결과: 매출이 10% 하락해 8만 4천 달러를 기록
• 평가: C

여러 긍정적인 신규 리뷰가 있었음에도 매출은 하락했습니다.

• RaidOwl
• Home Network Guy (함께 발행된 블로그 글)
• Network Profile
• Botio Studio (중국어)

아마존이 이해하기 어려운 계정 상태 정책으로 저희 상품의 노출 순위를 낮추면서 매출의 상당 부분을 잃었습니다. 현재는 아마존과의 관계가 회복되어 판매가 다시 반등했습니다.

다른 창업자들에게서도 이맘때쯤이면 매년 여름 비수기가 찾아온다는 이야기를 들었습니다. 실제로 TinyPilot 역시 2022년 7월에 매출이 11% 하락한 바 있습니다.

위탁 제조업체로의 생산 전환 일정 준수

• 결과: 일정이 3주 지연됨
• 평가: D

위탁 제조업체의 하위 공급업체들이 전원 어댑터와 USB 케이블 같은 부품 생산에 더 많은 시간이 필요해 제조 일정이 밀렸습니다. 전환 기간 중 재고가 바닥나기 전까지 아직 3주 정도의 여유가 있지만, 상황이 다소 아슬아슬해지고 있습니다.

애초에 잘 설계된 목표는 아니었습니다. 마감일을 제가 정한 것도 아니고 제가 통제할 수 있는 부분도 제한적이기 때문입니다. 제가 할 수 있는 일은 TinyPilot 쪽에서 차질이 생기지 않도록 막고 위탁 제조업체가 일정을 지키도록 하는 정도입니다.

이메일 처리 시간을 전체 업무 시간의 40% 미만으로 유지하기

• 결과: 대부분의 시간을 이메일 처리에 사용함
• 평가: F

결국 예상보다 훨씬 많은 시간을 이메일에 썼습니다. 7월에 휴가로 자리를 비웠는데, 쉬는 동안 얼마나 많은 이메일이 쌓일지 제대로 고려하지 못했습니다.

결국 이번 달은 대부분 이메일에 답하고 팀원들의 작업을 검토하는 데 시간을 보냈습니다.

TinyPilot 주요 지표

매출이 하락했음에도 수익은 여전히 2만~3만 달러 선을 유지하고 있습니다. 다만 이 수치는 다소 부풀려진 측면이 있습니다. 위탁 제조업체로의 전환을 앞두고 자체 생산을 축소하면서 신규 자재 구매를 중단해 비용이 인위적으로 낮아졌기 때문입니다.

새로운 리뷰가 많이 나왔는데도 웹사이트 방문자 수가 줄었다는 점이 의외입니다. 한동안 홈랩 리뷰라는 마케팅 채널은 포화 상태에 이른 것 같으니, 다른 형태의 영업과 마케팅에 집중해야 할 것 같습니다.

TinyPilot은 어떻게 반복 매출을 늘릴 수 있을까?

TinyPilot 매출이 주춤할 때마다 반복 매출에 대한 고민이 깊어집니다. 끊임없이 신규 고객을 찾아다니지 않아도 안정적인 수입이 있다면 얼마나 좋을까 싶습니다.

언젠가 TinyPilot을 원하는 사람 모두가 이미 제품을 갖게 되는 날이 오면 어떻게 해야 할지 두렵기까지 합니다. 그때가 되면 무엇을 해야 할까요?

처음부터 TinyPilot은 반복 매출을 가져가는 구조로 계획했습니다. 고객은 하드웨어를 한 번 구매하고, 이후에는 매년 소프트웨어 라이선스를 갱신하며 지속적인 소프트웨어 개발과 기술 지원을 위한 비용을 부담하는 방식이었습니다.

문제는 지금까지 TinyPilot이 고객으로부터 반복 매출을 실제로 걷을 수 있는 장치를 마련하지 못했다는 점입니다. 3년이 지난 지금도 일부 기업 고객을 제외하면 반복 매출이 거의 없는 상태입니다.

이번 회고에서는 TinyPilot의 반복 매출을 늘릴 수 있는 가능한 경로들을 고민해 보고자 합니다.

TinyPilot Pro 라이선스는 현재 어떻게 동작하는가

2020년에 오리지널 DIY TinyPilot 키트를 출시한 지 몇 주 뒤, 프리미엄 버전 소프트웨어 개발에 착수했습니다.

TinyPilot Pro를 위해 가장 먼저 만들기 시작한 기능 중 하나가 라이선스 검증이었습니다. 유료 소프트웨어를 판매하려면 사용자의 라이선스가 유효한지 확인할 방법이 필요했기 때문입니다.

라이선스 검증 시스템을 설계하기 시작하면서, 창업자로서 다른 여러 책임을 병행하는 상황에서 이 컴포넌트 하나를 만드는 데만 몇 달이 걸리겠다는 걸 깨달았습니다. 라이선스 관리 구현에만 3개월이 걸린다면, 고객이 TinyPilot Pro를 구매할 만한 매력적인 이유가 될 다른 프리미엄 기능들을 구현하는 데도 2개월이 더 필요했습니다.

회사를 시작한 지 불과 몇 달밖에 되지 않은 시점에서, 다음 출시까지 다섯 달을 기다리게 하며 모멘텀을 늦추고 싶지 않았습니다.

Basecamp 블로그에 예전에 본 글이 있는데, 지금은 찾을 수 없는 내용입니다. 자신들의 SaaS 제품을 과금 소프트웨어를 만들기도 전에 판매하기 시작했다는 이야기였습니다. (수정: Nathan Coleman이 찾아주셨습니다. Basecamp의 책 Getting Real에 나오는 내용입니다.) 그들은 소프트웨어 이용료 청구서가 서비스 이용 한 달이 끝난 뒤에 발행된다는 점에 착안해, 첫 판매 이후 한 달 동안 돈을 어떻게 걷을지 고민하면 된다고 판단했다는 것입니다.

저도 비슷한 전략을 택했습니다. 라이선스 강제 수단으로 양심에 맡기는 방식을 택했고, 제대로 된 라이선스 관리 솔루션을 구현할 때까지 1년의 시간이 있다고 생각했습니다.

그런데 3년이 지난 지금도 TinyPilot Pro의 라이선스 강제와 관련해 아무런 진전도 이루지 못했습니다.

최악의 타이밍에 이루어지는 라이선스 강제

저희는 TinyPilot 기기에 12개월간 무료 업데이트가 포함된다고 광고합니다. 감춰진 비밀은, 기기에 TinyPilot Pro를 한 번 설치하면 기기의 웹 인터페이스를 통해 영원히 소프트웨어를 업데이트할 수 있다는 점입니다.

TinyPilot Pro 소프트웨어는 유효한 라이선스와 연결되어 있는지를 추적하지 않습니다. 2020년 8월에 구매한 사용자 중에는 1년짜리 라이선스로 3년째 사용 중인 경우도 있습니다.

대다수 고객은 자신의 라이선스가 만료되었다는 사실조차 모릅니다. TinyPilot이 계속해서 기기에 업데이트를 제공하니 라이선스가 여전히 유효하다고 당연히 생각하기 때문입니다.

고객이 라이선스 만료를 알게 되는 경우도 가끔 있는데, 하필 가장 불편한 타이밍에 알게 됩니다.

TinyPilot은 저장 매체로 microSD 카드를 사용합니다. microSD는 특히 파일 시스템 손상에 취약합니다. microSD의 파일 시스템이 손상되면 유일한 해결책은 TinyPilot Pro 디스크 이미지로 microSD를 다시 플래싱하는 것입니다.

TinyPilot Pro 이미지를 다운로드하려면 고객은 주문 정보를 입력해야 합니다. 이미지를 제공하기 전에 고객의 라이선스가 여전히 유효한지 확인합니다.

고객 입장에서는 라이선스가 만료되었음을 알게 되는 최악의 방식입니다. 파일 시스템이 손상되어 이미 작업이 중단된 상태인데, 문제를 해결하려면 직접 기기 앞으로 가서 microSD를 빼 리플래싱해야 합니다. 그런데 거기에 추가로 돈을 내라고 하는 셈이니 말입니다.

고객이 새 이미지를 구매하고 싶지 않다면, 지원팀에 문의할 경우 예전 이미지에 대한 접근 권한을 제공합니다. 다만 저희가 답변을 드리기까지 최대 하루가 걸릴 수 있어, 그 사이 업무가 막혀 있다면 곤란한 상황이 됩니다.

이 시스템은 저희에게도 좋지 않습니다. 예전 TinyPilot Pro 버전에 대한 요청이 지원 리소스를 소모시키기 때문입니다. 그리고 고객이 새 이미지를 받더라도 기기 내 웹 인터페이스를 통해 계속 소프트웨어를 업데이트할 수 있으므로 다시 ‘무료 업데이트 무한’ 상태로 돌아가게 됩니다.

반복 구독을 할 만한 가치가 있으려면 무엇이 필요한가?

어떤 형태의 라이선스 강제든 비용이 많이 듭니다. 최소한 고객이 라이선스 정보를 입력할 수 있는 기능을 TinyPilot 웹 인터페이스에 추가하고, 인터넷상의 서버가 라이선스에 따라 업데이트 자격 여부를 판단할 수 있도록 해야 합니다.

이는 구현 비용이 많이 듭니다. 몇 주간의 개발 작업이 필요할 뿐 아니라, 주문 정보가 담긴 TinyPilot 이메일을 삭제해 업데이트에 접근할 수 없다는 고객들의 문의가 반드시 쏟아지면서 지원 부담도 커지기 때문입니다.

만약 그 모든 노력을 들였는데 갱신율에 아무런 영향이 없다는 걸 알게 되면 어쩌죠?

라이선스 갱신이 가치가 있으려면 연간 최소 3만 달러의 추가 수익을 창출해야 합니다. 라이선스에 대한 결제 처리 비용이 약 3% 정도 들 것으로 예상하므로, 라이선스 갱신 한 건당 TinyPilot이 얻는 순수익은 약 77달러입니다.

연간 3만 달러라는 목표를 달성하려면 매년 최소 390명의 고객이 라이선스를 갱신해야 합니다(390 x $77 = $30k).

TinyPilot은 2020년 출시 이후 총 약 5,000대의 기기를 판매했습니다. 현재는 연간 약 2,700대의 신규 기기를 판매하고 있습니다. 390명의 유료 구독자를 확보한다는 것은 기존 사용자 중 불과 7.8%를 설득해 지속 업데이트에 비용을 지불하도록 만드는 것을 의미하므로, 충분히 달성 가능해 보입니다.

고객의 라이선스 갱신 의향을 어떻게 테스트할 수 있을까?

그렇다면 기존 고객 중 7.8%를 설득해야 하는데, 본격적인 라이선스 관리 시스템을 구축하는 데 투자하지 않고도 그 수치가 달성 가능한지 어떻게 알 수 있을까요?

강제 공장 초기화

올해 초, TinyPilot의 기반 OS를 Debian Buster에서 Debian Bullseye로 전환해야 했습니다. Raspberry Pi OS는 메이저 버전 업그레이드를 공식 지원하지 않기 때문에, 모든 사용자가 microSD를 직접 리플래싱해 마이그레이션하도록 강제할 수밖에 없었습니다.

그 비용을 사용자에게 전가하는 게 정말 싫었지만, 다른 방법을 찾을 수 없었습니다. 한 가지 긍정적인 부수 효과는 ‘무료 무한’ 업데이트가 끝났다는 점입니다. 라이선스가 만료된 사용자는 업데이트를 계속 받으려면 12개월짜리 새 라이선스를 구매해야 했습니다.

이 변경은 4월 27일에 적용되었고, 변경 전후 3개월간의 라이선스 갱신 현황을 비교해 봤습니다.

한편으로는 업그레이드를 위해 결제를 강제했더니 갱신이 67% 증가했다는 점에서 고무적입니다. 다른 한편으로는 3개월 동안 갱신한 사용자가 55명에 불과했다는 점이 걱정됩니다. 만료된 라이선스를 보유한 기기가 약 2,500대 정도로 추산되는데, 이는 2.2%만이 업데이트 비용을 지불했다는 의미입니다.

갱신율이 실제보다 낮게 나타나는 데에는 몇 가지 요인이 작용합니다.

• 최근 작업의 상당 부분은 업데이트 경험을 더 빠르고 오류 없이 만드는 데 집중되었습니다. 물론 유용하지만, 그 자체만으로는 굳이 업데이트를 하고 싶게 만드는 요소는 아닙니다.
• 공장 초기화 과정의 업그레이드는 마찰이 큽니다. 20~30분을 들여 기기를 초기화하는 게 번거로워 업데이트 자체를 포기하는 사용자도 있을 것입니다.

수동 만료 알림

이번 달에는 고객 라이선스가 만료되었을 때 이메일 알림을 보내보는 아이디어를 떠올렸습니다. 물론 자동화할 수 있는 일이지만, 자동화에 큰 투자를 하기 전에 수동으로 몇 통의 이메일을 보내 고객이 반응하거나 이메일을 보고 구매하는지 확인해 보기로 했습니다.

아이디어를 테스트하기 위해 이메일 7통을 보냈지만, 수신자 중 아무도 갱신하거나 답장을 하지 않았습니다. 결론을 내리기에는 표본이 너무 작습니다. 7.8%의 고객에게 갱신을 유도해야 한다면 12~13명 중 1명꼴인 셈이니까요.

이 실험을 계속하기가 망설여지는 이유는 불리하게 작용하는 요인이 많기 때문입니다.

• 이메일이 도착한 시점에 고객이 굳이 TinyPilot 업데이트를 계속 받고 싶어 하지 않을 수도 있습니다. 사용자가 TinyPilot 웹 앱에서 “업데이트” 버튼을 클릭했을 때 알림이 뜬다면 훨씬 의미 있는 테스트가 될 것입니다.
• 일부 고객은 스팸 메일용 보조 계정으로 보이는 이메일 주소로 TinyPilot을 구매했기 때문에, 제 메일을 아예 보지 못했을 수도 있습니다.
• 이들 고객은 갱신을 위해 비용을 지불하지 않아도 계속 새 업데이트를 받을 수 있다는 점을 눈치챘을 수 있으므로, 갱신할 동기가 없습니다.

자동 갱신 옵션 추가

현재 라이선스 갱신은 일회성 구매로만 제공하고 있습니다. Shopify가 기본적으로 일회성 구매만 지원하기 때문에 정기 구독 옵션을 아직 검토하지 않았습니다.

Shopify에서 정기 결제를 받으려면 서드파티 Shopify 앱을 써야 하는데, 저는 그걸 정말 하고 싶지 않습니다. 제 경험상 Shopify 앱은 품질이 낮고, 서드파티 연동과 전혀 관련 없는 구매 고객의 정보를 포함해 고객 정보에 대한 광범위한 접근 권한을 공유해야 하기 때문입니다.

그럼에도 다른 실험들과 비교했을 때, 자동 갱신 옵션은 고객의 구독 의향을 테스트한다는 측면에서 가성비가 꽤 좋습니다. 라이선스 구매 페이지에 “혹은 연 10% 할인된 연간 구독으로 구매하기” 같은 옵션을 하나 추가하는 것만으로도 고객 중에 구독할 의향이 있는 사람이 있는지 알 수 있을 것입니다.

구독 버튼을 추가하는 건 비교적 쉬울 것이고, 구독이 일반적인 Shopify 주문으로 표시될 것이기 때문에 다른 프로세스나 시스템을 바꿀 필요도 거의 없을 것입니다.

사이드 프로젝트

What Got Done

최근 Nix를 실험해 보고 있는데, 그중 관심 있는 기능 중 하나가 nix develop입니다. 프로젝트를 빌드하고 테스트하는 데 필요한 개발 도구를 정확히 담은 독립적인 셸 환경을 만들 수 있게 해줍니다.

여러 소프트웨어 프로젝트를 진행하면서 겪는 짜증 중 하나는 의존성을 유지 관리하기 어렵다는 점입니다. 제 프로젝트들의 의존성은 Go 1.19나 Node.js 16 같은 특정 버전에 묶여 있습니다. 다음 버전으로 업그레이드해야 할 때마다 개발 환경에 어떻게 설치하고 지속적 통합(CI) 설정의 버전 번호를 어떻게 업데이트해야 할지 알아내는 과정이 번거롭습니다.

더 나쁜 경우는 한 시스템에 여러 프로젝트가 있을 때입니다. 한 프로젝트를 위해 Node.js를 업데이트하면 다른 프로젝트들이 예상치 못한 버전의 Node.js와 npm을 사용하게 됩니다.

nix develop이 약속하는 것은 의존성을 한 곳, 즉 Nix flake에 정의할 수 있다는 점입니다. 예를 들어 Go의 다음 버전으로 업그레이드해야 한다면 파일 하나만 업데이트하고 nix develop을 다시 실행하면 올바른 버전의 Go가 담긴 로컬 셸을 얻을 수 있습니다. CI 환경에서도 동일한 버전이 실행됩니다. 환경은 디렉터리에 국한되므로 패키지 버전을 변경해도 같은 시스템의 다른 프로젝트에는 영향을 주지 않습니다.

Go와 Node.js에 의존하고 버전 관리가 골칫거리였던 What Got Done에서 nix develop 실험을 시작했습니다.

What Got Done의 개발 환경에 Nix를 적용해 보는 건 흥미로웠지만, 지금까지 마주한 장애물은 다음과 같습니다.

• Go 정적 바이너리 빌드를 어떻게 동작시켜야 할지 알 수 없었는데, 해결책은 마치 “그냥 이 마법의 주문을 알고 있어야 해”라는 느낌이었습니다.
• 의존성의 정확한 버전을 지정할 쉬운 방법이 없습니다.
  • Docker처럼 go:1.19.3 같은 방식으로 버전을 선언할 수 있을 거라 기대했지만, Nix는 그런 방식을 지원하지 않습니다.
  • 재현성에 그토록 중점을 둔 도구가 그렇다는 점이 놀라웠습니다.
  • 제가 찾은 가장 가까운 해결책은 서드파티 도구를 사용해 패키지 버전과 연결된 nixpkgs 해시를 찾은 뒤, 해당 nixpkgs 해시에 패키지를 고정하는 것입니다. What Got Done의 의존성 하나에 대해 그 모습이 어떤지는 다음과 같습니다.
  • Devbox는 이 문제를 해결해 주지만, 그러면 Nix를 간접적으로만 사용하게 되고 Nix 위에 얹힌 Devbox의 추상화를 따로 배워야 합니다.
• Nix 스토어를 채우는 속도가 엄청나게 느립니다.
  • CircleCI에서 꽤 빠르게 띄울 수 있는 nixos/nix Docker 이미지가 있지만, 제 Nix+Go flake용 Nix 환경을 빌드하는 데 약 2분이 걸립니다.
  • 즉, 제가 실행하는 어떤 CI 단계든 Nix를 초기화하는 데만 2분을 소모해야 한다는 뜻입니다.
  • Nix 스토어를 캐싱해 보았지만 용량이 약 3GB라 CircleCI에서 다운로드하고 압축을 푸는 데만 약 2분이 걸립니다. CircleCI가 캐시 파일을 Amazon S3에 저장하는 것으로 보이는데, 캐시 크기가 1GB 미만이지 않으면 성능이 매우 떨어집니다.

마무리

무엇을 했나?

• “Installing NixOS on Raspberry Pi 4” 게시
• hurl을 배워 HTTP API용 curl 기반 통합 테스트를 대체함.
• 노스캐롤라이나주 샬럿과 캐나다 몬트리올 방문.

배운 점

• TinyPilot은 블로그와 유튜브 리뷰를 통해 얻던 마케팅 효과가 거의 소진된 것으로 보입니다.
  • 1년 전 신규 리뷰가 가져온 효과와 비교하면 최근 리뷰의 성과는 감소하고 있습니다. 2년 전 단 하나의 리뷰로 매출이 거의 세 배가 되었던 효과와는 확실히 다릅니다.
• 자동 갱신 TinyPilot 라이선스 옵션은 반복 매출 시장을 테스트하는 가장 가성비 좋은 방법입니다.

다음 달 목표

• 위탁 제조업체로의 생산 전환을 최대한 빠르게 진행하기.
• TinyPilot 오프라인 사무실 이전을 위한 세부 계획 수립하기.
• TinyPilot 라이선스 자동 갱신 옵션 테스트하기.

도움 요청

• Shopify용 서드파티 정기 구독 앱, 특히 디지털 상품용 앱을 사용해 본 경험이 좋든 나쁘든 있다면 이메일로 알려주세요.
• 제가 어렴풋이 기억하는 그 Basecamp 이야기를 찾을 수 있다면 댓글로 알려주세요.