한 줄 요약

릴리스의 핵심 경로에서 나 자신을 제외하기

하이라이트

• 우린 내가 직접 어떤 릴리스 작업도 수행하지 않은 최초의 TinyPilot 릴리스를 완료했습니다.
• 위임을 통한 릴리스 진행 덕분에 릴리스 프로세스에서 문서화되지 않았거나 제대로 설계되지 않은 많은 단계들을 발견할 수 있었습니다.
• Zig로 바이트코드 인터프리터를 작성하는 작업을 계속 즐기고 있습니다.

목표 평가

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

TinyPilot Pro 2.6.3 출시

• 결과: 릴리스를 출시했습니다.
• 등급: A

우연히 나에게만 집중되어 있던 릴리스 단계가 있는지 드러내려 했기 때문에, 이번은 내가 직접 어떤 릴리스 단계도 수행하지 않은 첫 번째 릴리스였습니다. 팀은 변경 목록 작성과 릴리스 공지를 비롯한 모든 단계를 공유된 문서를 바탕으로 수행했습니다.

TinyPilot Pro 릴리스 프로세스 내부 문서화

• 결과: 릴리스를 커버할 만큼은 문서화했지만, 여전히 개선할 부분이 남아 있습니다.
• 등급: B+

릴리스 프로세스를 문서화하는 것은 아주 유익한 작업이었습니다. 문서화되지 않은 절차뿐 아니라 프로세스 자체의 약점도 드러났습니다.

우리 릴리스 프로세스 중에는 비판적으로 검토하지 않은 부분이 많았습니다. 직접 문서화하려고 앉아 보니, 불필요하게 노동 집약적이거나 오류가 발생하기 쉽고, 바퀴를 재발명하는 격인 단계들이 여럿 있었습니다.

2023년 세금 신고

• 결과: 대부분 서류는 모았지만, 아직 신고하지 못했습니다.
• 등급: B

결국 TinyPilot 릴리스에 신경이 쏠려 아직 신고하지 못했습니다. 그래도 올해 안에는 신고하는 걸 정부가 반가워할 것 같으니, 아마 해야 할 것 같습니다.

TinyPilot 통계

연간 회고가 주목을 받으면서 방문자가 크게 늘었지만, TinyPilot 판매에는 큰 영향을 주지 않은 것 같습니다. 판매가 17% 감소했는데, 이는 주로 1월이 이례적으로 호조였던 탓입니다. 보통 월 매출은 7만 5천~9만 5천 달러 선입니다.

외주 제조업체로 전환한 뒤로는 현금 기준 순이익 수치가 월 단위로는 사실상 의미가 없어져서, 월별 순이익을 보고하는 방식을 새로 고민해야 합니다. 매달 순이익은 3~4개월마다 지급하는 제조 비용 청구 시점에 크게 좌우됩니다.

그럼에도 3개월 이동 평균 순이익은 제가 기대하는 1만~2만 달러 범위로 다시 돌아왔습니다.

알고 보니 우리 릴리스 프로세스는 25단계였다

원래 TinyPilot 소프트웨어 릴리스는 전적으로 제 일이었습니다. 제품이 성숙해지고 프로세스에 단계가 추가되면서 릴리스 하나에 10~20시간이 걸리게 됐습니다.

시작한 지 약 18개월쯤 되었을 때, 가장 까다로운 릴리스 작업들을 동료들에게 위임했습니다. 수동 테스트 대부분이 포함됐죠. 덕분에 릴리스당 제 작업 시간은 3~5시간으로 줄었고, 위임을 꽤 잘했다고 생각했습니다.

지난 TinyPilot 릴리스에서는 모든 것을 위임해 보자고 스스로에게 과제를 줬습니다. 제가 자리를 비웠을 때도 릴리스가 진행될 수 있도록 하고 싶었습니다.

제가 여전히 맡고 있던 작업들의 설명서를 쓰기 시작하면서, 몇 단계 정도만 문서화하면 될 거라 예상했습니다.

매 릴리스마다 제가 하던 일을 하나하나 나열해 보니, 릴리스 하나에 무려 25개의 개별 작업이 포함되어 있다는 걸 알게 됐습니다:

릴리스 후보 테스트

