한 줄 요약

제3자 물류로의 느린 전환

하이라이트

• TinyPilot의 물류 업무를 외부 업체에 맡기는 전환 작업을 시작했다.
• TinyPilot 고객들은 내가 예상한 것보다 가격에 덜 민감했다.
• TinyPilot 보상 판매에 많은 자원을 투입했지만, 그만한 가치가 있었는지 확신이 서지 않는다.

목표 달성 평가

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

판매량이 적은 제품의 물류를 신규 3PL로 전환하기

• 결과: 3PL 업체가 3주째 Power Connector 주문을 처리하고 있다.
• 등급: A

다듬어야 할 부분이 몇 가지 있었지만, 첫 번째 제품의 전환은 성공적으로 마무리했다.

NERD Summit 2023에서 발표하기

• 결과: 발표를 마쳤고 전달력에도 만족했다.
• 등급: A

2019년 이후 처음으로 오프라인으로 열린 NERD Summit에 다시 참가하니 즐거웠다. 멋진 발표도 많았고 복도에서 나눈 대화들도 재미있었다.

물류팀의 업무 부담을 줄여 대응성 업무가 전체 업무 시간의 80% 미만을 차지하도록 하기

• 결과: 대체로 성공했지만 정확히 측정하기는 어려웠다.
• 등급: B

3PL로 전환하기 위해 현지 팀이 일주일치 물량의 기기를 추가로 제작할 수 있을 만큼 여유를 만들어줘야 했다. 업무 부담을 줄이기 위해 여러 조치를 취했지만, 평소보다 더 많은 시간을 일하기도 했다.

TinyPilot 통계

TinyPilot 케이스를 플라스틱에서 금속으로 바꾸자 수요가 급격히 늘었다. 가격을 올리고 마케팅을 거의 중단했는데도 판매량은 계속 증가하고 있다.

올해 목표는 수익 10만 달러 달성인데, 이미 75%를 달성했다. 이 추세라면 4월이 끝나기 전에 연간 수익 10만 달러를 달성하게 될 것이다.

3PL 업체로 전환하며 겪은 시행착오

나의 최우선 과제는 TinyPilot의 물류 업무를 제3자 물류(3PL) 업체로 이전하는 것이다. 3PL의 역할은 완제품을 창고에 보관하고, 주문이 들어오면 제품을 꺼내 포장하고 배송하는 것이다.

그 첫 단계로 판매량이 가장 적은 제품인 TinyPilot Power Connector를 3PL에 맡겼다. 이 제품은 직접 TinyPilot 기기를 조립하는 사용자들을 위한 것으로, 웹사이트에도 광고하지 않는다. 한 달에 20~30개 정도만 판매된다.

Power Connector는 모든 주문을 3PL로 넘기기 전에 신규 3PL을 처음부터 끝까지 테스트해 볼 수 있는 위험 부담이 낮은 방법이었다. 이 과정에서 여러 문제가 드러났기에, 작은 규모로 테스트를 시작한 것이 다행이었다.

“모두 그냥 관리자 비밀번호를 알려줘요”

첫 번째 난관은 TinyPilot의 주문 시스템과 3PL의 시스템을 연동하는 것이었다. TinyPilot은 미국에서 가장 인기 있는 전자상거래 플랫폼 중 하나인 Shopify를 사용한다. 우리 3PL은 ShipStation으로 주문을 관리한다. ShipStation도 꽤 유명하고 평판도 좋아서, Shopify와 ShipStation을 연동하는 건 간단할 거라 생각했다.

내가 이전에 이용하던 3PL도 비슷한 주문 관리 시스템을 사용했다. 연동하려면 Shopify에 앱을 설치하고 3PL의 액세스 키를 붙여 넣기만 하면 됐다. 아주 쉬웠다.

새로운 3PL이 Shopify 계정과 ShipStation을 연동하는 방법을 보내왔을 때, Shopify의 루트 관리자 계정 정보를 넘기거나 그들을 위해 새로운 관리자 계정을 만들라고 안내했다.

뭔가 이상했다.

ShipStation 문서를 확인했지만 두 계정을 어떻게 연결해야 할지 알 수 없었다. ShipStation은 Shopify 계정과 ShipStation 계정의 소유자가 동일인이라고 가정하고 있었는데, 우리 경우는 그렇지 않았다.

ShipStation의 설계 때문에 교착 상태에 빠졌다. 나는 3PL의 ShipStation 관리자 계정 정보를 가지고 있지 않아 3PL의 ShipStation 계정에 연결할 수 없었고, 3PL은 내 Shopify 관리자 계정 정보를 가지고 있지 않아 TinyPilot의 Shopify 스토어에 연결할 수 없었다.

