한 줄 요약

내 시간은 어디에 쓰이고 있을까? (2023년판)

하이라이트

• TinyPilot에 불필요한 시간을 쓰고 있는 곳이 어디인지 파악하려 하고 있다.
• 다시 이메일에 중독되었다는 걸 깨달았다.
• 첫 서버 랙을 만들었다.

목표 평가

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

새로운 위탁 제조업체와 생산 배치 시작하기

• 결과: 첫 생산 배치를 시작했다.
• 등급: A

위탁 제조업체와 구매 주문서에 서명했으니 첫 생산 배치가 진행 중이다. 사업 역사상 가장 큰 단일 변화가 될 일이라 두렵다. 잘 풀리면 정말 좋을 것이고, 잘못되면 재앙이 될 것이다. 전자가 되길 바란다.

TinyPilot Pro 2.6.0 출시하기

• 결과: TinyPilot Pro 2.6.0을 일정에 맞춰 출시했다.
• 등급: A

6월 릴리스는 순조롭게 진행됐지만 다소 밋밋하게 느껴졌다. 최근 두 릴리스에서 개발 노력의 상당 부분을 업데이트를 더 간단하고 오류가 덜 발생하도록 만드는 데 썼다. 덕분에 소프트웨어 유지보수성은 크게 좋아졌지만, 릴리스 공지에서 흥미롭게 들리진 않는다.

매출 9만 5천 달러 달성하기

• 결과: 매출 9만 3천 달러를 달성했다.
• 등급: C

TinyPilot의 수익은 거의 정체 상태였다. 새로운 리뷰가 공개됐지만 반응이 미지근해서 기대보다 판매량이 적었다.

TinyPilot 통계

이번 달 거의 모든 지표가 정체됐다. 마케팅 시도 중 하나는 실패했지만, 진행 중인 다른 시도들에 대해서는 여전히 낙관적이다.

TinyPilot의 광고 효율은 크게 떨어졌다. 5월에는 광고비 1달러당 3.64달러의 매출을 올렸지만, 6월에는 1달러당 2.62달러에 그쳤다. 2.62달러의 매출에 재료비가 약 0.90달러 든다는 점을 고려하면 광고는 여전히 수익을 내고 있지만 마진은 더 얇아졌다.

광고는 한 달 더 지켜볼 생각이다. 성과가 개선되지 않으면 TinyPilot의 마케팅 컨설턴트와 시간을 잡아 무엇이 문제인지 점검해야겠다.

내 시간은 어디에 쓰일까?

최근 인디 창업가 모임에서 가장 큰 어려움은 중요하지만 긴급하지 않은 일을 할 시간을 찾는 것이라고 말했다.

다른 참석자들은 놀라워했다. 왜 모든 걸 자동화하거나 위임하지 못하느냐, 무엇 때문에 꼭 내 시간이 필요하냐는 것이었다.

작년에 내가 시간을 어떻게 쓰고 있는지 점검한 게 도움이 됐기에, 이번에 다시 같은 작업을 해보기로 했다.

TinyPilot 창업자로서 내 시간을 가장 많이 차지하는 업무는 다음과 같다.

업무 1: 변경 사항 조율하기

팀원이 두 명을 넘어서면서 내 주요 역할 중 하나가 변경 사항을 조율하는 일이라는 걸 깨달았다.

TinyPilot은 여러 영역에서 동시에 성장한다. 소프트웨어를 개선하고, 하드웨어를 개선하고, 새로운 벤더를 통합하고, 팀원을 늘리는 식이다.

사업의 한 영역에서의 변화는 대개 다른 부분에 물결처럼 영향을 미친다. 인력과 복잡성이 커질수록 그 파급 효과는 더 잦고 커졌다.

여기서 시간을 어떻게 줄일 수 있을까?

모임 참석자 중 일부는 그냥 매니저를 뽑으라고 제안했다. 말처럼 쉽지 않다.

TinyPilot에는 각각 2~3명으로 구성된 세 팀이 있다. 소프트웨어 개발, 지원 엔지니어링, 고객 서비스/현장 운영이 그것이다. 세 팀의 역할은 대부분 겹치지 않는다.

