한 줄 요약

익일 배송: 얼마나 어렵겠어?

하이라이트

• 익일 배송 옵션을 제공하는 데 생각보다 훨씬 많은 어려움을 겪었습니다.
• Handmade Seattle 컨퍼런스에 참석했습니다.
• Zig와 오픈소스 AI 챗봇을 실험해 봤습니다.

목표 평가

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

위탁 제조업체로 생산 이전을 최대한 빠르게 완료하기

• 결과: 이전을 완료했습니다.
• 평가: A

제조업체가 이제 우리가 직접 조립하던 때와 동일한 품질로 TinyPilot 기기를 생산하고 있습니다. 제조업체가 이제 기기들을 바로 3PL 창고로 배송하므로 TinyPilot이 자체 사무실을 유지해야 할 필요성이 사실상 사라졌습니다.

고객 인터뷰 5회 진행하기

• 결과: 고객 세 명에게 연락했지만 실제 통화는 한 건도 성사되지 않았습니다.
• 평가: F

이번에는 우선순위를 두는 것을 잊었습니다. 컨퍼런스와 휴가로 거의 2주를 통째로 비웠고, 고객 서비스 팀도 평소보다 여유가 없었습니다. 사업의 장기적인 지속 가능성을 위해 계속 투자해야 할 영역인 만큼, 팀에 더 적극적으로 후속 조치를 하며 우선순위를 챙겼어야 했습니다.

TinyPilot 사무실의 모든 구형 재고와 예비 부품 정리하기

• 결과: 이 작업을 잠시 보류하기로 했습니다.
• 평가: 해당 없음

알고 보니 건물주가 퇴거 시점에 대해 꽤 유연해서 사무실을 비워야 할 급박함이 생각보다 덜했습니다. 또 그냥 쓰레기통에 버리지 않고 사무실을 비우는 일이 예상보다 훨씬 어렵다는 것도 알게 됐습니다. 개당 1~50달러 정도의 가치는 있지만 종류별로 몇 개씩밖에 없는 물건이 수십 가지나 됩니다.

예를 들어 중고 Arduino Uno 보드가 세 개 있습니다. 개당 정가는 28달러입니다. eBay에 세 개를 올려봐야 총 30달러 정도 받을 수 있을 텐데, 처음부터 끝까지 처리하는 데 두 시간 정도가 걸립니다. 그러면 보드를 팔아 버는 돈보다 직원 인건비가 더 많이 드는 셈입니다.

새로 세운 계획은 이사 시기가 가까워질 때까지 기다렸다가, 사람들이 와서 원하는 것은 무료로 가져갈 수 있는 시간을 공지하는 것입니다.

TinyPilot 통계

수익이 무섭게 보이지만, 위탁 제조업체로 전환하면서 지출이 더 ‘뭉치는’ 형태가 되었기 때문일 뿐입니다. 10월에는 원자재 비용 청구가 없었지만, 11월에는 원자재 비용으로 5만 7천 달러가 나왔습니다. 사실 이 비용은 매출원가로 보고해야겠지만, 당분간은 단순 현금 흐름 차이로만 보고하고 있습니다.

8만~10만 달러가 TinyPilot의 정상적인 매출 범위이며, 우리는 그 안에 안정적으로 들어와 있습니다. 블랙 프라이데이/사이버 먼데이 기회를 활용해 볼 수도 있었겠지만, 제조 공정 전환 때문에 재고가 부족해 가격을 내릴 만큼 물량이 충분하지 않았습니다.

익일 배송: 얼마나 어렵겠어?

TinyPilot이 사업을 운영해 온 대부분의 기간 동안 우리는 당일 배송이나 익일 배송을 제공하지 않았습니다.

직접 주문을 처리하던 시절에는 6일 동안 사무실을 운영하며 주문을 처리했지만, 하루에 한 명만 근무했습니다. 누군가 아프거나 휴가를 가면 하루 만에 발송하는 것이 불가능한 상황이 생길 것을 알았기 때문에 익일 배송을 제공하지 않았습니다.

