한 줄 요약

장기 과제가 멈추면 걱정해야 합니다.

하이라이트

• TinyPilot가 월 매출 11만 2천 달러를 기록하며 처음으로 10만 달러 고지를 넘어섰습니다.
• TinyPilot 풀필먼트 팀의 여유 역량을 크게 과대평가했습니다.
• 장기 과제는 자원 고갈이 임박했음을 알리는 카나리아가 될 수 있습니다.

목표 달성도

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

TinyPilot 풀필먼트를 3PL 업체로 전환할 준비

• 결과: 물량이 적은 단일 제품으로 온보딩을 시작했습니다
• 등급: B

현지 스태프에게 이 작업을 할 여유가 얼마나 있을지 과소평가했습니다. 예상치 못한 판매 급증까지 겹치면서 사내 풀필먼트 워크플로를 3PL 업체에 맞게 전환하는 작업은 진척되지 못했습니다. 그래도 불완전한 프로세스라도 일단 진행하면서, 3PL 업체가 우리 시간을 확보해 주는 대로 개선해 나갈 수 있습니다.

신규 지원 엔지니어 온보딩 지속

• 결과: 두 명의 지원 엔지니어가 지원 티켓의 약 80%를 도움 없이 처리하고 있습니다.
• 등급: A

지원 엔지니어링 팀이 예상보다 더 빠르게 자리 잡고 있습니다. 고급 지원 요청을 처리하는 것은 물론, 애초에 버그가 발생하지 않도록 심층 조사를 진행하고 TinyPilot의 진단 로깅을 개선하고 있습니다.

제가 크리티컬 패스에 있는 프로젝트 줄이기

• 결과: 새로운 프로젝트를 시작하고 싶은 충동을 억눌렀습니다.
• 등급: B

새로운 TinyPilot 모델을 출시할 때마다 제 시간이 많이 듭니다. 이 과정을 여러 번 겪어 많은 일을 예상할 수 있게 됐지만, 아무리 철저히 계획해도 예상하지 못한 일이 반드시 생긴다는 것도 알고 있습니다. 여유가 있는 것처럼 느껴지는 날이 있어도, 제 시간을 최대한 비워 두려고 노력하고 있습니다.

TinyPilot 통계

TinyPilot가 또다시 역대 최고 판매를 기록하며 총 매출 11만 1,916달러에 도달했습니다. TinyPilot가 처음으로 월 매출 10만 달러를 넘긴 달입니다.

이번 급증은 홈랩 애호가들에게 가장 인기 있는 유튜브 채널 중 하나인 Linus Tech Tips에서 TinyPilot를 긍정적으로 언급한 덕분이 컸습니다. 리뷰 자체는 주로 경쟁사 제품에 관한 것이었지만, 구독자가 워낙 많다 보니 이후 2주간 TinyPilot 주문량이 크게 늘었습니다.

비용이 비정상적으로 높았던 와중에도 3개월 이동 평균 수익이 안정적으로 흑자를 유지하고 있어 다행입니다. TinyPilot는 정상 생산량을 넘어서는 케이스를 3D 프린팅하느라 프리미엄 비용을 지불하고 있지만, 1월에 메탈 케이스로 전환하면 비용이 크게 낮아질 것입니다.

시간을 절약할 시간조차 없습니다

11월 목표 중 하나는 풀필먼트를 제3자 물류(3PL) 업체로 전환하기 시작하는 것이었습니다. 풀필먼트 팀원 한 명에게 워크플로를 검토하고 3PL 업체에 인계할 준비를 해 달라고 부탁했습니다.

다음 주에 Linus Tech Tips 영상으로 주문이 급증하면서 3PL 전환 검토는 전혀 진척되지 못했습니다. 2주가 지나도 여전히 급증한 판매량을 처리하느라 바빠 추가 진척이 없었습니다.

