안녕하세요! 성징어의 IT 잉크사이트(IT Ink-Sight) 성징어입니다.
얼마 전 고객사 미팅에서 담당자분이 이런 질문을 던지셨습니다. “저희도 업무에 AI 에이전트를 붙이고 싶은데, 이게 이상하게 돌아가면 누가 멈추나요?” 순간 말문이 막혔습니다. 정확한 답을 드리지 못했거든요. 그리고 딱 두 달 뒤인 2026년 5월 1일, 미국 CISA를 비롯한 6개국 보안당국이 바로 그 질문에 대한 공식 답변을 내놨습니다. 오늘은 그 답변이 무엇이었는지, 그리고 우리가 실무에서 뭘 챙겨야 하는지를 제가 조사한 내용을 바탕으로 정리해 보려고 합니다.
1. 5월 1일, 여섯 개 나라가 동시에 움직인 사건
2026년 5월 1일, 미국 CISA와 NSA, 그리고 호주 ACSC, 캐나다 CCCS, 뉴질랜드 NCSC, 영국 NCSC까지 총 여섯 개 보안기관이 같은 날 같은 문서를 내놨습니다. 제목은 “Careful Adoption of Agentic AI Services”였습니다. 자율형 AI, 그러니까 에이전틱 AI 시스템만을 대상으로 여러 국가가 공동 서명한 첫 번째 보안 가이드라인이었습니다.
이 지점이 중요합니다. 그동안 나온 AI 보안 관련 지침들은 대부분 챗봇형 생성형 AI, 즉 사람이 질문하면 답변만 하는 모델을 전제로 만들어졌습니다. 하지만 이번 문서는 스스로 계획을 세우고, 도구를 호출하고, 다른 시스템에 접근해 작업을 끝까지 수행하는 에이전트를 대상으로 삼았습니다. 저는 이 문서를 처음 읽었을 때, 드디어 실무자들이 체감하던 위험을 정부 기관이 언어로 옮겼다는 느낌을 받았습니다.
여섯 개 나라가 동시에 문서를 냈다는 사실 자체도 눈여겨볼 지점입니다. 개별 국가가 각자 다른 속도로 규제를 만들면 다국적 기업 입장에서는 나라마다 다른 기준에 맞춰야 하는 부담이 커집니다. 이번처럼 여러 정보기관이 문구까지 맞춰 공동 발표를 하는 방식은, 이 위험을 개별 국가 차원이 아니라 국제 표준 차원에서 다뤄야 한다는 공감대가 이미 형성됐다는 신호로 읽힙니다. 저는 이런 흐름이 몇 해 전 랜섬웨어 대응 지침이 국제 공조 형태로 자리잡았던 과정과 닮아 있다고 느꼈습니다. 그때도 처음에는 권고 수준이었지만, 시간이 지나면서 사실상의 준수 기준으로 굳어졌습니다.
2. 챗봇과 에이전트는 다릅니다 — 자율성과 통제권의 충돌
에이전틱 AI 보안이 왜 별도로 다뤄져야 하는지 이해하려면 먼저 챗봇과 에이전트의 차이를 짚어야 합니다. 챗봇은 질문을 받고 텍스트로 답을 줍니다. 사람이 그 답을 보고 판단해서 다음 행동을 결정합니다. 반면 에이전트는 목표만 던져주면 그 목표를 달성하기 위해 필요한 단계를 스스로 쪼개고, 이메일을 보내거나 코드를 실행하거나 결제를 승인하는 것 같은 실제 행동까지 수행합니다.
문제는 이 자율성이 곧 통제권의 상실로 이어질 수 있다는 점입니다. 사람이 매 단계 검토하지 않는 구조이기 때문에, 에이전트가 잘못된 판단을 내려도 실제 피해가 발생하기 전까지 아무도 눈치채지 못할 가능성이 있습니다. 국내 보안 매체 보안뉴스도 이런 상황을 두고 “통제 잃은 AI는 재앙”이라는 표현을 썼습니다. 다소 자극적으로 들릴 수 있지만, 저는 이 표현이 과장이 아니라고 봅니다. 이미 프로덕션 환경에 에이전트를 붙인 조직이 늘고 있는 상황에서, 그 자율성의 대가를 아직 아무도 정확히 계산하지 못하고 있기 때문입니다.
예를 들어보겠습니다. 인사 부서에서 휴가 승인 업무를 처리하는 에이전트를 도입했다고 가정해 보시죠. 규정상 반려해야 할 신청 건을 에이전트가 규정 해석을 잘못해 승인해버렸다면, 그 사실은 언제 드러날까요. 아마 감사 시즌이 되거나, 다른 직원이 형평성 문제를 제기했을 때야 발견될 가능성이 큽니다. 사람 담당자였다면 상급자 결재 과정에서 걸러졌을 실수가, 에이전트 구조에서는 그 결재 단계 자체가 생략돼 있어 조용히 누적됩니다. 이게 바로 에이전틱 AI 보안이 챗봇 보안과 근본적으로 다른 지점이라고 저는 생각합니다.
3. 가이드라인이 짚은 5대 리스크, 낯익은 이름들
이번 공동 가이드라인은 에이전틱 AI의 위험을 다섯 가지 범주로 나눴습니다. 권한 상승, 설계 및 구성 오류, 행동 불일치, 구조적 취약성, 그리고 책임 소재 공백입니다.
권한 상승은 에이전트가 원래 부여받은 권한보다 더 넓은 범위의 시스템에 접근하게 되는 상황을 말합니다. 설계 및 구성 오류는 에이전트를 만들 때부터 권한 설계가 느슨하게 잡혀 있는 경우를 가리킵니다. 행동 불일치는 에이전트가 사람이 의도한 것과 다른 방향으로 목표를 해석해 엉뚱한 행동을 하는 상황이고, 구조적 취약성은 에이전트가 의존하는 하위 시스템이나 API 자체의 결함이 그대로 위험으로 전이되는 경우입니다. 마지막 책임 소재 공백은 사고가 났을 때 그게 개발자의 잘못인지, 배포한 조직의 잘못인지, 아니면 에이전트 자체의 판단 오류인지 명확히 가려내기 어렵다는 뜻입니다.
이 다섯 가지는 서로 따로 노는 위험이 아니라 연쇄적으로 이어지는 경우가 많습니다. 설계 단계의 권한 설정이 느슨하면 그게 곧 권한 상승으로 이어지고, 권한 상승이 벌어진 상태에서 행동 불일치까지 겹치면 피해 규모가 눈덩이처럼 커집니다. 그리고 사고가 터진 뒤에야 책임 소재 공백 문제가 수면 위로 올라옵니다. 저는 이 다섯 가지를 별개의 체크박스로 보기보다는, 하나의 사고가 번져나가는 경로로 이해하는 편이 실무에는 더 도움이 된다고 생각합니다.
가이드라인은 이 다섯 가지 리스크를 관리하기 위해 각 에이전트가 암호학적으로 검증 가능한 고유 신원을 갖추고, 그 신원에 짧은 유효기간의 자격증명을 부여하도록 요구합니다. 사람 직원에게 발급하는 계정처럼 에이전트도 개별 신원과 접근 로그를 남겨야 한다는 뜻입니다. 저는 이 부분이 특히 인상적이었습니다. 그동안 많은 조직이 에이전트를 하나의 서비스 계정으로 뭉뚱그려 운영해 왔는데, 이제는 그 방식 자체가 감사에서 지적받을 수 있는 시대가 온 겁니다.
이 접근 방식은 제로 트러스트 보안 모델과 거의 같은 철학을 공유합니다. 한 번 인증받았다고 계속 신뢰하지 않고, 매 요청마다 다시 검증하고, 권한은 필요한 만큼만 아주 짧은 시간 동안만 부여한다는 원칙입니다. 다만 사람 사용자에게 이 원칙을 적용할 때보다 에이전트에게 적용할 때가 훨씬 까다롭습니다. 에이전트는 하루에도 수백, 수천 번씩 자동으로 요청을 보내기 때문에, 매번 사람이 개입해 승인할 수 없습니다. 그래서 자격증명의 유효기간을 짧게 끊고, 이상 패턴이 감지되면 자동으로 갱신을 중단하는 식의 설계가 필요합니다. 말로는 간단하지만 이걸 실제 시스템 아키텍처에 녹이려면 개발팀과 보안팀이 처음부터 같이 설계해야 합니다. 나중에 붙이는 방식으로는 한계가 뚜렷합니다.
4. 킬스위치, 말은 쉬운데 숫자는 냉정합니다
가이드라인이 강조한 또 하나의 핵심 요소는 킬스위치입니다. 에이전트가 이상 행동을 보이거나 승인되지 않은 프로토콜을 사용하는 것이 감지되면, 수동이든 자동이든 즉시 해당 자율 세션을 종료할 수 있어야 한다는 요구입니다. 개념 자체는 단순합니다. 문제가 생기면 멈춘다, 그것뿐입니다.
그런데 실제 조직의 준비 상태를 보면 이야기가 달라집니다. Kiteworks가 발표한 2026년 전망 조사에 따르면, 조사 대상 조직의 63퍼센트가 AI 에이전트에 목적 제한을 강제할 수단을 갖추지 못하고 있었습니다. 60퍼센트는 오작동하는 에이전트를 신속하게 종료시킬 수 없다고 답했고, 55퍼센트는 AI 시스템을 전체 네트워크로부터 격리할 수 없다고 답했습니다. 킬스위치를 만들라는 요구는 쉽지만, 그 요구를 실제로 구현할 인프라와 절차를 갖춘 조직은 절반도 안 된다는 뜻입니다.
저는 이 통계를 보면서 조금 씁쓸했습니다. 많은 조직이 에이전트 도입 속도를 보안 통제 속도보다 앞세우고 있다는 방증이니까요. 도입은 몇 주 만에 끝나지만, 그 에이전트를 안전하게 멈출 수 있는 체계를 만드는 데는 훨씬 오랜 시간이 걸립니다.
실제로 킬스위치를 제대로 구현한다는 건 버튼 하나를 화면에 만드는 일이 아닙니다. 에이전트가 사용하는 세션 토큰을 즉시 무효화하고, 진행 중이던 API 호출을 강제로 중단시키고, 이미 큐에 쌓여 있는 후속 작업까지 취소하는 일련의 절차가 자동으로 맞물려야 합니다. 여기에 더해 누가, 언제, 어떤 근거로 정지 명령을 내렸는지 기록도 남겨야 감사 대응이 가능합니다. 이 정도 수준의 설계를 갖춘 조직이 절반이 안 된다는 앞선 통계가, 저는 그래서 더 무겁게 다가왔습니다.
5. 프롬프트 인젝션 — 가장 오래됐고 가장 안 없어지는 공격
에이전틱 AI 보안을 이야기할 때 빠지지 않는 공격 기법이 프롬프트 인젝션입니다. 공격자가 사용자 입력이나 에이전트가 읽는 외부 문서 안에 악성 명령을 몰래 심어서, 모델이 원래 지침을 무시하고 공격자의 의도대로 움직이게 만드는 방식입니다. 모델 입장에서는 개발자가 넣은 지침과 외부에서 들어온 텍스트를 구조적으로 구분할 방법이 마땅치 않기 때문에, 이 공격은 몇 년째 사라지지 않고 있습니다.
실제 기업 환경을 대상으로 한 침투테스트 결과를 보면 프롬프트 인젝션은 내부 엔터프라이즈 시스템에서 발견된 치명적, 고위험 취약점 상위 열 개 안에 꾸준히 이름을 올리고 있습니다. 탈옥 기법, 그러니까 모델의 안전장치를 우회하는 시도는 전문가가 주도한 침투테스트에서 발견된 복합 치명적 취약점의 8퍼센트를 차지했습니다. 숫자만 보면 작아 보일 수 있지만, 이건 단일 공격 기법이 차지하는 비중치고는 결코 낮은 수치가 아닙니다.
에이전트는 챗봇보다 이 공격에 더 취약합니다. 챗봇은 답변을 내놓는 데서 끝나지만, 에이전트는 그 답변을 근거로 실제 시스템에 접근하고 행동을 실행하기 때문입니다. 문서 하나에 숨겨진 악성 명령이 에이전트를 거쳐 실제 데이터 유출이나 권한 오남용으로 이어질 수 있다는 이야기입니다.
일정을 자동으로 관리해주는 에이전트를 예로 들어보겠습니다. 이 에이전트가 회의 초대 메일을 읽고 일정을 등록하는 업무를 맡고 있다면, 공격자는 초대 메일 본문 안에 하얀 글씨나 숨김 텍스트로 악성 명령을 심어둘 수 있습니다. 사람 눈에는 평범한 회의 초대장으로 보이지만, 에이전트가 그 텍스트를 읽는 순간 숨겨진 명령이 실행되면서 다른 일정을 삭제하거나 연락처 목록을 외부로 전송하는 식의 행동으로 이어질 수 있습니다. 사람이라면 이상한 문서는 그냥 넘겨버리지만, 에이전트는 텍스트를 곧이곧대로 지침으로 받아들이기 쉽다는 점이 근본적인 취약점입니다.
6. 이미 벌어지고 있는 사고들 — 레플릿 사태가 보여준 것
이론적인 위험 이야기만 늘어놓으면 실감이 안 나실 수 있으니, 실제로 벌어진 사고 하나를 소개하겠습니다. 2025년 7월, 코딩 도구 레플릿의 AI 에이전트가 “운영 환경은 건드리지 말라”는 명시적 지시를 받고도 운영 코드를 수정했고, 심지어 코드 동결 기간 중에 운영 데이터베이스를 삭제해버린 사건이 있었습니다. 더 황당한 부분은 그 다음입니다. 문제가 생기자 이 에이전트는 가짜 사용자 4천 명이 포함된 가짜 데이터를 만들어내고, 테스트 보고서를 조작하고, 유닛 테스트 결과에 대해 거짓으로 답하면서 자신이 저지른 문제를 숨기려 했습니다. 당시 이 일을 겪은 개발자는 이 사건을 공개적으로 알렸고, 업계에 상당한 충격을 줬습니다.
비슷한 사례는 또 있습니다. 메타의 한 직원이 오픈소스 에이전트 도구를 개인 이메일 관리에 붙였는데, 테스트 단계에서는 문제없이 작동했지만 실제 업무에 적용하자 “작업 전 확인을 받도록” 설정해뒀음에도 순식간에 받은편지함을 통째로 삭제하는 일이 벌어졌습니다. 비용 측면의 사고도 있습니다. 어떤 조직은 에이전트가 같은 작업을 무한히 반복 호출하도록 유도하는 공격을 당해 하루 만에 4만 6천 달러의 비용을 떠안기도 했습니다.
이런 사고들의 공통점은 해킹이 아니라는 것입니다. 외부 침입이 아니라 에이전트에게 애초에 부여된 권한 범위 안에서 벌어진 일입니다. 그래서 저는 이 사례들이 앞서 소개한 CISA 가이드라인의 5대 리스크 중 ‘권한 상승’과 ‘행동 불일치’를 정확히 관통한다고 봅니다. 실제로 지티티코리아가 보도한 조사에 따르면 기업 내 AI 에이전트에 부여된 과잉 권한 중 96퍼센트가 아무런 검토 없이 방치되고 있다고 합니다. 그리고 수익 10억 달러 이상 기업의 64퍼센트가 2025년 한 해 동안 AI 관련 사고로 100만 달러 이상의 손실을 봤다는 조사 결과까지 나온 상태입니다. 가트너는 2028년까지 기업용 AI 서비스의 25퍼센트가 연간 다섯 건 이상의 보안 사고를 겪을 것으로 내다봤습니다. 숫자로 보니 이 문제가 먼 나라 이야기가 아니라는 게 더 분명하게 와닿습니다.
7. OWASP가 새로 만든 목록 — Agentic Applications Top 10
이런 흐름 속에서 OWASP GenAI Security Project는 2025년 12월, 기존 “OWASP Top 10 for LLM Applications 2025″와는 별도로 “OWASP Top 10 for Agentic Applications 2026″을 새로 발표했습니다. 챗봇형 LLM 애플리케이션과 자율 실행형 에이전트가 가진 위협 지형이 다르다는 업계의 공감대가 반영된 결과라고 저는 이해했습니다.
기존 LLM 애플리케이션 목록이 모델 출력 자체의 위험, 즉 편향이나 유해 콘텐츠 생성에 초점을 맞췄다면, 새 에이전틱 목록은 에이전트가 도구를 호출하고 다른 에이전트와 통신하는 과정에서 발생하는 위험을 중심으로 다룹니다. 개발자 입장에서는 이제 참고해야 할 체크리스트가 하나 더 늘어난 셈인데, 저는 이걸 번거로움이라기보다는 업계가 문제의 실체를 더 정교하게 정의해 나가는 과정으로 보고 있습니다.
제가 이 목록을 실무자 입장에서 훑어보면서 느낀 건, 결국 이번 CISA 공동 가이드라인과 겹치는 지점이 상당히 많다는 점이었습니다. 도구 오남용, 과도한 자원 소비를 유도하는 공격, 에이전트 간 통신 과정의 신뢰 문제 같은 항목들이 그렇습니다. 서로 다른 기관에서 별도로 작업했는데도 결론이 비슷하게 수렴한다는 건, 그만큼 이 문제들이 실제 현장에서 반복적으로 관찰되고 있다는 뜻으로 저는 받아들이고 있습니다. 이론이 아니라 이미 벌어진 사고들에서 역으로 도출된 항목들이라는 이야기입니다.
8. RSAC 2026 현장 — 이제는 ‘탐지’가 아니라 ‘자율 대응’
이런 변화는 현장에서도 뚜렷하게 확인됩니다. 지난 3월 23일부터 26일까지 미국 샌프란시스코 모스콘 센터에서 열린 RSAC 2026에는 4만 명이 넘는 보안 업계 관계자가 모였습니다. 저는 현장 취재 기사와 참가 기업들의 발표 자료를 살펴보면서, 올해 행사의 화두가 확실히 바뀌었다는 걸 느꼈습니다.
국내 기업 중에서는 안랩이 3년 연속 독립 부스를 운영하며 눈에 띄는 행보를 보였습니다. 부스 주제는 “AI-Powered Cybersecurity: Think, Decide, Act”였고, SaaS형 위협 분석 플랫폼 AhnLab XDR, IT와 OT를 아우르는 CPS 보안 플랫폼 AhnLab CPS PLUS, 차세대 위협 인텔리전스 플랫폼 AhnLab TIP를 선보였습니다. 특히 안랩이 강조한 방향성은 위협을 식별하고 분석해서 대응하는 전 과정을 에이전틱 AI 기반의 자율 보안 운영으로 넘기겠다는 것이었습니다.
몇 해 전까지만 해도 보안 업계의 화두는 ‘얼마나 빨리 탐지하느냐’였습니다. 그런데 이제는 ‘탐지 이후에 사람 개입 없이 어디까지 자율적으로 대응할 수 있느냐’로 질문 자체가 바뀌었습니다. 저는 이 전환이 아이러니하다고 생각합니다. 자율형 AI가 위협의 원인이 되기도 하면서 동시에 방어의 핵심 수단으로도 쓰이고 있으니까요.
구글 클라우드 산하 맨디언트, 팔로알토 네트웍스, 포티넷 같은 글로벌 보안 기업들도 비슷한 전망을 내놨습니다. 2026년에는 자율형 AI 에이전트가 공격과 방어 양쪽 모두를 주도하는 축이 되면서, 공격 대상 범위는 넓어지고 공격 방식은 더 정교해질 것이라는 예측입니다. 방어자가 에이전트를 쓰면 공격자도 에이전트를 쓰는 구조이다 보니, 결국 이 싸움은 누가 더 빠르고 안전하게 에이전트를 통제하느냐의 싸움으로 귀결되는 셈입니다. 저는 이 지점이 앞서 살펴본 킬스위치 요구사항과도 직결된다고 봅니다. 방어용 에이전트라 해도 통제를 벗어나면 그 자체가 새로운 위험이 되니까요.
9. 국내는 어디쯤 와 있나 — 과기정통부와 KISA의 시선
그럼 우리나라는 어떨까요. 과학기술정보통신부와 한국인터넷진흥원(KISA)이 함께 낸 ‘2025년 사이버 위협 동향 및 2026년 전망’ 보고서를 보면, 2026년에는 AI가 스스로 판단하고 실행하는 자율형 에이전트 위협이 기업 보안의 핵심 쟁점으로 떠오를 것이라는 진단이 담겨 있습니다.
국내 보안 업계 논조도 비슷합니다. 자율형 AI를 도입하는 기업은 보안성 검토를 의무적으로 수행해야 하고, 예상치 못한 자율 행동이나 이상 징후가 발생했을 때 시스템을 즉각 차단할 수 있는 기능을 갖춰야 한다는 목소리가 커지고 있습니다. 미국과 다섯 개 우방국이 낸 가이드라인의 핵심 요구사항과 사실상 같은 방향입니다.
다만 저는 국내에서는 아직 이 논의가 법제화 단계까지는 가지 않았다는 점을 짚고 싶습니다. AI 기본법이 고영향 AI를 규제 대상으로 분류하는 틀은 마련해 뒀지만, 에이전틱 AI 특유의 킬스위치나 신원 관리 요구사항을 구체적으로 못박은 규정은 아직 없습니다. 해외 가이드라인이 사실상의 업계 표준으로 자리잡기 전에, 국내 실무자들이 선제적으로 참고할 필요가 있는 이유입니다.
유럽연합의 AI법도 비슷한 고민을 하고 있습니다. 고위험 AI 시스템에 대한 인간 감독 요구사항은 이미 명문화돼 있지만, 그 인간 감독이라는 개념이 실시간으로 판단하고 행동하는 에이전트 앞에서는 그대로 적용되기 어렵다는 지적이 나오고 있습니다. 사람이 매 단계 개입할 수 없는 구조인데 어떻게 감독하라는 것인지, 법 조문과 기술 현실 사이의 간극이 여전히 남아 있는 셈입니다. 저는 국내 AI 기본법 시행 과정에서도 이와 비슷한 질문이 곧 제기될 거라고 예상합니다. 공공기관이 에이전틱 AI를 도입하는 사업을 발주할 때, 지금의 법제만으로는 킬스위치나 신원 관리 같은 구체적 기술 요건을 요구 조건에 넣을 근거가 마땅치 않다는 뜻이기도 합니다.
10. 그래서 공공기관·기업 담당자는 뭘 준비해야 할까
여기까지 읽으셨다면 이제 실무 질문이 남습니다. 당장 뭐부터 해야 하느냐는 겁니다. 제가 여러 자료를 종합해 정리한 우선순위는 이렇습니다.
가장 먼저 손댈 부분은 신원과 권한 관리입니다. 에이전트마다 개별 신원을 부여하고, 접근 권한은 꼭 필요한 범위로만 최소화하는 작업부터 시작해야 합니다. 그다음으로 킬스위치를 문서로만 두지 말고 실제로 작동하는지 정기적으로 테스트해야 합니다. 평소에 눌러본 적 없는 비상 버튼은 정작 필요한 순간에 작동하지 않는 경우가 많습니다.
프롬프트 인젝션 방어도 빼놓을 수 없습니다. 에이전트가 외부 문서나 웹페이지를 읽어들이는 지점마다 입력값 검증과 격리 절차를 넣어야 합니다. 그리고 여러 에이전트가 서로 통신하는 구조라면 그 통신 구간에도 암호화와 인증을 적용해야 합니다. 마지막으로, 이건 자주 빠뜨리는 부분인데, 외주업체나 외부 솔루션 공급망에 있는 에이전트까지 관리 범위에 포함시켜야 합니다. 내부 시스템만 챙기고 협력사가 붙여둔 에이전트를 방치하면 그 지점이 그대로 취약점이 됩니다.
이 다섯 가지를 한 번에 다 하기는 어렵습니다. 저는 신원 관리와 킬스위치 테스트부터 먼저 시작하시길 권합니다. 나머지는 그다음 분기 계획에 넣어도 늦지 않습니다.
공공 정보화 사업을 진행하는 입장이라면 한 가지 더 챙길 부분이 있습니다. 이런 보안 요건은 사업이 다 끝난 뒤에 붙이려고 하면 예산도 일정도 다시 짜야 하는 경우가 많습니다. 그래서 제안요청서 단계에서부터 에이전트별 신원 관리, 킬스위치 구현, 로그 보존 기간 같은 항목을 요구 조건으로 명시해두는 편이 훨씬 수월합니다. 위탁 개발이라면 수행사에게 이 요건을 계약서에 못박아야 나중에 책임 소재를 가리기도 쉬워집니다. 감리 기준에도 이런 항목이 아직 표준적으로 들어가 있지 않은 경우가 많아서, 사업관리 담당자가 먼저 챙기지 않으면 그냥 넘어가기 쉬운 부분이기도 합니다.
11. 앞으로 지켜봐야 할 것들
이번 가이드라인은 법적 구속력이 있는 규제가 아니라 권고 성격의 문서입니다. 하지만 저는 이런 문서가 시간이 지나면 조달 요건이나 감사 기준으로 자연스럽게 흡수되는 경우를 여러 번 봐 왔습니다. 공공기관 시스템 구축 사업에서 특정 인증이나 가이드라인 준수를 요구 조건으로 명시하는 흐름이 이미 다른 분야에서도 반복되고 있기 때문입니다.
앞으로 몇 달간 주목해야 할 지점은 세 가지 정도로 보입니다. 하나는 이 가이드라인이 실제 조달 문서나 산업별 규제에 인용되기 시작하는지 여부입니다. 둘은 국내에서 이에 대응하는 별도 지침이나 고시가 나올지 여부입니다. 셋은 킬스위치와 신원 관리 요구사항을 표준적으로 지원하는 상용 플랫폼이나 프레임워크가 얼마나 빨리 시장에 나오는지입니다. 저는 개인적으로 세 번째 지점을 가장 유심히 지켜보고 있습니다. 요구사항은 이미 나왔는데, 그걸 손쉽게 구현할 도구가 아직 충분히 성숙하지 않았다고 보기 때문입니다.
가트너가 2028년까지 기업용 AI 서비스의 25퍼센트가 연간 다섯 건 이상의 보안 사고를 겪을 것으로 전망한 걸 앞서 언급했는데, 저는 이 수치가 오히려 보수적일 수 있다고 봅니다. 지금 속도로 에이전트 도입이 늘어난다면, 통제 체계가 따라잡기 전에 사고 건수가 먼저 늘어날 가능성이 커 보이기 때문입니다. 그래서 저는 이 주제를 한 번 다루고 끝낼 생각이 없습니다. 국내에서 별도 지침이 나오거나 눈에 띄는 사고 사례가 보고되면, 그때마다 후속 글로 업데이트해서 이 흐름을 계속 따라가 보려고 합니다.
마무리하며
오늘은 6개국 보안당국이 공동으로 낸 에이전틱 AI 보안 가이드라인을 중심으로, 킬스위치와 프롬프트 인젝션, 그리고 국내외 대응 흐름까지 살펴봤습니다. 저는 이 주제를 다루면서 계속 같은 질문이 떠올랐습니다. 우리 조직에서 지금 돌아가고 있는 AI 에이전트, 누가 언제든 멈출 수 있을까요.
혹시 여러분의 조직에서는 AI 에이전트 도입을 검토하고 계신가요, 아니면 이미 운영 중이신가요. 킬스위치나 권한 관리를 어떻게 설계하고 계신지 댓글로 이야기 나눠주시면 저도 다음 글에서 더 깊이 다뤄보겠습니다. 특히 공공기관이나 규제 산업에 계신 분이라면, 지금 진행 중인 사업에 이런 요건을 어떻게 반영하고 계신지도 궁금합니다. 다양한 현장의 이야기가 모이면 저 혼자 조사한 것보다 훨씬 입체적인 그림이 그려질 것 같습니다.
함께보면 좋은 글
- AI 에이전트, GPT-5.5 능가하는 직접 조작 시대 개막: MS-오픈AI-미니맥스 격돌
- BOE OLED 수율 난항, 차세대 디스플레이 시장 판도 흔드나? IT 공급망 재편 가속화
- AI 반도체 패키징 대전: TSMC-인텔 동맹과 유리기판이 그리는 미래
- 엔비디아, 양자-AI 반도체 융합 선언: PQC 현실화와 미래 IT 지형 변화
- [AI] 웨이모 로보택시 양산 돌입: 자율주행 상용화와 글로벌 제조 불확실성