3PL에 TinyPilot Shopify의 전체 관리자 권한을 주고 싶지 않았고, 내 개인 계정의 비밀번호를 넘겨주는 것은 더더욱 원치 않았다.

대신 나는 직접 ShipStation 계정을 하나 만들고 권한이 제한된 Shopify 더미 사용자 계정을 만들었다. 그리고 그 더미 계정을 이용해 TinyPilot의 Shopify 계정을 내 테스트용 ShipStation 계정에 반복적으로 연결해 보았다.

시행착오 끝에 ShipStation 계정을 연결하는 데 필요한 Shopify 사용자 계정의 최소 권한을 알아냈다. 이를 파악한 뒤 3PL을 위해 TinyPilot Shopify에 최소한의 권한만 가진 제한된 계정을 만들어 주었다.

혹시 Shopify와 ShipStation 연동에서 나와 같은 어려움을 겪고 있는 분이 이 글을 발견한다면, Shopify에서 ShipStation을 연결하는 데 필요한 권한은 다음과 같다:

• Orders
  • Edit orders
• View products
• Customers
• Manage settings
• Manage and install apps and channels

Shopify를 3PL의 ShipStation 계정과 연동하는 과정이 이렇게 복잡하다는 사실에 놀랐다. 3PL은 Shopify 고객이 수십 곳이나 있다고 했기에, 예전에는 이 과정을 어떻게 해결했는지 물어봤다.

“모두 그냥 관리자 비밀번호를 알려줘요”라고 3PL 매니저가 말했다. 그녀는 대부분의 고객이 기술에 크게 익숙하지 않아 물류를 맡기는 업체에 Shopify 계정 정보를 제공하는 것을 별로 이상하게 여기지 않는다고 설명했다.

50달러짜리 주문을 배송하는 데 150달러를 써야 할까?

전환 과정의 다음 난관은 호주에서 온 주문이었다. TinyPilot이 서비스하는 국가 중 호주는 배송비가 가장 비싼 나라 중 하나다. TinyPilot Power Connector를 미국 내에서 배송하는 데는 몇 달러밖에 들지 않지만, 호주까지 배송하는 데는 50달러가 든다.

3PL 측은 이 주문을 배송하는 데 150달러가 들 것이라고 알려왔다. 하지만 고객이 지불한 배송비는 50달러뿐이었다. TinyPilot은 Shopify가 대신 협상해 준 덕분에 DHL 국제 배송 할인 요금을 적용받고 있었는데, 3PL은 DHL과 할인 요금 계약이 없어 호주까지 우편 요금으로 150달러를 지불해야 했던 것이다.

3PL이 정가 우편 요금을 지불한다면, 그 차액인 100달러는 내가 부담해야 한다. 그러면 이 주문으로 인해 주문이 없었을 때보다 오히려 50달러를 손해 보게 되는 셈이었다.

한 건의 주문에서 손해를 보는 것 자체는 큰 문제가 아니었지만, 이는 더 깊은 문제를 시사했다. TinyPilot 고객이 결제 단계에서 보는 배송비는 Shopify의 배송 요금을 기준으로 한 것이었다. 고객에게 보여지는 배송비를 내 3PL의 요금으로 바꿔야 했다.

나는 다시 물었다, “다른 고객들은 어떻게 하나요?”

3PL 매니저는 다른 고객들은 무료 배송을 제공하거나, 배송물의 크기나 무게와 관계없이 국가별로 고정 요금을 책정한다고 했다.

그렇게 대략적으로 가격을 책정하는 것이 불가능한 일은 아니지만, 어설프게 느껴졌다. 우리는 계속 추측에 의존해야 했고, 고객에게 배송비를 너무 적게 혹은 너무 많이 청구하는 상황이 분명히 생길 것이었다. TinyPilot의 현재 시스템은 고객이 정확한 배송비를 기준으로 택배사를 선택할 수 있게 해 주는데, 나는 그 방식을 유지하고 싶었다.

ShipStation 문서에서 ShipStation이 Shopify와 배송 요금을 공유할 수 있다는 것을 알게 되었기에, 가능해 보였다. 3PL은 이전에 한 번도 해본 적이 없다고 했지만, 함께 방법을 찾아보기로 했다. 몇 시간 뒤 3PL 매니저가 전화해 ShipStation 쪽에서는 가능하지만 내 Shopify 요금제에서는 지원되지 않는다고 알려왔다.

