한 줄 요약

일에 서서히 복귀하고 있다.

하이라이트

• 초보 아빠로서 시간 균형을 맞추는 게 한결 수월해졌다.
• 블로그 글 두 개가 반응이 없어 풀이 죽었는데, 나중에 반응이 좋았다.
• 소프트웨어 개발에 스택드 디프(stacked diff) 워크플로를 실험해 봤는데, git의 단점을 제외하면 마음에 들었다.

목표 성적표

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

가족과 시간 보내기

• 결과: 아내와 아들과 즐거운 시간을 보냈다.
• 성적: A

오랫동안 일하지 않는 것처럼 느껴질 때조차, 그건 내 선택이며 여전히 내 시간을 대부분 통제하고 있다는 점을 스스로에게 상기하는 것이 도움이 됐다.

여전히 일과 가족 시간 사이에서 적절한 균형을 찾아가고 있지만, 점점 나아지고 있다.

Nix를 이용한 퍼즈 테스팅 튜토리얼 발행하기

• 결과: 마침내 글을 완성했지만, 반응은 별로 없었다.
• 성적: A

일에 서서히 복귀하기

이 회고를 쓰려고 앉았을 때, 일할 시간이 없다는 불안감이 너무나 먼 기억처럼 느껴졌다. 아마 두 달 전쯤이었겠지 생각했는데, 확인해 보니 바로 직전 회고에서 한 이야기여서 놀랐다.

다행히 이제는 가족과의 시간 균형에 대해 훨씬 마음이 편해졌다. 가족과 많은 시간을 보내면서도 그 어느 때보다 많은 글을 발행했다.

여기에 영향을 준 몇 가지 요인은 다음과 같다:

아들이 밤에 더 잘 잔다

처음에는 밤에 세네 번 깨서 깰 때마다 60~90분씩 먹느라 시간을 보냈는데, 이제는 밤에 두세 번만 깨고 15~60분 안에 다시 잠든다.

어젯밤에는 통잠(7시간 45분)을 잤는데, 정말 신나는 일이었다.

가족의 도움을 더 받고 있다

아들이 좀 더 크면서, 우리가 없어도 가족이 와서 아이를 돌봐주는 것이 한결 편해졌다. 이제는 주당 약 다섯 시간 정도 도움을 받고 있고, 가족들이 더 도와줄 의향이 있어 앞으로도 계속 늘어날 것 같다.

아들이 낮잠 자는 동안 일할 수 있다

아들은 누군가 안고 있거나 가슴에 안는 아기띠에 있을 때 더 오래 잔다. 그래서 나는 보통 하루에 한두 시간에서 세 시간 정도 아들을 가슴에 안은 채로 일한다. 몇 시간 동안 이어지는 시간이라 아내에게도 혼자만의 시간을 주는 셈이 된다.

보장된 업무 시간이 있다

나는 불규칙한 일정으로는 일하기가 어렵다. 아내가 아들을 돌보거나 아들이 내 가슴에서 자고 있는 시간이 많더라도, 언제든 나를 필요로 할 수 있다는 생각 때문에 집중하기가 더 어렵다.

아내가 매일 90분 동안은 온전히 집중할 수 있는 시간을 보장해 주기로 했는데, 집중하는 데 큰 도움이 됐다. 매일 그런 시간이 있다는 걸 아니까, 고도의 집중이 필요한 작업은 그 시간에 몰아서 할 수 있다.

블로그 글에 너무 많은 투자를 하고 있는 걸까?

예전에는 어려운 걸 하나 배울 때마다 꼭 블로그 글로 정리해 설명해야 한다는 나쁜 습관이 있었다.

독자가 아주 적거나 도달할 방법이 없는 글이라도 모든 글을 최대한 완벽하게 다듬으려고 했다. 이전 사례로는 “Hiring Content Writers: A Guide for Small Businesses”(독자는 있지만 도달할 방법이 마땅치 않다)와 “Retrofitting Apps for Cloud Storage with Zero Code Changes”(매우 틈새 주제라 내 특이한 사용 사례 외에는 흥미를 끌기 어렵다)가 있다.

