AI 가드레일은 보안 경계가 아닙니다

모델의 안전 계층(safety layer)이 단 몇 분 만에 제거될 수 있다면, 개발자들은 이를 하루 동안 구경하며 지나갈 스캔들이 아니라 설계상의 경고로 취급해야 합니다.

최근 Financial Times의 보고서에 따르면, Meta와 Google의 AI 모델에서 가드레일(guardrails)이 매우 빠르게 제거될 수 있다는 신호가 포착되었습니다. 이는 기존 기업들의 가정, 즉 '모델을 구매하고, 안전 설정을 켠 뒤, 바로 출시한다'는 가정을 흔들 만큼 강력합니다. 그 가정은 언제나 지나치게 깔끔했습니다. 그것은 모델의 동작(model behavior)과 시스템 보안(system security)을 혼동하고 있습니다.

가드레일은 중요합니다. 가드레일은 명백한 해악을 줄이고, 태만한 오용을 차단하며, 일반적인 사용자 상호작용을 더 안전하게 만듭니다. 하지만 가드레일은 벽이 아닙니다. 그것은 안전벨트에 더 가깝습니다. 유용하고 때로는 생명을 구하기도 하지만, 브레이크, 도로 규칙, 그리고 깨어 있는 운전자를 대체할 수는 절대 없습니다.

개발자들이 계속 저지르는 실수

많은 AI 애플리케이션 설계가 여전히 프롬프트(prompt) 내부에 너무 많은 신뢰를 두고 있습니다. 시스템 프롬프트(system prompt)는 모델이 무엇을 해야 하는지 말합니다. 정책 계층(policy layer)은 모델이 무엇을 거부해야 하는지 말합니다. 도구 지침(tool instructions)은 모델이 무엇을 건드릴 수 있는지 말합니다. 그런 다음 애플리케이션은 모델에게 파일, 메시지, 데이터베이스 레코드, 지원 티켓 또는 결제 워크플로우에 대한 접근 권한을 부여합니다.

바로 이 지점에서 리스크의 형태가 변합니다. 잘못된 답변을 내놓는 챗봇은 하나의 문제입니다. 하지만 도구, 메모리, 그리고 권한을 가진 챗봇은 전혀 다른 차원의 문제입니다.

만약 모델만이 어떤 행동이 안전한지 결정하는 유일한 요소라면, 당신은 매우 예의 바른 보안 경계(security boundary)를 구축한 것입니다. 예의 바른 경계는 누군가가 그 경계를 우회하여 대화하는 법을 배우게 되면 무너집니다.

가드레일이 잘하는 것

가드레일은 그것이 잘하는 계층, 즉 출력이 사용자에게 도달하기 전에 나쁜 출력을 줄이는 용도로 사용하십시오. 가드레일은 유해한 텍스트(toxic text), 명백한 정책 위반, 탈옥 시도(jailbreak attempts), 민감한 데이터 유출, 그리고 저급한 수준의 남용을 잡아낼 수 있습니다. 또한 여러 팀이 동일한 모델을 기반으로 구축할 때 일관성을 유지하는 데에도 도움이 됩니다.

그것이 진정한 가치입니다. 저는 모든 소규모 앱 팀이 안전 규칙 (safety rules)을 처음부터 직접 만드는 것을 원하지 않습니다. 대부분의 팀은 이 모든 것을 혼자서 발명할 수 있다고 가장하는 것보다 모델 제공자의 제어 기능 (controls), 모더레이션 엔드포인트 (moderation endpoints), 평가 스위트 (evaluation suites), 그리고 정책 검사 (policy checks)를 사용하는 것이 훨씬 더 낫습니다.

하지만 작업은 거기서 끝나지 않습니다. 거절 메시지 (refusal message)가 접근 제어 (access control)는 아닙니다. 더 안전한 모델이 권한 시스템 (permissions system)은 아닙니다. 잘 작성된 지침 (instruction)이 샌드박스 (sandbox)는 아닙니다.

가드레일이 실패할 것이라고 가정하고 설계하는 방법

실질적인 해답은 지루하며, 이는 보안 분야에서 보통 좋은 신호입니다.

• AI에게 필요한 최소 권한 (least privilege)만 부여하십시오. 만약 AI가 송장 (invoices)을 요약하기만 하면 된다면, 송장을 삭제할 수 있는 권한을 주지 마십시오.

• 도구 호출 (tool calls)을 일반적인 서버 측 권한 부여 (server-side authorization) 뒤에 두십시오. 모델은 동작을 요청할 수 있지만, 해당 동작이 허용되는지 여부는 백엔드 (backend)에서 결정해야 합니다.

• 읽기와 쓰기를 분리하십시오. 모델이 운영 데이터 (production data)를 변경하기 전에 초안을 작성하거나, 미리 보거나, 권장하도록 하십시오.

• 비용이 많이 들거나, 파괴적이거나, 공개적인 동작에 대해서는 확인을 요구하십시오. 모델이 확신에 찬 어조로 말한다고 해서 이메일 전송, 카드 결제, 데이터 삭제, 콘텐츠 게시가 이루어져서는 안 됩니다.

