Samsung SDS

상업용 클라우드 산업이 본격화한 지 2026년 올해로 20년째이다. 2006년 아마존이 AWS를 세계 최초로 선보이면서 클라우드는 본격적으로 시작되었고, 마이크로소프트의 애저가 2010년, 구글 클라우드가 2013년 가세하며 시장은 폭발적으로 성장했다. 무려 매년 15% 안팎의 강력한 성장률을 꾸준히 기록하며 IT 시장의 성장을 견인해 왔다. 게다가 2023년부터 촉발된 생성형 AI 열풍을 클라우드 시장의 성장에 더 가속도를 붙게 해 최근 3년은 무려 20% 이상의 성장률을 보이고 있다. AI 붐을 타고 오래된 클라우드 산업이 다시 불타오르고 있다. 세상만사 양이 있으면 음이 있는 것처럼 클라우드의 성장 과정에 불편한 진실은 무엇일까?

소버린 AI, 독파모, AI폰으로 커져가는 멀티 클라우드

지난 4년간 AI는 끝도 없이 더 뛰어난 성능의 모델 개발을 위해 자원이 투자되었다. 더 강력한 프런티어 모델 개발을 위해서는 GPU부터 상당한 컴퓨팅 인프라를 필요로 한다. OpenAI가 9월에 공개한 GPT-6 아스트라는 엔비디아의 최신 GPU인 그레이스 블랙웰 NVL72 10만 개 이상을 사용했다고 젠슨 황이 밝혔다. 이어 앞으로는 GPU 40만 개가 추가로 가동될 것이라고 밝혔다. 이런 최첨단의 모델은 학습에도 많은 컴퓨팅 자원이 필요하지만, 운영할 때도 학습보다 많은 자원이 필요하다. 게다가 추론의 깊이가 크고 Agent 작업이 많아질수록 더 많은 컴퓨팅 자원을 필요로 한다. 그런 컴퓨팅 자원이 바로 데이터센터이고, 그 데이터센터에는 모델만 있는 것이 아니라 모델이 잘 작동되도록 해주는 수많은 소프트웨어와 솔루션이 필요하고 그 집합체가 클라우드이다.

그런데, 이같은 경쟁이 해를 거듭할수록 커지고 있을 뿐 아니라 규모도 확대되고 있다. 미국의 기업 간 경쟁을 넘어 중국의 참전 그리고 전 세계의 각국이 소버린 AI를 국가 중요 정책을 삼으면서 AI를 둘러싼 경쟁은 확산하고 있다. 당연히 그만큼 데이터센터에 대한 투자도 불이 붙고 있다. 그만큼 GPU, HBM을 포함한 서버와 네트워크 장비 그리고 냉각 설비들과 전력 장치들이 가득한 물리적인 인프라인 데이터센터는 더 많이 필요하고, 그 위에서 가상화 기술로 이들 자원을 잘 사용할 수 있도록 해주는 소프트웨어 기반의 서비스인 클라우드의 역할도 더 중요해지고 있다.

[그림 1] AI 확산으로 복잡해지는 멀티·하이브리드 클라우드 구조 (출처: ChatGPT 이미지 생성)

AI 시대 멀티 ·하이브리드 클라우드의 복잡도 - 모델 ·데이터 ·도구· 컴퓨팅이 여러 클라우드와 온디바이스로 흩어진다 - 실행은 분산, 통제는 중앙으로에 대한 도식표

그 과정에 모델은 다양해지고 있다. GPT, Claude, Gemini와 같은 프런티어 모델과 중국의 오픈웨이트 모델들 그리고 정부 주도로 만들어가는 독파모와 같은 모델까지 다양한 모델을 혼용하면서 복잡도가 커진다. 심지어 갤럭시 S26이나 아이폰 18 프로 그리고 AI PC와 같은 기기들 안에서 AI가 구동되는 온디바이스 AI까지 더해지면서 AI를 구동할 때 이용해야 하는 모델들이 많아지고 있다. 모델만 다양해지는 것이 아니라 AI가 잘 구동되고 Agent가 완결적으로 작업을 처리하는 과정에 필요로 하는 데이터와 도구들도 더 많아지고 있다. 그렇게 모델과 데이터, 도구가 많아지면 그만큼 이들이 구동되고 저장된 데이터센터도 많아져서 복잡도가 더 커진다. 그렇게 여러 곳을 경유하며 사용해야 하는 경우 이 혼잡함을 관리하고 에러나 지연 속도, 비용 등을 최소화해야 하려면 이를 제어할 수 있는 클라우드의 역할이 중요해진다. 그렇게 여러 클라우드를 복합적으로 사용하는 것을 멀티 클라우드라고 한다.

