AI가 내 비밀을 남에게 말했다 | 클라우드플레어 사고... 엔비디아가 DPU를 만든 이유

Video: AI가 내 비밀을 남에게 말했다 | 클라우드플레어 사고... 엔비디아가 DPU를 만든 이유
Channel: 안될공학 - IT 테크 신기술
Duration: 12m 35s
Source: subtitle (auto, ko)
Transcript:
네, 여러분 안녕하세요. 패치입니다. 여러분 만약에 여러분이 AI에다 회사 분석을 넣었는데 답변에 다른 고객의 내용이 섞여 나온다면 어떨까요? 아유, 여러모로 아주 아찔하죠. 생각하기도 싫은데요. 클라우드 플레이어가 10월 26일 공개한 사고에서 실제로 이런 일이 벌어졌습니다. 회사 조사에서 확인한 그 범위는 약 155개의 응답이었고요. 특정 모델을 실행하는 과정에서 고객 사이에 데이터 경계가 무너졌다는 거예요. 이런 서비스를 운영하는 회사 입장에서는 AI가 얼마나 빨리 답을 하느냐 이것만큼이나 고객의 정보가 누구에게 보이느냐 이것이 사업의 중요한 조건이죠. 그래서 오늘은 질문을 엔비디아 쪽으로 한번 옮겨 보려고 하는데요. 엔비디아에는 이미 엄청나게 비싼 GPU가 있는데 왜 블루필드라는 DPU까지 따로 설계를 할까요? GPU를 사서 여러 기업의 서비스를 제공하는 고객들은 계산 성능이랑 함께 고객끼리 섞이지 않는 그런 실행 환경이랑 통제 가능한 그런 운영 구조를 요구를 하죠. 엔비디아는 그중에서 네트워크랑 저장 장치, 인프라 통제를 담당하는 해법으로 블루필드를 제시하고 있습니다.

클라우드 플레어 사고에서 드러난 그런 추론 소프트웨어의 책임 클라우드 사업자의 선택까지 쫙 따라가 보면이 칩을 필요로 하는 고객이 누구인지도 보입니다. 내 회사 안에서만 쓰는 AI 서버랑 여러 회사의 작업을 받아서 돈을 버는 클라우드는 운영 조건이 다른데요. 가상의 예로 어 같은 데이터 센터에 경쟁 관계인 두 회사가 들어왔다고 해 볼게요. 장비랑 네트워크를 효율적으로 운영을 하면서도 각 회사의 데이터랑 통신 관리 권한이 허용된 범위 안에 머물러야 하잖아요. 한 고객이 자기 서버 관리자라고 해서 옆 고객의 네트워크나 클라우드 전체 통제 규칙까지 바꿀 수 있어선 절대 안 되겠죠. 실제 대형 클라우드도이 문제를 설계 출발점으로 설명을 합니다. AWS는 자체 니트로 시스템을 소개를 하면서 고객이 요구하는 보안이란 격리 그리고 성능 비용 효율을 함께 제공하기 위해서 가상화 구조를 다시 설계했다고 밝혔는데요. AWS가 직접 설계한 별도 하드웨어로 인프라 업무를 분리하는 접근인데 고객 작업이란 클라우드 운영의 경계를 나눈다는 그런 요구가 잘 드러납니다.

AI 클라우드인 코어위브도 자사의 그 보안 안내에서 관리형 쿠버네티스 서비스의 노드를 고객별로 분리를 설명을 하고 있어요. 저장 데이터의 암호화랑 고객 통신을 비공개로 유지하는 그런 가상 네트워크도 함께 안내를 하고 있죠.데 여기에서 중요한 건 고객이 구매하는 대상인데요. 기업은 GPU 계산 시간을 쓰면서도 자기 문서랑 모델 그리고 데이터가 정해진 범위에서만 사용된다는 그런 운영 조건을 함께 요구를 하죠. 그 조건을 설명하고 검증할 수 있어야만 민감한 업무를 맡길 수 있을 테니까요. 근데 클라우드 플레어 사고는 이런 경계가 서비스 내부에서 어떻게 무너질 수 있는지를 보여 주는데요. 이게 영향을 받은 곳은 클라우드플레이어 workers AI의 GLM 5.3 운영 환경이었습니다. 문제가 있었던 기간은 8월 27일부터 9월 9일까지였고요. 9월 9일에 수정한 다음에 10월 26일 조사 결과를 공개를 한 거예요. 다른 워커스 AI 모델에는 영향이 없었다는게 회사 설명이긴 합니다. AI는 긴 문서를 읽고 나면 답변을 이어갈 때 이제 참고할 계산 결과를 KB 캐시라는 작업 기억에 보관을 하죠.