다음에 풀필먼트 담당자와 미팅했을 때, 이런 비정기적인 업무에 평소 얼마나 여유가 있는지 물었고, 사실상 0에 가깝다는 답을 듣고 놀랐습니다. 기기를 조립하고 주문을 발송하며 지원 요청에 대응하는 단기 업무만으로도 일주일 근무 시간을 모두 채우기에 충분했습니다.

익숙한 상황이지만, 보통 단기 업무로 여유가 없는 사람은 저였습니다.

어떤 워크플로든 시간을 확보할 수 있는 뻔한 방법들이 있습니다. 자동화하거나, 인력을 추가하거나, 매니지드 서비스로 옮기는 식입니다. 문제는 워크플로를 바꾸는 데 마찰 비용이 든다는 점입니다.

지난 몇 달 동안 저는 아웃소싱과 위임에 따른 시간 투입량을 보여 주는 그래프를 열심히 그려 왔습니다. 그런 맥락에서, 누군가를 고용해 업무를 넘기기 전후로 제가 투입하는 시간은 다음과 같습니다.

처음에는 제가 모든 일을 직접 하므로 업무에 많은 시간이 듭니다. 누군가를 고용하면 제가 직접 업무를 계속해야 하는 데다 채용과 교육 업무까지 더해져 오히려 일이 더 많아집니다. 새로 온 직원이 완전히 숙련되어야 순수익이 발생하는데, 업무 복잡도에 따라 몇 주에서 몇 달이 걸릴 수 있습니다.

현실적으로 하루에 쓸 수 있는 시간은 한정되어 있습니다. 하루 근무 시간의 한계를 고려하면 어떻게 될까요?

이런, 이제는 누군가를 채용하고 교육할 단기적 여유가 없어 채용 이후 상태에 도달할 수 없습니다. 스스로 시간을 아끼기 위한 시간조차 없는 셈입니다.

장기 과제를 소진의 조기 경보로 활용하기

3PL 업체로의 전환 지연을 겪으며 여유 역량이 바닥나는 것을 더 일찍 감지할 시스템이 필요하다는 것을 깨달았습니다.

지금으로선 가장 좋은 아이디어는 모든 구성원의 단기 과제와 장기 과제의 균형을 더 의식적으로 관리하는 것입니다. 예를 들어 지원 엔지니어의 시급한 책임은 TinyPilot 도움말 포럼과 CRM 플랫폼에서 고객 지원 요청에 대응하는 것입니다. 지원 요청량은 오르내리므로, 지원 엔지니어들은 여유가 생기면 지원 요청에서 반복되는 패턴을 찾아 도움말 문서를 작성하거나 더 근본적인 버그 수정을 모색합니다.

TinyPilot의 모든 팀원은 단기 과제와 장기 과제를 함께 맡고 있습니다.

장기 과제는 광산 속 카나리아 역할을 할 수 있습니다. 팀의 장기 과제 진행 속도가 점차 느려지면, 해당 팀이 최대 역량에 가까워지고 있다는 신호일 가능성이 높습니다. 그 시점에 저는 책임을 줄이거나 역량을 추가해 부하를 덜어 줄 방법을 찾아야 합니다.

장기 과제를 경고 신호로 활용하는 데에는 두 가지 어려움이 있습니다. 첫째는 장기 과제를 가장 자주 외면하는 팀이 창업자 팀, 즉 바로 저라는 점입니다. 제가 과부하 상태이면 다른 팀의 장기 과제 진행 둔화를 알아차리지 못합니다. 알아차린다 해도 대응할 시간이 없습니다. 결국 제가 맡는 프로젝트 수를 더 엄격히 관리해 전환 비용에 쓸 여유를 남겨 두는 것이 해법이라고 생각합니다.

다른 문제는 풀필먼트 팀의 장기 과제가 가장 모호하다는 점입니다. 제조 및 풀필먼트 프로세스는 매주 개선할 수 있는 성격의 워크플로가 아닙니다. 하지만 풀필먼트와 제조를 외부 업체로 이전하면서 풀필먼트 팀의 역할은 고객 지원 쪽으로 옮겨 갈 것입니다. 고객 지원은 지원 요청에 응대하는 단기 업무와 내부 플레이북을 다듬는 장기 업무 사이에 더 자연스러운 균형이 있습니다.

