Refactoring English: Month 2

Michael Lynch

Refactoring English: 2개월 차

한 줄 요약

AI 혁명이 한창인데 책을 쓰고 있어도 될까?

하이라이트

  • AI 혁명을 그냥 지켜만 봐도 되는지 의문이 들기 시작했다.
  • 책에 더 많은 시간을 쏟기 전에, 이 책을 살 의향이 있는 독자가 실제로 있는지 스스로 증명해야 한다.
  • RSS가 블로그를 읽기 훌륭한 방법이라는 걸 지구상에서 가장 늦게 깨달은 사람은 아마도 나일 것이다.

목표 성적표

매달 초에 달성하고 싶은 목표를 정합니다. 이번 달 목표를 어떻게 달성했는지 살펴보겠습니다.

2024년 연간 회고 블로그 글 발행하기

결과물이 만족스러웠습니다. 이미 따로 글을 써서 다룬 굵직한 사건들이 많아 한 해가 조각조각 나뉜 느낌이 들어 무엇을 넣어야 할지 정하기가 어려웠습니다. 하지만 최종 결과물은 한 해를 잘 정리한 요약이 되었다고 느꼈습니다.

이 글은 Hacker News에서 잠시 1위를 차지했습니다가, 갑자기 63위로 밀려났는데 이유는 잘 모르겠습니다.

책의 다음 챕터 마무리하기

예상보다 조금 더 진행했습니다. 원래 퀴즈까지 만들 계획은 없었기 때문입니다. 퀴즈가 대단하다고 생각하지는 않지만, 텍스트 콘텐츠에 인터랙티브 요소를 결합하는 재미있는 방식이라고 생각합니다.

독자 피드백을 반영해 튜토리얼 챕터 수정하기

독자 제안에 따라 문장 단위의 수정을 일부 진행했지만, 가장 큰 수정은 새 섹션을 추가한 것이었습니다. 몇몇 분이 예시에서 유용한 더미 데이터를 사용하는 방법에 대한 가이드가 있으면 좋겠다고 했는데, 저도 그 내용이 글에 들어가야 한다는 데 동의했습니다.

AI 혁명 중에 책을 쓰는 게 바보 같은 일일까?

AI가 소프트웨어 개발에 혁명을 일으키고 있다는 점은 제게 분명합니다.

AI 모델은 이제 유능한 주니어 엔지니어 수준으로 동작합니다. 지금과 같은 속도로 발전한다면 2년 안에 대부분의 프로그래밍 작업에서 최고의 인간보다 뛰어난 성능을 보일 것입니다.

소프트웨어 산업의 많은 부분이 AI를 중심으로 재편될 것으로 예상합니다. 제 일생에서 가장 가까운 비유는 데스크톱 소프트웨어에서 인터넷으로의 전환입니다.

저는 직장도 없고 운영할 회사도 없으니, 최근의 AI 발전을 활용하기 위해 원하는 무엇이든 할 수 있는 완전한 자유가 있습니다.

그런데 저는 AI와 전혀 관계없는 책을 쓰고 있습니다…

그저 가장 새롭고 반짝이는 것을 쫓고 싶지는 않지만, AI 혁명을 외면하는 건 90년대 후반에 인터넷이 등장하는 걸 보면서 “나는 고객이 우편으로 주문하는 CD로 소프트웨어를 배포하고 싶어”라고 말하는 것과 같다는 느낌도 듭니다.

책에 집중하기로 한 이유는 여전히 유효하지만, 6개월 전에 계획했을 때 예상했던 것보다 기회비용이 훨씬 커졌습니다.

이 책에 시장이 있기는 할까?

또 다른 문제는 책을 쓰는 것이 장기적인 헌신을 요구하는 일인데, 사람들이 이 책을 읽고 싶어 하는지 아직 확신이 없다는 점입니다.

처음 공개한 챕터는 반응이 좋았지만, 그건 재미있고 대중적인 appeal이 있는 챕터 중 하나였습니다. “Passive Voice Considered Harmful” 같은 챕터는 “채소를 먹어라”는 훈계에 가깝지 않을까 두렵습니다. 사람들은 유익하다는 건 알겠지만, 읽는 재미는 없습니다. 그리고 Hacker News나 reddit 같은 제가 주로 활동하는 곳에서는 수동태에 대한 글을 주목해주지 않을 것입니다.

문제는 제 책의 대부분 챕터가 이런 “채소를 먹어라”식 챕터라는 점입니다.

“글을 소리 내어 읽어 보라” 같은 팁을 블로깅 챕터의 일부로 넣는 식으로 구조를 바꿀 수도 있지만, 그 팁은 블로그 글뿐만 아니라 모든 종류의 글쓰기에 적용되기 때문에 그다지 자연스럽지 않습니다.

