AI 시대에 레드팀으로 살아남기

그 주장은 어쩌면 너무 방어적이다. “아직 AI는 이걸 못 한다”, “아직 사람의 직관이 필요하다”, “아직 현장 경험이 부족하다” 같은 말은 어느 정도 맞지만, 시간이 지나면 점점 약해질 수도 있다. 기술이 부족해서 사람이 필요하다는 논리는 기술이 좋아지는 순간 쉽게 무너진다.

그래서 이 글은 조금 다른 방향으로 쓰려 한다.

AI가 이미 잘하고 있는 부분, 앞으로 더 잘하게 될 부분, 그리고 그 상황에서 사람 레드팀이 어떤 위치를 잡아야 하는지를 정리해보려 한다. 내 기본적인 생각은 단순하다.

AI는 공격 과정을 대신 수행하는 측면에서 굉장히 빠른 속도로 따라올 것이다.

그러면 사람 레드팀은 AI Agent를 “해킹 실력이 매우 좋은 부사수”처럼 다루고, 조직의 실질적 보안 리스크와 비즈니스 로직을 이해하고 설계하는 쪽으로 이동해야 한다.

2. 이미 일어난 변화

먼저 인정할 건 인정해야 한다.

AI는 이미 취약점 발견과 공격 자동화 영역에 들어왔다. 아직 완벽하진 않지만, “가능성이 있다”는 단계는 지났다. 이제는 실제 사례와 벤치마크가 나오고 있다.

대표적인 사례가 Google Project Zero와 DeepMind의 Big Sleep이다. Big Sleep은 SQLite에서 이전에 알려지지 않았던 exploitable stack buffer underflow를 발견했고, Google Project Zero는 이를 ‘AI Agent가 널리 쓰이는 실제 소프트웨어에서 previously unknown exploitable memory-safety issue를 발견한 첫 공개 사례’로 설명했다.

DARPA AI Cyber Challenge도 흐름을 잘 보여준다. AIxCC 결승에서 참가 팀들의 Cyber Reasoning System은 5,400만 줄 이상의 코드에서 취약점을 찾고 패치 생성을 시도했다. DARPA 발표에 따르면 최종 라운드에서 시스템들은 63개 challenge에 포함된 synthetic vulnerability 중 54개를 발견했고, 그중 43개를 패치했다. 추가로 18개의 real, non-synthetic vulnerability도 발견했다.

웹 해킹 쪽도 비슷하다. XBOW는 104개의 현실적인 웹 보안 벤치마크에서 20년 이상 경력의 principal pentester와 같은 85% 성공률을 기록했고, 사람에게 주어진 시간이 40시간이었던 반면 XBOW는 28분 만에 같은 세트를 수행했다고 공개했다. 물론 벤더가 공개한 자체 실험이라 그대로 일반화하긴 어렵다. 그럼에도 방향성은 분명하다. 반복 가능한 공격 실행의 비용은 빠르게 내려가고 있다.

Xint도 유사한 흐름에 있다. Xint는 애플리케이션을 실제 사용자처럼 탐색해 숨은 attack surface와 API를 찾고, 사용자 권한과 데이터 흐름을 분석해 authorization bypass와 logical vulnerability를 탐지한다고 설명한다. 특히 context-aware testing, Proof of Vulnerability, attack path 기반 보고를 강조한다는 점에서 기존 DAST의 한계를 AI 기반 탐색으로 확장하려는 방향에 가깝다.

이 사례들을 보면 대략적인 방향은 보인다.

취약점 발견 → 재현 → 패치 제안 → 재검증의 흐름은 앞으로 더 자동화될 것이다. 예전에는 사람이 일일이 인풋 포인트를 찾고, 요청을 변형하고, 페이로드를 바꾸고, PoC를 다듬었다면, 그런 반복 작업의 상당 부분이 점점 Agent로 넘어갈 가능성이 높다.

