[ET시론] AIDC 보안, GPU보다 먼저 설계해야 한다

인공지능(AI) 경쟁이 거세지면서 AI 데이터센터(AIDC) 구축 논의도 빠르게 확산하고 있다. 그래픽처리장치(GPU) 확보량, 전력 용량, 냉각 효율, 부지와 건설 일정이 사업의 핵심 지표처럼 제시된다. 모두 중요한 요소다. 그러나 AIDC가 국가와 기업의 핵심 데이터를 처리하고 업무 판단과 자동화를 담당하게 된다면, 더 먼저 물어야 할 질문이 있다. '어떤 AI 서비스를 어떤 보장 수준으로 수용하고, 누가 어떤 권한으로 운영하며, 문제가 생겼을 때 어디까지 통제하고 복구할 수 있는가?' 이 질문에 답하지 못한 채 GPU부터 쌓는다면, 우리는 고성능 인프라는 얻을 수 있어도 신뢰할 수 있는 AI 기반은 얻기 어렵다.

AIDC는 GPU 서버가 많은 일반 데이터센터가 아니다. △데이터 수집·정제·학습·추론 △모델 저장과 배포 △검색증강생성(RAG) △프롬프트 △외부 응용프로그램 인터페이스(API) △모델 컨텍스트 프로토콜(MCP), AI 에이전트의 도구 호출이 하나의 실행 사슬로 연결되는 복합 시스템이다. 여기에 전력·냉각 설비, 관리망, 고속 네트워크, 스토리지, 가상화·컨테이너 플랫폼, 클라우드 운영체계가 결합된다. 따라서 AIDC 보안은 시설 출입통제나 방화벽, 서버 백신을 추가하는 수준으로 설명할 수 없다. 인프라와 데이터, 모델, 서비스, 운영 행위가 서로 영향을 주는 전체 구조를 보호해야 한다.

현재의 가장 큰 문제는 보안 기능의 부재보다 보안 설계의 분절이다. 데이터센터팀은 시설과 서버를, 클라우드팀은 가상화와 계정을, AI 개발팀은 모델과 데이터를, 보안관제팀은 로그와 경보를 각각 관리한다. 개별 영역에는 보안 제품과 절차가 존재하지만, 하나의 AI 서비스가 어떤 사용자와 단말에서 시작해 어떤 데이터와 모델을 사용하고, 어떤 도구를 호출해 어떤 결과를 만들었는지를 끝까지 연결해 보기는 어렵다. 공격자는 이 조직 경계를 따르지 않는다. 계정을 탈취한 뒤 RAG 지식베이스를 과도하게 조회하고, 프롬프트 인젝션으로 에이전트의 행동을 바꾸고, 정상 API를 이용해 정보를 반출할 수 있다. 개별 장비에서는 정상처럼 보이는 행위가 전체 흐름에서는 침해가 될 수 있다.

첫째, AIDC 보안은 장비 구매가 아니라 수용 업무의 정의에서 시작해야 한다. 어떤 업무를 AIDC에 올릴 것인지, 데이터의 민감도와 중요도는 어느 수준인지, 외부 모델과 API를 허용할 것인지, AI가 추천만 하는지 실제 업무를 실행하는지, 서비스 중단이 허용되는 시간은 얼마인지 먼저 정해야 한다. 같은 GPU를 사용하더라도 공개 정보 검색 서비스와 국가 핵심 업무를 처리하는 에이전트형 서비스의 위험은 같지 않다. 보호 대상을 정의하지 않으면 적정한 격리 수준도, 필요한 로그도, 복구 목표도 정할 수 없다. 보안 요구사항이 GPU·네트워크·스토리지·클라우드 구조를 결정해야지, 구축을 마친 뒤 남은 공간에 보안 솔루션을 붙여서는 안 된다.

이 원칙은 미국 사이버보안·인프라보안청(CISA)이 강조하는 '설계단계부터 안전하게'와도 맞닿아 있다. 보안 책임을 이용기관에만 넘기지 말고 제품과 서비스의 설계, 구현, 기본 설정에 내재화해야 한다는 취지다. AIDC에도 같은 원칙이 필요하다. 관리망과 서비스망의 경계, GPU 클러스터와 테넌트 간 격리, 펌웨어·드라이버·컨테이너 이미지의 공급망 검증, 관리자 권한과 비상계정, 백업과 복구 경로를 초기 아키텍처에서 함께 설계해야 한다. 특히 관리 인터페이스와 오케스트레이션 계층이 침해되면 다수의 AI 워크로드와 데이터가 동시에 영향을 받을 수 있으므로, 일반 업무 서버보다 강한 권한 분리와 변경 통제가 필요하다.

