블로그

전체 81

AI 엔지니어링의 계획부터 실행까지 자율로 처리하는 AI 에이전트 - Arize Alyx 2.0

2026/03/30 by. pr@cloudnetworks.co.kr

AI 엔지니어링의 계획부터 실행까지 자율로 처리하는 AI 에이전트 - Arize Alyx 2.0

Alyx 2.0은 Arize AI가 출시한 AI 엔지니어링 에이전트로, Arize AX 플랫폼 전반에 내장되어 AI 시스템의 디버깅, 평가, 프롬프트 최적화, 실험을 자율적으로 계획하고 실행합니다. 단순히 질문에 답하는 챗봇이 아니라, 다단계 워크플로를 스스로 분해하고 실행하는 진정한 계획(Planning) 에이전트입니다. Alyx 2.0은 장애 원인을 수 초 안에 분석하고, 프로덕션 장애에서 테스트 데이터셋을 자동으로 생성하며, 프롬프트 실험 전체를 하나의 워크플로로 처리합니다. Arize AX 플랫폼의 트레이스 화면, 프롬프트 플레이그라운드, Eval Builder, 데이터셋·실험 페이지 등 어느 화면에서든 작동하며, AX CLI를 통해 Cursor, Claude Code 같은 외부 개발 환경과도 연결됩니다.이번 블로그에서는 계획하고 실행하는 AI 에이전트 'Alyx 2.0'의 기능과 작동 방식을 소개합니다.Arize AX, 그리고 AlyxArize AX는 개발 단계부터 실제 운영까지 AI 에이전트와 애플리케이션을 모니터링하고 개선하는 엔터프라이즈 AI 엔지니어링 플랫폼입니다. 에이전트 레벨 트레이싱, 프롬프트 최적화, 온라인·오프라인 평가(Evaluation), 실시간 모니터링 및 알림, ML·컴퓨터 비전 모델 관측성까지 AI 시스템 운영에 필요한 기능을 하나의 플랫폼에서 제공합니다. LLM 기반 AI 시스템을 운영하는 팀이 모델의 동작을 이해하고, 오류를 진단하고, 지속적으로 개선할 수 있도록 설계된 플랫폼입니다.AI 제품을 만드는 팀이라면 익숙한 상황이 있습니다. 모델은 어느 정도 완성됐는데, 정작 시간의 대부분은 트레이스를 뒤지거나, 평가 기준을 손으로 설정하거나, 여러 툴 사이를 오가며 결과를 직접 이어 붙이는 데 쓰입니다. 어떤 팀은 LLM 애플리케이션 하나를 운영하기 위해 트레이싱 툴, 평가 프레임워크, 프롬프트 관리 시스템, 실험 플랫폼을 각각 별도로 운용합니다. 이 툴들 사이를 오가며 데이터를 복사하고, 결과를 수동으로 정리하고, 다음 액션을 직접 결정하는 과정이 반복됩니다. 이 워크플로들은 파편화되어 있고, 수동적이며, 느립니다. 시스템이 점점 더 에이전틱해질수록 이 문제는 더 심각해집니다.Arize AX는 이 파편화된 워크플로를 하나의 플랫폼으로 통합합니다. 그리고 Alyx는 그 플랫폼 위에서 작동하는 에이전트입니다. Alyx는 이 Arize AX 플랫폼 전반에 내장된 AI 에이전트로, AI 엔지니어가 애플리케이션을 구축하고 개선하는 과정을 지원하도록 설계되어 있습니다. 사용자가 플랫폼의 어느 화면에 있는지에 따라 Alyx는 그에 맞는 컨텍스트와 기능을 제공합니다. 별도로 실행하는 툴이 아니라, 작업하는 화면에 항상 함께 있으면서 그 맥락에 맞는 기능을 제공하는 방식입니다.Alyx가 기존 AI 어시스턴트와 다른 이유AI 어시스턴트라는 말을 들으면 보통 질문에 답하거나, 정해진 흐름대로 실행하는 도구를 떠올립니다. 기존의 많은 AI 어시스턴트는 사전 정의된 워크플로를 실행하거나 단일 결정 트리를 따르는 수준에 머물렀습니다. 적응하지 못하고, 복잡한 액션을 조합하지 못하며, 예상치 못한 결과를 만들어내지도 못합니다.Alyx 2.0이 다른 이유는 계획(Planning) 능력에 있습니다. Alyx 2.0은 다단계 작업을 추론하고, 액션 전반에서 컨텍스트를 유지하며, 필요할 경우 UI와 직접 상호작용하고, 중요한 의사결정 지점에서 사용자 승인을 요청하는 진정한 오케스트레이터입니다. 단순히 더 나은 모델을 쓰거나 더 많은 툴 호출을 하는 것이 아니라, 계획 자체가 핵심 변화입니다.Alyx는 정교한 오케스트레이션 시스템을 기반으로 구축되어 있으며, 다단계 워크플로를 관리하고, 툴 호출을 조율하고, 복잡한 분석 전반에 걸쳐 컨텍스트를 유지합니다. 사용자가 어떤 툴을 사용해야 하는지, 어떤 정보를 쿼리에 제공해야 하는지 알 필요 없이, Alyx가 요청을 동적으로 라우팅하고, 적절한 툴을 선택하고, 작업을 연결해 질문에 답합니다.이 오케스트레이터 아키텍처가 가능하게 하는 것들은 네 가지입니다. 첫째, 복잡한 질문을 다단계 계획으로 자동 분해하는 태스크 분해입니다. 둘째, 컨텍스트에 기반해 툴을 선택하고 순서를 정하는 툴 호출 조율입니다. 어떤 툴을 어떤 순서로 호출해야 하는지를 Alyx가 스스로 결정합니다. 셋째, 반복과 툴 호출 전반에 걸쳐 컨텍스트를 유지하는 대화 연속성입니다. 앞선 분석 결과를 기억하고, 다음 단계에서 그 결과를 활용합니다. 넷째, 작업이 실패하거나 재시도가 필요할 때 에이전트가 적응하는 오류 처리 및 복구입니다. 기존의 분석 툴이 AI 시스템 데이터를 일반적인 관측성 트레이스로 취급하는 것과 달리, Alyx는 LLM 워크플로와 AI 에이전트의 고유한 구조와 의미를 이해하도록 설계되어 있습니다.결과적으로 작업의 단위 자체가 달라집니다. 프롬프트, 트레이스, 개별 평가 수준이 아니라 AI 엔지니어링 전체 라이프사이클 수준에서 작동합니다. 실제 장애에서 데이터셋을 합성하고, 장애 패턴에서 평가를 도출하고, 어노테이션을 기반으로 프롬프트를 최적화하고, 실험을 실행 및 분석하는 과정을 하나의 연속된 루프로 처리합니다. Alyx는 툴을 직접 조율하는 것이 아니라 의도를 위임하는 방식입니다.Alyx가 실제로 해결하는 것들AI 시스템 운영에서 반복적으로 발생하는 문제들이 있습니다. 트레이스를 하나씩 열어보고 어노테이션을 검토하며 어디서 무엇이 잘못됐는지 추측하는 디버깅 과정, 테스트 데이터를 손으로 만들어야 하는 데이터 생성 과정, 빈 화면에서 시작하는 프롬프트 실험 과정이 그것입니다. Alyx는 이 세 가지를 모두 다른 방식으로 처리합니다.AI 시스템에서 문제가 생겼을 때 보통은 트레이스를 하나씩 열어보고, 어노테이션을 검토하고, 어디서 무엇이 잘못됐는지 추측하는 과정을 반복합니다. 에러 메시지 하나를 추적하는 데 수 시간이 걸리는 경우도 있고, 문제를 찾았더라도 그것이 실제로 중요한 이슈인지 판단하는 데 또 시간이 필요합니다. 어노테이션이 쌓여 있어도 그것을 체계적으로 분석해 레이블로 정리하고, 어떤 것이 실제로 중요한지 판단하는 과정은 여전히 수작업에 의존합니다.Alyx에게 "무엇이 잘못됐나요?"라고 질문하면 장애 패턴, 수정 제안, 최적화된 프롬프트를 수 초 내에 제공합니다. 트레이스 어노테이션을 종합해 이산적인 레이블로 정리하고, 실제로 중요한 이슈를 판단한 뒤 평가 템플릿을 생성하고 평가 태스크를 자동으로 실행합니다. 수동 리뷰도, 레이블 체계 논의도, 수작업 연결도 필요 없습니다.대부분의 디버깅 툴은 더 많은 데이터를 보여줄 뿐입니다. Alyx는 왜 문제가 발생했는지를 설명합니다. 특정 가이드라인까지 실패 원인을 추적하고, 정확한 의사결정 경로를 제시하며 근본 원인을 도출합니다. 추측 없이, 데이터 탐색 없이, 정확히 무엇을 수정해야 할지를 알 수 있습니다.장애를 파악했다면 다음은 재현과 검증입니다. 테스트 데이터를 만드는 일은 생각보다 많은 시간을 잡아먹습니다. 실제 프로덕션 환경에서 발생한 장애를 재현하는 케이스를 수동으로 구성하는 것은 번거롭고, 자동화되지 않은 경우 일관성도 보장하기 어렵습니다. 프로덕션 환경의 실제 장애를 바탕으로 테스트 데이터셋을 자동으로 생성하고, 그 장애 패턴을 회귀 테스트로 전환합니다. 수동으로 재현하거나 버그가 배포된 뒤에야 발견할 필요가 없습니다.장애 패턴이 파악되면 그것을 평가 기준으로 전환하는 과정도 자동화됩니다. 수동으로 평가 항목을 설계하거나 어떤 실패 케이스를 테스트로 만들어야 할지 고민할 필요가 없습니다. Alyx가 장애 패턴에서 직접 회귀 테스트를 생성하고, 같은 문제가 다시 배포되기 전에 잡아낼 수 있는 체계를 만들어 줍니다. 평가 설계에 들어가는 시간을 줄이고, 실제로 중요한 문제에 집중할 수 있게 됩니다.프롬프트 실험도 마찬가지입니다. 프롬프트 실험은 보통 최악의 상태에서 시작됩니다. 빈 플레이그라운드, 데이터셋 없음, 베이스라인 없음, 어디서부터 시작해야 할지 모르는 상태. 실험을 설계하는 것 자체에 많은 준비가 필요하고, 그 준비 과정에서 시간이 소모됩니다. 데이터셋을 준비하고, 프롬프트 변형을 만들고, 평가를 연결하고, 실험을 돌리고, 결과를 분석하고, 어떤 프롬프트가 나은지 판단하는 과정이 전부 수동입니다.Alyx를 사용하면 이 과정을 위임할 수 있습니다. 데이터셋 생성, 프롬프트 변형 생성, 평가 연결, 실험 실행, 결과 분석, 개선 사항 추천을 하나의 연속된 워크플로 안에서 처리합니다. 인터페이스를 클릭하거나 실험을 수동으로 실행하는 것이 아니라, 의도를 지시하면 Alyx가 실행을 담당합니다.Alyx가 작동하는 곳Alyx는 특정 화면에서만 작동하는 툴이 아닙니다. Arize AX 플랫폼 안에서 작업이 일어나는 곳이라면 어디서든 Alyx가 함께합니다. 각 화면에서 Alyx가 제공하는 기능은 그 화면의 맥락에 맞게 달라집니다.트레이스 상세 화면에서는 특정 트레이스에 대한 트러블슈팅과 스팬 분석, 어노테이션을 지원합니다. 프롬프트 플레이그라운드에서는 프롬프트 최적화와 실험 실행을 지원합니다. Eval Builder와 Task Builder에서는 커스텀 평가 항목 구성을 지원합니다. 트레이스 테이블의 검색창에서는 자연어를 필터 문법으로 변환하는 기능을 제공합니다. 자연어로 조건을 입력하면 Alyx가 이를 Arize AX의 필터 문법으로 변환해 적용합니다. 트레이스 메인 페이지에서는 여러 트레이스를 동시에 분석하고 패턴을 발견하는 멀티 트레이스 분석을 지원합니다. 데이터셋·실험 페이지에서는 실험 결과 분석과 데이터셋 관리를 지원합니다.여러 화면에서 공통으로 제공되는 기능도 있습니다. ArizeQL Generator는 자연어나 기존 코드(SQL, Python)를 커스텀 메트릭 생성을 위한 AQL로 변환합니다. 기존에 작성해둔 SQL 쿼리나 Python 코드가 있다면 그것을 그대로 AQL로 변환해 Arize AX에서 사용할 수 있습니다. Prompt Optimization은 품질 향상이나 특정 이슈 해결을 위해 프롬프트를 최적화합니다.LLM 외에 ML 및 컴퓨터 비전 임베딩 시각화 화면에서도 Alyx를 활용할 수 있습니다. 임베딩 페이지에서 특정 포인트나 클러스터를 선택한 뒤 "Summarize with Alyx"를 사용하면 해당 선택 항목에 대한 요약을 제공합니다.브라우저 안에서 Alyx가 자연어 의도로 작업을 처리한다면, AX CLI는 같은 데이터를 머신 리더블 형태로 만들어 코딩 에이전트가 직접 활용할 수 있도록 확장합니다. CLI로 최근 스팬 데이터를 로컬 파일로 추출한 뒤 Cursor나 Claude Code에 전달해 패턴 분석을 요청하는 방식으로, Arize AX의 데이터를 이미 사용 중인 개발 환경과 연결할 수 있습니다.Alyx 데이터 프라이버시엔터프라이즈 환경에서 데이터 보안은 빠질 수 없는 고려 사항입니다. AI 엔지니어링 플랫폼을 도입할 때 가장 먼저 확인하게 되는 것 중 하나가 데이터가 어떻게 처리되는지입니다. 특히 프로덕션 트레이스에는 민감한 사용자 데이터나 비즈니스 로직이 포함될 수 있기 때문에, Alyx가 그 데이터를 어떻게 다루는지는 도입 전에 명확히 파악해야 할 사항입니다.Arize의 Alyx는 Azure OpenAI를 기반으로 구축되어 있으며, 고객 데이터가 서드파티 제공업체에 직접 노출되지 않도록 보호합니다. Alyx의 입출력 데이터는 OpenAI 모델 개선, Microsoft 또는 서드파티 제품 개선, Azure OpenAI 모델 자동 개선 어디에도 사용되지 않으며, 모델은 Stateless로 운영되어 프롬프트나 결과물이 저장되지 않습니다. Azure OpenAI 서비스는 Microsoft가 완전히 통제하며, OpenAI가 운영하는 ChatGPT나 OpenAI API 같은 서비스와는 상호작용하지 않습니다.사용자 자신의 OpenAI 또는 Anthropic(AWS Bedrock, Vertex AI 경유) 모델을 Alyx에 직접 연결해 사용하는 것도 가능합니다. 고객 지원 기능의 경우, 지원 관련 질문을 할 경우 해당 질문 내용이 서드파티 서비스인 RunLLM에 전달됩니다. 공유되는 데이터는 해당 질문 텍스트에 한정되며, 추가적인 모델 정보나 사용자 데이터는 공유되지 않습니다.Alyx를 만드는 데 Alyx를 사용했습니다Arize는 2년 전 GPT-3.5로 Alyx 구축을 시작했습니다. 당시 에이전트는 유행어에 불과했고, 모델은 충분하지 않았으며, 툴 호출은 막 등장하던 시점이었습니다. 그러나 Arize는 하나의 가설을 갖고 있었습니다. 미래는 UI를 클릭하거나 어시스턴트와 채팅하는 것이 아니라, 원하는 것을 말하면 에이전트가 그것을 실행하는 방식이 될 것이라는 가설이었습니다.Arize는 Arize AX와 Alyx를 사용해 Alyx 자체를 구축했습니다. 그 과정에서 얻은 교훈들이 Alyx의 다음 방향을 만들어가고 있습니다. 자신이 만드는 제품을 직접 사용하면서 개선하는 이 방식은 Alyx가 실제 AI 엔지니어링 워크플로에서 어떤 문제가 발생하는지를 정확히 이해하고 있다는 것을 의미합니다. 이론적으로 설계된 기능이 아니라, 실제로 사용하면서 필요하다고 느낀 기능들로 구성된 에이전트입니다.Alyx를 구축하면서 Arize 팀을 놀라게 한 순간들이 여러 번 있었습니다. 명시적으로 설계하지 않은 것들을 Alyx가 스스로 해낸 것입니다. 이것이 진정한 에이전트를 구축하는 것의 재미이자 도전입니다.진짜 에이전트를 만드는 것의 어려움Arize는 Alyx를 구축하면서 마주한 기술적 과제들을 공개적으로 밝히고 있습니다.컨텍스트 관리는 매우 어렵습니다. 메시지 버스, UI 상태, 컨텍스트 윈도우 팽창. 중요한 정보를 잃지 않으면서 모든 것을 일관되게 유지하는 것은 지속적인 도전입니다. 회귀를 방지하기 위해 에이전트를 테스트하는 문제는 아직 해결되지 않았습니다. 시스템이 적응형으로 설계되어 있을 때, 프롬프트나 아키텍처 변경이 이전 워크플로를 깨뜨리지 않는지 어떻게 확인할 것인가. Arize는 Alyx 자체를 위한 커스텀 평가 프레임워크를 별도로 구축해야 했습니다. UI 통합도 예상보다 훨씬 어렵습니다. 프로그래매틱 액션과 서브 에이전트, 작고 재사용 가능하도록 툴을 스마트하게 분리하는 것. 모든 결정이 복잡하게 얽혀 있습니다.이 과제들을 공개하는 이유는 단순합니다. AI 엔지니어링 툴을 만드는 팀이 실제로 겪는 문제들을 Arize도 똑같이 겪으면서 Alyx를 만들었기 때문입니다. Alyx는 이론적인 설계가 아니라 실제 운영 경험에서 나온 에이전트입니다.Arize가 보는 Alyx의 미래Claude Code와 Cursor가 소프트웨어 개발을 혁신했을 때, 기존 워크플로에 AI를 추가한 것이 아니었습니다. 개발자가 코드와 상호작용하는 방식 자체를 근본적으로 재정의했습니다. 파일을 수동으로 검색하거나, 쿼리를 작성하거나, 툴을 구성하는 대신, 필요한 것을 자연어로 설명하면 지능적인 에이전트가 컨텍스트를 이해하고, 코드베이스를 탐색하고, 행동을 취했습니다.Arize는 Alyx를 AI 시스템의 구축, 디버깅, 최적화를 위한 필수 불가결한 에이전트로 만들겠다는 비전을 갖고 있습니다. 핵심 통찰은 같습니다. 복잡한 기술 작업의 미래는 더 많은 대시보드를 만들거나 더 많은 구성을 노출하는 것이 아닙니다. 애플리케이션을 이해하고 자연스러운 대화를 통해 복잡한 워크플로를 대신 실행할 수 있는 지능형 에이전트를 만드는 것입니다.AI 엔지니어링 툴의 미래는 Alyx처럼 생겼습니다. 도메인을 이해하고, 복잡한 워크플로를 실행하고, 정교한 시스템과의 자연어 상호작용을 가능하게 하는 지능형 에이전트. 이것은 기존 툴에 AI 기능을 추가하는 것이 아닙니다. 인간과 AI가 기술적 작업에서 협력하는 방식을 재정의하는 것입니다. Claude Code와 Cursor가 소프트웨어 개발에 가져온 혁신, 즉 수동 탐색과 구성에서 지능적이고 대화형 지원으로의 전환이 AI 엔지니어링에도 오고 있습니다. Alyx는 그것이 어떤 모습인지에 대한 Arize의 비전입니다.마치며AI PM이나 AI 엔지니어에게 가장 어려운 일은 프롬프트를 작성하는 것이 아닙니다. 그 주변의 모든 것이 문제입니다. 긴 세션에 걸쳐 컨텍스트를 관리하는 것, 모호한 장애를 재현 가능한 테스트 케이스로 전환하는 것, 겉보기엔 문제없는 프롬프트 변경 이후 에이전트가 왜 동작을 멈췄는지 파악하는 것. 이 문제들은 AI 시스템이 정교해질수록 더 빈번하게 발생하고, 해결하는 데 더 많은 시간이 필요합니다.Alyx는 이 문제들을 해결하기 위해 설계된 에이전트입니다. 장애 원인을 분석하고, 테스트 데이터를 생성하고, 평가 항목을 만들고, 프롬프트 실험을 실행하는 과정을 하나의 연속된 워크플로로 처리합니다. 사용자가 각 단계를 직접 조율할 필요 없이, 의도를 지시하면 Alyx가 계획을 세우고 실행합니다. Arize AX 플랫폼 전반에서 작동하며, AX CLI를 통해 Cursor나 Claude Code 같은 외부 개발 환경과도 연결됩니다.AI 엔지니어링의 방식이 바뀌고 있습니다. 툴을 직접 조율하는 것에서 의도를 위임하는 것으로, 수동 워크플로에서 에이전트가 계획하고 실행하는 방식으로. Alyx는 그 변화의 중심에 있습니다.클라우드네트웍스는 Arize AI 공식 파트너로서 국내 기업들이 Arize AX를 도입하고 실제 운영 환경에 적용하는 과정을 지원하고 있습니다. AI 시스템을 운영하면서 겪는 모니터링, 평가, 디버깅의 어려움을 Arize AX와 Alyx로 해결하고자 하는 팀이라면 클라우드네트웍스를 통해 도입 방향을 구체화할 수 있습니다.▶ Arize AI 자세히보기

