한 줄 요약

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 소프트웨어의 프리미엄 버전 작업을 시작했습니다.

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

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

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

Basecamp 블로그에 SaaS 제품을 과금 시스템조차 만들기 전에 판매하기 시작했다는 내용의 글이 있습니다. (수정: Nathan Coleman님이 찾아주셨습니다. Basecamp의 책 Getting Real에 나오는 내용입니다.) 이들은 소프트웨어 이용료가 서비스 한 달이 끝난 뒤에 청구되므로 첫 판매 이후 돈을 걷는 방법을 고민할 시간이 한 달은 있다고 판단했다고 합니다.

저도 TinyPilot에 비슷한 전략을 적용했습니다. 1년 안에 제대로 된 라이선스 관리 솔루션을 구현할 수 있을 거라 기대하고, 라이선스 집행 방법으로 자율 준수(honor system) 방식을 택했습니다.

그리고 3년이 지난 지금, TinyPilot Pro의 라이선스 집행과 관련해 여전히 아무 진전도 이루지 못했습니다.

최악의 타이밍에 이루어지는 라이선스 검증

고객에게는 TinyPilot 기기에 12개월 무료 업데이트가 포함된다고 안내하고 있습니다. 하지만 숨겨진 비밀은, 일단 기기에 TinyPilot Pro를 설치하고 나면 웹 인터페이스를 통해 영구적으로 소프트웨어를 계속 업데이트할 수 있다는 점입니다.

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

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

고객이 라이선스 만료를 알게 되는 경우도 있지만, 그 시점이 하필 가장 불편한 타이밍입니다.

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

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

고객 입장에서는 라이선스 만료 사실을 알게 되는 최악의 방식입니다. 파일시스템이 손상되어 이미 작업이 중단된 상황에서, 문제를 해결하려면 직접 기기 앞으로 가서 microSD를 빼낸 뒤 다시 플래싱해야 합니다. 그런데 그 와중에 추가 비용을 요구하는 셈이 됩니다.

고객이 새 이미지를 구매하고 싶지 않다면, 지원팀에 문의할 경우 이전 버전 이미지에 대한 접근 권한을 제공해 드립니다. 하지만 답변을 받는 데 영업일 기준 최대 하루가 걸릴 수 있어, 업무가 막힌 상황에서는 좋지 않습니다.

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

정기 구독이 노력할 만한 가치가 있으려면?

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

이는 수 주간의 개발 작업이 필요한 데다, 주문 정보가 담긴 TinyPilot 이메일을 삭제해 업데이트에 접근할 수 없다는 문의가 필연적으로 늘어나 지원 부담까지 커지므로 구현 비용이 큽니다.

만약 그 모든 노력을 들였는데 갱신율에 아무 영향이 없다면 어떻게 해야 할까요?

라이선스 갱신이 가치가 있으려면 연간 최소 3만 달러의 추가 이익을 만들어야 합니다. 라이선스 결제 수수료를 약 3%로 추산하면, 라이선스 한 건 갱신당 TinyPilot이 얻는 순수익은 약 77달러입니다.

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

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

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

좋습니다, 기존 고객의 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.8%가 갱신해야 한다면 12~13명 중 한 명 정도만 갱신하면 되는 셈이니까요.

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

• 이메일이 도착하는 시점은 고객이 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 환경에서도 동일한 버전이 실행됩니다. 환경이 디렉터리 단위로 격리되므로 패키지 버전을 변경해도 같은 시스템의 다른 프로젝트에는 영향을 주지 않습니다.

What Got Done은 Go와 Node.js에 의존하고 버전 관리가 골칫거리였기 때문에, 이 프로젝트에서 nix develop을 실험하기 시작했습니다.

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

• Go 정적 바이너리 빌드를 동작시키는 방법을 찾지 못했고, 해결책은 “그냥 이런 마법 주문을 알고 있어야 한다”는 식으로 느껴집니다.
• 의존성의 정확한 버전을 지정할 쉬운 방법이 없습니다.
  • Docker처럼 go:1.19.3 형태로 버전을 선언할 수 있을 거라 기대했지만, Nix는 그런 문법을 지원하지 않습니다.
  • 재현성에 그토록 중점을 둔 도구에서 이런 점은 의외였습니다.
  • 제가 찾은 가장 가까운 해결책은 서드파티 도구를 사용해 패키지 버전과 연결된 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 미만이지 않으면 성능이 매우 떨어집니다.

마무리

무엇을 해냈나?

• “Raspberry Pi 4에 NixOS 설치하기”를 게시했습니다
• HTTP API의 curl 기반 통합 테스트를 대체하기 위해 hurl 사용법을 익혔습니다.
• 미국 노스캐롤라이나주 샬럿과 캐나다 몬트리올을 방문했습니다.

배운 점

• 블로그와 YouTube 리뷰를 통해 얻던 마케팅 효과가 거의 소진된 것으로 보입니다.
  • 신규 리뷰의 효과는 1년 전에 비해 눈에 띄게 줄었습니다. 2년 전 리뷰 하나로 매출이 거의 세 배로 뛰었던 때와는 확실히 다릅니다.
• TinyPilot 라이선스에 자동 갱신 옵션을 추가하는 것이 반복 매출 시장성을 테스트하는 가장 가성비 좋은 방법입니다.

다음 달 목표

• 가능한 한 빠르게 외주 제조업체로 생산을 전환하기.
• TinyPilot 오피스 이전을 위한 세부 계획 수립하기.
• TinyPilot 라이선스 자동 갱신 옵션 테스트하기.

도움 요청

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