jacobhan.me

보안 아키텍처

API가 UI가 될 때 — 에이전트 중심으로 재편되는 보안 스택

취약점이 공개되기 전에 이미 악용되는 시대가 왔다. 방어 시간이 음수가 된 환경에서 보안 조직의 운영 모델과 보안 제품의 해자(moat)는 동시에 다시 계산되고 있다. 데이터·관리·제어라는 세 평면으로 이 재편을 읽는다.

2026년 8월 8일

방어의 시간표가 뒤집혔다. 한때 조직은 알려진 취약점이나 제로데이(zero-day, 패치 이전에 악용되는 결함)에 대응할 30일 안팎의 여유를 가정하고 패치 정책을 세웠다. 지금 그 가정은 성립하지 않는다.

취약점 공개와 실제 악용 사이의 간격을 추적하는 공개 대시보드 '제로데이 클록(Zero Day Clock)'의 데이터가 이 변화를 가장 건조하게 보여준다. 이 프로젝트는 실환경 악용이 확인된 3,500여 건의 CVE(Common Vulnerabilities and Exposures, 공통 취약점 및 노출)–익스플로잇 쌍을 대상으로, 익스플로잇 신호가 관측된 날짜에서 NVD(National Vulnerability Database, 미국 국가취약점데이터베이스) 공개일을 뺀 값을 TTE(Time-to-Exploit, 악용까지의 시간)로 정의한다. 값이 음수면 공개보다 악용이 먼저 일어났다는 뜻이다. 2018년 이후 공개된 약 23만 5,000건의 CVE 가운데 실제 악용이 확인된 것은 1.5% 수준이며, 대시보드는 그 부분집합만 다룬다.

공개에서 악용까지, 중위 소요 시간

실시간 대시보드 값이므로 조회 시점에 따라 달라진다. 막대 길이는 로그 스케일 기준의 상대 크기다. 2024년 이후 값은 시간 단위로 붕괴하며, 2025년 이후에는 다수 사례가 공개 이전에 악용된다.

2018771일
202184일
20236일
20244시간
2025~0일 이하
73%공개 전 악용된 비중(2026년 5월 시점). 5년 전에는 31%였다
-7일맨디언트 M-Trends 2026이 제시한 평균 TTE. 2018년에는 63일이었다
90건2025년 실환경에서 악용이 관측된 제로데이. 48%가 기업용 기술을 표적으로 삼았다
43일이미 악용이 확인된 취약점의 중위 수정 소요일(2026년 침해조사보고서)

같은 방향의 신호가 여러 곳에서 나온다. 크라우드스트라이크의 2026년 위협 보고서는 공개 이전에 악용된 제로데이가 전년 대비 42% 늘었다고 집계했고, AI가 개입한 공격은 89% 증가했다고 보고했다. 하루에 등록되는 신규 CVE는 135건 안팎으로 전년보다 40% 가까이 늘었다. 반면 방어 측 수치는 반대로 움직인다. 알려진 악용 취약점의 중위 수정 기간은 32일에서 43일로 늘었고, 끝까지 패치되는 비율은 26% 수준에 머문다. 미국 사이버보안·인프라보안국(CISA)이 악용 확인 취약점 목록(KEV)의 기본 조치 기한을 2주에서 3일로 줄이는 방안을 검토한다는 보도가 5월에 나온 것도 이 격차 때문이다.

공격 측의 반복 주기는 모델 성능에 연동되어 짧아지는데, 방어 측의 반복 주기는 변경관리·회귀시험·가동률 약정에 묶여 있다. 이 비대칭이 지금 보안 아키텍처 논의의 출발점이다.

여기서 나오는 결론은 '도구를 더 사자'가 아니다. 최고정보보호책임자(CISO)의 역할 자체가 도구 관리자에서 에이전트 관리자로 옮겨가고, 그에 맞춰 스택이 다시 짜인다는 것이다. 그리고 이 이동의 이익은 벤더 전체에 고르게 분배되지 않는다.

1. 이제 보안팀도 직접 만든다