이 변화가 공격자에게만 유리한 것도 아니다. 방어팀도 같은 흐름을 활용할 수 있다. Big Sleep처럼 릴리스 전에 취약점을 찾고 패치하거나, AIxCC처럼 취약점 발견과 패치를 한 세트로 묶는 접근은 방어 측에도 분명한 장점이 있다.

결국 취약점 발견은 점점 “희소한 이벤트”가 아니라 “상시 운영 프로세스”에 가까워질 가능성이 높다.

발견
  ↓
재현
  ↓
티켓 생성
  ↓
패치 제안
  ↓
재검증
Plain Text
복사

이 워크플로가 더 빨라지고, 더 자주 돌고, 더 많은 결과를 만들어내는 방향으로 갈 것이다.

3. AI는 “공격 실행”을 빠르게 따라올 것이다

나는 앞으로 AI가 공격 과정의 많은 부분을 빠르게 따라올 것이라고 본다.

특히 정찰, 엔드포인트 식별, 파라미터 변조, 인증 상태 비교, 페이로드 생성, 취약점 재현, 로그 정리, 보고서 초안 작성 같은 영역은 그렇다. 이미 지금도 모델과 Agent를 잘 엮으면, 사람이 하던 반복 작업의 상당 부분을 맡길 수 있다.

Anthropic의 2026년 분석도 비슷한 방향을 보여준다. Anthropic은 2025년 3월부터 2026년 3월까지 악성 사이버 활동으로 차단한 832개 계정을 분석했고, 공격자들이 AI를 단순한 초기 접근보다 계정 탐색, lateral movement, privilege escalation 같은 더 복잡하고 후반부의 공격 단계에 활용하는 흐름을 관찰했다고 설명했다.

이건 꽤 중요한 변화다.

예전에는 AI를 보안에 쓴다고 하면, 피싱 메일을 더 그럴듯하게 쓰거나 악성코드 일부를 생성하거나 취약점 설명을 요약하는 정도를 떠올렸다. 그런데 이제는 공격 체인의 여러 단계를 이어 붙이고, 상황에 따라 다음 행동을 결정하는 쪽으로 가고 있다.

물론 아직 완성도가 들쭉날쭉하고, 실제 운영 환경에서는 오탐과 누락도 많을 것이다. 하지만 방향은 명확하다. 공격 실행을 이루는 단위 작업은 점점 자동화된다.

그래서 나는 AI Agent를 “대체자”라고 부르기보다, 해킹 실력이 매우 좋은 부사수라고 보는 편이 더 현실적이라고 생각한다.

좋은 부사수가 들어오면 사수의 역할은 달라진다. 사수가 모든 요청을 직접 날릴 필요는 없다. 대신 무엇을 봐야 하는지, 어디까지 가야 하는지, 어떤 증적이 의미 있는지, 어떤 결과를 버려야 하는지를 판단해야 한다.

AI 시대의 레드팀도 비슷할 것이다.

4. “Can I?”보다 “Should I?”가 중요해진다

AI가 공격 실행을 빠르게 따라온다면, 사람은 무엇을 해야 할까.

나는 이 질문을 이렇게 바꿔야 한다고 본다.

“할 수 있는가?”보다 “할 수 있어야 하는가?”를 봐야 한다.

전통적인 취약점 검증은 대체로 “Can I?”에 가깝다.

이 파라미터로 다른 사용자의 데이터를 볼 수 있는가.

이 입력값으로 SQL Query를 조작할 수 있는가.

이 토큰으로 관리자 API를 호출할 수 있는가.

이 SSRF로 내부 메타데이터에 접근할 수 있는가.

반면 비즈니스 로직과 권한 모델 검증은 “Should I?”에 가깝다.

이 사용자가 이 주문을 취소할 수 있어야 하는가.

이 판매자가 이 정산 정보를 볼 수 있어야 하는가.

이 CS 계정이 전체 고객의 개인정보를 내려받을 수 있어야 하는가.

