7년 전, 저는 구글 개발자 일을 그만두고 직접 부트스트랩 소프트웨어 회사를 차렸습니다. 매년 근황을 공유하며 그 과정이 어떻게 진행되고 있는지, 인디 창업가로서의 삶은 어떤지 전해왔습니다.

회사를 매각했다

지난 1년 동안 가장 중요한 커리어 변화는 2020년에 창업한 회사인 TinyPilot을 매각한 일입니다.

아내와 저는 가정을 꾸리고 싶었는데, 7명 규모의 회사를 혼자 운영하면서 신생아에게 좋은 아빠가 되는 것은 불가능하다고 생각했습니다. 회사에 대한 비전이 저와 일치하는 인수자를 찾았고, 2024년 4월에 매각을 완료했습니다.

이미 매각 과정과 그 과정에서 배운 교훈에 대해 글을 쓰고 팟캐스트에서도 이야기했지만, 요약하자면 모든 것이 잘 풀린 것에 감사하고 있습니다.

아빠가 되었다

8월에 아내와 저는 첫 아이인 아들을 맞이했습니다.

출산 직후 간호사 한 분이 저희 세 가족의 아름다운 사진을 찍어 주셨는데, 아래에 첨부했습니다. 아들의 프라이버시를 보호하고 싶어서 직접 튜닝한 고속 푸리에 변환으로 사진에서 생체 정보를 제거했습니다.

인디 창업가로서 누리는 유연함과 TinyPilot 매각 타이밍에 감사하고 있습니다. 지난 5개월은 제 인생에서 가장 행복한 시간이었습니다.

교육용 제품을 만들었다

TinyPilot은 4월에 매각했지만, 인수인계를 돕기 위해 5월 중순까지 회사에 남아 있었습니다.

아들 출산 예정일은 8월이었고, 아이가 태어나면 휴식을 취할 계획이었습니다. 그러다 보니 뭔가 새로운 일을 시작할 수 있는 시간은 3개월뿐이었고, 그마저도 출산 후의 삶에 적응하는 동안 몇 달간 미뤄둘 수 있는 일이어야 했습니다.

그래서 그 3개월 동안 가장 적합한 제품은 다운로드 가능한 강의나 책이라고 판단했습니다. 교육용 제품은 작업을 잠시 멈추기 쉽고, 유료 고객이 있더라도 서버를 계속 운영하거나 지원 문의를 처리할 필요가 없기 때문입니다.

교육용 제품을 만들어 본 경험은 2021년이 유일했습니다. 기술 독자를 위한 블로깅에 대한 동영상 강의를 녹화했는데, 첫해에 7,600달러, 그 이후에 2,200달러를 더 벌었습니다. 강의 제작자 기준으로 대히트는 아니지만, 제작에 약 100시간이 들었고 콘텐츠 자체에 자부심을 느낍니다. 인디 창업가가 된 이후로 투자 대비 수익률이 가장 높은 프로젝트였습니다.

여름 동안 2021년 블로깅 강의 자료를 개정했습니다. 매주 라이브 화상 통화로 소규모 학생 그룹을 가르치는 것부터 시작했습니다. 학생들의 피드백을 바탕으로 강의를 계속 다듬은 뒤, 최종 다운로드 버전을 녹화해 판매할 계획이었습니다.

라이브 강의는 무난하게 진행됐지만, 학생들의 피드백은 독자를 끌어모으는 방법보다는 글쓰기 자체에 대해 더 배우고 싶다는 것이었습니다. 강의를 마무리하고 싶었지만 아들이 예정보다 몇 주 일찍 태어나 녹화를 끝내지 못했습니다.

아들이 태어난 뒤에는 집에서 영상을 녹화하기가 더 어려워져, 개발자를 위한 효과적인 글쓰기 기법에 대한 책을 쓰기로 방향을 바꿨습니다. 현재 챕터 단위로 공개하며 독자 피드백을 바탕으로 내용을 계속 개선하고 있습니다.

아직 일부만 녹화한 블로깅 강의 영상들이 남아 어떻게 할지 고민 중인데, 그중 하나를 공유합니다. 유명한 부트스트랩 작가 Patrick McKenzie가 블로깅 대결을 제안하면 왜 응해야 하는지에 대한 영상입니다.