그 글들을 고맙게 읽어준 독자들도 있었지만, 기회비용도 고려해야 한다. 그 글을 쓰는 데 쓴 시간에 더 많은 독자에게 도달하거나 전체적으로 더 큰 가치를 줄 수 있는 다른 글을 쓸 수 있지 않았을까?

이후로는 글을 더 전략적으로 쓰게 됐다. 일정 규모 이상의 독자에게 도달하기 어렵다고 판단되면 아예 쓰지 않거나, “Notes” 섹션에 간단하게만 정리한다.

“Using Nix to Fuzz Test a PDF Parser”

이 글에 얼마나 많은 시간을 투자했는지를 두고 마음이 복잡하다.

글을 쓰면서 Nix와 퍼즈 테스팅에 대해 많이 배웠지만, 생각보다 훨씬 오래 걸렸다. 처음에는 “몇 시간 만에 간단히 정리하면 되겠지”라고 생각했는데, 결국 20시간 넘게 썼다.

LLM 시대에 소프트웨어 튜토리얼을 쓰는 건 의욕을 꺾는 일이기도 하다. 몇 년 전까지만 해도 튜토리얼은 사람들이 나중에 웹 검색을 통해 찾아오면서 장기적인 보상이 있었다. 요즘은 틈새 튜토리얼을 써 봐야 LLM이 내용을 가져가고 독자는 그게 내 글인지조차 모른다.

“Lessons from my First Exit”

이 글은 처음부터 불리한 요소가 몇 가지 있어 위험 부담이 크다는 걸 알고 있었다:

• 사업 매각의 세세한 내용을 다루는데, 독자의 99%는 그런 계획이 없다.
  • 이전에 매각에 대해 쓴 글은 반응이 좋았지만, 그건 이야기 형식이라 직접 매각에 관심이 없는 독자도 그 과정을 즐기며 읽을 수 있었다.
• 글이 엄청 길다.
  • 나는 보통 글 하나를 10분 분량으로 쓰려고 하는데, 이 글은 예상 읽기 시간이 33분이다.
• 그나마 가능성이 있는 소셜 미디어 채널은 Hacker News뿐이었다.

Hacker News에 직접 올렸지만 전혀 첫 페이지에 오르지 못했다.

여전히 Hacker News에서 반응을 얻을 가능성은 있다고 본다. 하지만 완전히 실패하더라도 글을 쓴 것에 만족한다. 인수를 스스로 정리하는 데 도움이 됐고, 나중에 다른 사업을 매각하게 되면 유용한 참고 자료가 될 것이다. 인수를 경험했거나 고려 중인 창업자들에게서 긍정적인 피드백도 받았다.

그리고 갑자기, 그 글들이 반응을 얻었다

위 내용을 쓰고 나서 Hackaday가 내 Nix 퍼징 튜토리얼을 다뤘다는 걸 알게 됐는데, 꽤 뿌듯했다.

그리고 “Lessons from my First Exit”가 실패했다고 쓴 바로 다음 날, 한 독자가 다시 Hacker News에 글을 올렸고, 2위까지 올랐다.

그래도 내 초기 분석은 맞았다고 생각한다. 퍼징 글에는 과도하게 투자했고, TinyPilot 매각 글에는 적절한 만큼 투자했다.

스택드 디프로 대규모 기능 구현하기

지난 몇 주간 취미로 하는 프로그래밍 시간 대부분을 TV와 영화 리뷰 웹 앱인 ScreenJournal에 썼다. Letterboxd나 Goodreads 같은 서비스인데, 리뷰는 친구들에게만 보이고 코드는 오픈소스라는 게 특징이다.