첫 번째 변화는 조달의 문제다. 애플리케이션과 에이전트를 개인이 만들 수 있게 되면서, 보안팀도 그 대열에 들어왔다. 부(副)최고정보보호책임자급 실무자가 자기 이름으로 다섯 개의 에이전트를 24시간 돌리는 사례가 이미 업계 대화에 등장한다. 이는 인력 증강 효과이면서 동시에 구매 결정의 재검토를 촉발한다. 직접 만들어 우리 운영 방식에 맞출 수 있는 기능을 왜 별도 제품으로 사야 하는가.

실제 사례가 이 물음을 구체화한다. 노션(Notion)의 보안팀은 자사 커스텀 에이전트 기능으로 '스크러프(Scruff)'라는 에이전트를 만들어 보안 알림의 분류와 보강을 맡겼다. 알림이 구조화된 데이터베이스로 들어오면 에이전트가 트리거를 받아 조사 준비 작업을 대신하고, 사람은 판단이 필요한 결정에만 개입한다. 이 팀은 주당 6시간 이상을 절감했다고 밝혔으며, 같은 방식으로 애플리케이션 보안 자동화, 코드 수정안 생성, 적대적 테스트까지 에이전트에 넘겼다. 흥미로운 지점은 이 팀이 남긴 평가다. 가장 강력한 자동화는 별도 플랫폼이 아니라, 업무가 이미 일어나는 자리에서 조직의 맥락을 아는 AI라는 것이었다.

다만 이 논리에는 명확한 한계선이 있다. 크라우드스트라이크나 센티널원(SentinelOne)을 즉석에서 코딩해 대체하는 일은 일어나지 않는다. 엔드포인트에 깊게 박힌 센서, 그로부터 나오는 텔레메트리, 그 데이터가 만드는 네트워크 효과는 사내 개발로 재현할 수 없다. 재검토 대상은 제어점 자체가 아니라, 벤더 제품 코드 안에 들어 있는 분석·리포팅·워크플로 계층이다. 그 계층은 조직마다 다르고, 조직마다 다른 것은 조직이 직접 만드는 편이 유리해지는 영역이다.

2. 헤드리스로 가는 소프트웨어

두 번째 변화는 인터페이스다. 에이전트 채택이 빨라지면서 소프트웨어는 사람이 로그인하는 화면을 전제하지 않는 방향으로 이동한다. 2026년 4월 샌프란시스코에서 열린 개발자 행사에서 세일즈포스는 '헤드리스 360(Headless 360)'을 발표했다. 마크 베니오프 최고경영자의 표현은 간명했다. 브라우저는 필요 없고, API가 곧 UI라는 것이다. CRM 데이터부터 에이전트포스(Agentforce), 슬랙까지 플랫폼 전체를 API와 MCP(Model Context Protocol, 모델 컨텍스트 프로토콜) 도구, CLI 명령으로 노출했다. 60여 개의 MCP 도구와 30여 개의 코딩 스킬이 함께 공개되어 클로드 코드, 커서, 코덱스 같은 외부 코딩 에이전트가 조직의 업무 로직에 직접 접근한다. 27년 동안 '로그인하는 플랫폼'이던 제품이 스스로를 인프라로 재정의한 셈이다.

보안 영역도 같은 방향으로 움직인다. 시스딕(Sysdig)은 헤드리스 클라우드 보안 제품으로 쓸 수 있고, 트렌치(Trench)는 헤드리스 보안운영 제품을 만들었다. 다수 벤더는 자사 데이터를 에이전트가 끌어갈 수 있도록 MCP 서버를 붙였다. 앞서 언급한 노션의 사례에서도, 조사 워크플로를 돌리는 동안 사람이 위즈(Wiz)나 크라우드스트라이크, 스캐너의 화면에 브라우저로 접속하지 않는다. 에이전트가 API와 MCP로 데이터를 당겨오고, 사람은 그 결과에 대해 결정만 한다. 클로드에서 위즈와 애저(Azure) 등 보안 도구로 커넥터를 붙여 하나의 대화 인터페이스에서 분석을 수행하는 조직도 있다.

