6년 전, 나는 구글 개발자 직을 그만두고 자본 없이 내 소프트웨어 회사를 차렸다.

처음 몇 년 동안 내가 시도한 사업은 모두 실패했다. 그중 가장 잘된 사업도 월 수익이 수백 달러에 불과했고, 수익을 낸 사업은 하나도 없었다.

3년 차의 절반쯤 지났을 때, TinyPilot이라는 장치를 만들었다. 원격으로 컴퓨터를 제어할 수 있게 해주는 장치다. 제품은 빠르게 인기를 얻었고, 그 이후로 지금까지 나의 주력 사업이 되었다.

2023년 TinyPilot은 99만 7천 달러의 매출을 올렸는데, 후하게 반올림하면 100만 달러다. 더 중요한 것은 사업이 23만 6천 달러의 순이익을 냈다는 점으로, 2022년 대비 20배 증가한 수치다.

이번 글에서는 부트스트랩 창업가로서 6년 차에 배운 것들을 공유하려 한다.

이전 회고

• 1인 개발자로서의 첫 해
• 1인 개발자로서의 두 번째 해
• 1인 개발자로서의 세 번째 해
• 부트스트랩 창업가로서의 네 번째 해
• 부트스트랩 창업가로서의 다섯 번째 해

TinyPilot의 수익성이 20배 증가했다

거의 손익분기점에 머물렀던 2년을 지나 TinyPilot은 마침내 의미 있는 수익을 냈다.

변화의 대부분은 매출 증가 덕분이다. 올해 메탈 케이스로 바꾸면서 고객이 기꺼이 지불하려는 가격이 올라갔고, 생산 능력도 함께 늘어났다.

지출 항목별로는 변동이 있었지만 전체 규모는 거의 그대로였다. 디자인 비용은 거의 0으로 줄었는데, 로고를 다듬는 데 매달 6천 달러씩 디자인 에이전시에 지불하는 것을 중단했기 때문이다. 하드웨어 설계를 반복해 개선하는 대신 기존 제품의 규모를 키우는 데 집중했고, 덕분에 전기공학 관련 비용을 10만 달러 줄일 수 있었다.

나는 급여를 받지 않기 때문에 2023년 TinyPilot을 통해 내가 번 총액은 23만 6천 달러다. 사람들은 내가 부트스트랩 창업 초기 5년간 어떻게 그 적은 수입으로 버텼는지 자주 궁금해한다. 답은 매사추세츠 서부에 살기 때문에 물가가 낮다는 것과, 빅테크에서 일하며 모아둔 인덱스 펀드 저축이 있었고 그 투자에서 나오는 배당 소득으로 생활할 수 있었다는 것이다.

2023년 가장 아찔했던 10분

2월의 한 나른한 토요일 오후, 현관문을 두드리는 소리가 들렸다. 현관 앞에는 청바지에 윈드브레이커를 입은 50대 중반의 남자가 서 있었다. 나는 파자마 차림 그대로 문을 열었다.

“TinyPilot 하시는 분 맞나요?” 그가 물었다.

“아, 큰일이다”라고 생각했다. 불만 있는 고객이 내 집을 찾아온 건가?

“네, 그런데요…” 나는 조심스럽게 대답했다.

“사무실 관리인입니다. 스프링클러가 터졌는데 사무실에 들어갈 수가 없어요. 내려와 주실 수 있을까요?”

심상치 않은 이야기였다.

사무실까지 5분 운전하는 동안 이게 사업의 끝일지도 모른다는 생각이 들었다. 모든 재고를 TinyPilot 사무실에 보관하고 있었다. 회로 기판이 물에 흠뻑 젖은 뒤에도 작동할까? 아마 아닐 것이다.

TinyPilot은 보험에 가입되어 있었지만, 1년 전에 재고가 지금의 절반이었을 때 정한 보장 금액이었다. 설령 보험금이 나온다고 해도 전체 제조 과정을 다시 가동하기까지 몇 달 동안 사업은 사실상 마비될 것이다.

건물에 도착해 2층에 있는 TinyPilot 사무실로 올라가는데, 한 걸음 내딛을 때마다 카펫에서 물이 질퍽거렸다.

