한 줄 요약

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

하이라이트

• 책 집필에 집중할지 보안 버그 바운티를 쫓을지 고민하고 있다.
• AI를 활용해 보안 취약점을 찾는 방법을 가르치는 강의를 고려 중이다.

목표 달성 평가

매달 초에 달성하고 싶은 목표를 선언한다. 목표 대비 실적은 다음과 같다:

Refactoring English 집필 마무리

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

거의 다 끝났다는 느낌이 계속 들지만, 그때마다 의도했던 것보다 버그 바운티에 더 많은 시간을 쓰게 된다.

Refactoring English 지표

3월 이후로 마케팅을 전혀 하지 않아 책 수익이 감소했다. 대신 버그 바운티 헌팅에 정신이 팔려 있었다. 과거의 노력 덕분에 간신히 버텨왔지만, 마케팅을 소홀히 하면 수치가 0을 향해 떨어질 것이 분명하다.

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

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

AI와 보안 연구 동향을 계속 지켜보지 않았다면, Firefox는 놀라운 사례 연구다. 2025년 내내(AI가 보안 연구를 제대로 하기도 전) 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가 소스 코드를 직접 감사하는 데 얼마나 뛰어난지 확인한 뒤, 나는 퍼징을 그만두고 소스 코드 감사에 집중했다. 지금까지 5개의 서로 다른 버그 바운티 프로그램에 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로 소셜 미디어 데이터를 되찾아보자

몇 주 전, 레딧에서 한 질문을 봤다. 페이스북 계정을 삭제하고 싶지만 데이터를 쓸 만한 형식으로 보관하고 싶다는 내용이었다. 그 질문을 보고 예전에 Hacker News에서 봤지만 자세히 살펴보지 않았던 Timelinize라는 프로젝트가 떠올랐다.

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

Timelinize는 아직 상당히 알파 단계처럼 느껴지고, 쓸 만하게 만들려고 로컬 패치를 많이 추가해야 했지만, 방향성은 마음에 든다. 더 사용해 보면서 내 패치를 더 많이 업스트림에 기여할 계획이다.

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

이상한 점은, Netflix나 HBO를 볼 때는 “어, 내가 감시당하고 있네!”라고 의식적으로 생각한 적이 없다는 것이다. 하지만 TV와 영화를 온전히 로컬에서 보기 시작하자, 마치 오랫동안 사무실 큐비클에만 있다가 바깥세상이 있다는 사실 자체를 잊고 있었던 것 같았다. 그리고 밖에 나가 신선한 공기와 햇살을 즐겼다. 비유적인 의미로 말이다. 문자 그대로는 여전히 실내에 앉아 컴퓨터로 TV를 보고 있었다. 하지만 이전보다 훨씬 빠르고 자유로웠다!

Timelinize에서도 비슷한 “신선한 공기를 마시는” 경험을 했다. Timelinize의 인터페이스는 사용자 중심적으로 설계되어 있어, 클라우드 플랫폼의 인터페이스가 얼마나 사용자 적대적인지 깨닫게 된다. Facebook과 Twitter는 당신이 옛 메시지를 그냥 스크롤해 읽는 것을 원하지 않는다. 그건 돈이 되지 않기 때문이다. 당신이 옛 메시지를 읽지 못하게 하려고, 그들은 경험을 미묘하게 불편하게 만든다. 대화를 좁은 상자에 가두고, 몇 초마다 멈춰서 새 메시지가 로드되기를 기다리게 하며, 계속해서 주의를 끄는 알림을 보여줘 수익화할 수 있는 새 콘텐츠로 다시 끌어들이려 한다.

Timelinize에서는 읽기 경험이 내 아카이브를 그저 읽을 수 있도록 설계되어 있다. 새로운 콘텐츠를 확인하라며 주의를 빼앗으려는 것이 아무것도 없다. Timelinize는 과거의 스냅샷을 보여주기 때문이다. 10년 전 날짜로 이동해 그때 나눈 대화를 읽는 것이 재미있다.

React2Shell 이야기와 Next.js에서 벌어진 일

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

지난주, React2Shell을 발견한 두 연구자가 그 이면에서 무슨 일이 있었는지 글을 썼다:

• “The React2Shell Story” by Lachlan Davidson, 취약점을 발견한 수석 연구원.
• “The React2Shell Story and What Happened Next.js” by Sylvie Mayer, 취약점을 탐색하고 벤더에 알리며 포상금을 지급할 버그 바운티 프로그램을 찾는 일을 도운 연구원.

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

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

연구자들은 Meta가 보안 권고를 공개 발표하기 전까지는 다른 벤더들에게 버그를 공개할 수 없었다. 문제는 React2Shell이 공개되는 순간, Lachlan과 Sylvie가 같은 포상금을 노리는 다른 모든 사람들에 대한 선점 효과를 잃게 된다는 점이었다.

선수를 치기 위해 Sylvie는 버그 비공개 기간 동안 버그 바운티 프로그램을 사전 조사하고, 해당 벤더들의 사이트가 React2Shell에 취약한지 확인했다. 그렇게 하면 Meta가 취약점을 발표하자마자 Sylvie와 Lachlan이 해당 제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이 제보된 우회 한 건당 $50k를 지급했기 때문이다.

마무리

무엇을 해냈나?

• 새 챕터 발행: “Improve Your Writing with AI”와 “Meet the Reader Where They Are”
• AI를 활용해 글쓰기를 개선하는 방법에 대한 독자 대상 라이브 세션 진행
• 버그 바운티 프로그램을 통해 다수의 보안 버그 제보

배운 점

• 장기적으로는 보안 버그 바운티보다 책에 집중하는 것이 나에게 더 낫다.
  • 어려운 점은 버그 바운티가 단기적으로 보상이 즉각적인 반면, 책에 대한 보상은 투자가 있은 뒤 최소 한 달은 지나야 따라온다는 것이다.
• 클라우드 서비스에서 직접 운영하는 로컬 솔루션으로 옮기는 것이 의외로 만족스럽다.

다음 달 목표

• Refactoring English를 “콘텐츠 완성” 단계까지 가져가기.
• Refactoring English 독자가 책을 읽으면서 피드백을 남길 수 있는 도구 만들기.

도움 요청

팀 코드에서 AI를 활용해 보안 취약점을 찾는 방법을 배우고 싶다면 관심 등록 리스트에 신청해 달라. 관심이 충분히 모이면 강의를 만들 예정이다.

• 사전 관심 등록 - AI를 활용해 보안 취약점 찾기