한 줄 요약

책 집필에 집중해야 할까요, 버그 바운티를 쫓아야 할까요?

하이라이트

• 책에 집중할지 보안 버그 바운티에 뛰어들지 고민하고 있습니다.
• AI를 활용해 보안 취약점을 찾는 방법을 가르치는 강좌 개설을 고민 중입니다.

목표 점검

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

Refactoring English 집필 마무리

• 결과: 아직 1~2주 정도 집필이 남았습니다
• 평점: C

거의 다 끝난 것 같다는 느낌이 계속 들지만, 생각보다 버그 바운티에 시간을 훨씬 더 쓰고 있습니다.

Refactoring English 지표

3월 이후 마케팅을 전혀 하지 않아 책 매출이 줄었습니다. 대신 버그 바운티 헌팅에 정신이 팔려 있었습니다. 그동안 쌓아둔 노력 덕분에 그럭저럭 버티고는 있지만, 마케팅을 계속 소홀히 하면 수치가 결국 0을 향해 갈 것 같습니다.

3개월간의 버그 바운티 프로그램

지난 3개월 동안 AI를 활용해 보안 취약점을 찾는 데 많은 시간을 쏟았습니다. 공개적으로 이야기하지 않은 이유는 한정된 버그 바운티 프로그램에 경쟁자를 끌어들이고 싶지 않았기 때문입니다. AI가 보안 리서치에 얼마나 효과적인지 다른 사람들도 이미 깨달았을지 확신이 서지 않았는데, 이제는 비밀이 아닌 것 같습니다.

AI와 보안 리서치 동향을 따라오지 않았다면, Firefox 사례는 놀라울 정도입니다. AI가 보안 리서치에 별 도움이 되지 않던 2025년 내내 Mozilla와 외부 연구자들이 매달 Firefox에서 찾아낸 보안 취약점은 10~20개 정도였습니다.

2026년 2월, Anthropic은 Claude Opus를 이용해 Firefox 취약점 22개를 찾아냈습니다. 즉, Anthropic 혼자서 이전 13개월 동안 다른 모든 사람이 합쳐서 찾은 월간 최대치보다 더 많은 취약점을 한 달 만에 찾아낸 셈입니다. 두 달 뒤 Anthropic은 Claude Mythos로 Firefox에서 무려 271개의 취약점을 추가로 찾아냈습니다.

저도 이 흐름을 어느 정도 일찍 감지하긴 했지만, 방향을 조금 잘못 짚었습니다. 지난 1월에는 AI가 사이버 보안 리서치를 혁신할 수 있다고 생각하면서도, 그 가치는 보안 도구를 만드는 데 있다고 여겼습니다. AI로 퍼즈 테스팅 도구를 작성했는데, 예전에 손으로 직접 했을 때보다 퍼즈 테스팅을 훨씬 빠르게 수행할 수 있어서 놀라웠습니다.

퍼저를 10~20배 더 빠르게 만들 수 있게 됐지만, 알고 보니 제 전략은 필요 이상으로 많은 수고를 들이는 방식이었습니다. AI에게 퍼즈 테스팅 도구를 만들어 달라고 하고 그 결과를 분석하게 하는 대신, 그냥 AI에게 “소스 코드를 보고 취약점을 전부 찾아줘”라고 물어보면 됐습니다.

AI가 소스 코드를 직접 감사하는 데 얼마나 뛰어난지 확인한 뒤에는 퍼징을 그만두고 소스 코드 감사에 집중했습니다. 지금까지 다섯 개의 버그 바운티 프로그램에 50건이 넘는 버그를 제보했고, 약 1만 달러의 포상금을 받았습니다.

버그는 찾기 쉬워졌지만, 바운티 프로그램은 더 어려워졌습니다

AI를 활용해 보안 취약점을 찾는 데는 성공했지만, 그 발견에 대해 기꺼이 비용을 지불하려는 회사를 찾는 일은 그만큼 성공적이지 못했습니다.

지금까지의 결과는 다음과 같습니다.

• 벤더 1: Meta
  • 원격 코드 실행 버그 1건을 포함해 총 8건을 제보했습니다.
  • 몇 주 동안 아무런 답변을 받지 못했습니다.
  • 해당 제품을 개발한 개발자들의 이메일 주소를 찾아 연락했고, 덕분에 트리아지를 통과하도록 에스컬레이션을 받았지만, 그 이후로 2주 넘게 아무런 진전이 없습니다.
• 벤더 2
  • 1건을 제보했습니다.
  • 벤더는 하루 만에 트리아지를 마쳤지만, 본격적인 조사를 시작하려면 몇 주가 걸릴 것이라고 했습니다.
  • 30일이 넘도록 아무 소식을 듣지 못했습니다.
• 벤더 3:
  • 1건을 제보했습니다.
  • 벤더는 중복 제보라며 포상금을 지급하지 않았습니다.