처음부터 ScreenJournal이 영화와 TV 쇼를 모두 지원하길 바랐지만, 영화가 더 단순해서 먼저 구현했다. TV 쇼 지원까지 고려해 코드를 일반화하지도 않았다. 실제로 구현하게 될지 몰랐으니, 일단 있는 기능에 최적화하고 싶었다.

10월에 TV 쇼 리뷰 기능을 추가하면서, 리뷰가 항상 영화라는 전제하에 작성된 코드의 많은 부분을 고쳐야 했다.

전체 변경은 결국 2천 줄 규모가 됐는데, 단일 체인지리스트로는 이해하기가 꽤 부담스럽다. 여기서 “체인지리스트”라는 용어를 쓰지만, GitHub로 치면 풀 리퀘스트, GitLab으로 치면 머지 리퀘스트 같은 걸 말한다.

예전에는 이런 큰 변경을 다룰 때 기능이 완성될 때까지 깨지거나 미완성인 상태의 피처 브랜치를 유지했다. 피처 브랜치에 직접 변경을 하거나, 그 브랜치에서 다시 하위 작업을 위한 브랜치를 만들고 완료되면 합치는 식이었다.

이 방식의 문제는 피처 브랜치가 너무 커서 이해할 수 없는 거대한 변경 덩어리가 된다는 점이다. What Got Done을 Firestore에서 SQLite로 마이그레이션했을 때가 그 예인데, 그 변경 안에는 하위 단계가 많았지만 모든 것이 뒤섞여 있어 단계별로 살펴볼 수 없었다.

그래서 이번 ScreenJournal 변경에서는 다른 방식을 시도했다. 크고 지저분한 피처 브랜치를 유지하는 대신, 스택드 디프를 사용했다.

나는 TV 쇼 리뷰 흐름의 각 페이지마다 체인지리스트를 만들어 작업을 나눴다.

리뷰를 남기는 첫 단계는 리뷰할 대상을 검색하는 것이다. 이전에는 영화만 가능했기 때문에, TV 쇼 지원을 위한 첫 단계는 사용자가 영화와 TV 쇼 중 하나를 선택할 수 있는 라디오 버튼을 추가하는 것이었다:

다음으로 필요했던 건 사용자가 TV 쇼의 시즌을 선택하는 방법이었다. 영화만 있을 때는 필요 없던 기능이었기 때문에, 이것도 별도의 변경으로 만들었다.

이런 식으로 흐름의 각 단계를 새로운 브랜치이자 별도의 풀 리퀘스트로 계속 진행해 나갔다.

이 방식의 개발에서 얻은 몇 가지 교훈은 다음과 같다.

좋았던 점: 스택드 디프가 더 동기부여가 된다

스택드 디프의 좋은 점은 기능의 각 하위 작업이 별도의 체인지리스트가 된다는 것이다.

변경을 더 작은 조각으로 나누니 성취감과 진척도가 더 잘 느껴졌다. 하나의 하위 작업을 끝내면 기능이 30%에서 35%로 진행되는 커다랗고 지저분한 브랜치 하나를 다루는 것보다, 체인지리스트 하나를 끝내고 100% 완료됐다는 걸 아는 게 훨씬 만족스럽다.

나빴던 점: 변경 이력을 계속 지워야 한다

스택드 디프 워크플로에서 가장 마음에 들지 않는 점은 결국 소스 히스토리를 지우게 된다는 것으로, 이는 소스 컨트롤의 큰 장점을 무력화한다.

스택의 더 앞부분에서 변경했어야 했다는 걸 깨달을 때마다 git rebase를 해야 하는데, 이는 히스토리를 다시 쓴다. 즉 GitHub에 강제 푸시를 해야 하고, 그 결과 체인지리스트에 보기 흉한 force-pushed 항목들이 가득 쌓인다:

어떤 사람들은 각 커밋이 마치 살인 사건의 증거라도 되는 양 모든 변경이 발생한 그대로 보존되길 바란다. 나는 그 정도까지는 바라지 않지만, 실수했을 때를 대비해 합리적인 실행 취소 히스토리는 남기고 싶다. 강제 푸시가 원격의 실행 취소 히스토리를 덮어쓰고 로컬에서 복잡한 복구 작업을 해야 한다는 점이 마음에 들지 않는다.

