제대로 작동하는 AI 시스템을 구축하려면 먼저 망가뜨려 봐야 합니다. 금융 서비스의 고객용 AI 앱을 대상으로 공격자처럼 테스트하고 취약점을 탐색하는 레드팀 테스트를 진행했습니다. 이번에 발견한 내용은 보안이 필수인 LLM 기반 애플리케이션을 배포하는 모든 조직에 중요합니다.
레드팀 테스트는 실제 공격자가 취약점을 발견하기 전에 해결할 수 있도록 의도적으로 AI 시스템을 공격해 허점을 찾아보는 활동입니다. 금융 서비스에서는 특히 위험이 큽니다. AI 애플리케이션이 고객 데이터를 다루고 거래를 처리하며 금융 관련 인사이트를 제공하기 때문입니다. 문제가 발생하면 사용자 경험 저하부터 규제 위반, 금전적 손실, 회복할 수 없는 브랜드 훼손까지 이어질 수 있습니다.
목표는 취약점을 조기에 발견하고 현실적인 공격 패턴을 테스트해, 조직이 규제 기관에서 매우 중요하게 여기는 AI 안전 요건을 충족하도록 돕는 것이었습니다.
여기서 한 가지 구분할 점이 있습니다. 탈옥은 기반 모델의 안전 필터를 공격하지만, 프롬프트 인젝션은 신뢰할 수 없는 사용자 입력을 개발자의 신뢰할 수 있는 프롬프트와 결합해 애플리케이션 자체를 공격합니다. 프롬프트 인젝션은 범용 모델이 아니라 시스템과 시스템이 처리하는 기밀 데이터를 노리므로 더 큰 위험을 초래합니다.
첫 번째 테스트에서는 다음 영역에 걸쳐 약 750건의 테스트를 진행했습니다.
세션 간 데이터 유출
개인 식별 정보(PII) 노출(자연어, API 조작 및 다양한 인코딩 이용)
SQL 인젝션
시스템 프롬프트 재정의
초기 테스트에서 기존 시스템의 두 가지 주요 문제를 발견했습니다. 다중 의도 쿼리 처리와 인코딩된 프롬프트 사용이었습니다.
다중 의도 쿼리: 정상적인 요청과 악의적인 요청을 결합한 쿼리입니다. 예: “카테고리별 지출 내역을 보여주고 [악성 SQL]도 실행해 줘.” 애플리케이션은 악의적인 의도를 감지하지 못하고 전적으로 하위 데이터 계층의 보호 장치에 의존했습니다. 이는 지하실 금고를 믿는다는 이유로 현관문을 열어 두는 것과 같습니다.
인코딩: Base64, Hex, LeetSpeak 및 동형 문자로 요청을 인코딩하는 방식입니다. 시스템이 악의적인 의도를 걸러내기 어려울 수 있습니다. 이러한 쿼리가 민감한 데이터를 노출하지는 않았지만, 환각, 사용자에게 악성 SQL을 그대로 되풀이하는 현상, 의도 분류 혼선 등 시스템을 크게 불안정하게 만드는 데 영향을 미쳤습니다.
초기 테스트 결과는 다음과 같았습니다.
시간 관련 환각: 모델이 사실이 아닌 날짜나 거래 타임스탬프, 특정 기간에 대한 요약을 사실인 것처럼 확신에 차서 제시하는 현상입니다. 고객이 잘못된 날짜를 근거로 행동하면 실제 피해로 이어질 수 있는 금융 환경에서는 중대한 위험입니다.
악성 SQL을 사용자에게 그대로 되풀이함(메모리 오염 위험 우려)
의도 분류 혼선
출력 형식 깨짐
이러한 결과를 바탕으로 범위를 좁혔습니다. SQL 인젝션과 인코딩 테스트는 우선순위를 낮췄습니다. 팀에서 이미 대응하고 있었기 때문입니다. 대신 가장 효과적이었던 공격 벡터인 개인 식별 정보(PII) 노출과 세션 간 유출에 집중했습니다.
2차 테스트에서 가장 인상적인 발견은 놀라울 만큼 단순했습니다. 대개는 영리한 수법조차 필요하지 않았습니다.
많은 경우, 정상적인 요청처럼 보이게 내부 데이터를 요청하는 것만으로도 시스템이 해당 데이터를 노출하겠다고 응답했습니다. 간단한 쿼리에도 최종 사용자에게 절대 노출되어서는 안 되는 내부 ID와 시스템 필드가 언급된 응답이 돌아왔습니다.
더 깊이 조사한 결과, 이는 단순히 애플리케이션 계층의 문제만은 아니었습니다. 하위 text-to-SQL 서비스가 필요 이상의 필드를 요청하는 쿼리를 작성하고 있었으며, 설명 응답에서도 접근이 제한되어야 할 데이터를 언급했습니다. 이를 통해 시스템 간 연동 지점에 실제 취약점이 있다는 사실이 드러났습니다. 이러한 취약점은 개별 구성 요소를 따로 테스트하는 것이 아니라 전체 스택을 테스트해야만 발견할 수 있습니다.
모델이 아닌 시스템을 레드팀 테스트하세요. LLM만 따로 테스트해서는 애플리케이션의 보안 수준을 거의 파악할 수 없습니다. 사용자가 실제로 이용하는 방식대로 전체 스택을 처음부터 끝까지 테스트하세요.
입력 검증은 LLM에 도달하기 전에 이루어져야 합니다. 인코딩된 쿼리, 다중 의도 공격, 기본적인 인젝션 시도는 하위 서비스에 맡기지 말고 시스템 경계에서 차단해야 합니다.
시스템 간 접점을 신뢰하지 마세요. 여러 서비스로 구성된 아키텍처에서는 가장 주목할 만한 취약점이 시스템 사이의 틈에 숨어 있습니다. 제로 트러스트는 말 그대로 어떤 것도 신뢰하지 않는다는 뜻이므로 모든 계층에서 모든 것을 검증하세요.
단순한 공격도 통합니다. 정교한 탈옥은 크게 주목받지만, 때로는 그저... 물어보면 됩니다. 사용자가 겉보기에는 정상적인 쿼리에 내부 식별자를 포함했다는 이유만으로 시스템이 이를 거리낌 없이 노출한다면 문제입니다.
실제로 무엇을 테스트하는지 이해하세요. 알려진 공격 패턴은 애플리케이션에 적용한 가드레일이 아니라 LLM 자체의 학습을 통해 차단될 수도 있습니다. 어떤 통제 장치가 실제로 작동하는지 파악할 수 있도록 레드팀 테스트에 관측 가능성을 구축하세요.
제약이 있는 환경에는 창의적인 해결책이 필요합니다. 커스텀 프로바이더와 로컬 모델 지원을 활용하면 특수한 클라우드 액세스 없이도 실질적인 레드팀 테스트를 수행할 수 있습니다. 다만 이로 인해 생기는 한계는 투명하게 공개해야 합니다.
레드팀 테스트는 일회성 작업이 아닙니다. 반복적으로 진행하고 가능한 경우 자동화해야 하며, 시스템의 변화에 맞춰 함께 발전해야 합니다. 내일 중요한 공격은 오늘 중요한 공격과 다릅니다.
규제 환경의 AI 시스템에 대한 감시는 앞으로 더욱 엄격해질 것입니다. 보안 테스트를 출시 전에 한 번 확인하고 넘어가는 절차가 아니라 지속적으로 수행해야 할 활동으로 여기는 조직이 이러한 엄격한 검증에 더 잘 대응하고, 고객의 신뢰를 잃게 만드는 PR 위기도 피할 수 있습니다.