주문 처리를 제3자 물류 창고(3PL)로 옮기면서 인력 부족에 대한 취약성은 사라졌습니다. 3PL은 우리보다 훨씬 더 많은 인력 여유를 갖추고 있어 무슨 일이 있어도 주문이 영업일 기준 하루 안에 출고됩니다.

3PL로 전환하면서 마침내 익일 배송 옵션을 제공할 수 있게 됐습니다!

복잡한 배송 스택

3PL로 전환하면서 배송 옵션을 관리하는 로직은 더 복잡해졌습니다. 예전에 TinyPilot 고객에게 배송 옵션을 제시하던 방식은 다음과 같았습니다.

1. 내가 Shopify에서 고객에게 제공할 배송 옵션을 선택합니다.
2. 고객이 결제 시 배송 옵션을 선택합니다.
3. 고객이 선택한 배송에 맞춰 Shopify에서 우편 요금을 구매합니다.

이 시스템에서는 Shopify가 경험을 처음부터 끝까지 통제했고, 꽤 잘 해냈습니다.

우리 3PL은 ShipStation이라는 (그다지 좋지 않은) 창고 관리 솔루션을 사용합니다. 이 도구는 우리 Shopify 스토어와 연동되므로, 이제 스택은 이렇게 생겼습니다.

1. ShipStation이 3PL에 지원하는 배송 옵션 목록을 제공합니다.
2. 3PL이 이 목록 중에서 고객사(TinyPilot)에게 제공하고 싶은 배송 옵션을 선택합니다.
3. Shopify가 ShipStation에 조회하여 ShipStation과 3PL이 합의한 배송 옵션을 파악합니다.
4. 내가 Shopify에서 고객에게 제공할 배송 옵션을 선택합니다.
5. 결제 시 ShipStation이 고객에게 “가장 좋은” 옵션이 무엇인지 불투명하게 추측하여 배송 옵션 수를 두세 개로 줄입니다.
6. 고객이 결제 시 배송 옵션을 선택합니다.
7. 3PL이 고객이 선택한 배송에 맞춰 ShipStation이나 다른 업체에서 우편 요금을 구매합니다.

이렇게 많은 주체가 얽혀 있으니 잘못될 수 있는 경우도 엄청나게 많고 서로 책임을 떠넘길 기회도 많습니다.

익일 배송을 활성화하려 했는데, 3PL에서 ShipStation을 거쳐 Shopify를 통해 내게까지 설정이 전달될 때쯤에는 익일 배송 옵션이 하나도 남아 있지 않다는 것을 알게 됐습니다.

수개월 동안 오가며 확인한 끝에 문제를 ShipStation으로 좁혔습니다. ShipStation은 익일 배송과 2일 배송 옵션을 “비슷하다”고 간주하기 때문에 익일 배송 옵션을 표시하지 않는데, 2일 배송 옵션이 항상 더 저렴하므로 익일 배송 옵션은 절대 노출되지 않습니다.

네, 제대로 읽으신 게 맞습니다. 주 업무가 소포 배송용 우편 요금을 판매하는 회사인 ShipStation이 왜 누군가가 2일 배송보다 비싼 익일 배송을 선택하는지 이해하지 못하는 것입니다.

ShipStation 때문에 문제가 너무 많아서 고객에게 배송 옵션을 보여주는 방식은 예전 스택으로 되돌리기로 했습니다. 이제는 그냥 Shopify를 통해 고객에게 배송 옵션과 요금을 보여주고 ShipStation에 요금을 조회하는 과정은 아예 생략합니다.

ShipStation을 결제 과정에서 배제할 때의 문제는 3PL이 더 비싼 ShipStation 요금으로 우편 요금을 결제하는데, Shopify는 더 저렴한 Shopify 요금으로 고객에게 배송비를 청구한다는 점입니다. 예를 들어 고객은 익일 배송비로 30달러만 낼 수 있지만, ShipStation을 통한 실제 우편 요금은 100달러입니다. 그 차액 70달러는 TinyPilot이 부담해야 합니다.

