한 줄 요약

어떻게 하면 더 잘 위임할 수 있을까?

하이라이트

• 제품 의사결정과 문서를 더 잘 위임하는 방법에 대해 고민했다.
• Nix를 배운 경험과 Zig를 배운 경험을 비교했다.

목표 평가

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

TinyPilot 라이선스 검증 설계 작업 완료하기

• 결과: 설계 문서 작성을 마치고 리뷰를 완료했다.
• 점수: A

TinyPilot 고객이 최신 버전으로 업데이트하기 전에 유효한 라이선스를 보유하고 있는지 확인하는 방법에 대한 계획을 세웠다. 서드파티 라이선스 관리 솔루션(현재는 Keygen 쪽으로 기울고 있다)을 정하면 세부 사항을 더 채워야겠지만, 큰 틀은 잡았다.

신규 기기 제조 배치별 샘플 검사 프로세스 만들기

• 결과: 하지 못했다.
• 점수: F

시간이 부족했던 탓도 있다. 협력사와 관련된 몇 가지 문제를 급하게 처리해야 했고, 거기에 시간을 꽤 썼다.

또 다른 이유는 이 일이 달갑지 않은 일이라 미루게 되었다는 점이다. 제조 오류를 초기에 잡아내기 위해 중요한 일이지만, 지금까지 그다지 협조적이지 않았던 3PL에 특별히 요청을 해야 하는 일이다.

TinyPilot 연말 세무 처리하기

• 결과: 모든 협력사로부터 W-9 양식을 받았다.
• 점수: A-

이제 이 작업은 끝났고, 누가 W-9 양식을 제출해야 하는지 더 잘 이해하게 됐다. 앞으로는 막판에 몰아서 하지 않아도 될 것 같다.

TinyPilot 통계

수익은 11월보다 소폭 감소했지만, 매년 나타나는 계절적 추세다. 평소 범위는 월 7만 5천~9만 달러 정도인데, 이번 달은 그 범위의 하한에 가깝지만 걱정할 수준은 아니다.

이익이 무섭게 보이는 이유는 아직 현금 기준으로 장부를 정리하고 있기 때문이다. 서드파티 위탁 제조업체로 전환하면서 제조 비용을 선지출하는 규모가 훨씬 커졌다. 4분기에 TinyPilot은 자재와 제조에 15만 달러를 썼는데, 분기 기준으로 역대 최대 금액이다. 매출원가(COGS) 기준으로 보면 12월 TinyPilot의 이익은 실제로 9천 달러(양수 9천 달러)였다.

그럼에도 외부 제조 및 풀필먼트 업체로의 전환을 관리하는 데 집중하느라 마케팅을 소홀히 해 왔다. 다행히 TinyPilot은 지난 몇 달간 마케팅에 큰 투자를 하지 않고도 성장했지만, 영원히 그럴 수는 없으니 1월 목표 중 하나는 새로운 마케팅 채널을 모색하는 것이다.

어려운 제품 의사결정을 위임할 수 있을까?

요즘 내 시간이 어디에 쓰이는지 돌아보면, 상당 부분이 이른바 ‘어려운 제품 의사결정’에 들어가고 있다. TinyPilot에 어떤 기능이 필요한지, 거기에 얼마나 투자할지, 예상치 못한 문제가 생겼을 때 자원을 어떻게 다시 배분할지를 고민하는 시간이다.

이런 어려운 제품 의사결정을 TinyPilot 팀에 위임해 보려 했지만, 별 진전이 없었다.

기능별 비용 대비 사용자 만족도를 보여주는 차트를 만들어 팀에 “선 위에 있는 것만 하자”고 말할 수 있으면 좋을 텐데.

하지만 새로운 기능에 얼마나 투자할지를 결정할 때는 그 외에도 고려할 요소가 많다. 예를 들면 다음과 같다:

• 이 기능이 필요 없는 사용자에게 혼란이나 복잡함을 초래하지는 않을까?
• 이 기능을 장기적으로 유지보수하는 부담은 얼마나 될까?
• 이 기능이 지원팀에 어떤 영향을 미칠까?

그리고 이런 다차원 차트를 만들 수 있다 해도 모든 변수에 대해 의미 있는 추정을 하기는 어렵다. 한 사람은 5%의 사용자가 혜택을 볼 거라 생각하고, 다른 합리적인 팀원은 15%라고 추정할 수도 있다. 그 하나의 변수만으로도 기능의 가치가 3배나 달라진다. 모든 변수를 합치면 두 사람이 추정한 투자 대비 수익이 100배까지 차이날 수도 있다.

