한 줄 요약

내 시간은 어디로 가고 있을까? (2023년판)

하이라이트

• 타이니파일럿에서 불필요하게 시간을 쓰고 있는 곳이 어디인지 파악하려고 하고 있다.
• 다시 이메일 중독에 빠졌다는 사실을 깨달았다.
• 첫 서버 랙을 만들었다.

목표 성적표

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

새 위탁 제조업체와 제조 배치 시작하기

• 결과: 첫 제조 배치가 시작됐다.
• 성적: A

위탁 제조업체와 구매 주문서에 서명해 첫 생산 배치가 진행 중이다. 지금까지 사업에서 시도한 가장 큰 단일 변화라 두려움이 앞선다. 잘 풀리면 대박이겠지만, 잘못되면 재앙이 될 것이다. 잘 되길 바라고 있다.

TinyPilot Pro 2.6.0 출시하기

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

6월 릴리스는 순조롭게 진행됐지만 다소 아쉽게 느껴졌다. 최근 두 번의 릴리스에서는 업데이트를 더 쉽고 오류 없이 만드는 데 개발 노력의 상당 부분을 쏟았다. 덕분에 소프트웨어 유지보수성은 크게 개선됐지만, 출시 공지에서는 그다지 흥미롭게 들리지 않는다.

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

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

타이니파일럿 매출은 거의 제자리걸음이었다. 새로운 리뷰가 나왔다지만 반응이 미지근해 기대보다 판매가 적었다.

TinyPilot 통계

거의 모든 지표가 제자리걸음이었다. 마케팅 시도 중 하나는 실패했지만, 아직 진행 중인 다른 시도들에 대해서는 낙관적으로 보고 있다.

타이니파일럿 광고 효율이 크게 떨어졌다. 5월에는 광고비 1달러당 3.64달러의 매출을 올렸는데, 6월에는 1달러당 2.62달러에 그쳤다. 매출 2.62달러 중 원가가 약 0.90달러인 점을 감안하면 광고는 여전히 수익이 나지만 마진은 더 얇아졌다.

광고는 한 달 더 지켜보려고 한다. 성과가 개선되지 않으면 타이니파일럿 마케팅 컨설턴트와 시간을 잡고 문제점을 점검할 계획이다.

내 시간은 어디로 가는가?

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

다른 참석자들은 의아해했다. 왜 모든 일을 자동화하거나 위임하지 못하느냐, 무엇이 꼭 내 손을 거쳐야 하느냐고 물었다.

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

타이니파일럿 창업자로서 내 시간을 가장 많이 차지하는 업무는 다음과 같다.

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

팀 규모가 두 명을 넘어서면서 내가 맡은 핵심 역할 중 하나가 변경 사항을 조율하는 일이라는 걸 깨달았다.

타이니파일럿은 여러 축으로 동시에 성장한다. 소프트웨어를 개선하고, 하드웨어를 개선하고, 새로운 벤더를 통합하고, 팀원을 늘리는 일이 병렬로 진행된다.

한 영역의 변화가 다른 영역에 연쇄 영향을 미치는 경우가 많다. 인력과 복잡도가 늘어나면서 이런 연쇄 효과도 더 잦고 커졌다.

이 부분에 쓰는 시간을 어떻게 줄일 수 있을까?

모임 참석자 중 일부는 그냥 매니저를 고용하라고 조언했다. 말처럼 쉽지 않다.

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

한 팀만 관리할 사람을 뽑는다면 시간을 많이 아끼지 못한다. 세 팀을 모두 관리할 사람을 뽑으려면 소프트웨어 관리 경험이 필요하므로 연봉이 12만 5천 달러 이상일 가능성이 높다. 채용 비용까지 고려하면 연간 최소 20만 달러가 들고, 이는 타이니파일럿의 현재 수익 전부를 소진하는 수준이다.

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

위임할 수 없는 부분을 발견하면 내가 직접 맡는 경우가 있다. 예를 들어 어떤 업무가 A, B, C 세 하위 작업으로 이뤄져 있고 B가 타이니파일럿을 대표해 계약에 서명하는 일이라면 “아, 이건 나만 할 수 있네”라고 생각한다. 그런 경우 A와 C는 위임할 수 있는데도 그 가능성을 놓치곤 한다.

다른 해법은 더 많은 일을 벤더에 맡기고 타이니파일럿이 내부에서 직접 처리하는 범위를 줄이는 것이다. 올해 우리는 자체 풀필먼트를 중단하고 제3자 물류(3PL) 업체로 전환했다. 엣지 케이스 대응은 더 어려워졌지만, 이전에 우리가 관리하던 업무 범주 자체가 통째로 사라졌다.

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

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

