한 줄 요약

미루는 습관을 그만둬야 한다.

하이라이트

• 책 집필을 미루는 온갖 방법을 찾아냈다.
• 오픈소스 프로젝트를 퍼즈 테스트하며 재미있게 보냈다.
• 소프트웨어 개발용 고사양 데스크톱 컴퓨터의 부품을 골랐다.

목표 평가

매달 초에 달성하고 싶은 목표를 정한다. 목표별로 얼마나 해냈는지는 다음과 같다.

가족과 함께 시간 보내기

• 결과: 가족과 함께하는 시간을 계속 즐겼다.
• 평점: A

직접 관리하는 육아휴직 기간 동안, 가족과 함께하는 시간과 개인 및 업무 프로젝트에 쓰는 시간 사이의 균형을 계속 즐기고 있다.

Refactoring English 한 챕터 완성 및 공개

• 결과: 챕터 작업은 했지만 아무것도 공개하지 못했다.
• 평점: D

목표를 세울 때 이 과제를 너무 쉽게 봤다. 몇 년 전에 한 챕터를 시작해 두고 간간이 손을 대 왔는데, 기억 속에는 이미 80%쯤 완성된 것 같았다. 하지만 이번에 다시 열어 보니 20% 정도 완성된 느낌이었다.

챕터를 60% 정도까지 끌어올리긴 했지만, 할 수 있는 만큼 집중하지는 못했다.

책 집필 미루기를 그만둬야 한다

혹시 새 폰트가 필요한 건 아닐까

책의 첫 챕터 작업을 시작했는데, 사이트의 밋밋한 디자인 때문에 계속 집중이 흐트러졌다.

책 웹사이트는 내가 만든 단순한 디자인 테마를 쓰고 있다. 그냥 Bootstrap 기본 CSS에 내가 추가한 커스텀 스타일을 조금 얹은 수준이다. 딱히 무엇이 문제인지 꼬집을 수는 없었지만, 전체적인 느낌이 어딘가 어색했다.

마음에 드는 블로그와 웹사이트들을 찾아보며 그곳에서 쓰는 폰트를 내 사이트에 적용해 보기 시작했다.

• Jonas Hietala는 Concourse와 Century Supra를 사용하는데, Matthew Butterick이 디자인한 유료 폰트다.
• Xe Iaso는 Iosevka Aile Iaso를 사용하는데, 알고 보니 그녀가 직접 디자인한 폰트였다.
• fasterthanlime은 Atkinson Hyperlegible을 사용하는데, 시각 장애가 있는 사람에게 읽기 좋다고 해서 Braille Institute에서 무료로 배포하는 폰트다.

책 웹사이트에 가장 잘 어울린 폰트는 Concourse였고, 이를 계기로 Matthew Butterick의 폰트들을 모두 살펴보게 됐다. 처음으로 Google Fonts의 무료 폰트 대신 직접 폰트를 구매했다. 제목에는 Concourse를, 본문에는 Heliotrope를 썼다.

좋은 폰트가 얼마나 큰 차이를 만드는지 보고 놀랐다. 다른 디자인은 하나도 손대지 않았는데도 사이트가 3배는 더 보기 좋아진 느낌이었다. 마치 편법을 쓴 기분이었다.

혹시 책 표지가 필요한 건 아닐까

멋진 새 폰트를 설치하고 나니 이번엔 책 표지가 신경 쓰였다. 어차피 출간 전에 표지를 외주할 예정이니 지금 미리 해두는 것도 나쁘지 않겠다 싶었다. 멋진 표지가 있으면 더 많은 사람이 관심을 가질 테니까. 그래서 표지 디자인 시안을 작성해 디자이너에게 의뢰했다.

이전 아이디어로 돌아가야 하나

