침투 테스트를 사람이 하던 시대에는 "어디까지 찔러봐도 되는가"를 계약서로 정했습니다. 이제 AI 에이전트가 침투 테스트를 대신하는 시대가 되면서, 그 범위를 정하는 일이 콘솔의 설정 화면으로 들어왔습니다.

Amazon Web Services가 Security Agent의 침투 테스트에 생성형 AI 애플리케이션을 위한 별도 테스트 범위를 추가했습니다. 새로 나온 서비스가 아니라 기존 서비스의 기능 확장이고, 내용은 침투 테스트 생성 공식 문서에 반영돼 있습니다. 핵심은 하나입니다. 기존 웹 취약점 검사와 프롬프트 인젝션 같은 LLM 위험 검사를 구분해서 돌릴 수 있게 됐다는 것.

뭐가 추가됐나: 테스트 범위 두 가지

침투 테스트를 만들 때 고르는 Test scope 필드에 선택지가 생겼습니다.

Web application (기본값):
  웹·API 위험 전반을 보는 풀 침투 테스트
  AI 기능도 범위에는 들지만 주 검사 대상은 아님

Gen AI application:
  챗봇·에이전트 등 생성형 AI 기능의 LLM 위험에 집중
  앱의 LLM 연동 표면을 찾아 프롬프트 인젝션 검사

공식 문서의 정의도 짚고 넘어가겠습니다. 프롬프트 인젝션은 "모델이 자기 지시를 무시하고 의도하지 않은 동작을 하도록 만드는 crafted input"입니다. SQL 인젝션이 데이터베이스 쿼리 문법을 노린다면, 프롬프트 인젝션은 모델의 지시 체계를 노립니다. 공격 표면이 다르니 테스트 하네스도 달라야 한다는 게 이번 범위 분리의 논리입니다.

왜 가르는가: 웹 취약점과 LLM 위험은 다른 시험이다

같은 "침투 테스트"라는 이름 아래 있지만, 두 검사가 묻는 질문은 다릅니다.

구분 Web application 범위 Gen AI application 범위
묻는 질문 앱에 뚫린 구멍이 있는가 모델이 지시를 어기고 엉뚱한 일을 하는가
대표 위험 OWASP Top 10, SQLi·XSS·비즈니스 로직 결함 프롬프트 인젝션, 지시 무시·의도 밖 동작
공격 표면 URL·API·인증 경로 LLM 연동 표면(챗봇·에이전트·생성 기능)
페이로드 성격 취약점 증명용 최소 영향 페이로드 지시를 어기도록 유도하는 crafted input
위험 제외 설정 Exclude risk types로 카테고리 제외 가능 해당 제외 설정은 웹 범위에만 적용

마지막 줄이 실무에서 중요합니다. 문서에 따르면 위험 유형 제외(Exclude risk types)는 웹 애플리케이션 범위에만 적용됩니다. Gen AI 범위는 그 자체가 이미 "LLM 위험에 집중"이라는 필터라서, 제외 목록을 따로 두지 않는 구조입니다. 범위를 고르는 일이 곧 검사 정책을 고르는 일입니다.

전체 그림: 5단계 마법사에서 범위가 하는 일

범위 선택은 침투 테스트 생성 마법사의 맨 첫 단계에 있습니다. 전체 흐름을 그리면 이렇습니다.

① Penetration test details: 이름·테스트 범위·대상 URL·서비스 역할
② VPC Resources (선택): 비공개 대상의 네트워크 접근
③ Credentials (선택): 로그인 크리덴셜, 테스트로 사전 검증
④ Network configuration: 닿을 수 있는 도메인 전부 분류
⑤ Additional configuration: 앱 문맥·실행 옵션·위험 제외

4단계의 도메인 분류는 AI 앱 테스트에서 특히 신경 써야 합니다.

Target:     공격해도 되는 URL (검증된 도메인만 가능)
Accessible: 공격은 금지, 경유는 허용 (로그인 페이지·CDN 등 지원 서비스)
Out of scope: 접근 자체 금지 (파괴적 동작·민감 관리 기능)