한 팀만 관리할 사람을 뽑는다면 시간이 크게 절약되지 않을 것이다. 세 팀을 모두 관리할 사람을 뽑으려면 소프트웨어 관리 경험이 필요하니 연봉이 12만 5천 달러 이상은 될 가능성이 높다. 고용 비용으로 따지면 연 최소 20만 달러가 들고, 이는 TinyPilot의 현재 수익 전부를 써야 하는 수준이다.

내가 생각할 수 있는 최선의 해결책은 작년과 같다. 동시에 진행하는 프로젝트 수를 줄이고, 위임할 기회를 더 찾는다는 것이다.

내가 직접 맡는 일 중에는 위임할 수 없는 부분이 있어 보인다는 이유로 떠안는 경우가 있다. 예를 들어 어떤 업무가 하위 작업 A, B, C로 이루어져 있고 B에 TinyPilot을 대표해 계약서에 서명하는 일이 포함되면, “아, 이건 나만 할 수 있어”라고 생각한다. 그중 일부는 A와 C를 위임할 수 있는데도 그 가능성을 고려하지 않고 놓친다.

다른 해결책은 더 많은 일을 벤더에 맡기고 TinyPilot이 직접 처리하는 일의 범위를 줄이는 것이다. 올해 우리는 직접 하던 풀필먼트를 중단하고 제3자 물류(3PL) 업체로 전환했다. 엣지 케이스를 처리하기는 더 어려워졌지만, 이전에 관리하던 일의 카테고리 자체가 통째로 사라졌다.

업무 2: 3PL 파트너와의 관계 관리

3PL 업체로 전환하는 작업은 초기에 일이 몰릴 거라고 예상했다. 업체를 선정하고 전환하는 과정이 힘들겠지만, 그 이후에는 대부분 순조로울 거라고 생각했다.

그런데 3PL 업체와 함께 아직 풀어야 할 자잘한 워크플로가 길게 남아 있다는 걸 알게 됐다.

• 우리 사무실에서 3PL 창고로 이동 중인 재고를 어떻게 추적할까?
• 3PL이 창고에서 재고를 분실하지 않는지 어떻게 검증할까?
• 3PL이 주문에 잘못된 제품을 배송했을 때 문제는 어떻게 해결할까?
• 당일 배송을 원하는 고객은 어떻게 처리할까?

해결 가능한 문제들이지만 새로운 이슈가 계속 생기다 보니 3PL에 대해 고민하는 데 많은 시간을 쓴다.

여기서 시간을 어떻게 줄일 수 있을까?

이 영역은 팀에 더 많이 위임해야 할 부분이다.

TinyPilot 현장 직원들에게 3PL 관계 관리를 더 적극적으로 맡아달라고 요청하기 시작했고, 잘 되고 있다.

예전 같으면 3PL의 재고 분실을 막는 문제 같은 경우, 내가 직접 재고 보고서를 감사하는 프로세스를 정의했을 것이다. 대신 모든 걸 직접 정의하기보다 현장 직원 한 명에게 맡겼다.

업무 3: 소프트웨어 개발에 기여하기

TinyPilot 소프트웨어 개발에 많은 시간을 쓰는 이유는 그 부분이 가장 즐겁기 때문이다. 코드를 많이 쓸 시간은 없지만, 마음은 여전히 개발자다.

몇 시간 여유가 생기면 종종 작은 버그를 고치거나 코드를 정리하는 데 쓴다. 하지만 사소해 보이던 변경이 며칠짜리 작업으로 불어나기도 한다.

여기서 시간을 어떻게 줄일 수 있을까?

이건 어려운 문제다. 뻔한 해답은 “Michael은 코드 작성을 그만둬야 한다”이기 때문이다.

하지만 나는 코드를 쓰는 게 좋다…

더 현실적인 해법은 내가 맡는 작업에 더 보수적으로 접근하는 것이다. 개발 작업은 다음으로 제한해야 한다.