멋진 기술들을 배웠다

TinyPilot을 운영할 때는 기술적인 작업을 할 시간이 없었는데, 소프트웨어를 만드는 걸 좋아하는 저로서는 아쉬운 일이었습니다.

프로그래밍을 늘 좋아했지만, 지난 1년만큼 신나게 느껴진 적은 없었습니다. 무료로 공개된 놀라운 오픈소스 소프트웨어들에 감탄하고 있습니다.

Nix

지난 1년 동안 제 작업에 가장 큰 영향을 준 기술은 Nix와 NixOS였습니다.

Nix는 apt-get이나 yum 같은 패키지 매니저이면서 CMake나 Bazel 같은 빌드 도구이기도 합니다. 이 두 기능을 합친 덕분에 소프트웨어 프로젝트의 의존성을 관리하고 배포용으로 패키징하는 일이 쉬워집니다.

조금씩 Nix를 도입해 왔는데, 너무 마음에 들어 이제는 모든 프로그래밍 프로젝트에 Nix를 쓰고 모든 컴퓨터에서 NixOS를 사용합니다.

• 누구에게 추천하나요?
  • Docker, Ansible, Terraform 같은 Infrastructure as Code 도구를 좋아하는 개발자.
• 장점은 무엇인가요?
  • 소프트웨어 프로젝트에서 모든 의존성을 소스 코드로 정의할 수 있습니다. 누구나 한 줄 명령어로 동일한 환경을 재현할 수 있습니다.
  • NixOS는 Nix 개념을 중심으로 설계된 리눅스 배포판입니다. 컴퓨터 전체 설정을 텍스트 파일로 정의할 수 있어 처음부터 다시 구축하거나 이전 설정으로 롤백하기가 쉽습니다.
  • Nix는 Docker의 많은 장점을 가지면서도, Nix 패키지가 Docker 이미지보다 더 잘 조합된다는 장점이 있습니다.
• 단점은 무엇인가요?
  • 학습 곡선이 가파르고, 개발자를 위한 괜찮은 입문 가이드를 찾지 못했습니다. 가장 가까운 자료는 DevOps 엔지니어를 대상으로 한 NixOS in Production입니다.
  • “flakes”라는 기능을 둘러싼 분열이 있습니다. flakes를 사용하면 그렇지 않은 튜토리얼과 문서를 이해하기 어렵고, 그 반대도 마찬가지입니다.
  • 리더십 문제로 Nix 커뮤니티가 건강하지 못한 상태입니다.
  • 지속적 통합(CI)에서는 작은 규모에서 효율이 떨어집니다. Nix 전용 CI 업체로 옮기지 않는 한, Nix에 의존하는 CI 작업을 55초 이내에 실행할 방법을 찾지 못했습니다.
• 어떻게 시작하면 좋을까요?
  • Nix를 조금씩 점진적으로 시도해 보세요. Nix의 일부 기능만 배워도 큰 가치를 얻을 수 있습니다.
  • Determinate Systems 인스톨러로 Nix를 설치한 뒤, nix shell로 프로그램을 실행해 보세요(예: nix shell -p cowsay 실행 후 cowsay howdy, human). 패키지 저장소에서 한 줄로 설치할 수 있는 모든 패키지를 검색해 볼 수 있습니다.
  • 일회성 셸이 마음에 들었다면, 프로젝트 하나를 위한 dev shell을 만들어 모든 의존성과 개발 도구를 단일 파일로 관리해 보세요.

htmx

친구들이 몇 년 동안 htmx를 칭찬해 왔지만, 개념이 와닿지 않았습니다.

“HTML <button> 요소로 POST 요청을 보낼 수 있다고? 그게 뭐 어때서?”

그러다 긴 비행 중에 htmx 철학을 다룬 무료 전자책 Hypermedia Systems를 읽었습니다. 그 책을 통해 htmx의 가치는 <button>으로 POST 요청을 보낼 수 있다는 데 있는 것이 아니라, 커스텀 JavaScript나 깊은 추상화 계층의 부담 없이 HTML에 간단한 상호작용을 가져오는 데 있다는 것을 깨달았습니다.

