Refactoring English: Month 16

Michael Lynch

Refactoring English: 16개월 차

원문은 Michael Lynch님이 에 게재했습니다. 이 블로그 구독하기

한 줄 요약

완성을 코앞에 두고

하이라이트

  • 한 번에 써 내려간 Hacker News 메인에 올랐다.
  • 앞으로 몇 년간 소프트웨어 보안이 험난할 것으로 예상한다.
  • 가족 사진 공유 앱의 첫 번째 마일스톤을 달성했다.

목표 성적

매달 초에 이루고 싶은 목표를 정한다. 이번 달 결과는 다음과 같다.

Refactoring English 집필 마무리

  • 결과: 새 챕터를 공개했지만 아직 완성은 못했다
  • 등급: C

마지막 세 챕터를 한 달 안에 끝내는 건 야심 찬 목표라는 걸 알고 있었지만, 해볼 만하다고 생각했다. 세 개 중 하나만 끝냈지만 책은 거의 완성 단계에 왔다.

Refactoring English 지표

지표2026년 2월2026년 3월변동
순 방문자7,7886,932-856 (-11%)
사전 주문 매출$886.20$725.80-$160.40 (-18%)

방문자와 매출이 이번 달에 소폭 하락했지만, 별다른 홍보 성과 없이도 꾸준히 독자와 구매자가 유입되고 있어 다행이다.

이번 달에 한 유일한 홍보는 “Which Design Doc Did a Human Write?”라는 글이었다. Lobsters에서는 반응이 좋았지만 Hacker News에서는 흥행에 실패했다. /r/programming에서는 “AI가 생성했다”는 이유로 글을 거부했는데, 내가 운영진에게 직접 메시지를 보내 글 자체는 사람이 썼다고 설명한 뒤에도 마찬가지였다.

이 글의 아이디어는 지난 Refactoring English 라이브 수업에서 얻었다. AI가 설계 문서를 쓸 만큼 충분히 뛰어난지 토론하다가, 내가 손수 쓴 설계 문서의 AI 버전을 생성하는 게 얼마나 쉬울지 깨달았다. 사람들이 각 설계 문서에서 인간과 AI를 가르는 단서로 무엇을 짚어냈는지 추측하는 글을 읽는 게 흥미로웠다.

사이먼 윌리슨 전략을 활용할 기회 포착

사이먼 윌리슨은 지난 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을 무작위로 요약하기만 해서는 별다른 반향을 얻기 어렵다. 흥미로운 정보가 웹에 친화적이지 않은 형식에 갇혀 있을 때를 포착해, 아직 신선할 때 웹으로 옮겨와야 한다.

지난주 나는 니콜라스 칼리니의 “Black Hat LLMs” 강연을 보고 윌리슨의 기법을 쓸 기회가 있다는 걸 깨달았다.

강연에서 칼리니는 23년간 아무도 눈치채지 못한 리눅스 커널의 원격 익스플로잇 가능한 취약점을 어떻게 찾았는지 설명했다. 놀라운 점은 칼리니가 한 일을 누구라도 할 수 있었다는 것이다. 그는 그저 리눅스 커널 소스의 각 파일에 Claude Code를 적용해 취약점을 찾아달라고 요청했을 뿐이다.

나는 온라인에서 칼리니의 발견에 대한 논의를 찾아봤지만, 아무도 이야기하지 않는 것을 보고 놀랐다. 유튜브에 공개됐고 Hacker News 스레드에서 언급되기도 했지만, 받아야 할 관심에 비하면 훨씬 적은 주목을 받고 있는 듯했다. 사람들은 Claude Code가 FreeBSD 버그의 익스플로잇을 작성한 것을 크게 떠들썩하게 다루고 있었지만, 이 소식이 더 큰 뉴스처럼 느껴졌다.

내 예상은 맞았다.

나는 그 글을 세 시간 만에 한 자리에서 써 내려갔는데, 보통 몇 주에 걸쳐 10~30시간을 들이는 내 평소 과정보다 훨씬 빨랐다. 지금까지 이 글은 순 방문자 4만 1천 명을 끌어모았다. Hacker NewsLobsters에서 반응이 좋았다. 내가 트위터에 글조차 올리지 않았는데도, 독자의 거의 절반이 트위터를 통해 글을 찾았다.

과거에는 내 개인 블로그의 글이 인기를 끌면 많은 독자가 더 깊이 파고들어 Refactoring English를 발견하곤 했다. 이번에는 그러지 않았는데, 아마도 AI에 관심 있는 독자들은 AI 없이 글쓰기를 다루는 책에는 관심이 덜하기 때문인 것 같다.

앞으로 몇 년간 소프트웨어 보안은 험난할 것이다

칼리니의 강연은 내가 몇 달째 생각해 온 점을 부각한다. 앞으로 몇 년은 사이버 보안 측면에서 꽤 험난할 것이다.

예전에는 보안 취약점을 찾는 데 비용이 많이 든다는 점 때문에 일반인이 사이버 공격으로부터 어느 정도는 보호를 받았다.

예를 들어 6개월 전에 Syncthing이라는 오픈소스 파일 동기화 도구를 쓰는 사용자들을 해킹하고 싶다고 상상해 보자. 소프트웨어 보안 전문가가 아니라면, 그런 사람을 고용해야 한다.

  • 취약점을 잘 찾는 사람
  • 찾은 취약점을 무기화하는 일을 돈 받고 해도 괜찮다고 생각하는 사람
  • 모르는 사람과 일할 의향이 있는 사람

