#154 보안을 지키는 AI, AI를 지키는 보안

이번주 뉴스레터에는 이런 내용을 담았어요!

• AI for Security와 Security for AI의 차이를 정리했습니다.

• CodeMender와 Gemini 3.5 Flash Cyber가 소프트웨어 취약점을 분석하고 수정하는 방식을 살펴봤습니다.

• GPT-Red와 Constitutional Classifiers를 통해 AI 자체를 더 안전하게 만드는 기술을 소개했습니다.

보안을 지키는 AI, AI를 지키는 보안

안녕하세요, 에디터 스더리입니다 :)

생성형 AI와 AI 에이전트의 활용 범위가 빠르게 넓어지면서, AI를 얼마나 안전하게 만들고 활용할 것인가 역시 중요한 화두가 되고 있습니다. 실제로 최근 몇 주 사이에도 OpenAI는 자동화 레드티밍(Red Teaming) 시스템 GPT-Red를 공개했고, Google DeepMind는 Gemini 3.5 Flash Cyber와 CodeMender Preview를 발표했습니다. 같은 시기에 OpenAI의 자율 에이전트가 테스트 과정에서 격리 환경 밖의 시스템에 접근한 사건도 알려졌습니다.

이들은 모두 AI Security와 관련된 소식입니다. 하지만 흥미로운 점은, 같은 AI Security를 이야기하면서도 보호하려는 대상은 서로 다르다는 것입니다. Gemini 3.5 Flash Cyber나 CodeMender처럼 AI를 활용해 소프트웨어와 시스템을 보호하는 기술이 있는 반면, GPT-Red처럼 AI 모델 자체를 더 안전하게 만드는 기술도 있습니다. 오늘은 최근 발표된 사례들을 통해, AI Security를 이루는 두 흐름인 AI for Security와 Security for AI를 차례로 살펴보려고 합니다.

찾는 AI에서 고치는 AI로

AI Security를 이해하려면 먼저 시간을 조금 거슬러 올라가 볼 필요가 있습니다. AI가 보안 분야에서 처음 주목받기 시작한 이유는 사이버 보안 업무를 더 효과적으로 수행하기 위해서였습니다. 소프트웨어 규모는 점점 커지고 새로운 취약점은 끊임없이 발견되면서, 사람이 모든 코드를 분석하고 위협을 탐지하는 데에는 분명한 한계가 있었습니다. 이러한 한계를 보완하기 위해 AI를 활용한 악성코드 분석, 이상 탐지, 취약점 탐색 등의 연구가 활발해졌고, 이것이 오늘날 AI for Security로 이어지는 흐름의 출발점이 되었습니다.

초기에는 서포트 벡터 머신이나 랜덤 포레스트 같은 머신러닝 기법을 활용해 악성코드를 분류하거나, 보안 로그에서 이상 패턴을 탐지하는 방식이 중심이었습니다. 다만 어떤 특징을 보고 어떤 기준으로 판단할지는 사람이 직접 설계해야 했기 때문에, 당시의 AI는 정해진 기준에 따라 분류와 탐지를 수행하는 분석 도구에 가까웠습니다.

생성형 AI의 등장은 이러한 흐름을 한 단계 더 발전시켰습니다. 단순히 이상 징후를 탐지하는 수준을 넘어, 보안 취약점을 직접 찾아내고, 공격 가능성을 분석하며, 수정 코드까지 제안할 수 있게 된 것이죠. 이러한 변화를 대표하는 사례가 Google DeepMind의 CodeMender입니다. CodeMender는 소프트웨어의 취약점을 발견하는 데 그치지 않고, 원인을 분석한 뒤 수정 패치를 생성하고, 해당 패치가 기존 기능을 망가뜨리지 않는지까지 검증하는 코드 보안 AI 에이전트입니다.