March 30, 2026

시스코 AI 디펜스(Cisco AI Defense)란? 기업 AI 보안을 위한 탐색·탐지·보호 전략

2026/03/05 by. pr@cloudnetworks.co.kr

시스코 AI 디펜스(Cisco AI Defense)란? 기업 AI 보안을 위한 탐색·탐지·보호 전략

March 05, 2026

'섀도우 AI(Shadow AI)'란? AI 에이전트 보안 위협과 옥타(Okta)의 아이덴티티 기반 대응 전략

2026/03/03 by. pr@cloudnetworks.co.kr

'섀도우 AI(Shadow AI)'란? AI 에이전트 보안 위협과 옥타(Okta)의 아이덴티티 기반 대응 전략

AI 에이전트가 기업의 새로운 디지털 인력으로 자리잡으면서, IT 부서의 통제 밖에서 운영되는 'Shadow AI'가 기업 보안의 새로운 사각지대로 부상하고 있습니다. 글로벌 아이덴티티 보안 기업 Okta는 이 문제에 대응하기 위해 ISPM(Identity Security Posture Management) 내 Agent Discovery 기능을 발표했습니다. 이번 블로그에서는 Shadow AI가 왜 기존 Shadow IT보다 위험한지, 그리고 아이덴티티 중심의 보안 전략이 해법인지 살펴보도록 하겠습니다. 🔵Shadow IT에서 Shadow AI로 무엇이 달라졌는가Shadow IT는 새로운 문제가 아닙니다. 직원들이 IT 부서 승인 없이 SaaS 도구를 도입하는 현상은 오래전부터 있었습니다. 그러나 AI 에이전트는 기존 Shadow IT와 근본적으로 다른 세 가지 특성을 가집니다.첫째, 작동 레이어가 다릅니다. 기존 Shadow IT가 주로 개별 앱 수준의 문제였다면, AI 에이전트는 애플리케이션 레이어에서 작동하면서 다수의 비인간 아이덴티티(NHI)를 통해 광범위하고 장기적인 권한을 행사합니다.둘째, 생성과 확산 속도가 다릅니다. 에이전트 빌더 플랫폼의 확산으로 이제 모든 직원이 디지털 워커를 직접 프로비저닝할 수 있게 되었습니다. 직원이 검증되지 않은 도구에 OAuth 권한을 부여하면, 그 순간 보안 경계 밖으로 데이터가 흘러나갈 수 있습니다.셋째, 피해 범위(blast radius)가 다릅니다. 비인가 에이전트가 핵심 시스템에 연결되면, 단일 에이전트의 침해가 연쇄적으로 다수의 앱과 데이터에 영향을 미칠 수 있습니다. Equals Money의 James Simcox(COO/CPO)는 "AI 에이전트 제품이 여러 서비스에 연결된 채로 누구도 모르게 들어온다면, 그것은 실질적인 문제"라고 지적합니다.Gartner의 2025년 조사에 따르면, 69%의 조직이 직원들의 비인가 GenAI 도구 사용을 의심하거나 그 증거를 확보하고 있으며, 2030년까지 40% 이상의 기업이 비인가 Shadow AI로 인한 보안 또는 컴플라이언스 사고를 경험할 것으로 예측했습니다. Okta의 'Okta for AI Agents' 솔루션 페이지 데이터에 따르면, 현재 91%의 조직이 이미 AI 에이전트를 사용하고 있지만, 44%는 거버넌스가 전혀 없는 상태입니다.🔵차단이 아닌 가시성, 기존 접근법이 통하지 않는 이유Shadow AI에 대한 가장 직관적인 대응은 차단입니다. 그러나 현업에서는 차단이 오히려 문제를 악화시킨다는 공감대가 형성되고 있습니다. Paysafe의 Amar Akshat(SVP Technology & Chief Architect)는 "차단하면 가시성만 차단하는 것이다. AI 환경은 너무 빠르게 진화하고 있어 차단은 단지 사용을 보이지 않게 만들 뿐"이라고 지적합니다. KPMG의 2025년 조사에서도 미국 직장인의 거의 절반이 비인가 방식으로 AI 도구를 사용하고 있는 것으로 나타났습니다. 직원들이 공식 도구보다 비인가 도구를 선택하는 이유는 속도와 편의성 때문이며, 단순 차단은 이 근본 원인을 해결하지 못합니다. Equals Money의 Simcox가 "직원들이 스스로 하기 전에, 우리가 먼저 ChatGPT를 직원들에게 배포했다"고 밝힌 것도 같은 맥락입니다. 승인된 도구의 접근성을 높이는 것이 Shadow AI 확산을 줄이는 첫 번째 단계입니다.그러나 승인된 도구를 제공하는 것만으로는 충분하지 않습니다. 기존의 네트워크/엔드포인트 기반 보안 접근법은 AI 에이전트에 적용되지 않습니다. AI 에이전트는 네트워크나 디바이스 레이어가 아닌 애플리케이션 레이어에서 작동하기 때문입니다. 따라서 필요한 것은 에이전트가 어디에 존재하고, 누가 만들었으며, 어떤 데이터에 접근하고, 어떤 권한을 보유하는지에 대한 가시성, 즉 아이덴티티 중심의 접근법입니다.여기에 '권한 상속(permission inheritance)' 문제도 가시성 없이는 대응이 불가능합니다. Okta의 'AI at Work 2025' 보고서에 따르면 36%의 조직만이 AI에 대한 중앙화된 거버넌스 모델을 보유하고 있고, NHI 관리 전략을 갖춘 조직은 10%에 불과합니다. 관리자 권한을 가진 직원이 AI 도구에 자신의 전체 권한을 넘겨주는 상황이 발생하더라도, 가시성이 없으면 이를 탐지할 방법이 없습니다.🔵Okta의 해법: Agent Discovery in ISPM이러한 문제에 대한 Okta의 해법은 ISPM(Identity Security Posture Management) 내 Agent Discovery 기능입니다. 2026년 2월 12일 발표된 이 기능은 'Okta for AI Agents' 솔루션의 핵심 구성요소로, Shadow AI를 탐지하고 거버넌스 체계 안으로 편입시키는 것을 목적으로 합니다.Agent Discovery가 해결하는 세 가지 문제는 다음과 같습니다.· 탐지: 조직 내에서 운영 중인 Shadow AI 에이전트를 자동으로 발견· 리스크 파악: 알려지지 않은/알려진 에이전트의 숨겨진 아이덴티티 리스크 및 잘못된 설정(misconfiguration)을 식별· 영향 범위 매핑: 에이전트가 침해될 경우 어디까지 피해가 확산되는지(blast radius)를 시각화Agent Discovery는 OAuth 동의(consent)를 탐지하는 데서 시작합니다. Google Chrome 등 브라우저와 통합되어, 직원이 AI 도구(Client App)에 기업 데이터(Resource App)에 대한 접근 권한을 부여하는 순간을 실시간으로 포착합니다. 이를 통해 어떤 에이전트가 어떤 데이터 소스에 어떤 수준의 권한(scope)을 가지고 있는지를 매핑하고, 미인가 에이전트가 핵심 데이터에 대한 권한을 획득하면 알림을 발생시킵니다.중요한 것은 탐지 이후의 조치입니다. 발견된 에이전트는 Okta 플랫폼에 관리되는 아이덴티티로 등록하고, 보안 정책을 적용하며, 인간 소유자(human owner)를 지정합니다. Shadow AI를 단순히 발견하는 데 그치지 않고, 발견된 에이전트를 거버넌스가 적용되는 관리 자산으로 전환하는 것이 Agent Discovery의 핵심 가치입니다.🔵AI 에이전트 보안의 4단계 플레이북Okta는 블로그를 통해 AI 자산에 대한 통제권을 확보하기 위한 4단계 플레이북을 제시했습니다. 각 단계는 가시성의 범위를 점진적으로 확대하면서, 최종적으로 통합된 아이덴티티 플랫폼에서 모든 에이전트를 관리하는 구조입니다.Stage 1: 승인된 AI 플랫폼 내 에이전트 파악Microsoft Copilot, Salesforce Agentforce, AWS Bedrock, OpenAI, Google Vertex AI 등 기업이 공식 승인한 AI 플랫폼이라 하더라도, 그 안에서 어떤 에이전트가 어떤 권한으로 작동하고 있는지를 보안팀이 파악하지 못하는 경우가 많습니다. 승인 자체가 가시성을 보장하지는 않습니다. 에이전트 수가 방대하여 수동 감독은 사실상 불가능하며, 에이전트에 설정 편의를 위해 과도한 관리자 권한이 부여되거나, 운영 환경과 개발 환경 간 접근이 무분별하게 연결되는 상황도 탐지하기 어렵습니다. Okta는 이러한 'Crown Jewel' 환경에 대한 자동화된 인벤토리를 제공하여, 각 에이전트의 소유자, 실제 권한, 주요 리스크 위치를 식별합니다.Stage 2: 비승인 플랫폼의 미지 에이전트 탐지대부분의 조직이 소수의 승인된 도구에만 집중하는 사이, 부서 전반에서 비승인 플랫폼, 검증되지 않은 에이전트 빌더, 숨겨진 MCP 서버 등을 통해 공격 표면이 확대됩니다. 핵심 리스크 동인은 OAuth 권한 부여(User Consent)입니다. 직원이 자체 제작하거나 외부에서 가져온 에이전트에 기업 데이터 접근 권한을 부여하면, 그 에이전트는 사용자를 대신해 데이터에 접근하고 작업을 수행할 수 있는 OAuth 토큰을 획득합니다. Okta의 SAM(Secure Access Monitor) 브라우저 플러그인이 ISPM에 실시간 OAuth 신호를 피드하여, 비승인 플랫폼의 에이전트 식별, 과도한 권한(scope) 노출, 법률 및 개인정보 보호 검토를 우회한 Shadow SaaS 탐지를 수행합니다.Stage 3: 비인간 아이덴티티(NHI) 레이어 강화AI 에이전트는 하나의 '봇'이 아니라, API 토큰, 액세스 키, 서비스 프린시펄, OAuth 토큰 등 다수의 비인간 아이덴티티(NHI) 위에서 작동합니다. AI 에이전트를 진정으로 보호하려면, 에이전트 자체뿐 아니라 그 에이전트가 행동할 수 있게 해주는 기술적 키를 강화해야 합니다. 이를 위해서는 AI 에이전트, 그것을 생성한 사람, 에이전트를 구동하는 특정 NHI, 그리고 에이전트가 접근할 수 있는 앱 간의 그래프 연결에 대한 깊은 가시성이 필요합니다. Okta는 SaaS, IdP, 클라우드 인프라, On-Prem AD 전반의 다양한 NHI 유형에 대한 가시성을 단일 뷰에서 제공하며, OWASP Top 10 for NHIs에 매핑된 25개 이상의 우선순위 리스크 탐지를 통해 과도한 권한이나 미갱신 자격증명 같은 고위험 취약점을 사전에 식별합니다.Stage 4: 통합 아이덴티티 플랫폼으로 일원화앞선 세 단계에서 발견된 AI 에이전트와 그 기반 NHI를 동일한 아이덴티티 플랫폼으로 통합하는 것이 최종 단계입니다. Okta는 플랫폼 중립적(platform-neutral)이므로 에이전트의 출처에 관계없이 탐지가 가능하며, 이 통합을 통해 인간과 비인간 전체 인력에 대해 일관된 보안 정책을 적용할 수 있습니다. 인간 직원에게 적용하는 정책을 AI 에이전트에도 동일하게 적용하는 것, 이것이 아이덴티티 기반 AI 보안의 최종 목표입니다.🔵AI 보안의 핵심은 아이덴티티 보안AI 에이전트 보안에서 가장 중요한 전제는, AI 에이전트가 결국 '아이덴티티'라는 점입니다. 에이전트는 사람처럼 인증을 받고, 권한을 부여받고, 데이터에 접근하고, 작업을 수행합니다. 따라서 에이전트 보안의 핵심은 별도의 새로운 보안 체계를 구축하는 것이 아니라, 기존의 아이덴티티 보안 패브릭에 에이전트를 통합하는 것입니다.Okta가 이번 Agent Discovery 발표를 통해 제시하는 접근법을 정리하면 다음과 같습니다.· 보이지 않는 것은 관리할 수 없다: Shadow AI를 탐지하는 가시성 확보가 모든 보안의 출발점· 발견에서 거버넌스로: 탐지된 에이전트를 관리 아이덴티티로 등록하고, 인간 소유자를 지정하고, 보안 정책을 적용하는 전환이 필수· 인간과 비인간의 일원화: AI 에이전트를 별개의 존재가 아닌, 조직 아이덴티티 체계의 일부로 관리하는 통합 접근이 필요· 속도와 안전은 양자택일이 아니다: 아이덴티티 기반 거버넌스를 통해 혁신의 속도를 유지하면서도 보안 확보 가능80%의 조직이 의도하지 않은 에이전트 행동을 경험하고, 23%가 에이전트를 통한 자격증명 노출을 보고하는 현재 상황에서, AI 에이전트를 조직의 정식 아이덴티티로 대우하고 생성부터 폐기까지 전체 라이프사이클을 관리하는 체계 구축은 더 이상 선택이 아닌 필수입니다.Shadow AI는 더 이상 방치할 수 있는 문제가 아닙니다. 보이지 않는 에이전트를 발견하고, 발견된 에이전트를 관리 자산으로 전환하며, 인간과 비인간 아이덴티티를 하나의 체계 안에서 일관되게 관리하는 것이 Okta가 제시하는 아이덴티티 기반 AI 보안의 핵심입니다. Okta에 대한 도입 및 상담 문의는 공식 파트너사인 클라우드네트웍스로 연락 부탁드립니다. ▶ 옥타(Okta) 자세히보기

