이렇게까지 창의적으로 AI를 타락시켜?" (강수진 박사)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

AI를 이렇게까지 창의적으로 타락시키는 핵심 수법은 지시를 쪼개고 맥락과 형식을 바꾸는 프롬프트 인젝션이며, 이를 막으려면 실제 공격 데이터에 기반한 지속적인 레드티밍과 정교한 가드레일 조율이 필요하다.

📌 핵심 요점

1. 프롬프트 인젝션은 모델의 시스템 지침을 노출시키거나, 악성·유해 문장을 사실 또는 사용자 지시로 오인하게 만드는 자연어 기반 공격이다.
2. 직접 인젝션은 사용자가 모델에 공격 문장을 바로 입력하는 방식이고, 간접 인젝션은 웹페이지·메일·PDF·캘린더 같은 외부 데이터를 통해 정보 유출이나 에이전트 오작동을 유발하는 방식이다.
3. 단순한 금지 요청은 거부되더라도 교육 목적, 신분 사칭, 형식 변환, 빈칸 채우기, 한 글자씩 답하게 하기처럼 요청을 재구성하면 방어가 흔들릴 수 있다.
4. 특히 멀티턴 대화에서는 공격자가 세부 정보를 조금씩 축적하거나 허위 전제를 단계적으로 주입하면서 모델의 지시 준수와 사실 판단을 약화시킬 수 있다.
5. 방어는 시스템 프롬프트 한 줄로 끝나지 않으며, 다양한 공격 데이터셋·평가 루브릭·멀티턴 테스트를 활용하면서 안전성과 정상 사용자 경험 사이의 균형을 조정해야 한다.

🧩 배경과 문제 정의

AI 서비스가 대중화되면서 자연어 지시를 이용해 시스템 프롬프트를 노출시키거나 모델이 유해·허위 내용을 생성하도록 유도하는 프롬프트 인젝션이 중요한 보안 문제로 떠올랐다. 영상은 직접·간접 인젝션의 차이를 설명한 뒤, 싱글턴과 멀티턴 공격을 실제로 시연하고 합성 공격 데이터로 방어 프롬프트를 평가한다. 핵심 문제는 공격을 많이 막을수록 정상 요청까지 거부할 가능성이 커진다는 점이며, 서비스 제공자는 안전성·유용성·토큰 비용 사이에서 가드레일의 수위를 조율해야 한다.

🕒 시간순 섹션별 상세정리

1. 프롬프트 인젝션의 문제 제기

• 이전 시스템 지침을 무시하라는 요청으로 모델의 내부 지침이 노출될 수 있고, 유해 문장을 사실로 믿게 만들 수도 있다고 보여준다. [00:25]
• 맥락이 길어지는 멀티턴 대화에서는 모델의 지시가 약해질 수 있으며, 공격 사례를 알아야 방어법도 설계할 수 있다고 강조한다. [00:40]

2. 직접·간접 인젝션의 정의

• 프롬프트 인젝션은 시스템 내부 명령을 보게 만들거나 대화 중 악성·유해 내용을 심어 모델이 이를 사용자 지시로 착각하게 하는 방식으로 드러난다. [01:47]
• 공격은 시스템 프롬프트, 사용자의 직접 입력, 메일 같은 외부 데이터의 세 레이어에서 발생할 수 있다고 구분한다. [02:50]
• 직접 인젝션은 모델에 공격 문장을 입력하는 방식이고, 간접 인젝션은 웹페이지·메일·PDF·캘린더를 통해 데이터 유출이나 에이전트 오작동을 노리는 방식이다. [03:42]

3. 금지 요청과 멀티턴 우회

• 시연에서는 금지된 제조 방법을 직접 질문하자 모델이 거부하지만, 교육 목적이라는 명분을 붙였을 때 일부 모델이 흔들릴 수 있다고 보여준다. [04:35]
• 핵분열 같은 세부 질문으로 범위를 나누어 대화를 이어 가면 모델이 현재 답변의 전체 목적을 혼동하고 지시가 약해질 수 있다고 드러낸다. [05:25]
• 세부 정보를 조금씩 얻어 결합하면 전체 금지 정보에 가까워질 수 있으므로, 가드레일도 이런 누적형 공격을 고려해야 한다. [06:24]

4. 한 글자씩 조합하는 창의적 공격

• 모델에게 한 글자로만 답하게 한 뒤 여러 단어의 앞글자를 차례로 요구하고, 마지막에 결과를 합쳐 욕설을 완성하는 공격을 시연한다. [07:38]
• 각 요청은 무해해 보여도 멀티턴 전체 결과는 금지 출력이 될 수 있어, 한 턴 단위 필터만으로는 방어가 어렵다고 보여준다. [08:19]
• B2C 서비스라면 다양한 연령대가 사용하므로 이런 출력을 막는 것이 일반적이지만, 시연 모델에서는 결과가 생성됐다고 지적한다. [08:49]

