이 글의 목차
2026 AI 시대 버그바운티 로드맵: 성장 방향성과 AI 활용 전략
1. AI 시대에 버그바운티를 어떻게 접근해야 하는가
요즘 AI 도구가 빠르게 발전하면서 버그바운티 판도도 바뀌고 있다. 효율적으로 취약점을 찾을 수 있다는 장점도 있지만 그와 반대로 문제들도 생기고 있다. 비추어 보면 자동화 스크립트로 마구 쏘아대거나 AI가 반쯤 만들어준 허술한 제보(AI Slop)가 눈에 띄게 늘었다. 이런 제보는 플랫폼 검수 팀에서 걸러지고, 결국 제보자의 신뢰만 깎일 수 있다는게 문제다.
이 상황을 두고 두 가지 반응이 나온다. 한쪽은 “AI가 다 해주니까 기본기는 건너뛰고 Claude Code부터 배우면 된다"고 하고, 다른 한쪽은 “AI는 쓸모없으니 어떤 도움도 없이 예전 방식대로만 하면 된다"고 한다. 나는 둘다 정답이 될 수 없다고 생각한다.
많은 사람들이 AI를 써보며 실제로 도움이 된다는 사실을 체감하고 있다. AI는 해커를 완전히 대체하지 못하지만, 초보자와 숙련된 해커 사이의 격차를 좁혀준다. 멘토가 없어서, 라이트업을 봐도 이해가 안 돼서, 코드 리뷰를 받을 수 없어서 수년간 정체됐던 그 격차를 AI를 제대로 쓰면 몇 달 만에 줄일 수 있다.
이 글의 방향성은 내가 좋아하는 NahamSec의 유튜브 영상을 토대로 내용을 정리하고 구성했다. 앞으로 내가 나아가야할 이정표가 되지 않을까 싶어 정리해봤다.
Nahamsec의 친구 Douglas가 Claude를 활용해 하나의 버그바운티 프로그램에서 4만 달러(약 5천만 원)를 번 사례가 있다. 그가 타깃에 무작정 Claude Code를 던져놓고 버그가 나오길 기다린 것이 아니라고 한다. 그는 HackerOne에서 실제로 찾아냈던 보고서들을 꾸준히 쌓아왔고, 그 경험에서 나온 본인만의 방법론과 언어로 버그들을 정리했다. 그리고 이것을 AI가 실행할 수 있는 커스텀 스킬로 만들었다. AI는 그가 이미 갖고 있던 기술을 1,000배 빠르게 실행해준 것뿐이다.
기본기가 없는 사람에게 똑같은 AI 환경을 쥐어주면 결과는 0이다. AI가 증폭시켜 줄 대상 자체가 없기 때문이다.
핵심 공식은 이렇다.
먼저 배우고, 그 다음에 AI로 가속화한다. 절대 반대가 되어서는 안 된다.
2. Pillar 1: 기초 메커니즘 익히기
2.1. 웹이 어떻게 작동하는지 알아야 한다
브라우저가 서버에 요청을 보내고, 서버가 응답을 돌려주는 흐름을 모르면 AI가 패킷을 분석해줘도 그 내용을 읽을 수 없다. Claude나 ChatGPT에게 물어보면 훌륭한 답변을 주겠지만, 기초가 없으면 그 내용이 무엇을 의미하는지 전혀 알 수 없다.
익혀야 할 것들은 이렇다.
- HTTP 요청과 응답의 구조, 헤더가 어떤 역할을 하는지, 상태 코드가 무엇을 의미하는지
- 쿠키와 세션과 JWT가 인증을 어떻게 처리하는지, 로그인할 때 서버에서 실제로 무슨 일이 일어나는지
- Burp Suite나 Caido 중 하나를 골라서 요청을 가로채고, 수정하고, 다시 보내는 법
이론을 수집하는 것보다 실제 패킷을 눈으로 보는 게 훨씬 빠르다. 어디서 배워야 할지 모른다면 PortSwigger의 Web Security Academy가 무료로 제공되는 가장 체계적인 시작점이다. 강의보다 중요한 것은 직접 랩 실습을 해보는 것이다.
2.2. 취약점의 이름이 아니라 동작 원리를 알아야 한다
IDOR, XSS, SQLi라는 이름을 외우는 것이 목적이 아니다. 서버가 왜 그런 오류를 내는지를 이해해야 AI에게 “이 부분을 이런 방향으로 살펴봐"라고 정확하게 지시할 수 있다.
IDOR / BAC (권한 검증 누락) 서버가 사용자의 세션을 확인하는 대신 요청 파라미터 안의 ID 값을 그대로 믿는 구조에서 생긴다. 왜 서버가 파라미터를 과하게 신뢰하게 되는지를 이해하면 어디를 찾아야 할지 보인다.
XSS (스크립트 삽입) 사용자가 입력한 값이 검증 없이 브라우저 해석기로 들어가는 구조다. 브라우저가 HTML과 JavaScript를 어떻게 읽는지 알면, 어떤 입력이 어디서 실행될 수 있는지 판단할 수 있다.
SQLi (쿼리 구조 변형) 데이터와 명령이 분리되지 않아서 생기는 문제다. 서버가 입력값을 쿼리 안에 직접 끼워 넣는 구조를 이해하면 어떤 파라미터를 테스트해야 하는지 보인다.
3. Pillar 2: AI와 함께 배우는 방법
3.1. 기존 학습 방식의 한계
공개된 취약점 라이트업(Write-up)을 읽다가 SSTI 같은 모르는 개념이 나오면 검색한다. 검색 결과로 들어간 페이지에서 또 모르는 개념 여섯 개가 나와 다시 검색한다. 3시간 뒤 탭을 닫고 자괴감을 느낀다. 처음에 무엇을 읽고 있었는지 이미 잊은 상태다.
3.2. AI를 1:1 튜터로 쓰는 방법
AI를 단순한 검색창으로 쓰지 않는다. 라이트업 전체를 AI에 복사해 넣고, 예를 들어 이런 식으로 요청한다.
읽다가 막히는 순간 맥락을 끊지 않고 바로 물어볼 수 있다. 꼬리 질문을 던지고, 나를 테스트해달라고 퀴즈를 내게 하거나, 직접 시도해볼 수 있는 유사한 과제를 달라고 한다.
| 구분 | 내용 |
|---|---|
| Read | 이해가 안 되는 공개 취약점 라이트업 전문을 AI에 넣는다 |
| Ask | 공격자의 접근 논리, 서버 측 취약 원인을 초보자 눈높이로 설명해달라고 한다 |
| Quiz | AI에게 나를 테스트해달라고 하거나 직접 시도해볼 과제를 달라고 한다 |
| Apply | 배운 내용을 실제 랩이나 타깃에 적용해본다 |
모든 버그 유형, CVE, 공개 라이트업을 알고 있으며 아무리 쉬운 질문을 해도 피곤해하지 않는 24시간 튜터가 생긴 셈이다. 단, 이 루프는 Pillar 1의 기초가 갖춰졌을 때만 작동한다. HTTP 기초를 모르면 AI의 설명이 오히려 더 큰 혼란을 일으킬 뿐이다.
3.3. AI가 커뮤니티를 대신하지는 못한다
AI는 훌륭한 튜터이지만 커뮤니티는 아니다. AI는 프로그램 매니저에게 소개해주거나 추천해주지 못한다. X(트위터)에서 다른 해커들을 팔로우하고, 디스코드에 참여하거나 오프라인 모임에 나가는 것은 AI가 채워줄 수 없는 부분이다.
4. Pillar 3: 정찰과 타깃 선정
4.1. 어떤 타깃을 골라야 하는가
Google이나 Apple 같은 대형 기업의 프로그램은 수많은 전문가가 이미 훑고 지나갔다. 가장 경쟁이 치열한 공격 표면이라 초보자가 6개월을 쏟아도 아무것도 찾지 못하고 포기하는 경우가 많다.
처음에는 이런 프로그램을 먼저 보는 게 낫다.
- 범위(Scope)가 넓다
- 최신 프로그램이고 업데이트가 자주 일어난다
- 서브도메인 구조가 정리되지 않아서 관리 허점이 있을 가능성이 있다
4.2. 정찰 단계에서 AI를 어떻게 쓰는가
Subfinder, HTTPX, AlterX 같은 정찰 도구로 수집하면 수백 개의 서브도메인과 엔드포인트 목록이 나온다. 이 데이터를 혼자 분류하려면 시간이 많이 든다. AI를 활용하는 방법은 세 가지다.
첫째, 결과물 분류 서브도메인 400개가 나왔을 때, 목록을 AI에 넣고 “인증, 관리자, API, 내부 툴, 마케팅 등으로 분류해줘"라고 하면 우선순위 타깃 리스트가 만들어진다.
둘째, 페이로드 생성 특이한 인증 로직을 발견했을 때, 그 흐름을 설명하고 “우회 가능한 페이로드나 기법 10가지를 써줘"라고 요청한다.
셋째, 커스텀 정찰 스크립트 작성 Python을 몰라도 된다. “JWT 토큰을 사용해서 targets.txt 파일 안의 모든 엔드포인트에 요청을 보내고, 인증 없이도 접근 가능한지 확인한 결과를 CSV로 저장하는 스크립트를 써줘"라고 구체적으로 지시하면 AI가 작동하는 코드를 만들어준다.
4.3. 스크립트를 만들게 할 때 중요한 두 가지
Python 문법을 완벽히 외우는 것보다 원하는 검증 로직을 AI에게 정확하게 설명하는 능력이 더 중요하다.
명확한 명세(Specification) 단순히 “스크립트 짜줘"가 아니라 입력 파일 형식, 포함할 헤더, 비교 조건, 출력 방식까지 구체적으로 지시한다.
문서화(Documentation) 스크립트가 완성되면 어떤 기능을 하는지, 어떤 예외를 처리하는지 README나 파일 상단 주석으로 남겨둔다. 3개월 뒤 사이트 구조가 바뀌어서 스크립트가 깨졌을 때, 문서가 있으면 AI에게 문맥을 전달해 빠르게 수정할 수 있다.
5. Pillar 4: 실전 탐색과 분석
5.1. 기능 맵핑부터 시작한다
모든 기능을 무작위로 눌러보는 방식은 시간이 많이 들고 어디서 무엇을 했는지 파악하기 어렵다. 앱을 둘러보며 구조를 먼저 파악한 뒤, AI에게 우선순위를 이렇게 물어본다.
IDOR, Access Control, 권한 상승 등 어디부터 봐야 하는지 체크리스트가 나온다.
5.2. 요청 안의 모르는 값을 AI로 분석한다
Burp에서 가로챈 요청 안에 Base64로 인코딩된 값, JWT, 역할을 알 수 없는 파라미터가 있을 때, 요청 전체를 AI에 넣고 각 파라미터가 어떤 역할을 하는지, 어떤 부분을 조작해볼 수 있는지 분석받는다.
5.3. 클라이언트 코드를 AI로 읽는다
JavaScript 파일은 난독화되어 있거나 길이가 길어서 직접 읽기 어렵다. 클라이언트 측 JavaScript를 Claude Code나 Cursor에 넣고 “모든 API 호출, 메서드, 헤더, 파라미터, 참조된 서브도메인을 문서화해줘"라고 지시한다. 여기서 나온 엔드포인트와 파라미터를 Burp Suite나 Caido로 가져가 직접 테스트한다.
AI가 버그를 대신 찾아주지는 않는다. 비즈니스 로직과 맥락은 해커가 직접 판단해야 한다. 하지만 지루한 작업의 70~80%를 AI가 처리해주기 때문에 해킹 본연의 일에 더 집중할 수 있다.
초보자에게 먼저 추천하는 버그 유형은 Broken Access Control, IDOR, XSS(특히 Blind XSS)다. 깊은 기술적 지식보다 세심함이 필요하고, AI가 가장 강력하게 도울 수 있는 분야다.
6. Pillar 5: 보고서 작성과 장기적 성장
6.1. 취약점을 찾은 것만으로는 충분하지 않다
보고서 작성 능력은 500달러짜리 제보를 3,000달러짜리로 바꿀 수 있다. 아무리 좋은 취약점을 찾아도 그 취약점이 실제로 어떤 피해를 줄 수 있는지 설득하지 못하면 보상을 받지 못하거나 거절당한다. 단순히 “이런 버그가 있다"로 끝내지 않고, “이 버그가 기업 데이터에 어떤 위험을 가져오는지"를 비즈니스 관점에서 설명해야 한다.
6.2. 보고서를 쓸 때 AI를 활용하는 방법
보고되지 않은 취약점의 데이터 전체를 AI에 그대로 넣으면 안 된다. 타깃 정보와 민감한 데이터를 제거한 뒤 세 가지 방식으로 활용한다.
첫째, 임팩트 문구 작성 앱 이름이나 엔드포인트 없이 버그 클래스만 설명하고 임팩트 문구를 요청한다.
둘째, 보고서 첨삭 민감 정보를 제거한 보고서 초안을 넣고, 검수자(Triager) 관점에서 부족한 점이나 추가해야 할 내용을 지적받는다.
셋째, 번역 및 언어 교정 영어가 익숙하지 않은 경우 Claude를 이용해 시니어 보안 연구원의 톤으로 재작성하거나 번역을 맡겨 전달력을 높인다.
6.3. 거절을 받아도 성장할 수 있다
중복(Duplicate)이나 정보 수준 판정(Informational)으로 거절을 받아도 끝이 아니다. 테스트했던 과정을 AI에 설명하고, 시니어 멘토에게 묻듯 피드백을 요청한다.
과거에는 시니어 멘토가 있어야 가능했던 피드백 루프를 AI를 통해 실행할 수 있다. 그 답변을 자신만의 방법론에 쌓아간다.
7. 제대로 성장하고 있는지 확인하는 방법
AI 튜터, 정찰 보조, 코드 리뷰, 보고서 도우미는 강력하지만, 방심하면 단순히 복사/붙여넣기만 하는 사람이 될 수 있다. 스스로에게 이런 질문을 던져본다.
성장하고 있다는 신호는 이것이다. 버그 유형을 설명할 수 있고, 페이로드가 왜 작동하는지 말할 수 있으며, 스크립트의 작동 원리를 타인에게 논리적으로 설명할 수 있다.
멈춰 있다는 신호는 이것이다. AI가 준 결과를 이해하지 못한 채 복사해서 붙여넣기만 하고, 검수자가 거절했을 때 왜 틀렸는지 반박하지 못한다. 난이도 높은 버그를 만나면 성장이 정체되고, 실력이 아닌 AI 의존으로 버텨온 것이 드러난다.
방향은 하나다.
기본기로 해킹의 방향을 잡고, AI로 탐색의 속도를 높인다.
참고 리소스