AI는 이제 AI를 해킹하기 시작했다: GPT-Red가 보여준 새로운 보안 시대

GPT-Red는 무엇이고, 무엇이 아닌가

GPT-Red를 ‘해킹을 하는 GPT’라고 부르면 중요한 구분이 사라진다. 먼저 분명히 해 둘 것은, GPT-Red는 일반 ChatGPT 화면에서 선택할 수 있는 공개 모델이 아니라는 점이다. GPT-5.6이나 ChatGPT가 사용자의 질문에 답하도록 만들어진 범용 모델이라면, GPT-Red는 애초에 그런 용도로 설계되지 않았다. OpenAI의 설명에 따르면 GPT-Red는 취약점을 더 많이 찾아내어 광범위 배포 전에 고치기 위한 자동화 안전 레드팀 모델이다. 정확히 말하면 GPT-Red는 실제 서비스를 공격하기 위한 AI가 아니라 AI 시스템의 취약점을 사전에 발견하고 방어 체계를 강화하기 위한 AI 레드팀 모델이다. 공격 목표를 가진 입력을 보내고, 대상 GPT 모델의 반응을 관찰한 뒤, 다음 시도를 반복하는 방식으로 작동한다. 여기서 공격 대상은 임의의 외부 시스템 전반이 아니라 우선 AI 시스템의 안전성과 견고성, 특히 도구를 쓰는 에이전트의 프롬프트 인젝션 방어다. OpenAI가 이런 모델을 만든 배경도 짚어볼 만하다. AI가 에이전트로서 도구를 다루고 실제 작업을 수행하는 시대가 되면서, 그동안 사람이 수행하던 보안 검증 작업의 일부를 자동화할 필요가 커졌고, GPT-Red는 그 필요에 대한 OpenAI의 응답이다. 출처: GPT-Red: Unlocking Self-Improvement for Robustness

둘의 차이를 표로 정리하면 다음과 같다.

따라서 GPT-Red는 GPT-5.6이나 ChatGPT처럼 범용 질문 응답, 글쓰기, 코딩을 위해 공개된 선택지로 이해하면 안 된다. OpenAI는 GPT-Red를 배포 모델과 분리해 두며, 악성 능력을 의도적으로 학습한 모델이 적대적 행위자에게 넘어가지 않도록 한다고 밝힌다. 현재 공개된 설명의 범위에서 이는 제품 사용법이나 외부 고객용 침투 테스트 서비스의 발표가 아니라, 내부 안전 연구 및 학습 체계의 사례다. ‘GPT-Red를 사내에 설치해 모든 취약점을 찾는다’는 도입 시나리오를 이 발표에서 읽어내는 것은 과도하다. 출처: GPT-Red: Unlocking Self-Improvement for Robustness

왜 일반에 공개하지 않는지도 짚어볼 필요가 있다. GPT-Red는 방어를 위해서라고는 해도 공격 기법을 만들어 내는 능력을 의도적으로 학습한 내부 보안 모델이다. 이런 기능을 ChatGPT나 API 형태로 그대로 공개하면, 방어 연구에 쓰이는 것보다 악용될 가능성이 커질 수 있다. 그래서 사용자가 GPT-Red를 직접 써 보는 구조가 아니라, GPT-Red가 찾아낸 취약점으로 더 견고해진 미래의 GPT 모델을 사용자가 간접적으로 경험하게 되는 구조에 가깝다.

그럼에도 이 사례가 산업적으로 중요한 이유는 분명하다. 모델이 강해질수록 사람이 설계하고 실행하는 적대적 테스트만으로는 실패 사례의 양과 다양성을 따라가기 어렵다. OpenAI는 인간·제3자 레드팀, 여러 겹의 안전장치, 실시간 모니터링을 계속 병행하겠다고 명시한다. 즉 GPT-Red는 인간 레드팀을 없애는 선언이 아니라, 인간이 설계한 위협 모델 안에서 더 많은 가설을 반복 검증하는 자동화 계층의 등장이다. 출처: GPT-Red: Unlocking Self-Improvement for Robustness

‘자가학습’이라는 말은 정확히 읽어야 한다