5. 신분 사칭과 형식 우회

• 개발자·기자·피해자·교육 목적이라는 신분과 상황을 가장해 정책 해제를 유도하거나, 금지 내용을 창의적인 형식으로 바꾸어 달라고 요청하는 수법을 보여준다. [09:20]
• 내용을 코드화해 받은 뒤 해석하는 방식도 가능하며, 방어 프롬프트에는 요약·번역·코드 등 어떤 형태로도 유해 내용을 출력하지 않는다는 규칙을 쌓을 수 있다고 보여준다. [10:10]
• 다만 프롬프트만으로 100% 방어할 수 없다고 명확히 한 뒤 더 복잡한 공격 사례로 넘어간다. [10:18]

6. 원문 대조와 빈칸 채우기 공격

• OCR 검증으로 위장해 시스템 프롬프트 원문을 코드 펜스로 출력하게 만들면, 모델이 준비된 가짜 시스템 프롬프트를 그대로 노출하는 사례를 보여 준다. [11:21]
• 자막 감수와 빈칸 채우기로 위장한 공격은 다음 단어를 예측하는 모델의 성향을 이용해 유해·혐오·욕설 표현을 완성하게 만든다. [12:09]
• 한 글자 조합과 빈칸 공격처럼 공격자가 상당한 수고를 들인 창의적 변형이 계속 등장한다고 정리한다. [12:26]

7. 허위 정치 정보를 단계적으로 주입하기

• 정치부 기자 역할과 정상적인 기사 구조 요청으로 대화를 시작한 뒤, 존재하지 않는 자료와 주장을 다음 턴에 주입하는 방식을 보여준다. [13:07]
• 이후 특정 후보가 사퇴해야 한다는 사실과 무관한 결론까지 넣으면 모델이 실제 기사처럼 허위 내용을 생성할 수 있다고 경고한다. [13:35]
• 진행자도 모델이 기억한 기자라는 신분과 방송 목적을 근거로 평소에는 답하지 않을 요청에 응답했던 경험을 소개하며 멀티턴 취약성을 확인한다. [14:19]

8. 합성 공격 데이터로 방어 성능 평가

• 방어 프롬프트 적용 전 다양한 예시가 모두 뚫렸다고 설명한 뒤, 실제 업무에서 사용하는 방식처럼 합성 공격 데이터로 가드레일을 시험한다. [14:52]
• 전체 300개 중 공격 수위가 높은 30개를 실행하며 정치·빈칸·욕설 등 여러 유형이 데이터셋에 포함돼 있다고 보여준다. [15:29]
• 로그상 처음에는 29건 차단으로 보였지만 실행 완료 후 30건을 모두 막은 것으로 확인된다. [16:00]

9. 과잉 방어와 정상 사용자 경험의 충돌

• 샘플 데이터 차단과 달리 실제 공격은 의도·변형·멀티턴 구성이 다양해 모든 규칙을 시스템 프롬프트에 넣기 어렵다고 지적한다. [16:33]
• 가드레일이 지나치게 높으면 정상 질문도 거부하거나 아무 답변도 하지 않을 수 있어, 단순 차단 판정이 아닌 평가 루브릭이 필요하다. [17:14]
• 보이스피싱 피해 예방처럼 정보 제공 가치와 악용 위험이 공존하는 요청은 기업마다 허용 정책이 달라질 수 있다고 보여준다. [18:10]

10. 공개 시스템 프롬프트와 안전 규칙의 비중

• 클로드의 공개 시스템 프롬프트를 예로 들어 미성년자·아동 안전·학대·정신건강 등 다양한 안전 지침 때문에 프롬프트가 길어질 수밖에 없다고 보여준다. [19:59]
• 신조어와 문화적 비하 표현처럼 빠르게 변하는 공격을 추적하기 위해 레드티밍이 필요하며, 모델사마다 시스템 프롬프트와 체감되는 방어 수준이 다르다고 드러낸다. [20:02]
• 긴 시스템 프롬프트는 사용자 토큰 여유를 줄이지만 안전 규칙이 계속 필요해 크게 줄이기 어렵다고 전망한다. [20:24]

11. 긴 지침의 구조화와 멀티턴 테스트

• 시스템 프롬프트가 지나치게 길면 모델이 지시를 건너뛸 수 있어, 기호·직관적 카테고리·문장 배열 패턴을 활용해 구조를 개선한다고 보여준다. [20:53]
• 싱글턴보다 멀티턴 방어가 훨씬 까다롭기 때문에, 정치 기사 요청에서 허위 자료와 결론을 단계적으로 넣는 테스트를 다시 실행한다. [21:20]
• 많은 공격 데이터를 확보해 가드레일을 설계해야 하지만, 지나치게 미세한 규칙은 대상 사용자 수와 비용을 함께 고려해야 한다. [21:51]