며칠 뒤, 한 독자에게서 Hit the Front Page of Hacker News의 미완성 레슨을 구매할 수 있냐는 메일을 받았다. 나는 아직 공개하지 않은 두 개의 새 레슨과 기존 강의 링크를 보내줬다. 독자는 자료가 마음에 드는 듯했다. 문득 Refactoring English를 잠시 멈추고 Hit the Front Page of Hacker News 리부트를 마무리해야 하나 하는 생각이 들었다.

이제는 집중해야 할 때

이쯤 되니 책을 쓰는 것 말고는 온갖 활동을 다 찾아 하고 있다는 걸 깨달았다.

책을 완성하는 일이 너무 멀게 느껴지니 딴짓을 하기 쉽다. 게다가 글쓰기에 관한 책이다 보니 글 하나하나를 완벽하게 써야 할 것 같아 문장 다듬는 데 매번 발목이 잡힌다.

첫 샘플 챕터를 공개하고 독자 피드백을 받아보면 책에 대한 감이 더 잡힐 것 같다. 그때까지는 그냥 밀고 나가기로 했다.

퍼징은 정말 재미있다

앞선 이야기에도 불구하고, 지난달 퍼즈 테스트를 하며 정말 즐거운 시간을 보냈다.

11월 대부분은 생후 3개월 된 아기를 재우고 첫 수유 때까지 기다리는 동안 혼자만의 시간이 몇 시간 있었다. 아기가 잠든 뒤 1~4시간 사이에 깨어날 수 있다. 그 시간에는 하루 종일 쌓인 피로에다 언제든 방해받을 수 있어 프로그래밍에 집중하기 어렵지만, 퍼즈 테스트를 하기에는 완벽한 시간이다. 퍼즈 테스트는 세팅 과정에서 시행착오가 대부분이라 그리 높은 집중력을 요구하지 않는다.

openc2e 퍼징하기

Nix는 퍼즈 테스트 워크플로를 쉽게 만들 수 있게 해주는데, 아직 세상이 그 진가를 제대로 모르는 것 같다.

어느 날 밤, Facebook이 공개한 무작위 오픈소스 유틸리티를 퍼징한 블로그 글을 읽었다. 그래서 Nix로 그 퍼징 워크플로를 재현하는 데 한 시간 정도 썼다.

며칠 뒤 밤에는 두어 시간 정도 들여 퍼저를 작성해 openc2e를 퍼징했다. openc2e는 Creatures 게임 시리즈의 오픈소스 재구현이다.

1996년에 나온 원작 Creatures 게임에는 커스텀 스크립팅 언어와 그에 대응하는 가상 머신이 포함돼 있었다. 이 언어는 Creatures Agent Object Script(CAOS)라고 하며, 플레이어가 게임용 커스텀 애드온을 만들 수 있게 해준다.

CAOS는 어셈블리어와 비슷한 저수준 언어다.

SETS VA00 "he"
ADDS VA00 "llo"
DBG: ASRT VA00 eq "hello"

열성 팬들이 openc2e 안에 CAOS 인터프리터를 재구현해 뒀는데, 아무도 퍼징해 본 적이 없을 거라고 생각했다. 하지만 애드온을 설치하면 신뢰할 수 없는 서드파티 코드를 파싱하므로 퍼징할 가치가 충분하다.

CAOS 언어의 렉서부터 퍼징하기 시작했고, 곧바로 수많은 크래시를 발견했다.

크래시 중 하나는 닫히지 않은 큰따옴표 하나 때문이었는데, 이 코드를 아무도 퍼징하지 않았다는 내 예상을 확인시켜 줬다.

* The following line crashes openc2e's CAOS lexer.
"

가장 단순한 크래시를 수정하고 수정 사항을 보여주는 유닛 테스트와 함께 풀 리퀘스트를 올렸지만, 프로젝트가 반쯤 방치된 상태라 모든 수정이 반영되기까지는 시간이 좀 걸릴 것 같다. 내 PR이 꽤 괜찮다고 생각해서 언젠가 리뷰할 시간을 내주길 바란다.

퍼징은 하고 싶은 대로 할 수 있다

