한 줄 요약

나도 모르게 TinyPilot의 릴리스 과정을 독점하고 있었다.

목표 성적표

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

연간 회고 발행

• 결과: “My Sixth Year as a Bootstrapped Founder” 발행
• 평가: A

발행이 몇 주 늦어지긴 했지만 결과물에는 만족한다.

이 글은 Hacker News에서 하루 동안 1위를 차지했는데, 재미있으면서도 돈 이야기를 하는 것이 양날의 검임을 보여준다. 숫자를 공유하면 독자들의 관심과 흥미가 훨씬 커지지만, 댓글의 대부분은 숫자 이야기에만 집중됐다.

블로거 5명에게 TinyPilot 협업 제안하기

• 결과: 블로거 2명에게 연락
• 평가: C

TinyPilot 릴리스 과정을 문서화하는 데 예상보다 많은 시간이 들어 블로거들에게 연락할 시간이 부족했다. 두 명에게 연락했지만 둘 다 답장을 받지 못했다.

2023년 세금 신고 자료 준비하기

• 결과: 모든 세금 서류 준비 완료
• 평가: A

세금 작업은 언제나 지루하지만, 올해는 모든 것이 일정대로 진행되고 있다.

TinyPilot 통계

TinyPilot은 역대 두 번째로 높은 월간 수익을 기록했다. 특별한 이유는 없고 그냥 매출의 자연스러운 변동이라고 생각한다. 보통 한 달 매출은 7만 5천~9만 5천 달러 선인데, 이번 달은 변동폭의 높은 쪽에 걸렸고 몇 건의 큰 주문이 겹치면서 10만 달러를 넘겼다.

이익은 터무니없이 높게 찍혔는데, 이 역시 외주 제조사로 전환한 뒤 원자재 비용 지출이 한 번에 몰리는 특성 때문이다. 3개월 이동 평균이 플러스로 돌아온 건 반갑지만 평소보다는 낮은 수준이다.

나도 모르게 TinyPilot의 릴리스 과정을 독점하고 있었다

TinyPilot 기기를 처음 몇 대 팔았을 때는 개발용 컴퓨터에서 microSD를 제대로 복제하지 못했다. 그래서 Linux를 microSD에 플래싱한 뒤 TinyPilot 설치 스크립트를 기기마다 일일이 수동으로 실행하는 방식으로 고객용 microSD를 하나씩 만들었다.

그 이후로 하드웨어 장치용 소프트웨어 릴리스 과정에 대해 많은 것을 배웠다. 이제 릴리스 과정은 훨씬 더 성숙해졌고, 테스트도 더 철저해졌으며 재현성과 자동화 수준도 높아졌다.

릴리스 과정은 TinyPilot 공용 Notion 워크스페이스에 문서화해 두었고, 새로운 TinyPilot 릴리스가 나 때문에 막히지 않도록 대부분의 과정을 팀원들에게 위임했다.

적어도 나는 그렇게 생각했다.

최근 릴리스에서는 릴리스 단계를 직접 수행하지 않기로 스스로에게 도전했다. 대신 문서에 기반해 팀원들이 릴리스를 진행하도록 부탁했다.

팀원에게 첫 번째 작업을 부탁하기도 전에, 과정 중 얼마나 많은 부분을 내 머릿속에만 가둬두고 있었는지 깨달았다. 릴리스의 모든 단계는 문서화되어 있었지만, 각 단계가 어떻게 맞물려 돌아가는지를 설명하는 내용은 전혀 없었다.

또 “변경 로그 업데이트”나 “릴리스 공지 작성” 같은 작업이 짧은 문구로 보이는 것보다 훨씬 복잡하다는 것도 알게 됐다. 공지에서 어떤 기능을 강조해야 할까? 지루한 세부 사항에 빠지지 않으면서 기능을 설명하는 암묵적인 규칙은 무엇일까?

과정을 문서화하는 것의 장점은 모든 결정을 의도적으로 고민하게 만든다는 점이다. 과거 릴리스들을 훑으며 패턴을 추론하려 한 경우가 많았는데, 그러다 내 결정이 일관되지 않았다는 걸 깨달았다. 어떤 경우에는 일관되게 해온 일이 있었지만, 이유를 설명하려다 보니 더 나은 전략이 있다는 걸 알게 되기도 했다.

