AI 앱은 안전한가? 프로덕션 전 AI 시스템에 개발자가 반드시 구현해야 할 내용

출처: Dev.to

AI 안전은 소프트웨어 아키텍처 문제로 부상하고 있습니다. 수년간 개발자들은 좋은 시스템이 아키텍처가 청결할 때 테스트, 수정, 보안이 쉬워진다는 것을 배웠습니다. 명확한 경계를 두는 것이 중요합니다. 의존성이 중요합니다. 신뢰 경계를 두는 것이 중요합니다. 로그가 중요합니다. 실패 동작이 중요합니다.

AI 애플리케이션은那些 원칙을 없애지 않습니다. 오히려 그 중요성을 더 높입니다.

기본 앱은 입력을 받아 로직을 적용하고 출력을 반환합니다. AI 앱은 개방된 지시를 수용하고 개인 데이터 검색, 도구 호출, 파일 작성, 워크플로우 트리거, API 사용, 다른 시스템과 상호작용할 수 있습니다. AI 에이전트가 등장하면 애플리케이션은 단순히 응답하는 것이 아니라 계획하고 행동합니다. 이는 보안 모델을 변화시킵니다.

AI 앱은 안전할까요?

진실한 답변은: 충분히 생산 환경에 배치할 수 있지만, 오직 생산 시스템과 동일한 방식으로 설계될 때만 가능합니다.

AI 앱이 안전하지 않은 경우는 모델을 모든 것의 가운데 신뢰받는 뇌로 대하는 경우입니다. 그곳에서 많은 실제 실패가 시작됩니다. 팀은 모델을 내부 문서, 고객 데이터, 티켓 시스템, 코드 저장소, 데이터베이스 또는 관리자 도구에 연결합니다. 프로토타입은 작동하고 데모는 인상적입니다. 그 후 동일한 시스템이 생산 환경에 더 가깝게 이동하지만 권한, 로깅, 실패 복구 동작, 남용 사례에 대한 충분한 검토가 이루어지지 않습니다.

위험은 드물게 ‘AI가 악질이 된다’는 것이 아닙니다. 실제 위험은 더 단순합니다:

• AI 앱은 자신이 보아야 할 데이터가 아닌 정보를 보게 됩니다.
• AI 앱은 사용자가 받아서는 안 되는 정보를 전달합니다.
• AI 앱은 과도한 권한을 가진 도구를 호출합니다.
• AI 앱은 내용에 숨겨진 악의적인 지시를 따릅니다.
• AI 앱은 검증되지 않은 코드, 쿼리 또는 작업을 생성합니다.
• AI 앱은 신뢰받는 워크플로우를 통해 승인된 것처럼 보이는 비즈니스 작업을 생성합니다.

Why AI Apps Break Old Security Assumptions

전통적인 애플리케이션은 대체로 예측 가능한 경로를 가집니다. 사용자가 버튼을 클릭합니다. 백엔드는 요청을 검증합니다. 서비스는 알려진 작업을 수행합니다. 액세스 제어는 사용자가 허용되는지 결정합니다.

AI 앱은 다릅니다. 이는 instruction 계층이 유연하기 때문입니다.

사용자는 시스템에 내부 문서 요약, 코드 생성, 지원 사례 분류, 계약 데이터 추출, 답변 준비, 또는 작업 트리거와 같은 요청을 할 수 있습니다. 동일한 텍스트 상자면 검색 인터페이스, 코드 생성기, 데이터 추출기, 워크플로우 보조기, 명령 인터페이스가 될 수 있습니다.

그 유연성은 유용합니다. 하지만 위험하기도 합니다.

일반적인 앱에서는 악의적인 지시를 전달하려면 정의된 입력 필드를 이용해야 하지만, AI 앱에서는 지시 자체가 인터페이스입니다. 더 나아가 지시는 사용자 외부에서 올 수 있습니다. 모델은 이메일, 티켓, 웹 페이지, PDF 파일, 풀 리퀘스트, 채팅 메시지, 또는 적대적인 텍스트가 포함된 문서를 처리할 수 있습니다.