March 03, 2026

어라이즈 AI(Arize AI) - AI 에이전트, 제대로 작동하는지 어떻게 알 수 있을까?

2026/02/25 by. pr@cloudnetworks.co.kr

어라이즈 AI(Arize AI) - AI 에이전트, 제대로 작동하는지 어떻게 알 수 있을까?

February 25, 2026

TLS/SSL 인증서 ‘47일’ 시대: 변경 일정과 자동화 대응 Q&A 총정리

2026/02/19 by. pr@cloudnetworks.co.kr

TLS/SSL 인증서 ‘47일’ 시대: 변경 일정과 자동화 대응 Q&A 총정리

2026년 3월부터 공개 TLS 인증서의 최대 유효기간이 단계적으로 단축되면서, 인증서 갱신은 더 이상 ‘가끔 하는 작업’이 아니라 상시 운영 업무가 됩니다. 이번 글에서는 DigiCert의 '47-Day TLS Certificates FAQ' 문서를 기반으로 유효기간 단축 로드맵(200일→100일→47일), 도메인 검증 재사용 기간(최대 10일) 변화, 그리고 자동화가 왜 필수인지 핵심 질문과 답변 형태로 정리했습니다. 아래 Q&A를 통해 우리 조직이 어떤 준비를 해야 하는지 빠르게 점검해보실 수 있습니다.⏰47-Day TLS Certificates: FAQs Q: 인증서 유효기간에 대한 새로운 규칙은 무엇인가요? CA/B 포럼의 새로운 TLS 규칙에는 2026년 3월부터 적용되기 시작하는 3가지 주요 변경 사항이 있습니다:1. 공개 TLS 인증서의 최대 유효기간이 398일에서 47일로 감소합니다.2. 도메인 및 IP 주소 검증 정보가 재사용될 수 있는 최대 기간이 398일에서 10일로 감소합니다.3. SII(Subject Identity Information, 인증서가 발급되는 대상(엔터티)의 식별 정보)의 재사용 가능 최대 기간이 825일에서 398일로 감소합니다.일부 공개 인증서의 자동화에는 특수 도구나 전문성이 필요할 수 있지만, 대부분의 경우 작업은 비교적 단순합니다. 관련 문서도 충분히 제공되어 있고, 서비스는 (DigiCert가 제공하는 것처럼) 무료인 경우도 많습니다. Q: 변경 일정은 어떻게 되나요? 공개 TLS 인증서의 최대 유효기간은 향후 몇 년에 걸쳐 다음과 같이 감소합니다:• 2026년 3월 15일까지: TLS 인증서 최대 유효기간 398일• 2026년 3월 15일부터: TLS 인증서 최대 유효기간 200일• 2027년 3월 15일부터: TLS 인증서 최대 유효기간 100일• 2029년 3월 15일부터: TLS 인증서 최대 유효기간 47일도메인 및 IP 주소 검증 정보의 재사용 가능 최대 기간도 다음과 같이 감소합니다:• 2026년 3월 15일까지: 도메인 검증 정보 재사용 가능 최대 기간 398일• 2026년 3월 15일부터: 도메인 검증 정보 재사용 가능 최대 기간 200일• 2027년 3월 15일부터: 도메인 검증 정보 재사용 가능 최대 기간 100일• 2029년 3월 15일부터: 도메인 검증 정보 재사용 가능 최대 기간 10일Q: 최대 인증서 유효기간(47일까지)과 최대 도메인 검증 재사용 기간(10일까지)의 차이는 무엇인가요? 인증서의 최대 유효기간은 인증서가 유효하다고 간주되는 최대 일수입니다. 인증서를 발급하려면, 인증기관(CA)은 신청자가 인증서에 포함된 도메인명 또는 IP 주소를 통제하고 있음을 검증해야 합니다. 현재 규칙처럼 1년에 한 번 인증서를 갱신하는 경우라면, 갱신 주문 시점에 매년 통제 여부를 다시 검증하게 됩니다. 그런데 갱신 전에 인증서를 교체해야 하는 경우(예: 개인키가 유출된 경우)는 어떻게 될까요? 이때 CA는 가장 최근 갱신 시 수행된 검증을 재사용할 수 있어, 다시 검증할 필요를 줄일 수 있습니다. 이는 도메인 검증 재사용 최대 기간이 아직 만료되지 않았기 때문입니다.기본 요구사항(Baseline Requirements, 즉 CA/B 포럼의 인증서 발급 규칙)은 오래전부터 이 두 가지 시간 제한을 모두 규정해 왔지만, 일반적으로 두 값을 같은 일수로 설정해 왔습니다. 새 규칙의 최종 단계에서 “최대 인증서 유효기간은 (궁극적으로) 47일”이지만 “도메인 검증은 10일까지만 재사용 가능”하도록 바뀌는 이유는, 검증 정보가 빠르게 최신성을 잃는다고 보고 더 자주 검증이 수행되도록 하기 위함입니다. 이 변경은 또한 CA/B 포럼이 도메인 검증은 반드시 자동화되어야 한다고 믿고 있음을 분명히 보여줍니다. 이렇게 짧은 일정에서는 수동 검증이 큰 부담이 됩니다. 자동화가 되면, 짧은 일정은 전혀 문제가 되지 않습니다.Q: 선택지는 무엇인가요? 합리적인 선택지는 하나뿐입니다. 인증서 수명주기 관리(CLM, Certificate Lifecycle Management)를 자동화하는 것입니다. CA/B 포럼과 업계(DigiCert 포함)는 인증서 유효기간이 단축될 것이며 수동 인증서 관리는 더 이상 현실적인 해법이 될 수 없다고 수년 전부터 고객에게 권고해 왔습니다.도메인 검증(DV) 인증서의 대부분의 사용 사례는 ACME(Automated Certificate Management Environment)와 ARI(ACME Renewal Information) 표준을 활용해 비교적 쉽게 자동화할 수 있습니다. 이 기능은 DigiCert CertCentral에 추가 비용 없이 포함되어 있습니다. 더 복잡한 사례의 경우, DigiCert의 Trust Lifecycle Manager(TLM)가 다양한 엔터프라이즈 구성에 대해 매니지드 자동화 지원을 제공합니다.일부 애플리케이션에는 내부 PKI(프라이빗 PKI라고도 함)도 또 다른 선택지가 될 수 있습니다. 많은 공개 신뢰 인증서는 공개 접근이 필요 없는 리소스를 보호하는 데 사용되며, 모범 사례에 따르면 이런 리소스는 인터넷에서 접근되지 않아야 합니다. 관리자가 이런 리소스에 공개 인증서를 쓰는 경우가 있는 이유는 가장 쉬운 방법이기 때문이지만, 올바른 접근은 내부 PKI를 사용하는 것입니다.내부 PKI는 기업 내부의 프라이빗 리소스 간 통신을 위해, 기업 내부에서만 “유효”하거나 신뢰되는 인증서를 발급합니다. 따라서 인증서 유효기간과 다른 많은 파라미터에 대해 자체 규칙을 설정할 수 있습니다. 내부 PKI에 필요한 모든 소프트웨어를 직접 운영할 수도 있지만, 이는 복잡하고 오류 가능성이 큰 작업입니다. DigiCert는 엔터프라이즈, 클라우드, 제조(Manufacturing) 사용 사례를 위한 여러 내부 PKI 솔루션을 제공합니다.도메인 검증에 대한 동일한 일정은 OV 및 EV 인증서에도 적용됩니다. 결국 OV/EV 인증서도 DV 인증서와 같은 일정(즉, 200/100/10일마다)으로 도메인 검증을 수행해야 합니다. 다만 그 인증서에 포함되는 다른 정보(예: 조직명과 주소)는 398일마다만 갱신하면 됩니다. 도메인 검증은 DV 인증서와 마찬가지로 자동화할 수 있고 자동화해야 하지만, 다른 정보는 완전 자동화가 불가능합니다.Q: 변경이 적용되는 날짜부터 브라우저는 200/100/47일을 초과하는 유효기간의 인증서를 더 이상 받아들이지 않나요? 정확히는 그렇지 않습니다. 제한은 브라우저가 받아들일 수 있는 인증서 종류가 아니라, CA가 발급할 수 있는 인증서 종류에 적용됩니다. 브라우저는 “현재 날짜가 인증서의 유효기간 범위 내에 있는지”를 확인합니다.규칙 변경이 적용되면, CA는 200/100/47일을 초과하는 유효기간의 TLS 인증서를 더 이상 발급할 수 없습니다. 하지만 규칙 변경 이전에 발급된 398일 유효기간 인증서는 만료될 때까지 계속 유효합니다. 200일 인증서가 100일로 바뀔 때도, 100일 인증서가 47일로 바뀔 때도 동일하게 적용됩니다. Q: CA/B 포럼은 무엇인가요?CA/Browser Forum(약칭 CA/B Forum 또는 CABF)은 DigiCert 같은 인증기관(표준에서는 certificate issuers, 인증서 발급자)과 인증서를 사용해 리소스를 인증하는 애플리케이션(대개 웹 브라우저로, 표준에서는 certificate consumers, 인증서 소비자)으로 구성된 업계 표준 기구입니다. 그 밖의 이해관계자도 회원으로 참여하지만, 투표권은 자격을 갖춘 인증서 발급자와 소비자에게만 제한됩니다.TLS 인증서를 위한 최초의 TLS Baseline Requirements(BR)는 2012년에 발효되었습니다. 이 외에도 공개 코드 서명(public code signing) 및 S/MIME 인증서에 대한 표준을 다루는 작업 그룹이 있습니다.Q: 이러한 표준 변경은 내부(프라이빗) PKI에도 영향을 미치나요? 아니요. Baseline Requirements는 공개 인증기관에만 구속력을 갖습니다.내부 PKI는 네트워크 또는 클라우드 내부에서 운영됩니다. 내부 PKI에도 인증기관이 포함되지만, 인증서 만료일을 포함해 내부 인증기관이 강제하는 정책은 사용자가 설정합니다. 내부 PKI에서도 짧은 만료일을 선택하는 것이 최선일 수는 있지만, 필수는 아닙니다. 내부 PKI의 모든 소프트웨어를 직접 운영할 수도 있지만, 이는 복잡하고 오류 가능성이 큰 작업입니다. DigiCert는 엔터프라이즈, 클라우드, 제조 사용 사례를 위한 여러 내부 PKI 솔루션을 제공합니다.Q: 인증서를 더 자주 교체해야 한다면 비용을 더 내야 하나요? 아니요. 최소한 DigiCert CertCentral에서는 그렇지 않습니다. 인증서는 연간 구독 형태로 결제합니다. 구독 기간 동안에는 필요한 만큼 자주 갱신하거나 교체해도 비용이 들지 않으며, 구독에는 ACME/ARI 자동화도 추가 비용 없이 포함됩니다. 이런 변화가 올 것을 예상했기 때문에 구독 모델로 전환한 것도 그 이유 중 하나입니다.고객이 인증서 갱신을 자동화하면, 쉬워지고 굳이 하지 않을 이유가 없기 때문에 자발적으로 더 빠른 교체 주기로 옮기는 경우가 많습니다. 예를 들어 30일마다 바로 갱신하도록 전환하면, 2029년 변화에도 대비가 되어 있다는 확신을 가질 수 있습니다.Q: 새 규칙은 중간 인증서와 루트 인증서에도 영향을 미치나요? 아니요. 이 규칙은 중간 CA가 발급하는 리프(leaf) 인증서에만 영향을 미칩니다.CA/B 포럼이나 다른 표준 기구에는 루트 및 중간 인증서의 유효기간을 제한하는 규칙이 없지만, 일반적으로 합의된 모범 사례가 존재하며, 인증서를 소비하는 소프트웨어 벤더는 신뢰 루트 프로그램에 대해 자체 규칙을 두고 있고 그 내용은 크게 다를 수 있습니다.Mozilla Root Store Policy는(7.4절) 키가 생성된 후 15년이 지나면 Mozilla가 루트 인증서를 신뢰 해제할 것이라고 말합니다. Chrome Root Program Policy 버전 1.6(2025년 2월 15일)의 유효기간 규칙은 더 복잡합니다. 명시적인 유효기간 상한은 없지만, “해당 키 자료가 15년보다 오래전에 생성된 루트 CA 인증서는 Chrome Root Store에서 지속적으로 제거될 것”이라고 되어 있습니다. 2014년 4월 16일 이전에 생성된 키를 포함하는 루트는 Root Program Policy에 정의된 고정 연간 일정에 따라 삭제됩니다. Microsoft Trusted Root Program은 “새로 발급된(Newly minted) 루트 CA는 제출일로부터 최소 8년, 최대 25년의 유효기간을 가져야 한다”고 말합니다. Microsoft와 다른 정책 간 규칙 차이는 Microsoft가 PKI에서 지원하는 애플리케이션의 범위가 다른 브라우저보다 훨씬 넓다는 점에서 비롯됩니다.상식적인 모범 사례 중 하나는, 루트 CA 인증서가 그 아래로 체인되는 어떤 중간 CA 인증서보다 먼저 만료되지 않도록 하는 것입니다.루트 및 중간 CA 인증서 수명주기를 잘못 관리하면 심각한 결과를 초래할 수 있습니다. 최근에도 ‘잊혀진 것으로 보이는’ Google 중간 CA 인증서가 만료되면서 많은 Google Chromecast 기기가 서비스를 이용하지 못한 사례가 있었습니다. Q: 인증서 수명주기 관리는 어떻게 자동화하나요? 웹 서버와 공개 TLS 인증서처럼 일반적이고 비교적 단순한 사례의 경우, CertCentral 고객은 널리 지원되는 ACME(Automated Certificate Management Environment)와 ARI(ACME Renewal Information) 표준을 이용해 무료로 자동화할 수 있습니다.물론 모든 인증서가 공개 TLS인 것은 아니며, 모든 기술이 ACME를 지원하는 것도 아닙니다. 그런 경우 DigiCert의 Trust Lifecycle Manager가 고급 자동화 기능과 통합을 제공합니다.ACME 자동화는 단순히 체크박스 하나를 켜는 수준을 넘어섭니다. 인증서를 요청하는 장비 또는 애플리케이션(대개 웹 서버)에서 변경해야 할 사항이 있습니다. 하지만 대부분의 관리자는 절차가 복잡하지 않고 문서도 잘 갖춰져 있음을 확인할 수 있습니다.Q: ACME와 ARI는 무엇인가요? ACME는 Automated Certificate Management Environment이고, ARI는 ACME Renewal Information입니다.ACME는 모든 주요 인증기관이 지원하는 표준으로, 인증서 클라이언트 소프트웨어(대개 웹 서버)가 CA에 인증서를 요청하고 클라이언트에 설치하는 방식입니다. (이 시나리오에서 클라이언트는 웹 서버입니다.) 클라이언트 소프트웨어도 ACME를 지원해야 합니다. 지원은 널리 퍼져 있지만 보편적이지는 않습니다. ACME 클라이언트 프로그램은 보통 Linux cron이나 Windows Scheduled Tasks를 이용해 일정에 따라 클라이언트 시스템에서 실행되지만, 더 큰 제품 안에 스케줄을 통합한 다른 솔루션도 있습니다.ARI는 관련 표준으로, 서버가 스케줄을 제안해 클라이언트가 인증서 만료 전에 갱신해야 함을 알 수 있도록 합니다. 올바르게 구성하면 ARI는 인증서가 폐기(revoked)된 경우에도 클라이언트에게 갱신을 지시해 장애를 예방할 수 있습니다. Q: 이 변화는 조직 검증(OV) 및 확장 검증(EV) 인증서에 어떤 영향을 미치나요? TLS 인증서에 대한 새 규칙에 따라, 2026년 3월 15일부터 SII(Subject Identity Information) 검증은 825일에서 398일로, 398일 동안만 재사용할 수 있습니다. 즉, OV 및 EV 인증서에 대한 주요 영향은 “인증서에 포함되어 조직을 식별하는 정보”인 SII를 2년에 한 번이 아니라 매년 다시 검증해야 한다는 점입니다.TLS Baseline Requirements에 따르면, 이를 위해 DigiCert 담당자와의 연례 전화 통화가 필요하므로 완전 자동화는 불가능합니다.OV 및 EV 인증서도 도메인명을 보호하므로, OV 및 EV 인증서의 유효기간도 DV 인증서와 동일한 일정으로 변경됩니다. 2026년에는 200일, 2027년에는 100일, 2029년에는 47일로 줄어듭니다. 이러한 인증서의 관리 자동화 필요성은 DV 인증서 못지않게 큽니다.Q: 왜 47일인가요? 47일은 임의의 숫자처럼 보일 수 있지만, 단순한 연쇄(cascade) 결과입니다:• 200일 = 최대 6개월(184일) + 30일 월의 1/2(15일) + 1일 여유(wiggle room)• 100일 = 최대 3개월(92일) + 30일 월의 약 1/4(7일) + 1일 여유(wiggle room)• 47일 = 최대 1개월(31일) + 30일 월의 1/2(15일) + 1일 여유(wiggle room)이처럼 “여유를 더해 홀수 기간을 설정하는” 모델은 CA/B 포럼에서 오랫동안 표준 운영 방식이었습니다. 현재의 398일 제한은 최대 1년(366일) + 최대 1개월(31일) + 1일 여유(wiggle room)로 선택되었습니다.Q: 이러한 변화는 양자 컴퓨팅으로 인한 암호 위협과 어떤 관련이 있나요? 직접적인 관련은 없습니다. 하지만 조직이 자동화된 인증서 관리 솔루션을 도입하도록 강제함으로써, 양자내성암호(PQC, Post-Quantum Cryptography)에 대한 준비 태세를 개선하는 효과를 가져올 것으로 예상합니다.앞으로 PQC로의 전환에는 인프라(예: 인증기관)의 암호 시스템, 고객 환경(웹 서버 및 디지털 인증서를 사용하는 기타 애플리케이션), 그리고 소프트웨어 자체(웹 브라우저, 네트워크 장비 등)에 걸쳐 많은 변화가 수반될 것입니다. 이러한 변화를 최신 상태로 따라가려면, 조직은 운영 중단 없이 빠르게 소프트웨어 변경을 수행할 수 있어야 합니다. 자동화된 인증서 수명주기 관리는 그중 중요한 일부를 가능하게 합니다.인증서는 PQC의 한 부분일 뿐이지만(다만 중요한 부분입니다), 여러분이 사용하는 다른 많은 소프트웨어·하드웨어 제품도 다양한 벤더에 의해 PQC를 지원하도록 업데이트되어야 합니다. 주목할 점은, 이러한 변화가 전면적으로 적용되는 2029년이 Gartner가 “조직이 양자 대비(quantum ready)를 갖춰야 한다”고 말하는 시점이기도 하다는 것입니다. Q: 브라우저가 아닌 클라이언트(네트워크 장비 등)는 어떤 영향을 받나요? 공개 TLS 인증서 시장은 대체로 웹 서버에 설치되는 브라우저 대상 인증서를 압도적으로 지원하지만, 그 외의 경우도 있습니다. VPN 게이트웨이와 일부 IoT 기기가 좋은 예입니다.이러한 장비들도 CLM(인증서 수명주기 관리) 주기를 더 촘촘하게 가져가야 합니다. 많은 장비가 ACME 또는 다른 자동화 프로토콜을 직접 지원하므로, 파라미터를 변경하는 것이 큰 작업이 아닐 수 있습니다. 반면 다른 경우에는 대체 자동화 메커니즘을 지원하거나 아예 지원이 없을 수도 있는데, 이때는 사용자가 자동화를 위해 프로그래밍을 해야 합니다.이 장비들에서 새로운 일정을 수용하는 것이 흔한 문제로 등장할 것입니다. 영향을 받는 자산의 전체 인벤토리를 완전하게 만드는 것이 중요하며, DigiCert는 이 과정을 지원할 수 있습니다.Q: 2026년 마감 이전에 인증서를 갱신하면 398일을 그대로 받을 수 있나요? 네, 2026년 3월 15일 이전에 갱신하여 다시 398일을 받는 것은 규칙상 가능합니다. 다만 이는 1회성 연장입니다. 다음에 인증서를 갱신할 때에는 최대 유효기간이 100일로 줄어들어 있을 것입니다. 대비를 위해 CertCentral 또는 Trust Lifecycle Manager를 사용한 자동화를 미리 구축해 두시기 바랍니다.2026년 3월 15일 당일 또는 그 이후에 인증서를 재발급(리키, rekey)해야 한다면, DigiCert(또는 어떤 공개 CA든)는 그 시점에 적용되는 규칙을 따라야 하며, 그 경우 최대 200일짜리 인증서가 될 수밖에 없습니다. 인증서 관리를 자동화하기 가장 좋은 시점은 가능한 한 빠를 때입니다. 만료 또는 기타 원인으로 인한 장애 위험 없이 준비할 수 있도록, 최대한 빨리 자동화 체계를 마련하시기 바랍니다.인증서 자동화는 “언젠가”가 아니라 “지금” 준비할수록 안전합니다. DigiCert Trust Lifecycle Manager(TLM)로 인증서 수명주기 관리를 체계화하고, 단축 일정(200→100→47일)에도 흔들림 없이 대응하세요.▶ 디지서트(DigiCert) TLM 자세히보기▶ FAQs: 47-Day TLS Certificates 원문보기