챗봇이 로그인 뒤에서 동작한다면 인증 크리덴셜을 넣어주고, 로그인 페이지나 CDN은 Accessible로 두는 식입니다. 문서가 강조하는 전제 두 가지도 그대로 가져오세요. 검증된 도메인만 테스트할 것, 그리고 인증이 필요한 검사는 비프로덕션 환경에서 범위를 좁힌 크리덴셜로 할 것. AI 앱이라고 예외가 아닙니다.

운영에 붙이는 법: 예산·재검증과 함께 돌리기

범위 분리는 단독 기능이 아니라, 올해 여름에 붙은 운영 기능들과 함께 쓸 때 빛이 납니다.

비용 통제: Max task hours로 작업량 상한 (최소 20시간, 프리셋·직접 입력)
  → 상한에 닿으면 지금까지 찾은 finding은 보존하고 정상 종료
수정 확인: finding 단위 재검증 (전체 재실행 없이 해당 항목만 재테스트)
  → Active(여전함) / Resolved(수정 확인) 판정, 이력 연결

Gen AI 범위로 프롬프트 인젝션을 찾고, 수정한 뒤에는 해당 finding만 골라 재검증하는 흐름이 됩니다. 웹 취약점과 LLM 위험을 같은 테스트에 섞어 돌리면 "무엇을 고쳤고 무엇이 확인됐는지"가 흐려지는데, 범위를 나누면 수정-재검증 사이클이 깨끗해집니다.

CodeBridge Mini Lab: 허가 환경에서 회귀 세트로 검증하기

브리핑의 액션(허가받은 테스트 환경, 프롬프트 인젝션·권한 없는 도구 실행의 회귀 테스트)을 실험 형태로 바꿔보겠습니다.

① 허가 환경 마련:
   [ ] 테스트 대상 도메인 검증 완료 (검증 안 된 도메인은 공격 불가)
   [ ] 비프로덕션 환경 + 일반 사용자 수준 크리덴셜 (관리자 권한 금지)
   [ ] Out of scope 경로 지정 (파괴적 동작·민감 관리 기능)
② Gen AI 범위 테스트 설계:
   [ ] 직접 프롬프트 인젝션: 지시 무시·역할 전환 유도 입력
   [ ] 간접 프롬프트 인젝션: 문서·웹 내용에 숨은 지시 (RAG·검색 연동 시)
   [ ] 권한 없는 도구 실행: 모델이 허가 범위를 벗어난 호출을 하는가
③ 회귀 세트로 고정:
   [ ] 위 케이스를 저장해 모델·프롬프트 업데이트마다 반복 실행
   [ ] finding은 수정 후 재검증으로 Active/Resolved 판정
   [ ] Max task hours로 비용 상한 걸고 finding 보존 확인

이 표가 쌓이면 "우리 AI 앱의 보안 회귀 세트"가 됩니다. 모델이 바뀌고 프롬프트가 바뀌어도 같은 시험을 같은 범위로 반복할 수 있다는 게 범위 분리의 진짜 수확입니다.

결론: 테스트 범위를 고르는 일이 곧 보안 정책을 쓰는 일이다

한 줄로 정리합니다.

웹 구멍을 찌르는 시험과 모델의 지시를 흔드는 시험은 다른 시험이다. 섞지 말고 나눠서 돌려라.

AWS가 문서 한 절을 추가한 것처럼 보이는 이번 변화의 의미는 "AI 앱 보안이 별도 시험 과목이 됐다"는 선언에 가깝습니다. 웹 취약점 검사는 그대로 두되, LLM 위험은 Gen AI 범위로 분리해 프롬프트 인젝션을 정면으로 검사하는 것. 당장 할 일은 허가받은 비프로덕션 환경을 마련하고, 인젝션 케이스와 권한 밖 도구 실행 케이스를 회귀 세트로 묶는 일입니다. 그 세트가 다음 모델 업데이트 때 우리를 지켜줍니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

AI가 만든 결과를 검증 기준과 제약이 있는 흐름으로 통제하는 연습이 필요하다면, Claude Code로 프로젝트 규칙과 검증 환경을 정리하는 과정이 이 글의 회귀 테스트 설계와 바로 이어집니다.