AI가 더욱 운영에 깊이 자리 잡으면, 보안 도전 과제도 커진다

AI 기술이 단순한 챗봇 수준을 넘어 에이전트(Agent) 아키텍처로 진화하면서, LLM이 외부 도구를 호출하고 자율적으로 의사결정을 내리는 운영 환경이 표준화되고 있습니다. 이러한 시스템은 MCP(Model Context Protocol), Function Calling, RAG 파이프라인을 통해 데이터베이스·이메일·코드 저장소·결제 시스템 등 기업 인프라와 직접 연결되며, 각 연결 지점마다 새로운 공격 표면(attack surface)이 생성됩니다. 특히 프롬프트 인젝션(Prompt Injection)은 외부 문서·웹페이지·이메일 본문에 삽입된 악성 지시문이 LLM의 시스템 프롬프트를 우회하도록 만드는 기법으로, 전통적인 SQL 인젝션과 달리 입력값 검증만으로는 차단이 불가능합니다. 또한 에이전트 간 상호 호출(A2A)이 늘어나면서 하나의 컴포넌트가 침해되면 권한이 연쇄적으로 확장되는 신뢰 경계(trust boundary) 붕괴 문제가 부각되고 있습니다.

개발자 입장에서 가장 체감되는 변화는 "AI가 코드를 짜는 시대"가 아니라 "AI가 직접 시스템을 조작하는 시대"로 넘어가면서 보안 책임의 무게가 급격히 커진다는 점입니다. 예를 들어 Cursor·Claude Code 같은 코딩 에이전트가 의도치 않게 프로덕션 DB에 접근하거나, RAG 시스템이 사내 기밀 문서를 외부 사용자에게 노출하는 사고가 실제로 보고되고 있습니다. OWASP는 이미 'LLM Top 10'을 발표해 LLM01(프롬프트 인젝션), LLM06(민감정보 유출), LLM08(과도한 권한 부여) 등을 명시했고, NIST AI RMF와 EU AI Act는 고위험 AI 시스템에 대한 감사·로깅·휴먼 인 더 루프(Human-in-the-loop) 의무를 강화하고 있습니다. 한국에서도 개인정보보호위원회가 AI 프라이버시 가이드라인을 강화하면서, AI 시스템 도입 시 DPIA(개인정보 영향평가)가 사실상 필수가 되는 추세입니다.

엔지니어가 당장 실천해야 할 사항은 명확합니다. 첫째, **최소 권한 원칙(PoLP)**을 AI 에이전트에도 적용해 도구별로 별도의 IAM 역할을 부여하고 read/write를 분리해야 합니다. 둘째, 에이전트의 모든 도구 호출에 대해 구조화된 로깅과 트레이싱(OpenTelemetry GenAI semantic convention 활용)을 구현하고, 민감 작업에는 반드시 사용자 확인 단계를 두어야 합니다. 셋째, 프롬프트 인젝션 방어를 위해 시스템 프롬프트와 사용자 입력을 명확히 구분하는 구분자 처리, 외부 콘텐츠에 대한 신뢰도 라벨링, 출력 가드레일(Llama Guard, Prompt Guard 등) 도입을 검토해야 합니다. 넷째, 코드 생성 AI를 사용할 때는 시크릿 스캐닝(gitleaks, trufflehog)과 SAST를 CI 파이프라인에 강제 적용해 AI가 생성한 코드의 취약점이 그대로 머지되지 않도록 해야 합니다. AI 운영화(operationalization)는 거스를 수 없는 흐름이지만, 보안을 사후 고려사항으로 두면 그 규모만큼 사고의 폭발 반경도 커진다는 점을 기억해야 합니다.