발표 제목의 ‘self-improvement(자가개선)’를 ‘self-learning(자가학습)’과 같은 말로 읽으면 오해가 생긴다. GPT-Red는 스스로 모든 경험을 실시간으로 학습하는 AI가 아니라, 공격 시도의 결과와 평가 데이터를 모아 다음 훈련 주기에 반영함으로써 다음 세대 모델의 안전성을 높이는 개선 루프에 가깝다. 자율 시스템이 실시간으로 무제한 학습하며 공격 범위를 넓힌다는 뜻이 아니다. 공개 설명상 GPT-Red는 다양한 방어 LLM과 함께 자기대전 강화학습으로 훈련된다. 레드팀 모델은 유효한 실패를 이끌어 낼 때 보상받고, 방어 모델은 원래 작업을 수행하면서 공격을 막을 때 보상받는다. 방어가 강해지면 공격 모델은 더 강하고 다양한 공격을 찾아야 한다. 훈련 환경마다 레드팀 모델이 통제할 수 있는 부분과 성공 조건을 정의하는 위협 모델도 둔다. 출처: GPT-Red: Unlocking Self-Improvement for Robustness

실무자는 이를 ‘운영 중 온라인 학습’과 구분해야 한다. 전자는 운영 데이터가 즉시 모델 가중치와 행동을 바꾸는 체계이고, 후자는 통제된 평가 결과와 새 공격 데이터를 모아 다음 훈련·평가 주기에 반영하는 체계다. 후자는 재현성, 데이터 심사, 회귀 검증, 안전한 배포 경로를 만들기 상대적으로 수월하다. 반면 전자는 오염된 입력이 학습 신호에 섞이거나, 왜 행동이 바뀌었는지 추적하기 어려운 문제가 커진다. GPT-Red의 공식 설명이 뒷받침하는 것은 반복 평가와 학습을 통한 지속 개선이지, 현장에서 스스로 학습하는 완전 자율 공격 시스템이라는 해석이 아니다.

OpenAI가 공개한 수치도 이 맥락에서 읽어야 한다. 내부적으로 복제한 간접 프롬프트 인젝션 평가에서 GPT-Red는 사전 지정된 환경의 인간 레드팀보다 높은 성공률을 보였고, GPT-5.6 Sol의 특정 직접 인젝션 벤치마크 실패는 이전 생산 모델보다 줄었다고 발표했다. 이는 해당 평가 설계와 대상 모델에서의 결과다. 인간 보안 전문가 전체보다 우월하다거나, 모든 기업 시스템에 같은 성능이 재현된다는 근거는 아니다. 수치는 도입 의사결정의 답이 아니라, 평가 데이터·위협 모델·성공 정의를 공개하고 계속 갱신해야 한다는 신호다. 출처: GPT-Red: Unlocking Self-Improvement for Robustness

왜 에이전트가 되면 보안 문제가 달라지는가

전통적 챗봇은 틀린 답변을 하더라도 대개 대화 안에서 영향이 끝났다. 에이전트는 다르다. 사용자의 목표를 해석하고, 브라우저·파일 검색·코드 실행·메일·업무용 SaaS 같은 도구를 조합해 실제 상태를 바꾼다. OpenAI도 에이전트를 추론, 멀티모달 이해, 도구 사용의 발전으로 가능해진 LLM 기반 시스템으로 설명하며, 워크플로 안에서 도구와 가드레일을 설계해야 한다고 권고한다. 출처: A practical guide to building agents

위험의 핵심은 ‘모델이 나쁜 의도를 갖는가’가 아니라 서로 다른 신뢰 경계가 한 문맥에 섞이는 데 있다. 에이전트는 웹페이지, 받은 메일, 연결 앱의 응답, 로컬 파일, 코드 저장소처럼 제3자가 영향을 줄 수 있는 데이터를 읽는다. 그 데이터 안의 숨은 지시가 사용자 요청처럼 보이게 만들면, 민감 파일을 외부로 보내거나 잘못된 도구 호출을 유도하려 할 수 있다. OpenAI가 GPT-Red의 주요 대상 중 하나로 프롬프트 인젝션을 든 이유도 여기에 있다. 출처: GPT-Red: Unlocking Self-Improvement for Robustness

이를 세 층으로 나누면 운영 판단이 쉬워진다.

이 구조는 ‘프롬프트를 잘 쓰면 안전하다’는 오해를 막는다. 지시문은 유용한 제어 수단이지만 보안 경계가 아니다. 에이전트가 접근하지 못하는 자격 증명, 호출할 수 없는 도구, 승인 없이는 실행되지 않는 변경, 외부 전송 전에 작동하는 정책 검사가 훨씬 강한 방어선이다. 안전한 에이전트 설계에서 가드레일과 인간 개입이 워크플로 수준의 구성 요소여야 하는 이유도 같다. 출처: A practical guide to building agents

