한 줄 요약

microSD 플래싱의 의외로 어려운 과정

하이라이트

• TinyPilot이 역대 두 번째로 높은 월 매출을 기록했습니다.
• TinyPilot의 제조를 외부 위탁 업체로 이전하는 작업이 거의 마무리되었습니다.
• 어쩌면 기계식 키보드의 다크사이드에 발을 들였는지도 모릅니다.

목표 평가

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

위탁 제조업체로 생산 이전을 최대한 빨리 완료하기

• 결과: 첫 번째 배치에서 사소한 문제가 있었지만, 곧 이전을 완료할 수 있을 것 같습니다.
• 평가: B

위탁 제조업체로부터 첫 생산 배치를 받았고, 11월에 고객에게 배송할 예정입니다.

이번 배치가 완벽해서 이전이 완료됐다고 선언할 수 있기를 기대했습니다. 안타깝게도 조립 과정에 사소한 오류가 있어 사무실에서 직접 수정해야 했고, 아직 제조사에서 창고, 그리고 고객까지 매끄럽게 이어지는 파이프라인을 갖추지는 못한 상태입니다.

TinyPilot 소프트웨어 배포 과정의 수작업 줄이기

• 결과: 제게 종속되어 있던 수동 배포 작업을 제거했습니다.
• 평가: A

저는 항상 TinyPilot 소프트웨어 배포 과정을 자동화하고 단순화할 방법을 찾고 있습니다. 특히 TinyPilot의 일상적인 워크플로에서 제가 병목이 되지 않도록 하는 데 관심이 많습니다. 10월에는 새로운 TinyPilot Pro 버전이 출시될 때 TinyPilot 웹사이트를 업데이트하는 과정을 자동화하면서 두 가지 모두에서 진전을 이뤘습니다.

예전에는 제가 릴리스를 만들고 나서 웹사이트의 다운로드 URL을 수동으로 업데이트해야 했습니다. 이제는 웹사이트가 업데이트 서비스와 동기화되어 새로운 릴리스를 자동으로 인식합니다.

TinyPilot Pro 라이선스 관리를 강화할 계획 세우기

• 결과: 계획 수립에 진전이 없었습니다.
• 평가: F

개발팀이 10월에 예상보다 여유가 없어서, 결국 라이선스 관리 강화 계획에는 진전을 이루지 못했습니다.

TinyPilot 통계

이번 달은 TinyPilot 역사상 두 번째로 매출이 높은 달이었는데, 이유를 전혀 모르겠습니다. 애널리틱스에서도 눈에 띄는 점이 없고, 새로운 리뷰나 언급도 알지 못합니다. 2022년 10월에도 매출이 높았습니다이니 단순히 계절적 요인일 수도 있습니다.

제조 이전에 집중하느라 마케팅에 투자하지 못해서 수치가 조금 떨어질 것이라 예상했습니다. 모멘텀만으로도 유지할 수 있다는 점은 다행이지만, 2023년 마지막 몇 달 동안은 성장에 다시 투자를 늘리기 시작했습니다.

새 제조업체에서 microSD 제대로 준비하기

사라진 디스크

TinyPilot 장치는 microSD라는 작은 디스크에 데이터를 저장합니다. 제조업체가 TinyPilot 장치의 첫 샘플을 보내기로 한 며칠 전, 제가 보낸 레퍼런스 장치에 microSD가 들어 있는 것을 발견했습니다. microSD가 필요한지 물어왔습니다.

알고 보니 제조업체가 자재 명세서(BOM)에 microSD를 전혀 포함하지 않았던 것입니다. 저 역시 빠진 것을 알아차리지 못했습니다.

다행히 microSD를 구매하고 플래싱하는 과정은 빠르고 간단합니다. 이미 TinyPilot 로고가 들어간 microSD를 제작하는 업체가 있었고, 제조업체와 해당 업체를 연결해 주었으며 microSD에 TinyPilot 소프트웨어를 플래싱하는 방법을 설명했습니다.

제조업체와 저는 microSD 때문에 첫 샘플을 지연시킬 필요는 없다는 데 합의했습니다. 그래서 장치는 microSD 없이 먼저 배송하고, microSD는 1~2주 후에 따로 보내기로 했습니다.

그런데 첫 샘플에 문제가 너무 많았던 탓에 저는 microSD에 대해 완전히 잊어버렸고, 제조업체 역시 보내지 않았습니다.