• 더 나은 문서, 개선된 테스트, 새로운 편의 스크립트 같은 개발자 경험 개선
• 내가 가진 과거 지식이나 회사 내 맥락 덕분에 다른 사람에게 설명하는 것보다 내가 직접 변경하는 게 더 쉬운 경우
• 성공하면 도움이 되고 실패하면 버려도 되는 실험적인 변경

업무 4: 문서 검토하기

지원 엔지니어링 팀은 일상적인 고객 지원을 하는 것 외에도 문서와 튜토리얼을 작성한다. 나는 외부에 공개되는 문서를 꼼꼼하게 보는 편이라, 팀의 글을 검토하고 스타일, 명확성, 기술적 표현에 대해 피드백을 주는 데 많은 시간을 쓴다.

문서 검토 자체는 실제 소요 시간이 길지 않지만 집중력이 많이 필요하다. 내 글을 명확하게 쓰는 것도 정신적으로 고되지만, 남의 글을 읽고 무엇이 빠졌거나 불명확한지 짚어내는 건 더 어렵다.

새 튜토리얼을 검토할 한 시간의 여유가 있어도 유용한 피드백을 줄 만큼의 정신적 여력이 없어 병목이 되는 경우가 많다.

여기서 시간을 어떻게 줄일 수 있을까?

가장 쉽게 할 수 있는 변화는 동료 검토에 더 의존하는 것이다. 개발팀에서는 소프트웨어 엔지니어들이 서로의 코드를 90%는 나 없이 검토한다. 영어 글에서 일관된 스타일을 조율하는 건 코드보다 어렵지만, 문서 편집의 80% 정도는 동료 검토로 처리할 수 있다고 생각한다.

또 하나 바꿔야 할 점은 문서 작업을 배정할 때 내 검토 여력을 고려하는 것이다. 예전에는 지원 엔지니어링 팀의 작업 큐에 튜토리얼 세 개를 연속으로 넣어놓고는 한꺼번에 검토할 여력이 없었다. 검토할 시간을 확보할 수 있도록 문서 작업을 더 분산시켜야겠다.

이메일 중독에서 벗어나기

지난 몇 년간 나는 이메일과 건강한 관계를 유지하는 시기와 비생산적인 중독에 빠지는 시기를 오갔다.

좋은 이메일 습관을 어떻게 잃었을까?

건강한 이메일 습관이 자리 잡으면 유지하는 건 대체로 쉽다. 그 습관을 깨뜨리는 건 대개 이메일을 집요하게 확인해야 할 정당한 이유가 생겼을 때다.

최근 TinyPilot의 메탈 케이스를 만드는 벤더의 납기가 늦어지면서 케이스 재고가 바닥났다. 케이스가 없으면 새 장치를 조립할 수 없으니 큰 문제다. 그래서 현장 팀의 업무를 급히 재배정해야 했고, 새로 맡긴 일들은 며칠 뒤 케이스가 (제발) 도착하면 다시 내려놓을 수 있는 일이어야 했다.

케이스 부족 같은 상황에서는 이메일을 강박적으로 확인할 정당한 이유가 있다. 중국 벤더가 금요일 저녁에 이메일을 보냈는데 내가 월요일 아침까지 답을 미루면, 중국에서는 화요일 아침에야 내 답을 보게 된다. 3일이 지연되는 셈이고, 그만큼 현장 팀이 새 장치를 만들지 못하는 기간도 3일 늘어난다.

문제는 비상 상황이 끝난 뒤에도 이메일을 수시로 확인하는 습관이 남는다는 것이다. 이메일을 확인했는데 긴급한 게 없으면 여전히 도파민을 원하게 되어 소셜 미디어를 확인한다. 그건 절대 생산적이지 않다. 30초만 이메일을 확인하려다 10~30분 동안 둠스크롤링을 하게 된다.

해결책 1: 정해진 이메일 시간에만 확인하기

지금까지 나쁜 이메일 습관에서 벗어나는 방법은 하루를 명확하게 계획하는 것이었다.

매일 아침 업무 시간을 30분 단위로 나누고 각 블록을 어떻게 쓸지 정한다. 이메일을 하루 종일 배경 소음처럼 확인하지 않고, 읽고 답장하는 시간을 따로 정해두는 식으로 강박적인 확인을 피한다.