February 19, 2026

2026/02/11 by. pr@cloudnetworks.co.kr

랜섬웨어는 왜 반복되는가? 보안 자동화로 차단하는 4가지 방법

최근 몇 년간 국내외 주요 기업들의 보안 사고가 끊이지 않고 있습니다. 2022년 UBER 해킹 사건, 2025년 초 국내 금융보증 기관의 개인정보 유출 사건 등 대형 보안 사고들을 살펴보면 공통점이 있습니다. 바로 '수동 보안 체계의 한계'입니다.이번 글에서는 실제 보안 사고 사례를 분석하고, 왜 보안 자동화가 필수인지, 그리고 어떤 방식으로 랜섬웨어와 보안 위협을 차단할 수 있는지 살펴보겠습니다.☑️반복되는 보안 사고, 무엇이 문제인가2022년 UBER 해킹: 계정 관리와 자격증명 보호의 실패2022년, 글로벌 모빌리티 기업 UBER가 해킹을 당했습니다. 공격의 시작은 다크웹에서 구매한 퇴사자 계정이었습니다. 공격자는 2FA/MFA 스패밍으로 인증을 우회하고 VPN을 통해 UBER 사내 네트워크에 침투했습니다. 침투 후 공격자는 인프라 스캐닝으로 PowerShell 스크립트를 추적했고, 스크립트 내부에 하드코딩된 자격증명을 발견했습니다. 이를 활용해 PAM(특권 계정 관리 시스템)에 접근했고, 최종적으로 애플리케이션과 인프라 전반에 접근하여 데이터를 탈취했습니다.이 사고는 여러 단계에서 방어가 실패했음을 보여줍니다. 퇴사자 계정 관리, 퇴사자 계정 접근 탐지, 임의 자격증명 사용 탐지, VPN 인프라 접근 제어, 인프라 내부 접근 제어, 스크립트 내 자격증명 보호, 자격증명의 안전한 보호 중 어느 하나라도 제대로 작동했다면 막을 수 있었던 사고입니다.2025년 국내 금융보증 기관: 공격 탐지와 데이터 암호화의 부재2025년 초, 국내 한 금융보증 기관에서 개인정보 유출 사고가 발생했습니다. 공격자는 무차별 대입 공격으로 VPN에 접근했고, 사내 네트워크 침투 후 인프라 스캐닝을 통해 데이터베이스 자격증명을 획득했습니다. 더 심각한 문제는 데이터베이스에 저장된 개인정보가 암호화되지 않았다는 점입니다. 공격자는 개인정보 데이터를 취득하여 탈취했습니다.무차별 대입 공격 탐지, 임의 자격증명 사용 탐지, VPN 접근 제어, 인프라 내부 접근 제어, 데이터베이스 자격증명 보호, 데이터와 스토리지 암호화 중 어느 하나라도 제대로 구현되었다면 막을 수 있었던 사고입니다.☑️수동 보안의 한계보안 요소들의 자동화를 하지 않으면 다양한 손실이 누적 발생합니다. 핵심은 사람이 반복적으로 실수하지 않도록 만드는 구조를 만드는 것입니다.보안적 손실: 사람의 실수로 시작되는 보안 사고자격증명 유출은 보안 사고의 주요 원인입니다. IBM 2023년 데이터 유출 비용 보고서에 따르면 전체 보안 사고 중 19%가 자격증명 탈취에서 시작되며, 이로 인한 평균 손실액은 63억원에 달합니다. 더 심각한 문제는 권한 없는 사용자의 접근입니다. Forrester Research에 따르면 이러한 접근이 전체 보안 사고의 80% 이상에 관여합니다. Bastion이나 VPN만으로 접근을 제어할 경우 공유 계정 사용, 장기 키 노출과 같은 취약점이 발생합니다.결국 Verizon Data Breach Investigations Report (DBIR)가 밝혔듯이, 보안 사고의 80% 이상이 사람으로 인해 발생합니다. 아무리 강력한 보안 시스템을 구축해도 사람이 반복적으로 실수한다면 사고는 막을 수 없습니다.경제적 손실: 보이지 않는 비용의 누적보안적 위험 외에도 수동 관리는 상당한 경제적 비용을 발생시킵니다.수작업으로 키를 관리하는 경우를 살펴보겠습니다. 1개의 자격증명을 갱신하는 데 평균 26시간이 소요됩니다. 연간 500개의 자격증명을 관리한다면 1,0003,000시간이 소요되며, 이를 인건비로 환산하면 1.5억~4억원의 손실이 발생합니다. 이 시간과 비용을 보안 전략 수립이나 신규 위협 분석 같은 더 가치 있는 업무에 투입할 수 있습니다.Bastion Host 운영도 만만치 않은 비용을 요구합니다. 별도 관리 서버를 구성하면 인프라 비용으로 월 $50~$200가 소요되고, 여기에 관리 및 보안 점검 인력 투입 비용까지 합하면 연간 1~2천만원 이상이 추가로 발생합니다. 게다가 Bastion Host는 일반적으로 개별 리소스에만 연결되지 않기 때문에, 한 번 뚫리면 내부 자산 전체가 노출될 위험이 높습니다.☑️보안 자동화가 답이다: 4가지 핵심 원칙랜섬웨어를 막기 위해서는 보안 자동화가 필수입니다. 보안 자동화의 핵심은 네 가지 원칙으로 요약됩니다.원칙 1: 모든 침해는 항상 계정에서 시작된다UBER와 국내 금융보증 기관 사례에서 확인했듯이, 모든 보안 사고는 계정 침해에서 시작됩니다. 따라서 자격증명 관리가 보안의 출발점입니다.원칙 2: 누가, 언제, 무엇에 접근하는가를 통제하지 않으면 사고는 반복된다네트워크에 침투한 공격자가 내부 시스템을 자유롭게 이동할 수 있다면, 피해는 급속도로 확산됩니다. 접근 제어는 침해 확산을 막는 핵심입니다.원칙 3: 하드코딩된 시크릿은 침해를 예약한 것과 같다UBER 사례에서 본 것처럼, 스크립트에 하드코딩된 자격증명은 공격자에게 열쇠를 쥐어주는 것과 같습니다. 시크릿은 반드시 안전하게 보호되고 동적으로 관리되어야 합니다.원칙 4: 보안 사고는 '발생 여부'가 아니라 '인지 시점'이 문제다보안 사고를 완전히 막을 수는 없습니다. 중요한 것은 얼마나 빨리 탐지하고 대응하느냐입니다. 지속적인 탐지와 모니터링이 필요한 이유입니다.☑️보안 자동화 프레임워크: 4단계 방어 체계클라우드네트웍스는 침투 차단, 확산 제한, 자격 무력화, 조기 탐지라는 4단계 방어 체계로 랜섬웨어와 보안 위협을 차단합니다.1단계: 침투 차단 - 자격증명 관리 (Okta)첫 번째 방어선은 침투 자체를 차단하는 것입니다. Okta는 비밀번호 탈취를 무력화하고 이상 접근을 실시간으로 차단합니다.· 비밀번호 탈취 무력화 Okta는 강력한 MFA(다중 인증)와 Passwordless(비밀번호 없는) 인증을 제공합니다. 다양한 방식의 MFA 기능을 지원하며, 공격자의 행동을 감지하는 MFA를 통해 이상 접근을 차단합니다.· 이상 접근 실시간 차단 권한 최소화와 세션 통제를 통해 이상 접근을 차단합니다. Just In Time 방식으로 필요한 순간에만 권한을 부여하고, 세션 시간을 제한하며, 모든 명령어를 감사로그로 기록합니다.▶ 옥타(Okta) 자세히보기2단계: 확산 제한 - 접근제어 (QueryPie)공격자가 네트워크에 침투했다 하더라도, 내부 이동을 막으면 피해를 최소화할 수 있습니다. QueryPie는 불필요한 접근을 차단하고 최소 권한 기반으로 접근을 통제합니다.· 다양한 인프라에 대한 접근 관리 불필요한 접근을 차단하고 마이크로세그먼트를 실현합니다. 클라우드, 데이터베이스, Kubernetes, 웹 애플리케이션 등 다양한 인프라에 대한 접근을 관리합니다.· 최소 권한 기반 접근 특정 데이터베이스, 특정 서버만 최소 권한(RBAC, ABAC)으로 접근할 수 있도록 제어합니다.· 감사로깅 모든 접근 이력을 추적 관리합니다.▶ 쿼리파이(QueryPie) 자세히보기3단계: 자격 무력화 - 시크릿 관리 (HashiCorp Vault)세 번째 방어선은 자격증명이 탈취되더라도 재사용할 수 없게 만드는 것입니다. HashiCorp Vault는 ZeroTrust 아키텍처를 통해 데이터베이스와 서버 자격증명을 보호합니다.· DB/서버 자격증명 보호를 통한 ZeroTrust 아키텍처 구성 동적 자격증명을 짧은 TTL(Time To Live)로 발급하여 탈취되더라도 재사용이 불가능하도록 합니다. 자격증명 로테이션과 폐기를 자동화합니다.· 데이터 암호화 개인정보를 암호화하여 보호하고, 암호화키와 암호화 주체를 분리합니다.· 감사로깅 모든 자격증명 발급을 추적합니다.▶ 하시코프 볼트(HashiCorp Vault) 자세히보기4단계: 조기 탐지 - 지속 탐지 (Splunk)마지막 방어선은 위협을 조기에 탐지하고 즉각 대응하는 것입니다. Splunk는 무차별 대입 공격과 비정상 로그인 시도를 실시간으로 탐지하고 자동으로 대응합니다.· 실시간 위협 탐지 무차별 대입 공격(Brute Force), 비정상 VPN 로그인 시도를 실시간으로 탐지합니다. 내부망에서의 과도한 스캐닝, 비정상 데이터베이스 접근 로그를 이상 징후로 경고합니다.· 즉각 대응 침해 징후 발생 시 관리자에게 즉각적인 알림을 전송하고, 사전에 정의된 대응 플로우(Playbook)를 자동으로 실행합니다.▶ 스플렁크(Splunk) 자세히보기☑️마치며: 자동화로 완성하는 보안UBER와 국내 금융보증 기관 사례가 보여주듯, 수동 보안 체계는 이미 한계에 도달했습니다. 사람의 실수는 반복되고, 보이지 않는 비용은 누적되며, 보안 사고는 계속됩니다. 보안 자동화는 선택이 아닌 필수입니다. 자격증명으로 시작하여 모든 접근을 통제하고, 시크릿을 보호하며, 모든 것을 지속적으로 탐지하는 것. 이것이 랜섬웨어와 보안 위협으로부터 기업을 효과적으로 보호하는 방법입니다.클라우드네트웍스는 Okta, QueryPie, HashiCorp Vault, Splunk를 통해 기업 환경에 최적화된 보안 자동화 프레임워크를 구축합니다. 보안 사고가 발생하기 전에, 지금 바로 보안 자동화를 시작하세요. Okta, QueryPie, HashiCorp Vault, Splunk 솔루션에 대한 문의사항은 클라우드네트웍스로 연락 부탁드립니다.