여러 개의 화면을 오가는 시대가 끝나가는 것은 분명하다. 그렇다면 남는 질문은 하나다. API가 UI가 되는 세계에서 관리 인터페이스는 무엇이 되는가.

3. 프런티어 랩이 보안 안으로 들어왔다

세 번째 변화가 가장 직접적이다. 프런티어 모델을 만드는 회사들이 보안 제품 영역에 진입했다. 이들은 두 방향에서 동시에 압력을 만든다. 하나는 보안 전용 기능을 직접 출시하는 경로이고, 다른 하나는 보안팀이 자체 도구를 만드는 문턱을 낮춰 간접적으로 수요를 흡수하는 경로다.

2026년 2월
앤스로픽이 클로드 코드 시큐리티를 리서치 프리뷰로 공개. 코드베이스를 스캔해 취약점을 찾고 패치를 제안한다. 규칙 기반 정적 분석과 달리 비즈니스 로직 결함까지 추론한다는 점이 쟁점이 됐다.
2026년 3월
오픈AI가 코덱스 시큐리티를 공개. 리포지토리의 위협 모델을 먼저 구성한 뒤 취약점을 탐색하고 수정안을 내는 애플리케이션 보안 에이전트로, 2025년부터 넷기어 등과 비공개 베타를 거쳤다.
2026년 3월
크라우드스트라이크가 샬럿 AI 에이전트웍스 생태계 발표. 팰컨 플랫폼 위에서 노코드로 보안 에이전트를 만들게 열고, 앤스로픽·오픈AI·AWS·엔비디아·세일즈포스 등을 출시 파트너로 세웠다.
2026년 4월
앤스로픽이 이름을 클로드 시큐리티로 바꿔 공개 베타 전환. API 연동이나 자체 에이전트 구축 없이 저장소를 선택해 스캔하는 형태로, 예약 스캔과 표적 스캔, 처리 결과 추적을 붙였다.
2026년 6월
시스코가 시스코 클라우드 컨트롤을 공개. 네트워킹·보안·컴퓨트·관측가능성을 하나의 로그인과 하나의 데이터 계층으로 묶고, 그 위에 에이전트 빌더와 앱 빌더, 마켓플레이스를 얹었다. 앱 빌더에는 오픈AI 코덱스가 내장됐다.
2026년 7월
클로드 코드용 보안 플러그인 베타 공개. 기존 세션 안에서 멀티에이전트 스캔을 돌리고, 선택한 발견 항목을 검토 후 적용할 패치 파일로 바꿔준다.

시장은 이 진입을 해자에 대한 위협으로 읽었다. 2월 발표 직후 순수 보안 종목이 큰 폭으로 하락했다는 보도가 나왔다. 규칙 기반 제품의 시대가 끝난다는 해석이 과열된 반응이었는지는 별개 문제이고, 중요한 것은 그 반응이 겨눈 지점이다. 시장이 의심한 것은 센서와 텔레메트리가 아니라, 그 위에 얹힌 분석과 판단 계층이었다.

플랫폼 기업들은 같은 흐름을 자기 쪽으로 끌어오는 방식으로 대응했다. 마이크로소프트의 시큐리티 코파일럿은 피싱 신고 분류, 데이터 유출 방지 알림과 내부 위험 알림 분류, 취약점 개선, 위협 인텔리전스 브리핑, 조건부 액세스 정책 변동 감지 등을 각각의 에이전트로 나눠 배치했다. 팰로알토네트웍스는 기존 보안 오케스트레이션 제품의 후속으로 코텍스 에이전티엑스(Cortex AgentiX)를 내놓고 네이티브 MCP를 붙였으며, 구글은 원격 MCP 서버를 정식 출시하고 트리아지·위협 헌팅·탐지 엔지니어링을 담당하는 에이전트 구성으로 보안운영을 재편했다. 결과적으로 에이전트 상호운용성은 미래 논의 항목이 아니라 지금 도입 평가서에 들어가는 항목이 됐다.