좋았던 점: --update-refs가 스택드 디프 리베이스를 단순화한다

스택드 디프 워크플로를 실험하다가 git의 --update-refs 플래그를 알게 됐다. 이 플래그를 사용하면 여러 브랜치를 한 번에 리베이스할 수 있다.

이 덕분에 스택드 디프가 훨씬 수월해졌다. 이전에는 각 브랜치를 순서대로 리베이스했는데, 스택에 브랜치가 네 개가 넘어가자 고통스러울 정도로 지루해졌다.

나빴던 점: --update-refs 이후 푸시는 여전히 어렵다

A, B, C 브랜치가 있고 이들을 한 번에 리베이스하면, git 출력은 이렇게 보인다:

$ git rebase master --update-refs
Successfully rebased and updated refs/heads/C.
Updated the following refs with --update-refs:
        refs/heads/A
        refs/heads/B

--update-refs가 리베이스 자체는 단순화하지만, “자, 이제 방금 리베이스한 브랜치들을 푸시해” 같은 명령은 없다. 대신 git 출력을 텍스트 에디터에 복사해 브랜치 이름만 추려낸 뒤 git push origin A B C -f 같은 명령으로 다시 조합해야 한다. 흐름을 항상 끊는 성가신 과정이다.

나빴던 점: 자주 예상치 못한 git 상태에 빠진다

올바른 방식으로 리베이스하고 있다고 생각했는데도 자주 혼란스러운 상태에 빠졌다. 리베이스를 하고 나면 이미 해결한 충돌을 다시 해결하라고 하는 식이었다.

커밋을 스쿼시하고 다시 리베이스하는 식으로 우회했지만, 이 역시 히스토리를 다시 써서 실수를 되돌리기 더 어렵게 만든다. 코드를 작성하는 대신 git에 어떻게 제대로 사과해야 할지 고민하느라 정신적 에너지를 낭비하는 것도 짜증 났다.

jujutsu를 한번 써봐야 할지도 모르겠다

jujutsu라는 새로운 소스 컨트롤 시스템에 대한 이야기가 점점 더 많이 들린다. Google 내에서 표준이 될 예정이라고 한다.

몇 달 전에는 한번 써볼까 하다가 “뭐, git도 필요한 건 다 해주는데 굳이 새로운 걸 쫓아다닐 필요가 있을까?”라고 생각했다. 하지만 이번에 git rebase를 겪고 나니, 그동안 수많은 답답한 git 경험을 당연한 것으로 받아들여 왔다는 걸 깨달았다.

Steve Kalabnik의 튜토리얼을 훑어보니, jujutsu는 git보다 스택드 디프와 다중 리베이스를 더 잘 지원한다고 한다.

추천

“Why I still blog after 15 years” by Jonas Hietala

블로그에 관한 이 글에 많이 공감했다. Jonas의 사이트를 더 둘러보면서 “아, 이 사람은 스웨덴 버전의 나구나”라는 생각이 들었다. 내 글을 좋아한다면 그의 글도 좋아할 것이다.

“Notes on Ukraine” by Matt Lakeman

지난주에 Matt의 블로그를 발견했는데, 그 이후로 매일 “이 사람은 대체 누구지?”라는 생각을 한다.

Matt는 그리 유명하지 않은 여행지를 보통 열흘 정도 여행한 뒤 그 나라에 대한 블로그 글을 올린다. 하지만 엄마에게 보내는 엽서 같은 글이 아니다. 그 나라 역사에 대한 수 시간의 공부와 현지인들과의 대화를 바탕으로 한 중편 소설 분량의 글이다.

또 Matt가 인터넷 다른 곳에서 dormin111이라는 아이디로 오랫동안 글을 써 왔다는 것도 알게 됐다. 예를 들어 영화 The Disaster Artist에 대한 이 상세한 분석 같은 글이다.