Nix로 퍼징할 때 가장 재미있는 점 중 하나는 다른 사람에게 폐를 끼치지 않고도 내부 프로젝트를 마음껏 만질 수 있다는 것이다.

openc2e를 퍼징하려 할 때, 링크하고 싶은 코드가 링크에 적합하지 않은 오브젝트로 컴파일되어 있다는 걸 깨달았다. 어떻게 링크할지 고민하다가 그냥 내 저장소에서 Makefile을 패치해서 원하는 대로 바꿀 수 있다는 걸 깨달았다.

보통 오픈소스 프로젝트에 기여할 때 라이브러리를 private에서 public으로 바꾸는 식의 큰 변경을 하고 싶으면, 왜 private였는지 이유를 깊이 파악한 뒤 왜 공개해야 하는지 메인테이너를 설득하는 데 많은 시간을 써야 한다. 하지만 퍼징은 나만의 샌드박스에서 하는 일이라 원하는 대로 이것저것 만져볼 수 있다.

새 개발용 데스크톱 조립하기

소프트웨어 개발 방식을 대대적으로 바꾸려고 한다. 다시 평범한 사람처럼 코드를 작성할 예정이다.

약 10년 전부터 Linux에서 개발하는 게 더 편하다고 느꼈지만, 메인 OS로는 여전히 Windows를 선호했다. 그래서 Windows 데스크톱의 VirtualBox에서 Linux VM을 돌리는 방식으로 해결했다. 의존성 충돌을 피하려고 프로젝트별로 VM을 나눠 썼다(예: Python 2 프로젝트가 Python 3 프로젝트를 망치는 일을 방지).

2017년에는 Windows 시스템을 재부팅할 때마다 모든 VM을 다시 시작해야 하는 게 귀찮아져 첫 홈랩 VM 서버를 만들었다.

2019년쯤에는 VS Code와 Remote SSH로 모든 개발을 했는데, 대부분 잘 동작하지만 가끔 특이한 문제 때문에 일이 꼬이기도 했다.

그러다 지난 1년 사이에 두 가지 변화가 생겼다.

1. 내가 원하는 소프트웨어가 사실상 모두 Linux에서 구할 수 있다는 걸 깨달았다. Microsoft의 점점 더 심해지는 텔레메트리와 Windows 광고에 질려 Linux로 갈아탈 준비가 됐다.
2. Nix의 프로젝트별 환경을 알게 된 이후로는 프로젝트별 VM을 쓰지 않게 됐고, Nix를 설치한 단일 Debian VM에서 모든 개발을 하고 있다.

이 두 가지 변화 덕분에 더 이상 VM 서버나 Windows 데스크톱이 필요 없어졌다. 지난 몇 달간 Framework 13 노트북에서 NixOS를 만족스럽게 쓰고 있어, NixOS를 쓰는 단일 데스크톱으로 통합할 예정이다.

두 대를 한 대로 줄이니 경제적으로 책임 있는 선택을 하는 셈이다. 이렇게 생각하며 새 시스템에 과감히 돈을 썼다.

내 작업에서 병목은 대부분 디스크라서, 다소 사치스럽게 느껴졌지만 최고 사양으로 골랐다. 대부분의 데이터는 스토리지 서버에 있으니 OS용 디스크 하나만 있으면 된다.

CPU는 빠르지만 최상위 모델은 아니다. CPU를 살 때는 벤치마크를 보고 최상위 옵션의 80~90% 성능을 내면서 가격은 절반 이하인 제품을 고르려고 한다.

가장 큰 사치는 모니터다. 말도 안 되게 큰 49인치 울트라와이드 OLED다.

11살 때 아빠가 CompUSA에서 돌아와 당시로서는 가장 큰 모니터 중 하나가 담긴 상자를 건네주던 순간의 기쁨이 아직도 생생하다. 그 모니터는 아마 17인치 CRT였을 것이다. “네가 모니터를 보는 시간이 얼마나 많은데, 좋은 걸로 투자하는 게 낫지.”라고 아빠는 설명했다. 참고로 부모님 두 분 다 프로그래머셔서 나는 어릴 때부터 대부분의 자유 시간을 컴퓨터 앞에서 보냈다.