microSD가 올바르게 플래싱됐는지 확인하기

10월 중순쯤 제조업체는 제가 제기했던 첫 샘플의 모든 문제를 수정했다고 했습니다. 그리고 고객에게 바로 배송할 수 있도록 완전히 완성된 소규모 생산 배치를 보내겠다고 했습니다.

첫 배치에 대해서는 여전히 추가 QA를 진행해 자체 기준에 부합하는지 확인할 계획이었습니다. 검증 과정 중 하나는 제조업체가 microSD를 올바르게 플래싱했는지 확인하는 일이었습니다.

배치가 도착하기 이틀 전까지도 제조업체가 microSD를 올바르게 플래싱했는지 어떻게 확인할지 생각하지 못했습니다. 디스크의 마지막 바이트 하나까지 모두 정확한지 확인하고 싶었습니다.

microSD를 검증하는 일은 간단하지 않아서, TinyPilot 지원 엔지니어링 팀에 제조업체의 microSD와 우리의 ‘골든’ 디스크 이미지를 비교해 차이점을 알려주는 간단한 셸 스크립트를 만들어 달라고 부탁했습니다. 팀은 테스트에 맞춰 제시간에 스크립트를 만들어 주었습니다.

첫 배치가 도착했을 때 microSD를 장착하고 무결성 검사 스크립트를 실행했더니 모든 것이 일치한다고 나왔습니다. 잘됐습니다!

기능 테스트를 실행해 보니 모든 것이 정상적으로 작동했습니다. 매우 기뻤습니다. 이는 제조업체가 이번 배치를 완벽하게 처리했다는 뜻이었고, 외부 제조업체로의 이전이 성공했다고 선언할 수 있게 됐습니다.

테스트하던 마지막 TinyPilot을 종료하려는데 뭔가 이상한 점을 발견했습니다. 비디오 설정이 TinyPilot 출고 시 기본값이 아니었습니다. 누군가 저보다 먼저 이 장치를 사용한 것처럼 보였습니다.

테스트하던 장치를 종료하고 microSD 검사 스크립트를 다시 실행했습니다. 이번에는 테스트 중에 설정을 많이 바꿨기 때문에 당연히 변경 사항이 보고되어야 했습니다. 그런데 스크립트는 제 microSD가 골든 이미지와 완벽하게 일치한다고 보고했습니다.

뭔가 잘못됐습니다.

지원 엔지니어의 컴퓨터에서는 스크립트가 정상적으로 작동했지만, 제 테스트 환경에서는 항상 거짓 양성(false positive)을 반환했습니다.

microSD를 더 자세히 살펴보니 제조업체가 우리의 지침을 오해한 것이 분명했습니다. 우리는 테스트용 microSD로 QA를 수행한 뒤 고객에게 포장하기 전에 새 것으로 교체해 달라고 요청했습니다. 제조업체는 이 교체를 하지 않고 있었기 때문에, 사용한 microSD가 그대로 장착된 채 고객에게 배송되고 있었습니다.

다행히 이 문제는 사무실에서 비교적 쉽게 수정할 수 있었습니다. 현지 팀이 박스를 하나씩 열어 microSD를 깨끗한 상태로 다시 플래싱하고 재포장한 뒤 창고로 보냈습니다.

장기적으로는 모든 microSD를 사무실에서 다시 플래싱하고 싶지 않습니다. 제조업체에 문제를 알렸더니 실제로 지침을 오해했음을 인정하고, 고객에게 전달되는 모든 microSD가 우리 이미지로 새로 플래싱되도록 프로세스를 수정했다고 했습니다. 다음 배치는 다시 검증할 예정이지만, 이제 이 문제가 거의 마무리되어 가기를 기대하고 있습니다.

microSD 문제는 어떻게 예방할 수 있었을까?

microSD 문제는 이전에 발생한 여러 오류가 누적된 결과였습니다:

• 제조업체의 자재 명세서에서 microSD가 빠져 있는 것을 알아차리지 못했습니다.
• 제조업체가 샘플 microSD를 보내지 않았는데, 저도 후속 확인을 잊었습니다.
• 프로세스 후반부가 되어서야 microSD를 어떻게 검증할지 고민했습니다.
• microSD 검사 스크립트에 어느 정도 엄밀함이 필요한지 과소평가했습니다.

