적대적 예제(Adversarial Example)란? AI의 판단을 속이는 입력
TL;DR
적대적 예제(Adversarial Example)는 배포된 머신러닝 모델이 오분류하거나 의도와 다르게 행동하도록 일부러 바꾼 테스트 입력입니다. 사람에게는 원본과 거의 같아 보이는 이미지도 모델에는 전혀 다른 신호가 될 수 있습니다. 생성형 AI에서는 안전하지 않은 답을 끌어내도록 설계한 문장도 넓은 적대적 입력 맥락에서 다룹니다. 정상 입력 성능만 확인해서는 이런 약점을 찾기 어렵기 때문에 실제 사용 환경을 반영한 공격성 테스트와 운영 모니터링이 필요합니다.
핵심 3줄 요약
- 핵심 1
적대적 예제는 단순 오류가 아니라 모델의 약점을 겨냥해 만든 입력입니다. 입력을 조금 바꾸어 배포된 모델의 오분류나 오작동을 유도합니다. - 핵심 2
눈에 띄는 공격만 적대적 예제가 되는 것은 아닙니다. 사람이 알아채기 힘든 이미지 변화부터 교묘하게 구성한 문장까지 형태가 다양합니다. - 핵심 3
완벽한 방어법 하나는 없습니다. 정상 데이터와 적대적 입력을 함께 시험하고 입력 점검·모델 보강·사람 검토·운영 감시를 겹쳐야 합니다.
이 글에서 다룰 내용
- 적대적 예제의 한 문장 정의와 왜 중요한지
- 이미지 분류와 생성형 AI로 이해하는 쉬운 예시
- 적대적 예제가 만들어지고 문제를 일으키는 과정
- 회피 공격, 데이터 포이즈닝, 프롬프트 인젝션, AI 레드팀과의 차이
- AI 제품과 자동화에서 적대적 입력을 점검하는 방법
적대적 예제를 한 문장으로 정의하면 무엇인가요?
한 문장 정의: 적대적 예제는 배포된 머신러닝 모델이 잘못 분류하거나 의도하지 않은 행동을 하도록 공격자가 수정하거나 설계한 입력 사례입니다.
NIST 컴퓨터 보안 용어집은 적대적 예제를 배포 단계의 머신러닝 모델에 오분류나 오작동을 일으키는 수정된 테스트 표본으로 정의합니다. 핵심은 모델이 이미 쓰이고 있는 시점의 입력을 바꾼다는 데 있습니다.
TensorFlow는 신경망을 혼란시키려고 만든 특수 입력을 적대적 예제로 설명합니다. 대표적인 이미지 사례에서는 원본 판다 사진에 작은 변화를 더했더니 모델이 높은 확신으로 긴팔원숭이라고 분류했습니다. 사람 눈에는 변화가 거의 보이지 않아도 모델이 읽는 숫자 패턴은 크게 달라질 수 있습니다.
적대적 예제가 항상 미세한 변화만 뜻하지는 않습니다. 공격 목표와 입력 형태에 따라 눈에 띄는 문구, 물리적 표식, 음성 변화, 교묘하게 구성한 텍스트가 쓰일 수 있습니다. 사람이 원본과 구분하지 못해야만 적대적 예제가 되는 것은 아닙니다.
한 줄 정리: 적대적 예제는 모델의 약점을 겨냥해 배포 뒤의 판단을 틀리게 만드는 구체적인 입력 한 건입니다.
왜 AI를 사용할 때 중요한가요?
첫째, 정상 테스트에서 높은 성능을 낸 모델도 공격성 입력에는 약할 수 있습니다. 일반적인 테스트셋은 평소에 들어올 법한 데이터를 중심으로 만듭니다. 공격자는 그 분포의 빈틈과 모델의 경계를 노립니다.
둘째, 작은 입력 변화가 큰 결정 차이로 이어질 수 있습니다. 이미지 분류, 스팸 필터, 이상 탐지, 음성 인식처럼 입력을 분류하거나 점수화하는 AI는 임계값을 조금 넘는 순간 결과가 바뀔 수 있습니다.
셋째, AI가 실제 행동과 연결되면 피해 범위가 넓어집니다. 문서 분류 결과가 접근 허용으로 이어지거나, 에이전트의 판단이 외부 도구 실행으로 연결되면 잘못된 출력이 단순 답변 오류에 그치지 않습니다.
넷째, 생성형 AI도 의도적으로 만든 입력을 받습니다. Google은 생성형 AI의 적대적 테스트를 문제가 있거나 안전하지 않은 출력을 끌어낼 가능성이 큰 입력을 의도적으로 제공하는 평가 방법으로 설명합니다. 챗봇, 요약기, 검색 연결 AI도 정상 질문만으로는 드러나지 않는 실패를 따로 시험해야 합니다.
다섯째, 방어가 한 번 성공했다고 끝나지 않습니다. NIST는 적대적 머신러닝 방어에 만능 해결책이 없으며 현재의 완화책에도 한계가 있다고 설명합니다. 모델, 입력 경로, 사용자가 바뀌면 공격 방식도 달라집니다.
핵심 인사이트: 정확도는 평소 입력에 얼마나 잘 답하는지 보여 줍니다. 적대적 견고성은 누군가 일부러 흔들었을 때도 허용 범위 안에서 작동하는지를 묻습니다.
쉬운 예시로 이해해 볼까요?
감자나라ai님이 상품 사진을 자동 분류하는 AI를 운영한다고 가정해 보겠습니다. 정상적인 운동화 사진은 신발 카테고리로 잘 들어갑니다. 그런데 공격자가 이미지의 일부 픽셀을 계산해 바꾼 뒤 업로드하자 사람에게는 같은 운동화로 보이지만 모델은 전혀 다른 상품으로 분류합니다. 이 조작된 이미지가 적대적 예제입니다.
물리적 환경에서도 비슷한 문제가 생깁니다. NIST는 도로 표지판에 표식을 더해 자율주행 시스템이 정지 표지판을 속도 제한 표지판으로 잘못 읽게 만드는 회피 공격 사례를 소개합니다. 화면 속 파일만이 아니라 카메라가 보는 현실의 변화도 입력 조작이 될 수 있습니다.
텍스트 모델에서는 특정 안전 규칙을 우회하려고 표현 순서, 역할 지시, 인코딩, 문맥을 바꾼 문장이 적대적 입력으로 쓰일 수 있습니다. 다만 모든 어려운 질문이나 이상한 문장이 공격은 아닙니다. 실수로 모호하게 쓴 입력과 모델의 약점을 의도적으로 노린 입력은 목적과 맥락이 다릅니다.
쉬운 비유: 자물쇠가 평범한 열쇠에는 잘 버티지만 특정 각도로 깎은 열쇠에는 열린다면, 그 특수한 열쇠가 모델의 약점을 겨냥한 적대적 예제와 비슷합니다.
적대적 예제는 어떻게 만들어지나요?
1. 공격 목표를 정합니다
공격자는 모델이 아무 오답이나 내게 할 수도 있고 원하는 특정 결과를 내게 할 수도 있습니다. 스팸을 정상 메일로 분류하게 만들거나 특정 이미지를 다른 대상으로 인식하게 만드는 식입니다.
2. 모델에 관해 아는 범위가 달라집니다
모델 구조와 가중치, 기울기까지 아는 화이트박스 조건도 있고 API에 입력을 보내 결과만 관찰하는 블랙박스 조건도 있습니다. 적대적 예제가 반드시 모델 내부를 모두 알아야 만들어지는 것은 아닙니다.
3. 입력을 바꾸거나 새로 설계합니다
이미지의 픽셀, 음성의 파형, 문장의 철자와 표현, 문서 안의 지시처럼 모델이 읽는 부분을 조정합니다. 변화의 크기보다 그 변화가 모델의 판단 경계를 넘도록 설계됐는지가 중요합니다.
4. 성공 여부를 반복 확인합니다
공격자는 결과를 보며 입력을 다시 바꿀 수 있습니다. 한 번만 통과하면 되는 공격과 여러 환경에서도 재현돼야 하는 공격은 난도가 다릅니다. 화면에서 만든 이미지가 카메라 촬영 뒤에도 같은 효과를 내는지도 별도 문제입니다.
5. 실제 입력 경로에 적용합니다
파일 업로드, 카메라, 음성, API, 문서 검색, 챗봇처럼 서비스가 실제로 받는 형식과 전처리 과정을 거쳐야 합니다. 실험실에서 성공한 적대적 예제가 운영 환경에서도 항상 성공하는 것은 아닙니다.
실전 팁: 테스트할 때는 모델만 보지 말고 파일 변환, 이미지 압축, OCR, 입력 정규화, 검색, 도구 실행까지 실제 제품의 전체 입력 경로를 함께 확인하세요.
비슷한 용어와 무엇이 다른가요?
적대적 공격과의 차이
적대적 공격은 AI 시스템을 속이거나 정보를 빼내거나 성능을 떨어뜨리려는 공격 전체를 가리킵니다. 적대적 예제는 그 공격에 쓰이는 구체적인 입력 사례입니다. 공격은 행위와 절차이고 예제는 모델에 들어가는 데이터 한 건에 가깝습니다.
회피 공격과의 차이
회피 공격은 배포된 모델의 판단을 피하거나 바꾸려고 입력을 조작하는 공격 유형입니다. 적대적 예제는 회피 공격에 쓰일 수 있는 수정된 입력입니다. NIST는 회피 공격을 포이즈닝·개인정보 공격·오용 공격과 구분합니다.
데이터 포이즈닝과의 차이
데이터 포이즈닝은 학습 단계의 데이터에 오염된 사례를 넣어 모델 자체를 바꾸려는 공격입니다. 적대적 예제는 보통 학습이 끝난 모델에 배포 단계의 조작된 입력을 넣습니다. 학습 전 데이터를 건드리는지, 배포 뒤 입력을 건드리는지가 큰 차이입니다.
프롬프트 인젝션과의 차이
프롬프트 인젝션은 LLM이 원래 지시보다 공격자의 숨은 지시를 따르게 만드는 보안 문제입니다. 교묘한 프롬프트는 넓은 뜻의 적대적 입력이 될 수 있지만 적대적 예제 전체가 프롬프트 인젝션인 것은 아닙니다. 이미지 분류를 속이는 픽셀 변화에는 프롬프트가 없습니다.
적대적 테스트와 AI 레드팀의 차이
적대적 테스트는 실패를 찾기 위해 공격성 입력을 의도적으로 제공하는 방어 활동입니다. AI 레드팀은 사람, 절차, 도구를 동원해 더 넓은 위험과 공격 경로를 점검합니다. 테스트에서 만든 적대적 예제는 약점을 고치는 자료로 쓰이며 허가 없이 실제 서비스를 공격하는 행위와는 구분해야 합니다.
비교 정리: 적대적 예제는 입력 한 건, 회피 공격은 배포 뒤 판단을 피하는 공격, 데이터 포이즈닝은 학습 데이터 조작, 프롬프트 인젝션은 LLM의 지시 경계 공격, 적대적 테스트는 약점을 찾는 방어 평가입니다.
AI 제품에서는 어떻게 점검하나요?
첫째, 지켜야 할 행동과 실패 조건을 적습니다. 어떤 오분류가 큰 피해를 만드는지, 어떤 출력과 도구 실행을 금지할지, 허용 가능한 오류 범위가 어디까지인지 정합니다.
둘째, 위협 모델을 좁혀 시작합니다. 공격자가 입력만 바꿀 수 있는지, 결과를 반복 조회할 수 있는지, 파일이나 검색 문서를 넣을 수 있는지 구분합니다. 모든 공격을 한 번에 시험하려 하면 중요한 경로를 놓치기 쉽습니다.
셋째, 정상 테스트셋과 적대적 테스트셋을 분리해 관리합니다. 방어를 추가한 뒤 적대적 입력 성공률이 낮아져도 정상 사용자의 정확도와 접근성이 나빠질 수 있습니다. 두 결과를 함께 비교해야 합니다.
넷째, 실제 사용 조건을 다양하게 넣습니다. 이미지 크기와 압축, 촬영 각도, 문장 길이와 표현, 여러 언어, 파일 형식, 검색 문서, 연속 대화를 바꿉니다. Google은 적대적 테스트 입력이 제품 정책, 실패 유형, 사용 사례, 경계 사례를 넓게 다뤄야 한다고 안내합니다.
다섯째, 방어를 여러 층으로 나눕니다. 입력 정규화와 검증, 모델 보강, 출력 필터, 권한 제한, 사람 승인, 속도 제한, 로그와 경고를 조합합니다. 하나의 필터가 모든 입력 변형을 막을 것이라고 가정하지 않습니다.
여섯째, 발견한 사례를 회귀 테스트로 남깁니다. 문제를 고친 뒤 같은 입력과 변형 입력을 다시 실행합니다. 모델이나 프롬프트, 전처리 코드가 바뀔 때 취약점이 되살아나는지 확인합니다.
한 줄 정리: 적대적 예제 점검은 공격 한 건을 막는 작업이 아니라 실패 조건을 정하고 실제 입력 경로를 시험하고 발견 사례를 계속 재검증하는 운영 과정입니다.
사용할 때 무엇을 주의해야 하나요?
첫째, 사람에게 안 보이는 변화만 찾지 않습니다. 실제 공격은 눈에 띄는 스티커, 철자 변형, 파일 구조, 긴 문맥처럼 다양한 형태로 나타납니다. 미세한 픽셀 변화는 대표 사례이지 전체 정의가 아닙니다.
둘째, 테스트 성공을 완전한 안전 증명으로 해석하지 않습니다. NIST는 현재의 완화 방법이 모든 위험을 완전히 막는다고 보장하기 어렵다고 설명합니다. 알려진 공격을 통과해도 새로운 변형이 남을 수 있습니다.
셋째, 적대적 성능만 높이고 정상 사용성을 해치지 않습니다. 강한 필터와 입력 제한은 정상 파일이나 장애인 사용자의 표현, 다른 언어, 드문 사례까지 막을 수 있습니다. 오탐과 누락을 함께 측정해야 합니다.
넷째, 공격 샘플과 로그를 민감 정보처럼 다룹니다. 우회 문구와 취약한 입력 경로를 그대로 공개하면 악용 가능성이 커질 수 있습니다. 접근 권한, 공유 범위, 수정 책임자를 정해 보관합니다.
다섯째, 허가받은 범위에서만 시험합니다. 외부 서비스에 공격성 입력을 대량 전송하거나 운영 장애를 일으키면 약관과 법적 문제가 생길 수 있습니다. 자체 환경, 명시적으로 허용된 테스트 범위, 안전한 속도에서 진행합니다.
여섯째, 모델 문제와 제품 문제를 따로 보지 않습니다. 모델이 같은 답을 내더라도 도구 권한과 자동 실행이 제한돼 있으면 피해가 줄어듭니다. 반대로 모델의 작은 실수가 결제·삭제·외부 전송으로 바로 이어지면 위험이 커집니다.
주의: 적대적 예제를 찾았다는 사실은 공격이 이미 성공했다는 뜻이 아닐 수 있습니다. 재현 조건, 실제 입력 경로, 업무 영향, 기존 통제를 확인한 뒤 위험도를 판단하세요.
자주 묻는 질문
Q1. 적대적 예제는 사람이 알아볼 수 없는 입력인가요?
반드시 그렇지는 않습니다. 이미지의 미세한 픽셀 변화처럼 사람이 구분하기 어려운 사례가 유명하지만 눈에 보이는 표식이나 텍스트 변형도 모델을 속이도록 설계됐다면 적대적 입력이 될 수 있습니다.
Q2. 적대적 예제와 일반적인 모델 오류는 어떻게 다른가요?
일반 오류는 데이터 부족, 촬영 환경, 모호한 질문 때문에 우연히 생길 수 있습니다. 적대적 예제는 모델의 약점이나 판단 경계를 노려 오분류나 오작동을 유도하도록 의도적으로 수정하거나 만든 입력입니다.
Q3. 프롬프트 인젝션도 적대적 예제인가요?
넓은 적대적 입력 맥락에서는 함께 다룰 수 있지만 같은 용어는 아닙니다. 프롬프트 인젝션은 LLM의 지시 우선순위를 악용하는 공격이고 적대적 예제는 이미지·음성·표 형식 데이터 등 여러 입력 형태에서 나타날 수 있습니다.
Q4. 적대적 학습을 하면 모든 공격을 막을 수 있나요?
아닙니다. 알려진 적대적 예제를 학습에 포함하면 특정 공격에 대한 견고성이 좋아질 수 있지만 새로운 공격 방식과 다른 입력 조건까지 모두 막는다고 보장할 수 없습니다. 정상 성능 저하 여부도 함께 확인해야 합니다.
Q5. AI 서비스를 쓰는 일반 사용자도 무엇을 확인해야 하나요?
이미지·문서·음성을 AI 판단에 바로 연결할 때 입력 출처와 변형 여부를 확인하고 중요한 결정은 원본 자료와 사람 검토를 거치세요. 결과가 평소와 크게 다르면 입력 형식이나 숨은 문구를 살펴보고 서비스 운영자에게 재현 가능한 사례로 신고하는 편이 안전합니다.
출처
- NIST CSRC, adversarial example Glossary
- NIST, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
- NIST, Types of Cyberattacks That Manipulate Behavior of AI Systems
- TensorFlow, Adversarial example using FGSM
- Google for Developers, Adversarial Testing for Generative AI
마무리
적대적 예제는 AI가 평소 입력을 잘 처리한다는 사실만으로는 안전을 판단할 수 없다는 점을 보여 줍니다. 모델의 판단 경계를 노린 입력은 이미지, 음성, 텍스트, 문서처럼 여러 형태로 들어오며 작은 변화가 큰 결과 차이를 만들 수 있습니다.
감자나라ai님이 AI 제품이나 자동화를 검토할 때는 정상 사용 사례 옆에 “누군가 이 입력을 일부러 바꾼다면 무엇이 잘못될 수 있는가”라는 질문을 붙여 보세요. 실패 조건을 정하고 실제 입력 경로를 반복 시험하며 사람 승인과 운영 감시를 함께 두는 것이 현실적인 출발점입니다.