Shopify 기능 페이지를 확인해 보니 “Third-party calculated shipping rates”는 Shopify의 Advanced 플랜에서만 제공된다는 것을 확인했다:

그렇게 되면 TinyPilot의 Shopify 요금제는 월 105달러짜리에서 무려 월 399달러짜리 플랜으로 오르게 되며, Shopify가 TinyPilot의 가장 비싼 클라우드 서비스가 된다.

이 모든 것을 파악하는 동안에도 나는 3PL 매니저와 통화 중이었다. 다소 충동적으로 그 자리에서 바로 업그레이드했다.

배송 요금에 대해 한바탕 호들갑을 떤 터라, 그 자리에서 발을 빼기엔 민망했다. 그래도 나중에 마음을 바꿀 수 있도록 일부러 월간 결제로 신청했다.

돌이켜보면 Shopify Advanced 플랜은 여전히 그만한 가치가 있다고 생각한다. 국가별로 배송비를 일일이 추정하고 시장 상황에 따라 조정하는 일을 정말 하고 싶지 않았다. 그리고 상위 요금제로 올리면 신용카드 수수료가 0.2% 줄어드니 비용을 일부 만회할 수 있다. 작년 TinyPilot 매출을 기준으로 계산하면 수수료 할인으로 약 2,000달러를 아낄 수 있으니, 이 터무니없이 비싼 플랜에 연간 4,800달러를 쓰는 비용 중 일부는 돌려받는 셈이다.

TinyPilot 수요는 얼마나 탄력적일까?

TinyPilot이 현재 직면한 제약은 제조 역량이다. 아직 기기를 사내에서 조립하고 있는데, 주문이 들어오는 속도가 직원들이 기기를 제작하는 속도와 거의 비슷하다.

모든 제품을 3PL로 전환하려면 주문량을 따라가는 것만으로는 부족하다. 3PL 창고로 보낼 Voyager 2a 기기를 최소 일주일치 분량으로 여유 있게 비축해야 한다. 판매 속도를 늦추기 위해 TinyPilot 가격을 올려봤는데, 흥미로운 데이터를 얻을 수 있었다.

경제학에서 제품의 ‘탄력성’은 소비자가 가격에 얼마나 민감하게 반응하는지를 나타낸다. 우버가 탄력적인 제품의 좋은 예다. 요금이 저렴하면 편리함 때문에 이용하겠지만, 요금이 10배로 오르면 아마 대중교통을 이용할 것이다.

그렇다면 TinyPilot 고객은 가격에 얼마나 민감할까?

Voyager 2a USB-C

Voyager 2a PoE

소감

표본이 너무 작아 단정적으로 말하긴 어렵지만, 데이터에 따르면 TinyPilot 고객은 내가 예상했던 것보다 가격에 덜 민감한 것으로 보인다. 특히 PoE 모델의 수요는 매우 비탄력적인데, 가격을 80달러(17%) 인상했는데도 고객들이 거의 같은 속도로 구매를 이어갔다.

내 안의 자본가는 이윤을 극대화하기 위해 계속 가격을 올리고 싶어 한다. 반면 애호가로서의 나는 일반 사용자가 부담 없이 쓸 수 있도록 가격을 저렴하게 유지하고 싶다.

최근 첫 TinyPilot 프로토타입을 만들었던 당시의 블로그 글을 다시 읽다가 다음 문단을 발견했다:

다음으로 상용 KVM over IP 솔루션을 알아봤다. Dell의 iDRAC과 비슷한 기능을 제공하지만… 가격은 대당 500달러에서 1000달러로 훨씬 더 비쌌다.

이제 내가 그 비싼 상용 KVM over IP 솔루션이 되어 버렸다!

어쩌면 비합리적으로 들릴지 모르지만, 나는 2020년의 내가 — 큰돈을 들이지 않고 홈 서버를 쉽게 관리할 방법을 찾던 그때의 내가 — 매력적으로 느꼈을 만한 TinyPilot 제품을 제공하고 싶다.

공급과 생산 속도 모두에 제약이 있는 지금 상황에서는 높은 가격이 타당하다고 생각한다. 하지만 언젠가는 다시 가격을 낮추고 판매량으로 만회할 수 있기를 바란다. 그 배경에는 공급 제약이 있다.

보상 판매는 어리석은 생각이었을까?