전체 릴리스를 위임하는 것은 내가 직접 할 때보다 느렸지만 가치 있는 연습이었다. 릴리스 과정이 나에게 의존하는 정도를 줄이고, 과정을 개선할 기회를 만들며, 앞으로 하위 작업들을 병렬로 진행하기도 더 쉬워진다.

사이드 프로젝트

Zig로 바이트코드 인터프리터 구현하기

지난 몇 달간 Zig를 탐색해 왔는데, 더 깊이 배우는 데 가장 큰 장애물은 Zig에 잘 맞는 프로젝트를 찾기 어렵다는 점이다.

내가 떠올리는 프로젝트 아이디어 대부분은 웹 앱이라 보통 Go를 쓰게 된다. Go는 웹 앱을 만들기 위해 설계된 반면, Zig는 C를 대체하는 더 범용적인 언어로 설계됐기 때문이다.

지난 몇 달간 틈틈이 Bob Nystrom의 Crafting Interpreters와 Andreas M. Antonopoulos와 Gavin Wood가 쓴 Mastering Ethereum을 읽었다. Crafting Interpreters는 C로 바이트코드 인터프리터를 구현하는 방법을 보여주고, Mastering Ethereum은 이더리움의 핵심이 이더리움 가상 머신(EVM)이라는 바이트코드 인터프리터라는 점을 설명한다.

몇 가지 관심사를 결합해 Zig로 이더리움 가상 머신을 구현하면 좋겠다고 생각했다. 그래서 eth-zvm이라는 프로젝트를 시작했다.

아직 이더리움의 2% 정도밖에 구현하지 못했지만, 내 인터프리터는 이미 실제 이더리움 프로그램을 실행하고 결과를 반환할 수 있다.

내 인터프리터가 이더리움 바이트코드로 컴파일된 간단한 프로그램을 실행할 때 모습은 다음과 같다:

$ echo '600160005260206000f3' | xxd -r -p | zig-out/bin/eth-zvm -v
PUSH1 0x01
  Stack: push 0x1
---
PUSH1 0x00
  Stack: push 0x0
---
MSTORE
  Stack: pop 0x0
  Stack: pop 0x1
  Memory: Writing value=0x1 to memory offset=0
  Memory: 0x00000000000000000000000000000001
---
PUSH1 0x20
  Stack: push 0x20
---
PUSH1 0x00
  Stack: push 0x0
---
RETURN
  Stack: pop 0x0
  Stack: pop 0x20
  Memory: reading size=32 bytes from offset=0
  Return value: 0x0000000000000000000000000000000000000000000000000000000000000001
---
EVM gas used:    18
execution time:  792.395µs
0x0000000000000000000000000000000000000000000000000000000000000001

내 인터프리터의 결과를 evm.codes 플레이그라운드의 JavaScript 구현과 비교해 볼 수 있다.

Zig 자체가 성능에 최적화되어 있으니 다른 인터프리터를 성능 면에서 쉽게 압도할 줄 알았는데, 이더리움 공식 Go 구현이 꽤 빠른 것으로 드러났다:

내 인터프리터는 아직 활용하지 않은 성능 최적화 여지가 많이 남아 있어서, 메모리 할당을 좀 줄이는 데 시간을 투자하면 다른 구현들을 이길 수 있을 것 같다.

이 프로젝트를 어디까지 끌고 갈지는 모르겠지만, Zig와 이더리움, 인터프리터에 대한 지식을 쌓는 실용적인 방법이 되고 있다. 또 운영체제에서 읽거나 할당하는 모든 바이트를 신중하게 다뤄야 해서, 오랜만에 하는 재미있는 유형의 프로그래밍이기도 하다.

마무리

무엇을 해냈나?

• “My Sixth Year as a Bootstrapped Founder”를 발행했으며, 당일 Hacker News 1위를 차지했다.
• TinyPilot 릴리스 과정 문서화를 시작했다.

배운 점

• 누군가 실제로 그 문서를 보고 과정을 따라 해보기 전까지는, 그 과정이 제대로 문서화된 것이 아니다.

다음 달 목표

• TinyPilot Pro 2.6.3 출시하기.
• TinyPilot Pro 릴리스 과정을 내부 문서로 정리하기.
• 2023년 세금 신고하기.