층에 도착해 보니 스프링클러가 터진 곳은 TinyPilot 사무실이 아니라 공용 회의실이었고, 안도감이 들었다. 사무실 문을 열고 들어가 보니 안은 완전히 뽀송뽀송했다. 물은 문틈으로조차 새어 들어오지 않았다.

안도감도 잠시, 집주인은 회의실과 맞닿은 벽을 수리해야 해서 “몇 주에서 몇 달” 동안 나가 있어야 할 수도 있다고 말했다.

보통 며칠 만에 사무실 전체를 옮겨야 하는 것도 큰混乱이지만, 그 주는 특히 더 그랬다. TinyPilot을 시작한 이래 가장 긴 여행인 2주간의 유럽 여행을 앞두고 있었기 때문이다.

내가 자리를 비운 사이에 팀이 이사를 해야 한다면 컴퓨터나 프린터를 세팅할 사람이 아무도 없었다. 사무실 IT 담당자는 바로 나였기 때문이다. 그리고 팀이 배송 라벨을 출력하지 못하면 주문을 처리할 수 없었다.

결론적으로 이사를 하지 않아도 됐지만, 그 경험 덕에 다시는 그런 상황에 처하고 싶지 않다는 생각이 들었다. TinyPilot의 운영을 작고 단일한 사무실 한 곳에 집중시키는 것은 너무 큰 위험이었다.

주문 처리 외주화와 스트레스 줄이기

TinyPilot의 주문 처리는 항상 매우 원활했고, 그래서 외주화를 계속 미뤄왔다. 지난 2년간 3,500건이 넘는 주문 중 고객에게 잘못된 제품을 보낸 경우는 다섯 건 정도에 불과했다.

2023년 3월, TinyPilot은 자체 주문 처리에서 제3자 물류(3PL) 창고를 이용하는 방식으로 전환했다. 기기 조립은 여전히 사무실에서 했지만, 고객에게 보낼 상태로 포장된 제품을 창고로 일괄 발송하면 3PL이 고객에게 배송하는 마지막 단계를 맡는 구조였다.

3PL로 전환할 당시 우리는 “긴급 모드”에 있었다. 두 명의 파트타임 직원으로 구성된 팀이 주당 약 50대를 조립했지만 고객들도 같은 속도로 구매하고 있었다. 작은 차질이라도 생기면 판매를 중단해야 할 수 있는 스트레스가 큰 상황이었다.

외주화를 통해 팀의 시간을 확보하면 주당 100대 정도 생산할 수 있으리라 기대했지만, 실제로는 최대 생산량이 70대 정도에 불과했다. 그 속도라면 창고에 건강한 수준의 재고를 쌓기까지 최대치로 일해도 몇 달이 걸릴 터였다. 결국 여름을 넘기기 위해 임시로 직원 한 명을 더 채용했다.

결국 외주화가 시간을 엄청나게 벌어다 주지는 않았지만, 훨씬 더 많은 유연성을 가져다주었다.

현지 팀은 이미 유연해 보였다. 원하면 언제든 출근할 수 있었기 때문이다. 다음 날 우편 수거 전까지 주문 포장이 끝나기만 하면 새벽 3시에 일해도 상관없었다.

3PL로 전환하면서 매일 우편 수거에 맞춰야 하는 마감은 사라졌다. 대신 우리가 지켜야 할 유일한 마감은 일주일에 한 번 조립된 제품을 창고로 보내는 것이었다.

유연성이 높아지자 스트레스가 많이 줄었다. 직원이 4일 연휴를 쓰고 싶으면 일정을 조정해 그 주에도 평소대로 15시간을 일할 수 있었다. 며칠 쉬어도 나머지 팀원에게 부담을 준다는 느낌이 들지 않았다.

TinyPilot을 진짜 제품처럼 보이게 만들기

2023년 TinyPilot에서 가장 눈에 띄는 변화 중 하나는 제품 외관을 개선한 것이다.

2022년 말까지 우리는 7대의 고급 3D 프린터를 쉬지 않고 돌려 TinyPilot 케이스를 만들고 있었다. 3D 프린팅치고는 케이스 품질이 꽤 좋았지만, 여전히 3D 프린팅 제품 특유의 ‘시제품’ 같은 느낌이 남아 있었다.