복잡해진 클라우드가 가져다준 통제와 보안의 이슈

여기에 보안까지 고려하면 더 복잡해진다. AI 구동 과정에는 회사 밖으로 보내도 되는 정보와 내부에서만 처리해야 하는 정보가 섞여 있기 때문이다. 일례로 계약서를 검토하는 Agent는 고객 정보와 계약서는 회사 내부의 모델로 분석하고 공개된 시장 정보의 수집과 정리는 외부 클라우드의 모델에 맡길 수 있다. 모든 작업을 외부에 맡기지도 않고 모든 인프라를 내부에 갖출 필요 없이 취사선택하며 이용하는 것이다. 이렇게 자체 서버나 프라이빗 클라우드와 외부의 퍼블릭 클라우드를 연결해 사용하는 것을 하이브리드 클라우드라고 한다. 보안과 통제 때문에 내부에 남겨야 하는 자원과 확장성 때문에 외부에서 빌려 쓰는 자원을 결합하는 방식이다. AI 확산과 함께 하이브리드 클라우드는 더욱 확산하고 있다.

이렇게 멀티 클라우드와 하이브리드 클라우드는 서로 다른 구분이다. 멀티 클라우드가 여러 클라우드 사업자의 서비스를 사용하는 것이라면 하이브리드 클라우드는 내부 인프라와 외부 클라우드를 함께 사용하는 것이다. 회사 내부 시스템을 AWS와 애저에 연결한다면 두 가지에 모두 해당한다. 반대로 하나의 클라우드에서도 여러 회사의 AI 모델을 이용할 수 있다. 그럼에도 최고 성능의 프런티어 모델도 사용해야 하고 기업 독자적인 Vertical sLLM도 이용하면서 모델들을 여러 클라우드를 넘나들며 사용해야 해서 멀티 클라우드도 더 확대되고 있다.

그런데 데이터를 내부에 보관한다고 해서 외부로 나가지 않는 것은 아니다. 사내 문서를 찾아 AI에 제공하는 RAG를 내부에 구축했더라도 검색한 내용을 외부 모델의 입력으로 전달한다면 해당 내용은 회사 밖에서 처리된다. 계약서 원본은 내부 서버에 그대로 남아 있어도 계약 조건이 담긴 몇 개의 문단은 외부로 이동할 수 있다. 외부 사업자가 데이터를 학습에 사용하지 않는다는 확신을 주긴 하지만 그것만을 전적으로 믿을 수는 없다. 따라서 AI 시대의 보안은 데이터의 보관 위치 외에도 외부 클라우드에 무슨 내용이 전달되는지를 따져 봐야 한다. 문서 파일 자체가 통째로 전달되지 않는다고 하더라도 문서의 어떤 내용이 추출되어 프롬프트와 함께 전송되는지는 파악해서 이에 대한 관리가 필수적이다.

데이터가 내부에 있어도, AI 처리 경로는 외부로 나갈 수 있다 : 통제 대상은 '어디에 저장했나'가 아니라 '무엇이 모델 입력으로 전송되나'

기업 내부

• 계약서 원본
• 원문 전체 전송
• 사내 문서
• RAG / Vector DB

원문 전체 전송 불가 정책 게이트웨이 검색 → 문단 추출 → 민감정보 마스킹 → 정책 판정 외부 AI 모델 • 클라우드 API 원문 전체 수신 : 계약 조건 · 고객 정보까지 노출 (허용) 필요 문단만 • 마스킹 후 정책에 따라 전송

발훼 + 제7조 (지급 조건) 계약 당사자 : 블라인드 처리 담당자 김 ** · 연락처 : 블라인드 처리 지급 기한: 검수 완료 후 30일 이내

감사 로그-원문 대신 메타데이터 ·접근 기록 중심 = 10:21:07 | user_8F2A | doc#A-12 | 전송 문단 3 | 마스킹 √ | 모델: 승인 목록

여러 클라우드를 연결하는 과정에는 또 다른 문제가 생긴다. 사업자마다 데이터를 주고받는 방식과 인증 체계가 다르고 이용 요금과 장애 대응 방식도 다르다. 한 곳에서 정상적으로 작동하던 시스템이 다른 곳에서도 그대로 작동한다는 보장은 없다. 클라우드 사이를 오가는 횟수가 늘면 통신 지연과 데이터 전송 비용도 함께 살펴야 한다. 그래서 멀티 클라우드 운영의 핵심은 여러 서비스를 연결하는 데 그치지 않는다. 어떤 작업을 어디에 배치하고 어떤 데이터는 이동시키지 않을지 결정해야 한다. 자주 사용하는 데이터 가까이에서 작업을 처리하고 각 환경의 상태와 접근 권한을 공통 기준으로 관리해야 한다. 그만큼, AI 시대에 멀티 클라우드는 성능이나 보안 외에도 비용을 절감하면서 효율적으로 운영할 수 있는 것도 중요하다.