거창하게 들릴지 모르지만, 최종 결정을 내리는 사람은 ‘제품 비전’을 가지고 있어야 한다. 고객, 개발팀, 지원팀 모두와 연결되어 있어야 한다. TinyPilot에서는 그 위치에 있는 사람은 나뿐이다.

한 가지 가능한 해법은 프로덕트 매니저를 채용해 상위 전략을 계획으로 구체화하고 팀과 함께 실행하도록 하는 것이다. 하지만 이는 관리해야 할 인원이 한 명 더 늘고 팀과의 커뮤니케이션에도 계속 포함시켜야 해서 그다지 현실적이지 않다. 현재 나는 6명을 관리하고 있는데, 이 정도가 효과적으로 관리할 수 있는 상한선처럼 느껴진다.

또 다른 가능성은 기존 팀원에게 프로덕트 매니저 역할을 맡기는 것이지만, 이 역시 비현실적으로 느껴진다. 아침에 우편물 가져오기 같은 단순한 잡무가 아니라, 거의 모든 고객 및 팀과의 소통에 참여해야 하므로 주당 10~20시간의 업무가 추가된다. 설령 그렇게 한다 해도, 그 사람을 제대로 된 제품 의사결정을 내릴 수 있을 정도로 키울 수 있을지 확신이 서지 않는다.

지금으로서는 개발팀에 상위 전략과 버그 및 기능 작업에 대한 대략적인 개발 시간 예산을 계속 제공하는 것이 계획이다. 지금까지는 잘 작동해 왔지만, 팀이 더 자율적으로 의사결정을 내릴 수 있도록 도울 방법을 계속 찾고 있다.

문서 작업을 더 잘 위임할 수 있을까?

나는 문서에 까다로운 편이다. 개선할 여지가 보이면 최대한 좋게 만들 때까지 공개하고 싶지 않다.

나는 여전히 TinyPilot의 모든 블로그 글, FAQ, 튜토리얼을 검토하고, 그 때문에 공개 과정에서 병목이 되는 경우가 많다. 창업자로서 쓰는 시간 중 상당 부분이 문서 검토에 들어간다고 느낀다.

문서에 절대적인 시간을 많이 쓴다기보다, 문서 검토에 ‘깊은 사고’ 예산을 많이 쓰고 있다. 나는 하루에 한 시간 정도 글을 쓸 수 있다. 다른 사람의 글을 검토하는 일은 직접 쓰는 것보다 더 힘들다. 아이디어를 어떻게 표현할지 고민하는 데 그치지 않고, 왜 그렇게 표현해야 하는지까지 생각해야 하기 때문이다.

예전에는 코드 리뷰에서도 완벽주의 때문에 어려움을 겪었고, 사소한 것은 넘기는 법을 배워야 했다. 코드가 최대한 아름답지 않아도 사용자 경험에 영향을 주지 않으니 괜찮다. 하지만 문서는 누구나 볼 수 있고, A등급 글과 B등급 글 사이에는 분명한 차이가 있다.

그렇다면 어떻게 글의 수준을 높게 유지하면서도 내가 과정의 의존성이 되지 않을 수 있을까?

프리랜서 테크니컬 라이터를 들이는 것도 고려해 봤지만, 그러면 글쓰기 파이프라인이 더 복잡해질 것이다. 전담 작가가 있으면 오히려 사람들이 글쓰기 실력을 키우려는 의욕을 잃을까 걱정도 된다. “나는 그냥 쓰고, 고치는 건 테크니컬 라이터가 할 일이야”라고 생각하게 될 수도 있다.

글을 검토할 때 겪는 어려움 중 하나는, 내 머릿속에 전형적인 TinyPilot 고객에 대한 모델이 있지만 그 모델을 다른 사람에게 정확히 설명하는 방법을 모른다는 점이다. 그리고 다른 사람들이 그 모델을 이해한다 해도, 그에 맞춰 글을 쓰는 것 자체가 어렵다.

이를 개선하는 한 가지 방법은 과거 리뷰를 다시 살펴보고 패턴을 찾는 것이다. 패턴을 찾으면 “리뷰를 보내기 전에 스크린샷이 도움이 될 부분이 있는지, 새로운 용어를 사용하기 전에 설명하고 있는지 등을 확인하세요”라고 말할 수 있다.

팀용 Grammarly 구독이 있지만 우리 워크플로우에는 잘 맞지 않는다. 사람들이 초안을 쓸 때는 쓸지 몰라도, 매번 수정할 때마다 글 전체를 Grammarly에 복사해 붙여 넣고 싶어 하는 사람은 없다. 개발자 친화적인 Vale도 살펴봤지만 Grammarly에 비하면 원시적으로 느껴진다. Vale에 노이즈가 적은 검사 규칙을 설정해 볼 수 있을 것 같으니 한번 시도해 보려고 한다.