이 습관으로 다시 돌아가도록 스스로를 다잡아야 한다. 리듬을 타면 유지하기 쉽지만, 그 리듬에 들어가는 게 어렵다. 예전에도 처음 며칠을 버텨내면 그 뒤로는 쉬워지고, 의지력에 기대지 않아도 될 만큼 보람이 있었다.

해결책 2: 사후 피드백 장려하기

이 글을 쓰는 지금은 오전 10시이고, 지금까지 이메일 확인을 참아왔다. 하지만 일을 막고 있다는 느낌이 강하게 든다.

그런 느낌이 드는 이유는 팀원들이 지원 티켓에 대해 내 피드백을 자주 요청하는데, 내가 그렇게 하도록 장려해왔기 때문이다.

팀원들이 지원 티켓을 나에게 에스컬레이션하면 내 받은 편지함이 더 시간에 민감해진다는 걸 깨닫고 있다. 두 지원 엔지니어 중 누가 시간이 될 때까지 막혀 있던 티켓이 이제는 나와 그 티켓을 에스컬레이션한 특정 지원 엔지니어에게 막히게 된다. 그러면 고객을 며칠씩 기다리게 하지 않으려고 빨리 답해야 한다는 압박을 느낀다.

한 번도 시도해보지 않은 방법 중 하나는 “병렬 에스컬레이션”이다. 내 피드백을 기다리느라 지원 티켓을 멈춰두는 대신, 팀원들이 고객 응대를 계속하면서 동시에 내 피드백을 요청하도록 장려하는 것이다.

해결책 3: 동료 검토를 더 활용하도록 팀원들에게 권한 주기

문서 검토 얘기를 할 때 동료 검토를 언급했지만, 모든 종류의 업무에서 동료 검토를 더 활용할 기회를 찾아야 한다. 동료와 함께 기술을 키울 수 있고, 특히 나에게 막혀 있는 작업을 줄일 수 있다.

사이드 프로젝트

첫 홈 서버 랙 만들기

첫 홈랩 서버를 만든 이후로 사무실에는 서버와 네트워크 장비가 계속 늘어났다.

약혼자는 사무실에 전선이 여기저기 널려 있어 청소가 안 된다고 지적했다. 나는 “뭐? 이 정도면 전선이 평범한 수준인데”라고 생각했다. 그런데 가만히 보니 확실히 전선이 좀 많았다…

서버 랙을 만들면 우리 둘 다 만족할 수 있겠다는 생각이 들었다. 나는 재미있는 홈랩 프로젝트를 하게 되고, 그녀는 모든 전선이 하나의 유닛 안에 깔끔하게 정리되는 걸 좋아할 테니까.

그래서 첫 서버 랙을 만들었다. 만드는 과정도 재미있었고, 확실히 훨씬 깔끔해졌다. 모든 걸 수직으로 쌓으니 바닥의 전선도 줄었고, 바퀴가 달려 있어 청소하기도 쉽다.

처음으로 매니지드 스위치와 VLAN을 쓰고 있다. 처음에는 VLAN이 너무 번거롭고 디버깅하기 어렵다고 느꼈다. 이제는 기본을 익히고 나니 재미있고 모든 걸 VLAN으로 만들고 싶어졌다.

모든 부품을 어떻게 골랐고 어떤 실수를 했는지에 대해 더 긴 글을 준비 중이니 기대해 달라.

Nix 배우기

Nix는 지난 1년간 가장 흥미로워 보이는 기술 목록의 맨 위에 있었기에, 최근 시간을 투자해 더 배워보기로 했다.

Nix 첫인상에 대한 노트를 정리했는데, 뜻밖에 Hacker News와 Twitter에서 큰 관심을 받았다. Nix 커뮤니티 사람들이 나에게 연락해 막혔던 부분을 도와주겠다고 했다.

덕분에 완전히 이해하지 못한 기술을 실험할 때 노트를 더 많이 남겨야겠다는 생각이 들었다.

