Refactoring English: 두 번째 달
원문은 Michael Lynch님이 에 게재했습니다. 이 블로그 구독하기
한 줄 요약
AI 혁명 한복판에 책을 쓰고 있어도 될까?
하이라이트
- AI 혁명을 그냥 지켜보고만 있어도 될지 고민이 된다.
- 책에 더 많은 시간을 투자하기 전에 독자들이 정말 이 책을 살 의향이 있는지부터 증명해야 한다.
- 아마 지구상에서 제일 마지막으로 RSS가 블로그를 읽기에 훌륭한 방법이라는 걸 깨달았다.
목표 성적표
매달 초에 그 달에 이루고 싶은 목표를 정한다. 목표 대비 실적은 다음과 같다:
2024년 연말 결산 블로그 글 발행하기
- 결과: My Seventh Year as a Bootstrapped Founder를 발행했다
- 평점: A
결과물이 만족스러웠다. 이미 따로 글로 썼던 굵직한 사건들 때문에 한 해가 파편화된 느낌이라 무엇을 넣어야 할지 고민이 많았는데, 최종 결과는 한 해를 잘 요약한 글이 되었다고 생각한다.
한때 Hacker News 1위까지 올랐지만 갑자기 63위로 떨어졌는데, 이유는 잘 모르겠다.
책의 다음 챕터 한 개 완성하기
- 결과: “Passive Voice Considered Harmful”과 함께 인터랙티브 연습 문제를 공개했다.
- 평점: A
퀴즈는 원래 계획에 없었으니 예상보다 조금 더 했다. 퀴즈가 대단하다고는 생각하지 않지만, 텍스트 콘텐츠와 좀 더 인터랙티브한 요소를 결합하는 재미있는 방식이었다.
독자 피드백을 반영해 튜토리얼 챕터 수정하기
- 결과: “Use unambiguous example values.”라는 새 섹션을 추가했다.
- 평점: A
독자 제안에 따라 문장 단위의 자잘한 수정도 했지만, 가장 큰 수정은 새 섹션을 추가한 것이다. 몇몇 독자들이 예시에 쓸 더미 데이터에 대한 가이드가 있으면 좋겠다고 했는데, 나도 이 내용이 글에 들어가야 한다고 생각했다.
AI 혁명 중에 책을 쓰는 건 바보 같은 짓일까?
AI가 소프트웨어 개발에 혁명을 일으키고 있다는 건 분명해 보인다.
AI 모델은 이제 유능한 주니어 엔지니어 수준으로 동작한다. 지금 속도로 개선된다면 2년 안에 대부분의 프로그래밍 작업에서 최고의 인간보다 뛰어난 성능을 보일 것이다.
소프트웨어 산업의 상당 부분이 AI를 중심으로 재편될 것으로 예상한다. 내 생애에서 가장 가까운 사례는 데스크톱 소프트웨어에서 인터넷으로의 전환이다.
나는 직장도 없고 운영할 회사도 없으니, 최근 AI 발전을 활용하고 싶다면 무엇이든 할 수 있는 완전한 자유가 있다.
그런데 나는 AI와 전혀 상관없는 책을 쓰고 있다…
가장 새롭고 반짝이는 것을 쫓고 싶지는 않지만, AI 혁명을 방관하는 건 90년대 후반에 인터넷이 등장하는 걸 보면서 “나는 고객이 우편으로 주문하는 CD에 소프트웨어를 담아 팔고 싶다”고 말하는 것과 같다는 느낌도 든다.
책에 집중하기로 한 이유는 여전히 유효하지만, 6개월 전에 계획했을 때보다 기회비용이 훨씬 커졌다.
이 책에 시장이 있기는 할까?
또 다른 문제는 책을 쓰는 데 오랜 시간이 걸리는데, 사람들이 이 책을 읽고 싶어 하는지 아직 확신이 없다는 것이다.
처음 공개한 챕터는 반응이 좋았지만, 그건 재미있고 대중적인 매력이 있는 챕터였다. “Passive voice considered harmful” 같은 챕터는 “채소 먹어라”는 훈계에 가깝다는 게 걱정이다. 도움이 된다는 건 알겠지만 읽는 재미는 없다. 그리고 Hacker News나 reddit 같은 내가 주로 활동하는 곳에서는 수동태에 관한 글을 띄워주지 않을 것이다.
문제는 내 책의 대부분 챕터가 그런 “채소 먹어라” 식의 챕터라는 것이다.
“글을 소리 내어 읽어보라” 같은 팁을 블로깅 챕터의 일부로 넣는 식으로 구조를 바꿀 수도 있지만, 그건 블로그 글에만 해당하는 조언이 아니라 모든 종류의 글쓰기에 해당하기 때문에 어색하다.
하지만 어쩌면 접근 방식이 잘못된 것일 수도 있다. 웹을 둘러보는 사람들이 수동태에 대한 글을 굳이 찾아 읽고 싶어 하지는 않겠지만, 효과적인 글쓰기에 관한 책을 읽기로 마음먹었다면 수동태 챕터도 읽을 가능성이 높다.
온라인에 무료로 공개하는 샘플이 책에 들어갈 챕터와 한 글자도 다르지 않아야 한다고 생각했지만, 그럴 필요는 없다. 웹에 맞게 콘텐츠를 어떻게든 각색하면 되니, 블로깅에 관한 샘플 챕터의 일부로 글을 소리 내어 읽는 팁을 다루는 것도 괜찮다. 실제 책에서는 그 팁이 블로깅 챕터에 속하지 않도록 구조를 짜면 된다.
그럼에도, 앞으로 몇 달을 더 투자하기 전에 이 책을 살 고객이 있다는 걸 검증해야 한다. 그래서 계획은 “개발자가 읽는 블로그 글 쓰기” 같은 재미있고 접근하기 쉬운 챕터를 하나 더 완성한 뒤, 초기 세 챕터를 바탕으로 사전 예약을 받는 Kickstarter를 시작하는 것이다. 계속 집필할 정당성을 확보할 만큼 합리적인 최소 사전 주문 목표치를 정해야 한다.
뒤늦게 깨달았다: RSS는 훌륭하다
RSS는 25년이나 된 기술이지만, 나는 RSS로 글을 읽는 데 전혀 흥미가 없었다.
2011년에 Google Reader를 써봤지만, 피드에 흥미로운 글이 충분히 쌓이지 않아 확인하는 걸 그만두고 잊어버렸다.
지난 몇 년간 RSS에 대한 관심이 다시 커진 이유는 여러 가지다:
- 예전에 트위터에서 팔로우하던 기술 분야 사람들이 모두 다른 공간으로 흩어졌다.
- 소셜 미디어가 흥미로운 기술 글보다 눈길을 끄는 글을 더 증폭시킨다는 걸 점점 더 깨닫게 됐다.
- OS를 NixOS로 바꾸면서 무료 오픈소스 RSS 리더를 셀프 호스팅하기가 쉬워졌다.
- 이메일로 블로그를 구독하는 게 마음에 들지 않는다는 걸 깨달았다. 받은 편지함이 어지러워지고, 제대로 읽을 상태가 아닐 때도 읽어야 한다는 압박을 느끼게 된다.
- AI로 만든 저질 콘텐츠가 웹을 뒤덮으면서, 내가 좋아하는 특정 사람들의 글을 직접 팔로우하고 싶어졌다.
그래서 fusion RSS 리더를 설치했는데, 새로운 블로그 글을 읽는 내가 가장 좋아하는 방법 중 하나가 됐다. 소셜 미디어에서 마음에 드는 블로그 글을 찾으면 다른 글들도 훑어본다. 흥미로운 주제를 다루면 바로 피드에 추가한다.
최근 흥미로운 블로그를 팔로우하기 위해 RSS 리더인 fusion을 사용하기 시작했다
사이드 프로젝트
wordword: 블로그 글에서 어휘적 착시 찾기
최근 Matt Might의 블로그 글에서 “어휘적 착시(lexical illusions)”라는 개념을 읽었다. 텍스트에서 중복된 단어를 인지하지 못하는 현상이다. 예를 들면 다음과 같다:
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.
나도 블로그를 쓸 때 이런 실수를 하곤 해서, 이 실수를 자동으로 잡아주는 도구를 만들고 싶었다.
도구를 만들 때 Cline이라는 AI 어시스턴트에 많이 의존했다. 내 프롬프트와 테스트 케이스를 바탕으로 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 foundwordword를 내 블로그의 CI 빌드와 git pre-commit hook에 추가했다.
그리고 Zig로 만들었기 때문에 엄청나게 빠르다. 블로그의 Markdown 파일 212개를 단 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을 써왔는데, 모든 사용자를 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 솔루션으로 활용하는 데는 한계가 크다.
10 Gbps 라우터를 샀다
처음으로 ISP에서 2 Gbps 대칭 속도를 제공하기 시작해서, 그 용량을 전부 활용하고 싶었다.
기존 라우터는 Qotom Q355G4였는데, 랙에 장착할 수 없고 1 Gbps 포트만 있다는 점을 제외하면 잘 쓰고 있었다.
OPNsense나 Protectli처럼 신뢰할 수 있는 하드웨어 벤더에서 라우터를 사고 싶었지만, OPNsense의 가장 저렴한 10 Gbps 랙 마운트형 라우터는 1,200달러였고, Protectli는 랙 마운트형 옵션이 아예 없었다.
결국 Qotom C3758R 1U 10 Gbps 라우터(배송비와 세금 포함 417달러)를 샀고, OPNsense business를 설치했다.
ISP에서 새로 제공하기 시작한 2 Gbps 속도를 활용하기 위해 Qotom C3758R 10 Gbps 라우터(위에서 세 번째)를 샀다.
라우터의 RAM이나 디스크 공간이 부족하지 않을까 항상 걱정하는데, OPNsense는 거의 자원을 쓰지 않는다. 8GB RAM과 128GB 디스크로 했는데, 속도 테스트를 하면서 시스템 부하를 확인해보니 RAM 사용량은 13%를 넘지 않았고 CPU는 최대 약 30%였다. 그래서 이 하드웨어로도 충분하다. 참고로 방화벽 규칙을 많이 쓰지 않고 OPNsense의 IDS/IPS 기능도 사용하지 않는다.
완전히 Rackstuds로 갈아탔다
첫 홈 서버 랙을 만드는 과정에 대한 글을 올린 뒤, 여러 독자가 케이지 너트 대신 Rackstuds를 써보라고 추천했다.
일반 케이지 너트보다 Rackstuds가 훨씬 마음에 든다.
처음에는 회의적이었다. Rackstuds는 플라스틱이라 금속 케이지 너트보다 부러지기 쉬울 것 같았기 때문이다. 하지만 Rackstuds는 최대 40파운드(약 18kg)까지 장비를 지탱할 수 있다는 실험실 테스트 결과를 공개하고 있다.
Rackstuds가 케이지 너트보다 다루기가 확실히 쉽다. 케이지 너트로는 장비를 장착하기가 어려웠는데, 특히 무거운 장비는 더 그랬다. 한 손으로 장비를 들고 수평을 유지한 채, 다른 한 손으로 너트를 조여 장비를 고정해야 했다.
Rackstuds는 이 문제를 해결한다. 스터드를 먼저 설치한 뒤 장비를 그냥 걸기만 하면 되기 때문이다.
헷갈렸던 점 하나는 Rackstuds에 빨간색과 보라색 두 가지 버전이 있다는 것이다. 차이가 헷갈린다. 보라색 스터드 제품 페이지는 이렇게 말한다:
Suitable for rails between 2.7mm/0.106 and 3.2mm/0.125". If ≤ 2.2mm/0.086", use the new red version instead
뭐라는 거지?
서버 랙에서 “레일”이라고 하면 서버를 밀어 넣어 장착하는 슬라이드 레일을 떠올렸는데, 그건 어느 면으로 봐도 3mm보다 훨씬 크다.
내가 생각했던 서버 랙의 “레일”.
마침내 Rackstuds가 말하는 레일 두께가 랙 전면의 금속 부분을 의미한다는 걸 알게 됐다:
내 StarTech 랙에서는 보라색 Rackstuds가 더 편안하게 맞았다.
또 다른 함정은 Rackstuds Duo를 사면 정확히 1U인 장비에만 쓸 수 있고, 낱개로 된 Rackstuds는 어떤 랙 장비든 장착할 수 있다는 점이다. 나는 먼저 8개짜리 샘플 팩을 샀고, 그 다음 앞으로 쓸 랙 장비들을 위해 20개짜리 한 봉지를 더 샀다.
마무리
무엇을 해냈나?
- Refactoring English의 “Passive Voice Considered Harmful” 챕터와 함께 인터랙티브 연습 문제를 공개했다.
- My Seventh Year as a Bootstrapped Founder를 발행했다.
- 짧은 노트 글 5개를 발행했다:
- Zig로 만든 새로운 블로그 오류 검사 도구를 만들었다.
배운 점
- 책 집필에 들어가는 시간과 AI 변화로 생긴 다른 프로젝트 기회를 고려하면, 지금의 책 아이디어가 올바른 전략인지 재평가해야 한다.
- 책의 콘텐츠를 웹에 더 잘 맞게 각색해서 독자를 끌어올 수 있다. 발췌본이 책 본문과 100% 동일할 필요는 없다.
다음 달 목표
- Refactoring English의 블로깅 챕터를 완성한다.
- Refactoring English 사전 예약을 판매하기 시작한다.
댓글
로그인하고 댓글 남기기