그래도 이 방법 덕분에 TinyPilot은 ShipStation이 어리석게 우리 설정을 덮어쓰지 않고도 원하는 배송 옵션을 제공할 수 있습니다. 그리고 70달러의 추가 배송비를 부담하는 것이 판매 자체를 놓치는 것보다 낫습니다.

익일 배송 고객은 4배 더 까다롭다

대부분의 경우 3PL은 영업일 기준 하루 안에 주문을 발송합니다. 가끔 이틀이 걸리고, 아주 드물게는 사흘이 걸리기도 합니다. 웹사이트에는 처리 기간을 최대 3일까지로 안내해 두었지만, 고객들은 이를 잘 보지 않는 것 같습니다.

일반 배송이나 2일 배송을 선택한 고객의 90%는 처리가 하루 지연되어도 아무 말도 하지 않습니다.

블랙 프라이데이 다음 주 월요일, UPS에 이상한 문제가 생겨 수거해 간 모든 주문에 대해 운송장 추적 정보를 업데이트하지 않았습니다. 창고 측은 UPS가 전부 수거해 갔다고 확언했지만, UPS 추적에는 아무 것도 뜨지 않았습니다.

이 UPS 추적 버그는 익일 배송을 요청한 고객 다섯 명에게 영향을 미쳤습니다. 24시간 안에 그중 두 명이 지연에 대해 항의하는 이메일을 보내왔습니다. 즉, 익일 배송 고객의 40%가 불만을 제기한 반면, 일반 배송이나 2일 배송에서 지연을 인지한 고객은 약 10%에 불과했습니다.

그리고 저는 이해합니다. 제가 익일 배송으로 무언가를 주문했을 때도 빨리 받고 싶고, 판매자가 며칠 동안 묵혀 두면 짜증이 납니다.

이 익일 배송 고객들은 양날의 검입니다. 일반 배송비의 다섯 배를 내고서라도 빨리 받으려는 고객이라면 아마 지출을 아끼지 않는 큰손일 것이고 TinyPilot 매출을 끌어올려 줄 겁니다. 하지만 동시에 꽤 요구가 많고, 대부분의 고객에게는 없는 긴급성에 대한 기대를 갖고 있어 지원 팀을 힘들게 만들 것이라는 점도 알게 됐습니다.

첫 Handmade 컨퍼런스

11월에 시애틀에서 열린 첫 Handmade 컨퍼런스에 참석했습니다. 저수준 소프트웨어를 다루는 사람들을 위한 인디 컨퍼런스입니다.

컨퍼런스에서 얻은 소감은 다음과 같습니다.

인기 있는 기술 스택에도 대안이 있다

데이비드 포스터 월리스는 유명한 2005년 케니언 칼리지 졸업 축사를 물고기에 대한 농담으로 시작했습니다.

두 마리 어린 물고기가 헤엄쳐 가는데, 반대편에서 헤엄쳐 오던 늙은 물고기를 만났습니다. 늙은 물고기가 고개를 끄덕이며 말합니다. “안녕, 얘들아. 물은 어때?” 두 어린 물고기는 조금 더 헤엄쳐 가다가, 결국 한 마리가 다른 한 마리를 쳐다보며 말합니다. “물이 뭐야?”

저에게 웹 브라우저는 물과 같습니다.

저는 소프트웨어를 사용자가 결국 HTML과 JavaScript를 통해 상호작용하는 것으로 생각하는 데 너무 익숙해서 다른 대안이 있다는 사실 자체를 거의 잊고 삽니다. 90년대에 정적 문서를 렌더링하기 위해 만들어진 기술을 중심으로 모든 것을 설계한다는 게 얼마나 이상한 일인지 생각해 본 지도 오래됐습니다.

하지만 Handmade에서 만난 개발자 대부분은 웹 브라우저를 전혀 다루지 않았고, 제가 익숙한 기술들을 사용하지도 않았습니다.