하지만 3PL 업체와 함께 풀어야 할 자잘한 워크플로가 꼬리에 꼬리를 물고 계속 나오고 있다.

• 재고가 우리 사무실에서 3PL 창고로 이동하는 동안 어떻게 추적할 것인가?
• 3PL 창고에서 재고가 분실되지 않았는지 어떻게 검증할 것인가?
• 3PL이 주문에 잘못된 상품을 배송했을 때 어떻게 해결할 것인가?
• 당일 배송을 원하는 고객은 어떻게 대응할 것인가?

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

이 부분에 쓰는 시간을 어떻게 줄일 수 있을까?

이 영역에서는 팀에 더 많이 위임해야 한다.

타이니파일럿 현장 직원들에게 3PL 관계 관리를 더 적극적으로 맡아 달라고 요청하기 시작했고, 효과가 나타나고 있다.

이전에는 3PL 재고 분실 방지 같은 문제라면 내가 직접 재고 리포트를 감사하는 프로세스를 정의하곤 했다. 이제는 내가 모든 걸 정의하는 대신 현장 직원 한 명에게 맡긴다.

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

타이니파일럿 소프트웨어 개발에 관여하는 데 많은 시간을 쓴다. 그 부분이 가장 즐겁기 때문이다. 코드를 많이 쓸 시간은 없지만 마음은 여전히 개발자다.

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

이 부분에 쓰는 시간을 어떻게 줄일 수 있을까?

이 문제는 어렵다. 뻔한 해답은 “Michael은 코딩을 그만둬야 한다”이기 때문이다.

하지만 나는 코딩이 좋다…

더 현실적인 해법은 내가 맡는 개발 업무를 더 보수적으로 고르는 것이다. 맡아야 할 일은 다음과 같이 제한해야 한다.

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

업무 4: 문서 검토하기

지원 엔지니어링 팀은 일상적인 고객 지원을 제공하는 것 외에도 문서와 튜토리얼을 작성한다. 나는 대외 문서에 까다로운 편이라 팀이 쓴 글을 검토하고 문체, 명확성, 기술적 표현에 대해 피드백을 주는 데 많은 시간을 쓴다.

문서 검토 자체는 실제 소요 시간이 길지 않지만 집중력을 많이 요구한다. 내 글을 명확하게 쓰는 것도 정신적으로 지치는데, 남이 쓴 글을 읽고 무엇이 빠졌거나 불명확한지 조리 있게 지적하는 일은 더 어렵다.

그래서 문서 작업에서 내가 병목이 되는 경우가 많다. 새로운 튜토리얼을 검토할 한 시간의 여유가 있더라도 유용한 피드백을 줄 만한 집중력이 없을 때가 많다.

이 부분에 쓰는 시간을 어떻게 줄일 수 있을까?

가장 쉽게 할 수 있는 변화는 동료 검토에 더 의존하는 것이다. 개발 팀에서는 소프트웨어 엔지니어들이 서로의 코드를 90%는 내 도움 없이 검토한다. 글쓰기에서 일관된 문체를 맞추는 것이 코드보다 어렵긴 하지만, 문서 편집의 80% 정도는 동료 검토로 처리할 수 있다고 생각한다.

또 하나 바꿔야 할 점은 문서 작업을 할당할 때 내 여유를 고려하는 것이다. 이전에는 튜토리얼 세 개를 연달아 지원 엔지니어링 팀 큐에 넣었지만, 정작 한 번에 다 검토할 여력이 없었다. 검토 시간을 확보할 수 있도록 문서 작업을 더 분산해서 배치해야 한다.

이메일 중독에서 벗어나기

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

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

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

최근 타이니파일럿 메탈 케이스를 제조하는 벤더의 납기가 지연되면서 케이스 재고가 바닥났다. 케이스가 떨어지면 신제품 조립이 불가능해져 큰 문제가 된다. 현장 팀의 업무를 급히 재배정해야 하고, 새로 맡긴 일도 케이스가 (제발) 며칠 내로 도착하면 다시 내려놓을 수 있는 일이어야 한다.

케이스 부족 같은 상황에서는 이메일을 강박적으로 확인할 정당한 이유가 있다. 중국 벤더가 금요일 저녁에 이메일을 보내고 내가 월요일 아침까지 답을 미루면, 상대는 중국 시각 화요일 아침에야 내 답을 본다. 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천 달러 달성하기.
• 위탁 제조업체로의 전환을 일정대로 유지하기.
• 이메일에 쓰는 시간을 40% 미만으로 줄이기.