프롬프트 인젝션이 새로운 SQL 인젝션인 이유

관찰

2000년대 초반, SQL 인젝션은 웹 애플리케이션 보안의 가장 큰 위협이었다. 개발자들은 사용자 입력을 그대로 SQL 쿼리에 연결하는 관행을 바꾸지 못해 수많은 데이터 유출 사고를 경험했다. 현재 LLM 기반 시스템에서 발생하는 프롬프트 인젝션은 정확히 동일한 패턴을 보인다.

통찰

두 공격의 공통점은 ‘입력과 명령어의 경계 미구분’ 이다. SQL에서 사용자 입력이 쿼리 구조를 변경할 수 있었던 것처럼, LLM에서 사용자 입력이 시스템 프롬프트를 덮어쓸 수 있다. 이는 단순한 기술적 유사성을 넘어, 새로운 컴퓨팅 패러다임이 도입될 때마다 반복되는 보안 사고의 전형적인 패턴이다.

시사점

• 파라미터화된 쿼리 교훈: SQL 인젝션을 해결한 ‘파라미터화된 쿼리’처럼, LLM에도 ‘구조화된 프롬프트 템플릿’이 필요하다.
• 자만의 위험: “우리는 이미 알고 있다”는 착각이 가장 위험하다. 2000년대 개발자들도 SQL 인젝션을 알았지만, 실제로 방어하지 않았다.
• 새로운 취약점 클래스: 프롬프트 인젝션은 ‘인젝션’이라는 이름을 공유하지만, AI 특화된 새로운 방어 체계가 필요하다.

질문

• LLM 시스템에서 ‘파라미터화된 프롬프트’를 구현할 수 있는가?
• 현재의 방어 기법이 공격자의 진화 속도를 따라잡을 수 있는가?

연결된 생각

• 20260814-blast-radius-over-prevention-in-agent-security — 위 질문에 대한 실무자의 답: 파라미터 바인딩에 해당하는 해법이 아직 없으므로, 방어 목표를 예방에서 폭발 반경 축소로 옮겨야 한다
• 20260814-agent-security-as-renamed-legacy-security — SQL 인젝션 외에도 사회공학적 해킹→jailbreak, 하드코딩 API 키→시스템 프롬프트 유출로 이어지는 전체 대응 지도