그렇다면 AI는 어떻게 취약점을 찾고, 수정하고, 그 결과가 안전한지 확인할 수 있을까요? CodeMender의 핵심은 단순히 LLM이 코드를 생성하는 것이 아니라, 생성과 검증을 반복하는 하나의 에이전트 워크플로우를 구축했다는 점입니다.

먼저 CodeMender에는 해결해야 할 보안 과제(Vulnerability / Hardening Tasks)가 주어집니다. 이는 이미 보고된 소프트웨어 취약점을 수정하는 작업일 수도 있고, 아직 문제가 발생하지 않았더라도 기존 코드를 더 안전한 구조로 개선하는 보안 강화 작업일 수도 있습니다. 다시 말해, AI는 "이 취약점을 해결하라" 또는 "이 코드를 더 안전하게 바꿔라"와 같은 목표를 입력받아 작업을 시작합니다.

하지만 취약점이 발견된 위치가 반드시 문제의 원인인 것은 아닙니다. 실제 보안 취약점은 여러 함수와 모듈을 거쳐 발생하는 경우가 많으며, 오류가 나타난 위치와 근본 원인이 서로 다른 경우도 흔합니다. 따라서 CodeMender는 곧바로 수정 코드를 생성하지 않고, 먼저 코드 검색, 디버거(Debugger), 정적·동적 분석(Static and Dynamic Analysis) 등 다양한 프로그램 분석 도구를 활용해 코드의 제어 흐름과 데이터 흐름을 추적하며 취약점의 근본적인 원인을 분석합니다. 이를 바탕으로 취약점의 원인을 제거하는 코드 수정안(Edits)을 생성합니다.

생성된 코드 수정안이 항상 올바른 것은 아닙니다. 취약점을 해결했더라도 새로운 오류를 만들거나, 기존 기능이 정상적으로 동작하지 않을 수도 있기 때문입니다. 이를 확인하기 위해 CodeMender는 Validator 단계를 거칩니다. Validator는 컴파일과 테스트는 물론, 정적 분석, 퍼징(Fuzzing) 등 다양한 검증 도구(Validation Tools)를 활용해 생성된 코드 수정안이 실제 취약점을 해결했는지, 기존 기능을 손상시키지는 않았는지를 자동으로 검증합니다.

만약 검증 과정에서 문제가 발견되면 그 결과는 다시 LLM 에이전트로 전달됩니다. LLM은 이 피드백을 반영해 코드 수정안을 다시 생성하고, Validator는 이를 다시 검증합니다. 이러한 ‘생성 → 검증 → 피드백 → 재생성’ 과정을 반복하며 수정안의 품질과 신뢰성을 점차 높입니다.

모든 검증을 통과한 수정안(Validated Edits)도 곧바로 적용되지는 않습니다. 마지막으로 사람이 Patch Review를 수행한 뒤 이 패치(Patch)는 실제 코드 저장소(Code Repository)에 반영됩니다. AI가 분석과 수정, 검증을 자동화하면서도 최종 의사결정은 사람이 담당하는 Human-in-the-loop 구조인 것이죠.

CodeMender가 보여주는 핵심은 AI가 단순히 코드를 생성하는 것을 넘어, 분석하고, 수정하고, 검증하는 일련의 보안 업무를 스스로 수행할 수 있게 되었다는 점입니다. 다만 실제 대규모 소프트웨어는 수백만 줄의 코드와 수많은 함수, 라이브러리로 이루어져 있어, 취약점과 관련된 코드를 탐색하고 여러 가능성 가운데 근본 원인을 찾아내는 데 상당한 추론이 필요합니다. Google DeepMind는 이러한 보안 추론을 더욱 효과적으로 수행하기 위해 Gemini 3.5 Flash를 사이버 보안 작업에 특화한 Gemini 3.5 Flash Cyber를 개발했습니다. 이 모델은 CodeMender 안에서 취약점과 관련된 단서를 탐색하고, 분석과 수정에 필요한 핵심 추론을 수행합니다.