TinyPilot이 새로운 하드웨어 버전을 출시할 때마다 고객들은 기존 기기를 반납하고 최신 모델로 교환할 수 있는지 물어왔다. 이전에는 보상 판매 절차가 없다고 하면서 대신 신제품을 할인된 가격에 제공하겠다고 답하곤 했다.

올해 TinyPilot의 가장 큰 제약은 라즈베리파이 수급이다. 그래서 제한된 라즈베리파이 재고로 TinyPilot이 얻을 수 있는 수익을 극대화하려고 노력하고 있다.

고객에게 신제품 할인을 제공하는 대신, 보상 판매를 제공하는 것이 기발한 아이디어라고 생각했다. 고객이 기기를 보내면 우리는 가능한 한 많은 부품을 재활용해 Voyager 2a로 개조한 뒤 다시 보내주는 방식이었다. TinyPilot의 모든 제품은 동일한 모델의 라즈베리파이를 사용하므로, 새로운 라즈베리파이를 소모하지 않고도 충성 고객에게 보답할 수 있는 방법이었다.

보상 판매 과정은 예상보다 훨씬 복잡하고 노동 집약적이었다.

많은 고객이 일상 업무에 TinyPilot을 사용하고 있어 교체품을 받기 전에 기기를 보내고 싶어 하지 않았다. 그런 경우에는 재생 부품으로 만든 Voyager 2a를 먼저 판매한 뒤, 보상 판매 기기를 받으면 부분 환불을 해주었다.

또 여러 대의 TinyPilot 기기를 보유하고 있어 모두 가동 상태로 유지해야 하는 고객들도 있었다. 그런 고객에게는 재생 기기를 먼저 보내고 기존 기기를 돌려받은 뒤, 그것을 최신 버전으로 개조해 다시 보내고, 다시 다음 기기를 받는 식으로 모든 기기를 교체할 때까지 반복했다. 어떤 고객은 이런 방식으로 네 대를 교체하기도 했다.

모든 보상 판매가 원활하게 진행되긴 했지만, 예상보다 훨씬 많은 작업이 필요했다.

이 결정의 득실을 따지기는 어렵다. 장점은 무형적이기 때문이다 — 우리와 함께해 주고 제품을 지지해 주는 고객에게 보답한다는 것이다. 반면 단점은 매우 구체적이었다. 보상 판매는 일반 판매보다 평균적으로 2~3배 더 오래 걸렸고, 사실상 원가 수준으로 진행됐다.

TinyPilot이 일반 판매 한 건당 300~400달러의 이익을 남긴다고 할 때, 보상 판매 한 건이 약 2.5건의 판매를 막았다면 보상 판매 한 건당 750~1,000달러의 비용이 든 셈이다. 총 22건의 보상 판매를 진행했으니, 보상 판매 프로그램에는 약 1만 9,000달러가 든 것이다.

다시 한다면 여전히 보상 판매를 제공하겠지만, 다음과 같이 방식을 조정할 것이다:

• 보상 판매를 널리 홍보하지 않고, 문의하는 고객에 한해 대응한다.
• 보상 판매 요청을 별도의 지원 대기열로 처리하고, 각 고객의 처리가 시작되기까지 몇 주가 걸릴 수 있음을 미리 안내한다.

사이드 프로젝트

Zestful 마이크로서비스를 Go로 재구현하기

2018년 레시피 재료 파싱 서비스인 Zestful을 출시할 당시, 잠재 고객이 서비스를 부담 없이 체험해 볼 수 있는 방법을 만들고 싶었다. 다른 서비스들은 계정을 만들거나 신용카드를 등록해야 했지만, 나는 Zestful 웹사이트에 마찰 없는 데모를 제공하고 싶었다:

데모는 사용자당 하루 30회 파싱으로 제한해야 했다. 그 이후에는 유료 플랜에 가입해야 했다. 유료 서버와 API 인터페이스는 동일하지만, 하루 30개 재료로 사용량을 제한하는 데모 서버를 만들기로 했다.

당시 나는 App Engine을 좋아했고 직접 데이터베이스를 운영하는 걸 싫어했다. 그래서 Python 2.7 App Engine과 Google Cloud Datastore를 이용해 데모 앱을 만들었다.

요청이 들어오면 데모 서버는 Google Cloud Datastore에서 사용자의 IP 주소를 조회했다. 해당 IP가 할당량을 모두 사용했다면 서버는 유료 플랜 가입을 안내하는 오류와 함께 요청을 거부했고, 할당량이 남아 있다면 요청을 유료 Zestful 서버로 전달한 뒤 클라이언트 IP에 연결된 할당량에서 1을 차감했다.