그 이후로 나는 아빠의 논리를 근거로 고급 모니터 구매를 정당화해 왔고, 그 선택은 늘 만족스러웠다. 나는 1년에 2,500시간을 컴퓨터 앞에서 보낸다. 시간당 비용으로 따지면 고급 모니터 가격은 거의 무시할 수준이다.

게다가 5120x1440 해상도로 Hacker News를 경험하고 나니 이제 예전으로 돌아갈 수가 없다.

울트라와이드 모니터 사용법 익히기

새 컴퓨터의 모든 부품이 아직 도착하진 않았지만, 새 모니터는 먼저 설치했다. 데스크톱에서 창을 관리할 새로운 전략이 필요하다는 걸 금방 깨달았다.

기존 모니터는 34인치였고, 주로 Win+Left / Win+Right로 창을 화면 절반 크기로 도킹해 썼다. 새 모니터는 너비가 5120px라 한 번에 두 개 이상의 창을 도킹하고 싶었다.

Komorebi를 써봤지만 너무 복잡했다. 그러다 Fancy Zones를 찾았는데, 정확히 내가 원하던 기능이었다. GUI로 영역을 정의한 뒤 단축키나 마우스로 창을 해당 영역에 도킹할 수 있다.

내가 설정한 네 개의 영역은 다음과 같다.

1. 1000x1440px - 주 VS Code 창
2. 1000x1440px - 보조 VS Code 창
3. 1560x1440px - 주 웹 브라우저 창
4. 1560x1440px - 보조 웹 브라우저 창

보통은 웹 브라우저와 VS Code 창만 도킹한다. 그 외의 창들은 잠깐 쓰는 플로팅 창으로 띄운다.

VS Code 너비를 1000px로 제한하는 게 도움이 된다. 나는 편집 창만 열어두는 걸 선호하는데, 화면이 넓으면 파일 탐색기 같은 다른 패널을 열어둔 채 잊어버리기 쉽다. 하지만 1000px에서는 사이드 패널을 가끔 열 수는 있어도 눈에 띄게 공간을 차지해서 곧 닫고 다시 메인 편집 패널에 집중하게 된다.

OLED와 LED의 선명도 차이는 신경 쓰지 않을 줄 알았는데, 확실히 차이가 느껴진다. 블랙이 더 깊어 이미지가 한층 선명하게 느껴진다.

주사율도 신경 쓰지 않을 줄 알았는데, 60Hz와 120Hz의 차이를 확실히 느낀다. 모니터는 240Hz를 지원하지만 Windows에서는 어떤 이유에서인지 그 옵션이 보이지 않아, NixOS로 옮기면 이것저것 만져볼 생각이다.

마무리

무엇을 해냈나?

• 블로그의 템플릿과 CSS 코드를 많이 정리하고 홈페이지를 재구성했다.
• 새 메인 데스크톱 워크스테이션의 부품을 선정하고 주문했다.
• Refactoring English의 디자인 요소를 작업했다.
• NixOS에서 간단한 서비스를 실행하는 방법에 대한 짧은 튜토리얼을 공개했다.

배운 점

• 다른 프로젝트에 커스텀 패치를 적용할 수 있게 해주는 워크플로는 유쾌한 자유를 준다.
  • 변경 사항이 자신에게만 영향을 미치므로 하고 싶은 대로 할 수 있다. 그리고 패치를 쉽게 만드는 워크플로가 있다면 특별한 버전의 코드를 빌드해야 한다는 부담도 느끼지 않는다.

다음 달 목표

• Refactoring English 두 챕터 완성하기.
• 디자이너와 함께 Refactoring English 표지 디자인 완성하기.