그의 모든 작업에서 가장 놀라운 점은 아무런 속셈이 없어 보인다는 것이다. 보통 누군가 글쓰기에 그토록 많은 투자를 하면 그게 어떻게 이득이 되는지 분명히 보인다. Substack이나 유료 강의로 돈을 벌고 무료 글은 미끼 상품인 식이다. 하지만 Lakeman의 글에서는 어떤 속셈이나 수익 동기도 찾을 수 없다. 그는 그냥 깊이 생각하고 그 생각을 나누는 것 자체를 좋아하는 것 같다.

어쨌든 이 우크라이나 글로 돌아오면, 나는 그가 전쟁 전에 방문한 줄 알았는데 알고 보니 전쟁이 시작된 지 두 달 뒤에 방문해서 전선에서 몇 마일 떨어진 곳에서 군인과 민간인을 인터뷰했다고 한다. 직업 기자는 아니지만 우크라이나에서 다양한 실제 사람들을 인터뷰한 사람의 전쟁 보도를 보는 게 흥미로웠다. 전통 미디어 채널에서 본 어떤 것보다 더 진솔하고 개인적인 시각으로 상황이 느껴졌다.

Cyberpunk 2077 (비디오 게임)

나는 비디오 게임을 많이 하지 않는다. 1년에 새 게임 하나를 사서 질릴 때까지 하는데, 보통 며칠에 걸쳐 5~25시간 정도 한다. 이 게임은 25시간 정도 했는데도 아직 재미있게 하고 있다.

게임의 깊이가 놀랍다. 25시간을 했는데도 게임의 5% 정도밖에 탐험하지 못한 것 같아, 현대 게임의 세계가 이렇게 광활하다는 사실에 놀란다.

나는 보통 비디오 게임 스토리에 관심이 없고 지루한 설명을 앉아서 들어야 하면 짜증이 나는데, Cyberpunk는 이야기가 충분히 매력적이어서 집중하게 되는 몇 안 되는 게임 중 하나다. 그리고 성우 연기에 투자를 많이 해서 Keanu Reeves가 중요한 역할을 맡았다는 점도 멋지다.

Detroiters (TV 프로그램)

이 쇼에 대해 들어본 적은 있었지만, 이름 때문에 항상 시청을 망설였다. 등장인물의 특징이 디트로이트에 산다는 것뿐인 쇼라니? 지루할 것 같았다.

그러다 쇼의 이 클립을 보고 멋진 사람들이 출연한다는 걸 알게 됐고, 분위기는 I Think You Should Leave를 시트콤 형식으로 조금 더 현실감 있게 만든 느낌이었다. 시즌 1을 막 끝냈는데 정말 좋았다.

마무리

무엇을 했나?

• 장문 글 두 편 발행:
  • “Lessons from my First Exit”
  • “Using Nix to Fuzz Test a PDF Parser”
• 짧은 노트 다섯 편 발행:
  • “Delete the Timestamps from your Static Blog”
  • “Massachusetts Residents Can Sue Online Merchants for Spam”
  • “An Unsuccessful Experiment with Nemotron”
  • “Creating a Nix Workflow to Fuzz netconsd”
  • “Takeaways from Charles Marohn’s ‘Escaping the Housing Trap’”
• ScreenJournal에 TV 쇼 리뷰 지원 추가

배운 점

• 스택드 디프는 대규모 변경에 좋은 워크플로지만, git은 이에 대한 지원이 부족하다.
• 블로그 글에 대한 투자는 기대 수익에 맞춰야 한다.
  • 배운 모든 것을 기록하는 걸 좋아하지만, 블로그가 재정적으로 지속 가능하려면 장문 글 중 상당수가 내 수익형 프로젝트에 관심을 가질 만한 독자를 끌어와야 한다.

다음 달 목표

• 가족과 시간 보내기.
• Refactoring English의 한 챕터 완성 및 발행하기.