원문을 그대로 쓰는 메모장보다는 앞에 내용을 참조하는 그런 숫자 형태의 정보인데 그래도 원래 내용의 민감성은 남아 있는 거죠. 클라우드 플레이어는 입력을 읽는 프리필 단계랑 답을 내보내는 디코드 단계를 서로 다른 GPU 그룹에다 맡기고 그 사이로 KV캐시를 전달했습니다. 그런데 입력을 이만큼까지 받겠다고 정해 놓은 한더가 정작 입력 담당 GPU가 캐시 담을 수 있는 양보다 컸던 거예요. SG랭이라는 추론 엔진은이 요청을 처리를 할 수 없으니까 거절을 해야 한다고 표시를 했고요. 그런데 거절 처리를 마무리하려고 임시 데이터를 넣어둔 요청이 그다음 전달 단계까지 넘어가 버린 거죠. 답변 담당 지유는 정상적으로 준비가 끝난 줄 알았던 거고요. 실제로 새로 채운 캐시는 1부분이었는데 그 뒤에 남아 있던 공간까지 읽어 버리면서 이전 고객의 계산 결과를 가져다 써 버린 거예요. 공동 작업대에서 앞사람의 서류를 치우지 않아 버린 채 다음 건의 서류가 전부 도착했다고 도장을 확 찍어 버린 상황에 가까운 거죠.

클라우드 플레어는 캐시 용량이랑 입력 한도를 맞추고 그다음에 거절할 요청이 전달 단계에 들어가기 전에 오류로 끝나도록 수정을 했습니다. 별도의 관련 문제로 진행 중인 데이터 전송이 완료되기 전에 메모리를 다른 요청에 돌려주지 않도록 하는 부분도 보강을 했고요. 거절할 요청을 정상 요청처럼 넘겨 버린 것이 이번 사고의 직접적인 원인이었고요. 전송 중인 메모리를 너무 일찍 다시 쓰는 문제는 또 따로 구분을 해서 봐야 하는데요. 뭐 모델이 문장을 유창하게 만드는 것이랑 그 문장을 만드는데 쓴 정보가이 고객의 것이 맞는지 그거는 좀 별개의 검사이죠. 운영 사이에는 이렇게 추론 엔진 내부를 검증할 책임이랑 함께 데이터가 오가는 네트워크랑 저장 장체 경계를 관리를 해야 할 책임이 있습니다. 근데 이제 서비스 규모가 커지게 되면 이런 관리 업무도 늘어나게 되는데요. 네트워크로 들어오는 데이터를 어느 고객한테 보낼지를 정하고요. 저장 장치 접근을 처리를 하고 통신을 암호화하고 그리고 고객별로 자원을 나누는 일이 계속 돌아가야 되죠.

서버의 CPU가 소프트웨어로이 일을 맡으면 고객 서비스를 돌리는데 쓸 계산 능력이랑 메모리에서 데이터를 읽고 쓰는 여력도 그만큼 나눴어야 돼요. 보안 기능을 충분히 적용하면서도 응답 속도랑 운영 비용을 유지를 해야 하는 것이 운영사의 고민인 거죠. 데이터 처리 경로가 밀리면 GPU도 기다려야 되는데요. 어, 예를 들어서 비싼 요리사 아주 고급 요리사들을 잔뜩 모아 놨는데 재료가 주방에 천천히 늦게 들어오는 상황을 생각하시면 되는데요. 요리사를 많이 데려오는 것만으로는 그런 대기 시간이 줄어들지가 않죠. 이런 수요의 엔비디아가 제시하는 블루필드 DPU는 고속 네트워크 기능에다가 자체 CPU 코어랑 전용 가속기를 묶은 그런 인프라 프로세서입니다. 서버의 주 CPU가 하던 네트워크 스토리지 보안 업무 가운데서 DPU가 맡을 수 있는 일을 좀 넘겨 주는 거죠. 이렇게이를 옮기는 걸 오프로딩이라고 부르는데요. 안에 들어 있는 CPU가 관리 규칙이랑 서비스를 실행을 하고요. 그 규칙에 따라서 데이터를 처리하거나 암호화하는 반복 작업은 전용 회로가 빠르게 맞는 거예요.