• 벤더 4
  • 40건 정도를 제보했습니다.
  • 그중 8건이 2주 만에 지급되어 총 $9,700를 받았습니다.
  • 2건은 중복으로 거절되었습니다.
  • 나머지는 모두 트리아지를 기다리고 있지만, 가장 가치 있는 건들은 이미 지급이 완료된 앞선 8건에 포함되어 있었습니다.
• 벤더 5: Firedancer (암호화폐 프로젝트)
  • 중간 심각도 이슈 몇 건을 찾았습니다.
  • 제보 절차를 시작하다가 연구자가 들어본 적 없는 서비스에 여권을 업로드해야 한다는 요구사항을 보고 중단했습니다.
  • 프로그램 규정도 애매한 부분이 있어, 그들이 이용하는 바운티 플랫폼의 규정과 서로 모순되는 것처럼 보였습니다.

결국 벤더 4에서 받은 1만 달러는 2주간의 파트타임 작업으로 얻은 성과입니다. 다른 곳에서 6주 이상을 들여 아무 보상도 받지 못한 시간을 고려하지 않는다면 훌륭한 수익률입니다. 벤더 4 같은 곳을 더 찾을 수 있다면 좋겠지만, 방법을 모르겠습니다.

책에 집중해야 할까요, 버그 바운티에 집중해야 할까요?

이제 책과 버그 바운티 사이에서 시간을 어떻게 배분해야 할지 고민하고 있습니다. 생각은 다음과 같습니다.

• 책에 집중하기
  • 장점: 책이 거의 완성 단계라 집중해서 마무리하면 미완성인 책보다 훨씬 가치가 높아집니다.
  • 장점: 책은 오직 저만 만들 수 있는 결과물인 반면, 버그 바운티에는 누구나 참여할 수 있습니다.
  • 장점: 이미 책 출간이 늦어진 상태라, 마무리하면 독자를 기다리게 한 죄책감을 덜 수 있습니다.
  • 장점: 책에 대해서는 공개적으로 이야기할 수 있고, 생각을 정리하는 데 도움이 될 뿐 아니라 새로운 독자가 책을 발견하는 계기가 됩니다.
  • 단점: 책의 기대 수익은 단기적으로는 바운티 헌팅보다 낮게 느껴집니다. 이론상으로는 다음 주에 10만 달러짜리 버그를 찾을 수도 있지만, 다음 주까지 책 판매로 10만 달러를 벌어들일 만한 일을 하기는 어렵습니다.
• 버그 바운티에 집중하기
  • 장점: 버그 바운티 2주로 2025년 한 해 동안 책으로 번 돈보다 더 많이 벌었습니다.
  • 장점: AI 도구로 찾을 수 있는, 아직 발견되지 않은 유료 버그가 엄청나게 많이 남아 있습니다.
  • 장점: 몇 달만 쉬어도 남아 있는 버그의 가치는 크게 떨어질 것입니다. 다른 연구자들이 찾기 쉬운 버그들을 먼저 차지해 버릴 테니까요.
  • 단점: 버그 바운티는 답답합니다. 벤더가 터무니없이 낮은 금액을 제시하거나 아예 무시해도 협상할 수단이 없습니다. 악용하려는 매수자에게 익스플로잇을 파는 경우가 아니라면 대응할 방법이 없습니다.
  • 단점: 버그 바운티 헌팅은 도박처럼 중독성이 있습니다. 보상이 반무작위적으로, 가변적으로 나타나기 때문입니다.
  • 단점: 버그 바운티는 좋지 않은 AI 사용 습관으로 다시 밀어 넣습니다. 백그라운드에서 AI 에이전트가 버그를 찾는 동안 계속 진행 상황을 확인하고 초기 결과에 따라 방향을 바꾸고 싶어집니다.
  • 단점: 작업 내용을 공개적으로 공유하는 데 제약이 훨씬 많습니다. 바운티 프로그램이 요구하는 경우도 있고, 제가 집중하는 영역에 경쟁자를 끌어들이고 싶지 않기 때문이기도 합니다.

이성적으로는 버그 바운티를 계속할 이유를 찾기 어렵지만, 그래도 조금은 계속하고 싶습니다. 아마 책 70%, 버그 바운티 30% 정도의 비중이 되지 않을까 싶습니다.

AI로 소프트웨어 보안을 강화하는 방법을 가르쳐야 할까요

세 번째 가능성은 버그 바운티를 쫓는 대신, 지난 몇 달간 AI로 보안 취약점을 찾는 방법에 대해 배운 내용을 가르치는 것입니다.