프롬프트 주입은 실제 엔지니어링 문제로 부상합니다. 단순히 모델에게 이전 지시를 무시하도록 말하는 재미있는 트릭 이상입니다. 생산 환경에서는 프롬프트 주입이 시스템이 읽는 내용, 숨기는 내용, 전송하는 내용, 생성하는 내용, 삭제하는 내용, 또는 승인하는 내용을 조작할 수 있는 방법으로 활용될 수 있습니다.

AI 시스템 주변에 새로운 신뢰 경계를 두는 것

흔한 실수는 모델에만 집중하는 것입니다.

• 사용자 입력
• 시스템 프롬프트
• 검색 소스
• 벡터 스토어
• 플러그인과 도구
• APIs
• 신원 및 액세스 제어
• 로그
• 보호 장치
• 인간 검토 경로
• 모니터링
• 배포 파이프라인
• 데이터 보존
• 공급업체 서비스

전체 시스템은 신뢰 경계를 필요로 합니다.

모델의 응답이 자동으로 데이터베이스 쿼리, 이메일, 머지된 풀 리퀘스트, 결제 행동, 또는 고객 맞춤 답변이 되지 않게 해야 합니다. AI 레이어는 제안만 하고, 애플리케이션은 허용 여부를 결정해야 합니다. 민감한 작업에는 모델 외부에 규칙을 두어야 합니다.

가장 안전한 패턴은 간단합니다: 모델을 정책 엔진으로 만들지 마세요.

인증, 검증, 속도 제한, 데이터 접근, 승인 워크플로우, 감사 기록과 같은 일반적인 애플리케이션 제어 기능을 사용하세요. 모델은 의도를 해석하는 데 도움이 될 수 있지만, 애플리케이션이 실제 가능한 행동을 강제해야 합니다.

AI 앱 보안을 위한 두 가지 실용적인 접근법

AI 시스템을 보안하는 데 유용한 두 가지 사고 방식을 제시합니다.

접근법 1: AI 수명 주기 보안

이 접근법은 AI 시스템의 전체 수명 주기를 고려합니다.

• 시스템을 훈련하거나 공급하는 데이터는 무엇인가?
• 그 데이터에 누가 접근할 수 있나요?
• 사용되는 모델은 무엇인가요?
• 모델은 어떻게 평가되나요?
• 출력을 형성하는 프롬프트나 검색 소스는 무엇인가요?
• 배포 시에는 어떤 일이 발생하나요?
• 출시 후 시스템은 어떻게 모니터링되나요?
• 실패는 어떻게 보고되고 해결되나요?

이 접근법은 AI 제품, 내부 코플롯, RAG 시스템, 지원 봇, 코딩 보조 도구, 분석 툴을 구축하는 팀에게 유용합니다.

이 접근법의 가치는 포괄성입니다. 개발자와 보안 팀이 프롬프트를 넘어 생각하도록 강제합니다. 데이터 품질, 액세스 제어, 인프라, 모델 동작, 사용자 권한, 런타임 모니터링 모두 동일한 설계의 일부가 됩니다.

단점은 과도하게 광범위해질 수 있다는 점입니다. 모든 가능한 AI 위험이 하나의 거대한 프레임워크에 포함되면 개발자가 이번 주 코드 변경 사항을 이해하기 어려울 수 있습니다.

접근법 2: 에이전트 아키텍처 보안

두 번째 접근법은 아키텍처를 시작점으로 삼습니다.

