한 줄 요약

일에 천천히 복귀하는 중.

하이라이트

• 초보 아빠로서 시간 균형을 맞추는 게 점점 수월해지고 있다.
• 블로그 글 두 개가 반응이 없다고 속상해했는데, 이후에 잘 됐다.
• 소프트웨어 개발에 스택드 디프 워크플로를 실험해 봤는데, 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” 섹션에 간단하게 정리하는 식으로 쓴다.

“Nix로 PDF 파서 퍼즈 테스트하기”

이 글에 들인 시간에 대해서는 마음이 복잡하다.

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

LLM 시대에 소프트웨어 튜토리얼을 쓰는 건 의욕을 꺾기도 한다. 몇 년 전까지만 해도 튜토리얼은 웹 검색을 통해 나중에 발견되면서 장기적인 보상이 있었다. 요즘은 틈새 튜토리얼을 쓰면 LLM이 내가 쓴 내용을 그대로 가져가고, 독자는 그 출처가 나라는 사실조차 모른다.

“첫 엑시트에서 얻은 교훈”

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

• 사업 매각의 아주 세부적인 내용을 다루는데, 내 독자의 99%는 그럴 계획이 없다.
  • 이전에 매각에 대해 쓴 글은 반응이 좋았지만, 그건 이야기 형식이라 직접 매각에 관심이 없는 독자도 그 과정을 즐기며 읽을 수 있었다.
• 글이 엄청 길다.
  • 나는 보통 글 하나당 읽기 시간 10분 정도를 목표로 하는데, 이 글은 예상 읽기 시간이 33분이다.
• 어느 정도 가능성이 있는 소셜 미디어 채널은 Hacker News가 유일했다.

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

아직 Hacker News에서 관심을 받을 가능성은 충분히 있다고 생각하지만, 설령 완전히 실패하더라도 글을 쓴 것 자체에는 만족한다. 인수를 스스로 정리하는 데 도움이 됐고, 나중에 다른 사업을 매각하게 되면 유용한 참고 자료가 될 것이다. 인수를 경험했거나 고민 중인 창업가들로부터 긍정적인 피드백도 받았다.

그러다 갑자기 그 글들이 주목을 받기 시작했다

위 내용을 쓰고 나서 Hackaday에서 내 Nix 퍼징 튜토리얼을 다뤘다는 사실을 알게 됐는데, 보람을 느꼈다.

그리고 “첫 엑시트에서 얻은 교훈”이 실패했다고 쓴 바로 다음 날, 한 독자가 그 글을 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라는 새로운 소스 컨트롤 시스템에 대한 이야기가 점점 더 많이 들린다. 구글 내 표준이 될 가능성이 있는 시스템이다.

몇 달 전에는 써볼까 하다가 “뭐, git도 내가 필요한 건 다 해주는데, 왜 또 새로운 걸 쫓아다니지?”라고 생각했다. 그런데 이번에 git rebase를 겪고 나니, 그동안 답답한 git 경험을 너무 당연하게 받아들였다는 걸 깨달았다.

Steve Klabnik의 튜토리얼을 훑어보니, 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는 스토리가 충분히 몰입되어 집중하게 되는 몇 안 되는 게임 중 하나다. 그리고 키아누 리브스가 주요 역할로 출연할 정도로 성우 연기에 그렇게 많은 투자를 했다는 점도 멋지다.

Detroiters (TV 시리즈)

이 시리즈 이름은 들어봤지만, 제목 때문에 늘 보기를 망설였다. 등장인물의 가장 큰 특징이 디트로이트에 산다는 것인 시리즈라니? 지루하게 들렸다.

그러다 이 시리즈의 이 클립을 보고 훌륭한 사람들이 출연한다는 걸 알게 됐고, 톤은 I Think You Should Leave를 시트콤 형식으로 조금 더 현실적으로 만든 느낌이었다. 시즌 1을 막 다 봤는데, 정말 좋았다.

마무리

무엇을 해냈나?

• 정식 글 두 편 발행:
  • “첫 엑시트에서 얻은 교훈”
  • “Nix로 PDF 파서 퍼즈 테스트하기”
• 짧은 노트 다섯 편 발행:
  • “정적 블로그에서 타임스탬프 삭제하기”
  • “매사추세츠 주민은 스팸 메일로 온라인 판매자를 고소할 수 있다”
  • “Nemotron을 활용한 실패한 실험”
  • “netconsd를 퍼즈하기 위한 Nix 워크플로 만들기”
  • “Charles Marohn의 ‘Escaping the Housing Trap’에서 얻은 인사이트”
• ScreenJournal에 TV 시리즈 리뷰 기능 추가

배운 점

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

다음 달 목표

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