AI가 직접 도구를 사용하는 Agent로 발전하면 보안의 대상도 넓고 깊어진다. 외부 문서나 웹페이지에 숨어 있는 악의적인 지시를 AI가 업무 명령으로 받아들일 수 있고 이것을 프롬프트 인젝션이라 부른다. 단순한 챗봇에서는 잘못된 답변으로 끝날 일이 이메일 발송과 파일 수정 권한을 가진 Agent에서는 정보 유출이나 업무 사고로 이어질 수 있다. 방화벽을 뚫는 대신 이미 권한을 가진 AI가 잘못된 일을 하도록 유도하는 것이다. 이제는 누가 시스템에 접속했는지뿐 아니라 그 권한으로 어떤 행동을 하려는 지까지 통제해야 한다. 자유롭게 연결한 모델과 데이터와 도구가 통제되지 않는 순간 클라우드의 유연성은 기업의 취약점으로 바뀔 수 있다.

[그림 3] 프롬프트 인젝션으로 인한 AI 에이전트의 위험과 실행 통제 (출처: ChatGPT 이미지 생성)

Al Agent의 위험: 외부 문서의 지시가 업무 실행으로 이어질 때 - 간접 프롬프트 인젝션 - 문제는 '무엇을 답했나'가 아니라 '어떤 권한으로 무엇을 실행했나'에 관련된 도식표

안전하고 안정적인 클라우드 운영을 위한 지침

그렇기에 AI로 인해 더 복잡해지고 안전 관리해야 하는 클라우드를 유연하게 확장하면서도 통제 관리를 어떻게 잘 해야 할까?

[그림 4] 분산된 AI 인프라를 하나의 기준으로 통제하는 운영 체계 (출처: ChatGPT 이미지 생성)

인프라는 분산해도, 통제와 책임은 분산하지 않는다 라는 타이틀과 분산된 AI 인프라가 가운데 통제 조종석이라고 적혀있는 원형으로 모여있는 이미지

첫째는 어디에 무슨 데이터를 저장하고 Agent에 어디까지 권한을 허용할 것인지를 정하는 것이다.
공개 정보와 외부 처리가 허용된 업무 정보 그리고 내부에서만 처리해야 하는 정보를 구분해야 한다. 이 기준에 따라 사용할 수 있는 모델과 클라우드가 달라야 한다. 공개 정보야 외부의 강력한 프런티어 모델에 의존해도 되지만, 내부에서 처리해야만 하는 것은 내부 자체 모델에 의존해야 한다. 특히, 회사 기밀문서는 저장 위치뿐 아니라 실제 처리 장소와 접근 권한도 확인해야 한다. Agent에는 업무 수행에 필요한 수준의 최소한 권한만 부여해야 한다. 일례로 문서를 요약하는 Agent에 삭제 권한까지 줄 이유는 없다. 또한, 사용자가 볼 수 없는 문서를 Agent가 대신 검색해서도 안 된다. 송금이나 외부 발송과 같은 중요한 작업은 별도의 승인 절차를 거치도록 해야 한다. 이런 통제는 AI에게 주의를 당부하는 프롬프트가 아니라 실제 데이터를 제공하고 작업을 실행하는 시스템에서 강제되어야 한다.

둘째는 무엇을 어디서 처리할 것인지를 정하는 분배의 메커니즘이다.
사용해야 하는 모델이 여러 개가 되면 어떤 요청을 어디서 처리할 것인지 제어하는 관리자가 필요하다. 이를 통해 어떤 프롬프트를 어느 모델을 호출해서 어떻게 안전하게 사용할 것인지를 관리할 수 있다. 여기에 Agent의 작업 흐름을 관리하는 체계를 결합해야 한다. 사용자의 요청 하나가 어떤 모델과 데이터와 도구를 거쳤는지 로그로 기록해 추적하고 관리해야 한다. 모델 종류와 버전, 응답 시간 그리고 오류와 토큰 사용량을 함께 살펴야 문제가 생긴 위치를 찾을 수 있다. 모든 답을 내부의 모델만으로는 성능의 한계로 해결할 수 없다. 결국 고품질의 결과를 필요로 하는 프롬프트는 외부 모델에 도움을 받아야 하는데 이때 내부 라우터를 거치면서 모델을 선택하고 외부에 프롬프트를 보낼 때 보안 문제를 최소화할 수 있어야 한다.