여기에 소형 언어 모델(SLM)과 오픈소스 모델의 자리도 남아 있다. 특정 용도에 맞춰 조직의 맥락으로 학습시키면 운영 비용이 낮고 해당 작업에서는 더 나은 결과를 낼 수 있다. 다만 성능 상위 오픈소스 모델의 상당수가 중국에서 나오고 있어, 그 모델을 어디까지 신뢰하고 어떻게 통제할 것인가라는 별도의 문제가 붙는다. 실행 시점에 데이터 보호를 적용하는 계층을 함께 두는 접근이 현실적 타협안으로 거론된다.

다음 스택 — 세 개의 평면

세 변화를 합치면 스택의 모양이 나온다. 핵심 전제는 이 스택이 사람이 아니라 에이전트를 1차 사용자로 두고 설계된다는 점이다. 그러려면 견고한 데이터 기반, AI를 전제로 한 아키텍처, 그리고 에이전트가 실제로 접근할 수 있는 열린 인터페이스가 필요하다.

관리 평면 — 오케스트레이션과 보고

보안운영 조직이 실제로 일하는 자리다. 제어 환경 전반을 가로지르는 에이전트를 만들고 관리하며, 그 에이전트들이 공유하는 중앙 컨텍스트 계층을 운용한다. 오늘날 흩어져 있는 다수의 관리 화면이 이 평면에서 하나로 수렴할 것으로 본다. 도메인별 에이전트의 정의를 통해 아래 제어 평면까지 손이 닿는다.

에이전트 하니스컨텍스트 계층정책 일관성단일 관리 인터페이스
▲ 정책 하달 · 상태 수집 ▼

제어 평면 — 최전선의 제어점

방화벽, 엔드포인트 탐지·대응(EDR), 신원 공급자(IdP), 클라우드 네이티브 애플리케이션 보호 플랫폼(CNAPP), 이메일 보안처럼 지금 익숙한 기술들이 그대로 남는다. 달라지는 것은 형태다. 각 도메인은 그 도메인 전용 에이전트가 운영하고, 관리 평면이 이들을 조율해 전사 정책을 일관되게 집행한다. 여기에 공격·방어 에이전트, 즉 레드팀과 블루팀의 자리도 함께 들어간다.

EDRIdP · 인증서CNAPP이메일 보안도메인 에이전트
▲ 원격 측정 · 이벤트 ▼

데이터 평면 — 데이터 기반

보안 운영 모델에 필요한 모든 데이터가 저장되고 분석되는 기층이다. 통상 보안 데이터 파이프라인과 데이터 레이크의 조합으로 구현된다. 에이전트가 이 기층에 얼마나 빠르게 접근하는지가 위쪽 두 평면의 실효 속도를 결정한다.

보안 데이터 파이프라인데이터 레이크빠른 파싱·검색

이 구조에서 보안운영 조직의 일은 성격이 바뀐다. 알림을 사람이 열어보는 일이 아니라, 정책을 스택 전반에 일관되게 구현하고 규제와 위험 프로파일의 변화에 따라 조정하는 오케스트레이션 에이전트 무리를 설계하고 관리하는 일에 가까워진다. 거버넌스·리스크·컴플라이언스(GRC) 기능과 닮은 모양이다. 동시에 도메인별 에이전트는 깊은 전문성을 요구하며, 그 전문가는 에이전트가 무너지는 지점에서 직접 개입해야 한다. 자동화의 확대가 전문성의 감소를 뜻하지 않는다는 점이 이 그림의 중요한 함의다.

무엇이 남고 무엇이 흡수되는가

이익이 고르게 분배되지 않는다는 말의 구체적 내용은 이렇게 정리된다.

방어 가능성 높음깊게 박힌 제어점

  • 엔드포인트 — 센서에서 나오는 텔레메트리와 1차 차단은 사내 개발로 재현하기 어렵다
  • 신원·인증·인증서 인프라 — 깊은 기술 전문성이 곧 진입 장벽이며 환경의 제어점 자체다
  • 브랜드와 신뢰 — 정교한 공격을 경계에서 막는 일을 사내 제작물에 맡기려는 조직은 드물다
  • 조직 밖에서만 얻는 데이터 — 내부에서 조달할 수 없는 데이터와 그로부터 나오는 네트워크 효과

