한 줄 요약

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

하이라이트

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

목표 평가

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

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

• 결과: 물량이 적은 단일 제품으로 온보딩 절차를 시작했다
• 평가: B

이 작업을 맡을 현지 인력의 여유 역량을 과소평가했다. 예상치 못한 판매량 급증까지 겹치면서 사내 풀필먼트 워크플로를 3PL 업체에 맞게 전환하는 작업은 진척이 없었다. 그래도 불완전한 프로세스라도 일단 앞으로 나아가고, 3PL 업체가 우리 시간을 확보해주면 점차 개선해 나갈 수 있다.

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

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

지원 엔지니어링 팀이 예상보다 더 효율적으로 자리 잡고 있다. 고난도 지원 요청을 처리하는 것은 물론, 버그 자체를 줄이기 위한 심층 분석을 수행하고 TinyPilot의 진단 로깅을 개선하고 있다.

내가 병목이 되는 프로젝트 줄이기

• 결과: 새로운 프로젝트를 시작하고 싶은 충동을 잘 참아냈다.
• 평가: B

새로운 TinyPilot 모델을 출시할 때는 항상 내 시간이 많이 들어간다. 이 과정을 여러 번 겪어봐서 해야 할 일을 상당 부분 예측할 수 있게 됐지만, 아무리 계획을 세워도 예측하지 못하는 일은 반드시 생긴다는 것도 알고 있다. 여유가 있다고 느껴지는 날이 있더라도 가능한 한 내 시간을 최대한 비워두려고 노력하고 있다.

TinyPilot 통계

TinyPilot은 또다시 역대 최고 판매량을 기록하며 총 매출 11만 2천 달러를 달성했다. TinyPilot 역사상 처음으로 월 매출이 6자리 수를 넘은 달이다.

이번 급등은 홈랩 애호가들에게 가장 인기 있는 유튜브 채널 중 하나인 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 메인테이너 가이드를 그냥 읽되, 오래된 부분은 무시하세요”라고 말하는 수준이었다.

내가 가장 도움이 된다고 느낀 가이드는 다음과 같다:

• “Creating and hosting your own deb packages and apt repo” by Alex Couture-Beil
• “Pragmatic Debian packaging” by Vincent Bernat

Vincent는 심지어 화상 통화에 응해 Debian 패키지에 대한 나의 남은 질문들에 답해주기까지 했다.

사이드 프로젝트

ScreenJournal

나는 TV 프로그램과 영화를 많이 보고 친구들에게 추천하는 걸 좋아하지만, 정작 어떤 작품을 추천하려 했는지 자주 잊어버린다.

Goodreads로 독서를 기록하듯 영화와 TV를 기록할 수 있는 앱을 찾아봤지만, 내가 원하는 것과 맞는 건 없었다. 내 친구들은 기본값이 공개인 소셜 앱에 지쳐 있는 것 같아서, 추천을 공유하고 싶어 하는 친구들끼리 작은 커뮤니티를 만들 수 있는 무언가를 원했다. 트위터보다는 디스코드에 가까운 느낌이다.

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

아직 리뷰가 비공개이고 단일 사용자만 지원해서 본격적으로 공개할 단계는 아니다. 지금은 한 사람이 쓰는 비공개 영화 일기로만 쓸 수 있지만, 다음으로 구현할 기능은 다중 사용자 지원이다.

사용자 관리는 제대로 구현하기가 악명 높게 어려워서, 나는 항상 직접 구현하는 걸 피해 왔다. 지난 몇 년 동안은 친구인 David Toth의 UserKit 서비스를 이용해 사용자를 관리했다. UserKit은 훌륭했지만 아직 공개되지 않아 ScreenJournal을 자신의 서버에서 운영하려는 다른 개발자들이 쓰기에는 부적합하다.

Go용 오픈소스 사용자 관리 프레임워크를 찾아봤지만, 대부분은 내가 원하지 않는 외부 서비스의 OAuth에 의존하고 있었다. 나머지는 너무 무겁고 복잡해서 쓰고 싶지 않았다.

그래서 위험을 감수하고 직접 사용자 관리를 구현하고 있다. 세션 관리는 jeff를, 인증은 bcrypt를 사용하고 잘 되길 바랄 뿐이다.

마무리

무엇을 해냈나?

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

배운 점

• 장기 과제는 자원 고갈을 예측하는 좋은 선행 지표다.
  • 어떤 팀의 장기 과제 진행이 지속적으로 느려진다면, 프로세스를 전환할 여유가 완전히 사라지기 전에 대응하는 것이 중요하다.
  • 파운더는 다른 팀의 자원 고갈에 효과적으로 대응하기 위해 장기 과제를 위한 시간을 확보하는 것이 특히 중요하다.
• Debian 패키징은 처음에 보이는 것만큼 어렵지 않다.

다음 달 목표

• 3PL 업체를 통해 첫 주문을 처리한다.
• 다음 TinyPilot Pro 릴리스의 코드 작성을 완료한다.
• TinyPilot Voyager 2a의 1월 출시를 준비한다.