AIDC에서는 사이버보안과 물리적 운영 안정성도 분리하기 어렵다. GPU 집적도가 높아질수록 전력과 냉각, 배전, 배터리, 환경제어 설비의 이상이 곧 서비스 중단과 데이터 손상으로 이어질 수 있다. 반대로 관리시스템과 원격 유지보수 경로가 침해되면 물리 설비의 설정 변경이 대규모 장애를 유발할 수 있다. 따라서 시설 운영기술(OT), 건물관리시스템, 전력·냉각 제어망도 AIDC 보안 범위에 포함하고, 안전한 정지와 우회 운영, 복구 우선순위를 사전에 정해야 한다. 기밀성만 강조해 가용성을 훼손하거나, 가용성을 이유로 관리자 권한과 원격 접속을 과도하게 허용하는 두 극단을 모두 경계해야 한다.

둘째, AIDC 인프라 보안과 그 위에서 실행되는 AI 서비스 보안을 구분하되 하나의 체계로 연결해야 한다. 인프라 보안은 시설, 전력·냉각, 네트워크, 스토리지, 가상화, 컨테이너, 운영망·관리망과 공급망을 보호한다. AI 서비스 보안은 학습·추론 데이터, 모델, RAG 지식베이스, 프롬프트와 응답, 에이전트 권한, API·MCP 호출과 가드레일을 다룬다. 두 영역은 보호 대상과 전문성이 다르지만 사고는 경계를 넘는다. 취약한 계정이 모델 저장소 변조로 이어질 수 있고, 오염된 문서가 RAG를 거쳐 잘못된 답변이나 도구 실행을 유도할 수 있으며, 과도한 에이전트 권한이 데이터 삭제나 외부 전송으로 확대될 수 있다. 따라서 두 보안체계는 공통 자산 식별자, 권한 정보, 데이터 등급, 정책과 로그를 공유해야 한다.

셋째, AIDC에는 전 구간 가시성과 맥락 기반 분석이 필요하다. 로그를 많이 모으는 것만으로는 부족하다. '누가, 어떤 계정과 단말로, 어떤 서비스에 접속해, 어떤 데이터와 모델을 이용하고, 어떤 경계를 지나, 어떤 API와 도구를 호출했는가'를 하나의 흐름으로 재구성할 수 있어야 한다. NIST의 제로트러스트 아키텍처가 네트워크 위치만으로 신뢰하지 않고 사용자와 단말, 자원 접근을 지속적으로 검증하도록 요구하는 이유도 여기에 있다. AIDC에서는 사람 계정뿐 아니라 서비스 계정, API 키, 토큰, AI 에이전트의 디지털 신원까지 동일한 원칙으로 관리해야 한다. 특히 에이전트가 여러 도구를 연속 호출하는 환경에서는 단일 로그인 성공 여부보다 세션 중 권한과 행동의 변화가 더 중요하다.

넷째, 탐지는 실제 정책 집행과 격리로 이어져야 한다. 보안관제가 위험을 발견해도 운영자가 여러 시스템에 접속해 수동으로 조치한다면 AI 기반 공격과 자동화된 오작동의 속도를 따라가기 어렵다. 비인가 외부 API 호출, 권한을 초과한 RAG 조회, 민감정보가 포함된 응답, 비정상적인 에이전트 도구 호출이 확인되면 추가 인증, 세션 종료, 토큰 폐기, API 차단, 데이터 전송 보류, 워크로드 격리와 같은 조치를 정책에 따라 실행할 수 있어야 한다. 다만 AI가 모든 조치를 독자적으로 결정하게 해서는 안 된다. 고위험 업무의 차단·삭제·외부 전송과 같은 조치는 인간 승인, 권한 분리, 예외 절차와 되돌리기(Rollback)를 함께 설계해야 한다. 자동화의 목표는 사람을 없애는 것이 아니라, 근거 있는 판단을 필요한 시간 안에 실행하도록 돕는 것이다.

다섯째, AIDC 보안은 체크리스트가 아니라 운영 증적으로 검증해야 한다. 방화벽과 접근통제 솔루션을 설치했다는 사실만으로는 실제 정책이 작동했다고 말할 수 없다. 누가 접근을 승인했는지, 어떤 정책이 허용·차단을 결정했는지, 어떤 데이터가 이동했는지, 격리 후 복구가 정상적으로 검증됐는지가 기록돼야 한다. NIST 사이버보안 프레임워크(CSF) 2.0과 AI 위험관리 프레임워크(AI RMF)가 거버넌스부터 식별·보호·탐지·대응·복구, 그리고 AI 위험의 맥락화·측정·관리까지 전 생애주기를 강조하는 이유도 보안이 일회성 구축이 아니라 반복 운영이기 때문이다. AIDC의 검수 기준도 장비 수량이 아니라 정상 흐름과 위반 흐름에서 통제가 실제 작동하고 증적이 남는지로 바뀌어야 한다.

