한 줄 요약

TinyPilot 판매를 어떻게 지속 가능하게 유지할 수 있을까?

하이라이트

• TinyPilot이 역대 최고 매출인 7만 4천 달러를 기록했다.
• 소프트웨어 라이선싱에 대한 최적의 방안을 모색 중이다.
• 여전히 마음에 드는 웹 프레임워크를 찾고 있다.

목표 달성도

매달 초에 달성하고 싶은 목표를 정한다. 이번 달 목표 대비 성과는 다음과 같다.

TinyPilot 설치용 독립 tarball 만들기

• 결과: 정상 작동하는 tarball 패키지를 확보했다
• 등급: A

TinyPilot의 설치 과정은 시간이 지날수록 점점 복잡해지고 있다. 여러 저장소와 서드파티 의존성에서 코드를 가져오다 보니 그 관계들을 추적하기가 갈수록 어려워지고 있다.

현재 모든 것을 단일 tarball로 통합해 설치 과정을 전면 개편하고 있다. 이를 통해 모든 의존성을 한곳에 명확하게 모을 수 있다. 무료 버전의 TinyPilot을 새 업데이트 시스템으로 전환하는 중이며, 곧이어 TinyPilot Pro도 이전할 예정이다.

TinyPilot 웹사이트 리디자인에 대한 장문 블로그 글 초안 완성

• 결과: 초안을 완성했다
• 등급: A

회고록에 이 경험에 대해 이미 많이 써 두었으니 블로그 글을 쓰는 건 쉬울 줄 알았다. 하지만 장문 글은 쓰는 스타일이 달라 결국 상당 부분을 다시 써야 했다. 분량은 5,200단어로 평소 글의 두 배 정도라 줄이려고 노력 중이다.

유료 검색 광고 ROAS 2.0으로 높이기

• 결과: ROAS가 1.79에서 1.99로 상승했다
• 등급: A

TinyPilot과 함께 일하는 디지털 마케팅 프리랜서가 광고 대비 매출을 1.99까지 끌어올렸다. 광고에 1달러를 쓸 때마다 약 0.55달러의 이익을 남기는 셈으로 추산된다.

안타깝게도 검색 노출 점유율을 더 높이려 할수록 비용이 증가하기 때문에 광고비를 두 배로 늘린다고 매출이 두 배가 되지는 않는다. 그래도 지금까지의 성과에 만족하며, 새로운 마케팅 채널을 계속 탐색하고 있다.

TinyPilot 통계

이번 달은 TinyPilot 역사상 최고 (수정: 두 번째로 높은, 아래 참고) 매출을 기록한 달이었다. 그리고 흥미로운 점은 6월에 그 외에는 특별할 것이 전혀 없었다는 점이다.

TinyPilot이 이전에 기록을 경신했던 달들은 모두 신제품 출시나 호평 리뷰 같은 일회성 이벤트와 관련이 있었다. 하지만 6월은 사실상 아무 특별한 일도 일어나지 않은 평범하고 지루한 달이었다. 그리고 그게 멋지다! 외부 이벤트에 의존하지 않고도 지금 하고 있는 일을 반복할 수 있다는 뜻이기 때문이다.

사이트 방문자는 전월 대비 감소했지만, 이는 5월이 직전 블로그 글 때문에 비정상적으로 높았기 때문이다. 전체 방문자 수는 여전히 1분기보다 훨씬 높은 수준이며, 방문자 증가는 새로운 마케팅 캠페인 덕분이라고 본다.

TinyPilot Pro 사용자는 어떻게 라이선스를 인증할까?

나는 TinyPilot 소프트웨어가 새로운 하드웨어 판매 여부와 관계없이 자체적으로 지속 가능하기를 항상 바랐다. 사용자는 TinyPilot 하드웨어를 구매하면 프리미엄 소프트웨어를 무료로 받지만, 소프트웨어 유지보수를 위한 자금을 마련하려면 일정 시점 이후에는 비용을 지불할 방법이 필요하다.

2020년 12월에 TinyPilot Pro라는 유료 버전을 출시했다. 처음에는 라이선스 키 검증 기능을 함께 출시할 계획이었지만, 해당 기능을 미뤘는데, 2021년 말에 라이선스가 만료되기 전까지는 필요하지 않다고 판단했기 때문이다.