1. 릴리스 후보 빌드 생성
2. 변경 로그 초안 작성
3. 보안 권고 초안 작성(해당 시)
4. 릴리스 공지 초안 작성
5. 기능 변경 사항을 반영하도록 테스트 계획 업데이트
6. Voyager 기기에서 릴리스 후보 테스트
7. 기존 정식 빌드에서 릴리스 후보로의 업데이트 테스트
8. DIY 기기에서 릴리스 후보 테스트
9. 실물 기기 대상 자동화된 E2E 테스트 실행
10. 테스트 결과 검토
11. 릴리스 출시 여부 결정

릴리스 출시

1. 보안 권고 게시(해당 시)
2. 변경 로그 게시
3. TinyPilot Pro 프로덕션 릴리스 게시
4. 최신 버전으로 업데이트가 정상적으로 동작하는지 확인
5. TinyPilot 팀에 릴리스 공지
6. 변경 로그에 이미지 해시 추가
7. 최소 48시간 동안 버그 리포트 모니터링

릴리스 알리기

1. TinyPilot Community 릴리스 게시
2. 릴리스 공지 블로그 글 게시
3. EU 유통사에 릴리스 공유
4. 제조사에 릴리스 공유
5. 내부 플레이북 링크 업데이트
6. 공개 메일링 리스트에 릴리스 공지 발송
7. TinyPilot 트위터에 블로그 글 공유

제가 문서화하고 위임한 작업은 수동 테스트가 필요한 세 가지뿐이었습니다. 나머지 22개는 여전히 제가 직접 하고 있었습니다.

목록을 보면 릴리스 하나에 25단계라니 많아 보입니다. 사실 특정 작업 안에는 수십 개의 세부 단계가 있어 체감상 훨씬 더 많습니다.

수동 단계가 이렇게 많으면 더 자동화해야 할 것 같지만, 딱히 자동화할 만한 대상이 눈에 띄지 않습니다. 변경 로그에 이미지 해시를 추가하거나 내부 플레이북 링크를 업데이트하는 단계 정도는 자동화할 수 있겠지만, 연간 두 시간 정도를 아끼자고 자동화에 10시간을 들이는 셈이 될 겁니다.

저에게 더 중요한 교훈은 릴리스에 작업을 추가할 때 신중해야 하며, 현재 있는 작업들의 필요성도 계속 의문을 가져야 한다는 점입니다.

릴리스 전 버그는 어떻게 잡을까?

릴리스 작업 위임은 일반적인 위임보다 어렵다는 걸 알게 됐습니다. 제가 결정을 내리는 방식을 설명할 수 있다 해도, 동료들에게는 그 결정을 내릴 맥락이 부족했기 때문입니다.

예를 들어 최종 테스트 중에 마주한 버그를 공유해 보겠습니다.

보통 기기를 네트워크에 연결하면 라우터가 할당하는 로컬 IP 주소를 그대로 사용합니다. 일부 TinyPilot 사용자는 기기가 고정된 예측 가능한 IP 주소를 요청하길 원합니다. 이번 릴리스에서는 TinyPilot 웹 인터페이스에서 고정 IP 주소를 할당하는 기능을 추가했습니다.

릴리스 전 테스트에서 이 기능이 어떻게 동작했는지 보겠습니다:

고객 지원팀이 테스트를 실행했고 아무 문제가 없다고 보고했습니다. 테스트 계획대로 페이지가 새 IP 주소에서 로드됐습니다. 지원 엔지니어링팀도 테스트 영상을 검토한 뒤 기능이 정상 동작한다고 보고했습니다.

제가 영상을 검토하니 큰 문제가 보였습니다. 웹 인터페이스가 새 주소에서 로드되기 전 몇 초 동안 사용자에게 이런 무서운 오류 화면이 나타났습니다:

개발팀에 보여주자 모두 크게 낙담했습니다.

우리는 동적 IP에서 고정 IP로 사용자를 안내하는 UI에 수주 간의 개발 시간을 투자했습니다. DNS 캐싱, 로컬 TLS 인증서, 교차 도메인 요청에 대한 브라우저 보안 보호 등 때문에 특히 까다로운 작업이었습니다. 많은 테스트와 오케스트레이션 코드를 거친 끝에 개발팀은 마침내 제대로 만들었다고 생각했지만, 막상 TinyPilot 사무실에서는 부드럽게 동작하지 않았습니다.

