한 줄 요약

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월이 그 외에는 특별할 것 없는 평범한 달이었다는 사실입니다.

이전에 기록을 경신했던 달들은 모두 신제품 출시나 호평 리뷰 같은 일회성 이벤트 덕분이었습니다. 하지만 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를 직접 관리해야 한다
  • 기기 제조 과정에 단계가 하나 추가된다
  • 기기 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 셀러로 가입하는 과정이 끔찍하고 지루할 것 같아 망설였는데, 직접 겪어 보니 예상보다 훨씬 더 끔찍하고 지루했습니다.

제품을 등록하기까지 3주가 걸렸습니다. 며칠마다 Amazon은 새로운 승인이 필요하다거나 제 신원이나 제품에 대해 무언가를 증명하라고 요구했습니다.

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

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

이어서 Amazon은 제가 “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 웹사이트 리디자인에 관한 블로그 글 게시