웹 개발에 지루한 JavaScript가 많이 필요하다는 건 늘 알고 있었지만, 그걸 당연하게 받아들였습니다. HTML과 CSS는 표현을 담당하고, JavaScript는 상호작용을 담당한다. 둘을 연결하려면 접착 코드가 필요하고, 접착 코드는 본질적으로 지루한 법이다, 라고 생각했습니다.

htmx의 핵심 주장은 HTML/CSS 쪽에 더 많은 상호작용을 가져오면 접착 코드와 상용구 JavaScript를 없앨 수 있으며, npm, Webpack, 거대한 프론트엔드 프레임워크 같은 복잡성과 의존성을 끌어들이지 않고도 이를 해낼 수 있다는 것입니다.

• 누구에게 추천하나요?
  • React나 Vue 같은 무거운 프레임워크보다 바닐라 JavaScript나 jQuery를 선호하는 개발자.
• 장점은 무엇인가요?
  • 그동안 얼마나 불필요한 JavaScript를 써 왔는지 깨닫게 해 줍니다.
  • htmx는 프레임워크가 아니라 라이브러리이므로 React나 Vue처럼 전부 아니면 전무 식의 도입이 필요하지 않습니다. 웹 앱의 단일 폼에만 적용해 보고 마음에 드는지 확인해 볼 수 있습니다.
  • 빌드 과정이 없으므로 Webpack/Node.js로 일반 텍스트 HTML, CSS, JavaScript를 생성할 필요가 없습니다. 작성한 코드가 브라우저에서 실행되는 코드와 동일합니다.
• 단점은 무엇인가요?
  • htmx 방식으로 사고를 전환하는 것이 어렵게 느껴졌지만, 결과적으로 더 단순한 코드가 나오는 경우가 많았습니다.
  • htmx의 오류 처리가 어색하다고 느꼈지만, 괜찮은 우회 방법이 있습니다.
  • htmx는 콘텐츠 보안 정책(CSP)을 약화시킵니다.
• 어떻게 시작하면 좋을까요?
  • htmx에 대한 제 좀 더 자세한 소개 글을 읽어 보세요.
  • ScreenJournal을 htmx로 포팅한 경험을 읽어 보세요.
  • Hypermedia Systems(무료, 온라인 공개) 초반 몇 장을 읽어 보고 자신에게 맞는지 확인해 보세요.
  • 웹 애플리케이션의 단일 폼에 htmx를 적용해 보세요.

Zig

Zig의 아이디어는 우리가 여전히 C 같은 저수준 언어로 작성해야 하는 프로그램이 있지만, 50년 된 프로그래밍 언어를 계속 사용함으로써 스스로 일을 더 어렵게 만들고 있다는 것입니다.

Zig는 C와 동일한 파워와 성능을 제공하면서도, C가 만들어졌을 당시에는 없었던 하드웨어와 컴파일러의 발전을 활용합니다.

Zig의 아이디어가 바로 마음에 들었지만, 마땅한 프로젝트를 찾지 못했습니다. 개인 프로젝트에서 C나 C++를 사용한 지 15년이 넘었고, 저는 보통 소규모 웹 앱을 만드는데 Zig는 그런 용도에 가장 적합한 도구가 아닙니다.

그래도 Zig는 정말 재미있습니다. 인터넷 없이 노트북만 가지고 무인도에 1년 동안 고립된다면, 제가 꿈꾸는 활동은 어린 시절 즐겼던 컴퓨터 게임(예: Age of Empires II, Command and Conquer)의 오픈소스 재구현을 다듬어지지 않은 C++ 코드에서 우아한 Zig로 포팅하는 것입니다.

• 누구에게 추천하나요?
  • 해당 언어들을 현대적으로 재해석한 언어에 호기심이 있는 C/C++ 프로그래머.