Go로 직접 인증 라이브러리 만들기

2018년에 웹 앱을 만들기 시작했을 때 직접 인증을 구현하고 싶지 않아 항상 타사 서비스를 이용했다.

타사 인증 서비스는 그럭저럭 쓸 만했지만 오픈소스 프로젝트의 확산을 제한했다. 다른 개발자들은 내가 쓰는 것과 같은 인증 서비스를 써야만 내 앱을 배포할 수 있었다.

타사 인증의 또 다른 문제는 엔드투엔드 테스트를 더 느리고 불안정하며 복잡하게 만든다는 점이다.

가장 최근 프로젝트인 ScreenJournal에서는 인증에 타사 서비스를 쓰지 않을 방법을 찾아봤다. 먼저 사용 가능한 인증 라이브러리가 무엇이 있는지 살펴봤다. 내 요구사항은 다음과 같았다.

1. 오픈소스여야 한다.
2. 웹 앱에 주로 쓰는 언어인 Go를 사용해야 한다.
3. 앱 옆에서 함께 도는 별도 서비스가 아니라 앱에 빌드되는 라이브러리여야 한다.
4. 데이터 저장소로 SQLite를 지원해야 한다.

goth(구 gomniauth)이 가장 인기 있는 인증 라이브러리인 것 같지만, 외부 타사 서비스에 의존하므로 요구사항 (3)을 충족하지 못한다.

다른 유명한 Go 인증 솔루션은 authboss다. 모든 요구사항을 충족하지만 문서가 꽤 부실하다. 그게 지원 요청을 줄이려고 저자가 의도적으로 한 선택이라는 걸 알게 됐다.

한 오후를 들여 authboss로 간단한 웹 앱을 구현해 보려 했지만 기본 동작조차 제대로 만들지 못했다. authboss에 대해 알면 알수록 내가 원하는 것과 맞지 않았다. authboss는 인증뿐 아니라 페이지 렌더링과 URL 경로 라우팅까지 맡기길 기대하는 것 같았는데, 인증 라이브러리에 바라는 것보다 과한 역할이다.

지금은 재사용 가능한 인증 라이브러리를 직접 만들려고 하고 있다. 인기 있는 오픈소스 패키지로 만들려는 건 아니고, 취미 프로젝트마다 인증 코드를 복사해 붙여 넣는 일을 줄여줄 무언가를 만들고 싶을 뿐이다.

지금까지 할 수 있는 건 사용자 비밀번호가 맞는지 확인하는 것뿐이다. 클라이언트가 여전히 비밀번호 해시를 직접 생성해야 하므로 아직 재사용 가능하지 않다. 그건 인증 라이브러리가 해야 할 일이라고 생각한다.

재사용 가능한 인증 라이브러리를 만드는 건 흥미로운 도전이다. 평소에 잘 쓰지 않는 Go 기능을 써야 하고, 라이브러리가 단순화를 추구할지 다양한 인증 형태에 유연하게 대응할지 사이의 트레이드오프를 고민하며 아키텍처 감각을 단련하게 된다.

마무리

무엇을 해냈나?

• 위탁 제조업체와 함께 TinyPilot Voyager 2a 장치의 첫 생산 배치를 시작했다.
• 첫 홈 서버 랙을 만들었다.
• Nix와 NixOS의 기초를 배웠다.

교훈

• 창업자로서 내 시간을 더 효과적으로 쓸 수 있는 기회가 여러 가지 있다.
  • 위임할 기회를 더 찾고 큰 작업을 나눠 위임을 쉽게 만든다.
  • 맡는 개발 작업을 더 신중하게 고른다.
  • 이메일에 쓰는 시간을 더 계획적으로 관리한다.
  • 팀원들이 동료 검토를 더 활용하도록 장려한다.
• 서버 랙은 홈랩 덕후와 그 파트너 모두에게 즐거운 아이템이다.

다음 달 목표

• 판매 매출 9만 8천 달러 달성하기.
• TinyPilot의 위탁 제조업체 전환 일정을 지키기.
• 이메일에 쓰는 시간을 40% 미만으로 줄이기.