February 11, 2026

한 번 로그인으로 안전하게! 옥타(Okta) '디바이스 기반 SSO' 솔루션

2026/02/04 by. pr@cloudnetworks.co.kr

한 번 로그인으로 안전하게! 옥타(Okta) '디바이스 기반 SSO' 솔루션

직원들이 어디서든 필요한 앱과 도구에 안전하고 원활하게 접근할 수 있어야 합니다. 하지만 기존의 SSO(Single Sign-On)와 MFA(Multi-Factor Authentication)만으로는 충분하지 않습니다. 사용자들은 반복되는 인증 프롬프트에 불편을 느끼고, 이러한 표준 방어 수단도 정교한 ID 기반 공격을 막기에는 역부족일 수 있습니다.최근 Okta 공식 블로그에서 이러한 SSO 보안 취약점에 대응하는 새로운 솔루션을 소개했습니다. Okta가 새롭게 선보이는 'Device-Bound SSO'는 세션 재생 공격을 방어하면서도 로그인 절차를 간소화하는 솔루션입니다. 디바이스 로그인 시점부터 하드웨어로 보호되는 SSO 세션을 시작하여, 보안과 생산성을 동시에 확보할 수 있습니다.🔷Work safer and faster with 'Device-Bound Single Sign-On'직원들은 어디에 있든, 언제든 업무에 필요한 앱과 도구에 안전하고 원활하게 접근할 수 있기를 기대합니다. 하지만 한 가지 분명한 사실은 기존의 SSO(Single Sign-On)와 MFA(Multi-Factor Authentication)만으로는 충분하지 않다는 것입니다. 사용자들은 반복되는 인증 프롬프트에 불만을 느낄 뿐만 아니라, 이러한 표준 방어 수단도 더욱 정교한 ID 기반 공격을 막는 데는 실패할 수 있습니다.SSO의 광범위한 도입이 인력 생산성과 사용자 경험을 크게 향상시킨 것은 사실이지만, 동시에 MFA를 우회하는 데 악용될 수 있는 단일 고가치 자산, 즉 지속적인 세션 토큰이나 쿠키를 만들어냈습니다. 2025 SpyCloud Identity Exposure Report에 따르면, 2024년에 약 173억 개의 세션 쿠키가 악성코드에 감염된 디바이스에서 탈취되었습니다. 조직은 어떻게 세션 재생 공격을 방어하면서 직원들의 로그인 불편을 줄일 수 있을까요?Okta는 ID 보안이 생산성이나 민첩성을 해치지 않으면서 모든 로그인 접점을 보호할 수 있도록 IT 및 보안 팀에 권한을 부여해야 한다고 믿습니다. 이것이 Okta가 주요 플랫폼과의 가장 깊은 디바이스 통합을 제공하고 디바이스 액세스에 의미 있는 투자를 해온 이유입니다.이제 Okta는 Okta Device Access의 차세대 진화를 발표하게 되어 기쁩니다. 디바이스를 활용하여 애플리케이션 보호 방식을 재정의하는 새로운 방법을 소개합니다. Device-Bound SSO는 세션 재생 보호와 간소화된 로그인 경험을 제공하여 사용자가 안전하게 필요한 곳으로 이동할 수 있도록 돕습니다.하드웨어로 보호되는 SSO로 안전한 시작Okta Device Access의 새로운 기능인 Device-Bound SSO는 디바이스 로그인 후 다운스트림 앱에 원활하게 액세스할 수 있도록 하드웨어로 보호되는 SSO 세션을 시작합니다. 기존 SSO와 달리 이 기능은 인증 프롬프트를 줄이면서 Okta SSO 세션 재생 위험을 최소화합니다. 신뢰할 수 있는 사용자 및 디바이스 ID와 애플리케이션 액세스를 연결하는 심층 방어 보안을 확보할 수 있습니다.Device-Bound SSO를 사용하면 디바이스 로그인 시 처음 인증받을 때 SSO가 시작되며, 보안이 가장 초기 액세스 지점으로 이동하여 디바이스 자체에서 신뢰가 시작되도록 보장합니다. 즉, Okta Device Access로 성공적으로 완료된 디바이스 로그인을 활용하여 동일한 수준의 보안 보증이 필요한 다운스트림 리소스에 액세스할 수 있습니다. 이는 인증 요청 빈도를 줄여 위협 행위자의 진입점을 감소시킬 뿐만 아니라, 하드웨어로 보호되고 암호화 방식으로 안전한 세션을 시작하여 ID 기반 공격을 훨씬 어렵게 만듭니다. 액세스가 사용자뿐만 아니라 그들의 디바이스에도 연결되기 때문에, 위협 행위자가 활성 Okta SSO 세션을 탈취하더라도 다른 디바이스에서 이를 활용할 수 없습니다.Okta Device Access는 Windows 및 macOS 컴퓨터의 디바이스 로그인 시점에 Okta의 간편하고 안전한 인증 경험을 제공합니다. 이제 Device-Bound SSO를 통해 사용자는 Okta에 연결된 디바이스에 로그인하기만 하면 업무 리소스에 안전하게 액세스할 수 있어, 더 안전하고 빠르게 업무를 시작할 수 있습니다.Okta에 연결되도록 기기를 구성하세요.Device-Bound SSO는 모든 Okta 연결 디바이스에서 사용할 수 있습니다. 디바이스를 Okta에 연결하면 디바이스에서 앱까지 현대적이고 통합된 인증 경험을 활용할 수 있습니다.Okta 연결 디바이스란 단순히 Okta에 직접 등록되어 조직의 신뢰할 수 있는 ID 보안 체계의 일부가 된 디바이스를 말합니다. 디바이스는 더 이상 단순한 하드웨어가 아닙니다. 일급 ID로 인식되고 보호됩니다. 즉, Okta는 디바이스 관리 솔루션 및 도구 생태계와 협력하여 해당 디바이스에서 사용자 및 디바이스 ID에 대한 통합 인증 레이어 및 디렉터리로서 액세스 관리 요구사항을 처리합니다.직원 입장에서는 업무 시작이 더욱 원활해집니다. 디바이스에 한 번 로그인하면 Okta로 보호되는 앱에 원활하게 액세스할 수 있습니다. IT 및 보안 팀 입장에서는 각 로그인이 사용자, 디바이스, 조직 간의 신뢰 핸드셰이크가 되어, 디바이스 자체를 보안 태세에 바인딩하여 분산된 ID의 격차를 해소하는 동시에 데이터를 보호하고 직원들이 계속 업무를 수행할 수 있도록 만듭니다.조직은 이미 Active Directory 또는 Entra ID에 연결된 디바이스를 Okta에 연결하여 하이브리드 Okta 연결 상태로 만들 수 있습니다. 어느 경우든 조직은 다음과 같은 주요 ID 보안 결과를 통해 안전하고 현대적인 경험을 얻습니다.· 디바이스가 Okta Universal Directory에 등록되며, 운영 체제(OS) 프로필을 기본 Okta 사용자에게 연결할 수 있습니다.· 디바이스에서의 인증은 하드웨어로 보호되는 디바이스 세션으로 보호됩니다(즉, Device-Bound SSO를 활성화하려면 디바이스가 Okta에 연결되어 있어야 합니다).· 인증 시 Okta는 사용자가 Okta 연결 디바이스에서 보호된 리소스에 액세스하고 있음을 증명합니다.Okta Device Access가 추가 기능을 계속 도입함에 따라, Okta 연결 디바이스는 첫 로그인부터 시작되는 보호를 활용하여 디바이스를 신뢰할 수 있는 게이트웨이로 전환하는 데 가장 유리한 위치에 있게 될 것입니다.자세히 알아보기Okta Device Access는 Okta 연결 디바이스에서 현대적이고 통합된 인증 경험을 제공하여 사람들이 더 안전하고 빠르게 업무를 시작할 수 있도록 돕습니다. 첫 로그인부터 신뢰를 검증함으로써 디바이스 자체에서 보안이 시작되어 다운스트림 리소스로의 경로를 간소화하면서 보호를 강화합니다. Device-Bound SSO는 현재 셀프 서비스 얼리 액세스로 제공되며, Windows 및 macOS 디바이스 모두 지원됩니다. Device-Bound Single Sign-On과 Okta, Auth0 플랫폼에 대한 도입 상담 및 문의사항은 공식 파트너사인 클라우드네트웍스로 연락 부탁드립니다. ▶ 옥타(Okta) 자세히보기 ▶ Device-Bound Single Sign-On 자세히보기