이제 18개월이 지났지만 TinyPilot Pro는 여전히 사용자가 유효한 라이선스를 가지고 있는지 확인하지 않는다. 내 추산으로는 약 3분의 1의 사용자가 라이선스가 만료되었는데도 이를 모르고 있다.

사용자가 최신 버전으로 업그레이드할 때 유효한 라이선스를 확인하는 절차를 추가할 계획이다. 이렇게 하면 현재 버전에 만족하는 사용자는 영원히 그대로 사용할 수 있고, 최신 기능을 원할 경우 초기 1년 라이선스가 만료된 이후에는 소프트웨어 업데이트 비용을 지불해야 한다.

최신 업데이트를 다운로드할 권한이 있는지 확인하려면, 사용자가 업데이트 서버에 유효한 TinyPilot Pro 라이선스를 보유하고 있음을 증명할 방법이 필요하다.

고려 중인 옵션들은 다음과 같다.

장치 ID

TinyPilot은 Raspberry Pi에서 구동되며, 모든 Pi 장치에는 다음과 같이 조회할 수 있는 하드웨어 시리얼 번호가 있다.

$ cat /proc/cpuinfo | grep Serial | cut -d ' ' -f 2
10000000ecf8821b

고객에게 판매하기 전에 각 Pi의 장치 ID를 기록해 둘 수 있다. 사용자가 업그레이드를 시도할 때 장치 ID가 사전 등록되어 있는지 확인한 뒤 이를 기반으로 활성화하는 방식이다.

• 장점
  • 사용자에게 편리하다 - 장치 ID를 잃어버리거나 잊을 일이 없다
• 단점
  • 모든 장치 ID를 우리가 직접 추적해야 한다
  • 장치 제조 과정에 단계가 하나 추가된다
  • 장치 ID 기록을 시작하기 전에 구매한 사용자에 대한 별도 해결책이 여전히 필요하다

주문 정보

현재 고객이 공식 TinyPilot 디스크 이미지를 다운로드하려면 구매와 연결된 주문 번호와 이메일 주소를 요청한다.

동일한 로직을 TinyPilot 웹 앱 내에서 업그레이드를 제한하는 데 사용할 수 있다.

• 장점
  • 이미 주문 정보를 저장하고 있으므로 키나 장치 ID를 추적할 필요가 없어 관리 부담이 적다
  • 이미 주문 정보를 보유하고 있어 모든 기존 고객에게 적용 가능하다
• 단점
  • 최종 사용자가 주문 세부 정보를 항상 아는 것은 아니다
    • 리셀러를 통해 구매했거나 회사 내 다른 사람이 장치를 구매한 경우도 있다
  • Amazon, eBay 같은 새로운 채널에서 판매를 시작할 때마다 해당 채널의 주문 정보를 조회하기 위한 맞춤 코드를 작성해야 한다

인쇄된 정품 인증 키

Microsoft Windows나 Office를 정품 인증하는 방식과 유사하게 일련의 정품 인증 키를 생성할 수 있다(예: 1F9PA-V4JD5-4JPOM). 키를 인쇄해 각 장치에 동봉하고 사용자가 키를 입력해 라이선스를 증명하도록 하는 방식이다.

• 장점
  • 사용자가 직접 구매하든 Amazon, eBay 등을 통해 구매하든 동일하게 작동한다
• 단점
  • 사용자는 주문에 동봉된 종이 쪽지를 잃어버리거나 무시하기 쉽다
  • 정품 인증 키 배포를 시작하기 전에 구매한 사용자에 대한 해결책이 여전히 필요하다

소프트웨어에 내장된 라이선스

고객 장치에 이미지를 플래싱하므로 이론적으로는 각 고객 장치에 TinyPilot Pro 라이선스를 부여하는 고유 키 파일을 넣을 수 있다.

• 장점
  • 사용자가 직접 구매하든 Amazon, eBay 등을 통해 구매하든 동일하게 작동한다
  • 사용자가 키를 잃어버릴 일이 없다