오픈소스 프로젝트에서 버그를 함께 찾는 소규모 코호트 기반 강좌를 열어볼까 고민 중입니다. 바운티가 걸려 있지 않은 프로젝트를 선정하면, 수강생들이 보상을 가로채일 걱정 없이 내부적으로 발견 내용을 공유할 수 있습니다. 2~4주간 실시간 또는 녹화 스크린캐스트와 비공개 그룹 채팅을 결합한 형태로 진행할 생각입니다.

이 강좌는 버그 바운티로 돈 버는 방법을 가르치는 과정이 아닙니다. 그 부분도 어느 정도 다룰 수는 있겠지만, 초점은 아닙니다. 지난 3개월간 제가 가장 많이 배운 것이 그쪽이 아니기 때문입니다.

강좌의 주제는 대규모 코드베이스에서 AI를 활용해 보안 취약점을 찾는 방법입니다. AI가 버그가 있을 가능성이 높은 영역에 집중하고, 헛된 단서에 시간과 토큰을 낭비하지 않도록 하는 제가 익힌 기법들을 보여드릴 것입니다. 이 교훈은 여러분의 비공개 코드에 내부적으로 적용할 수도 있고, 보안을 강화하고 싶은 오픈소스 프로젝트에도 적용할 수 있습니다.

관심이 있으시다면 아래 대기 명단에 등록해 주세요.

• 사전 대기 명단 - AI로 보안 취약점 찾기

추천

Timelinize로 소셜 미디어 데이터를 되찾으세요

몇 주 전 reddit에서 Facebook 계정을 삭제하고 싶지만 데이터를 쓸 만한 형태로 보관하고 싶다는 질문을 봤습니다. 예전에 Hacker News에서 보고 깊이 살펴보지 않았던 Timelinize라는 프로젝트가 떠올랐습니다.

Timelinize를 사용하면 Facebook, Google, Twitter 같은 서비스에서 내보낸 데이터를 가져와 통합 타임라인으로 탐색할 수 있습니다. 만든 사람은 인기 리버스 프록시인 Caddy를 만든 Matt Holt입니다.

Timelinize는 아직 알파 단계 느낌이 강하고, 쓸 만하게 만들려고 로컬 패치를 꽤 추가해야 했지만, 방향성은 마음에 듭니다. 앞으로 더 사용하면서 제 패치를 더 많이 업스트림에 기여할 계획입니다.

이전에 클라우드 서비스가 필요했던 일을 로컬 오프라인 솔루션으로 대체할 때마다 묘하게 상쾌한 기분이 듭니다. 스트리밍 서비스에서 Jellyfin으로 옮겼을 때는, 나를 지켜보며 어떻게든 돈을 더 뽑아낼 궁리를 하는 회사 없이 그저 보고 싶은 것을 본다는 느낌이 놀라울 정도로 다르게 다가왔습니다.

이상한 점은, Netflix나 HBO를 볼 때는 “감시당하고 있어!”라는 생각을 의식적으로 한 적이 없다는 것입니다. 하지만 TV와 영화를 오로지 로컬에서만 보기 시작하자, 마치 오랫동안 사무실 칸막이에만 있다가 바깥세상이 있다는 사실 자체를 잊은 것과 같았습니다. 그리고 밖으로 나와 신선한 공기와 햇살을 즐기는 기분이 들었습니다. 물론 비유적인 표현입니다. 실제로는 여전히 실내에 앉아 컴퓨터로 TV를 보고 있었으니까요. 하지만 이전보다 훨씬 빠르고 자유로웠습니다!

Timelinize에서도 비슷한 “신선한 공기를 마시는” 경험을 했습니다. Timelinize의 인터페이스는 사용자 중심이라, 클라우드 플랫폼의 인터페이스가 얼마나 사용자 적대적인지 새삼 깨닫게 됩니다. Facebook과 Twitter는 여러분이 옛 메시지를 스크롤하며 읽는 것을 원하지 않습니다. 그건 돈이 되지 않기 때문입니다. 여러분이 옛 메시지를 읽지 못하도록 교묘하게 불편하게 만듭니다. 대화를 좁은 상자에 욱여넣고, 몇 초마다 멈춰서 새 메시지가 로드될 때까지 기다리게 하며, 끊임없이 주의를 흩뜨리는 알림을 보여 새로운 수익화 가능한 콘텐츠로 다시 끌어들입니다.

Timelinize에서는 읽기 경험이 온전히 아카이브를 읽는 데 맞춰져 있습니다. 새로운 무언가를 확인하라며 주의를 빼앗으려는 요소가 전혀 없습니다. Timelinize는 과거의 스냅샷을 보여주기 때문입니다. 10년 전 특정 날짜로 점프해 당시 나눈 대화를 읽는 것이 꽤 재미있습니다.

The React2Shell Story and What Happened Next.js

당시에는 React2Shell을 따로 따라가지는 않았지만, React.js의 치명적인 취약점으로 공격자가 다수의 React.js 및 Next.js 앱에서 코드 실행을 할 수 있게 했던 사건입니다.

