[AI/보안] 대시보드는 '초록불'인데, 챗봇은 거짓말을 하고 있다: AI 보안을 바라보는 완전히 새로운 시각

메타인지 월드 2026. 11. 9. 00:00

우리가 매일 쓰는 챗봇이나 AI 서비스. "서버 다운 없음, 에러율 0%"라며 대시보드는 온통 평온한 초록불인데, 알고 보니 AI가 고객들에게 엉뚱한 환불 규정을 3주 동안이나 안내하고 있었다면 어떨까요?

전통적인 IT 세상에서는 서버가 죽거나 에러 코드가 뜰 때 장애를 알아차립니다. 하지만 AI 시대의 장애는 아주 조용하고 우아하게 찾아옵니다. 인프라는 멀쩡한데, '콘텐츠(내용)'가 망가져 있기 때문입니다.

IT 보안 전문가나 플랫폼 엔지니어들이 왜 기존의 보안 상식을 과감히 내던지고 AI 보안을 완전히 다른 눈으로 봐야 하는지, 그 흥미로운 쟁점들을 짚어봅니다.

1. AI는 왜 기존 보안 방식으로 지킬 수 없을까?

우리가 흔히 아는 소프트웨어는 '결정론적(Deterministic)'입니다. 똑같은 입력값을 넣으면 프로그램은 항상 똑같은 결과값을 뱉어냅니다. 그래서 단위 테스트를 짜고, 코드를 비교해서 바뀐 점을 찾아내기가 쉽습니다.

하지만 LLM(대형 언어 모델)은 '확률론적(Probabilistic)'입니다. 똑같은 질문을 던져도 모델은 가장 그럴듯한 다음 단어를 확률적으로 꺼내놓기 때문에, 매번 답변의 결이 조금씩 달라집니다.

"이 코드가 정확히 이렇게 작동할 거야"라고 단언할 수 없습니다.
컴파일러나 단위 테스트가 AI의 '말버릇'이나 '거짓말(환각)'을 미리 잡아주지 못합니다.

따라서 AI 시대의 보안은 "서버가 절대 죽지 않게 막는다"가 아니라, "AI의 행동과 콘텐츠가 기준선 안에서 잘 움직이고 있는지 끊임없이 측정한다"는 SRE(사이트 신뢰성 엔지니어링) 관점으로 완전히 판을 갈아야 합니다. 배포 전 테스트를 한 번 하고 끝내는 건 계기판이 아니라 그냥 '기념사진' 한 장 찍어두는 것과 다를 바 없습니다.

2. 수많은 해킹 위협 중, 대체 무엇부터 막아야 할까?

보안 책이나 프레임워크를 펼치면 수십 가지의 경고와 해킹 시나리오가 쏟아집니다. 하지만 현업에 치이는 엔지니어들에게 "이 열 가지 위험을 똑같이 중요하게 관리하라"는 건 "아무것도 하지 말라"는 말과 같습니다.

무시무시한 해킹 기술보다 '도달 가능성(Reachability)'을 최우선으로 볼 것을 조언합니다.

고급 해커가 내부망을 뚫고 들어오는 복잡한 익스플로잇은 생각보다 비용이 많이 듭니다.
반면, 프롬프트 인젝션(Prompt Injection)은 특별한 도구도 필요 없이, 그냥 평범한 사용자가 챗봇 창(텍스트 박스)에 글을 입력할 수만 있다면 시작하는 첫날부터 누구나 무료로, 무한정 시도할 수 있습니다.

누구나 정문으로 쉽게 들어와서 시스템을 흔들 수 있기 때문에, 프롬프트 인젝션이 모든 위협의 최상단(Tier 1)에 위치해야 하는 것입니다.

3. 위험을 점수 매길 때, "곱하기"를 쓰면 안 되는 이유

전통적인 보안 업계에서는 위험을 평가할 때 보통 이렇게 계산했습니다.

위험 = 위협 X 취약점 X 영향력

모든 조건이 맞물려 돌아가야 사고가 난다는 'AND(곱셈) 논리'였죠.

하지만 AI 보안, 특히 '은밀함(Silence/탐지 불가능성)'이라는 축을 다룰 때 이 곱셈 공식은 치명적인 함정을 만듭니다.

"눈에 잘 띈다고 해서 안전한 것은 아니다 (Easy to see is not 'safe')"

만약 어떤 공격이 너무 노골적이어서 로그에 대놓고 다 찍힌다고 해봅시다. 전통적 곱셈 공식에 따르면 "탐지가 잘 되니까(은밀함 점수가 낮으니까) 전체 위험 점수도 낮아지겠네?"라며 방심하게 만듭니다.

하지만 공격이 대놓고 이루어졌든 숨어서 이루어졌든 간에, 시스템이 거기에 속아 넘어가 회사의 결제 승인을 내려버리거나 고객 정보를 유출해 버린다면(파급 범위가 크다면) 팀 입장에선 가장 먼저 고쳐야 할 대형 사고입니다.

보기 쉽다는 이유로 위험 점수를 깎아내리는 곱셈은 AI 시스템의 현실과 맞지 않습니다. 그래서 복잡한 수식 놀음이나 '가짜 정밀함'을 버리고, 각 요소의 무게를 정직하게 더해서(Addition) 팀이 서로 치열하게 논쟁하고 우선순위를 합의하는 '실무적 정렬 도구'로 써야 합니다.

💡 글을 마치며: 완벽한 벽은 없다, 오직 끊임없는 관측만 있을 뿐

AI 시스템의 보안은 방화벽으로 단단한 성벽을 쌓아 올리는 일이 아닙니다. 텍스트와 데이터가 뒤섞여 들어오는 구조 속에서, AI가 언제든 엉뚱한 길로 샐 수 있음을 인정하고 출발해야 합니다.

대시보드가 고요해도 콘텐츠는 썩어갈 수 있고,
화려한 해킹 기술이 아니라 평범한 텍스트 박스가 가장 위험한 통로가 되며,
완벽한 점수 계산식보다 팀이 머리를 맞대고 정하는 우선순위가 더 강력한 방어선이 됩니다.

AI를 도입하는 모든 플랫폼 팀이 "코드가 배포되면 끝"이 아니라, "AI의 행동을 SLO(서비스 수준 목표)로 묶어 끊임없이 관측하는" 운영의 체계로 눈을 돌려야 하는 이유입니다.