2023년 2월, 우리는 메탈 케이스로 전환했다.

메탈 케이스가 판매에 미친 영향은 놀라웠다. 판매량 자체가 늘었을 뿐 아니라 고객이 지불할 의사가 있는 가격도 올라갔다. 가격을 여러 차례 실험한 끝에 결국 가격을 10% 인상했는데도 월 판매량은 3D 프린팅 케이스를 쓰던 때보다 여전히 높았다.

TinyPilot의 포장도 개선했다. 작년 말까지도 우리는 기기와 케이블을 뽁뽁이 파우치에 함께 넣어 평범한 갈색 박스에 담아 보내고 있었다.

리뷰어가 TinyPilot 언박싱 경험을 공유할 때마다 나는 조금씩 얼굴을 찡그렸다.

제품용 리테일 박스를 멋지게 만들어 보자고 디자이너들과 몇 번 이야기를 나눈 적도 있지만 성사되지 않았고, 우선순위도 높지 않았다. 메탈 케이스로 바꾼 뒤에는 TinyPilot의 포장이 특히나 미숙해 보였다.

2023년 하반기에는 위탁 제조업체와 협력해 전체 생산 과정을 맡겼다. 그 과정에서 업체가 리테일 박스 제작을 제안해 주었다.

위탁 제조업체는 박스를 정말 잘 만들어 주었다. 베스트바이 매대에 놓였을 때 시선을 확 사로잡을 정도는 아니지만, 네트워킹 하드웨어 제품으로서 전문적인 느낌을 주는 포장이다.

배운 점

낮은 지연 시간의 책임에 숨어 있는 스트레스

TinyPilot의 주문 처리를 3PL로 전환한 것이 현지 팀의 스트레스를 줄이고 유연성을 높였지만, 내 스트레스도 얼마나 크게 줄었는지에 가장 놀랐다.

나는 몇 년 동안 “만약에?”라는 불안을 모르는 사이에 계속 짊어지고 있었던 것이다.

3PL로 바꾸기 전에는 주문 처리를 막을 수 있는 모든 것들에 대한 걱정이 늘 마음 한구석에 있었다. 사무실 공유기가 다운되어 인터넷에 접속하지 못하면 어쩌지? 데스크톱이 갑자기 프린터와 연결이 안 되면 어쩌지? 긴급하게 중요한 프로세스를 풀어달라고 호출될 수 있는 상황이 수십 가지였다.

이제 3PL과 위탁 제조업체로 전환한 뒤에도 잘못될 수 있는 일은 여전히 많지만, 나는 대부분의 일상적인 운영에서 핵심 경로 밖에 있다. 창고에서 프린터가 고장 나도 다른 사람이 고칠 것이고, 나는 아마 그 사실조차 모르고 지나갈 것이다.

프로젝트가 성숙할수록 유지보수에 더 많은 시간이 든다

6월에 최신 TinyPilot 소프트웨어 업데이트의 변경 사항을 정리하면서 우리가 한 작업이 사용자에게 어떤 이득이 되는지 설명하는 데 애를 먹었다. 리팩터링 작업을 지나치게 했다고 생각해 다음 릴리스는 더 사용자 중심으로 만들겠다고 다짐했다.

다음 업데이트를 발표할 때가 되자 같은 문제가 반복됐다. 두 달 반 동안 개발한 끝에 보여줄 수 있는 것이라고는 사소하고 겉모습만 개선된 것들뿐이었다.

지금의 속도는 몇 달마다 주요 기능을 출시하던 초기와 비교하면 빙하처럼 느리게 느껴졌다. 내가 우선순위를 잘못 정한 걸까? 팀이 열정을 잃은 걸까? 기술 부채를 너무 많이 떠안은 걸까?

최종 사용자에게 보이지 않는 작업을 포함해 릴리스의 전체 작업 목록을 검토했다. 돌이켜봐도 내가 올바른 작업을 선택했다고 느꼈고, 각 작업에 투자한 시간도 합리적이었다.

그렇다면 우선순위도 잘 정하고 효율적으로 일했는데 왜 진행 속도는 이렇게 느려진 걸까?

