한 줄 요약

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

하이라이트

• 책 집필을 미루는 여러 방법을 찾아냈습니다.
• 오픈소스 프로젝트를 퍼즈 테스팅하며 즐거운 시간을 보냈습니다.
• 소프트웨어 개발용 하이엔드 데스크톱의 부품을 골랐습니다.

목표 달성도

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

가족과 함께하는 시간 즐기기

• 결과: 가족과의 시간을 계속 즐겼습니다.
• 평가: 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로 재현하는 데 한 시간을 썼습니다.

며칠 뒤에는 Creatures 게임 시리즈의 오픈소스 재구현인 openc2e용 퍼저를 만드는 데 몇 시간을 썼습니다.

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에서 구동된다는 걸 깨달았습니다. Windows에서 점점 노골적으로 심해지는 Microsoft의 텔레메트리와 광고에 지쳐 Linux로 갈아탈 준비가 되었습니다.
2. Nix에서 프로젝트별 환경을 쓰는 방법을 알게 된 이후로는 프로젝트별 VM을 쓰지 않게 되었고, Nix를 설치한 Debian VM 하나에서 모든 개발을 하고 있습니다.

이 두 변화 덕분에 더 이상 VM 서버나 Windows 데스크톱이 필요 없어졌습니다. 지난 몇 달 동안 Framework 13 노트북에서 NixOS를 즐겁게 써 온 만큼, 이제 NixOS를 탑재한 Linux 데스크톱 한 대로 통합할 계획입니다.

두 대를 한 대로 줄이는 경제적으로 책임 있는 선택을 하고 있다며, 이렇게 새 시스템에 과소비한 걸 합리화했습니다.

제 작업에서는 디스크가 가장 자주 병목이 되기 때문에, 사치스럽다는 느낌이 들지만 최고 사양으로 골랐습니다. 대부분의 데이터는 스토리지 서버에 있어 OS용 디스크 하나만 있으면 됩니다.

CPU는 빠르지만 최상위 라인은 아닙니다. CPU를 고를 때는 벤치마크를 보고 최상위 제품 대비 80~90% 성능을 내면서 가격은 절반 이하인 제품을 고르려고 합니다.

가장 큰 사치는 모니터입니다. 터무니없이 큰 49인치 울트라와이드 OLED입니다.

11살 때 아버지가 CompUSA에서 돌아와 당시 가장 큰 모니터 중 하나가 든 상자를 내밀던 순간의 기쁨이 아직도 생생합니다. 아마 17인치 CRT였을 겁니다. 아버지는 “네가 모니터를 바라보는 시간을 생각하면 좋은 모니터에 투자하는 게 낫지”라고 말씀하셨습니다. 참고로 부모님 두 분 모두 프로그래머셨고, 저는 어릴 때부터 대부분의 여가 시간을 컴퓨터 앞에서 보냈습니다.

그 뒤로 줄곧 아버지의 논리를 근거로 고급 모니터 구매를 정당화해 왔고, 그 선택은 늘 만족스러웠습니다. 1년에 2500시간을 컴퓨터 앞에 앉아 있으니, 시간당으로 따지면 고급 모니터 비용은 거의 들지 않는 셈입니다.

게다가 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 표지 디자인을 완성합니다.