Nix 배우기 vs. Zig 배우기

TinyPilot의 제조와 풀필먼트를 서드파티 업체로 옮긴 결과 중 하나는 새로운 기술을 배울 시간과 정신적 여유가 더 생겼다는 점이다. 지난 2년간 멀리서 눈여겨보던 기술은 Nix와 Zig였고, 2023년 말에 드디어 두 기술을 모두 실험해 볼 수 있었다.

두 기술 모두 초보 수준으로 배워 보니, Nix를 배운 경험과 Zig를 배운 경험을 비교하는 것이 흥미롭다.

Zig는 추론으로 배우고, Nix는 복사-붙여넣기로 배운다

Zig에 대해 들었던 불만 중 하나는 문서가 부실하다는 것이다. 나 역시 문서가 꽤 간결하고 개발자보다는 컴파일러 설계자의 관점에서 쓰여 있다고 느꼈지만, 그래도 여러 논의를 뒤지고 실험을 거듭하면서 Zig에 대한 정확한 멘탈 모델을 만들 수 있었다.

6개월간 Nix를 사용했지만 여전히 Nix에 대한 멘탈 모델은 엉망이다. 여러 설명을 읽어 봤지만 개념이 제대로 정리되지 않았다. Nix 파일을 만들 때는 기존 예제를 복사해 내가 원하는 대로 조금 고치는 방법밖에 쓸 수 없다. 파일 대부분은 그냥 보일러플레이트이고, 왜 그렇게 되어 있는지 이해하지 못한다.

Zig에서 오류가 나면 보통 추론을 통해 컴파일러가 무슨 말을 하는지 이해할 수 있다. Nix에서 오류가 나면 완전히 무력감을 느낀다.

큰 차이 중 하나는 내가 C 계열 언어로는 개발 경험이 많지만 순수 함수형 언어 경험은 전혀 없다는 점인 것 같다. Zig는 C와 C++ 개발자를 대상으로 하므로, 10년간 그 언어들로 일해 온 나에게는 개념이 이해가 잘 된다.

Nix는 내가 한 번도 배워 본 적 없는 Haskell이나 다른 함수형 언어에서 영감을 많이 받은 것 같다. Haskell 개발자에게는 Nix가 더 직관적으로 느껴질 것이고, 오히려 함수형 언어에서는 그리 중요하지 않은 포인터와 메모리 할당자에 집중하는 Zig가 헷갈릴 수도 있다.

Zig의 개발 경험은 좁지만 깊고, Nix는 넓지만 얕게 느껴진다

Zig에는 패키지 관리나 코드 커버리지를 위한 툴링이 없다. 지금까지 Zig에 대해 실망했던 점 중 하나는 마이크로컨트롤러 지원이 거의 없는 것처럼 보인다는 것이다.

하지만 Zig가 뭔가를 할 수 있다고 하면 그건 제대로 해낸다. gcc를 대체할 수 있다는 주장에 회의적이었지만, gcc를 zig로 교체할 때마다 모든 것이 그냥 동작했다. Zig는 .c 파일을 Zig 파일로 바로 가져올 수 있다고 주장하는데, 실제로 그렇게 된다.

내 경험상 Nix는 Node.js 프로젝트 빌드 같은 단순한 일부터 OS 전체를 빌드하고 관리하는 일 같은 거대한 일까지 훨씬 더 넓은 범위의 일을 하려고 한다.

내 프로젝트가 Nix 툴링이 기대하는 형태와 정확히 일치하면 모든 것이 잘 동작한다. 하지만 내 설정이 Nix 툴링이 기대하는 것과 조금만 달라도 자주 벽에 부딪힌다. 예를 들어, Nix에서 임의의 Python 프로젝트를 실행하는 방법을 아직도 모르겠다.

Nix에서 가장 놀라운 공백 중 하나는 설치하고 싶은 패키지 버전을 지정하는 공식적인 방법이 없다는 점이다. 8년간 논의가 이어졌지만 해결책이 있는 것 같지도 않고, 고칠지 말지에 대한 공식 입장조차 없는 것 같다.

Nix 리더십은 분산되어 있고, Zig에는 BDFL이 있다

Andrew Kelly는 Zig의 최초 창시자다. 여러 명이 프로젝트에 합류했지만, 사실상 Andrew가 여전히 종신 자애로운 독재자(BDFL)로 남아 있다. Zig 문서나 도움을 검색할 때 GitHub 이슈나 포럼 토론에서 Andrew나 프로젝트 공식 관계자가 답변하는 경우를 자주 봤다.

Nix를 처음 들었을 때 Eelco Dolstra가 Nix의 BDFL일 거라고 생각했다. 적어도 공개적으로는 그렇지 않은 것 같다.

