AI

알리바바 판구(Pangu) 스토리지 해부: 신화 속 도끼는 어떻게 데이터센터의 척추가 되었나

marvin-jung 2026. 5. 19. 00:32
반응형
SMALL
알리바바 판구(Pangu) 스토리지 해부: 신화 속 도끼는 어떻게 데이터센터의 척추가 되었나
중국 신화의 창세 거인 이름이 알리바바와 화웨이의 핵심 인프라에 동시에 붙어 있습니다. 그 이유와, 10년 넘게 안정적으로 돌아가는 분산 스토리지의 속살을 같이 들여다보겠습니다.

중국 클라우드 업계를 들여다보다 보면 '판구(Pangu, 盘古)'라는 이름을 자주 만나게 됩니다. 묘한 점은 알리바바의 핵심 분산 스토리지 이름도 판구이고, 화웨이의 거대언어모델 시리즈 이름도 판구라는 것입니다. 라이벌 관계의 두 회사가 같은 이름을 쓰고 있는데, 그 배경에는 단순한 우연 이상의 의도가 있습니다.

이번 글에서는 판구라는 이름의 출처가 된 중국 신화부터, 알리바바가 이 이름을 붙인 분산 스토리지의 내부 구조, 그리고 10년이 넘도록 큰 사고 없이 운영되어 온 비결까지 정리해보겠습니다.

판구가 누구인가
신화 한 줄 요약

태초의 우주는 거대한 알이었고, 그 안에서 1만 8천 년을 잠들어 있던 판구가 깨어나 도끼로 알을 갈랐습니다. 가벼운 양(陽)은 위로 올라가 하늘이, 무거운 음(陰)은 아래로 가라앉아 땅이 되었습니다. 그는 하늘과 땅이 다시 붙지 않도록 가운데 서서 또 1만 8천 년을 받쳤고, 끝내 죽으면서 자신의 몸을 세상의 부품으로 분해했습니다.

죽은 뒤가 더 흥미롭습니다. 숨은 바람과 구름이, 목소리는 천둥이, 왼쪽 눈은 태양이, 오른쪽 눈은 달이 되었습니다. 피는 강과 호수가 되었고, 살은 대지, 뼈는 광물과 보석, 머리카락은 별자리가 되었다고 전해집니다. 정리해보면 판구는 '세상을 가르고, 떠받치고, 끝내 그 세상의 모든 구성 요소로 분해된 존재'입니다. 이 점을 기억하시면, 잠시 후 알리바바 판구의 구조를 보실 때 묘하게 겹치는 부분이 있어서 살짝 웃으실 수도 있겠습니다.

왜 알리바바와 화웨이는 둘 다 이 이름을 골랐을까

이름은 라벨이 아니라 포지셔닝의 선언입니다. 알리바바와 화웨이가 동시에 핵심 인프라에 판구라는 이름을 붙인 이유는, 결국 같은 메시지를 전하고 싶었기 때문입니다. "이것은 모든 것을 떠받치는 기반이다."

ALIBABA
알리바바 판구 (盘古存储)
영역 · 분산 파일 시스템 / 스토리지
시작 · 2009년 (Apsara OS와 함께)
위치 · EBS, OSS, RDS, MaxCompute, Hologres가 그 위에 올라감
"모든 데이터의 받침대"라는 포지셔닝
HUAWEI
화웨이 판구 (盘古大模型)
영역 · 거대언어모델 / 산업용 AI
시작 · 2021년 (200B 파라미터 중문 모델)
위치 · L0 기반 → L1 산업 → L2 시나리오 (5+N+X 계층)
"모든 산업 지능의 기반"이라는 포지셔닝

한쪽은 데이터의 기반, 다른 한쪽은 지능의 기반인 셈인데, 둘 다 '모든 위 서비스가 이 위에 선다'는 의미를 노린 것은 같습니다. 부수적으로, 비행천(飞天, Apsara), 쿤붕(鲲鹏, 화웨이 ARM 서버 칩) 같은 다른 작명들도 함께 보시면, 중국 빅테크가 신화의 거대 스케일을 인프라 작명에 의도적으로 끌어다 쓰는 패턴이 분명하게 보입니다.

알리바바 판구가 실제로 떠받치는 것