Ansible의 늪에서 빠져나오기

Ansible은 서버를 자동으로 구성하는 도구입니다. 저는 7년째 Ansible을 사용하고 있으며, 홈랩의 모든 가상 머신을 이 도구로 관리합니다.

2020년 TinyPilot 작업을 시작했을 때, Raspberry Pi에 코드를 배포하고 TinyPilot에 필요한 OS 기능을 구성할 방법이 필요했습니다. 원격 시스템 구성이야말로 Ansible의 주특기라 잘 맞는 선택이었습니다.

TinyPilot를 공개했을 때, 사용자가 가장 쉽게 설치할 수 있는 방법은 제가 개발 중에 사용하던 워크플로를 그대로 재현하는 것이었습니다. Ansible 환경을 부트스트랩한 뒤 Ansible로 TinyPilot를 설치하는 간단한 설치 스크립트를 만들었습니다.

당시에도 더 일반적인 설치 방식은 Debian 패키지를 쓰는 것이라는 걸 알고 있었습니다. 문제는 Debian 패키지를 만드는 법을 전혀 몰랐고, 작업량이 많아 보였다는 점입니다. 직접 apt 저장소를 구축해야 하나? 저장소 키는 어떻게 관리하지? TinyPilot는 nginx에 의존하는데 내 패키지에서 nginx를 어떻게 구성해야 하지?

2년 반이 지난 지금, 개발팀은 제가 Ansible을 선택한 대가를 치르고 있습니다. TinyPilot에 기능이 늘어나면서 Ansible 설정은 고통스러울 정도로 복잡해졌습니다. 설치 프로그램이 순수 셸 스크립트나 Debian 패키지였다면 설치와 업데이트에 10~20초면 충분했을 텐데, Ansible의 오버헤드 때문에 6분 이상 걸립니다.

최종 사용자에게 미치는 영향뿐 아니라, Ansible은 개발 리소스를 잡아먹는 경향이 있습니다. Ansible 코드는 디버깅이 느리고 지루하며, 특히 지속적 통합 환경에서 사용할 수 없는 운영체제나 아키텍처를 다룰 때는 더욱 그렇습니다. 사소한 변경도 종종 일주일 치 개발 시간으로 불어나곤 합니다.

지난 몇 달 동안 개발팀은 Ansible 코드를 TinyPilot용 Debian 패키지로 옮기는 방법을 모색해 왔습니다. 이제 발판을 마련했다고 기쁘게 보고드립니다. TinyPilot의 Ansible 역할(role)이 최신 TinyPilot Debian 패키지를 설치하는 하이브리드 솔루션을 만들었습니다. 덕분에 Ansible 코드를 조금씩 덜어내 Debian 패키지로 옮기기가 한결 수월해졌습니다.

TinyPilot를 시작할 때 Debian에 대해 미리 알았더라면 좋았을 내용들입니다.

• 자체 apt 저장소를 운영하지 않고도 독립형 Debian 패키지를 만들고 배포할 수 있습니다.
• 올바른 튜토리얼을 따라 하면 간단한 Debian 패키지 하나 만드는 데 15분이면 충분합니다. 해당 튜토리얼을 참고하세요.
• Docker QEMU를 이용하면 x64 시스템에서 ARM용 Debian 패키지를 빌드할 수 있습니다.
• 코드가 Python 같은 이식성 높은 언어라면 QEMU를 건너뛰고 아키텍처 독립적인 Debian 패키지를 빌드할 수 있습니다.
• 패키지가 다른 패키지를 구성해야 할 경우, 그 패키지가 소유한 파일을 직접 건드리기보다 설정 디렉터리에 파일을 추가하는 것이 일반적인 방법입니다.
  • 예를 들어 TinyPilot Debian 패키지는 /etc/nginx/sites-enabled/ 디렉터리에 파일을 추가해 nginx를 구성할 수 있습니다.