이 외부 파트너가 내부 운영 상태를 바꿀 수 있어야 하는가.

이 AI Agent가 이 Tool을 호출할 수 있어야 하는가.

XBOW의 IDOR 관련 글도 이 차이를 잘 짚는다. 전통적인 DAST는 유효한 세션 토큰, 정상적인 요청 구조, 200 OK 응답만 보면 통과로 판단하기 쉽지만, 실제 authorization flaw는 “이 사용자가 이 리소스를 볼 수 있어야 하는가”라는 소유권과 맥락의 문제라고 설명한다.

개인적으로 앞으로 사람 레드팀이 집중해야 할 지점이 여기에 있다고 본다.

AI는 “Can I?”를 빠르게 시도할 것이다.

사람은 “Should I?”를 설계해야 한다.

이 서비스에서 정상적인 돈의 흐름은 무엇인가.

정상적인 권한 위임은 어디까지인가.

정상적인 배포 승인은 어떤 단계를 거쳐야 하는가.

정상적인 고객 데이터 접근은 어떤 업무 맥락에서만 가능한가.

정상적인 AI Agent의 Tool 호출 범위는 어디까지인가.

이건 단순히 요청을 많이 날린다고 해결되는 문제가 아니다. 제품 구조, 권한 모델, 조직의 운영 방식, 데이터의 의미, 비즈니스 영향을 함께 봐야 한다.

5. 레드팀은 공격 실행자에서 리스크 설계자로 이동해야 한다

예전에는 레드팀의 실력이 종종 이런 방식으로 평가됐다.

얼마나 잘 뚫는가.

얼마나 깊게 들어가는가.

얼마나 조용히 움직이는가.

얼마나 좋은 익스플로잇을 쓰는가.

얼마나 예상 밖의 경로를 찾는가.

이 기준은 여전히 유효하다. 나도 기본기는 계속 중요하다고 생각한다. 직접 뚫어본 사람만이 AI가 내놓은 결과가 맞는지 판단할 수 있다. 기본적인 웹, 시스템, 네트워크, 클라우드, AD, IAM 지식 없이 Agent를 쓰면, 그냥 빠른 오탐 생성기가 될 가능성이 높다.

다만 앞으로는 그 위에 다른 능력이 더 중요해질 것이다.

무엇을 공격해야 하는지 정하는 능력.

어떤 공격 경로가 조직에 실제 피해를 주는지 판단하는 능력.

비즈니스 로직이 깨지는 지점을 찾아내는 능력.

기술적 가능성을 조직의 리스크 언어로 번역하는 능력.

예를 들어 같은 IDOR라도 서비스마다 의미가 다르다.

프로필 사진 URL 하나가 노출되는 IDOR과, 외부 파트너가 다른 파트너사의 정산 데이터를 볼 수 있는 IDOR은 다르다. 둘 다 접근제어 문제지만, 후자는 신뢰 모델과 비즈니스 운영 전체에 영향을 준다.

같은 SSRF라도 의미가 다르다.

내부 헬스체크 엔드포인트 하나를 호출할 수 있는 SSRF와, 클라우드 메타데이터를 통해 배포 Role을 탈취하고 고객 데이터에 접근할 수 있는 SSRF는 다르다.

같은 관리자 기능 노출이라도 의미가 다르다.

테스트용 배너를 바꿀 수 있는 관리자 기능과, 환불 승인·정산 확정·배송 상태 변경을 조작할 수 있는 관리자 기능은 다르다.

결국 중요한 건 취약점명이 아니다.

이 문제가 어떤 업무 흐름을 깨는가.

어떤 자산으로 이어지는가.

어떤 의사결정 권한을 우회하는가.

실제 사고가 났을 때 조직이 어떤 피해를 입는가.

이걸 설계하고 검증하는 사람이 필요하다.

그래서 나는 앞으로의 레드팀을 단순한 “공격 실행자”보다 리스크 설계자에 가깝게 봐야 한다고 생각한다.