가령 Syncthing 취약점을 찾아 익스플로잇까지 만들어 줄 사람을 5천 달러에 구했다고 하자. 그것도 여전히 큰 수고와 비용이다. 그것도 고용한 사람이 진짜이고 사기꾼이 아니라는 전제 하에서다.

그리고 그런 수고를 다 겪는다 해도, 익스플로잇을 쓸 때마다 “태워버릴” 위험이 있다. 누군가 자신의 시스템이 침해된 것을 알아차리고 그 원인을 Syncthing까지 추적하면, 당신의 익스플로잇을 식별해 버그를 제보할 수 있고, 그러면 익스플로잇은 무용지물이 된다.

오늘날 상황과 비교해 보자. 월 100달러짜리 Claude Code 구독을 결제하면 칼리니가 한 것처럼 치명적인 취약점을 찾을 수 있다. Claude Code의 가드레일은 취약점을 무기화하라는 요청을 거부하게 만들지만, 머지않아 AI 업체의 허락 없이도 공개 가중치 모델로 몰래 익스플로잇을 개발할 수 있게 될 것이다.

즉, 익스플로잇 개발 비용은 급격히 떨어졌지만, 이를 수정하는 가치는 그대로거나 오히려 낮아졌다. AI가 생성한 버그 리포트가 너무 많아 업체들이 버그 바운티 프로그램을 중단하고 있어, 성실한 연구자에게 돌아가는 금전적 보상이 사라지고 있다.

칼리니가 한 일은 요행이 아니다. 나도 이를 재현해 큰 노력 없이 인기 있는 코드베이스에서 아직 알려지지 않은 원격 코드 실행 취약점을 찾았다. 더 많이 찾을 수도 있겠지만, 나에게는 금전적 가치가 마이너스다. 해당 프로젝트에는 버그 바운티가 없어서, 나는 업체와 수정을 조율하는 데 몇 시간을 쓰면서도 0달러를 받기 때문이다.

내가 찾은 취약점에 대해 돈을 주지 않는 탐욕스러운 대기업이 있는 게 아니다. 관리자는 그저 선의로 프로젝트를 유지하는 평범한 개인일 뿐이다. 사실상 xkcd의 “Dependency”와 같은 상황이다. 그는 취약점 제보에 대해 돈을 줄 여유가 없는데, 그 역시 아무런 보수를 받지 못하기 때문이다. 그런데도 수십억 달러짜리 기업들은 분명히 그의 코드를 쓰고 있다.

xkcd #2347, “Dependency”

결국 우리는 AI 보안 도구가 오늘날 정적 분석 도구만큼 저렴하고 편리한 균형 상태로 돌아가게 될 것이다. 업체들은 AI를 이용해 보안 이슈를 프로덕션에 도달하기 전에 잡아낼 것이다.

단기적으로는 갑자기 낮은 곳에 매달린 열매가 된 취약점이 많다. 공격자에게는 이를 익스플로잇할 가치가 있고, 성실한 연구자에게는 이를 수정할 가치가 별로 없는 상황이다.

첫 번째 Little Moments 마일스톤 달성

지난 12월에 나는 기존 서비스가 너무 마음에 들지 않아서 아기 사진 공유를 위한 무료 오픈소스 앱을 만들고 있다고 발표했다.

이 앱은 바이브 코딩으로 쉽게 만들 수 있을 거라 예상했지만, 곧 설계 문서를 작성하는 연습을 하기에 좋은 기회라는 걸 깨달았다. 나는 Refactoring English를 위해 설계 문서 작성 과정에 대해 써 왔지만, 거의 10년 동안 제대로 된 분량의 설계 문서를 써 본 적이 없었다.

단기적으로는 바이브 코딩이 훨씬 더 만족스러운데 설계 문서를 쓰려니 어려웠다. 그래서 12월부터 시간이 걸렸지만, 마침내 집중해서 내 앱 Little Moments의 설계 문서를 작성했다. 설계 문서가 완성되자 나머지는 쉬웠다.

현재는 TinyBeans에서 내보낸 데이터를 가져와 로컬에서 렌더링할 수 있다. 실제 가족 사진을 공개하고 싶지 않아 테스트용 더미 데이터를 만들었다.

이 최소한의 구현만으로도 너무 신나고, 빨리 완성하고 싶다.

TinyBeans나 PhotoCircle을 써 본 적이 없다면, 내 아주 기초적인 앱 프로토타입이 신난다는 게 이상하게 들릴 수도 있다. 하지만 그 앱들의 사용자 경험이 얼마나 끔찍한지 아무리 강조해도 지나치지 않다.

TinyBeans에서는 다음 사진과 이전 사진을 보는 기본적인 흐름조차 제대로 동작하지 않는다. 사진을 보고 있다면 사진 목록으로 뒤로 이동한 뒤 다음 사진을 찾아야 한다. 그것도 모바일 앱에서의 이야기다. 웹 앱에서는 사진을 순서대로 볼 수도 없고 달력에서 찾아야 한다. 게다가 광고와 업셀 유도가 도처에 깔려 있고, 모든 것이 고통스러울 정도로 느리다.

Little Moments는 매우 빠르고, 탐색을 더 쉽게 만들기 위해 키보드 단축키모바일 스와이프 제스처도 추가했다. 앱을 완성해 TinyBeans 사용을 그만두고 싶어 마음이 급하다.

마무리

완료한 일

배운 점

  • 앞으로 몇 년간 사이버 보안은 험난할 것이다
    • 악의적인 행위자가 취약점을 찾는 것이 그 어느 때보다 쉬워진 반면, 이를 수정하려는 성실한 연구자에 대한 보상은 줄어들고 있다.

다음 달 목표

  • Refactoring English 집필 마무리

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

댓글