Nix는 2006년 박사 학위 논문에서 나온 Eelco의 아이디어다. Eelco는 Nix Foundation의 회장이지만, 동시에 Nix를 홍보하는 서드파티 컨설팅 회사인 Determinate Systems에서도 일한다. 하지만 Determinate Systems는 분명히 서드파티이며 Nix의 핵심 조직이 아니다. 그들이 내놓는 것들은 때때로 내부 Nix 팀의 작업과 충돌하고 논란이 되기도 한다.

Zig은 중앙에서 계획되는 느낌이 드는 반면, Nix는 방향을 잃은 느낌이다. 무언가를 이해하지 못해 검색하면 GitHub나 Nix Discourse 포럼의 두서없는 토론으로 이어지는 경우가 많다. 대화들은 마치 우연히 발견한 외계 기술을 논하는 사람들처럼 들린다. Nix 코어 팀 누군가가 의견을 내는 것을 본 적이 없고, 코어 팀 자체가 존재하는지도 모르겠다.

오래된 해법은 Nix나 Zig에서 대개 통하지 않는다

Zig는 아직 안정적인 1.0 릴리스를 선언하지 않았으므로, 컴파일러 업데이트가 호환성을 깨뜨리는 변경을 만드는 것이 일반적이다. Zig 0.8.0에서 유효하던 코드가 Zig 0.11.0에서는 유효하지 않을 수 있다. 내 경험상 Zig 툴링은 코드를 자동으로 고치는 데 꽤 능하지만 100% 정확하지는 않다.

Nix에서도 마찬가지로 오래된 예제 때문에 문제를 겪었다. Nix는 상당히 새롭고 아직 공식적이지 않은 기능인 flakes를 둘러싼 논란의 한가운데에 있다. 하지만 최근 가이드는 모두 flakes를 사용하고, 오래된 논의들은 flakes 이전 방식을 사용하므로, flakes 이전 해법을 flakes 이후 환경에 적용하는 데 어려움을 겪는다.

Zig는 팀 전체의 동의가 필요하지만, Nix는 부분 도입이 쉽다

Nix의 좋은 점 중 하나는 자립적(self-contained)이라는 것이다. 내 프로젝트 중 하나에 flake.nix 하나를 넣기만 하면 다른 것을 바꾸거나 팀원에게 뭐라 할 필요 없이 의존성을 자동으로 관리할 수 있다.

팀에서 나만 Nix를 쓰더라도 flake.nix는 다른 사람에게 비용을 주거나 새 툴을 쓰도록 요구하지 않으면서 나에게는 큰 가치를 준다. 프로젝트에 .vscode 디렉터리를 추가하는 것과 비슷하다. VS Code를 쓰는 사람에게는 도움이 되고, 다른 사람에게는 별로 방해가 되지 않는다.

반면 Zig는 헌신과 팀 전체의 동의가 필요하다. C나 C++ 프로젝트가 있는데 Zig로 전환하고 싶다고 해도, 혼자 더 나은 툴링을 즐기며 팀원들이 합류하기를 기다릴 수 없다. 프로젝트에 Zig 코드를 도입하는 순간 모두가 C/C++ 컴파일러가 아닌 Zig 컴파일러로 빌드해야 한다.

Zig의 잘못은 아니지만, 결과적으로 나는 코드를 만지작거리거나 Zig 프로젝트를 볼 때처럼 Zig-land를 방문할 때만 Zig를 접하게 되는 반면, 이제는 어디를 가든 Nix를 함께 가지고 다니게 됐다.

마무리

무엇을 했나?

• TinyPilot 라이선스 검증 설계 작업을 완료했다.
• 새로운 블로그 노트 3개를 발행했다.
  • “Using Zig to Unit Test a C Application”이 Hacker News, Lobsters와 Ziggit에서 인기를 끌었다.
• 연말 세무 처리를 완료했다.

배운 점

• 문서 리뷰에 대한 주기적인 메타 리뷰가 도움이 될 수 있다.
  • 현재는 글 하나 단위로만 개선점을 논의하고 있지만, 여러 글에 걸쳐 반복되는 패턴을 검토하면 팀의 글쓰기 실력이 더 향상될 수 있다.
• Vale이 문서 리뷰 전에 사소한 문제를 잡는 데 유용할 수 있다.

다음 달 목표

• 연간 회고를 발행한다.
• 블로거 5명에게 TinyPilot 협업에 대해 연락한다.
• 2023년 세금 신고를 위한 기록을 준비한다.

도움 요청

• 소량 주문(월 100~200건 배송)을 처리하는 괜찮은 3PL을 써 본 경험이 있다면 알려 달라. 현재 좋은 3PL을 찾고 있다.