생성형 AI 보안은 완벽한 통제가 아니라 피해 제한에서 시작된다

생성형 AI와 대규모 언어 모델을 사용하다 보면 한 가지 의문이 생깁니다.

충분한 안전장치를 적용하면 LLM을 완벽하게 통제할 수 있을까?

결론부터 말하면, LLM의 위험을 크게 줄이는 것은 가능하지만 모든 입력과 상황에서 원하는 대로만 동작하도록 완벽하게 통제하는 것은 현실적으로 매우 어렵습니다.

 

그 이유는 LLM이 일반적인 소프트웨어처럼 사람이 작성한 규칙만 실행하는 시스템이 아니라, 방대한 데이터에서 통계적 패턴을 학습한 신경망 모델이기 때문입니다.

 

이 글에서는 생성형 AI 보안을 “모델을 완벽히 묶어두는 기술”이 아니라 “모델이 실패하거나 우회되더라도 피해가 실제 시스템으로 번지지 않게 만드는 구조”라는 관점에서 정리해보겠습니다.

인공신경망은 생물학적 뉴런에서 출발했다

인공신경망은 인간의 뇌와 신경세포가 정보를 전달하는 방식에서 아이디어를 얻었습니다.

 

여러 입력을 받아 중요도를 계산하고, 일정한 조건을 충족하면 다음 뉴런으로 신호를 전달한다는 개념을 수학적으로 단순화한 것입니다.

입력값
→ 가중치 적용
→ 여러 입력값 결합
→ 활성화 함수
→ 출력값 전달

이러한 구조는 초기 인공신경망에서 CNN, RNN, LSTM을 거쳐 Transformer와 현대 LLM으로 발전했습니다.

인공신경망
→ CNN·RNN
→ LSTM·Attention
→ Transformer
→ GPT·Llama 등 LLM

다만 인공신경망이 실제 인간의 뇌를 그대로 복제한 것은 아닙니다. 생물학적 뉴런에서 기본 아이디어를 얻었을 뿐, 현대 LLM은 수많은 파라미터가 데이터의 패턴을 학습한 대규모 수학 모델에 가깝습니다.

 

따라서 생물학적 구조를 모방했기 때문에 통제가 불가능한 것이 아니라, 모델이 지나치게 크고 복잡한 확률적 시스템이기 때문에 모든 행동을 예측하기 어려운 것이라고 설명하는 편이 정확합니다.

LLM은 규칙을 실행하는 프로그램과 다르다

전통적인 프로그램은 개발자가 작성한 조건과 명령을 실행합니다.

if user_role == "admin":
    allow_access()
else:
    deny_access()

입력값과 프로그램 상태가 같다면 결과도 비교적 명확하게 예측할 수 있습니다.

 

반면 LLM은 입력된 문맥을 바탕으로 다음에 올 가능성이 높은 토큰을 계산합니다.

사용자 입력
→ 문맥과 토큰 관계 분석
→ 다음 토큰의 확률 계산
→ 토큰 선택
→ 같은 과정을 반복

예를 들어 모델은 다음과 같은 확률분포를 계산할 수 있습니다.

"보안" 다음에 올 토큰

정책: 35%
점검: 25%
취약점: 20%
시스템: 10%
기타: 10%

LLM의 출력은 이러한 확률 계산을 반복해 만들어집니다. Temperature와 같은 생성 설정이나 이전 대화 내용, 시스템 프롬프트, 외부 문서가 달라지면 결과도 달라질 수 있습니다.

 

즉, LLM은 정해진 답을 조회하는 데이터베이스가 아니라 문맥에 따라 결과를 생성하는 확률적 모델입니다.

완벽한 통제가 어려운 이유

LLM의 행동을 완전히 예측하기 어려운 이유는 단순히 출력에 무작위성이 있기 때문만은 아닙니다.

 