대체 압력 높음분석·보고·워크플로

  • 대시보드 — 제품마다 하나씩 있던 화면은 조직이 직접 만든 단일 인터페이스로 흡수된다
  • 알림 분류와 요약 — 반복적이고 분석 비중이 큰 작업이 가장 먼저 넘어간다
  • 워크플로 실행 — 조직마다 다른 절차는 조직이 직접 만드는 편이 유리하다
  • 접근 권한 검토·위협 보고서 요약 — 이미 상당수 기업에서 진행 중인 영역이다

이 구분은 정태적이지 않다. 자동화가 반복 작업에서 시작해 아키텍처 검토, 공격 테스트, 위협 헌팅처럼 복잡한 작업으로 확장되고 있고, 이런 역량은 이미 상용 제품으로 접근 가능하다. 다만 중요한 결정, 특히 잘못될 경우 가용성이나 보안 태세에 타격을 주는 결정에서는 사람이 회로 안에 남는다는 전제가 유지된다.

제품 기능의 기준선도 함께 올라간다. 모든 조직이 자기 도구를 만들지는 않겠지만, 만들 수 있다는 사실만으로 '이 기능은 살 만한가'의 기준이 상향된다. 벤더 입장에서 값이 붙는 것은 단일 기능이 아니라 네트워크 효과, 조직 내부에서 조달 불가능한 데이터, 그리고 브랜드다.

만들 것인가, 플랫폼에 얹을 것인가

직접 만든다는 선택지가 열렸다고 해서 전부 직접 만드는 결론이 나오지는 않는다. 실제 선택은 세 갈래다. 전부 자체 구축, 플랫폼이 제공하는 에이전트 빌더 확장, 또는 에이전트를 전제로 설계된 벤더 생태계 구매다.

현재 플랫폼 위에 전체 보안 기능을 올려 짓는 기업은 많지 않지만, 이 균형은 이동할 수 있다. 빌더 플랫폼의 실질적 이점은 제작 편의가 아니라 통합이다. 기존 IT·보안 스택과의 연결이 이미 깔려 있는 환경에서 만드는 것이, 제3자 도구로 만들고 커넥터를 하나씩 손으로 붙이는 것보다 실무적으로 빠르다. 플랫폼들이 나란히 마켓플레이스를 연 것도 같은 계산에서다. 상당수 벤더는 자사 제품을 마켓플레이스 제공물로 리팩터링해, 최신 기능이 여러 플랫폼에서 동시에 소비되도록 만들 것으로 보인다.

관리 인터페이스의 향방도 같은 방식으로 갈린다. 수많은 보안 화면이 하나로 수렴한다는 방향성은 분명하지만, 그 하나가 조직이 직접 만든 것일지 플랫폼 위에 올린 것일지는 결정되지 않았다. 두 형태가 섞이는 쪽이 현실적이다.

공격 측은 이미 이 스택으로 움직인다

방어 측 아키텍처 논의가 사변으로 들리지 않는 이유는, 같은 구조가 공격 측에서 먼저 작동하기 시작했기 때문이다. 2025년 9월 앤스로픽은 GTG-1002로 명명한 캠페인을 탐지해 공개했다. 클로드 코드를 무기화해 약 30개 조직을 표적으로 삼은 사이버 첩보 활동으로, 전술 단계 작업의 80~90%를 AI가 수행하고 사람은 표적 선정과 데이터 유출 승인 같은 전략적 판단에만 개입했다. 공격자는 모델의 안전장치를 기술적으로 우회한 것이 아니라, 자신이 정당한 보안 업체의 침투 테스트를 수행하는 직원이라고 모델을 설득하는 방식으로 통과했다. 미국 의회조사국은 이를 최초로 문서화된 AI 오케스트레이션 사이버 공격 사례로 기록했다. 자율성과 성공률이 보고된 만큼이었는지에 대해서는 이견이 있다.

이후 사례는 더 노골적이다.