• 장점은 무엇인가요?
  • 오랜만에 프로그래밍이 정말 재미있었고, 원래도 프로그래밍을 꽤 재미있어 하는데 그 재미가 더했습니다. 극도로 낮은 추상화로 코딩하고, 제 애플리케이션이 메모리 조각을 몇 번 건드리는지 완전히 제어하는 데서 오는 쾌감이 있습니다.
  • Zig는 명시적인 제어 흐름과 메모리 할당을 우선시하므로 Zig 코드가 이해하기 쉽다고 느낍니다.
  • Zig 커뮤니티는 환영하는 분위기에 긍정적입니다. 질문을 하면 인내심 있고 도움이 되는 답변을 받습니다. 제가 Zig 튜토리얼을 공유하면 커뮤니티가 열렬히 환영해 줍니다.
• 단점은 무엇인가요?
  • 아직 안정적인 1.0 릴리스가 없습니다. 최신 Zig 컴파일러로 업데이트할 때마다 코드 일부를 다시 작성해야 할 가능성이 높습니다.
  • 컴파일러가 계속 바뀌기 때문에 블로그 글이나 때로는 공식 언어 문서의 예제를 그대로 쓰려면 약간 수정해야 합니다.
  • 언어를 배우기 좋은 자료를 찾지 못했습니다. 아직 Zig 관련 책이 없습니다. 주로 여러 블로그 글, 포럼 토론, Zig 언어 명세를 짜깁기하며 배우고 있습니다.
• 어떻게 시작하면 좋을까요?
  • 평소 C나 C++로 작성할 간단한 프로그램을 Zig로 대신 작성해 보세요.
  • Zig를 배우기 위한 입문 연습 문제인 Ziglings을 시도해 보세요.
    • Ziglings 연습 문제는 Zig 컴파일러의 pre-release 버전에 의존합니다. Nix가 있다면 최신 pre-release Zig 컴파일러를 nix shell 'github:mitchellh/zig-overlay#master' 실행으로 쉽게 얻을 수 있습니다.

Nix로 하는 퍼즈 테스팅

제가 Nix 이야기를 끝냈다고 생각하셨나요? 아닙니다!

보안 취약점을 찾기 위해 퍼즈 테스팅을 시도해 보고 싶었습니다. 10년 전에 VLC에서 심각한 취약점을 발견했을 때 이후로는 퍼징 도구를 사용해 본 적이 없었기 때문입니다.

Antonio Morales의 2021년 퍼즈 테스팅 튜토리얼이 좋았지만, 모든 실습에 작동하는 퍼징 환경을 구축하기 위한 지루한 사전 작업이 필요했습니다.

Nix로 퍼징 워크플로를 구현해 보니 훨씬 더 좋았습니다. Nix를 퍼징 도구로 활용하는 것에 대해 세상이 아직 잘 모르고 있다고 느껴서, Nix로 더 많은 퍼징 튜토리얼을 만들고 싶을 정도입니다.

• 누구에게 추천하나요?
  • 퍼즈 테스팅을 수행하는 모든 사람, 특히 C/C++ 코드에서 퍼즈 테스팅을 하는 사람.
• 장점은 무엇인가요?
  • Nix는 퍼징 워크플로를 재현 가능하게 만듭니다.
    • Nix에서 퍼저를 실행하도록 설정해 두면, 누구나 nix run을 입력하는 것만으로 동일한 퍼징 설정을 실행할 수 있습니다. 의존성을 따로 고민할 필요가 없습니다. Nix가 사용했던 환경을 정확히 재현해 주기 때문입니다.
  • Nix는 의존성 설치를 단순화합니다.
    • Nix는 어떤 패키지 매니저보다도 큰 패키지 저장소 중 하나를 가지고 있습니다. 퍼징 대상에 의존성이 있다면 이미 Nix 패키지 저장소에 있을 가능성이 높아 각 의존성을 빌드하기 위한 특별한 과정을 고민할 필요가 없습니다.
  • Nix는 커스텀 패치를 단순화합니다.
    • 대상을 퍼징하기 위해 커스텀 패치를 적용해야 한다면, Nix를 사용하면 이를 쉽게 적용하고 패치 파일을 퍼징 워크플로의 나머지 소스와 함께 같은 소스 트리에 보관할 수 있습니다.
  • Nix는 빌드를 캐시합니다.
    • 다양한 컴파일 옵션을 실험해도 매번 처음부터 컴파일할 필요가 없습니다. Nix가 이전에 동일한 옵션으로 컴파일한 적이 있는지 기억하고 해당 빌드를 재사용합니다. make clean을 하거나 바이너리를 수동으로 삭제할 필요가 없습니다.