알리바바 클라우드를 써보신 적이 있다면 EBS(블록 스토리지), OSS(오브젝트 스토리지), RDS(관리형 DB), MaxCompute(빅데이터), Hologres(실시간 분석), NAS(파일 스토리지) 같은 서비스 이름이 익숙하실 것입니다. 이들이 바닥에서 어떻게 데이터를 보관하고 있는지 들여다보면, 거의 모두 판구 위에 올라가 있습니다. 사용자에게 직접 노출되는 일은 거의 없지만, 알리바바 클라우드라는 그룹 전체의 '척추' 같은 존재입니다.

내부 구조: 거인의 몸이 세 부분으로 나뉘듯

판구 신화에서 거인의 몸이 산, 강, 별, 바람으로 분해되었듯이, 알리바바 판구의 구조도 세 가지 핵심 컴포넌트로 명확히 분리되어 있습니다.

STEP 01
Client · 두뇌 역할

사용자 요청을 받아 어디로 보낼지 판단합니다. 파일을 어디서 읽고 어디에 쓸지를 결정하고, 재시도까지 직접 챙기는 '무거운(heavyweight) 클라이언트'입니다. 메타데이터 캐시를 로컬에 보관해 마스터에 매번 묻지 않아도 되도록 설계되어 있습니다.

STEP 02
Master / MetaServer · 척추 역할

파일 디렉토리 트리, 청크 위치, 데이터 배치 정책 같은 메타데이터를 관리합니다. 1.0 시절에는 단일 마스터에 부하가 몰려 한계가 있었지만, 2.0부터는 메타서버를 수평으로 쪼개고 RAFT 합의 알고리즘으로 묶어 한 군데가 죽어도 전체가 멈추지 않게 만들었습니다.

STEP 03
ChunkServer · 몸체 역할

실제 데이터를 청크 단위로 보관합니다. 일반 파일시스템 위에 그냥 얹는 게 아니라, USSFS라는 자체 사용자 공간 파일시스템을 만들어 SSD/NVMe에 직접 최적화했습니다. 일반 OS 파일시스템의 오버헤드를 걷어내는 설계입니다.

이 구조를 보고 흥미로웠던 점은, 메타와 데이터를 분리한 것 자체는 흔한 발상이지만 클라이언트에 '판단'을 위임한 부분입니다. 페이스북 Tectonic 파일시스템과 비슷한 철학으로, 마스터는 메타만 가볍게 다루고 무거운 결정은 클라이언트가 직접 내리도록 분산시켜 마스터 병목을 줄였습니다. 신화에 비유하자면, 거인이 하늘을 직접 떠받치지 않고 사방의 기둥에 일을 맡긴 셈입니다.

1.0에서 2.0으로: 안정적으로 살아남은 비결

판구 1.0은 2008년에서 2009년 무렵 Apsara 운영체제와 함께 시작되어 HDFS와 유사한 구조로 출발했습니다. 하드디스크 기반, 만 단위 노드, 3-카피 복제. 그 시절 기준으로는 충분했지만, NVMe SSD가 대중화되고 RDMA가 데이터센터에 깔리기 시작하면서 1.0 구조의 한계가 드러났습니다.

2017년 무렵 알리바바는 판구 2.0을 본격 가동했습니다. 흥미로운 점은 한 번에 갈아엎지 않았다는 것입니다. EBS 같은 핵심 서비스에서 단계적으로 3-카피를 EC(Erasure Coding)로 바꿔가며, 트래픽 증폭은 줄이고 저장 비용은 떨어뜨렸습니다. 핵심 수치 몇 가지를 모아보면 변화의 규모가 한눈에 들어옵니다.

~30 μs end-to-end 쓰기 지연
(NVMe + RDMA 기반)
~100 μs 평균 I/O 지연
(컴퓨트-스토리지 분리)
3-카피 → EC 저장 오버헤드 200%
→ 약 25-40%
ms 단위 P999 SLA 보장
(트래픽 폭증 시)

2019년 광군제(双11) 때 RDS에서 읽기 꼬리 지연이 갑자기 튀어 오른 사례가 알리바바가 USENIX FAST '23에 발표한 논문에 자세히 공개되어 있습니다. 청크 2개의 리밸런싱 마이그레이션이 진행되는 동안 나머지 청크를 가진 청크서버에서 장애가 동시에 발생한 것이 원인이었습니다. 이 경험을 토대로 Perseus라는 자체 모니터링 시스템과 자동 진단을 강화해서 같은 패턴이 다시 보이지 않도록 시스템을 다듬었다고 합니다.