휴대폰과 태블릿에서 소프트웨어를 작성하는 앱인 MobileCode의 개발자를 만났습니다. 어떤 언어를 쓰는지 물었을 때, Flutter나 아마도 React Native라고 답할 줄 알았습니다. 그가 “C”라고 답했을 때 정말 깜짝 놀랐습니다.

게다가 그는 C로 모바일 개발을 하면서 긍정적인 경험을 했다고 했습니다. 현대 프레임워크의 수많은 추상화 계층을 거치지 않고 iOS와 Android의 네이티브 그래픽 API를 직접 호출할 수 있다는 것입니다.

집요한 인디적 야망

애초에 Handmade를 처음 알게 된 이유는 안드레아스 클링을 팔로우하고 있었기 때문입니다. 그는 SerenityOS의 창시자로, 서드파티 라이브러리나 의존성 없이 혼자서 초기 OS를 만들었고 2021년 Handmade에서 자신의 프로젝트를 발표했습니다.

Handmade는 제가 한동안 관심을 가져온 인디 프로그래밍 언어인 Zig에 대한 발표도 끌어들입니다. Zig의 창시자인 앤드루 켈리는 2021년 CoRecursive 팟캐스트에 출연해 세상의 모든 C 코드를 Zig로 교체하고 싶다고 말했습니다.

Adam: C를 무너뜨리면 세상은 어떻게 보일까요?

Andrew: 오, 아름답죠. 대부분은 지금과 비슷하게 보일 거예요. 다만 모든 앱이 조금 더 잘 작동하고, 충돌도 덜하고, 메모리를 덜 쓰고, 그냥 더 빨라질 뿐이죠…

교과서에서 운영 체제가 어떻게 작동하는지, 임베디드 기기가 어떻게 작동하는지 보여주려 할 때, 예제 코드는 Zig를 사용할 거라고 당연하게 가정하게 될 거예요. 모두가 그렇게 하니까요.

저는 앤드루 특유의 야망과 소프트웨어에 대한 열정이 정말 멋지고 흥미롭다고 생각하고, 그것이 바로 제가 Handmade에서 찾으러 간 것이었습니다.

Handmade는 인디적 야망에 대한 제 기대를 충족시켜 줬습니다. 이 컨퍼런스는 바퀴를 재발명하는 행위를 기념했습니다.

소프트웨어 업계에서는 보통 누군가에게 바퀴를 재발명한다고 하면 비난하는 말이지만, Handmade는 이를 포용합니다. 왜 바퀴를 재발명하면 안 되는 걸까요? 어쩌면 당신의 바퀴가 다른 사람들이 쓰는 바퀴보다 더 나을 수도 있습니다. 그리고 바퀴를 재발명하려는 시도만으로도 바퀴가 어떻게 작동하는지 더 잘 이해하게 될 겁니다.

카메론 리케스는 학부생으로, 2D RPG 게임을 만드는 것에 대해 발표했습니다. 그러다 “결국” 직접 3D 게임 엔진을 처음부터 코딩하게 됐습니다.

야세르 아르게예스는 20대 초반으로, 처음부터 새로 만드는 LLVM 대체제인 Tilde를 작업 중입니다. 참고로 LLVM은 20년간 활발히 개발되어 온 컴파일러 백엔드입니다. 그는 발표에서 컴파일러 배경지식이 없다고 언급했지만, Handmade 토론에서 가장 인기 있는 요청 중 하나가 LLVM의 대안이었기 때문에 “그래, 내가 해보지”라고 생각했다고 합니다.

그리고 매우 친절했던 앤드루 켈리를 직접 만날 수 있었습니다. 그 대화가 마침내 저에게 Zig 코드를 직접 작성해 보도록 영감을 주었습니다.

빅테크에 대한 극도의 회의주의

컨퍼런스에 대해 한 가지 불만이 있었다면, 빅테크를 비판하는 어조가 제가 보기엔 비이성적일 정도로 강했다는 점입니다.

컨퍼런스 전반에 걸친 서사는 빅테크가 기본적으로 독이라는 것이었습니다. 그들이 만드는 모든 것은 버그투성이고, 비대하고, 신뢰할 수 없으며, 비싸다는 것입니다.