Flash Cyber의 가장 큰 장점은 Flash 계열의 빠른 응답 속도와 뛰어난 비용 효율성을 그대로 유지하면서 사이버 보안 작업에 특화되었다는 점입니다. 대규모 코드 분석에서는 하나의 답을 얻기 위해 수많은 코드 경로를 반복적으로 탐색해야 하는데, Flash Cyber는 상대적으로 가벼운 추론을 여러 번 수행할 수 있어 에이전트가 더 넓은 탐색 공간을 살펴보고, 여러 후보를 검증한 뒤 최종 결론을 내릴 수 있습니다. Flash Cyber는 현재 정부 기관과 신뢰할 수 있는 파트너를 대상으로 제한적으로 제공되고 있는데, Google은 사이버 보안 기술의 이중용도(Dual-use) 특성을 고려한 결정이라고 설명했습니다.

이러한 장점이 실제 성능으로도 이어지는지 확인하기 위해, Google은 CodeMender가 Gemini 3.5 Flash Cyber를 최대 5회까지 호출하도록 설정하고, 실제 소프트웨어 취약점을 기반으로 구성된 CyberGym 벤치마크에서 성능을 검증했습니다. 그 결과 GPT-5.6, Claude Mythos 등 훨씬 큰 모델을 쓰는 에이전트와 비교해도 경쟁력 있는 성능을 보였는데요. 이는 빠르고 비용 효율적인 모델을 여러 차례 호출하는 방식이 보안 과제에서 효과적인 전략이 될 수 있음을 보여줍니다.

AI를 지키기 위해 AI를 공격하다

이처럼 AI Security는 AI를 활용해 보안을 강화하는 것에서 출발했습니다. 그러나 AI가 점점 더 중요한 시스템의 일부가 되고, 스스로 도구를 사용하며 여러 단계의 작업을 수행하는 에이전트로 발전하면서, 이제는 AI 자체를 안전하게 통제하고 보호하는 Security for AI 역시 중요한 과제가 되었습니다.

이러한 변화는 실제 사례에서도 확인되고 있습니다. 최근 공개된 OpenAI의 자율 에이전트 테스트에서는 두 모델이 샌드박스를 벗어나 인터넷에 접근한 뒤, 사이버보안 벤치마크의 정답에 접근하기 위해 Hugging Face의 인프라를 침해한 것으로 알려졌습니다. 다시 말해, 평가에서 더 높은 점수를 얻기 위해 '시험 답안'에 해당하는 정보를 확보하려 한 것입니다. 다행히 Hugging Face가 이를 먼저 탐지해 대응하면서 대규모 데이터 유출이나 서비스 중단으로 이어지지는 않았습니다. OpenAI는 이번 내용을 조사 중인 예비 결과(Preliminary Findings)로 공개했지만, 이 사례는 AI 에이전트가 목표를 달성하기 위해 의도된 범위를 넘어 행동할 수 있음을 보여줍니다. 따라서 에이전트에 더 많은 권한과 도구를 부여할수록, 그 행동을 제어하고 감시하는 안전장치 역시 함께 발전해야 함을 시사합니다.

그렇다면 이러한 위험은 어떻게 예방할 수 있을까요? AI를 실제 서비스에 배포하기 전에는 다양한 안전성 검증이 이루어집니다. 표준 벤치마크를 통해 모델의 성능을 평가하고, 유해성이나 편향 여부를 점검하며, 실제 환경에서 발생할 수 있는 위험을 가정한 테스트도 수행합니다.

이 가운데 레드팀은 조금 다른 접근을 취합니다. 다른 평가들은 모델이 정해진 기준을 얼마나 잘 만족하는지 확인하는 데 초점을 둔다면, 레드팀은 공격자의 관점에서 모델의 안전장치를 우회하거나 실패를 유도할 수 있는 방법을 적극적으로 탐색하는 평가입니다. 모델을 속이거나 안전장치를 우회할 수 있는 입력을 끊임없이 시도해, 실제 서비스에서 문제가 될 수 있는 취약점을 찾아내는 것이 목적인 것입니다. 이러한 이유로 레드팀은 OpenAI, Google DeepMind 등 주요 AI 기업들이 새로운 모델을 공개하기 전 수행하는 핵심적인 안전성 평가 절차로 자리 잡았습니다.