셋째는 단순히 클라우드 사용료를 전체로 관리할 것이 아니라 업무 단위로 비용을 관리하는 것이다.
AI 서비스에서는 입력과 출력 토큰에 따른 비용을 구분해야 하고 자체 모델을 운영한다면 GPU와 메모리 등의 자원 사용 비용도 계산해야 한다. 즉, 기존의 클라우드 사용 요금과는 AI는 본질적으로 규모나 과금 방식이 크게 다르다. Agent는 하나의 작업을 처리하면서 여러 차례 모델을 호출한다. 앞서 읽은 문서와 대화 내용이 다음 호출에 다시 포함되거나 실패한 작업을 반복하면 사용량은 더 늘어난다. 여기에 검색과 저장 그리고 클라우드 사이의 데이터 전송 비용까지 붙는다. 따라서 월말에 클라우드 청구서를 확인하는 것으로는 부족하다. 부서와 업무별 사용량을 살피고 작업당 토큰과 호출 횟수에 상한을 두어야 한다. 그렇다고 무조건 토큰 가격이 싼 모델을 선택하는 것이 정답은 아니다. 저렴한 모델이 여러 번 실패하는 것보다 비싼 모델이 한 번에 정확하게 처리하는 편이 전체 비용은 낮을 수 있다. 단순한 작업에는 작은 모델을 쓰고 복잡한 판단에만 고성능 모델을 사용하는 식으로 업무에 맞게 배분해야 한다. 반복되는 입력의 재사용과 불필요한 문서 입력의 축소도 함께 고려할 수 있다. 결국 관리해야 하는 것은 토큰 단가만이 아니라 요구하는 품질을 충족하면서 업무 한 건을 제대로 끝내는 데 들어간 총비용이다. 모델의 성능과 비용 그리고 업무 성과를 같은 기준에서 비교해야 한다.

넷째는 이기종 컴퓨팅 자원을 통합해 하나의 자원처럼 사용하는 최적화 기술이다.
AI를 운영하는 인프라는 CPU와 GPU 그리고 NPU 등 서로 다른 특성을 가진 장비로 구성된다. 이들을 따로 운영하면 어떤 장비는 놀고 다른 장비에는 작업이 몰릴 수 있다. 가상화와 컨테이너를 활용해 실행 환경을 분리하고 표준화하는 이유가 여기에 있다. 여기에 쿠버네티스와 같은 자원 배치·운영 기술을 결합해 모델이 요구하는 메모리와 장비 종류에 맞춰 작업을 배정해야 한다. 단순히 서버 대수를 늘리는 것이 아니라 필요한 자원을 적절한 작업에 공급하는 것이다. 다만 가상화가 서로 다른 장비를 모두 같은 컴퓨터로 만들어주는 것은 아니다. 제조사별 드라이버와 모델 실행 환경의 호환성을 확인해야 하고 장비마다 사용할 수 있는 메모리와 지원 기능도 다르다. 멀리 떨어진 클라우드의 자원을 연결했다고 해서 한 데이터센터 안에 있는 것처럼 빠르게 통신할 수도 없다. 따라서 통합 운영의 목표는 모든 장비에 모든 작업을 올리는 것이 아니라 서로 다른 자원을 하나의 정책 아래 관리하면서 각 작업에 적합한 실행 장소를 찾아주는 것이다.

다섯째는 장애가 났을 때뿐 아니라 AI가 잘못 작동될 때도 안전하게 멈출 수 있어야 한다는 것이다.
여러 클라우드를 사용한다고 자동으로 장애에 강해지는 것은 아니다. 대체 환경의 처리 용량과 모델 호환성을 미리 검증하고 중단된 작업을 어디서부터 다시 시작할지도 정해야 한다. 재시도 횟수와 대기 시간을 제한하지 않으면 되려 장애가 비용 폭증으로 번질 수 있다. 특히 결제나 발주를 다시 실행할 때 같은 거래가 중복되지 않도록 설계해야 한다. 장애를 피하려고 다른 클라우드로 전환하다가 내부 전용 데이터를 외부로 보내는 우를 범해서도 안 된다. 대체 경로 역시 평상시와 같은 보안 기준을 충족해야 하며 그 조건을 지킬 수 없다면 작업을 중단하거나 사람에게 넘겨야 한다.

결국 AI 시대의 클라우드 전략은 얼마나 많은 자원을 연결하느냐보다 연결한 자원을 얼마나 책임 있게 운영하느냐에 달려 있다. 무엇을 어디에서 실행할지와 얼마를 쓰게 할지 그리고 언제 멈출지를 기업이 결정할 수 있어야 한다. 클라우드가 제공하는 유연성은 이런 통제가 뒷받침될 때 비로소 경쟁력이 된다. 인프라는 분산해 안정성을 담보할 수 있어도 통제와 책임까지 흩어져서는 안 된다.

FAQ