모델은 수십억에서 수조 개에 이르는 파라미터 사이의 복잡한 상호작용을 통해 결과를 생성합니다. 특정 입력이 내부에서 어떤 계산을 거쳐 최종 답변으로 이어졌는지를 사람이 모든 단계에서 명확하게 설명하기 어렵습니다.

 

또한 실제 LLM 서비스에는 모델만 존재하지 않습니다.

사용자 입력
→ 시스템 프롬프트
→ LLM
→ RAG 검색
→ 외부 도구 호출
→ 데이터베이스·API
→ 최종 응답

여기에는 다음과 같은 불확실성이 함께 존재합니다.

• 학습 데이터에 포함된 오류와 편향
• 처음 접하는 입력에 대한 일반화 실패
• 프롬프트 표현에 따른 결과 변화
• 직접·간접 프롬프트 인젝션
• RAG 문서에 포함된 악성 지시
• 도구 호출 과정의 권한 오용
• 모델 업데이트에 따른 행동 변화
• 여러 구성 요소를 결합하면서 발생하는 취약점

따라서 모델의 안전성만 높인다고 해서 전체 시스템의 보안이 자동으로 확보되지는 않습니다.

 

OWASP GenAI Security Project의 LLM Top 10도 이런 관점을 잘 보여줍니다. 2025 목록에는 Prompt Injection, Sensitive Information Disclosure, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector and Embedding Weaknesses 같은 항목이 포함됩니다. 대부분은 “모델이 나쁜 답을 했다” 하나로 끝나는 문제가 아니라, 모델이 애플리케이션·도구·데이터와 연결될 때 생기는 시스템 보안 문제입니다.

예측 불가능성과 보안 취약점은 구분해야 한다

LLM이 예상과 다른 답변을 생성했다고 해서 그것이 모두 보안 취약점은 아닙니다.

 

예를 들어 모델이 사실과 다른 내용을 답하는 환각은 신뢰성 문제입니다. 그러나 모델의 잘못된 답변이 시스템 명령으로 실행되거나, 중요한 의사결정에 사용되면 실제 보안 사고로 이어질 수 있습니다.

모델의 잘못된 출력
→ 사용자에게 참고 정보로만 제공
= 품질·신뢰성 문제

모델의 잘못된 출력
→ 서버 명령이나 금융 거래로 자동 실행
= 보안 사고 가능성

LLM의 예측 불가능성 자체가 곧 취약점인 것은 아닙니다.

 

하지만 예측하기 어려운 모델에 과도한 권한을 부여하고, 검증 없이 외부 시스템과 연결하면 그 불확실성이 취약점으로 전환될 수 있습니다.

생성형 AI 보안은 신뢰하지 않는 것에서 시작한다

LLM 보안에서 가장 중요한 원칙은 모델을 신뢰 가능한 보안 주체로 취급하지 않는 것입니다.

 

모델에게 “중요한 정보를 공개하지 마라”라고 지시했다고 해서 실제 접근 권한이 있는 비밀정보를 모두 전달해도 되는 것은 아닙니다. 시스템 프롬프트 역시 보안 경계가 아니라 모델에게 전달하는 지시문일 뿐입니다.

 

따라서 보안 통제는 모델 외부에서 강제해야 합니다.

LLM을 완전히 신뢰하지 않음
→ 입력 검증
→ 출력 검증
→ 최소 권한 적용
→ 도구 호출 통제
→ 중요 작업 승인
→ 감사 로그와 모니터링
→ 지속적인 공격 테스트

입력과 외부 문서를 신뢰하지 않는다

사용자 입력뿐 아니라 웹페이지, 이메일, PDF, RAG 문서에도 악성 지시가 포함될 수 있습니다.

 

LLM이 읽는 모든 데이터는 잠재적으로 공격자가 제어할 수 있는 입력으로 취급해야 합니다.

출력은 실행 전에 검증한다

LLM이 생성한 SQL, 코드, 명령어, API 인자를 그대로 실행해서는 안 됩니다.

 

스키마 검증, 허용 목록, 정책 검사, 실행 환경 격리 등의 절차가 필요합니다.