하지만 어쩌면 제가 잘못 접근하고 있는지도 모릅니다. 웹을 둘러보는 사람들은 수동태에 대한 글을 읽고 싶어 하지 않겠지만, 효과적인 글쓰기에 대한 책을 읽기로 마음먹었다면 수동태 챕터도 읽을 가능성이 높습니다.

온라인에 무료로 공개하는 샘플이 책에 실릴 챕터와 한 글자도 다르지 않을 거라고 생각했지만, 꼭 그렇게 할 필요는 없습니다. 웹에 맞춰 콘텐츠를 어떻게든 각색할 수 있으니, 블로깅에 대한 샘플 챕터에서 글을 소리 내어 읽는 팁을 다뤄도 괜찮습니다. 실제 책에서는 그 팁이 블로깅 챕터에 속하지 않도록 구성하면 됩니다.

그래도 앞으로 몇 달을 더 투자하기 전에 이 책을 살 고객이 실제로 있는지 검증해야 합니다. 그래서 계획은 “개발자가 읽는 블로그 글 쓰기” 같은 또 다른 재미있고 접근하기 쉬운 챕터에 집중한 뒤, 초기 세 챕터를 기반으로 사전 주문을 받는 Kickstarter를 시작하는 것입니다. 계속 집필할 가치가 있다고 판단할 만한 합리적인 최소 사전 주문량을 정해야 합니다.

뒤늦게 깨달았다: RSS는 훌륭하다

RSS는 25년이나 되었지만, 저는 RSS로 글을 읽는 데 빠져본 적이 없습니다.

2011년에 Google Reader를 써 본 적이 있지만, 피드에 흥미로운 글이 충분히 쌓이지 않아 그냥 확인을 그만두고 잊어버렸습니다.

지난 몇 년간 여러 가지 이유로 RSS에 대한 관심이 다시 커졌습니다.

  • 제가 트위터에서 팔로우하던 기술 분야 사람들이 모두 여러 공간으로 흩어졌습니다.
  • 소셜 미디어가 흥미로운 기술 글보다 눈길을 끄는 게시물을 더 증폭시킨다는 점을 점점 더 체감하게 되었습니다.
  • 운영체제를 NixOS로 바꾸면서 무료 오픈소스 RSS 리더를 직접 호스팅하기가 쉬워졌습니다.
  • 블로그를 이메일로 구독하는 걸 좋아하지 않는다는 걸 깨달았습니다. 받은편지함이 어지러워지고, 읽을 마음의 여유가 없을 때도 꼭 읽어야 할 것 같은 부담이 들기 때문입니다.
  • 웹이 AI가 생성한 저질 콘텐츠로 뒤덮여 가는 상황에서, 제가 좋아하는 특정 사람들을 직접 팔로우하고 싶어졌습니다.

그래서 fusion RSS 리더를 설치했는데, 새로운 블로그 글을 읽는 방법 중 가장 마음에 드는 방식 중 하나가 되었습니다. 소셜 미디어에서 마음에 드는 블로그 글을 찾으면 그 블로그의 다른 글들도 훑어보고, 흥미로운 주제를 다루면 바로 피드에 추가합니다.

최근 흥미로운 블로그들을 팔로우하기 위해 RSS 리더인 fusion을 사용하기 시작했습니다

사이드 프로젝트

wordword: 블로그 글에서 어휘 착시 찾기

최근 Matt Might의 블로그 글에서 “lexical illusion(어휘 착시)”이라는 개념을 설명하는 글을 읽었습니다. 텍스트에서 중복된 단어를 인식하지 못하는 현상을 말하는데, 예를 들면 다음과 같습니다.

Many readers are not aware that the
the brain will automatically ignore
a second instance of the word “the”
when it starts a new line.

저도 블로그를 쓸 때 이런 실수를 자주 해서, 자동으로 잡아주는 도구를 만들고 싶었습니다.

이 도구는 AI 어시스턴트인 Cline에 크게 의존해 만들었습니다. 제 프롬프트와 테스트 케이스를 바탕으로 Cline이 도구를 구현하는 솜씨가 인상적이면서도 무서울 정도였습니다.

그리고 도구는 잘 동작합니다. 이걸 활용해 이미 발행된 글에서 7개의 어휘 착시를 찾아냈습니다.