자동화 스캐너와 AI 레드팀은 경쟁재가 아니라 다른 층이다

기존 자동화 보안 도구를 과소평가할 이유는 없다. 정적 분석, 소프트웨어 구성요소 분석, 의존성 취약점 점검, 비밀정보 탐지, 동적 스캐너는 빠르고 재현 가능하며 규정 준수에 필요한 기본 신호를 만든다. 알려진 취약점, 잘 정의된 구성 오류, 정책 위반에는 이 도구들이 여전히 가장 경제적인 첫 번째 방어선이다.

AI 레드팀의 잠재력은 그 위에서 나타난다. 정해진 서명 하나를 찾기보다, ‘외부 문서를 읽은 조달 에이전트가 어떤 조건에서 내부 계약 정보를 다른 서비스로 보낼 수 있는가’처럼 목표와 맥락을 가진 실패 가설을 세울 수 있다. 대상의 반응을 관찰하며 다음 시도를 바꾸고, 여러 도구 호출 사이의 연결을 평가할 수 있다는 점도 차이다. GPT-Red가 프롬프트를 보내고 반응을 관찰하며 반복하는 구조는 이 가능성을 구체화한다. 그러나 이는 허가된 실험 환경에서의 평가 능력이지, 운영망에서 자유로운 공격 권한을 줘야 한다는 뜻이 아니다. 출처: GPT-Red: Unlocking Self-Improvement for Robustness

좋은 운영은 둘을 다음 순서로 연결한다. 먼저 전통 도구가 기본 위생 상태를 검사한다. 그 결과와 아키텍처 정보를 바탕으로 사람이 위협 모델과 교전 규칙을 작성한다. AI 레드팀은 그 규칙 안에서 다수의 변형 입력·다단계 시나리오를 생성하고 실행한다. 마지막으로 독립적인 판정기와 보안 담당자가 재현 가능한 증거를 검토해 결함을 확정하고, 수정 뒤에는 회귀 평가로 닫는다. AI가 발견한 문장 하나가 취약점 보고서가 되는 순간은 없다.

특히 오탐과 미탐의 비용은 대칭이 아니다. 오탐이 많으면 개발팀은 경보를 무시하게 되고, 미탐은 실제 데이터 유출이나 잘못된 변경으로 이어질 수 있다. AI가 지나치게 넓은 공격 시나리오를 제안할 때도 있다. 따라서 결과물은 ‘취약하다/안전하다’라는 레이블보다 재현 조건, 관찰된 도구 호출, 접근한 데이터 분류, 정책 위반 여부, 영향 범위, 신뢰도, 권장 조치를 포함한 증거 묶음이어야 한다. 사람이 그 묶음을 보고 수정 우선순위를 정할 수 있어야 자동화의 가치가 남는다.

레드팀을 실제 환경에 넣을 때 먼저 고정할 것

AI 레드팀 도입은 모델 구매에서 시작하지 않는다. 테스트 대상과 권한의 계약을 먼저 만든다. 범위가 없는 테스트는 보안 활동이 아니라 운영 위험이다. 다음 항목은 보안팀만의 문서가 아니라 제품 책임자, 플랫폼 운영자, 개발 리더가 함께 합의해야 한다.

교전 규칙은 프롬프트보다 앞선다

대상 시스템, 허용된 계정과 테넌트, 테스트 시간대, 사용할 데이터, 허용·금지된 도구, 네트워크 이그레스, 성공의 정의, 중단 조건을 문서화한다. 운영 고객 데이터 대신 합성 데이터와 분리된 비프로덕션 환경을 기본값으로 둔다. 실제 생산 환경 검증이 불가피하다면 쓰기 작업·외부 전송·고가치 자산 변경을 차단하거나 승인형으로 만들고, 제한된 창과 롤백 계획을 둔다.