조금 거창하게 들릴 수 있지만, 말하고 싶은 건 단순하다.

취약점을 찾는 것보다, 조직이 실제로 망가지는 방식을 설계하고 증명하는 일이 더 중요해진다.

6. AI Agent에게 일을 잘 시키는 능력

AI를 잘 쓰는 레드팀은 단순히 “이 사이트 털어봐”라고 시키지 않을 것이다.

그렇게 시켜도 어느 정도 결과는 나오겠지만, 그건 빠른 스캐너를 하나 더 쓰는 것에 가깝다. 정말 중요한 건 Agent에게 더 좋은 문제를 주는 것이다.

예를 들면 이런 식이다.

이 커머스 서비스에서 쿠폰, 포인트, 환불, 부분 취소, 배송 상태 변경이 서로 어떻게 영향을 주는지 정리해라.

관리자, 판매자, CS 담당자, 외부 파트너 계정으로 각각 로그인했을 때 접근 가능한 주문 데이터의 차이를 비교해라.

정산 상태가 확정된 이후에도 금액에 영향을 줄 수 있는 API가 있는지 찾아라.

GitHub Organization, CI/CD, Cloud IAM 사이에서 프로덕션 배포 권한으로 이어지는 경로를 정리해라.

이 AI Agent가 사용할 수 있는 Tool 목록을 기준으로, 사용자가 직접 접근할 수 없는 데이터에 Agent를 통해 접근할 수 있는지 확인해라.

패치 후에도 동일한 비즈니스 영향이 다른 경로로 가능한지 재검증해라.
Plain Text
복사

이런 지시를 하려면 사람이 먼저 서비스를 이해해야 한다. 기술 스택만 보는 게 아니라, 돈이 어떻게 움직이는지, 권한이 어떻게 위임되는지, 고객 데이터가 어디서 생성되고 어디로 흘러가는지, 어떤 액션이 운영팀의 승인 없이 일어나면 안 되는지까지 알아야 한다.

HackerOne은 AI Red Teaming을 “human-led, agent-driven” 테스트로 설명하면서, Agent가 프롬프트·RAG 파이프라인·Tool 권한·Agent workflow를 체계적으로 테스트하고, 사람 연구자는 판단과 창의성을 제공한다고 말한다. 이 표현은 일반적인 레드팀에도 꽤 잘 맞는다.

사람이 방향을 잡고, Agent가 실행한다.

사람이 목표를 정하고, Agent가 탐색한다.

사람이 의미를 판단하고, Agent가 증적을 쌓는다.

이게 내가 생각하는 현실적인 협업 구조다.

HackerOne의 exposure management 관련 글도 비슷한 방향을 말한다. 전통적인 자동화는 많은 결과를 만들지만 판단과 맥락이 부족하고, Agentic AI는 노이즈를 줄이고 우선순위를 드러내며 취약점 데이터를 맥락 있는 정보로 구조화한다고 설명한다. 중요한 건 여기서도 “human expertise amplified by AI”라는 관점이다.

결국 AI를 잘 쓰는 레드팀은 손이 더 빨라지는 팀이 아니다.

더 넓은 문제를 더 깊게 쪼개서 Agent에게 나눠줄 수 있는 팀이다.

7. 앞으로 사람이 봐야 할 것들

그렇다면 사람 레드팀은 구체적으로 무엇을 봐야 할까.

나는 크게 네 가지라고 본다.

7.1. Critical Asset 정의

첫 번째는 중요한 자산을 정의하는 일이다.

전통적인 침투 테스트에서는 Domain Admin이나 서버 장악이 상징적인 목표가 되는 경우가 많았다. 물론 여전히 중요하다. 하지만 모든 조직에서 Domain Admin이 최종 리스크는 아니다.

커머스에서는 정산, 환불, 쿠폰, 포인트가 더 중요할 수 있다.

