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 같은 인프라 코드화 도구를 좋아하는 개발자.
• 왜 써야 할까?
  • 소프트웨어 프로젝트에서 Nix를 이용하면 모든 의존성을 소스 코드로 정의할 수 있습니다. 누구나 한 줄 명령어로 동일한 환경을 재현할 수 있습니다.
  • NixOS는 Nix 철학을 기반으로 설계된 리눅스 배포판입니다. NixOS를 이용하면 컴퓨터 전체 설정을 텍스트 파일로 정의할 수 있습니다. 이를 통해 컴퓨터를 처음부터 다시 구축하거나 이전 설정으로 쉽게 롤백할 수 있습니다.
  • Nix는 Docker의 많은 장점을 가지고 있으면서도 Docker 이미지보다 패키지 간 조합이 더 잘 됩니다.
• 단점은 무엇인가?
  • 학습 곡선이 가파르고 개발자를 위한 제대로 된 입문 가이드를 찾지 못했습니다. 그나마 가장 가까운 자료는 DevOps 엔지니어 대상인 NixOS in Production입니다.
  • “flakes”라는 기능을 둘러싼 분열이 있습니다. flakes를 사용하면 그렇지 않은 튜토리얼과 문서를 이해하기 어렵고, 반대의 경우도 마찬가지입니다.
  • 리더십 문제로 Nix 커뮤니티가 건강하지 못한 상태입니다.
  • 지속적 통합(CI)에서는 규모가 작을 때 효율이 떨어집니다. Nix 전용 CI 벤더로 바꾸지 않는 한 Nix에 의존하는 CI 작업을 55초 이내에 실행할 방법을 찾지 못했습니다.
• 어떻게 시작하면 좋을까?
  • 작은 단위부터 점진적으로 시도해 보세요. 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를 보낼 수 있게 하는 데 있는 것이 아니라 커스텀 자바스크립트나 두꺼운 추상화 계층 없이 HTML에 간단한 상호작용을 더하는 데 있음을 깨달았습니다.

웹 개발에는 지루한 자바스크립트가 많이 필요하다는 걸 늘 알고 있었지만 그게 당연한 일이라고 받아들였습니다. HTML과 CSS는 표현을 담당하고 자바스크립트는 상호작용을 담당한다. 둘을 연결하려면 접착제 코드가 필요하고 접착제 코드는 본질적으로 지루한 법이니까요.

htmx의 핵심 주장은 HTML/CSS 쪽에 더 많은 상호작용을 가져오면 접착제 코드와 상투적인 자바스크립트를 없앨 수 있으며 npm, Webpack, 거대한 프론트엔드 프레임워크 같은 복잡성과 의존성을 도입할 필요도 없다는 것입니다.

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

Zig

Zig의 아이디어는 C 같은 로우레벨 언어로 작성해야 하는 프로그램이 여전히 존재하지만 50년 된 프로그래밍 언어를 계속 사용함으로써 스스로 일을 어렵게 만들고 있다는 데서 출발합니다.

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

저는 Zig의 아이디어를 듣자마자 마음에 들었지만 마땅한 프로젝트를 찾기 어려웠습니다. 지난 15년간 개인 프로젝트에서 C나 C++를 써본 적이 없습니다. 저는 보통 소규모 웹 앱을 만들고 Zig는 그런 용도에 최적의 도구가 아닙니다.

그럼에도 Zig는 정말 재미있습니다. 인터넷 없이 노트북 하나만 들고 무인도에 1년간 고립된다면 어린 시절 즐겨 하던 컴퓨터 게임(예: Age of Empires II, Command and Conquer)의 오픈소스 재구현을 세련되지 않은 C++ 코드에서 우아한 Zig로 포팅하는 상상을 하곤 합니다.

• 누가 시도해 보면 좋을까?
  • C/C++를 현대적으로 재해석한 언어에 관심 있는 C/C++ 프로그래머.
• 왜 써야 할까?
  • Zig는 오랜만에 프로그래밍이 정말 재미있다고 느끼게 해준 언어이며 저는 원래 프로그래밍 자체를 꽤 즐기는 편입니다. 극도로 낮은 추상도로 코딩하고 애플리케이션이 메모리를 몇 번 건드리는지까지 완전히 제어하는 데서 오는 쾌감이 있습니다.
  • Zig는 명시적인 제어 흐름과 메모리 할당을 중시하므로 Zig 코드를 이해하고 추론하기 쉽다고 느낍니다.
  • Zig 커뮤니티는 환영하는 분위기이고 긍정적입니다. 질문을 하면 인내심 있고 도움이 되는 답변을 받을 수 있습니다. 제가 Zig 튜토리얼을 공유하면 커뮤니티가 열렬히 환영해 줍니다.
• 단점은 무엇인가?
  • 아직 안정적인 1.0 릴리스가 없습니다. 최신 Zig 컴파일러로 업데이트할 때마다 코드 일부를 다시 작성해야 할 가능성이 큽니다.
  • 컴파일러가 자주 바뀌기 때문에 블로그 글이나 심지어 공식 언어 문서의 예제를 그대로 실행하려면 수정이 필요한 경우가 많습니다.
  • 언어를 배우기 위한 좋은 자료를 찾지 못했습니다. 아직 Zig 관련 서적이 없습니다. 주로 여러 블로그 글, 포럼 토론, Zig 언어 명세를 짜깁기하며 배웁니다.
• 어떻게 시작하면 좋을까?
  • 평소 C나 C++로 작성할 간단한 프로그램을 Zig로 작성해 보세요.
  • Zig를 배우기 위한 입문용 연습 문제인 Ziglings를 해보세요.
    • Ziglings 연습 문제는 Zig 컴파일러의 프리릴리스 버전에 의존합니다. Nix가 있다면 최신 프리릴리스 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와 honggfuzz를 이용해 오픈소스 PDF 리더용 퍼즈 워크플로를 만든 제 입문자용 튜토리얼을 시도해 보세요.

한 해를 돌아보면

매년 저는 인디 창업가로서의 삶이 여전히 즐거운지 스스로에게 묻습니다.

지난 몇 년간 이 질문에 답하기 어려웠습니다. 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에 대해 열광하고 있어 그 기술 스택을 한 번 시도해 보고 싶습니다.