• 단점
  • 구현이 극도로 비현실적이고 복잡하다
    • 고객마다 맞춤형 디스크 이미지를 생성하고 고객이 항상 자신의 이미지를 설치하도록 해야 한다
  • 내장 키 방식을 시작하기 전에 구매한 사용자에 대한 해결책이 여전히 필요하다

조합

가능한 한 가장 자동화된 방식을 사용하되 예외 상황에서는 더 수동적인 방식으로 대체하는 혼합 방식을 고려하고 있다.

1. 장치의 하드웨어 ID가 사전 등록되어 있는지 확인한다.
2. 사전 등록되어 있지 않다면 주문 ID와 이메일을 입력받아 주문을 자동으로 찾는다.
3. 주문 ID와 이메일로 주문을 자동으로 찾지 못하면 고객 지원에 이메일로 문의하도록 하여 수동으로 라이선스를 발급한다.

생각해 낼 수 있는 옵션 중에서는 이 방식이 오류 가능성이 가장 적고 최종 사용자의 부담도 가장 적어 보인다.

아마존 셀러 마켓플레이스에 발을 들이는 자, 모든 희망을 버려라

오랫동안 TinyPilot을 Amazon에서 판매하는 것을 고려해 왔다. 많은 사람들이 Amazon을 온라인 쇼핑의 원스톱 상점으로 여기기 때문이다. Amazon 셀러로 등록하는 과정이 끔찍하고 지루해 보여 망설여 왔는데, 직접 겪어 보니 예상보다 더 끔찍하고 지루했다.

제품 하나를 Amazon에 등록하는 데만 3주가 걸렸다. 며칠마다 Amazon은 새로운 승인이나 내 신원 또는 제품에 대한 증명을 요구했다.

먼저 Amazon은 운전면허증과 신용카드 번호로 내 신원을 확인해야 했다. 그 다음에는 운전면허증을 얼굴 앞에 들고 구부려 인쇄물이 아님을 증명하는 실시간 영상 통화에 참여해야 했다.

그 다음에는 신용카드를 확인할 수 없다며 계정이 하루 동안 정지됐다. 그 카드는 내가 1년 동안 Amazon에 등록해 두고 약 5만 달러어치 구매에 사용했던 바로 그 카드였다.

그 다음에는 “TinyPilot” 브랜드명을 사용할 권한이 있는지 확인하겠다며 다시 계정이 정지됐다. 내가 TinyPilot, LLC의 소유자임을 증명하는 서류를 제출하고, 제품 측면에 “TinyPilot”이라고 적혀 있는 사진을 보냈다.

3일 이내에 검토하겠다고 했지만 실제로는 10일이 걸렸다. 결론은 사진으로는 “TinyPilot”이 제품에 영구적으로 부착되어 있다는 충분한 증거가 되지 않는다는 것이었다…

그래서 브랜드명을 훨씬 더 클로즈업한 새 사진을 보냈고, 그제야 마침내 승인을 받았다.

새로 생긴 문제는 “tinypilot”을 검색해도 TinyPilot이 검색 결과에 나타나지 않는다는 것이었다.

특히 이상한 점은 Amazon 자체의 자동완성 추천어가 모두 명백히 내 제품과 관련된 것이었다는 점이다.

“tinypilot kvm over ip”로 검색해도 내 제품은 검색 결과 2~3페이지가 되어서야 나타났다.

결국 Amazon에서 광고를 구매했고, 그제야 첫 몇 건의 판매가 이루어졌다.

운영을 시작하는 데 필요한 어려운 과정은 이제 끝났기를 바라며, Amazon에서 평점이 쌓이면 매출 성장에 도움이 될지 지켜보려고 한다.

Amazon 고객은 확실히 다르다

Amazon 고객은 TinyPilot 웹사이트에서 직접 구매하는 고객과 기대치가 확연히 다른 것 같다.

