OWASP GenAI 레드 팀 매뉴얼, 모델을 넘어선 테스트로 범위 확대
OWASP는 10월 20일 GenAI 레드 팀 매뉴얼을 공개하며, 모델 응답을 넘어 연결된 애플리케이션과 에이전트까지 포괄하는 8개 테스트 단계를 소개했다. 버전 1.0 릴리스는 생성된 콘텐츠와 데이터 접근 및 실행 기능을 결합한 시스템 전반의 보안, 안전성, 장애 저항성을 다룬다. 핵심 메시지는 분명하다. 모델만 평가해서는 그 모델을 둘러싸고 구축된 제품에 관한 질문에 답할 수 없다.
OWASP GenAI 레드 팀 매뉴얼은 모델의 안전성 결과를 전체 배포 환경의 증거로 간주하는 익숙한 검증 방식에 문제를 제기한다. 레드 팀은 실패 지점을 찾아내기 위해 공격자의 관점을 취하는 승인된 테스트를 뜻한다. 연결형 AI 제품에서는 부적절한 답변이 아니라 무단 실행이 중대한 실패가 될 수 있다.
OWASP는 이미 2025년 1월 관련 가이드를 공개했으므로, 이번 릴리스가 AI 레드 팀을 처음부터 새로 도입한 것은 아니다. 10월 매뉴얼은 보다 상세한 운영 기준을 제공한다. 개발자와 엔터프라이즈 구매자에게 이 자료가 중요한 이유는 발견된 약점을 재현 가능한 증거, 비즈니스 영향, 검증된 수정 조치와 연결하기 때문이다. 여기에는 까다로운 균형이 따른다. 폭넓은 테스트는 더 유용한 검증을 제공하지만, 챗봇 데모만으로는 확보할 수 없는 접근 권한, 조율, 엔지니어링 시간이 필요하다.
OWASP GenAI 레드 팀 매뉴얼이 추가한 내용
이번 릴리스는 또 하나의 고립된 적대적 프롬프트 모음이 아니라 팀이 공유할 수 있는 참여 구조를 제공한다.
OWASP는 계획 수립, 정찰, 공격 표면 매핑, 익스플로잇, 지속성 확보, 영향 평가, 보고, 개선 조치에 이르는 프로세스를 설명한다. 명시된 범위에는 모델, 애플리케이션, 에이전트, 그리고 텍스트·이미지·오디오 등의 형식을 입력받거나 생성하는 멀티모달 인터페이스가 포함된다. 리소스 페이지는 윤리적 테스트, 측정 가능한 결과, 방어 운영과의 통합도 강조한다.
이처럼 폭넓은 범위는 중요하다. AI 실패에는 대개 편리한 조직상 분류가 붙어 있지 않기 때문이다. 유해한 응답은 모델 동작, 애플리케이션 지침, 검색된 자료 또는 연결된 서비스에서 비롯될 수 있다. 각 구성 요소는 서로 다른 팀이 관리한다. 공유 프로세스는 책임이 각 구성 요소의 경계에서 끝난다고 가정하지 않고, 이들이 같은 사건을 함께 조사할 수 있게 한다.
역사적 구분도 중요하다. OWASP의 이전 레드 팀 가이드는 이미 통합 취약점 및 지속적인 모니터링과 함께 모델 취약성을 평가할 것을 권고했다. 따라서 10월 발행물은 해당 접근법의 지속적인 발전을 의미한다. 이를 OWASP가 애플리케이션 위험을 처음 인정한 사례라고 부르는 것은 기록을 잘못 전달하는 일이다.
새 릴리스는 독자가 “테스트됨”이라는 표현에 기대해야 할 내용도 바꾼다. 한 조직은 문서 커넥터를 전혀 건드리지 않은 채 모델을 테스트했다고 사실대로 말할 수 있다. 다른 조직은 실행 기능을 수행하는 서비스를 제외한 채 애플리케이션 인터페이스를 테스트할 수 있다. 두 경우 모두 같은 보안 범주 아래에 놓이더라도, 서로 다른 범위를 설명한다.
공통 참여 구조는 이러한 차이를 드러내는 데 도움이 된다. 구매자는 테스트가 무엇을 다뤘는지, 테스터에게 어떤 접근 권한이 주어졌는지, 무엇이 범위 밖에 남았는지를 검토하도록 유도한다. 분석적 가치는 더 높은 구체성에서 나온다. 익숙한 프레임워크 이름은 이러한 답변을 대신할 수 없다.
프로젝트 파일을 읽고 고객 커뮤니케이션 초안을 작성하는 가상의 엔터프라이즈 어시스턴트를 생각해 보자. 글쓰기 품질을 평가하는 것만으로는 파일 권한을 준수하는지 거의 알 수 없다. 파일 접근을 평가하는 것만으로는 이후의 커뮤니케이션이 무단 수신자에게 자료를 노출하는지 알 수 없다. 제품은 이러한 동작을 결합하므로, 평가는 그 관계를 설명해야 한다.
매뉴얼의 공개가 조직들이 이미 이 접근법을 따른다는 사실을 입증하지는 않는다. 이는 그들의 주장을 검토할 수 있는 기준을 제공한다. 도입 여부, 구현 품질, 보안 결과는 여전히 별개의 문제다.
이 구분은 이번 릴리스를 적절한 관점에서 보게 한다. OWASP는 더 엄격한 테스트를 지원하는 지침을 공개했다. 이것이 배포된 제품을 개선하는지는 팀이 해당 지침을 접근 권한, 출시 준비 상태, 개선 조치에 관한 결정으로 어떻게 전환하는지에 달려 있다.
엔터프라이즈 구매자는 통합 위험을 함께 떠안는다
AI 모델을 비즈니스 시스템에 연결하는 조직은 그 연결에 따른 권한과 결과에 계속 책임을 진다.
모델 제공업체와 애플리케이션 개발자는 서로 다른 보안 질문에 답한다. 제공업체는 이용 가능한 테스트 환경에서의 동작을 평가한다. 개발자는 모델을 둘러싼 문서, 신원, 서비스, 실행 기능을 선택한다. 엔터프라이즈 배포는 구성, 계정 권한, 조직별 데이터를 통해 또 다른 계층을 추가한다.
이것은 실질적인 조달 문제를 만든다. 구매자는 방대한 모델 문서를 받을 수 있지만, 직원이 실제로 사용할 정확한 워크플로에 대해서는 거의 알지 못할 수 있다. 생성된 응답에 대한 긍정적 평가는 어시스턴트가 고객 계정을 분리하는지 또는 커넥터의 권한을 제한하는지를 입증하지 않는다. 이러한 특성은 배포된 애플리케이션에 달려 있다.
OWASP의 별도 애플리케이션 보안 테스트 지침은 이 구분을 뒷받침한다. 이 지침은 모델, 검색, 도구, 권한을 결합된 테스트 표면으로 다룬다. 또한 에이전트가 연결된 도구를 사용할 수 있는 경우, 입력에 삽입된 악의적 지침인 프롬프트 인젝션을 잠재적 권한 부여 문제로 규정한다.
따라서 부담은 여러 집단에 돌아간다. 제품 팀은 테스트가 가능할 만큼 허용된 동작을 정확히 설명해야 한다. 보안 팀은 배포된 구성에 접근해야 한다. 조달 팀은 제외 항목을 설명하는 보고서를 필요로 한다. 비즈니스 책임자는 남은 위험 가운데 어떤 것이 기능의 보류 또는 제한을 정당화하는지 결정해야 한다.
가상의 고객 지원 어시스턴트는 이 구분을 명확히 보여 준다. 모델은 직접 대화에서 개인정보 요청을 올바르게 거부할 수 있다. 그러나 주변 애플리케이션은 여전히 잘못된 고객의 기록을 검색할 수 있다. 모델의 거부 동작과 애플리케이션의 계정 분리는 서로 다른 증거를 필요로 한다.
내부 지식 시스템에서도 같은 문제가 발생한다. 어시스턴트는 문서를 정확히 요약할 수 있지만, 원본에 접근 권한이 없는 사람에게 그 요약을 제공할 수 있다. 정확성은 유용성을 높이지만 권한 부여 문제를 해결하지는 않는다. 다듬어진 응답은 근본적인 접근 오류를 감출 수 있다.
검색 가능한 지식 베이스를 구축하는 팀이라면, 핵심 질문은 올바른 정보를 찾는 데서 끝나지 않는다. 사람이 해당 정보를 검색하고 재사용할 수 있는 조건을 보존하는 일도 포함한다. AI를 추가하면 그러한 경계가 작동하는 인터페이스가 바뀐다.
이 분석은 모든 배포에 동일한 수준의 테스트 깊이가 필요하다는 의미는 아니다. 공개 정보로 제한된 도구는 비즈니스 기록을 변경할 권한을 가진 에이전트와 다른 결과를 초래한다. 결정은 애플리케이션의 실제 권한과 노출 수준을 따라야 한다.
상업적 의미는 일반적인 보안 강화 요구보다 더 구체적이다. 공급업체는 통합 경계를 문서화해야 한다는 압박을 받는다. 구매자는 더 넓은 접근 권한을 부여하기 전에 그 문서를 요청해야 한다는 압박을 받는다. 어느 쪽도 모델 벤치마크만으로 이 문제를 해결할 수 없다.
연결된 에이전트는 응답을 결과로 바꾼다
에이전트의 보안은 주변 소프트웨어가 생성된 결정을 통해 무엇을 하도록 허용하는지에 달려 있다.
AI 에이전트는 모델 출력을 사용해 연결된 도구를 통해 실행할 행동을 선택하고 수행하는 소프트웨어다. 이로 인해 중대한 전환이 일어난다. 그렇지 않았다면 단순 제안으로 남을 텍스트가 정보를 전송하거나, 기록을 수정하거나, 다른 서비스를 호출하는 요청이 될 수 있다.
144페이지 분량의 매뉴얼은 모델 프로브를 검색, 신원, 권한 부여, 도구와 연결한다. 내용에는 공격자의 영향력이 즉각적인 상호작용 이후에도 지속되는 지속성도 포함된다. 이러한 주제는 평가 범위를 개별 출력에서 시간에 따라 작동하는 연결 시스템의 행동으로 확장한다.
다음 사례는 보고된 사고가 아니라 설명을 위한 예시다. 외부에서 제공된 문서를 검토하는 연구 어시스턴트를 상상해 보자. 해당 문서에는 관련 없는 내부 자료를 공개하라고 어시스턴트에게 요청하는 지침이 포함되어 있다. 문서를 읽는 일은 정당하다. 그러나 그 지침을 다른 정보에 접근하고 전송할 권한으로 취급하는 것은 다른 경계를 넘는 일이다.
이 차이는 응답 필터링만으로는 불완전한 그림을 제공하는 이유를 설명한다. 최종 답변은 무해해 보일 수 있지만, 어시스턴트가 그 이전에 무단 행동을 시도했을 수 있다. 반대로 생성된 요청은 위험해 보일 수 있지만 연결된 서비스가 이를 올바르게 차단했을 수 있다. 행동과 그 결과를 관찰하면 평가가 달라진다.
이는 시도된 행동과 실제로 완료된 피해를 구분하는 데 유용하다. 평가자는 의심스러운 모든 문구를 성공적인 침해로 취급해서는 안 된다. 마찬가지로 깔끔한 최종 응답이 연결된 서비스가 부적절한 요청을 실행했다는 증거를 지워서도 안 된다. 제품의 실제 동작이 결과를 결정한다.
지속성은 또 다른 복잡성을 더한다. 가상의 어시스턴트가 공격자의 영향을 받은 선호 설정을 저장하고 이후 작업에서 이를 사용한다고 가정해 보자. 해결된 것처럼 보이는 대화도 미래의 행동을 바꾸는 상태를 남길 수 있다. 원래의 교환만 평가하면 이러한 지속적인 영향을 놓치게 된다.
더 넓은 시스템은 성공적인 방어의 의미도 바꾼다. 모델이 악의적인 지침을 따르더라도 권한 확인이 접근을 차단한다면, 애플리케이션은 그 시도된 행동을 억제한 것이다. 결과는 여전히 조사할 가치가 있지만, 실제 정보 공개와는 다르다. 보고서는 이 구분을 보존해야 한다.
제품이 유용한 기능을 갖출수록 균형은 더 뚜렷해진다. 읽기 전용 접근은 더 제한된 작업을 지원한다. 기록 수정 권한은 더 폭넓은 자동화를 가능하게 하는 동시에 잘못된 지침의 결과도 키운다. 테스트는 제품의 가치를 만드는 기능을 반영해야 한다.
이는 에이전트가 본질적으로 비즈니스 사용에 부적합하다는 사실을 입증하지 않는다. 권한이 자체적인 증거를 필요로 하는 이유를 보여 줄 뿐이다. 관련 비교는 에이전트가 시도할 수 있는 것, 주변 서비스가 허용하는 것, 사용자가 의도한 것 사이에서 이루어진다.
OWASP GenAI 레드 팀 매뉴얼은 이러한 결합된 관점을 명시한다. 실질적 의미는 모델 응답이 이미 받고 있는 것과 같은 수준의 검토를 애플리케이션 동작에도 적용한다는 데 있다.
공유 방법론은 증거 문제에 직면한다
구조화된 평가는 질문의 질을 높이지만, 그 결론은 여전히 테스트, 환경, 그리고 이를 뒷받침하는 증거에 의해 제한된다.
기여자들의 지원은 왜 공통 방법론이 실무자들에게 호응을 얻는지 설명하는 데 도움이 된다. NeuralTrust의 기여자 계정은 2026년 7월 1일자로 공개 의견 수렴 버전에 참여했다고 설명한다. 이 회사는 반복 가능한 참여 방식이 단절된 공격 기법보다 개선된 접근이라고 제시한다. 이는 참여자의 관점일 뿐, 사고 감소를 입증하는 독립적 증거는 아니다.
연표 역시 신중하게 다뤄야 한다. NeuralTrust는 OWASP가 10월에 리소스 페이지를 공개하기 전에 공개 의견 수렴용 매뉴얼을 논의했다. 독자는 이전 초안 활동과 현재 공식 릴리스에 붙은 날짜를 구분해야 한다. 어느 날짜도 특정 조직이 이 방법론을 채택한 시점을 입증하지는 않는다.
회의적인 질문은 구현에 관한 것이다. 보고서는 일관된 제목 구조를 사용할 수 있지만, 부실한 실험을 기록할 수도 있다. 긴 평가도 가장 중대한 도구를 누락할 수 있다. 테스트 환경은 외관상 프로덕션과 비슷해 보여도 서로 다른 권한을 사용할 수 있다. 형식적 구조는 이러한 한계를 설명하기 쉽게 만들지만, 자동으로 없애지는 않는다.
측정에도 과제가 있다. 테스트 결과는 무엇을 성공 또는 실패로 간주하는지에 따라 달라진다. 어시스턴트가 기밀 정보를 언급하는 것은 이를 검색하거나, 표시하거나, 외부로 전송하는 것과 다르다. 이러한 사건을 모호한 “유출”이라는 범주로 묶으면 결과를 해석하기 까다로워진다.
제품 간 비교도 같은 문제에 직면한다. 광범위한 권한을 가진 시스템은 엄격하게 제한된 어시스턴트보다 더 중대한 실패 경로를 드러낼 수 있다. 성공한 공격의 단순 건수는 제품들이 비교 가능한 작업, 접근 권한 또는 조건에 놓였는지 설명하지 못한다. 범위는 결과와 함께 제시되어야 한다.
자동화된 테스트는 또 다른 불확실성의 원천을 만든다. 한 모델의 행동을 판단하는 데 사용되는 모델은 작업을 오해하거나 결과를 잘못 분류할 수 있다. 그렇다고 자동화된 평가가 쓸모없다는 뜻은 아니다. 특히 결과가 출시 결정에 영향을 미칠 때 판단 과정 자체를 면밀히 검토해야 한다는 의미다.
보안과 유용성의 구분도 여기서 중요하다. 모든 요청을 거부하는 어시스턴트는 오용에 강한 것처럼 보일 수 있지만, 본래 맡은 일을 수행하지 못할 수 있다. 의미 있는 평가는 정당한 작업 수행 능력과 함께, 어시스턴트가 지켜야 할 경계를 보존해야 한다. 그렇지 않으면 겉보기 개선이 기능 상실을 가릴 수 있다.
이는 매뉴얼이 실패했다는 증거가 아니라 분석적 한계다. 어떤 방법론도 범위가 제한된 실험을 모든 미래 상호작용에 대한 증명으로 바꿀 수는 없다. 방어 가능한 결론은 테스트된 조건, 관찰된 결과, 남은 불확실성을 식별한다.
따라서 이 출판물은 포괄적 보증을 부추기지 않으면서 증거에 대한 기대를 높여야 한다. “OWASP 지침에 따라 평가됨”은 접근 방식을 설명한다. 구매자는 평가 중 어떤 일이 있었는지, 어떤 발견 사항에 대해 검증된 수정이 이뤄졌는지를 여전히 이해해야 한다.
테스트 예산은 전체 워크플로를 포괄해야 한다
더 폭넓은 AI 테스트에서 까다로운 부분은 워크플로를 통제하는 사람과 시스템을 조율하는 일이다.
프롬프트 중심의 실험은 대화형 인터페이스에 접근할 수 있으면 시작할 수 있는 경우가 많다. 워크플로 평가는 더 많은 맥락을 요구한다. 테스터는 애플리케이션의 의도된 작업, 접근 가능한 정보, 그리고 도구가 만들어낼 수 있는 영향을 이해해야 한다. 이러한 이해를 확보하는 데는 공격이 시작되기 전부터 조직의 노력이 든다.
그 비용은 보안 트레이드오프의 일부다. 더 넓은 범위는 배포된 제품에 더 잘 부합하는 결론을 뒷받침한다. 더 좁은 범위는 필요한 작업을 줄이지만, 결과 보고서가 입증할 수 있는 내용도 제한한다. 어느 선택도 테스트가 완료되었다는 일반적인 문구 뒤에 가려져서는 안 된다.
이 차이는 개선 조치에도 영향을 준다. 취약점이 지나치게 광범위한 서비스 계정에서 비롯됐다면 모델의 지침을 바꾸는 것만으로는 근본 권한이 그대로 남을 수 있다. 문제가 의도하지 않은 목적으로 사용된 정당한 접근과 관련된다면, 모든 접근을 제거하는 것은 제품의 역할을 무력화할 수 있다. 엔지니어링에는 유용한 수정을 뒷받침할 만큼 구체적인 진단이 필요하다.
소유권이 핵심 장애물이 될 수 있다. 모델 팀은 구성을 통제하고, 애플리케이션 팀은 오케스트레이션을 통제하며, ID 팀은 권한을 통제한다. 영향을 받는 워크플로는 사업 부서가 소유한다. 이런 경계를 가로지르는 발견 사항에는 누가 무엇을 바꿀지에 대한 결정이 필요하다.
문서 어시스턴트 사례는 이것이 어떻게 전개되는지 보여 준다. 제품은 내부 파일을 검색하고 외부용 요약을 작성한다. 테스트에서 제한된 콘텐츠가 초안에 포함된 사실이 발견된다. 시정 조치는 검색 권한, 수신자 확인, 문서 분류 또는 워크플로의 승인 단계와 관련될 수 있다. 이러한 해결책은 서로 다른 원인을 다룬다.
유용한 결과는 어떤 경계가 실패했는지, 선택한 해결책이 관찰된 경로를 차단했는지를 설명할 것이다. 근본 실패가 지침 처리와 관련된 경우가 아니라면, 단순히 어시스턴트 지침의 문구를 강화하는 것은 더 약한 증거가 된다. 수정은 입증된 메커니즘을 따라야 한다.
사용 가능한 도구는 이 작업의 서로 다른 부분을 지원한다. OWASP의 애플리케이션 테스트 지침은 모델 취약점 스캐닝용 NVIDIA garak과 적대적 상호작용 오케스트레이션용 Microsoft PyRIT를 나열한다. 이 도구들은 테스트 활동을 지원하는 반면, 참여 방법론은 범위, 해석, 후속 조치를 체계화한다. 역할은 겹치지만 서로 대체할 수는 없다.
따라서 도구 비교는 브랜드 선호보다 포괄 범위에 초점을 맞춰야 한다. 다양한 입력을 생성하는 스캐너는 비즈니스 기록이 적절하게 변경되었는지를 자동으로 입증할 수 없다. 오케스트레이션 프레임워크는 정의된 작업과 정책 없이 조직이 허용할 수 있는 권한 경계를 결정할 수 없다.
매뉴얼이 재현성과 방어적 통합을 강조하는 것은 엔지니어링 팀과 보안 팀이 활용할 수 있는 발견 사항이라는 운영적 결과를 지향한다. 비즈니스 가치는 그 인계에 달려 있다. 아무도 그 결과를 재현하거나 수정 사항을 검증할 수 없다면, 이례적인 응답을 발견하는 일의 유용성은 떨어진다.
1월까지 도입 증거를 지켜봐야 한다
가장 강력한 신호는 조직이 매뉴얼 사용 후 평가 범위를 바꾸고 수정 사항을 검증했다는 공개 증거가 될 것이다.
첫 번째로 살필 신호는 공개 사례 연구의 품질이다. 2027년 1월까지 유용한 사례는 테스트한 애플리케이션, 연결된 기능, 그리고 평가에서 제외된 경계를 설명할 것이다. 지지 표명이나 다운로드 발표는 관심을 보여 준다. 문서화된 참여 사례는 실제 제약 조건에서 이 방법론이 어떻게 작동하는지 드러낸다.
발견된 취약점과 구체적 시정 변경을 연결한다면 이러한 사례는 매뉴얼의 가치를 뒷받침할 것이다. 애플리케이션 결과를 살피지 않은 채 이례적인 모델 응답만 보고한다면 더 광범위한 주장은 약화될 것이다. 이 구분은 릴리스가 명시한 범위를 따른다.
다음 신호는 공급업체가 평가 서비스에서 포괄 범위를 설명하는 방식이다. OWASP의 레드 팀 이니셔티브는 이미 평가 및 공급업체 선정 리소스와 함께 매뉴얼을 제시하고 있다. 이는 서비스에 무엇이 포함되는지 살펴볼 기준점을 만든다. 구매자는 포괄되는 도구, 데이터 접근, 에이전트 행동에 대한 더 명확한 설명이 나오는지 지켜봐야 한다.
더 구체적인 보고는 공통 지침이 비교 가능성을 개선한다는 견해를 뒷받침할 것이다. 문서화된 범위 없이 OWASP 정렬을 폭넓게 주장하는 것은 더 약한 증거가 된다. 의미 있는 변화는 공급업체 페이지의 새 배지가 아니라 산출물과 계약상 기대치에서 나타날 것이다.
마지막 신호는 개선 조치 이후에 일어나는 일이다. 공개된 후속 결과는 조직이 원래 실패를 재테스트하고 관련 경로를 검토했는지를 보여 줄 것이다. 발견 단계에서 멈추는 사례는 핵심 운영 질문을 답하지 못한다. 제품은 의도된 기능을 유지하면서 더 안전해졌는가?
이는 OWASP나 참여 공급업체가 발표한 약속이 아니라 관찰 기준이다. 검증된 도입 수치나 사고 감소 측정치는 아직 매뉴얼의 영향을 입증하지 못한다. 이 릴리스는 그 영향을 조사하기 위한 프레임워크를 제공하며, 구현 증거는 뒤따라야 한다.
개발자에게 즉각적인 함의는 테스트 결과를 고객이 실제로 사용하는 구성과 연결하는 것이다. 엔터프라이즈 구매자에게는 모델 보증과 배포 증거를 구분하는 일이다. 사용자에게 실질적인 관심사는 어시스턴트가 자신의 정보와 행동을 둘러싼 경계를 지키는지 여부다.
OWASP GenAI 레드 팀 매뉴얼을 조직이 실제로 배포하는 AI 시스템의 평가 증거와 함께 읽어야 한다. 제품 소유자에게 어떤 워크플로를 테스트했고 어떤 권한이 범위 밖에 남았는지 설명해 달라고 요청하라. 보고서가 시도된 행동과 완료된 영향을 구분하는지 검토하라. 엔지니어링이 원래 실패 사례에 대해 수정 사항을 검증했는지 확인하라. 이러한 질문은 논의를 프레임워크 명칭이 아니라 관찰 가능한 행동에 연결해 둔다. 또한 자신감 있는 요약이 좁은 실험에 기반한 지점을 드러낸다. 어시스턴트에 더 넓은 접근 권한을 부여하기 전에, 추가된 권한을 포괄하는 증거를 요청하라. 최신 평가는 직원들이 사용하는 제품을 설명하는가, 아니면 그 아래의 모델만 설명하는가?
