탐눈, 클라우드 취약점 AI 자동 수정 확대…패치 전에 운영 장애부터 검증

클라우드 보안, 이제 ‘찾았다’보다 ‘고쳤다’가 더 중요함

• 탐눈이 AI 엔진 ‘타미(Tami)’를 스킬 기반 수정 오케스트레이터로 확장함

  • 고객 환경에 맞는 취약점 수정 절차를 자동 생성함
  • 보안 위험 유형별로 수정 실행과 운영 검증을 같이 수행함
  • 멀티클라우드, 쿠버네티스, API 기반 환경에서 수정 지연과 장애 위험을 줄이는 게 목표임

• 배경은 단순함. AI 기반 개발 도구가 코드를 더 빨리 만들면서, 취약 코드와 잘못된 클라우드 설정도 같이 늘고 있음

  • 기업은 더 많은 애플리케이션, API, 클라우드 워크로드를 운영하게 됨
  • 보안 플랫폼은 경고와 우선순위 분석을 잘해도, 실제 운영 환경에서는 수정 작업이 계속 밀림
  • 가트너에 따르면 중요 클라우드 경고의 평균 수정 시간은 128일임. 이쯤 되면 경고가 문제가 아니라 수습이 문제임

타미는 ‘단일 에이전트’가 아니라 수정 스킬 조정자

• 탐눈은 클라우드 환경에 약 1200개 수준의 서로 다른 보안 문제 유형이 있다고 설명함

  • 각각 수정 절차가 다르고, 확인해야 할 의존성도 다름
  • 그러니까 하나의 범용 패치 스크립트로 밀어붙이는 방식은 운영 환경에서 위험함

• 타미는 800개 이상 고객 계정과 600만 건 이상 실제 클라우드 수정 데이터를 기반으로 수정 스킬을 생성함

  • 고객별 자산 의존성, 운영 정책, 애플리케이션 영향 범위를 반영함
  • 같은 취약점처럼 보여도 고객 환경에 따라 다른 절차를 적용하는 구조임

• 고위험 수정 작업은 탐눈 전문가 조직 ‘CloudPros’ 검토를 거침

  • AI가 만든 수정안을 바로 운영에 넣는 게 아니라, 위험한 작업에는 사람 검증 단계를 둠
  • 기업과 파트너가 자체 수정 스킬을 추가할 수 있는 개방형 오케스트레이션 계층도 제공한다고 밝힘

패치 전에 ‘이거 서비스 안 죽나?’를 먼저 본다

• 이번 업데이트에서 눈에 띄는 기능은 ‘수정 신뢰 점수(Remediation Confidence Score)’임

  • 수정 작업을 SAFE, RISKY, UNSAFE 등급으로 분류함
  • 개발자에게 넘기기 전에 운영 위험도를 먼저 확인하게 해줌
  • 운영 중단 가능성과 의존성 충돌 여부도 함께 평가함

• ‘안전 취약점 패치 시뮬레이터’ 베타 기능도 공개됨

  • 실제 운영 적용 전에 버전 호환성, 의존성, 런타임 변화를 샌드박스에서 검증함
  • 쿠버네티스나 멀티클라우드처럼 설정과 의존성이 얽힌 환경에서는 이 단계가 꽤 중요함

• 탐눈은 플랫폼 규모와 성과 수치도 같이 공개함

  • 1000만 개 이상 워크로드 환경에서 운영 중이라고 밝힘
  • 90일 기준 노출 감소율 97%를 제시함
  • 운영 효율 비율은 142대1, 운영 환경 사고는 0건이라고 주장함

국내 기업도 남 얘기가 아님

• 생성형 AI와 AI 에이전트가 개발 속도를 올리면서 보안 운영 부담도 같이 커지고 있음

  • 코드 생산량이 늘면 애플리케이션, API, 워크로드도 늘어남
  • 그만큼 취약점과 잘못된 설정을 사람이 일일이 추적하기 어려워짐

• 특히 금융, 제조, 플랫폼 기업은 “빨리 고치되 서비스는 멈추면 안 되는” 압박을 동시에 받음

  • 클라우드 네이티브 전환이 진행될수록 취약점 대응은 단순 티켓 처리로 끝나지 않음
  • 운영 안정성, 변경 추적, 내부 정책, 컴플라이언스까지 같이 봐야 함

• 탐눈의 방향은 CNAPP 경고 탐지 이후를 겨냥함

  • 지금까지 많은 보안 도구가 “위험을 찾아줌”에 집중했다면, 이제는 “검증하고 실제로 고쳐줌”까지 가는 흐름임
  • AI 자동화가 들어갈수록 수정 실행과 운영 안정성 검증은 한 세트가 될 가능성이 큼

---

기술 맥락

• 이 기사에서 중요한 선택은 탐지 자동화가 아니라 수정 자동화예요. 클라우드 보안에서는 취약점을 찾는 도구가 많아졌지만, 실제 운영에 패치를 넣는 순간 장애 위험이 생기거든요.

• 타미가 스킬 기반 오케스트레이터를 택한 이유는 클라우드 문제가 너무 다양하기 때문이에요. 탐눈은 보안 문제 유형이 약 1200개라고 말하는데, 각 문제마다 의존성, 정책, 서비스 영향 범위가 달라서 단일 자동 수정 방식으로는 위험해요.

• 수정 신뢰 점수와 패치 시뮬레이터는 자동화의 속도를 유지하면서도 운영 리스크를 낮추는 장치예요. SAFE, RISKY, UNSAFE처럼 등급을 나누고 샌드박스에서 런타임 변화를 확인해야 개발팀이 패치를 덜 무서워해요.

• 국내 기업에도 이 흐름이 바로 연결돼요. 생성형 AI로 개발 속도가 올라가면 취약점도 더 빨리 쌓이기 때문에, 보안팀은 경고를 잘 분류하는 것보다 장애 없이 닫는 체계를 더 필요로 하게 돼요.