결국 판구가 오랫동안 안정적으로 보이는 것은 사고가 한 번도 없어서가 아닙니다. 큰 사고 한 번을 다음 분기 설계에 반영해 굳혀가는 패턴을 10년 넘게 반복해왔기 때문입니다. 거대한 자체 사업(타오바오, 알리페이, 광군제)이 가장 가혹한 부하 테스트 역할을 매년 해주고 있다는 점도 빼놓을 수 없습니다.

인사이트 몇 가지
INSIGHT 01
이름은 전략이다

중국 빅테크들은 핵심 인프라에 판구, 비행천, 쿤붕 같은 신화 이름을 즐겨 붙입니다. 단순한 작명 취향이 아니라 "우리가 만든 것이 토대다"라는 포지셔닝이고, 동시에 내부 엔지니어에게 자부심을 심어주는 장치입니다. 알리바바 판구가 오픈소스가 아닌 자체 라이센스로 유지되어 온 것도 이 맥락과 맞닿아 있습니다.

INSIGHT 02
중국 클라우드는 스토리지를 자체 개발한다

북미 클라우드들이 일부 오픈소스(HDFS, Ceph 등)에서 출발한 것과 달리, 알리바바, 텐센트, 바이두 모두 자체 분산 스토리지를 처음부터 직접 만들었습니다. 무엇보다 광군제처럼 단기간에 트래픽이 폭증하는 자체 사업이 있어 외부 솔루션으로는 SLA를 맞추기 어려웠습니다. 결국 거대한 사내 트래픽이 가장 강한 외부 차별화 기능을 만들어준 셈입니다.

INSIGHT 03
용량이 아니라 성능의 시대로

판구 2.0이 자기들의 표어를 'More than Capacity(용량 그 이상)'으로 잡은 것은 의미심장합니다. 클라우드 스토리지의 경쟁축이 '얼마나 많이 담느냐'에서 '얼마나 빨리 꺼내주느냐'로 옮겨갔다는 신호이고, AI 학습과 추론 워크로드가 늘어나면서 이 흐름은 더 가속화되고 있습니다.

현장 메모 · ODCC 2025

지난해 9월 북경 ODCC(开放数据中心大会)에 嘉宾(VIP 게스트)으로 참석했을 때, 알리바바 클라우드 세션에서 판구 위에 학습 데이터셋과 체크포인트를 올리고 RDMA 네트워크로 GPU 클러스터와 묶는 구조를 직접 들었습니다. 그 자리 분위기를 한 줄로 요약하면, "AI 시대의 스토리지는 더 이상 백엔드가 아니라 학습 파이프라인의 일부다"였습니다. 판구는 더 이상 'EBS의 받침대'가 아니라 'GPU의 옆자리'로 옮겨가고 있는 셈입니다.

정리하며

신화 속 판구는 자기 몸을 분해해 세상을 만들었습니다. 알리바바 판구는 자기 역할을 클라이언트, 메타서버, 청크서버로 분해해 클라우드를 떠받치고 있습니다. 이름 하나에 1만 8천 년의 신화와 10여 년의 엔지니어링이 같이 들어있다는 점이, 중국 클라우드를 들여다볼 때 묘하게 자주 마주치는 풍경입니다.

다음에 알리바바 클라우드 카탈로그에서 'Pangu'라는 단어를 보시면, 그 위에 올라간 모든 서비스가 이 한 층 위에 서 있다는 사실을 잠시 떠올려보시면 좋겠습니다.

NEXT TOPIC · 다음 글 예고
화웨이 판구 모델 5.5: 도끼를 휘두른 거인이 LLM이 되었을 때

같은 이름을 쓰는 화웨이 판구는 스토리지가 아니라 거대언어모델입니다. 256명의 전문가(MoE)로 구성된 718B 파라미터 모델이 어떻게 Ascend 910 칩과 짝을 이루는지, MindSpore 프레임워크 위에서 어떤 식으로 학습되는지, 그리고 한국 반도체 업계가 이 흐름을 어떤 시각으로 봐야 할지 다음 글에서 풀어보겠습니다. 알리바바 판구가 '데이터의 기반'이었다면, 화웨이 판구는 '지능의 기반'이라는 다른 결의 이야기입니다.

#알리바바판구 #Pangu스토리지 #알리바바클라우드 #분산파일시스템 #중국클라우드 #화웨이판구 #클라우드스토리지 #중국신화판구 #AI인프라 #데이터센터스토리지
반응형
LIST