• 프롬프트 (prompts), 검색된 컨텍스트 (retrieved context), 도구 호출 (tool calls), 거절 (refusals), 그리고 사용자 확인 (user confirmations)을 로그 (log)로 남기십시오. 문제가 발생했을 때, 무슨 일이 일어났는지 설명할 수 있는 흔적이 필요합니다.

• 해피 패스 (happy path) 데모뿐만 아니라 적대적인 프롬프트 (hostile prompts)로 테스트하십시오. 앱이 신뢰할 수 없는 콘텐츠를 읽는다면 프롬프트 인젝션 (Prompt injection)은 QA 체크리스트의 일부가 되어야 합니다.

이는 개발자들이 이미 다른 곳에서 사용하는 것과 동일한 사고방식입니다. 브라우저에서의 폼 검증 (form validation)을 믿고 서버 측 검증을 건너뛰지 않습니다. 친절한 UI를 믿고 데이터베이스 권한 (database permissions)을 건너뛰지 않습니다. AI 역시 인터페이스가 대화형이라는 이유만으로 마법 같은 예외를 받아서는 안 됩니다.

이 지점이 불편해지는 부분

불편한 지점은 개방적이고 커스터마이징 가능한 모델(open and customizable models)이 이러한 트레이드오프(tradeoff)를 더욱 날카롭게 만든다는 것입니다. 빌더(Builders)들은 로컬 모델, 미세 조정 (fine-tuning), 낮은 비용, 프라이빗 배포 (private deployment), 그리고 제공업체의 제한이 적은 환경을 원합니다. 이는 타당한 이유들이며, 저 또한 그러한 방향을 지지합니다. 소수의 호스팅된 API가 모든 AI 기능을 통제하지 않을 때 웹은 더 건강해집니다.

하지만 유연성은 안전 동작 (safety behavior)이 변경되거나, 제거되거나, 우회될 수 있음을 의미하기도 합니다. 주변 시스템이 잘 설계되어 있다면 내부 도구(internal tools)의 경우에는 이것이 허용될 수 있습니다. 그러나 소비자용 앱, 규제 대상 워크플로우 (regulated workflows), 아동용 제품, 건강 조언, 또는 돈과 관련된 그 어떤 것이라도 이 문제를 쉽게 무시하기는 어려워집니다.

정답은 '개방형 모델을 절대 사용하지 마라' 또는 '폐쇄형 모델만 신뢰하라'가 아닙니다. 그것은 너무 단순한 접근입니다. 정답은 모든 것이 잘 돌아갈 때 무엇을 거부하겠다고 약속하느냐만이 아니라, 모델이 실패했을 때 무엇을 할 수 있도록 허용할 것인지를 결정하는 것입니다.

빌더의 체크리스트 (A builder's checklist)

실제 권한을 가진 AI 기능을 출시하기 전에 다음 질문들을 던져보십시오:

• 모델이 무엇을 읽을 수 있는가?
• 모델이 무엇을 쓰고(write) 또는 트리거(trigger)할 수 있는가?
• 신뢰할 수 없는 텍스트가 모델의 지침 (instructions)에 영향을 줄 수 있는가?
• 사용자나 문서가 모델을 속여 개인 데이터를 드러내게 할 수 있는가?
• 모델이 시스템 프롬프트 (system prompt)를 무시하면 어떻게 되는가?
• 어떤 동작에 인간의 클릭이 필요한가?
• 실패 사례를 어디에서 검토하는가?

만약 답변이 모호하게 느껴진다면, 그 앱은 아직 광범위한 접근을 받아들일 준비가 되지 않은 것입니다. 그렇다고 개발을 중단하라는 뜻은 아닙니다. 범위를 좁히고, 중요한 부분에 마찰 (friction)을 추가하며, 위험한 동작을 모델의 직접적인 영향력 밖으로 옮기라는 의미입니다.

유용한 시사점 (The useful takeaway)

AI 가드레일 (guardrails)은 여전히 사용할 가치가 있습니다. 다만 그것들을 자물쇠처럼 취급하는 것만 멈추십시오.

개발자에게 더 안전한 패턴은 간단합니다. 모델은 추론 (reason), 초안 작성 (draft), 분류 (classify), 요약 (summarize), 제안 (suggest)을 하게 두십시오. 대신 여러분의 애플리케이션이 신원 (identity), 권한 (permissions), 속도 제한 (rate limits), 확인 (confirmations), 그리고 감사 로그 (audit logs)를 강제하도록 하십시오. 모델은 똑똑할 수 있습니다. 하지만 그 주변의 시스템은 완고해야 합니다.

참고 문헌 (References)

참고 문헌 (References)

• Financial Times: AI guardrails stripped from Meta and Google models in minutes

• Hacker News discussion of the Financial Times guardrails report

• OWASP GenAI Security Project: LLM01 Prompt Injection

• NIST AI Risk Management Framework

원래 게시된 곳: https://blog.jenuel.dev/blog/ai-guardrails-are-not-security-boundaries