이러한 구조는 문서 검토만으로 확인하기 어렵다. 구축 전 위협모델링, 구축 중 보안설계 검토, 서비스 개통 전 공격 시뮬레이션과 복구훈련, 운영 중 지속 점검을 하나의 검증 주기로 만들어야 한다. 프롬프트 인젝션, 권한 초과 도구 호출, 모델·지식베이스 오염, API 키 탈취, 관리망 침해, 테넌트 간 이동, 냉각·전력 장애와 같은 시나리오를 실제로 시험해야 한다. OWASP와 MITRE ATLAS가 AI 시스템의 공격 유형과 사례를 체계화하고 있는 만큼, AIDC 사업도 일반 취약점 점검을 넘어 AI 서비스와 인프라가 결합된 공격 경로를 검증해야 한다. 실패를 숨기지 않고 재현 가능한 증적으로 남겨 기준선과 대응 절차를 갱신하는 것이 보안 성숙도의 핵심이다.

이를 위해 정부와 산업계는 AIDC 보안의 공통 기준선을 조속히 마련해야 한다. 공통 기준선에는 최소한 △AIDC 자산과 AI 서비스 인벤토리 △데이터·모델·소프트웨어·펌웨어 공급망 관리 △관리자·서비스·에이전트 신원과 최소권한 △망·테넌트·워크로드·데이터 흐름의 격리 △RAG·프롬프트·API·MCP 통제 △전 구간 로그와 맥락 분석 △정책 기반 차단·격리·복구 △레드팀과 사고 대응 훈련 △운영 증적과 책임 추적이 포함돼야 한다. 공통 기준 위에는 금융·의료·국방·교통·제조 등 업무 위험에 따른 분야별 오버레이를 추가하는 방식이 현실적이다. 모든 AIDC에 동일한 강도의 통제를 강요하기보다, 처리 업무의 영향도와 위험에 따라 보장 수준을 차등화해야 한다.

조달과 사업관리 방식도 달라져야 한다. AIDC 사업의 제안요청서와 설계서에 GPU 성능, 전력, 냉각, 가용성만 적고 보안을 별도 장으로 두는 관행에서 벗어나야 한다. 보안 아키텍처, 신뢰경계, 권한 모델, 외부 연계, 정책 집행 지점, 로그와 증적, 격리·복구 시험을 핵심 요구사항과 인수 기준에 포함해야 한다. CISA와 FBI는 '시큐어 바이 디멘드' 가이드에서 소프트웨어 고객이 조달 과정에서 보안을 명시적으로 요구하고, 제품 보안 요구사항을 계약 문구에 반영하도록 권고한다. 구축 후 취약점을 발견해 보완하는 비용보다, 설계 단계에서 위험한 경로를 제거하는 비용이 작고 효과도 크다.

AIDC의 경쟁력을 GPU 숫자로만 평가하면 하드웨어 확보 경쟁에는 참여할 수 있어도 신뢰 경쟁에서는 뒤처질 수 있다. AI 주권도 국내에 GPU를 설치하고 데이터를 저장하는 것만으로 완성되지 않는다. 데이터와 모델이 어디에서 어떻게 사용되는지 보고, 운영 권한과 정보 흐름을 스스로 통제하며, 사고가 발생했을 때 차단·격리·복구한 과정을 증명할 수 있어야 한다. 결국 AIDC의 핵심 자산은 GPU만이 아니다. 예측 가능한 서비스, 통제 가능한 운영, 검증 가능한 보안이 함께 갖춰질 때 AI 데이터센터는 단순한 연산 시설을 넘어 국가와 산업이 신뢰할 수 있는 핵심 인프라가 된다. 그래서 AIDC 보안은 GPU를 들여온 뒤 검토할 문제가 아니라, GPU보다 먼저 설계해야 할 문제다.


김창훈 대구대 컴퓨터정보공학부 사이버보안전공 교수 kimch@daegu.ac.kr

김창훈 대구대 컴퓨터정보공학부 사이버보안전공 교수

〈필자〉 인프라 보안과 제로트러스트를 중심으로 연구와 교육을 수행해왔으며, 산학연 공동기술개발사업을 통해 사이버보안 기술의 현장 적용을 이끌어왔다. 국가정보원 사이버안보센터 정보보호 실태평가 위원으로 활동하며 공공 영역의 사이버보안 정책과 실무 점검에 참여하고 있다. 또 교육부 지정 영남권 정보보호영재교육원장으로서 정보보호 인재 양성에 힘쓰고 있다.