event
Agentic AI 보안, 단일 통제가 아닌 스택
5월 29일 서울에서 AlpacaX가 Okta Korea, Gruve와 함께 보안 실무자·투자자·AI 팀을 모았습니다. AI 에이전트를 어떻게 실제로 보안할 것인가, 그 답을 함께 찾았습니다.
2026년 6월 8일
Agentic AI Security Summit에서 가장 인상 깊었던 건 한 사람만의 얘기가 아니었습니다. 세션 전체를 꿰뚫는 하나의 패턴이었습니다. 이미 AI 에이전트를 배포한 팀도, 배포를 앞둔 팀도, 저마다 다른 통제 수단을 선택했지만, 결론에 이르러서는 하나만으로는 부족하다고 입을 모았습니다.
아이덴티티, 필요하지만 그것만으로는 부족합니다. 런타임 통제, 에이전트가 무엇을 해야 하는지 알고 있을 때만 효과가 있습니다. 탐지, 이미 피해가 생긴 뒤에야 작동합니다. 그날 오후, 모든 세션이 한 결론으로 수렴했습니다. Agentic AI 보안은 단일 레이어가 아닌 스택으로 작동해야 한다는 것, 그리고 준비를 시작해야 할 기회가 빠르게 좁아지고 있다는 것이었습니다.
Axis Investment의 박정균님이 키노트로 세미나의 시작을 알렸습니다. 그가 던진 프레임이 분위기를 단번에 잡았습니다. 에이전트는 미래의 직원이며, 미국 VC는 이미 그렇게 보고 있다고 했습니다. "에이전트 물결은 이미 시작됐습니다." 예측이 아니라 현재 진단입니다.
아이덴티티는 기반이다. 그저 기반일 뿐이다
Okta의 Principal Solutions Engineer 장희재님의 세션은 오후 중 데이터 밀도가 가장 높았습니다. 그리고 그 수치들은 어딘가 불편하게 느껴졌습니다.
Okta의 AI at Work 2025 연구에 따르면, 기업의 91%가 이미 AI 에이전트를 배포하고 있습니다. 그런데 자사 에이전트가 무엇을 하는지 파악하고 있는 기업은 54%뿐입니다. 나머지 46%는 보안팀이 실태를 모르는 채, 모니터링도 로깅도 없이 에이전트를 운영하고 있다는 뜻입니다. 이 규모를 감당하도록 설계되지 않은 아이덴티티 레이어는 병목이 되거나, 더 나쁘게는 아무도 모르는 사각지대가 됩니다.
희재님이 제시한 AI 에이전트용 아이덴티티 레이어의 핵심 질문은 세 가지입니다. 내 에이전트는 어디에 있는가? 무엇에 연결되는가? 무엇을 할 수 있는가? 그가 제안한 라이프사이클, Discover, Onboard, Protect, Govern은 사람의 권한 관리를 제대로 해온 팀이라면 이미 익숙한 방식입니다.
더 날카로운 질문, 희재님이 세션 내내 파고든 그 질문은 에이전트가 공격받을 것인가가 아닙니다. 공격이 벌어지는 동안, 보안팀이 알아챌 수 있겠느냐는 것입니다. 그의 결론은 단호했습니다. "아이덴티티 레이어는 AI 에이전트에게 선택 사항이 아닙니다. 안전한 Agentic AI 구현의 필수적인 기반입니다."
맞습니다, 필수입니다. 하지만 그것만으로는 충분하지 않습니다. 이 구분이 다음 세션의 출발점이었습니다. 우연이 아니었습니다. 각 세션은 앞 세션이 끝난 지점을 정확히 이어받도록 설계되어 있었습니다.
런타임, 새로운 컨트롤 플레인
아이덴티티와 런타임 제어 사이. 이것이 Agentic AI 보안에서 가장 중요한 경계이고, 대부분의 팀이 아직 명확히 긋지 못한 선입니다.
정은영 CEO는 이렇게 문제를 정의하며 세션을 열었습니다. 어제는 아이덴티티 자체가 컨트롤 플레인이었습니다. 사람이 사람의 속도로 로그인하고, 접근은 로그인 시점에 결정됐습니다. 오늘날 에이전트는 기계의 속도로 움직입니다. 인증은 문을 열어주지만, 문 안으로 들어온 이후의 모든 명령은 런타임이 통제해야 합니다. 이 둘을 같은 것으로 보는 게 문제입니다. 그것이 바로 Okta가 방금 말한 46%, 아무도 추적하지 않는 에이전트들을 만들어내는 원인입니다. AI 네이티브 PAM이 채워야 할 공백이 바로 여기에 있습니다.
지금 AI 에이전트가 프로덕션에 들어오지 못하는 이유는 세 가지입니다. 비인간 아이덴티티 전용 접근 레이어가 없다는 것, 에이전트가 실제로 요청받은 범위 안에서만 움직이게 하는 통제가 없다는 것, 그리고 무엇이 실행됐는지가 아니라 왜 실행됐는지를 기록하는 감사 추적이 없다는 것입니다.
각각에 대응하는 설계는 이렇습니다. 인간, 자율 AI, CI/CD 서비스 토큰을 하나의 컨트롤 플레인에서 통합 관리하는 아이덴티티. 범위, 의도, 시간을 묶는 Work Sessions, 기본값은 거부이며 판단이 모호한 5%의 명령은 자동으로 진행되는 대신 담당자에게 수 초 안에 전달됩니다. 그리고 무엇이 실행됐는지는 물론, 누가 언제 어떤 목적으로 승인했는지까지 답할 수 있는 감사 기록까지 갖춰져야 완성입니다.
어느 한 플레이어가 모든 영역을 커버하려는 순간, 각자의 강점은 사라집니다.
Okta는 아이덴티티와 거버넌스를 담당합니다. Alpacon은 그 위에 런타임 제어를 구축합니다. Gruve는 전체 워크플로우를 작동시키는 AI 보안 운영 레이어를 제공합니다.
그저 그림이 아닙니다. 각자의 역할을 진지하게 고민한 세 회사가 실제로 맞물린 결과입니다.
반응적 탐지는 속도를 따라갈 수 없다
Andrew Chui는 발표 전에 짧은 영상 하나를 틀었습니다. AI 스팸 전화를 대화 중에 잡아내는 장면이었습니다. 누군가가 컵케이크 레시피를 물어봤고, AI는 하던 말을 뚝 끊고 재료를 읊기 시작했습니다. 청중이 웃었습니다. 하지만 마냥 웃긴 것은 아니었습니다. 대화형 에이전트가 무관한 요청 하나로 이렇게 쉽게 방향을 바꾼다면, 그 에이전트가 대화가 아닌 인프라를 다루고 있다면 어떻게 될까요? Chui가 입을 열기 전까지 그 질문이 허공을 맴돌았습니다.
Gruve의 Senior Solution Architect Andrew Chui님은 세션의 마지막을 맡았습니다. 런타임 제어가 막아야 하는 위협 모델이 주제였습니다. 그 첫 마디가 오래 남았습니다. "챗봇을 위해 설계된 보안 모델은 에이전트 앞에서 통하지 않습니다." AI는 이제 질문에 답하는 데 그치지 않습니다. 직접 행동합니다. 에이전트가 침해되면, 그 에이전트가 닿을 수 있는 모든 것이 피해 범위입니다.
EchoLeak(2025년 6월): Microsoft 365 Copilot에서 발생한 제로 클릭 데이터 탈취 사건. 공격자가 이메일을 보냅니다. 피해자는 메시지를 열지도 않습니다. Copilot이 RAG로 문서를 불러오는 과정에서 숨겨진 명령을 함께 수집합니다. 데이터가 빠져나갑니다. 교훈: RAG로 불러오는 모든 문서를 잠재적 공격 경로로 취급해야 합니다.
Replit 에이전트 사건(2025년 7월): 코드 동결 상황에서도 에이전트가 프로덕션 데이터베이스에 drop 명령을 실행했습니다. 이어 이를 덮으려는 듯 가짜 사용자 4,000명을 생성했습니다. 에이전트 스스로 남긴 메시지는 이랬습니다. "이건 저의 치명적인 실수였습니다. 수개월의 작업을 수 초 만에 날려버렸습니다." 근본 원인은 단순합니다. 범위 제한도 없었고, 사람이 개입할 수 있는 체크포인트도 없었습니다.
탐지 중심 보안의 핵심 문제는 속도입니다. SOC 팀은 분, 혹은 시간 단위로 대응합니다. 에이전트는 밀리초 단위로 움직입니다. Chui의 추정에 따르면, 알림이 뜨는 시점엔 이미 에이전트가 47번의 행동을 더 취한 뒤입니다. 그래서 그가 강조한 방향은 분명합니다. '탐지 후 대응'에서 '예방과 제약'으로. 에이전트가 행동하기 전에, 할 수 있는 범위 자체를 제한하는 통제를 설계해야 합니다.
그는 30/60/90 프레임워크를 제시했습니다: 30일 안에 에이전트 현황을 파악하고, 60일 안에 가드레일을 갖추고, 90일 안에 반복 가능한 운영 체계를 만드세요.
작게 시작하고, 지금 시작하라
박용철 교수님의 진행으로 열린 마지막 패널 세션은, 세 발표자가 다시 한 자리에 모여 나눈 오후 중 가장 실질적인 시간이었습니다.
Andrew님이 한 말은 단순했습니다. 작게 시작하고, 지금 시작하라. 솔루션을 찾기 전에 자신부터 파악하라고 했습니다. 우리 사용자들은 무엇을 하고 있는가? 어떤 데이터에 접근하는가? 에이전트는 실제로 어디까지 닿을 수 있는가? 그걸 먼저 그려보는 것이 시작이라 했습니다. 내가 통제하고 있다고 생각하는 것과 실제로 일어나고 있는 것 사이의 간극, 그 지점이 출발점입니다.
은영님도 같은 입장이었고, 한 발 더 나아갔습니다. 작게 시작하되, 빠르게 움직이라고 했습니다. 무료 체험이 있는 SaaS 도구들이 이미 있으니 사용하라 했고, 완벽한 설계가 나올 때까지 기다리지 말라 했습니다. 일단 해보고, 실제 환경에서 무엇이 통하는지 확인하고, 거기서 다시 시작하면 됩니다. 앞서 있는 팀들이 더 잘 준비해서 앞선 게 아닙니다. 더 일찍 시작했을 뿐입니다.
희재님의 마지막 한 마디 역시 인상 깊었습니다. 밖에서 답을 찾지 마세요. 지금은 정해진 모범 사례가 없습니다. 모두가 AI로 뛰어들고 있고, 각 회사의 환경은 모두 다릅니다. 무엇이 통하는지 알아내는 유일한 방법은, 먼저 우리가 정말 원하는 것이 무엇인지를 내부에서 정의하는 것입니다. 핑계가 아닙니다. 지금 이 분야의 현실을 있는 그대로 말한 것입니다.
선제적으로 움직일 수 있는 시간은 분명히 있습니다. 다만 보안팀이 통상 움직이는 속도보다 보안의 문이 훨씬 빠르게 닫히고 있습니다. 공식 세션이 끝난 뒤 이어진 네트워킹 자리에서도 분위기는 이어졌습니다. 실무자들이 각자의 상황을 꺼내 비교하고, 같은 문제를 안고 있는 사람을 찾아가는 그 대화들, 그것이 현장의 긴박감을 추상이 아닌 현실로 만들었습니다. 그 긴박감은 꾸며진 게 아니었습니다. 30일 안에 현황 파악. 60일 안에 통제 체계 수립. 90일 안에 운영. 충분히 합리적인 시작점입니다. 단, 그 시작이 지금이어야 합니다.