여기에 최근 사례 하나를 덧붙일 수 있다. 영국 AI 보안연구소는 8월 초 공개한 사고 보고서에서, 통제된 역량 평가 중 프런티어 에이전트가 익명 네트워크를 경유해 승인되지 않은 외부 활동으로 이탈한 정황을 기술했다. 평가 환경에서 발생한 사건이며 아직 검증과 해석이 진행 중이지만, 샌드박스와 공개 인터넷의 경계가 에이전트의 목표 인식에 따라 무의미해질 수 있다는 문제를 제기한다.

공통 패턴은 하나다. 정찰, 익스플로잇 코드 작성, 에스컬레이션 시점 판단처럼 훈련된 사람이 하던 일을 에이전트가 대신했다. 공격의 단가가 내려가면 표적 수가 늘어나고, 표적 수가 늘어나면 방어 측의 우선순위 판단 자체가 병목이 된다.

제어계통으로 확장할 때의 제약

이 논의는 대부분 기업 정보시스템(IT)을 전제로 전개된다. 운영기술(OT)과 제어계통에 그대로 옮기려 할 때 두 가지 제약이 즉시 걸린다.

첫째, 패치 창이다. 정보시스템에서 '기계 속도의 대응'은 대체로 격리·차단·롤백을 의미하지만, 제어계통에서 같은 동작은 공정 정지나 계통 사고로 직결될 수 있다. 자율 조치의 허용 범위를 어디에 그을 것인가가 정보시스템보다 훨씬 좁은 구간에서 결정되어야 한다. 자율 에이전트의 오작동 비용이 비대칭적으로 큰 환경에서는, 사람이 회로 안에 남는다는 전제가 선택이 아니라 요건이다.

둘째, 데이터 평면의 부재다. 위 스택은 모든 관련 데이터가 하나의 기층에 모여 있다는 가정 위에 서 있다. 제어계통은 통신 프로토콜이 이질적이고 계측 지점이 희소하며, 데이터가 시스템별로 분절되어 있다. 관리 평면을 세우기 전에 데이터 평면을 세워야 하는데, 그 작업의 난도가 정보시스템 쪽과 다르다. 시스코가 클라우드 컨트롤을 발표하며 '핵심 IT 인프라의 운영과 방어'를 함께 내세운 것도, 이 계층 문제를 플랫폼 차원에서 흡수하려는 시도로 읽힌다.

정리

스타트업과 성장기업에 남는 과제는 명확하다. 자기 제품이 세 평면 중 어디에 서 있는지, 그리고 어떤 기능이 실제로 방어 가능하고 어떤 기능이 자체 제작물로 흡수될지를 구분해야 한다. 방어 가능성이 확인된 지점에서는 그 역량을 에이전트 중심 생태계에 어떻게 얹을지, 독립 제품으로 갈지 플랫폼 마켓플레이스 경유로 갈지가 다음 결정이다.

평면별로 보면 이렇다. 제어 평면에 있다면 서비스가 에이전트에게 쉽게 접근·소비되도록 만드는 일이 최우선이다. 기술이 가장 좋은 것만으로는 부족하고, 에이전트 생태계에 매끄럽게 통합되는 쪽이 이긴다. 데이터 평면에서 데이터 레이크 자체는 기존 대형 사업자의 몫에 가깝지만, 에이전트와 데이터 기층 사이의 파이프라인 — 빠른 파싱과 검색으로 왕복을 줄이는 계층 — 에는 여지가 있다. 가장 큰 파괴와 기회가 동시에 있는 곳은 관리 평면, 그리고 그것이 도메인별 에이전트를 통해 제어 평면까지 내려가는 구간이다. 조직이 자체적으로 만드는 수준을 넘어서는 일관성과 정확도, 속도를 내는 오케스트레이션 하니스가 되는 것이 이 구간의 생존 조건이다.

보안 조직 쪽의 결론은 더 간결하다. 도구 묶음의 관리자에서 에이전트의 관리자로 이동하는 일이며, 그 과정에서 직무는 분석가에서 엔지니어로 옮겨간다. 그 이동을 거부하는 선택지도 물론 존재하지만, 방어 시간이 이미 음수가 된 환경에서 그 선택의 비용은 매년 커진다.