# Find lexical illusions (and also some false positives like "Duck Duck Go").
$ wordword ./content/
./content/retrospectives/2019/11/index.md:114: the
./content/retrospectives/2022/05/index.md:175: Duck
./content/retrospectives/2022/05/index.md:175: Duck
./content/retrospectives/2022/05/index.md:175: Duck
./content/retrospectives/2022/05/index.md:175: Duck
./content/retrospectives/2022/05/index.md:177: Duck
./content/notes/nix-git-bash-shell/index.md:78: time
./content/notes/cypress-vs-playwright/index.md:278: makes
./content/posts/simple-vue-pre-rendered/index.md:36: for
./content/posts/bootstrapped-founder-year-6/index.md:132: case
./content/posts/ansible-role-clipbucket/index.md:83: a
./content/posts/bootstrapped-founder-year-1/index.md:177: NOW
./content/posts/bootstrapped-founder-year-1/index.md:177: NOW
./content/book-reports/chaos-monkeys/index.md:8: names
./content/book-reports/go-programming-blueprints/index.md:50: of
212 total files checked
15 total errors found

wordword를 블로그의 CI 빌드git pre-commit 훅에 추가했습니다.

그리고 Zig로 작성했기 때문에 엄청나게 빠릅니다. 블로그에 있는 212개의 Markdown 파일을 단 28.7밀리초 만에 검사합니다.

$ hyperfine 'wordword ./'
Benchmark 1: wordword ./
  Time (mean ± σ):      28.7 ms ±   1.3 ms    [User: 11.7 ms, System: 16.5 ms]
  Range (min … max):    26.8 ms …  31.7 ms    90 runs

그 외 자잘한 것들

Codeberg 멤버가 되었습니다

더 기업적이지 않고 더 오픈소스 친화적인 git 호스팅 서비스를 찾고 있었습니다.

그동안 GitLab을 사용해 왔습니다. 하지만 GitLab이 모든 사용자를 2주마다 강제로 로그아웃시키는 기이한 결정을 내렸습니다.

GitLab을 사용할 때마다 로그아웃되어 있습니다. 그리고 로그인하려면 비밀번호 관리자가 자격 증명을 자동으로 채우도록 허용하는 대신, 이메일에서 일회용 코드를 확인하느라 흐름이 끊깁니다.

Codeberg를 써 보니 마음에 들었습니다. GitLab보다 단순한데, GitLab은 제게 항상 필요 이상으로 복잡하게 느껴졌기 때문에 잘 맞았습니다. 게다가 완전한 오픈소스이며 Go와 HTML 템플릿으로 구현되어 있는데, 제가 가장 좋아하는 웹 스택입니다.

Codeberg를 후원하는 방법 중 하나로 회사의 투표권을 가진 멤버로 가입하는 방식이 있길래 그렇게 했습니다. 아직 멤버십으로 뭘 하지는 않았지만, 단순한 사용자가 아니라 협동조합의 일원이 된 것 같은 느낌이 들어 즐겁습니다.

Codeberg의 가장 큰 단점은 이를 지원하는 관리형 지속적 통합(CI) 업체가 없어 보인다는 점입니다.

  • WoodpeckerCI: 유료 관리형 호스팅을 제공하는 업체가 없습니다.
  • Forgejo Actions: 유료 지원이 없는 실험적인 프로젝트입니다.
  • CircleCI: Forgejo/Gitea를 지원하지 않습니다.
  • Garnix: Forgejo/Gitea를 지원하지 않습니다.
  • Buildkite: Forgejo/Gitea를 지원하지 않습니다.
  • Drone: Forgejo/Gitea를 지원하지만, 관리형 호스팅은 Enterprise에만 제공하는 것으로 보입니다.
  • Harness: Drone에서 나온 새로운 서비스인 것 같은데, Forgejo/Gitea를 지원하는지 알 수 없습니다.

Codeberg는 공식적으로 Woodpecker CI를 직접 호스팅하라고 권장하는데, 재미있어 보이면서도 비현실적으로 들려서 무료 Oracle Cloud VM에 하루를 들여 직접 구축했습니다. 이제 wordword와 다른 몇몇 프로젝트의 CI를 직접 호스팅하고 있습니다. 하지만 유료 업체만큼 안전하게 보호할 자신이 없어 시크릿을 저장할 생각은 없습니다. 그래서 진짜 CI/CD 솔루션으로 활용하는 데는 큰 제약이 있습니다.

10Gbps 라우터를 샀습니다

생애 처음으로 제 인터넷 서비스 제공업체(ISP)에서 2Gbps 대칭 속도를 제공하기 시작해서, 그 속도를 온전히 활용해 보고 싶었습니다.

기존 라우터는 Qotom Q355G4였는데, 랙 마운트가 안 되고 1Gbps 포트만 있다는 점을 제외하면 잘 써 왔습니다.

OPNsense나 Protectli 같은 신뢰할 수 있는 하드웨어 업체에서 라우터를 사고 싶었지만, OPNsense의 가장 저렴한 10Gbps 랙 마운트 라우터는 $1,200이고, Protectli는 랙 마운트 옵션이 아예 없습니다.

결국 Qotom C3758R 1U 10Gbps 라우터($417, 배송비와 세금 포함)를 구매해 OPNsense Business를 설치했습니다.