BOM을 검토할 때 저는 기억에만 의존해 모든 것이 있다고 생각했습니다. 제품 하나를 철저히 분해해 제조업체 BOM의 모든 항목이 실제 제품 구성 요소와 1:1로 일치하는지 확인했어야 했습니다.

제조업체의 약속 누락으로 문제가 생긴 것은 이번이 두 번째인데, 아직도 뚜렷한 해결책을 찾지 못했습니다. 전반적으로 대부분의 업무는 잘 처리하지만, 제가 후속 확인을 하지 않으면 약 10%의 업무를 잊어버립니다. 제조업체의 약속 누락과 관련해 기다리고 있는 일이 있을 때 문제를 제기해 왔지만, 그러다 보니 microSD나 설명서 같은 항목이 쉽게 누락됩니다. 출하가 막히기 전까지는 중요해 보이지 않는 부분들입니다.

microSD 검사 스크립트에도 투자를 충분히 하지 않았습니다. 당시에는 일회성 스크립트처럼 느껴져서 고객에게 전달되는 코드만큼 시간과 정성을 들일 필요가 없다고 생각했습니다. 하지만 거짓 양성을 겪고 나서 QA 과정에서 스크립트가 예상대로 작동하는 것이 얼마나 중요한지, 그리고 실수가 얼마나 큰 비용으로 이어질 수 있는지 깨달았습니다. 그래서 지금은 프로덕션 수준의 코드를 만드는 표준 프로세스에 따라 스크립트를 다시 작성하고 있습니다.

제조업체의 프로세스를 처음부터 끝까지 검증할 방법은 아직 잘 모르겠습니다. 사내에서 직접 할 때는 Notion에 지침을 정리해 두고 팀 전체가 그대로 따랐습니다. 하지만 제조업체와는 Notion 워크스페이스를 공유할 수 없습니다. 작업자 모두가 영어를 읽지 못하기 때문입니다. 그래서 우리는 영문 지침을 제공하고, 제조업체가 이를 베트남어로 번역해 작업자가 베트남어 버전을 보는 구조입니다. 베트남어 프로세스가 영문 프로세스와 일치하는지 제가 검증할 방법이 없습니다.

QA 과정의 영상을 요청한 것은 도움이 되었습니다. 언어와 관계없이 제조업체가 QA를 어떻게 수행하는지 보여주기 때문입니다. 하지만 전체 과정을 처음부터 끝까지 영상으로 담기는 어렵습니다. QA 과정 영상에서는 테스트에 사용한 microSD가 최종 제품에 그대로 남아 있다는 점이 드러나지 않았고, 이를 어떻게 방지할 수 있을지 아직 잘 모르겠습니다.

제조업체는 베트남 공장을 방문하라고 초대했지만, 올해는 출장을 너무 많이 다녀서 거절했습니다. 돌이켜보면 방문했더라면 비용이 많이 드는 오류를 막을 수 있었을지도 모릅니다. 현지 팀원 중 한 명에게 방문을 제안할 수도 있었을 텐데 말입니다.

고객 성공 프로세스 만들기

연초에 현지 TinyPilot 팀의 업무는 고객 서비스가 약 20%, 조립과 출고가 80%였습니다. 제조와 출고를 외부 업체로 이전하면서 올해 그 비중이 크게 바뀌었습니다. 2024년 초가 되면 조립과 출고는 현지 팀 업무에서 0%가 될 예정입니다.

문제는 고객 서비스가 여전히 현지 팀의 주당 업무 시간 중 50%도 차지하지 않는다는 점입니다. 그렇다면 남은 여유 시간을 어떻게 활용해야 할까요?

팀은 연초부터 이 문제를 논의해 왔습니다. 가장 자연스러운 전환은 지원 요청에 수동적으로 대응하는 것에서 기존 고객에게 능동적으로 다가가는 것으로 옮겨가는 것입니다. 일부 기업에서는 이 역할을 ‘고객 성공(customer success)’이라고 부릅니다.

부끄럽지만 사실 저는 고객에게 거의 연락하지 않습니다. 중요하지만 긴급하지 않은 일이라 항상 미루게 되는 업무 중 하나입니다. 하지만 현지 직원들에게 이 일을 가르칠 수 있다면 더 이상 제 시간에 구애받지 않게 됩니다.

다음과 같은 새로운 고객 성공 프로세스를 시범 운영하고 있습니다:

1. 고객 서비스 팀이 TinyPilot에 많은 금액을 지출한 고객(특히 재구매 고객)을 조사합니다.
2. 고객 서비스 팀이 해당 고객의 회사와 주문에 대한 구체적인 내용을 담아 자동 메일처럼 보이지 않는 사람이 직접 쓴 이메일을 보내고, 기능 요청이나 불편 사항에 대해 이야기할 통화를 제안합니다.
3. 고객과 미팅을 갖고 TinyPilot을 어떻게 활용하는지 배웁니다.
4. 고객 피드백을 기능 로드맵에 반영합니다.

제가 고객으로서 다른 업체의 아웃리치를 받을 때는 대개 노골적으로 자기중심적이라는 느낌을 받습니다. “저희 제품군을 더 잘 이해하도록 도와드리고 싶습니다”라고 말하지만, 실제로는 더 많은 제품을 팔려는 의도인 경우가 많습니다.

TinyPilot의 고객 아웃리치는 기생적이거나 탐욕스럽게 느껴지기보다 협업처럼 느껴지길 바랍니다. 고객이 원하는 기능에 맞춰 로드맵을 조정하는 데 도움이 될 것이고, 그렇지 않았다면 발견하지 못했을 TinyPilot의 새로운 기회도 찾아낼 수 있을 것이라고 생각합니다.

사이드 프로젝트

Ansible와 작별하고 Nix 시작하기

지난 몇 년간 개발 환경을 관리하는 데 Ansible을 사용해 왔지만, 불편한 점이 많아 점점 지쳐가고 있었습니다. 지난 몇 달 동안 Ansible을 Nix로 대체하려고 시도해 왔는데, 이제 거의 마무리가 된 것 같습니다.

예전에 Nix Home Manager를 본 적이 있지만 그 필요성을 이해하지 못했습니다. 홈 디렉터리의 파일을 관리한다고? NixOS가 이미 시스템 전체를 관리하지 않나?

제가 놓치고 있던 핵심은 다음과 같았습니다:

• Home Manager는 NixOS뿐 아니라 모든 Linux나 Mac 시스템에서 작동합니다.
• Home Manager는 텍스트 파일에 최적화되어 있어 텍스트 파일을 관리하는 인터페이스가 NixOS보다 뛰어납니다.

이제 Ansible로 개발 시스템을 관리하는 대신 Home Manager와 프로젝트별 Nix flakes로 모든 것을 관리합니다. 한 달 넘게 Ansible 플레이북을 실행하지 않았습니다.

눈에 띄는 변화 중 하나는 자주 쓰는 명령어에 대해 bash alias를 더 자주 정의하고 사용하게 됐다는 점입니다. 예전에는 bash alias를 추가하려면 Ansible 플레이북에 추가한 뒤 해당 alias를 적용하고 싶은 모든 시스템에서 플레이북을 다시 실행해야 했습니다. 하지만 시스템에서 Ansible 플레이북을 실행하는 과정이 너무 느리고 실패하기 쉬워서, 절반의 시스템에는 alias가 있고 절반에는 없는 상황이 되곤 했습니다. 마찰이 너무 커서 새로운 alias를 추가하고 평소 습관에 통합하려는 동기가 거의 생기지 않았습니다.

Nix에서는 이제 Home Manager가 모든 bash alias를 관리합니다. 셸 alias를 추가하고 싶으면 ~/.config/home-manager/home.nix를 수정한 뒤 home-manger switch를 실행해 변경 사항을 적용하면 됩니다(실제로는 이를 bash alias인 hs로 줄여 놓았습니다). 전체 과정은 1분도 걸리지 않으며, Ansible처럼 외부 요인 때문에 실패하는 일도 없습니다.

NixOS로 완전히 전환하려고 했지만, 평소 쓰던 Debian 개발 환경과 차이가 너무 많아 어려움을 겪고 있었습니다. Home Manager를 사용하는 것은 Nix에 완전히 올인하는 것과 익숙한 Debian 워크플로를 유지하는 것 사이의 좋은 절충안입니다.

이제는 이상한 기계식 키보드 애호가가 되었습니다

Python 창시자 Guido von Rossum과 Lex Fridman의 인터뷰에서, Lex는 자신이 얼마나 Kinesis Advantage 2 키보드를 사랑하는지에 대해 길게 이야기합니다.