여기서 ‘모델에 샌드박스를 써라’는 말만으로는 부족하다. 샌드박스는 네트워크, 파일시스템, 신원, 비밀정보, 도구 호출, 비용 자원을 각각 분리해야 한다. 읽기 전용 사본에서 가능한 테스트인지, 목적별 임시 자격 증명인지, 세션이 끝나면 권한이 자동 폐기되는지까지 확인해야 한다. GPT-Red 훈련에서도 환경별 위협 모델로 통제 가능한 요소와 성공 조건을 명시한다는 점은 기업 평가 설계에 좋은 기준점이다. 출처: GPT-Red: Unlocking Self-Improvement for Robustness

최소 권한은 역할이 아니라 작업 단위로 쪼갠다

에이전트 계정에 ‘개발자 권한’이나 ‘운영자 권한’을 통째로 부여하는 방식은 위험하다. 코드 검토 에이전트에는 특정 저장소의 읽기와 제한된 주석 작성만, 배포 보조 에이전트에는 특정 환경의 승인된 배포 작업만 부여하는 식으로 작업 단위 권한을 설계한다. 데이터베이스는 조회와 변경을 분리하고, 비밀정보 저장소의 값은 모델 문맥으로 원문 전달하지 않으며, 외부 전송은 별도 정책 판정과 승인 경로를 거치게 한다.

권한이 클수록 평가도 더 엄격해져야 한다. 읽기 전용 지식 검색 에이전트와 결제·인사·배포를 변경하는 에이전트를 같은 평가표로 통과시키면 안 된다. 고영향 행동에는 독립 정책 엔진, 사람의 명시적 확인, 두 단계 승인, 시간·금액·대상 제한 같은 결정적 통제가 필요하다. 모델이 어떤 설명을 했는지가 아니라, 실제 호출한 도구와 전달된 매개변수가 정책을 충족했는지 검사해야 한다.

로그는 관제가 아니라 검증의 입력이다

에이전트 운영에서 관찰 가능성은 선택 기능이 아니다. 각 실행마다 사용자 요청, 시스템 지시 버전, 참조한 외부 콘텐츠의 출처와 신뢰 등급, 모델·도구 호출 순서, 권한 판정, 데이터 분류, 변경 결과, 승인자, 중단 사유를 같은 추적 식별자로 묶는다. 민감 원문을 무분별하게 로그에 복제하지 않는 마스킹·접근 통제도 함께 설계해야 한다.

이 기록은 사후 포렌식뿐 아니라 AI 레드팀의 학습·평가 자산이 된다. 실패가 발견되면 ‘어떤 프롬프트가 문제였나’만 저장하지 말고, 어떤 신뢰 경계가 무너졌고 어떤 도구 권한이 있었으며 어떤 정책이 빠졌는지를 구조화한다. 다음 배포 때 같은 경로가 다시 열렸는지를 확인할 회귀 세트가 된다. OpenAI의 레드팀 가이드도 배포 전 오용·보안 위험을 적대적 사례로 탐색하고 평가할 것을 권한다. 출처: Red teaming | OpenAI API

개발 속도에 맞추려면 보안도 배포 파이프라인 안에 있어야 한다

AI가 코드 초안, 테스트, 문서화, 운영 작업을 빠르게 만들수록 ‘개발 완료 후 한 번 검사’하는 방식은 병목이 된다. 그렇다고 모든 변경을 AI가 자동 승인하게 해서는 안 된다. 더 현실적인 방향은 설계·구현·배포·운영의 각 단계에 서로 다른 검증을 넣는 것이다.

이 표가 말하는 바는 평가를 일회성 ‘감사’에서 제품 품질의 지속적 신호로 바꾸라는 것이다. 새 모델을 바꾸거나 프롬프트 한 줄을 고치거나, 연결 도구의 권한을 넓힐 때도 위협 모델은 달라질 수 있다. 평가 세트는 정답률만 재는 테스트가 아니라, 업무상 절대 일어나면 안 되는 행동과 필요한 정상 업무가 모두 포함돼야 한다. 정상 요청을 과도하게 거절하는 시스템은 보안이 아니라 기능 상실일 수 있다. GPT-Red 관련 발표도 견고성을 높이는 과정에서 일반 능력과 과잉 거절을 함께 평가했다고 설명한다. 출처: GPT-Red: Unlocking Self-Improvement for Robustness

산업 전체의 방향은 같지만, 같은 제품은 아니다