Debian을 배우면서 가장 어려웠던 점은 수많은 정보 속에서 유용한 내용을 가려내는 것이었습니다. 많은 자료가 사실상 “9,000쪽짜리 Debian 관리자 가이드를 읽되, 오래된 부분은 무시하세요”라고 말하는 수준이었습니다.

제가 가장 도움이 된다고 느낀 가이드는 다음과 같습니다.

• Alex Couture-Beil의 “나만의 deb 패키지와 apt 저장소 만들고 호스팅하기”
• Vincent Bernat의 “실용적인 Debian 패키징”

Vincent는 심지어 영상 통화에 응해 Debian 패키지에 대한 남은 질문들에 친절히 답해 주었습니다.

사이드 프로젝트

ScreenJournal

저는 TV 프로그램과 영화를 많이 보고, 친구들에게 추천하는 것을 좋아하지만, 정작 추천하려 할 때 어떤 작품이었는지 잊어버리곤 합니다.

Goodreads로 독서를 기록하듯 영화와 TV를 기록할 수 있는 앱을 찾아봤지만, 제가 생각한 것과 맞는 것은 없었습니다. 친구들은 기본값이 공개인 소셜 앱에 지쳐 있다고 느꼈고, 저는 추천을 공유하고 싶은 소수의 친구들로 작은 커뮤니티를 만들 수 있는 무언가를 원했습니다. 트위터보다는 디스코드에 가깝습니다.

친구들과 영화 리뷰를 공유하는 앱을 만들기 시작했습니다. 이름은 ScreenJournal입니다.

아직 본격적으로 공개할 단계는 아닙니다. 리뷰가 비공개이고 단일 사용자만 지원하기 때문입니다. 지금으로선 1인용 비공개 영화 일기장 정도이지만, 다음으로 구현할 기능은 다중 사용자 지원입니다.

사용자 관리는 제대로 구현하기가 악명 높게 어렵기 때문에, 저는 늘 직접 구현하는 것을 피해 왔습니다. 지난 몇 년간 친구인 David Toth가 만든 UserKit 서비스로 사용자를 관리해 왔습니다. UserKit은 훌륭했지만 아직 공개 서비스가 아니라, ScreenJournal을 자기 서버에서 직접 운영하고 싶은 다른 개발자에게는 실용적이지 않습니다.

Go용 오픈소스 사용자 관리 프레임워크를 찾아봤지만, 대부분 외부 서비스의 OAuth에 의존했고 저는 그 방식을 원치 않았습니다. 나머지는 너무 무겁고 복잡해서 쓰고 싶지 않았습니다.

대신 무모하게 직접 사용자 관리를 구현하고 있습니다. 세션 관리는 jeff를, 인증은 bcrypt를 사용하고, 잘 되기를 바랄 뿐입니다.

마무리

무엇을 했나요?

• 3PL 업체와의 온보딩을 시작했습니다.
• 여러 중요한 측면에서 TinyPilot Debian 패키지를 개선했습니다.
• 해외 계약자를 위한 더 나은 결제 플랫폼을 찾았습니다.
  • Deel은 경험이 좋지 않았고 Remote.com도 그다지 마음에 들지 않아, Pilot으로 가기로 했습니다.

배운 점

• 장기 과제는 자원 고갈을 알리는 좋은 선행 지표입니다.
  • 팀의 장기 과제 진행이 지속적으로 느려지면, 프로세스를 전환할 숨 돌릴 틈이 사라지기 전에 대응하는 것이 중요합니다.
  • 창업자가 장기 과제를 위한 시간을 확보하는 것이 특히 중요합니다. 그렇지 않으면 다른 팀의 자원 고갈에 효과적으로 대응할 수 없기 때문입니다.
• Debian 패키징은 처음 생각만큼 어렵지 않습니다.

다음 달 목표

• 3PL 업체에서 첫 주문을 처리합니다.
• 다음 TinyPilot Pro 릴리스의 코드 컴플리트를 달성합니다.
• 1월에 출시할 TinyPilot Voyager 2a를 준비합니다.