한 줄 요약

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

목표 점검

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

연간 회고록 발행하기

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

예정보다 몇 주 늦게 발행했지만, 결과물이 만족스러웠습니다.

이 글은 Hacker News 1위를 차지했는데, 재미있기도 했지만 돈 이야기를 꺼내는 것이 양날의 검이라는 사실도 다시 느꼈습니다. 숫자를 공개하면 독자들의 관심과 흥미가 훨씬 커지지만, 댓글 대부분은 숫자 이야기에만 집중됐습니다.

TinyPilot 협업을 위해 블로거 5명에게 연락하기

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

TinyPilot 릴리스 과정을 문서화하는 데 예상보다 많은 시간이 걸려 블로거에게 연락할 여유가 줄었습니다. 두 명에게 연락했지만 두 곳 모두에서 답을 받지 못했습니다.

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

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

세금 정리는 언제나 지루하지만, 올해는 모든 일정이 순조롭게 진행되고 있습니다.

TinyPilot 통계

TinyPilot은 역대 두 번째로 높은 월 매출을 기록했습니다. 특별한 이유는 없으며, 그냥 일반적인 판매 변동 때문이라고 생각합니다. 평소 월 매출은 7만 5천~9만 5천 달러 선인데, 이번 달은 변동폭 중에서도 높은 쪽에 걸렸고 몇 건의 대량 주문이 더해져 10만 달러를 넘겼습니다.

순이익은 비정상적으로 높게 나왔지만, 위탁 제조로 전환한 뒤 원자재 비용 지출이 간헐적으로 몰리기 때문입니다. 3개월 이동 평균이 플러스를 유지하고 있어 다행이며, 다만 평소보다는 낮은 수준입니다.

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

초기에 TinyPilot 장비를 몇 대 판매할 때만 해도 개발용 컴퓨터에서 microSD를 제대로 복제하지 못했습니다. 그래서 microSD에 Linux를 직접 플래싱한 뒤 TinyPilot 설치 스크립트를 한 대씩 수동으로 실행해 고객용 microSD를 하나하나 준비했습니다.

그 이후 하드웨어용 소프트웨어를 릴리스하는 과정에 대해 많은 것을 배웠습니다. 지금은 테스트가 더 촘촘해지고 재현성이 높아졌으며 자동화도 추가되어 릴리스 과정이 한층 성숙해졌습니다.

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

적어도 저는 그렇게 생각했습니다.

가장 최근 릴리스에서는 직접 어떤 단계도 수행하지 않기로 스스로에게 도전했습니다. 대신 팀원들에게 제가 작성한 문서를 바탕으로 릴리스를 진행해 달라고 부탁했습니다.

팀원에게 첫 번째 작업을 부탁하기도 전에, 얼마나 많은 과정을 제 머릿속에만 가둬두고 있었는지 깨달았습니다. 릴리스의 각 단계는 모두 문서화되어 있었지만, 그 단계들이 어떻게 연결되어 전체 흐름을 이루는지에 대한 설명은 없었습니다.

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

과정을 문서화하는 것의 장점은 모든 결정을 의도적으로 다시 생각해보게 만든다는 점입니다. 과거 릴리스를 살펴보며 패턴을 찾으려다 제 결정이 일관되지 않았다는 사실을 깨달은 경우가 많았습니다. 반대로 일관되게 해온 일도 있었지만, 이유를 설명하려다 보니 더 나은 전략이 있다는 것을 알게 되기도 했습니다.

릴리스 전체를 위임하는 것은 제가 직접 할 때보다 더 느리지만, 매우 가치 있는 경험이었습니다. 릴리스 과정이 저에게 덜 의존하게 되었고, 과정을 개선할 기회가 생겼으며, 앞으로는 세부 작업을 병렬로 진행하기도 더 쉬워졌습니다.

사이드 프로젝트

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

지난 몇 달간 Zig을 탐구해 왔습니다. 더 깊이 배우는 데 가장 큰 장애물 중 하나는 Zig에 잘 맞는 프로젝트를 찾는 일이었습니다.

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

지난 몇 달간 Crafting Interpreters by Bob Nystrom과 Mastering Ethereum by Andreas M. Antonopoulos and Gavin Wood를 틈틈이 읽어 왔습니다. 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와 이더리움, 인터프리터에 대한 지식을 쌓는 실전적인 방법이 되고 있습니다. OS로부터 읽거나 할당하는 모든 바이트를 신중하게 다뤄야 해서, 오랜만에 즐겁게 몰입할 수 있는 프로그래밍이기도 합니다.

마무리

완료한 일

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

배운 점

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

다음 달 목표

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