• AI 에이전트가 볼 수 있는 것은 무엇인가?
• 그것은 사용할 수 있는 도구는 무엇인가?
• 수행할 수 있는 행동은 무엇인가?
• 시스템을 벗어나 보낼 수 있는 데이터는 무엇인가?
• 인간 승인을 요구하는 결정은 무엇인가?
• 정책에 의해 차단되는 행동은 무엇인가?
• 각 도구 호출에 대해 로그는 무엇을 기록하나요?
• 시스템을 중지하거나 롤백할 수 있는 방법은 무엇인가?

이 접근법은 특히 에이전트 시스템에 유용합니다. 텍스트 요약만 하는 AI 어시스턴트는 하나의 위험 프로파일을 가지고 있지만, 티켓을 열거나 클라우드 자원을 수정하고 CRM 기록을 업데이트하며 스크립트를 실행하거나 브라우저와 상호작용할 수 있는 AI 에이전트는 매우 다른 위험 프로파일을 가집니다.

개발자에게 이 접근법은 애플리케이션 설계와 직접적으로 연관되어 있어 더 실용적입니다.

시스템을 그릴 수 있습니다. 사용자 입력이 들어오는 위치를 표시할 수 있고, 검색 작업이 발생하는 곳을 표시할 수 있으며, 도구가 호출되는 지점을 표시할 수 있습니다. 권한이 확인되는 위치도 표시하고, 로그가 기록되는 곳도 표시할 수 있습니다. 어떤 행동은 승인이 필요하다는 것을 결정할 수 있습니다.

이것은 AI 마법이 아니라 아키텍처 작업입니다.

AI 앱의 권한 문제

많은 AI 보안 실패는 실제로는 권한 실패입니다.

모델은 과도하게 많은 데이터를 읽도록 허용됩니다. 에이전트는 과도한 행동을 허용받습니다. 도구 토큰은 과도한 권한을 가지고 있습니다. 검색 시스템에는 여러 팀의 문서가 포함되어 있습니다. API 키는 검토되지 않은 서비스 계정과 연결되어 있습니다. 사용자는 자신이 어떤 데이터 소스를 사용했는지 알지 못한 채 답변을 받습니다.

개발자는 모바일 및 웹 앱에서 이미 이 문제를 이해하고 있습니다. 사용자는 한 가지 목적을 위해 앱을 설치한 뒤 사진, 위치, 연락처, 카메라, 마이크, 알림, 추적 등 접근 권한을 부여받는 습관이 위험할 수 있습니다. AI 시스템에서도 동일한 습관이 위험합니다. AI 기능을 민감한 데이터와 연결하기 전에, 일반적인 앱에서 데이터 수집이 어떻게 이루어지는지 이해하는 것이 도움이 됩니다. 이는 AI 제품에서도 동일한 프라이버시 문제를 제기합니다: 수집되는 데이터는 무엇인지, 왜 필요한지, 어디로 이동하고 누구에게 사용되는지입니다.

AI 앱에서는 모든 권한에 이유가 있어야 합니다.

• 지원 봇은 모든 고객 기록이 필요하지 않습니다.
• 코드 보조 도구는 프로덕션 비밀번호가 필요하지 않습니다.
• 문서 보조 도구는 사용자가 HR 액세스 권한을 가지고 있지 않는 한 HR 파일이 필요하지 않습니다.
• 응답을 초안 작성하는 에이전트는 자동으로 전송 권한이 필요하지 않으며, 시스템이 변경 제안을 권장하는 경우에도 자동으로 적용 권한이 필요하지 않습니다.

최소 특권 원칙은 여전히 유효합니다. AI는 이를 바꾸지 않습니다.

도구 호출을 위험한 작업처럼 다뤄라

많은 AI 앱의 가장 위험한 부분은 답변이 아니라 도구 호출입니다.

예시:

• 이는 사용자 데이터를 삭제하려는 요청을 보냅니다.
• 이는 전권 권한이 부여된 관리 API를 호출합니다.
• 이는 승인 없이 클라우드 리소스를 수정합니다.
• 이는 새로운 사용자 계정을 생성합니다.
• 이는 결제 작업을 시작합니다.