ISP에서 새로 제공하기 시작한 2Gbps 요금제를 활용하기 위해 Qotom C3758R 10Gbps 라우터(위에서 세 번째)를 구매했습니다.

라우터의 RAM이나 디스크 용량이 부족하지 않을까 항상 걱정하지만, OPNsense는 거의 자원을 필요로 하지 않습니다. 8GB RAM과 128GB 디스크로 구성했는데, 속도 테스트를 실행하면서 시스템 부하를 확인해 보니 RAM 사용량은 13%를 넘지 않았고 CPU도 최대 약 30%에 그쳐 제 용도에는 하드웨어가 충분하고도 남았습니다. 참고로 방화벽 규칙을 많이 쓰지 않고, OPNsense의 IDS/IPS 기능도 사용하지 않습니다.

완전히 Rackstuds로 갈아탔습니다

첫 홈 서버 랙을 만드는 과정에 대한 글을 발행한 뒤, 여러 독자가 케이지 너트 대신 Rackstuds를 써 보라고 추천했습니다.

저는 일반 케이지 너트보다 Rackstuds가 훨씬 마음에 듭니다.

처음에는 회의적이었습니다. Rackstuds는 플라스틱이라 금속 케이지 너트보다 쉽게 부러질 것 같았기 때문입니다. 하지만 Rackstuds는 최대 40파운드(약 18kg)까지 장비를 지탱할 수 있다는 실험실 테스트 결과를 공개했습니다.

Rackstuds는 확실히 케이지 너트보다 다루기 쉽습니다. 케이지 너트는 특히 무거운 장비를 장착하기 어렵게 만들었습니다. 한 손으로 장비를 들고 수평을 유지한 채, 다른 손으로 너트를 조여 장비를 고정해야 하기 때문입니다.

Rackstuds는 이 문제를 해결합니다. 스터드를 먼저 설치한 뒤 장비를 그냥 걸기만 하면 되기 때문입니다.

헷갈렸던 점 하나는 Rackstuds에 레드와 퍼플 두 가지 종류가 있다는 것이었습니다. 차이가 헷갈리게 설명되어 있습니다. 퍼플 스터드 제품 페이지에는 이렇게 적혀 있습니다.

2.7mm/0.106"에서 3.2mm/0.125" 사이의 레일에 적합합니다. ≤ 2.2mm/0.086"인 경우 대신 새로운 레드 버전을 사용하세요

뭐지?

저는 서버 랙에서 “레일”이라고 하면 서버에 붙어 슬라이딩되도록 하는 부품을 떠올리는데, 어느 치수든 3mm보다 훨씬 큽니다.

제가 생각했던 서버 랙의 “레일”입니다.

마침내 Rackstuds가 말하는 레일 두께가 랙 전면의 금속 부분을 의미한다는 걸 알아냈습니다.

제 StarTech 랙에서는 퍼플 Rackstuds가 더 잘 맞는 느낌이었습니다.

또 하나 주의할 점은 Rackstuds Duo를 구매하면 정확히 1U인 장비에만 사용할 수 있지만, 낱개 Rackstuds는 어떤 장비든 랙에 장착할 수 있다는 것입니다. 저는 먼저 8개짜리 샘플 팩을 샀다가, 앞으로 장착할 장비들을 위해 20개들이 한 봉지를 추가로 구매했습니다.

마무리

무엇을 해냈나?

배운 점

  • 책 아이디어가 소요 시간과 AI 변화를 더 잘 활용할 수 있는 다른 프로젝트들을 고려했을 때 올바른 전략인지 재평가해야 합니다.
  • 책의 내용을 웹에 더 잘 맞게 각색해 독자를 끌어올 수 있습니다. 발췌본이 책 본문과 100% 동일할 필요는 없습니다.

다음 달 목표

  • Refactoring English의 블로깅 챕터를 완성합니다.
  • Refactoring English의 사전 판매를 시작합니다.

도움이 필요한 부분

  • 전자책 출판에 더 특화된 Kickstarter 대안을 알고 계시다면 알려주세요.
    • LeanPub은 알고 있지만, Kickstarter처럼 “최소 목표를 달성해야만 진행되는” 방식을 찾고 있습니다.
  • PDF와 HTML로 모두 렌더링할 수 있는 마크업 언어로 책을 쓰는 도구에 대해 의견이 있으시다면 연락을 주시거나 아래에 댓글을 남겨주세요.
    • 고려 중인 옵션은 다음과 같습니다.
      • AsciiDoc
      • mdBook
      • Pollen - 아이디어는 마음에 들지만, Pollen을 배우려면 Racket을, 즉 Lisp를 배워야 해서 부담이 큽니다.

원문은 Michael Lynch님이 에 게재했습니다.

이 글은 muse-spark-1.2-contributor 모델을 사용해 번역했습니다.