최소한의 권한만 제공한다

LLM이 연결된 도구에는 업무 수행에 필요한 최소 권한만 부여해야 합니다.

 

예를 들어 이메일 검색만 필요한 에이전트에 메일 전송이나 삭제 권한까지 부여하면 모델의 실수가 실제 사고로 확대될 수 있습니다.

중요한 작업은 사람의 승인을 거친다

결제, 계정 삭제, 권한 변경, 외부 전송과 같은 고위험 작업에는 Human-in-the-Loop 방식의 승인을 적용해야 합니다.

LLM의 작업 제안
→ 정책 검사
→ 사용자 또는 관리자 승인
→ 실제 실행

실패와 우회를 전제로 테스트한다

한 번의 프롬프트 테스트를 통과했다고 해서 모델이 안전한 것은 아닙니다.

 

표현 변경, 다국어 입력, 인코딩, 역할극, 간접 프롬프트 인젝션 등 다양한 변형을 이용해 지속적으로 점검해야 합니다.

완벽한 방어보다 피해를 제한하는 구조가 중요하다

생성형 AI 보안의 목표를 “모델이 절대 잘못된 행동을 하지 않도록 만드는 것”으로 설정하면 현실적인 보안 설계가 어려워집니다.

 

보다 현실적인 목표는 다음과 같습니다.

모델이 잘못 판단하거나 공격에 우회되더라도 중요한 데이터와 시스템에는 피해가 발생하지 않도록 만드는 것

이는 기존 보안의 Zero Trust 원칙과도 연결됩니다.

 

사용자를 무조건 신뢰하지 않는 것처럼 LLM도 무조건 신뢰하지 않아야 합니다. 모델의 출력은 하나의 요청이나 제안으로 취급하고, 실제 권한 판단과 실행 여부는 별도의 보안 계층이 결정해야 합니다.

사용자
→ LLM
→ 보안 Wrapper
   ├── 인증 확인
   ├── 권한 검사
   ├── 입력값 검증
   ├── 정책 적용
   └── 승인 여부 확인
→ 외부 도구 실행

이 구조에서는 LLM이 공격자의 지시를 따르더라도 보안 Wrapper가 허용되지 않은 동작을 차단할 수 있습니다.

 

NIST AI Risk Management Framework가 강조하는 방향도 이와 비슷합니다. AI 위험 관리는 한 번의 체크리스트로 끝나는 일이 아니라, Govern, Map, Measure, Manage 활동을 통해 개발·배포·운영 전 과정에서 반복적으로 수행해야 하는 관리 체계에 가깝습니다. 생성형 AI 보안도 모델 하나의 성능이나 안전 필터에만 기대기보다, 운영 정책·권한·검증·모니터링을 함께 설계해야 합니다.

생성형 AI 보안의 출발점

LLM은 뛰어난 성능을 제공하지만, 모든 상황에서 동작을 완벽하게 예측하거나 통제할 수 있는 시스템은 아닙니다.

 

그렇다고 LLM을 사용할 수 없다는 의미도 아닙니다. 자동차 사고 가능성이 있다고 자동차를 사용하지 않는 것이 아니라, 안전벨트와 브레이크, 교통 규칙을 함께 적용하는 것과 같습니다.

 

생성형 AI도 모델의 한계를 인정하고 여러 보안 계층을 함께 적용해야 합니다.

생성형 AI 보안은 모델을 완벽히 통제할 수 있다는 믿음이 아니라, 모델이 언제든 실패하거나 우회될 수 있다는 인식에서 시작됩니다.

모델의 예측 불가능성을 제거하려 하기보다, 그 불확실성이 실제 데이터 유출이나 권한 오용, 시스템 침해로 이어지지 않도록 설계하는 것이 생성형 AI 보안의 핵심입니다.

참고 자료

• OWASP GenAI Security Project — 2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps
• OWASP Foundation — Top 10 for Large Language Model Applications
• NIST — AI Risk Management Framework
• NIST AI Resource Center — AI RMF Core