GPT-Red를 업계의 유일한 해답처럼 볼 필요는 없다. Anthropic의 Constitutional AI는 모델 행동을 인간 피드백과 AI 피드백, 원칙 기반 평가로 다루는 정렬 연구 방법이다. 이는 공격 탐색을 위해 특별히 훈련한 내부 레드팀 모델이라는 GPT-Red의 공개 설명과 목적·구성이 다르다. 두 사례가 함께 말해 주는 것은, 안전성을 배포 마지막 단계의 필터로만 처리하지 않고 학습·평가 과정에 넣으려는 흐름이다. 출처: Constitutional AI: Harmlessness from AI Feedback, GPT-Red: Unlocking Self-Improvement for Robustness

Google의 Secure AI Framework(SAIF)나 Microsoft의 AI 보안 지침 역시 같은 제품군으로 묶어서는 안 된다. 이들은 조직이 AI 시스템의 위험을 설계·배포·운영 전반에서 다루도록 돕는 보안 프레임워크와 실천 지침에 가깝다. 자동화 레드팀 모델 하나가 이런 거버넌스를 대신하지 못한다는 점에서 오히려 상호보완적이다. 기업은 모델 공급자의 안전 기능을 확인하되, 자사 데이터 흐름·도구 권한·규제·사고 대응까지 포함하는 독자적 운영 통제를 가져야 한다. 출처: Secure AI Framework, Microsoft Guide for Securing the AI-Powered Enterprise

이렇게 놓고 보면 OpenAI만 이런 방향으로 가는 것이 아니라는 점이 드러난다. Anthropic은 원칙 기반 정렬 연구에, Google과 Microsoft는 조직 전체를 위한 보안 프레임워크와 지침에 각각 투자하고 있다. 접근 방식과 강조점은 다르지만, 주요 AI 기업들이 하나같이 AI 안전성 검증과 자동화된 보안 평가에 지속적으로 자원을 넣고 있다는 사실은 같다. 이는 특정 기업 하나의 전략이라기보다, AI 산업 전체가 ‘모델을 더 크게 만드는 경쟁’ 못지않게 ‘모델을 더 안전하게 검증하는 경쟁’으로 무게중심을 옮기고 있다는 신호로 읽는 편이 정확하다.

이 구분은 구매와 책임의 경계를 선명하게 한다. 모델 공급자는 모델 수준 안전성과 플랫폼 제어를 제공할 수 있다. 애플리케이션 팀은 프롬프트, 검색 데이터, 연결 도구, 사용자 경험을 설계한다. 보안팀은 권한·로그·정책·사고 대응을 검증한다. 리더십은 허용 위험과 예외 승인 기준을 정한다. 어느 한 팀이나 한 모델의 성능으로 덮을 수 있는 문제가 아니다.

도입 전, 기술 리더가 던져야 할 일곱 질문

• 이 에이전트가 읽는 데이터 중 외부나 제3자가 바꿀 수 있는 것은 무엇인가? 그 데이터는 지시가 아니라 데이터로 처리되는가?
• 에이전트가 호출할 수 있는 도구와 각 도구의 읽기·쓰기·외부 전송 권한은 무엇인가? 작업 단위로 더 줄일 수 있는가?
• AI 레드팀의 테스트 대상과 교전 규칙은 문서화됐는가? 운영 데이터·운영 계정·운영 고객에 영향을 줄 가능성은 어떻게 분리했는가?
• 공격 성공과 실패를 어떤 관측값으로 판정하는가? 답변 문장뿐 아니라 실제 도구 호출과 상태 변경을 검증하는가?
• 오탐을 누가 분류하고, 미탐을 어떤 회귀 평가로 보완하는가? 결과에 재현 절차와 증거가 남는가?
• 위험한 행동에는 어떤 인간 승인과 자동 중단 장치가 있는가? 승인자는 맥락과 영향을 이해할 정보가 있는가?
• 모델, 프롬프트, 도구 연결, 권한 정책 중 하나가 바뀔 때 어떤 평가를 다시 실행하는가? 실패 사례는 릴리스 기준으로 관리되는가?

이 질문에 답하지 못한 상태에서 ‘AI 보안 도구’를 추가하면 경보만 늘고 책임은 흐려질 수 있다. 반대로 답을 문서화하면 특정 공급자나 모델이 바뀌어도 유지되는 보안 운영 기반이 생긴다. 처음에는 가장 위험한 에이전트 하나를 골라 읽기 전용 사본과 좁은 도구 권한에서 평가하는 편이 낫다. 발견한 실패 경로를 수정하고 회귀 테스트로 편입한 뒤, 권한과 대상 범위를 단계적으로 넓혀야 한다.