연사들에 따르면 더 많은 사람들이 빅테크의 단점을 인지하지 못하는 이유는 빅테크가 소프트웨어 컨퍼런스를 장악하고 있기 때문입니다. 그들은 발표자들이 빅테크 소프트웨어의 문제에 대해 솔직하게 말하는 것을 금지한다는 것입니다. 저는 중규모 컨퍼런스에서 몇 차례 발표한 적이 있는데, 빅테크를 비판하지 말라는 말을 들어본 적이 없어서 이 주장은 사실처럼 들리지 않았습니다.

저는 반빅테크 관점에 공감합니다. 가능하면 인디 기술을 선호하지만, 동시에 빅테크가 많은 것을 잘하고 기술 발전을 이끄는 대부분의 무거운 일을 해낸다고도 생각합니다. 단순히 코웃음을 치며 인디가 항상 빅테크보다 낫다고 가정하는 것은 실수라고 생각합니다.

다른 후기

• Carl Sverre

다른 후기를 알고 있다면 알려 주세요. 링크를 추가하겠습니다.

사이드 프로젝트

WanderJest

WanderJest는 몇 년 전 사람들이 근처에서 열리는 라이브 코미디 공연을 찾을 수 있도록 돕기 위해 시작한 웹 앱입니다. 코로나가 터졌을 때 보류했지만, 그 이후로도 틈틈이 만지작거리고 있습니다.

WanderJest의 가장 큰 과제 중 하나는 다가오는 공연에 대한 정보를 알아내는 것이었습니다. 코미디 공연에 대한 가장 표준적인 정보는 보통 다음과 같은 포스터입니다.

공연자들은 포스터를 만들고 나서 모든 정보를 다른 곳에 다시 입력하고 싶어 하지 않으므로, 포스터에서 정보를 “공짜로” 뽑아낼 방법을 고민해 왔습니다.

첫 번째 아이디어는 공연 기획자가 포스터를 만들 수 있도록 돕는 도구를 만드는 것이었습니다. 며칠 동안 이것저것 만져보다가 처음으로 접촉한 코미디언에게 제안했는데, 그는 관심이 없었습니다. 아직 이 아이디어를 완전히 접은 건 아니지만, 계속 개선해 나갈 만큼 열정이 생기지는 않았습니다.

하지만 이제 AI 이미지 인식이 발전하면서, 다른 아이디어는 공연 포스터를 찾아낸 뒤 오픈소스 AI 도구를 사용해 공연 정보를 스크래핑하는 것입니다.

사이먼 윌리슨의 글을 읽고 Llamafile을 사용하는 것이 얼마나 쉬워졌는지 깨달았고, 그래서 포스터 문제에 도전해 봤습니다.

안타깝게도 LLaVA 1.5의 이미지 정확도는 제가 필요로 하는 수준에 미치지 못하는 것 같습니다. 코미디 공연 포스터를 보여주고 질문하면 답의 정확도는 70% 정도에 불과합니다.

설정을 이것저것 만져 봤지만 결과를 개선하지는 못했습니다.

그럼에도 이 분야에서 오픈소스 솔루션들의 발전과 경쟁을 보는 것이 기대됩니다. 자세한 내용은 다음을 참고하세요.

• Rough Experiments with Llamafile and LLaVA 1.5

마무리

무엇을 해냈나?

• TinyPilot Pro 2.6.2 출시
• Handmade Seattle 컨퍼런스 참석
• 주요 공급업체 중 한 곳과의 배송 내보내기 문제 해결

배운 점

• 익일 배송은 더 많은 지출을 기꺼이 하는 고객을 끌어들이지만, 그 고객들은 요구 수준도 더 높다.

다음 달 목표

• TinyPilot 라이선스 검사를 위한 설계 작업 완료하기.
• 신규 기기 제조 배치마다 샘플 검사를 위한 프로세스 만들기.
• TinyPilot 연말 세무 업무 처리하기.