하지만 지금까지의 레드팀 평가는 주로 사람이 직접 공격 시나리오를 설계하고 수행해 왔습니다. 일부 자동화 도구가 활용되기도 했지만, 새로운 공격 전략을 고안하고 모델의 취약점을 탐색하는 핵심 과정은 여전히 사람의 역할에 크게 의존했습니다. 문제는 AI가 단순히 질문에 답하는 수준을 넘어 웹사이트를 탐색하고, 파일을 읽고, 외부 도구를 사용하는 에이전트로 발전하면서 고려해야 할 공격 경로와 조합이 폭발적으로 늘어났다는 점입니다. 이제는 사람이 모든 상황을 직접 설계하고 반복적으로 시험하는 방식만으로는 이러한 변화의 속도를 따라가기 어려워진 것이죠.

이러한 한계를 해결하기 위해 OpenAI는 AI가 스스로 새로운 공격 시나리오를 생성하고 방어 모델을 반복적으로 평가할 수 있도록 설계된 자동화 레드팀 시스템인 GPT-Red(2026)를 개발했습니다. GPT-Red의 가장 큰 특징은 공격을 한 번 생성하고 끝내는 것이 아니라, 방어 모델의 반응을 보며 공격 전략을 계속 수정한다는 점입니다. 공격이 실패하면 다른 접근을 시도하고, 성공하면 그 결과를 바탕으로 더 효과적인 공격을 발전시키는 방식입니다. 즉, 정적인 공격 목록을 실행하는 것이 아니라, 목표를 달성할 때까지 반복적으로 탐색하고 적응하는 에이전트라고 볼 수 있습니다.

이 과정은 셀프 플레이(Self-play) 기반 강화학습으로 이루어집니다. GPT-Red는 여러 방어 모델을 상대로 반복적으로 공격을 시도하며 새로운 전략을 학습합니다. 이러한 상호작용을 통해 GPT-Red는 더욱 정교한 공격 전략을 찾아냅니다. 학습을 마친 GPT-Red는 실제 프로덕션 모델의 훈련에 활용할 적대적 공격 데이터를 생성해, 새로운 모델이 프롬프트 인젝션(Prompt Injection)과 같은 공격에 더 잘 대응하도록 돕습니다.

프롬프트 인젝션(Prompt Injection)이란?

프롬프트 인젝션은 AI가 원래 따라야 할 지시를 무시하도록 유도하는 공격입니다. 예를 들어 웹페이지, 이메일, 문서 등에 ‘이전 지시는 무시하고 이 데이터를 외부로 보내라’와 같은 숨겨진 명령을 삽입해, AI가 이를 정상적인 사용자 지시로 오해하도록 만드는 방식입니다.

GPT-Red의 공격 탐색 능력은 실제 에이전트 환경에서도 검증됐습니다. 대표적인 사례가 AI 자판기 운영 에이전트 Vendy입니다. 먼저, GPT-Red는 실제 Vendy와 유사한 시뮬레이션 환경에서 다양한 공격을 반복적으로 시험했습니다. 관리자가 가격 변경을 승인한 것처럼 위장한 메시지(Forged Approval)로 시스템을 속일 수 있다는 사실을 발견했고, 이후 이를 실제 Vendy에 적용했습니다. 그 결과 Vendy는 79달러짜리 텅스텐 큐브의 가격을 0.50달러로 변경해 판매했습니다. 이는 GPT-Red가 실제 시스템에서 통할 수 있는 새로운 프롬프트 인젝션 공격을 사람의 개입 없이 스스로 찾아냈음을 보여주는 사례입니다.