GPU의 큰 행렬 계산이라든가 데이터를 분류하고 전달하는 일은 필요한 회로랑 데이터 흐름이 다르기 때문에 그걸 담당하는 칩도 이렇게 나누는 거죠. 저는 DPU의 경제성을 봤을 때 필요한 보호 기능을 켠 상태에서 CPU랑 GPU가 실제 고객 작업에 얼마나 더 쓰이는지를 좀 봐야 된다고 생각을 합니다. 보호 기능을 꺼놓고 얻은 속도라면 이거는 운영사가 중요시 해야 하는 서비스의 성능이랑은 조건이 좀 달라지니까요. 그리고 일을 옮기는 것과 함께 또 누가 통제 권한을 갖는지도 되게 중요한데요. 고객이 사용하는 서웨어 운영 체제에 문제가 생겨도 고객 사이의 네트워크 경계를 관리를 하는 쪽은 또 별도로 통제를 할 수가 있어야겠죠. 블루필드의 DPU 모드에서는 자체 암 시스템이 네트워크 자원이랑 데이터 경로를 관리를 하는데요. 추가로 제로 트러스트 모드를 설정을 하면 호스트 서버의 관리자가 블루필드의 일부 관리 기능에 접근하는 것도 제안을 할 수가 있습니다. 관리하는 경로랑 권한을 좀 따로 설정을 해 두면 고객이 작업하는 쪽이랑 클라우드 운영사가 관리하는 쪽을 분리를 할 수가 있는 거죠.

블루필드는 일반 네트워크 어댑터처럼 쓰는 NIC 모드도 지원을 하는데요. 그래서 블루필드를 달았다는 것만 볼게 아니라 실제로 어떤 모드랑 어떤 설정으로 쓰는지도 봐야 돼요. 고객별 네트워크 분리의 DPU를 활용하는 실제 운영사가 코어 위브입니다. 코어 위브는 자체 기술 설명에서 수년간 블루필드 DPU를 서버에 통합을 해 왔고 NBDI의 도카 소프트웨어로 핵심 네트워크랑 보안 기능을 DPU에 옮겼다고 설명을 합니다. 고객마다 별도의 가상 네트워크를 만들고요. 그 분리를 하드웨어에서 적용을 하는 그런 구조라는 거죠. 현재 보안 안내에도 블루필드 3DPU 기반의 가상 네트워크를 명시를 하고 있어요. 여기에서는 운영사가 원하는 고객별 격리랑 엔비디아가 공급하는 DPU의 기능이 실제 서비스 설계에서 만난 건데요. 제가 중요하게 보는 건 보안 기능을 켰다는 그런 표시보다 고객 서버에 문제가 생겼을 때도 누가 그 규칙을 관리하고 유지할 수 있느냐 그거인 거죠. CPU의 일을 덜어주는 성능 효과랑 통제 권한을 분리하는 보완 효과를 함께 제공을 해야지만이 장비를 추가할 이유가 생기는 거겠죠.

운영사가 처리를 해야 될 데이터의 종류도 AI 서비스랑 함께 늘어나고 있는데요. 긴 문서를 읽고 여러 단계로 일하는 에이전트는 앞에서 계산해 둔 작업 기억을 계속 쓸 수 있는 편이 좋겠죠. 매번 버리고 다시 계산하게 되면 GPU 시간이랑 전력을 다시 써야 하니까요. 그런데 GPU에 붙은 HBM은 빠르지만 담을 수 있는 양에는 한 개가 있죠. 모든 고객과의 긴 대화에서 나온 캐시를 여기에다 계속 쌓아 둘 수는 없는 거예요. 그래서 쓰던 캐시를 다른 메모리나 저장 장치로 옮겼다가 필요할 때 다시 가져오는 그런 구조가 중요해지는 거죠. 엔비디아가 2026년 3월 소개한 CMX는 블루필드 4를 활용을 해서 여러 GPU가 연결된 묶음에다 KB캐시용 저장 개층을 더하는 플랫폼입니다. 이더넷으로 연결한 플래시 저장 장치에 캐시를 두고요. 필요해지기 전에 GPU 쪽으로 준비해 놓는 그런 방향인데요. ND디아의 설명에서도 블루필드 4은이 캐시의 입출력이랑 저장 장치 처리를 맞고요. KB 전송 경로의 암호화랑 CRC 검사도 가속을 합니다.

