리팩터링 잉글리시: 16개월 차
한 줄 요약
완주를 눈앞에 두다
하이라이트
- Hacker News 첫 페이지에 글이 올랐습니다. 한 자리에서 써 내려간 글입니다.
- 앞으로 몇 년간 소프트웨어 보안은 꽤 험난할 것으로 예상합니다.
- 가족 사진 공유 앱의 첫 번째 마일스톤을 달성했습니다.
목표 평가
매달 초에 이루고 싶은 목표를 정합니다. 이번 달 목표 달성 결과는 다음과 같습니다.
Refactoring English 마무리하기
- 결과: 새 챕터를 공개했지만 아직 완성은 하지 못했습니다
- 평점: C
마지막 세 챕터를 한 달 안에 끝내겠다는 것이 욕심이라는 건 알고 있었습니다. 그래도 해볼 만하다고 생각했습니다. 세 개 중 하나만 완성했지만, 책은 거의 마무리 단계에 와 있습니다.
Refactoring English 지표
| 지표 | 2026년 2월 | 2026년 3월 | 변화 |
|---|---|---|---|
| 순 방문자 수 | 7,788 | 6,932 | -856 (-11%) |
| 사전 예약 수익 | $886.20 | $725.80 | -$160.40 (-18%) |
이번 달 방문자 수와 매출이 소폭 하락했지만, 별다른 홍보 없이도 독자와 구매자가 꾸준히 유입되고 있어 다행입니다.
이번 달에 진행한 유일한 홍보는 “Which Design Doc Did a Human Write?”라는 글이었습니다. Lobste.rs에서는 반응이 좋았지만 Hacker News에서는 별다른 반응을 얻지 못했습니다. /r/programming에서는 “AI가 생성한 글”이라는 이유로 거부당했고, 운영진에게 메시지를 보내 글 자체는 사람이 직접 썼다고 설명한 뒤에도 결과는 마찬가지였습니다.
이 글의 아이디어는 지난 Refactoring English 라이브 수업에서 얻었습니다. AI가 설계 문서를 작성할 만큼 충분히 뛰어난지에 대해 토론하다가, 제가 직접 손으로 쓴 설계 문서의 AI 버전을 쉽게 생성해 볼 수 있겠다는 생각이 들었습니다. 사람들이 각 설계 문서에서 인간과 AI를 가르는 단서로 무엇을 짚어내는지 읽는 과정이 흥미로웠습니다.
사이먼 윌리슨 전략을 활용할 기회 포착
사이먼 윌리슨(Simon Willison)은 지난 3년간 Hacker News에서 가장 인기 있는 블로거였습니다. 저는 최근 글에서 윌리슨의 잘 알려지지 않았지만 효과적인 블로깅 전략을 다룬 바 있습니다.
사이먼은 종종 폐쇄형 플랫폼(예: TikTok, Twitter)에 갇힌 아이디어를 찾아내 이를 개방형 웹으로 가져와 Hacker News에서 더 쉽게 논의될 수 있도록 합니다. 그의 가장 인기 있는 글 중 일부는 짧은 인용이나 링크에 약간의 논평을 덧붙인 것에 불과합니다. “I’m worried that they put co-pilot in Excel”은 그가 TikTok에서 본 영상의 인용일 뿐입니다. “A computer can never be held accountable”는 사이먼이 몇 개의 트윗을 요약한 글입니다.
사이먼은 이 방식을 “인터넷 전반에 기여하는 저노력 고효율 방식”이라고 부른 바 있으며, 저도 이에 동의합니다.
윌리슨 전략에서 유일하게 어려운 부분은 언제 써야 할지를 알아채는 것입니다. 트윗과 TikTok을 무작위로 요약하기만 해서는 큰 관심을 끌기 어렵습니다. 흥미로운 정보가 웹에 친화적이지 않은 형식에 갇혀 있을 때를 포착해, 아직 신선할 때 웹으로 옮겨와야 합니다.
지난주에 니컬러스 칼리니(Nicholas Carlini)의 “Black Hat LLMs” 발표를 보고 윌리슨의 기법을 활용할 기회라는 걸 깨달았습니다.
발표에서 칼리니는 23년간 아무도 발견하지 못한 리눅스 커널의 원격 익스플로잇 가능한 취약점을 어떻게 찾았는지 설명했습니다. 놀라운 점은 누구나 칼리니가 한 일을 할 수 있었다는 것입니다. 그는 그저 리눅스 커널 소스의 각 파일에 Claude Code를 실행해 취약점을 찾아보라고 시켰을 뿐입니다.
온라인에서 칼리니의 발견에 대한 논의를 찾아봤지만, 의외로 아무도 이야기하고 있지 않았습니다. 유튜브에 공개되었고 Hacker News 스레드에서도 언급되었지만, 마땅히 받아야 할 관심에 비하면 훨씬 덜 주목받고 있었습니다. 사람들은 Claude Code가 FreeBSD 버그의 익스플로잇을 작성했다는 소식에는 호들갑을 떨면서도, 이 소식은 그보다 더 큰 뉴스처럼 느껴졌습니다.
역시 제 생각이 맞았습니다.
글을 세 시간 동안 한 자리에서 써 내려갔는데, 보통 몇 주에 걸쳐 10~30시간을 들이는 제 평소 과정보다 훨씬 빨랐습니다. 지금까지 이 글은 4만 1천 명의 순 방문자를 끌어모았습니다. Hacker News와 Lobste.rs에서 좋은 반응을 얻었습니다. 제가 트위터에 글을 올리지도 않았는데도 독자의 거의 절반이 트위터를 통해 글을 찾아왔습니다.
과거에는 제 개인 블로그 글이 인기를 끌면 많은 독자가 더 깊이 살펴보다가 Refactoring English를 발견하곤 했습니다. 이번에는 그렇지 않았는데, 아마 AI에 관심 있는 독자들이 AI 없이 글쓰기에 관한 책에는 상대적으로 관심이 적기 때문인 것 같습니다.
앞으로 몇 년간 소프트웨어 보안은 험난할 것입니다
칼리니의 발표는 제가 몇 달째 고민해 온 문제를 잘 보여줍니다. 앞으로 몇 년은 사이버 보안 측면에서 꽤 힘든 시기가 될 것이라는 점입니다.
예전에는 보안 취약점을 찾는 데 비용이 많이 들었기 때문에 일반인도 사이버 공격으로부터 어느 정도 보호를 받을 수 있었습니다.
예를 들어, 6개월 전에 오픈소스 파일 동기화 도구인 Syncthing을 사용하는 사람들을 해킹하고 싶었다고 상상해 보겠습니다. 소프트웨어 보안 전문가가 아니라면 다음과 같은 사람을 고용해야 했을 것입니다.
- 취약점을 잘 찾는 사람
- 취약점을 무기화하는 대가로 돈을 받는 것을 꺼리지 않는 사람
- 낯선 사람과 일할 의향이 있는 사람
취약점을 찾아 익스플로잇까지 만들어 주는 사람을 5천 달러에 찾았다고 가정해 보겠습니다. 그래도 여전히 많은 노력과 돈이 듭니다. 게다가 고용한 사람이 사기꾼이 아니라는 보장도 없습니다.
설령 그런 수고를 다 감수한다 해도, 익스플로잇을 사용할 때마다 익스플로잇을 “태워먹을(burn)” 위험이 있습니다. 누군가 자신의 시스템이 침해된 것을 알아채고 Syncthing까지 추적을 해 들어가면, 당신의 익스플로잇을 식별해 버그를 제보할 수 있고, 그러면 익스플로잇은 무용지물이 됩니다.
오늘날 상황과 비교해 보겠습니다. 이제는 월 100달러짜리 Claude Code 구독만 구매하면 칼리니처럼 심각한 취약점을 찾을 수 있습니다. Claude Code는 가드레일 때문에 취약점을 무기화해 달라는 요청은 거부하지만, 머지않아 오픈 웨이트 모델로 몰래 익스플로잇을 개발할 수 있게 될 것이고, 그때는 어떤 AI 벤더도 안 된다고 제지하지 않을 것입니다.
결국 익스플로잇 개발 비용은 급격히 떨어졌지만, 이를 수정하는 가치는 그대로이거나 오히려 낮아졌습니다. AI가 생성한 버그 리포트가 너무 많이 쏟아지다 보니 벤더들은 버그 바운티 프로그램을 중단하고 있고, 성실한 연구자들에게 돌아갈 금전적 보상도 사라지고 있습니다.
칼리니가 한 일은 우연이 아닙니다. 저도 이를 재현해 인기 있는 코드베이스에서 아직 알려지지 않은 원격 코드 실행 취약점을 큰 노력 없이 찾아냈습니다. 마음만 먹으면 더 많이 찾을 수 있을 것 같지만, 저에게는 금전적 가치가 마이너스입니다. 해당 프로젝트에는 버그 바운티가 없어서, 벤더와 수정 절차를 조율하는 데 몇 시간을 쓰면서도 보상은 0원이기 때문입니다.
제가 찾은 취약점에 대해 돈을 주지 않는 탐욕스러운 대기업이 있는 것도 아닙니다. 유지보수자는 그저 선의로 프로젝트를 운영하는 한 사람일 뿐입니다. 사실상 “Dependency” xkcd 만화 그대로입니다. 그 역시 돈을 받지 않고 일하기 때문에 취약점 제보에 보상할 돈이 없습니다. 비록 수십억 달러 규모의 기업들이 분명 그의 코드를 사용하고 있음에도 말입니다.