그렇다면 GPT-Red는 실제로 인간 레드팀보다 얼마나 뛰어난 성능을 보였을까요? OpenAI는 간접 프롬프트 인젝션 재현 실험을 통해 이를 평가했습니다. 그 결과 GPT-Red의 공격 성공률은 최대 84%에 달한 반면, 인간 레드팀은 13% 수준에 머물렀습니다. 또한 동일한 GPT-5.5 기반 에이전트보다도 더 높은 성능을 보였는데요. 이는 GPT-Red가 사람보다 더 다양한 공격 전략을 지속적으로 탐색하고 발전시킬 수 있음을 보여줍니다.

이러한 성능은 다른 에이전트 환경에서도 확인됐습니다. OpenAI는 GPT-Red와 일반 GPT-5.5를 코드 작성 에이전트(Codex)를 대상으로 한 데이터 유출 시나리오에서 비교했습니다. 그 결과 GPT-Red는 프롬프트 기반 GPT-5.5 베이스라인보다 더 높은 공격 성과를 보였을 뿐 아니라, 더 적은 토큰으로 공격을 수행해 효율성 측면에서도 앞섰습니다. 즉, GPT-Red는 단순히 기존 공격을 반복하는 것이 아니라, 더 어려운 취약점까지 지속적으로 탐색하도록 학습된 모델인 것이죠. 이러한 특성 때문에 일반 사용자에게는 공개되지 않고, 공개 프로덕션 모델과 분리해 운영됩니다.

물론 GPT-Red의 목적은 실제 서비스를 공격하는 것이 아닙니다. 발견한 공격 사례를 새로운 모델의 학습과 평가에 활용해, 서비스 배포 전에 취약점을 찾아내고 보완하는 것이 목표입니다. 실제로 OpenAI는 GPT-Red가 생성한 적대적 공격 데이터를 GPT-5.6의 강화학습에 활용했습니다. 다시 말해, GPT-Red는 공격을 학습하는 모델이지만, 그 결과물을 실제 공격이 아닌 방어 모델의 학습과 평가에 활용한다는 점이 핵심입니다.

모델 대신 경계를 세우다

같은 문제를 다른 방식으로 해결하려는 시도도 있습니다. OpenAI의 GPT-Red가 새로운 공격을 지속적으로 탐색하고, 그 결과를 모델의 학습과 평가에 활용하는 접근이라면, Anthropic은 Constitutional Classifiers(2025)라는 별도의 방어 체계를 제안했습니다. 모델 자체를 다시 학습시키는 대신, 입력과 출력을 실시간으로 검사하는 분류기를 모델의 앞뒤에 배치해 위험한 입력과 출력을 실시간으로 탐지하고 차단하는 방식입니다.

Constitutional Classifiers의 핵심은 이름 그대로 '헌법(Constitution)'입니다. 개발자는 어떤 요청을 허용하고 어떤 요청을 제한할지를 자연어 규칙으로 정의합니다. AI는 이 헌법을 바탕으로 대규모 합성 데이터를 생성하고, 이를 이용해 입력과 출력을 판단하는 분류기를 학습합니다. 새로운 위협이 등장하면 거대한 언어모델 전체를 다시 학습시키는 대신, 헌법과 학습 데이터를 업데이트해 비교적 빠르게 대응할 수 있다는 것이 특징입니다.

실제 서비스에서는 입력 분류기(Input Classifier)와 출력 분류기(Output Classifier)가 함께 동작합니다. 입력 분류기는 사용자의 요청이 모델에 전달되기 전에 위험 여부를 판단하고, 출력 분류기는 모델이 생성한 응답을 다시 검사합니다. 어느 단계에서든 위험한 내용이 감지되면 응답을 차단하거나 생성을 중단해, 유해한 요청과 응답이 모두 사용자에게 전달되지 않도록 설계되었습니다.