• 단점은 무엇인가요?
  • 테스트하려는 코드를 Nix를 통해 빌드하는 방법을 추가로 익혀야 한다는 추상화 계층이 하나 더 생깁니다.
  • Nix는 CMake 기반 프로젝트를 빌드하는 데 마법 같은 도움을 주지만, Nix의 빌드 옵션은 모두 암시적이라 동작을 이해하기 어렵습니다.
  • Nix에서 디버그 심볼을 생성하는 데 어려움을 겪었고, 무엇을 잘못했는지 아직도 잘 모르겠습니다.
• 어떻게 시작하면 좋을까요?
  • Nix와 honggfuzz를 사용해 오픈소스 PDF 리더를 위한 퍼징 워크플로를 만든 제 입문자용 튜토리얼을 시도해 보세요.

1년은 전반적으로 어땠나?

매년 저는 인디 창업가로서의 삶이 여전히 즐거운지 자문합니다.

지난 몇 년간은 이 질문에 답하기 어려웠습니다. TinyPilot을 운영할 때는 회사와 TinyPilot 팀과 함께 일하는 것이 자랑스럽고 즐거웠지만, 하드웨어 회사의 속도와 복잡함이 제게는 벅차게 느껴졌습니다.

올해는 인디 창업가로서의 삶이 다시 즐거웠습니다. 아내와 아들과 많은 시간을 보낼 수 있는 자유가 좋았습니다. 업무 복귀가 전적으로 제 결정에 달려 있었고, 출산 후의 삶에 일을 어떻게, 언제 녹여낼지 완전히 제가 통제할 수 있다는 점에 감사했습니다.

TinyPilot 매각은 스트레스가 많고 불쾌한 과정이었지만, 돌이켜보면 기억에 남는 건 매사추세츠 서부에서 아내와 친구들과 함께 즉흥적으로 떠난 디저트 투어를 하며 축하했던 순간들입니다.

5월에는 구글 리크루터가 면접 없이 예전 직책으로 복직시켜 주겠다고 제안했지만, 전혀 마음이 동하지 않았습니다.

저는 여전히 인디 창업가로서의 삶을 즐기고 있으며, 가능한 한 오래 계속하고 싶습니다.

배운 교훈

일하지 않아도 괜찮다

아들이 태어나기 전에는 얼마나 쉴지 고민했습니다. 당연히 한 달 쉬는 건 괜찮겠죠. 그런데 한 달이 괜찮다면 두 달은 왜 안 될까요? 네 달은요? 1년은요?

아들이 태어난 후 몇 달 동안은 갑자기 자유 시간이 전혀 없어졌습니다. 더 무서운 질문과 씨름했습니다. 이제 아이가 생겼으니 원해도 다시 일로 복귀할 수 없는 건 아닐까? 글쓰기와 프로그래밍에 필요한 끊김 없는 시간을 다시는 확보할 수 없는 건 아닐까?

숨을 고르고 보니 “자유 시간이 없다”는 이유는 일주일에 며칠씩 아내와 아들과 함께 시내로 긴 산책을 나가 야외 브런치를 즐기거나, 아기를 보러 온 손님들을 맞이하느라 바빴기 때문이었습니다. 이 모든 것이 제가 좋아하는 좋은 일들이며, 다시 일하기로 마음먹는다면 여전히 제 시간을 제가 통제할 수 있다는 걸 스스로에게 상기시켜야 했습니다.

결국 업무 복귀는 자연스럽게 이루어졌고, 가족과의 시간과 충돌한다고 느껴지지도 않았습니다. 아내와 저는 저희에게 맞는 돌봄 균형을 찾았고, 아들이 자라고 다른 가족들이 돌봄을 돕기 시작하면서 계속 조정해 나가고 있습니다.

문서화는 동료가 그 문서를 실제로 사용해 보기 전까지는 완료된 게 아니다