February 04, 2026

2026/01/29 by. pr@cloudnetworks.co.kr

서버 접근 시 비밀번호 기반 인증방식, 왜 개선이 필요할까?

2025년 상반기, 국내 통신사에서 역대 국내 침해사고 중 최대 규모의 정보 유출 사고가 발생했습니다. 과학기술정보통신부와 한국인터넷진흥원(KISA)의 민관합동조사 결과에 따르면, 서버 계정정보가 암호화되지 않은 채 평문으로 저장되어 있었고, 공격자는 이를 활용해 내부망의 다른 서버들로 침투할 수 있었습니다. 서버 계정 관리 부실과 주요 정보 암호화 미흡, 그리고 전사적으로 작동하지 못한 정보보호 거버넌스 체계가 복합적인 원인으로 지목되었습니다.이처럼 서버 패스워드 관리는 단순한 운영 편의성의 문제가 아닌, 기업의 핵심 정보 자산을 지키는 보안의 첫 관문입니다. 이글루코퍼레이션의 2025년 사이버 보안 위협 보고서에서도 관리 서버 해킹 및 초기 관리자 패스워드 노출 등 접근 통제 취약점을 악용한 공격이 지속적으로 증가하고 있다고 경고했습니다.☑️주기적인 패스워드 변경, 왜 필요하지만 어려울까?패스워드가 유출된 경우 패스워드가 변경되기 전까지 공격자의 행위에 대한 대처가 어렵습니다. 주기적인 패스워드 변경을 통해 이러한 위협을 최소화할 수 있지만, 일반적인 수동 방법으로는 합리적 운영에 한계가 있습니다.주기적인 패스워드 변경이 필요한 이유는 명확합니다. 패스워드 유출 시 즉각적인 확인이 어렵고, 접근 권한이 종료된 계정에 대한 통제가 어려우며, 고정된 패스워드 사용 시 공격에 노출될 확률이 높아집니다. 또한 내부자의 위협에 노출되기 쉽고, 각종 컴플라이언스 준수를 위해서도 필수적입니다. 그러나 수동 변경에는 여러 한계가 있습니다. 서버 수량에 따라 수많은 인력 투입이 필요하며, 동일하거나 유사한 패스워드를 재사용할 가능성이 높습니다. 변경된 패스워드를 공유하기 위해 메신저나 메모를 사용하면 노출 가능성이 향상되고, 패스워드 변경으로 인한 서비스 장애 및 운영 리스크가 증가합니다. 무엇보다 로그와 이력이 부재하여 감사의 신뢰성이 부족하다는 점이 가장 큰 문제입니다.보안뉴스의 2025년 시스템 접근제어·계정관리·패스워드 관리 리포트에 따르면, 수작업 기반의 사용자 계정관리 프로세스는 시간이 오래 걸리고 인력 소모가 커서 결과적으로 기업에 상당한 비용을 발생시킵니다. 또한 복잡한 비밀번호 정책이나 다중인증(MFA) 사용을 불편해하는 사용자가 많아 비밀번호 재사용이나 취약한 비밀번호 설정 등 잘못된 보안 습관이 만들어지는 문제도 발생하고 있습니다.☑️HashiCorp Vault를 활용한 서버 패스워드 관리하시코프 볼트(HashiCorp Vault)는 이러한 문제를 해결할 수 있는 강력한 시크릿 관리 솔루션입니다. HashiCorp Vault는 API keys, passwords, certificates 등 모든 시크릿에 대한 통합 인터페이스를 제공하며, 엄격한 접근 통제와 상세한 감사 로그를 기록합니다.Vault를 활용하면 서버, 클라우드, 데이터베이스에 대한 시크릿 관리를 중앙화하고 암호화하여 안전하게 관리할 수 있습니다. 애플리케이션과 사용자는 API, UI, CLI, SDK를 통해 Vault에 접근하며, Vault는 인증 과정을 거친 후 키, 패스워드, 토큰을 안전하게 관리합니다.HashiCorp Vault는 데이터를 저장 백엔드에 보내기 전에 암호화합니다. 저장 백엔드는 보안 경계 외부에 있기 때문에 신뢰할 수 없는 것으로 간주되므로, 공격자가 저장소에 접근하더라도 Vault가 복호화하기 전까지는 데이터를 읽을 수 없습니다.방안 1: SSH CA - 비밀번호 없는 안전한 인증SSH CA(Certificate Authority)는 패스워드 노출 없이 단기 인증서 발급을 통한 안전한 사용자 인증 방식입니다. SSH CA 방식은 서버 접근 시 비밀번호 대신 단기 유효한 인증서를 발급하여 사용자를 인증합니다. 이는 패스워드리스(passwordless) 방식으로 계정 공유, 장기 비밀번호 노출 등의 보안 리스크를 해소합니다. 패스워드 관리 없이 사용자 단위의 접근 통제와 자동 만료 기반의 안전한 서버 접근이 가능하다는 것이 가장 큰 장점입니다.SSH CA 작동 방식은 다음과 같습니다. 먼저 사용자가 개인 SSH 키 쌍을 생성합니다. 그 다음 Vault에 인증하여 토큰을 받고, SSH 공개키를 Vault에 전송하여 서명을 요청합니다. Vault는 설정된 역할에 따라 SSH 키에 서명하여 인증서를 반환하고, 사용자는 이 서명된 인증서를 사용하여 SSH 연결을 시도합니다. 원격 호스트는 클라이언트 SSH 인증서가 신뢰할 수 있는 SSH CA에 의해 서명되었는지 확인하고 연결을 허용합니다.이 방식의 특징은 모든 인증서 서명 요청에 인증이 필요하다는 점입니다. 이를 통해 기업은 중앙 아이덴티티 프로바이더를 사용하여 서버에 대한 승인된 SSH 접근을 관리할 수 있습니다. 또한 호스트 측에서는 최소한의 변경만 필요하며, SSH CA 공개 인증서만 있으면 되므로 호스트가 Vault에 직접 연결할 필요가 없습니다. SSH CA의 개인 키는 보호되어 Vault 외부로 절대 나가지 않으며, 모든 Vault 인증 시도와 키 서명 요청은 감사 추적에 기록됩니다.방안 2: SSH OTP - 일회성 비밀번호로 노출 위험 최소화SSH OTP(One-Time Password)는 일회성 비밀번호 발급으로 단기 인증을 수행하여 패스워드 노출 위험을 최소화하는 방식입니다. HashiCorp는 Vault가 클라이언트의 SSH 연결 요청 시마다 일회성 비밀번호를 발급합니다. 이 방식은 기존 비밀번호 기반 접근 구조를 유지하면서도, 장기 비밀번호 사용으로 인한 보안 리스크를 줄일 수 있습니다. 별도 키 관리 없이 일회성 비밀번호를 통해 접근 이력을 명확히 추적할 수 있다는 것이 특징입니다.SSH OTP 작동 방식은 다음과 같습니다. 인증된 클라이언트가 Vault 서버에 OTP를 요청하고, 승인된 경우 Vault가 OTP를 발급합니다. 클라이언트가 SSH 인증 중 이 OTP를 사용하면, Vault helper가 OTP를 받아 Vault 서버로 검증을 요청합니다. Vault 서버는 OTP를 검증한 후 삭제하여 단 한 번만 사용되도록 보장합니다.SSH 연결 설정 시 Vault 서버에 접촉하기 때문에 모든 로그인 시도와 관련된 리스 정보가 감사 장치에 기록됩니다. 이를 위해서는 원격 호스트에 vault-ssh-helper를 설치해야 합니다. vault-ssh-helper는 SSH 백엔드의 OTP 타입 역할에 속하는 모든 원격 호스트에 설치되어야 합니다.☑️마치며서버 패스워드 관리는 더 이상 선택이 아닌 필수입니다. SK쉴더스의 2025 보안 위협 전망 보고서와 엑소스피어의 2025년 보안 이슈 분석에 따르면, 2026년에도 서버 접근 통제 취약점을 악용한 공격과 랜섬웨어 공격이 지속적으로 증가할 것으로 예상됩니다.HashiCorp Vault의 SSH CA와 SSH OTP 방식은 각각의 장점을 가지고 있습니다. SSH CA는 완전히 passwordless 환경을 구축할 수 있고, SSH OTP는 기존 인프라를 크게 변경하지 않으면서도 보안을 강화할 수 있습니다. 조직의 상황과 요구사항에 따라 적절한 방식을 선택하거나 두 가지를 조합하여 사용할 수 있습니다. 서버 패스워드 관리의 자동화와 중앙화, 그리고 감사 추적 가능성은 현대적인 보안 아키텍처의 필수 요소입니다. 지금부터라도 조직의 서버 접근 통제 방식을 점검하고 개선할 때입니다.클라우드네트웍스는 HashiCorp 공식 파트너로서 Vault를 포함한 HashiCorp 제품군의 도입부터 구축, 운영까지 전 과정을 지원하고 있습니다. 조직의 현재 인프라 환경과 보안 요구사항을 분석하여 최적의 시크릿 관리 아키텍처를 제안해드립니다. 서버 접근 통제 방식 개선이나 HashiCorp Vault 도입에 대해 궁금하신 점이 있으시다면, 클라우드네트웍스로 연락 부탁드립니다. ▶하시코프 볼트(HashiCorp Vault) 자세히보기