암호화는 내용을 보호하는 역할이고 CRC는 전송이라든가 저장 과정에서 이제 데이터가 선상을 되는지 그걸 확인하는 검사죠. 누가이 데이터를 읽어도 되는지 그리고 지금 처리하는 요청의 데이터가 맞는지 별도를 확인을 해야 하니까 이렇게 나눈 거예요. 어떤 캐시를 어느 요청에 가져다 줄지는 AI를 실행하는 추론 프레임워크랑 캐시 관리 소프트웨어가 함께 결정을 하게 되는데요. 빠른 운송이랑 올바른 배차가 맞아 들어가야지만 전체 시스템이 잘 돌아가는 그런 구조인 거겠죠. 여기서 재밌는 건 GPU를 추가하지 않고도 기다리는 시간을 줄일 여지가 좀 생긴다는 점인데요. 어, 제 생각에는 긴 문맥을 처리를 하는 서비스일수록 저장 장체 용량만 비교하기보다는 필요한 캐시가 일단 제 시간에 돌아오는지를 좀 봐야 할 것 같아요. 캐스를 많이 보관했어도 다시 가져오는 시간이 길어지면 고객은 여전히 답변을 기다리고 있게 되니까요. 엔비디아는 운영사 요구에 맞춰서 보호 기능도 데이터 경로를 따라서 넓히고 있는데요. 지원되는 시스템이랑 소프트웨어 접근 정책을 갖춰서 쓰는 기능들입니다.

5월 발표한 블루필드 4 STX용 독화 보안 기능에는 허용된 작업만 해당 권한으로 파일에 접근을 하게 하는 그런 기능이랑 고객 사이의 네트워크 격리가 같이 포함이 되어 있는데요. 서비스를 만드는 쪽에서는 이런 인프라 보호를 출론 엔진의 데이터 관리랑 연결을 해야 하겠죠. 예를 들어서 암호화 해서 정확히 전달한 데이터를 받았어도 프로그램이 옆에 고객의 메모리까지 자기 것으로 읽어 버리면 그 프로그램의 상태 관리를 바로 고쳐야겠죠. 클라우드 플레이어가 입력 한도랑 캐시 용량을 맞추고 잘못된 요청이 다음 단계로 넘어가지 않도록 수정한 부분이 바로 여기에 해당하는 겁니다. 네트워크랑 저장 장치에서는 누가 접근할 수 있는지를 관리하고 추론 엔진에서는이 캐시가 누구의 요청이고 언제까지 쓸 것인지 그거를 관리를 해야 하고요 두 부분이 착착 맞물려야 하는 거고요. 운영사는 이런 과정에서 누가 뭘 책임지는지 고객한테 설명을 할 수 있어야 하는데요. 어떤 장비를 쐈는지랑 함께 오류나 취소가 났을 때 데이터가 어디에 남고 언제 다시 쓰이고 누가 읽을 수 있는지까지 검증을 해야 하는 겁니다.

기업 고객이 민감한 업무를 믿고 맡길 수 있게 만드는 요런 조건들이 장비 도입을 실제 유료 과동으로 이어주는 그런 중요한 단계겠죠. 그래서 이제 처음 질문으로가 보면 엔비디아가 DPU를 따로 설계하는 이유가 보이는데요. GPU를 사는 클라우드 사업자는 그런 계산 능력을 여러 고객한테 안정적으로 제공을 해야지만 돈을 벌 수 있죠. 고객별로 데이터를 격리하고 운영 권한을 통제하면서 비싼 CPU랑 GPU는 가능한한 고객의 계산을 쓰고 싶어 하는 거예요. 엔비디아는 그 요구에 맞춰서 GPU 주변의 네트워크랑 저장 보완 처리를 블루필드로 분담을 하는 그런 구조를 제안을 하고 있는데요. 코어웨이브처럼 이거를 서비스에 통합한 사례는 이런 요구가 이제 제품 설명을 넘어서 실제 구매랑 설계 선택으로도 이어지고 있다는 그런 근거라고 보시면 됩니다. 제 생각에는 여기에서 이제 MBD 사업 범위도 넓어지는 건데요. GPU의 성능을 공급하는데에 더해서 고객이 그 GPU를 서비스로 운영을 할 때 필요한 인프라까지 함께 공급을 할 수 있으니까요.

고객이 이런 구성을 선택을 할지는 뭐 총 비용 대비 효과에 달려 있겠죠. 추가 장비랑 통합 운영에 드는 비용을 감안을 해 봤을 때 같은 보안 단계랑 응답 지원 조건에서 더 많은 고객의 요청을 처리할 수 있는지 그거를 좀 확인해 봐야 될 것 같습니다. 클라우드 플레이어 사고는 운영사가 반드시 지켜야 할 그런 경계를 보여줬고 코아 위브의 선택은 그 경계 중에서도 특히 인프라 영역에 실제로 돈을 쓰는 이유를 보여줍니다. GPU가 있는데 왜 DPU까지 만들까? M비DI 고객한테 필요한 건 빠른 계산이랑 함께 그 계산을 다른 고객이랑 안전하게 나눠서 서비스 할 수 있는 그런 구조이기 때문이겠죠. 그럼 오늘은 여기까지 패치였습니다.