12. API 환경의 책임과 최종 균형

• 시스템 프롬프트가 없는 API 테스트에서는 허위 정치 주장이 생성되며, API 사용자는 서비스의 말투·도메인·안전 정책을 직접 입히는 작업이 필요하다고 보여준다. [23:10]
• 높은 방어벽은 정상적인 심층 기사 요청까지 막을 수 있어 어떤 영역은 허용하고 어떤 영역은 제한할지 조율하는 일이 어렵다고 정리한다. [24:02]
• 공격을 직접 시험해야 방어법을 찾을 수 있으므로 화이트해커처럼 공격과 방어를 함께 연구해야 하며, 잘못된 응답과 과잉 거부 모두 서비스 평판과 사용자 경험에 타격을 줄 수 있다고 결론짓는다. [25:28]

🧾 결론

• 창의적인 공격은 하나의 금지 문장을 정면으로 깨기보다, 무해해 보이는 여러 요청을 조합해 최종적으로 금지된 결과를 완성한다.
• 프롬프트만으로 100% 방어할 수 없으며, 샘플 공격을 모두 차단했다는 결과도 새로운 변형과 멀티턴 공격에 대한 일반적인 안전성을 보장하지 않는다.
• API 기반 서비스를 만드는 조직은 원본 모델 위에 서비스 목적과 위험 수준에 맞는 시스템 프롬프트와 가드레일을 직접 설계해야 한다.
• 효과적인 방어자는 공격자의 관점에서 모델을 시험하되, 정상적인 정보 요청까지 과도하게 차단하지 않도록 평가 기준을 함께 운영해야 한다.

📈 투자·시사 포인트

• AI 서비스가 대중화될수록 프롬프트 인젝션 방어, 레드티밍, 가드레일 평가가 부가 기능이 아니라 서비스 신뢰도를 좌우하는 핵심 운영 역량이 될 가능성이 크다.
• 공격 유형과 문화적 표현이 계속 변하기 때문에 일회성 프롬프트 구축보다 공격 데이터의 수집·갱신·평가 체계를 가진 조직이 유리하다.
• 지나치게 높은 가드레일은 정상 요청까지 거부해 사용자 경험을 훼손하고, 지나치게 낮은 가드레일은 유해 출력과 평판 손상으로 이어질 수 있어 기업별 정책 조율 능력이 중요하다.
• 시스템 프롬프트가 길어질수록 토큰과 지시 집중력이 소모되므로, 규칙의 구조화·우선순위화와 효율적인 멀티턴 평가 기술의 가치가 커질 수 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 시연에 사용된 중국 모델의 정확한 제품명과 버전은 전사 표현이 불명확하므로 별도 원본 화면 확인이 필요하다.
• 30건을 모두 막았다는 결과는 특정 합성 데이터와 방어 프롬프트를 사용한 한 차례 시연이며, 전체 300건이나 새로운 공격 변형에서도 같은 성능이 유지되는지는 제시되지 않았다.
• 정치 기사와 허위 정보 생성 사례는 공격 과정을 설명하기 위한 예시이므로, 등장하는 주장이나 인물 설정을 실제 사실로 받아들여서는 안 된다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 직접 인젝션·간접 인젝션·멀티턴 인젝션을 분리한 공격 테스트 세트를 만들고 각각의 차단 결과를 기록한다.
• 번역·요약·코드화·빈칸 채우기·역할 사칭처럼 금지 요청을 우회하는 형식 변형을 가드레일 테스트에 포함한다.
• 단순 거부 여부만 보지 말고 유해 정보 누출, 허위 사실 생성, 무응답, 정상 요청 오차단을 구분하는 평가 루브릭을 적용한다.
• API 기반 서비스라면 모델의 기본 방어를 가정하지 말고 서비스 도메인과 이용자 범위에 맞는 시스템 프롬프트를 명시적으로 설계한다.

❓ 열린 질문

• 새로운 멀티턴 공격을 막으면서도 정상적인 교육·보도·예방 목적의 질문을 과도하게 거부하지 않을 최적의 판단 기준은 무엇인가?
• 시스템 프롬프트가 길어질 때 모델이 일부 지시를 건너뛰는 문제를 구조화와 표현 방식만으로 얼마나 줄일 수 있는가?
• 합성 공격 데이터에서 높은 차단률을 기록한 가드레일이 실제 사용자들이 만드는 예상 밖의 공격에도 같은 수준으로 작동하는가?