SaaS에서는 테넌트 격리와 고객 데이터 접근이 더 중요할 수 있다.

핀테크에서는 거래 승인과 계좌 연결 흐름이 더 중요할 수 있다.

AI 서비스에서는 Agent의 Tool 권한과 RAG 데이터 접근 범위가 더 중요할 수 있다.

개발 조직에서는 GitHub, CI/CD, Cloud Role이 더 중요할 수 있다.

첫 질문은 이거여야 한다.

무엇을 장악하면 이 조직에 실제 피해가 발생하는가?

이 질문 없이 취약점을 찾으면 결과는 많아도 방향은 흐려진다.

7.2. 비즈니스 로직 이해

두 번째는 비즈니스 로직이다.

비즈니스 로직 취약점은 단순히 “특이한 버그”가 아니다. 조직이 돈을 벌고, 고객을 관리하고, 권한을 위임하고, 데이터를 처리하는 방식이 깨지는 지점이다.

자동화 도구가 점점 더 잘 도와줄 수는 있어도, 처음부터 완전히 이해하기는 어렵다. 이유는 간단하다. 비즈니스 로직은 코드에만 있지 않기 때문이다.

정책 문서에 있고, 운영팀의 관행에 있고, CS 매뉴얼에 있고, 관리자 화면의 암묵적인 사용 방식에 있고, 조직의 책임 경계에 있다.

그래서 사람 레드팀은 개발자처럼 코드를 보고, 기획자처럼 흐름을 보고, 공격자처럼 우회 경로를 봐야 한다.

7.3. 공격 경로 설계

세 번째는 공격 경로 설계다.

앞으로는 취약점 하나보다 “경로”가 더 중요해질 수 있다. 단일 취약점은 낮은 위험처럼 보이지만, 여러 정상 기능과 약한 통제가 연결되면 실제 침해 경로가 된다.

예를 들어 이런 흐름이다.

외부 파트너 계정
  ↓
주문 조회 권한
  ↓
다른 파트너 주문 ID 추측
  ↓
정산 데이터 조회
  ↓
환불 상태 변경 API 접근
  ↓
금액 조작 가능성
Plain Text
복사

여기에는 화려한 익스플로잇이 없을 수 있다. CVE도 없을 수 있다. 하지만 조직 입장에서는 훨씬 더 중요한 리스크다.

AI Agent는 이런 경로의 후보를 많이 찾아줄 것이다. 하지만 어떤 경로가 실제로 의미 있는지, 어떤 단계가 현실적인지, 어떤 증적이 충분한지는 사람이 판단해야 한다.

7.4. 리스크 커뮤니케이션

마지막은 커뮤니케이션이다.

보고서는 앞으로 더 중요해질 것이다. 단, 취약점 개수를 늘리는 방식의 보고서가 아니라 조직의 의사결정에 영향을 주는 보고서여야 한다.

예를 들어 이런 문장은 약하다.

IDOR 취약점이 발견되었습니다.

반면 이런 문장은 다르다.

외부 파트너 계정이 주문 ID를 변조해 타 파트너사의 정산 데이터를 조회할 수 있으며, 이 데이터에는 환불 금액, 고객 식별자, 내부 정산 상태가 포함됩니다. 이 문제는 단순한 접근제어 누락이 아니라 파트너 정산 신뢰 모델 전체에 영향을 줍니다.

첫 번째는 취약점 보고다.

두 번째는 리스크 설명이다.

AI가 보고서 초안을 더 잘 쓰게 될수록, 사람은 문장 작성보다 판단에 집중해야 한다. 어떤 결과가 중요한지, 어떤 표현이 조직을 움직일 수 있는지, 어떤 권고가 현실적인지 정해야 한다.

8. 내가 생각하는 레드팀의 스탠스

그래서 앞으로 레드팀은 어떤 스탠스를 취해야 할까.

나는 이렇게 생각한다.

