한 줄 요약

익일 배송, 뭐 그리 어렵겠어?

하이라이트

• 익일 배송 옵션을 제공하는 데 생각보다 훨씬 애를 먹었습니다.
• Handmade Seattle 컨퍼런스에 다녀왔습니다.
• Zig와 오픈소스 AI 챗봇을 실험해 봤습니다.

목표 성적표

매달 초에 달성하고 싶은 목표를 정합니다. 이번 달에는 그 목표들을 얼마나 달성했는지 돌아보겠습니다.

계약 제조사로 생산 이전을 최대한 빨리 완료하기

• 결과: 이전을 완료했습니다.
• 성적: A

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

고객 인터뷰 5회 진행하기

• 결과: 세 명의 고객에게 연락을 시도했으나 실제 인터뷰는 한 건도 성사되지 않았습니다.
• 성적: F

이번에는 제가 우선순위 관리를 제대로 하지 못했습니다. 컨퍼런스와 연휴 이동으로 거의 2주를 통째로 비웠고, 고객 지원팀도 평소보다 여유가 없었습니다. 비즈니스의 장기적인 지속 가능성을 위해 꼭 필요한 투자인 만큼, 팀과 더 긴밀히 소통하며 우선순위를 챙겼어야 했습니다.

TinyPilot 사무실의 기존 재고와 예비 부품 모두 정리하기

• 결과: 진행을 잠시 보류하기로 했습니다.
• 성적: 해당 없음

알고 보니 임대인은 퇴거 시점에 대해 꽤 유연해서, 생각했던 것보다 사무실을 비워야 할 급박함이 크지 않았습니다. 또 모든 걸 그냥 버리지 않고 정리하려니 생각보다 훨씬 어려웠습니다. 개당 1~50달러 정도의 가치가 있는 물건이 수십 가지 있는데, 종류별 수량은 몇 개 되지 않습니다.

예를 들어 중고 Arduino Uno 보드가 세 개 있습니다. 새 제품 정가는 28달러입니다. 세 개를 eBay에 팔면 합쳐서 30달러 정도 받을 수 있겠지만, 등록부터 발송까지 전 과정을 처리하는 데만 두 시간 가까이 걸립니다. 결국 보드를 팔아 남는 돈보다 직원 인건비가 더 많이 드는 셈입니다.

새 계획은 퇴거 시점이 가까워지면 공지를 올려, 원하는 분들이 사무실에 들러 필요한 물건을 무료로 가져가도록 하는 것입니다.

TinyPilot 통계

순이익이 무섭게 보이지만, 계약 제조사로 전환하면서 비용 지출이 한꺼번에 몰리는 ‘뭉침’ 현상 때문일 뿐입니다. 10월에는 원자재 비용 청구가 전혀 없었지만, 11월에는 원자재 비용으로 5만 7천 달러가 나갔습니다. 이 비용을 매출원가로 잡아야 맞지만, 지금은 단순한 현금 흐름 차이로만 기록하고 있습니다.

TinyPilot의 평소 매출 범위는 8만~10만 달러이며, 이번 달도 그 범위 안에 무난히 들어갑니다. 블랙프라이데이·사이버먼데이 기회를 활용해 볼 수도 있었겠지만, 제조 방식 전환 때문에 재고가 부족해 가격을 내릴 만큼 물량이 충분하지 않았습니다.

익일 배송, 뭐 그리 어렵겠어?

TinyPilot은 대부분의 기간 동안 당일·익일 배송을 제공하지 않았습니다.

직접 주문을 처리하던 시절에는 주 6일 사무실에 상주하며 주문을 처리했지만, 하루에 근무하는 인원은 한 명뿐이었습니다. 누군가 아프거나 휴가를 가면 하루 만에 발송하는 게 불가능해질 수 있어 익일 배송을 제공하지 않았습니다.

물류를 외부 전문 업체(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 때문에 문제가 계속되자, 고객에게 배송 옵션을 보여주는 방식을 예전 스택으로 되돌리기로 했습니다. 이제는 ShipStation에서 요금을 조회하지 않고, Shopify를 통해 배송 옵션과 요금을 그대로 보여줍니다.

ShipStation을 결제 과정에서 빼버리면 생기는 문제는, 3PL이 더 비싼 ShipStation 요금으로 우편 요금을 결제하는데, Shopify는 더 저렴한 Shopify 요금 기준으로 고객에게 배송비를 받는다는 점입니다. 예를 들어 고객은 익일 배송비로 30달러만 냈는데, ShipStation을 통한 실제 우편 요금은 100달러인 식입니다. 그 차액 70달러는 TinyPilot이 부담해야 합니다.

그럼에도 이 방식 덕분에 ShipStation이 어설프게 개입해 덮어쓰는 일 없이 저희가 원하는 배송 옵션을 제공할 수 있게 됐습니다. 70달러의 추가 배송비를 떠안는 것이 판매 자체를 놓치는 것보다 낫습니다.

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

대부분의 경우 3PL은 영업일 기준 하루 안에 주문을 출고합니다. 가끔 일이 생겨 이틀이 걸리기도 하고, 아주 드물게는 사흘이 걸리기도 합니다. 웹사이트에는 처리 기간을 최대 3일로 안내하고 있지만, 고객들은 이를 크게 신경 쓰지 않는 듯합니다.

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

블랙프라이데이 다음 주 월요일, 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를 쓰니까 당연히 Zig를 예제 코드로 쓰게 될 겁니다.

앤드루 특유의 소프트웨어에 대한 야망과 열정이 정말 멋지고 흥미진진하다고 생각하는데, 바로 그것을 찾아 Handmade에 갔습니다.

Handmade는 제 기대대로 인디적 야망을 마음껏 보여줬습니다. 이 컨퍼런스는 바퀴를 재발명하는 일을 기념합니다.

소프트웨어 업계에서 바퀴를 재발명한다는 건 보통 비난에 가깝지만, Handmade는 이를 포용합니다. 왜 바퀴를 재발명하면 안 되나요? 어쩌면 당신이 만든 바퀴가 모두 쓰고 있는 바퀴보다 더 좋을지도 모릅니다. 그리고 바퀴를 재발명하려는 시도 자체만으로도 바퀴가 어떻게 작동하는지 훨씬 잘 이해하게 됩니다.

학부생인 캐머런 리케스는 2D RPG 게임을 만들던 발표를 했습니다. 그러다 결국 직접 3D 게임 엔진을 처음부터 만들어 버렸다고 합니다.

20대 초반의 야세르 아르게예스는 20년간 활발히 개발되어 온 컴파일러 백엔드인 LLVM을 처음부터 다시 만드는 Tilde를 작업 중입니다. 발표에서 야세르는 컴파일러를 전공한 적은 없지만, 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 연말 세무 업무를 처리한다.