AI 성능 경쟁에서 거버넌스 경쟁으로

GPT-Red 사례를 OpenAI라는 한 회사의 안전 연구로만 좁혀 읽으면 산업 전체의 변화를 놓친다. AI 에이전트가 코드를 실행하고, 업무 도구를 호출하고, 데이터를 옮기는 역할을 넘겨받을수록 기업이 AI를 도입할 때 비교해야 할 기준도 달라진다. 앞으로는 어떤 모델이 더 똑똑한가보다, 그 AI에게 어떤 권한을 줬고 그 권한을 얼마나 안전하게 검증하고 통제할 수 있는가가 더 중요한 경쟁력이 될 수 있다.

이는 TechBrief가 다뤄온 다른 주제들과도 이어진다. AI 코딩 에이전트의 보안 사각지대 논의가 보여준 것도 결국 권한과 데이터 흐름을 조직이 직접 검증해야 한다는 같은 문제의식이었다. MCP처럼 에이전트가 외부 도구·데이터에 연결되는 표준이 넓어질수록, 그리고 개발 파이프라인 안에 보안 검증을 넣는 DevSecOps적 접근이 AI 에이전트에도 적용될수록, 이 문제는 보안팀만의 과제가 아니라 제품·개발 조직 전체의 과제가 된다. 결국 이 모든 흐름은 AI 거버넌스, 즉 AI에게 어떤 권한을 얼마나 줄지, 그 권한을 누가 어떻게 검증하고 통제할지를 조직 차원에서 설계하는 문제로 수렴한다. AI 에이전트가 시스템 권한을 더 많이 갖게 될수록, 그 AI를 검증하는 또 다른 AI의 중요성도 함께 커질 수 있다.

이런 흐름에서 현실적인 목표는 완전 자율 보안이 아니라 검수 가능한 자동화다. AI가 탐색과 반복 속도를 높이는 동안, 사람은 그 결과를 검증하고 최종 책임을 지는 구조를 유지해야 신뢰할 수 있는 자동화가 된다. AI 성능 자체보다 이 검증 체계를 갖췄는지가, 조직이 AI 에이전트를 얼마나 안전하게 확장할 수 있는지를 가르는 기준이 될 가능성이 크다.

결론: 경쟁력은 AI의 능력보다 검증 능력에서 갈린다

GPT-Red의 메시지는 AI가 인간 해커를 대체한다는 이야기가 아니다. 더 정확히는 AI 에이전트가 실제 도구와 데이터에 연결될수록, 방어 측도 사람이 만드는 고정 테스트만으로는 충분하지 않을 수 있다는 이야기다. AI가 더 많은 실패 가설을 만들고 반복 실행할 수 있다면, 인간 보안팀은 그만큼 위협 모델, 권한 설계, 증거 검토, 대응 우선순위에 집중할 수 있다.

그러나 자동화의 속도는 통제의 품질을 대신하지 않는다. 범위가 없는 공격, 과도한 권한, 추적되지 않는 도구 호출, 검수 없는 결과는 보안 검증을 또 다른 위험으로 바꾼다. AI 레드팀의 가치가 생기는 조건은 샌드박스, 최소 권한, 데이터 경계, 관찰 가능성, 중단권, 인간 책임이 함께 설계됐을 때다.

앞으로 기업이 경쟁해야 하는 것은 더 뛰어난 AI를 빨리 도입하는 능력만이 아니다. GPT-Red는 그 경쟁의 무게중심이 어디로 향하는지를 보여주는 이른 사례다 — 평가·권한·로그·사람의 판단을 연결하는 보안 운영 방식이지, 모델 하나의 기능이 아니다.

AI 시대의 경쟁력은 가장 뛰어난 AI를 확보하는 것이 아니라, AI에게 부여한 권한을 얼마나 안전하게 검증하고 통제할 수 있는 체계를 갖추고 있는가에 달려 있다. GPT-Red는 새로운 모델 하나가 등장했다는 소식이 아니라, AI가 AI를 검증하는 시대를 상징하는 출발점이다.

참고 출처

• GPT-Red: Unlocking Self-Improvement for Robustness
• Red teaming | OpenAI API
• A practical guide to building agents
• Constitutional AI: Harmlessness from AI Feedback
• Secure AI Framework
• Microsoft Guide for Securing the AI-Powered Enterprise