지배적인 요인은 코드베이스의 규모라는 것을 깨달았다. 우리는 3년 전에 비해 코드가 세 배로 늘었다. 그리고 코드 한 줄마다 유지보수에 시간이 든다. 개발자 수를 그대로 유지하면서 코드베이스 규모가 커지면, 더 많은 시간 비중을 기존 코드 유지보수에 써야 하는 것이다.

유지보수 외에도 코드가 많아지면 새 기능을 만드는 비용도 더 커진다. 앱에 기능이 하나도 없을 때는 첫 기능을 만드는 게 쉽다. 이미 20개의 기능이 있는 앱에 21번째 기능을 추가하려면 다른 모든 기능과 어떻게 통합할지 훨씬 더 깊이 고민해야 한다.

그래서 우리가 훨씬 더 빨리 나아갈 방법을 아직 찾지는 못했지만, 기능 개발 속도에 대한 기대치를 조절하는 법을 배웠다. 그리고 더 복잡해진 코드베이스를 감안해 개발 비용을 산정하는 방식도 조정했다.

대부분의 지원 에스컬레이션은 비동기로 처리할 수 있다

나는 TinyPilot 팀에 가능한 한 많은 자율성을 주려고 노력한다. 동시에 모두가 막혔을 때 편하게 내게 도움을 요청할 수 있도록 하고 싶다.

문제는 지원 티켓이 내게 에스컬레이션될 때 특히 스트레스를 느꼈다는 것이다.

한동안 나는 그게 에스컬레이션의 본질이라고 생각했다. 가장 어려운 고객 문의만 보는 것이니 당연히 스트레스받을 수밖에 없다고 여겼다. 하지만 대부분은 개선할 수 있는 문제였다.

먼저 에스컬레이션 프로세스를 조정했다. 대부분의 에스컬레이션은 “마이클, 전에 본 적 없는 문제인데 어떻게 처리할까요?”라는 형태였다. 나는 팀에 에스컬레이션할 때 해결책을 함께 제안하도록 접근 방식을 바꾸자고 권했다. 내가 자리에 없고 그들이 마지막 지원선이라면 고객에게 뭐라고 말할 것인지 생각해 보라는 것이었다.

80%는 팀이 내가 추천했을 해결책과 동일한 답을 내놓았다. 지원팀이 이렇게 하는 횟수가 늘어날수록 어려운 케이스를 다루는 능력도 점점 좋아졌다.

팀의 답이 내 답과 얼마나 가까운지 알게 된 뒤에는 굳이 내 답변을 기다리며 지원 티켓을 멈출 필요가 없다는 것을 깨달았다. 80%의 케이스에서 내 기여가 “그래, 그렇게 해”뿐이라면, 그냥 즉시 그들의 계획을 실행하고 병렬로 내게 대안을 확인하면 되지 않을까?

내가 지원 문제에 대해 더 나은 아이디어를 가지고 있던 소수의 경우에도, 그것은 거의 항상 팀의 제안에 더해 고객이 시도해 볼 수 있는 추가적인 방법이었다. “더 일찍 개입해 주셨으면 좋았을 텐데요, 저희가 기기를 전자레인지에 넣으라고 했더니 집에 불이 났어요”라는 상황은 한 번도 없었다.

작년 목표 평가

작년에는 한 해 동안 달성하고 싶은 큰 목표 세 가지를 세웠다. 그 목표들에 대한 결과는 다음과 같다.

주당 20시간으로 TinyPilot 운영하기

• 결과: 이전 해들보다 근무 시간을 크게 줄였고, 어느 해보다 여행을 많이 했다.
• 성적: B-

2023년에는 2022년보다 훨씬 적게 일했다. 업무와 개인적인 여행을 많이 다녔고, 통틀어 약 5주 동안 “부재 중”이었지만 모든 일이 순조롭게 진행됐다.

저녁에 업무를 마무리할 때 2022년에는 자주 미완의 일을 남긴 채 끝내는 느낌이었던 반면, 2023년에는 하루 일이 대체로 깔끔하게 마무리된 느낌이 들었다.

10만 달러 순이익 달성

• 결과: 23만 6천 달러의 순이익을 달성했다.
• 성적: A+

하드웨어 엔지니어링에 지출이 줄어들 것을 알았기에 올해 수익이 날 거라 예상했지만, 메탈 케이스로의 전환이 가져올 추가 매출을 과소평가했다.