TinyPilot 매각을 앞둔 몇 달 동안 가능한 한 많은 업무를 팀에 위임하는 데 집중했습니다. 새 소유자가 인수한 뒤 제가 아니면 할 수 없는 중요한 업무 때문에 막히는 일이 없도록 하고 싶었습니다.

모든 업무, 심지어 제가 직접 하던 일까지도 플레이북이 있었기 때문에 위임은 쉬울 거라고 생각했습니다. 팀원들에게 제 업무를 넘기기 시작하면서, “문서화되었다”고 생각했던 프로세스 중 제가 담당하던 많은 부분이 사실은 제 머릿속에만 존재한다는 걸 깨달았습니다. “릴리스 공지 작성”이나 “공개 체인지로그 업데이트” 같은 단계는 짧은 문구로 보이는 것보다 훨씬 복잡했습니다.

이제 저는 동료가 문서만을 보고 프로세스를 끝까지 따라갈 수 있을 때 비로소 그 프로세스가 문서화된 것이라고 생각합니다.

현금 보유 구매자에게 매각하면 리스크와 서류 작업이 크게 줄어든다

TinyPilot 매각에서 얻은 가장 큰 교훈 중 하나는 클로징 시기가 얼마나 큰 차이를 만드는지였습니다. 매각이 한 달씩 길어질 때마다 매도자가 추가로 감당해야 하는 리스크와 서류 작업이 얼마나 늘어나는지 미처 깨닫지 못했습니다.

구매자의 자금 조달 방식은 클로징 시기에 큰 영향을 미칩니다. 구매자가 은행에서 돈을 빌리면 은행이 거래의 핵심 의사결정자가 됩니다. 은행은 느리게 움직이고, 많은 서류를 요구하며, 거래가 무산되어도 상관하지 않기 때문에 협상이 어렵습니다.

다음에 회사를 매각한다면 현금을 보유한 구매자를 끌어들이기 위해 인센티브를 제공할 것입니다.

작년 목표 채점하기

작년에는 세 가지 큰 목표를 세웠습니다. 그 결과는 다음과 같습니다.

주 20시간으로 TinyPilot 운영하기

• 결과: 주 20시간으로 운영 시간 단축
• 등급: A

4월에 회사를 매각했기 때문에 1년 중 짧은 기간만 TinyPilot을 운영했지만, 마침내 주 20시간만으로 운영하는 목표를 달성했습니다. 이전 3년간 반복해서 세웠던 목표였습니다.

마침내 성공할 수 있었던 이유는 선택의 여지가 없었기 때문입니다. 실사와 회사 매각 관리만으로도 주당 15~20시간이 소요되어 예전처럼 하던 일을 계속할 여유가 없었습니다. 다행히 팀원들이 나서서 제가 미처 위임할 생각조차 하지 못했던 업무들을 맡아 주었습니다.

강의나 책 출간하기

• 결과: 라이브 강의는 진행했지만 강의나 책은 출간하지 못함.
• 등급: C

라이브 버전을 건너뛰었다면 강의를 출시할 수 있었을지도 모르지만, 시험 운영을 한 것은 여전히 잘한 일이라고 생각합니다. 강의의 방향성에 대해 유용한 피드백을 얻을 수 있었기 때문입니다.

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

• 결과: 주 10~20시간 소프트웨어 개발
• 등급: A

더 자주 코드를 작성하고 있으며, 정말 즐겁게 하고 있습니다.

내년 목표

5만 달러 수익 달성하기

모든 제품을 합쳐 5만 달러의 수익을 올리고 싶습니다. 반복 매출일 필요는 없습니다. 일회성 판매도 포함되지만, 제 제품을 팔아 최소 5만 달러를 버는 방법을 찾고 싶습니다.

강의나 책 출간하기

2021년부터 매년 책 출간을 목표로 세워 왔습니다. 한 번도 달성하지 못했지만, 올해는 해낼 수 있을 것 같습니다.

새로운 프로그래밍 언어 배우기

새로운 프로그래밍 언어를 배울 때마다 프로그래밍 전반에 적용할 수 있는 통찰을 얻습니다.

제가 좋아하는 블로거들이 Elixir와 Phoenix에 대해 열광하고 있어, 그 기술 스택을 한번 시도해 보고 싶습니다.