2018년 이후 App Engine과 Google Cloud 전반에 대한 애정이 식었다. 몇 달 안에 Python 2.7용 App Engine을 종료한다는 Google의 공지를 받았을 때, 오늘날 같은 서비스를 얼마나 더 빠르게 구현할 수 있을지 실험해 보면 재미있겠다고 생각했다.

Python 대신 Go를 사용했는데, Go 웹 앱이 구축하고 유지 관리하기 쉽다고 생각하기 때문이다. SQLite와 Litestream을 이용해 데이터베이스를 어떻게 설계할지 고민하다가, 영구 저장소를 아예 생략할 수 있다는 것을 깨달았다.

모두의 할당량을 메모리에 보관하면 단점이 뭘까? 새 버전을 배포하거나 서버를 재시작할 때마다 모두의 할당량이 그날 초기화되어 데모 서버에 대해 추가 요청을 할 수 있게 된다는 것이다.

재시작할 때마다 사용자당 0.60달러 상당의 추가 할당량을 제공하는 것은 큰 문제가 아니었다. 특히 서버를 자주 재시작할 계획이 없었다는 점을 고려하면 더욱 그랬다.

나는 약 6시간의 개발 시간 만에 서비스를 재구현했다. 원래 버전을 만드는 데 2주가 걸렸던 기억이 나서 스스로 대견하게 느껴졌다. 불과 5년 만에 10배나 빨라진 셈이었다!

그러다 원래 App Engine 버전의 커밋 기록을 확인해보니, 실제로는 단 하루 만에 구현했다는 것을 알게 됐다.

Mon Apr 30 00:51:48 2018 -0400  Adding badges to README (#7)
Mon Apr 30 00:51:40 2018 -0400  Adding changes to make prod API work (#6)
Mon Apr 30 00:43:55 2018 -0400  Adding support for parser config model (#5)
Sun Apr 29 23:51:03 2018 -0400  Adding deployment to Travis (#4)
Sun Apr 29 23:41:42 2018 -0400  Adding rate limiter (#3)
Sun Apr 29 18:18:37 2018 -0400  Adding coveralls.yml (#2)
Sun Apr 29 18:14:46 2018 -0400  Merge pull request #1 from mtlynch/parser-proxy
Sun Apr 29 18:11:16 2018 -0400  Fixing response handler
Sun Apr 29 17:52:28 2018 -0400  Fixing HTTP handler
Sun Apr 29 17:40:02 2018 -0400  Adding in ParserProxy and tests
Sun Apr 29 11:20:11 2018 -0400  Initial commit

커밋 기록을 보면 일요일 아침부터 월요일 새벽 1시까지 이어진 마라톤 코딩 세션이었으니, 원래 작업은 아마 14시간 정도 걸렸을 것이다. 그러면 속도 향상은 2.3배 정도인 셈이다.

그러니 5년 전보다 그렇게까지 빨라진 건 아니지만, 데이터베이스를 생략해 단순화할 새로운 기회를 포착할 수 있게 된 점은 자랑스럽다. 또한 새로운 기술을 계속 학습해 과거보다 더 많은 해결책을 활용할 수 있게 된 것도 기쁘다.

마무리

무엇을 해냈나?

• 제품 하나를 3PL 업체로 전환했다.
• NERD Summit에서 발표했다.
• 새로운 회계사를 찾고 2022년 세금 신고를 위한 대부분의 준비 작업을 마쳤다.

배운 점

• 중요한 업무를 새로운 업체에 넘기기 전에 제한적인 시범 운영을 하라.
  • 물류 업무를 한 번에 3PL 업체에 넘기려 했다면 매우 혼란스러웠을 것이다.
  • 제한적인 시범 운영으로 첫 번째 업체가 맞지 않음을 판단해 걸러내고, 두 번째 업체와의 거친 부분들을 다듬을 수 있었다.

다음 달 목표

• 모든 제품을 3PL 업체로 전환하기.
• TinyPilot 기기 조립을 맡을 위탁 제조사를 선정하고 전환 과정을 시작하기.
• TinyPilot Pro 신규 버전을 출시하기.

도움이 필요한 부분

혹시 하드웨어 제품의 위탁 제조와 관련해 경험이 있는 분, 혹은 그런 분을 소개해 줄 수 있는 분이 있다면 이야기를 나누고 싶다. 특히 연간 2,000~5,000대 정도의 적은 물량으로 전자 제품을 다뤄본 분들의 경험에 관심이 많다.