Amazon을 통해 구매한 첫 고객은 “UPS 2-day로 배송해 달라”는 주문과 함께 메시지를 보냈지만 우리는 UPS 배송을 제공하지 않는다. 고객 메시지에 답변은 했지만 다음에 어떻게 해야 할지 확신이 서지 않았다. 주문을 취소하고 Amazon으로부터 페널티를 받을 위험을 감수해야 할까? 고객의 답변을 기다리다가 배송 지연으로 페널티를 받을 위험을 감수해야 할까? 결국 하루를 기다린 뒤 답이 없어 취소했는데, 고객이 같은 주문을 다시 했고 우리는 USPS로 발송했으며 별다른 불만은 듣지 못했다.

며칠 후 다른 Amazon 고객이 신속 배송비로 10달러를 냈는데도 제품이 아직 도착하지 않았다며 “매우 실망했다”는 메시지를 보내왔다. 운송장을 확인해 보니 USPS Priority로 하루 일찍 발송했지만 USPS 배송이 지연되고 있었다. 이는 명백히 우리가 통제할 수 없는 부분이지만, 고객들은 제3자 판매자에게서 구매하는 것과 Amazon 자체 배송망을 통해 직접 구매하는 것의 차이를 잘 모르는 것 같다.

직접 주문하는 고객에게서도 이런 불만을 가끔 듣지만, Amazon에서 보는 빈도에는 전혀 미치지 못한다.

여전히 사랑할 만한 웹 프레임워크를 찾아서

지난 업데이트에서 언급했듯이, 팬데믹 초기에 보류했던 라이브 코미디 공연 탐색 도구인 WanderJest를 다시 만들고 있다.

수년간 Angular와 Vue 같은 SPA 프레임워크로 작업한 끝에, “기본으로 돌아가기” 기술 스택으로 Go + VanillaJS + SQLite 조합으로 WanderJest를 다시 쓰고 있다. Chris Ferdinandi는 그의 글 “SPAs were a mistake.”에서 내가 느꼈던 답답함을 잘 표현했다.

현재 기술 스택이 지금까지 써 본 어떤 웹 프레임워크보다 마음에 들지만, 여전히 사랑스럽다고는 할 수 없다. 대부분의 시간을 그저 이것저것을 이어 붙이는 지루한 작업에 쓰고 있다.

예를 들어, 사용자가 WanderJest에서 사진, 자기소개, 다른 소셜 네트워크 링크를 포함한 프로필을 만들 수 있게 하려면 다음이 필요하다.

1. 사용자가 프로필을 만들고 수정할 수 있는 웹 폼 만들기
2. 사용자 제출을 받기 위한 서버 측 엔드포인트 만들기
3. 프로필 정보를 나타내는 데이터 모델 만들기
4. 데이터 스토어에 데이터를 넣고 빼기 위한 직렬화/역직렬화 코드 작성
5. 데이터를 삽입하고 조회하기 위한 SQL 쿼리 작성
6. 프로필 정보를 렌더링하기 위한 웹 UI 만들기

다른 프레임워크보다 단계는 적지만, 그 작업들은 정말 지루하다.

Phoenix LiveView는 지난 1년간 내 관심 목록에 있었다. fly.io의 멋쟁이들이 열광하는 것이기도 하다. Phoenix가 약속하는 것 중 하나는 위에서 나열한 반복적인 작업들을 자동화한다는 점이다. Chris McCord는 Phoenix로 15분 만에 기본적인 Twitter 클론을 만드는 멋진 데모를 선보인 바 있다.

동시에, “남의 떡이 더 커 보인다”는 심리에 빠져 특정 스택을 제대로 익히지도 못하고 계속 프레임워크를 옮겨 다니는 것은 아닌지 걱정도 된다. 좋은 절충안은 Ruby on Rails일지도 모른다. Phoenix와 비슷한 개발 경험을 제공하면서도 생태계는 더 성숙하다고 생각하기 때문이다.

마무리

무엇을 해냈나?

• Amazon에서 TinyPilot 판매 시작
• 새로운 장문 블로그 글 초안 완성
• TinyPilot 설치 번들 생성 과정 완료

얻은 교훈

• Amazon Seller Marketplace는 보이는 것보다 훨씬 더 불쾌하다.

다음 달 목표

• TinyPilot 라이선스 관리 계획 확정.
• TinyPilot Community를 차세대 업데이트 시스템으로 이전.
• TinyPilot 웹사이트 리디자인에 대한 블로그 글 게시.