그렇다면 제가 일일이 간섭하지 않고도 이런 버그를 어떻게 잡을 수 있을까요? 서로 다른 팀이 기능 동작을 기대하는 방식 사이의 간극은 어떻게 메울 수 있을까요?

우리는 프로세스를 조정하기로 했습니다. 개발팀이 새 기능을 출시하거나 기존 동작을 변경할 때, 기대한 대로 동작하는지 확인하기 위해 릴리스 전 테스트 영상을 직접 검토하도록 했습니다.

어떤 버그를 고칠지 어떻게 결정할까?

릴리스 프로세스 위임에서 다음 과제는 릴리스 매니저가 릴리스 전 테스트에서 발견한 버그를 어떻게 처리할지 정하는 것이었습니다. 릴리스를 연기해야 할까요? 아니면 버그를 그대로 두고 출시해야 할까요?

릴리스가 저에게 집중되어 있을 때는 출시냐 수정이냐를 결정하기가 더 쉬웠습니다. 팀 전반의 맥락을 알고 있었기 때문입니다. 개발팀과 긴밀히 소통하고 있어 버그 수정에 얼마나 걸리는지, 수정 과정에서 다른 것이 깨질 위험은 얼마나 되는지 알고 있었습니다. 동시에 제품 책임자이기도 해서 그 버그가 고객에게 얼마나 영향을 줄지도 이해하고 있었습니다. 버그 수정 비용에 비해 기능이 충분히 중요하다면 릴리스를 미루고 버그를 고쳤습니다.

릴리스 매니저가 제가 아닐 경우, 버그를 고치기 위해 릴리스를 언제 연기해야 할지 어떻게 결정할 수 있을까요?

우리의 새로운 전략은 릴리스 매니저가 직접 결정하지 않고, 다른 팀들로부터 모든 정보를 모아 제품 책임자가 결정하도록 하는 것입니다. 이렇게 하면 의사결정에 필요한 정보를 모으는 과정과 실제 결정을 분리할 수 있습니다. 이는 오직 저만 할 수 있는 릴리스 작업을 최소화하려는 목표에도 부합합니다.

사이드 프로젝트

세계에서 가장 빠른 (미완성) 이더리움 구현을 작성했습니다

지난달에 언급했듯이 Zig와 인터프리터, 이더리움에 대해 더 배우는 재미있는 방법을 찾았습니다. 바로 Zig로 이더리움 바이트코드 인터프리터를 작성하는 것입니다.

Zig는 개발자에게 성능에 대한 높은 수준의 제어권을 제공하므로, 인터프리터 작업 초기에 한 일 중 하나는 내 구현과 공식 Go 구현을 비교하는 벤치마크를 지속적 통합(CI)에 설정하는 것이었습니다.

한동안 제 Zig 버전은 Go 버전보다 성능이 약간 뒤처졌습니다. 그러다 벤치마킹 스크립트를 리팩터링하자 성능이 알 수 없이 급락했습니다.

Zig 포럼인 Ziggit에 도움을 요청했고, 벤치마킹 스크립트와 Zig 코드 모두에 버그가 있다는 걸 알게 됐습니다. 그 두 가지 단순한 버그를 고치자 제 Zig 버전이 Go 버전을 단숨에 앞질렀습니다.

공정하게 말하면 제 버전은 이더리움의 약 3%만 구현했으니 불공정한 이점이 있는 셈이지만, 여전히 재미있는 프로젝트입니다.

마무리

무엇을 했나?

• TinyPilot Pro 2.6.3을 출시했습니다.
• TinyPilot 릴리스 프로세스에서 문서화되지 않은 단계들을 파악하고 대부분을 문서화했습니다.

배운 점

• 작업에 팀 간 협업이 필요할 때 위임이 더 어려워집니다.
  • 일부 결정은 궁극적으로 제품 책임자가 내려야 하지만, 팀은 결정에 필요한 정보를 모으는 과정을 결정 자체와 분리되도록 프로세스를 조정할 수 있습니다.

다음 달 목표

• TinyPilot 릴리스 문서의 빈틈을 메우기.
• 2023년 세금 신고 완료하기.