xkcd #2347, “Dependency”
결국 우리는 AI 보안 도구가 오늘날 정적 분석 도구만큼 저렴하고 편리해진 균형 상태로 다시 돌아가게 될 것입니다. 벤더들은 AI를 이용해 보안 문제가 실제 서비스에 반영되기 전에 잡아낼 수 있게 될 것입니다.
단기적으로는 갑자기 손쉽게 딸 수 있는 낮은 열매가 된 취약점이 많습니다. 공격자 입장에서는 이를 악용할 가치가 있지만, 성실한 연구자가 이를 수정할 유인은 별로 없습니다.
첫 번째 Little Moments 마일스톤 달성
지난 12월에 저는 기존 서비스가 너무 마음에 들지 않아 아기 사진 공유를 위한 무료 오픈소스 앱을 만들겠다고 발표한 바 있습니다. 기존 선택지가 싫었기 때문입니다.
처음에는 바이브 코딩으로 쉽게 만들 수 있을 거라 생각했지만, 곧 설계 문서를 작성하는 연습을 하기에 좋은 기회라는 걸 깨달았습니다. Refactoring English에서 설계 문서 작성 과정을 다뤄 왔지만, 정작 제대로 된 분량의 설계 문서를 써 본 건 거의 10년 만이었습니다.
바이브 코딩이 단기적으로는 훨씬 더 만족감을 주다 보니 설계 문서를 쓰는 일이 쉽지 않았습니다. 그래서 12월부터 이렇게 오래 걸렸지만, 결국 집중해서 제 앱인 Little Moments의 설계 문서를 완성했습니다. 설계 문서가 끝나자 나머지는 쉬웠습니다.
현재는 TinyBeans에서 내보낸 데이터를 가져와 로컬에서 렌더링할 수 있습니다. 실제 가족 사진을 공개하고 싶지 않아 테스트용 더미 데이터를 만들었습니다.
이렇게 최소한의 구현만으로도 너무 신이 나고, 빨리 완성하고 싶습니다.
TinyBeans나 PhotoCircle을 써 본 적이 없다면, 이렇게 극히 기초적인 앱 프로토타입이 왜 신나는지 이상하게 들릴 수 있습니다. 하지만 그 앱들의 사용자 경험이 얼마나 끔찍한지는 아무리 강조해도 지나치지 않습니다.
TinyBeans에서는 다음 사진과 이전 사진을 보는 기본 흐름조차 제대로 동작하지 않습니다. 사진을 보고 있으면 사진 목록으로 다시 돌아가 다음 사진을 찾아야 합니다. 그것도 모바일 앱에서의 이야기입니다. 웹 앱에서는 사진을 순서대로 볼 수조차 없고 달력에서 찾아야 합니다. 거기에 더해 광고와 유료 유도 화면이 도처에 깔려 있고, 모든 것이 고통스러울 정도로 느립니다.
Little Moments는 매우 빠르며, 탐색을 더 쉽게 하려고 키보드 단축키와 모바일 스와이프 제스처도 추가했습니다. 앱을 완성해 TinyBeans 사용을 그만둘 생각에 벌써 기대됩니다.
마무리
무엇을 해냈나요?
- “Claude Code Found a Linux Vulnerability Hidden for 23 Years”를 공개했습니다
- “Which Design Doc Did a Human Write?”를 공개했습니다
- Refactoring English의 “Help the Reacher Reach Their Goal” 챕터를 공개했습니다
- Firefox에 처음으로 기여했습니다. 손상된 Ogg 파일로 인한 충돌을 방지하는 작은 수정이었습니다.
배운 점
- 앞으로 몇 년간 사이버 보안은 험난할 것입니다
- 악의적인 행위자가 취약점을 찾는 일은 그 어느 때보다 쉬워졌지만, 이를 고치려는 성실한 연구자에 대한 보상은 점점 줄어들고 있습니다.
다음 달 목표
- Refactoring English 집필을 마무리합니다
글을 무작위로 읽기