Kinesis는 기계식 키보드의 인기 브랜드입니다. 키가 오목한 웰(well) 안에 배치되어 있고 키보드 양쪽이 몇 인치 떨어져 있는 것이 특징입니다.

Lex는 Kinesis 키보드를 너무 좋아해서 비행기에도 들고 탑니다. 노트북 내장 키보드를 쓰는 것보다 거대한 키보드를 들고 다니는 편을 택할 정도입니다.

저는 14살 때부터 줄곧 어떤 형태로든 Microsoft 인체공학 키보드를 사용해 왔습니다. 마음에 들긴 하지만 Lex가 Kinesis에 대해 이야기하는 것처럼 열정적으로 좋아하는 것은 아니라서, 지난 몇 달 동안 기계식 키보드에 호기심이 생겼습니다.

기계식 키보드를 쓰는 사람을 두세 명 정도 알지만, 그 매력을 이해하지 못했습니다. 그들이 무언가에 열광하는 건 괜찮지만, 키보드에서 얻을 수 있는 최대의 즐거움은 그리 크지 않다고 생각해서 굳이 신경 쓸 필요가 없다고 느꼈습니다.

그러다 호기심이 생겨 고급 키보드에 대해 더 찾아보기 시작했습니다. 깨어 있는 대부분의 시간을 키보드 앞에서 보내니, 이 경험을 최적화하는 데 투자해야겠다는 생각이 들었습니다.

Kinesis, Ergodox, ZSA 등 몇 가지 옵션을 살펴본 끝에 결국 Kinesis Advantage 360을 선택했습니다.

키보드를 처음 사용한 날은 정말 고전했습니다. 평소 타자 속도의 5% 정도로밖에 치지 못했습니다. 처리해야 할 서류가 많아서 다음 날 아침까지 키보드를 치워 두었습니다.

둘째 날은 조금 나아졌지만 여전히 어려웠습니다. 계속 사용해 보니 이제 영어 문장을 입력할 때는 이 키보드에서 더 빠르지만, 프로그래밍할 때는 더 느립니다. 이 키보드에서 [, {, = 같은 문자 입력에 아직 익숙해지지 않았습니다. 더 쉽게 쓰려고 키를 리매핑해 보기도 했지만, 아직 근육 기억을 만드는 중입니다.

Kinesis에 익숙해진 뒤에는 일반 키보드로 다시 돌아가도 전혀 문제가 없다는 리뷰를 본 적이 있는데, 저는 아직 그렇지 않습니다. Surface Pro 6의 좁은 노트북 키보드로 바꾸면 오타가 엄청나게 늘어납니다. 언젠가는 둘 다 편하게 쓸 수 있게 되길 바랍니다.

60일 반품 기간이 있지만, 지금으로서는 Kinesis를 계속 쓸 것 같습니다.

마무리

무엇을 이루었나?

• 위탁 제조업체가 만든 TinyPilot Voyager 2a 장치의 첫 배치를 출하했습니다.
• TinyPilot 배포 과정에서 수작업을 제거했습니다.
• 기계식 키보드로 교체했습니다.

교훈

• 제조업체의 약속을 더 적극적으로 추적하기
  • 이전에도 저지른 실수인데 제대로 대응하지 못했습니다.
  • microSD 문제는 제조업체가 무언가를 하겠다고 약속하고, 저는 그들이 처리하고 있다고 가정하며, 결국 둘 다 잊어버려 나중에 문제가 생기는 패턴을 반복한 것입니다.
  • 약속 내용을 기록하고 매주 진행 상황을 검토해 그들이 잊어버리는 경우에 대비해야 합니다.
• BOM을 구성 요소별로 일일이 대조하기
  • 제조업체가 몇 달 전 자재 명세서를 보냈을 때, 저는 머릿속으로 예상한 항목만 확인하고 microSD가 빠진 것을 놓쳤습니다.
  • 앞으로 BOM 합의 과정을 거칠 때는 기존 제품을 분해해 모든 구성 요소를 목록화한 뒤 제조업체의 BOM과 일치하는지 검증할 것입니다.

다음 달 목표

• 위탁 제조업체로 생산 이전을 최대한 빨리 완료하기
• 고객 아웃리치 통화 5회 진행하기
• TinyPilot 사무실의 기존 재고와 예비 부품을 모두 정리하기