AI를 부정할 필요는 없다.

AI를 과소평가할 필요도 없다.

그렇다고 AI가 못하는 것만 찾아 위안을 삼을 필요도 없다.

AI Agent는 해킹 실력이 매우 좋은 부사수다. 이 부사수는 빠르고, 많이 보고, 지치지 않고, 점점 더 똑똑해질 것이다. 그러면 사수는 더 높은 수준의 문제를 잡아야 한다.

사람 레드팀은 앞으로 이런 능력을 가져야 한다.

조직의 핵심 자산을 정의하는 능력
제품과 비즈니스 로직을 이해하는 능력
권한 모델과 신뢰 관계를 해석하는 능력
AI Agent에게 좋은 문제를 주는 능력
공격 경로를 설계하고 검증하는 능력
기술적 결과를 비즈니스 리스크로 번역하는 능력
현실적인 개선 우선순위를 제시하는 능력
Plain Text
복사

여기서 중요한 건 “기술을 버리자”가 아니다.

오히려 반대다. 기본기가 더 중요해질 수 있다. AI가 내놓은 결과가 맞는지 판단하려면 직접 해본 경험이 있어야 한다. 잘못된 PoC, 과장된 영향도, 의미 없는 공격 경로를 걸러내려면 해킹을 알아야 한다.

다만 손으로 모든 걸 직접 하는 사람이 아니라, AI를 이용해 더 넓고 복잡한 리스크를 검증하는 사람이 되어야 한다.

AI Agent가 수십 개의 후보 경로를 찾는다.
사람 레드팀이 그중 실제 리스크가 있는 경로를 고른다.
Agent가 증적을 모으고 재현을 자동화한다.
사람 레드팀이 비즈니스 영향을 해석한다.
Agent가 보고서 초안을 만든다.
사람 레드팀이 조직이 움직일 수 있는 언어로 다시 쓴다.
Plain Text
복사

이 구조에서는 AI가 사람을 단순히 대체한다기보다, 사람의 역할을 위로 밀어 올린다.

손은 Agent가 빌려준다.

머리는 사람이 더 잘 써야 한다.

9. 마치며

AI 시대에 레드팀이 사라질지 남을지 묻는 질문은 너무 단순하다.

내가 더 관심 있는 질문은 이것이다.

AI Agent가 공격 실행을 맡을 수 있다면, 사람 레드팀은 무엇을 설계해야 하는가?

사람 레드팀은 AI보다 손이 빨라지려고 애쓸 필요가 없다. 대신 AI에게 일을 잘 시킬 수 있어야 한다. 그리고 AI가 찾아낸 수많은 가능성 중에서 조직의 실제 리스크를 골라낼 수 있어야 한다.

전통적인 취약점 발견과 패치의 워크플로는 앞으로 더 자동화되고 견고해질 것이다. 그건 좋은 일이다. 반복 가능한 취약점은 더 빨리 발견되고, 더 빨리 수정되어야 한다.

그다음에 남는 영역이 사람 레드팀의 영역이다.

정상 기능이 어떻게 공격 경로가 되는지 보는 일.

비즈니스 로직이 어디서 깨지는지 증명하는 일.

조직이 정말로 두려워해야 할 시나리오를 설계하는 일.

그리고 그 시나리오를 AI Agent와 함께 더 빠르고 깊게 검증하는 일.

나는 그 방향이 더 현실적이라고 본다.

참고

•

Google Project Zero, From Naptime to Big Sleep

•

DARPA, AI Cyber Challenge marks pivotal inflection point for cyber defense

•

XBOW, XBOW now matches the capabilities of a top human pentester

•

XBOW, Getting to “Should I?”, Instead of “Can I?”

•

Theori, Xint Product Page

•

Anthropic, What we learned mapping a year’s worth of AI-enabled cyber threats 

•

HackerOne, H1 AI Red Teaming 

•

HackerOne, Agentic AI: The Future of Exposure Management