목표를 초과 달성해서 기분 좋게 놀랐다.

TinyPilot 사무실 닫기

• 결과: 중요도가 낮은 업무를 위해 사무실을 계속 유지하고 있다.
• 성적: B

이 목표를 세울 때는 집주인이 월 단위 임대 계약에 동의할 줄 몰랐는데, 동의해 주었다. 장기 계약이 없으니 특정 기한까지 나가야 한다는 압박이 줄어들었다.

제조와 주문 처리라는 핵심 운영을 성공적으로 사무실 밖으로 옮겼다. 그래서 엄밀히 말하면 사무실이 꼭 필요한 건 아니지만, 거점 공간이 있는 건 편리하다.

내일 관리인이 다시 문을 두드리며 어떤 재해로 사무실 재산이 모두 망가지고 공간을 사용할 수 없게 됐다고 해도 답답하겠지만 치명적이지는 않을 것이다.

7년 차 목표

주당 20시간으로 TinyPilot 운영하기

2022년에도, 2023년에도 이걸 목표로 세웠다는 걸 안다. 하지만 세 번째면 이루어진다! 관리에 쓰는 시간이 계속 줄어드는 추세라 올해는 가능할지도 모르겠다.

강의나 책 출간하기

2021년에 개발자들이 글쓰기를 개선하도록 돕는 책을 쓰겠다고 했다. 그 책의 첫 챕터의 80%까지 썼는데, 그해 TinyPilot이 내 여가 시간을 전부 흡수해 버렸다.

여전히 그 책을 쓰고 싶기 때문에 관리 시간을 줄인다면 그 여유 시간으로 글을 더 쓸 수 있기를 바란다.

최근에는 Nix와 Zig라는 두 기술을 실험하고 있는데, 흥미롭지만 교육 자료가 부족한 기술들이다. 둘 중 하나에 대한 강의를 만드는 것은 내 전문성을 키우면서 동시에 다른 사람들이 이 도구들을 더 쉽게 접할 수 있게 하는 재미있는 방법이 될 수 있다.

주당 10시간 소프트웨어 개발하기

코딩은 여전히 내가 가장 좋아하는 활동 중 하나다.

지난 몇 년간 TinyPilot에서 프로그래밍을 즐기긴 했지만, 제한된 근무 시간을 쓰기에 합리적인 방법은 아니었다. 6명의 팀원과 여러 핵심 벤더, 그리고 많은 움직이는 요소들을 두고 보면 TinyPilot에서 가장 시급한 일은 항상 관리였다.

TinyPilot의 운영 측면을 더 많이 외주화하고 위임함으로써 프로그래밍이 내 시간을 쓰는 최적의 방법은 아니더라도 적어도 합리적인 방법이 될 만큼 여유를 만들 수 있기를 바란다.

아직도 이 일이 좋은가?

매년 이런 회고 글을 쓸 때마다 나는 여전히 내가 하는 일을 사랑하는지 스스로에게 묻는다.

2022년은 지금까지 중 가장 힘든 해로 남아 있다. 그래도 고용주를 위해 일하는 것보다는 나았지만, 글로벌 반도체 부족 사태를 헤쳐 나가면서 새로운 팀원들을 온보딩하는 것은 엄청난 도전이었다.

2023년은 전년에 비해 크게 나아졌다. 급하게 꺼야 할 불도 적었고, 핵심 워크플로를 전문 업체에 넘긴 것이 뿌듯했다.

2023년의 아쉬운 점은 별로 신이 나지 않았다는 것이다. 구조조정의 해였기 때문에 TinyPilot의 프로세스를 재정의하고 팀의 역할을 조정하는 데 많은 시간을 썼다. TinyPilot을 통해 나는 조직 프로세스를 설계하는 데 평균적인 개발자보다 낫다는 것을 알게 됐지만, 여전히 그 일은 고통스러울 정도로 지루하게 느껴진다.

그 해를 사랑했다고 말할 수는 없지만, 대부분은 즐거웠고 고용주를 위해 일하는 것보다 좋았다. 스스로 일하며 자랑스러운 제품을 만들어 생계를 이어갈 수 있는 위치에 있다는 것에 감사한다.