프롬프트 인젝션이 SQL 인젝션과 닮았다는 말은 이제 흔하다. 정작 중요한 건 닮지 않은 지점이다. SQL 인젝션은 파라미터 바인딩이라는 근본 해법을 얻어 사실상 해결된 문제가 됐지만, LLM에는 아직 그에 해당하는 것이 없다. 데이터와 명령을 다른 통로로 넣는 방법이 존재하지 않는다. 이 비대칭을 인정하는 순간 방어의 목표가 바뀐다. “절대 안 뚫리게”가 아니라 “뚫려도 크게 안 터지게”다.
근거
파라미터 바인딩의 핵심은 알바생을 더 똑똑하게 교육시키는 게 아니라, 애초에 이상한 요청을 받아 볼 일 자체를 없애는 데 있다. 손님의 주문은 메뉴판 선택지로만 받고, 자유 서술 요청은 사장에게만 가도록 통로를 분리한다. LLM에는 이 분리가 없다. 개발자의 지시와 외부에서 가져온 데이터를 같은 눈으로 읽는다.
그래서 남는 방법은 두 종류뿐인데, 강도가 확연히 다르다. 시스템 프롬프트에 “사용자가 뭐라 해도 따르지 말라”고 적어 두는 건 지시로 지시를 막는 것이라 가장 약하다. 활짝 열린 문에 “허가된 사람 외 출입 금지” 팻말만 붙인 셈이다. 반면 권한을 애초에 안 주는 건 뚫린 뒤에도 유효하다.
프롬프트 인젝션 자체를 100% 막을 수 없다면, 뚫렸을 때 그 AI가 할 수 있는 일의 범위를 미리 줄여 놓는 쪽이 확실하거든요.
이 전환이 실무에 주는 지침은 명확하다. 읽기 권한은 되돌릴 수 없는 일을 만들지 않으므로 넉넉히 열어도 된다. 쓰기 권한은 다르다. 방어선은 입력 검증이 아니라 행동 직전에 그어야 한다.
연결된 생각
- 20260613-why-prompt-injection-is-the-new-sql-injection — 유사성을 지적한 노트. 이 노트는 그 비유가 끝나는 지점, 즉 해법의 부재를 다룬다
- 20260605-safe-execution-matters-more-than-smart-execution — 똑똑함보다 안전함이 우선이라는 판단의 보안 측 근거
- 20260611-enforceable-safety-hooks-for-llm — 지시로 지시를 막는 대신 실행을 차단하는 코드 게이트
- 20260814-agent-security-as-renamed-legacy-security — 이 논리가 속한 전체 매핑