지난주 React2Shell을 발견한 두 연구자가 그 뒷이야기를 글로 썼습니다.

• “The React2Shell Story” — Lachlan Davidson이 쓴, 취약점을 발견한 과정을 다룬 글입니다.
• “The React2Shell Story and What Happened Next.js” — 취약점을 탐색하고 벤더에 알리며, 취약점에 대해 보상금을 지급할 버그 바운티 프로그램을 찾는 과정을 함께한 Sylvie Mayer가 쓴 글입니다.

Lachlan의 글이 더 주목받았지만, 저는 Sylvie의 글이 더 흥미로웠습니다. 특히 그녀가 당시 20세 대학생이었다는 점을 고려하면 더욱 그렇습니다.

Lachlan과 Sylvie는 자신들이 수백, 수천 개의 주요 웹사이트에 영향을 미치는 “핵폭탄”을 발견했다는 것을 둘 다 깨달았습니다. React를 관리하는 Meta와 Next.js를 관리하는 Vercel에 버그를 제보한 뒤, 이 거대한 버그에 대해 보상금을 지급할 다른 버그 바운티 프로그램을 찾고 싶어졌습니다.

연구자들은 Meta가 보안 권고문을 공개할 때까지 다른 벤더들에게 버그를 공개할 수 없었습니다. 문제는 React2Shell이 공개되는 순간, 같은 바운티를 차지하려는 다른 사람들에 대한 우위를 잃게 된다는 것이었습니다.

한발 앞서 나가기 위해 Sylvie는 버그가 비공개 상태인 기간 동안 버그 바운티 프로그램을 미리 조사하고, 해당 벤더 사이트들이 React2Shell에 취약한지 확인했습니다. 그렇게 하면 Meta가 취약점을 공개하자마자 이들 제3자 바운티를 선점할 수 있었습니다.

문제는 React2Shell이 공개되기 전에 Vercel이 웹 애플리케이션 방화벽(WAF)에 이 버그를 차단하는 필터를 만들었다는 것이었습니다. 고객 사이트가 취약한 버전의 React나 Next.js를 실행 중이더라도 Vercel 고객을 보호하는 필터였습니다. Meta와 Vercel은 Cloudflare를 비롯한 유사한 WAF 플랫폼과 협력해 React2Shell 공격을 차단하는 방법을 공유하기도 했습니다.

그래서 Meta가 React2Shell을 공개한 뒤 Sylvie가 미리 조사해 둔 사이트들을 대상으로 버그를 재현해 보려 했지만, 버그가 발동하지 않았습니다. 바운티가 걸린 사이트들 거의 모두가 Cloudflare나 Vercel을 사용하고 있었기 때문에 WAF가 Sylvie의 익스플로잇을 차단한 것입니다.

이제 Lachlan과 Sylvie는 Cloudflare와 Vercel의 WAF를 우회해 React2Shell을 발동시키는 방법을 찾아야 했습니다. 하지만 엔터프라이즈급 WAF를 우회하는 것 자체가 거대한 리서치 프로젝트입니다. 다행히 Sylvie는 Cloudflare WAF의 우회 방법 하나와 Vercel의 우회 방법 다섯 가지를 찾아냈습니다.

흥미롭게도 Sylvie가 벌어들인 수익의 “압도적 다수”는 React2Shell 자체가 아니라 WAF 우회에 대한 보상이었다고 합니다. Vercel은 제보된 우회 방법 하나당 5만 달러를 지급했습니다.

마무리

무엇을 해냈나요?

• 새 챕터 공개: “AI로 글쓰기 개선하기”와 “독자가 있는 곳에서 만나기”
• AI로 글쓰기 개선하는 방법에 대한 독자 대상 라이브 세션 진행
• 버그 바운티 프로그램을 통해 다수의 보안 버그 제보

배운 점

• 장기적으로는 보안 버그 바운티보다 책에 집중하는 것이 저에게 더 좋습니다.
  • 어려운 점은 버그 바운티는 단기 보상이 즉각적인 반면, 책의 보상은 보통 투자 후 최소 한 달이 지나야 나타난다는 것입니다.
• 클라우드 서비스에서 직접 운영하는 로컬 솔루션으로 옮기는 일이 의외로 만족스럽습니다.

다음 달 목표

• Refactoring English를 “콘텐츠 완성” 상태로 만들기
• Refactoring English 독자가 책을 읽으면서 피드백을 남길 수 있는 도구 만들기

도움 요청

팀 코드에서 AI를 활용해 보안 취약점을 찾는 방법에 관심이 있으시다면 대기 명단에 등록해 주세요. 관심 있는 분이 충분히 모이면 강좌를 만들겠습니다.

• 사전 대기 명단 - AI로 보안 취약점 찾기