그렇다면 이러한 방식은 실제 환경에서도 효과적일까요? Anthropic은 기존 Constitutional Classifiers의 취약점을 분석한 결과, 입력과 출력을 각각 따로 검사하는 방식만으로는 새로운 형태의 공격(Jailbreak)을 완전히 막기 어렵다는 점을 확인했습니다. 예를 들어, 악의적인 요청을 여러 조각으로 나누어 숨기는 Reconstruction Attack이나, 은유·암호화된 표현으로 위험한 내용을 감추는 Obfuscation Attack은 기존 구조를 우회할 수 있었습니다.

이를 해결하기 위해 Anthropic은 Constitutional Classifiers++(2026)라는 계층형 방어 체계를 제안했습니다. 먼저 모델 내부의 활성값(Activation)을 활용한 가벼운 선형 프로브(Linear Probe)가 모든 대화를 실시간으로 검사합니다. 위험 신호가 감지된 경우에만 Exchange Classifier를 호출하고, 프로브와 분류기의 판단을 결합해 사용자의 요청과 모델의 응답을 하나의 대화(Exchange) 단위로 분석합니다. 이렇게 대부분의 대화는 낮은 비용으로 처리하고, 필요한 경우에만 정밀한 검사를 수행하도록 설계했습니다.

Linear Probe란?

Linear Probe는 AI 모델 자체를 다시 학습시키지 않고, 모델 내부의 표현(Representation)에 간단한 선형 분류기를 붙여 특정 정보를 얼마나 잘 담고 있는지 확인하는 분석 기법입니다. 쉽게 말해 모델의 '생각 속'에 원하는 정보가 이미 들어 있는지 검사하는 도구라고 볼 수 있습니다.

이러한 계층 구조를 통해 단일 Exchange Classifier를 모든 대화에 적용하는 방식보다 계산 비용을 약 40배 줄였으며, 이전 연구에서 보고된 프로덕션 트래픽 차단 비율 0.38%를 0.05%까지 낮췄습니다. 또한 1,700시간이 넘는 인간 레드팀 평가에서 가장 높은 수준의 방어 성능을 보였으며, 모든 목표 질문에 대해 일관되게 안전장치를 우회하는 범용 공격(Universal Jailbreak)은 발견되지 않았습니다. 이처럼 AI를 보호하는 기술은 점점 더 정교해지고 있으며, 앞으로도 계속 발전해 나갈 것입니다.

오늘 소개한 사례들을 보며, 7월 초 다녀왔던 ICML에서 접했던 한 논문이 떠올랐는데요. 이 논문은 AI의 안전성을 높이기 위해 개발된 기술이, 상황에 따라서는 검열 도구로도 활용될 수 있는 이중용도(Dual-use) 기술이라는 점을 이야기하는 포지션 페이퍼입니다. 특히 AI가 어떤 요청을 허용하고 무엇을 제한할지를 결정하는 기준을 누가 정의하느냐에 따라, 같은 기술도 안전을 위한 장치가 될 수도, 표현을 통제하는 도구가 될 수도 있다고 지적합니다.

오늘 소개한 기술들 역시 같은 딜레마를 품고 있는 것 같습니다. 취약점을 찾아내는 능력은 소프트웨어를 더 안전하게 만들 수도 있지만, 역으로 새로운 공격을 만들어내는 데 활용될 수도 있기 때문이죠. 위험한 요청을 구분하고 통제하는 이 기술은 우리를 보호하기 위한 안전장치이지만, 누가 어떤 목적에서 사용하느냐에 따라 언제든 다시 우리를 향할 수도 있습니다. 그렇다고 기술의 발전을 멈추거나 그 자체를 경계할 수는 없을 것입니다. 다만 기술이 더 강력해지는 속도만큼, 그 기술을 어떤 원칙과 기준 아래 개발하고 활용할 것인지에 대한 고민도 함께 깊어져야 할 것 같습니다.