January 29, 2026

시스코 AI 디펜스(Cisco AI Defense) : AI 시대를 위한 엔터프라이즈 보안 솔루션

2026/01/22 by. pr@cloudnetworks.co.kr

시스코 AI 디펜스(Cisco AI Defense) : AI 시대를 위한 엔터프라이즈 보안 솔루션

AI 시대, 새로운 보안 과제에 직면한 기업들기업의 AI 도입이 가속화되면서 보안 담당자들은 새로운 딜레마에 직면하고 있습니다. 서드파티 AI 애플리케이션을 사용하든, 자체 AI를 개발하든, 속도를 위해 안전과 보안을 희생할 수는 없습니다. 하지만 기존의 보안 솔루션만으로는 AI 특유의 위험을 충분히 방어하기 어려운 것이 현실입니다.멀티 클라우드, 멀티 모델 환경에서 기업들이 직면하는 AI 보안 과제는 복잡합니다. 조직 전반에서 사용되는 서드파티 AI 애플리케이션의 가시성을 확보해야 하고, 프롬프트 인젝션, 데이터 유출 등 AI 특화 위협으로부터 보호해야합니다. 분산된 클라우드 환경 전반의 AI 자산과 데이터를 관리하고, 빠르게 진화하는 AI 위협에 실시간으로 대응해야 합니다. Cisco AI Defense는 이러한 과제를 해결하기 위해 설계된 엔터프라이즈급 AI 보안 솔루션입니다.Cisco AI Defense: 엔터프라이즈가 선택한 AI 보안 솔루션Cisco AI Defense는 AI를 구축하고, 사용하고, 혁신하는 기업을 위한 엔드투엔드 보호 솔루션입니다.Gartner의 'Market Guide for AI Trust, Risk and Security Management'는 Cisco AI Defense를 AI TRiSM 시장의 주요 솔루션으로 소개하며 다음과 같이 평가했습니다."Cisco AI Defense는 엔터프라이즈 애플리케이션의 개발 및 배포와 서드파티 AI 앱의 직원 사용을 보호합니다. 이 제품은 Robust Intelligence 인수를 통해 얻은 알고리즘 취약성 테스트 및 런타임 가드레일을 기반으로 하며, Cisco의 네트워크 계층 가시성과 보안 실행을 활용하여 분산 환경 전반의 AI 자산과 워크로드를 보호합니다."Cisco는 2024년 AI 보안 스타트업 Robust Intelligence를 인수하며 AI 보안 역량을 대폭 강화했습니다. 이를 통해 알고리즘 기반의 정교한 취약성 테스트와 런타임 보호 기능을 자사의 네트워크 및 보안 인프라와 통합할 수 있게 되었습니다.Cisco AI Defense: AI 사용과 개발, 두 가지 시나리오 모두 보호· AI 사용 환경 보호 : 조직 전반에서 사용되는 서드파티 AI 애플리케이션을 자동으로 파악합니다. 직원의 액세스를 관리하고, 위협으로부터 보호하며, 민감한 데이터 손실을 방지하는 정책을 정의할 수 있습니다.· AI 개발 환경 보호 : 환경 전반의 AI 자산을 탐지하고, 알고리즘 방식으로 모델을 평가하여 취약점을 식별합니다. 이후 AI 앱과 고객을 실시간으로 보호하는 가드레일을 배포합니다.Cisco AI Defense의 핵심 구성 요소Cisco AI Defense는 포괄적인 AI 보안을 위한 다섯 가지 핵심 구성 요소로 이루어져 있습니다.1. AI Model and Application Validation (AI 모델 및 애플리케이션 검증) : 대규모로 모델 전반의 안전성 및 보안 취약점을 식별합니다. 알고리즘 레드 팀 기술을 통해 불과 몇 초 만에 AI 위험을 평가할 수 있습니다.2. AI Runtime Protection (AI 런타임 보호) : 네트워크에 내장된 가드레일로 프로덕션 AI 애플리케이션을 보호합니다. 적대적 공격과 유해한 응답을 실시간으로 차단합니다.3. AI Cloud Visibility (AI 클라우드 가시성) : 분산 환경 전반의 AI 모델과 연결된 데이터 소스를 자동으로 인벤토리화하여 사용 현황을 파악하고 위험을 측정합니다.4. AI Access (AI 액세스) : 서드파티 AI 애플리케이션에 대한 액세스를 모니터링하고 관리합니다. 민감한 데이터 노출을 제한하고 외부 위협으로부터 보호하는 정책을 실행합니다.5. AI Supply Chain Risk Management (AI 공급망 위험 관리) : AI 모델 및 파일에 대한 거버넌스와 보안을 보장하는 AI 공급망 위험 관리를 제공합니다.Cisco만의 차별화된 AI 보안 접근 방식· 네트워크 계층 데이터 인사이트 : Cisco는 분산 환경 전반에서 실행되는 데이터를 확인할 수 있어, AI 트래픽 및 관련 위험에 대한 완전한 가시성을 제공합니다.· 네트워크 패브릭에 융합된 보안 : Cisco는 에이전트나 라이브러리 없이 네트워크 수준에서 AI 보안을 실행하여, AI 개발과 보안을 분리합니다.· 고급 탐지 기능 : AI Defense 가드레일은 프롬프트 인젝션 및 악성 URL 탐지를 넘어 모델 서비스 거부(DoS), 코드 탐지, 오프 토픽 공격 등 최신 위협으로부터 보호합니다.· 우수한 위협 인텔리전스 : Cisco는 AI 연구소와 Talos의 최신 위협 인텔리전스를 활용하여 탐지 기능을 개선하고, 신규 공격으로부터 보호하기 위한 즉각적인 플랫폼 업데이트를 제공합니다. Splunk 고객은 추가 인사이트를 위해 Splunk 데이터를 활용할 수 있습니다.· AI 보안 표준을 선도하는 Cisco : Cisco는 AI 보안 표준 기구와 초기부터 협력해 왔으며, 현재도 적극적으로 기여하고 있습니다. AI Defense는 단일 통합으로 NIST, MITRE ATLAS, OWASP LLM Top 10을 포함한 표준과의 정렬을 지원합니다.AI TRiSM 프레임워크와 Cisco AI DefenseGartner가 제시한 AI TRiSM(AI Trust, Risk and Security Management) 프레임워크는 기업의 안전한 AI 도입을 위한 4개 계층으로 구성됩니다. Cisco AI Defense는 이 중 가장 중요한 상위 2개 계층을 포괄적으로 지원합니다.AI 거버넌스 계층· AI Cloud Visibility를 통해 조직의 모든 AI 자산을 자동으로 인벤토리화하고 위험을 평가합니다.· AI Model and Application Validation으로 알고리즘 기반의 취약성 테스트를 수행합니다.· 지속적인 보안 테스트와 평가를 통해 AI 시스템의 신뢰성을 보장합니다.AI 런타임 검사 및 실행 계층· 프롬프트 인젝션, 데이터 유출, 모델 DoS 등 AI 특화 위협을 실시간으로 탐지하고 차단합니다.· 민감한 데이터의 노출을 방지하고 액세스 제어를 실행합니다.· 입력 및 출력에 대한 실시간 검사를 통해 정책 위반을 방지합니다.Cisco의 네트워크 계층 가시성과 보안 실행 능력은 에이전트 설치 없이도 분산 환경 전반의 AI 워크로드를 효과적으로 보호합니다. 이는 AI 개발 속도를 저해하지 않으면서도 강력한 보안을 제공하는 Cisco만의 차별화된 접근 방식입니다.안전한 AI 혁신을 위한 파트너, 클라우드네트웍스기업의 AI 도입이 가속화될수록 체계적인 보안 전략은 더욱 중요해집니다. Cisco AI Defense는 AI 사용과 개발 전반에 걸쳐 포괄적인 보호를 제공하며, AI TRiSM 프레임워크를 실현하는 엔터프라이즈급 솔루션입니다. 클라우드네트웍스는 Cisco의 공식 파트너로서 기업의 AI 보안 전략 수립부터 Cisco AI Defense 도입, 운영, 최적화까지 검증된 전문성으로 지원합니다. Cisco AI Defense는 Splunk 데이터와의 연계를 통해 추가적인 인사이트 확보가 가능하며, 클라우드네트웍스는 Cisco와 Splunk 솔루션 모두에 대한 깊이 있는 경험을 보유하고 있습니다.▶ Cisco AI Defense 자세히보기▶ Splunk 자세히보기AI 거버넌스 구축과 AI 보안 강화에 대해 궁금하신 점이 있으시다면, 언제든 클라우드네트웍스로 문의해 주세요.

January 22, 2026