완벽한 설계는 없다: 엔비디아 GB10 메모리 구조에서 배우는 트레이드오프의 미학

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

최근 우리 팀은 새로운 AI 모델 서빙 구조를 설계하며 큰 난관에 부딪혔습니다. 처리 속도는 높이면서 비용은 낮추고, 동시에 확장성까지 확보하려다 보니 어느 하나 제대로 잡히지 않는 '이도 저도 아닌' 상태가 되어버렸기 때문입니다. 모든 지표를 완벽하게 만족시키려는 욕심이 오히려 독이 된 셈이죠. 밤새 아키텍처 다이어그램을 수정하며 머리를 싸매던 중, 우연히 접한 엔비디아(Nvidia)와 미디어텍(Mediatek)의 합작품인 'GB10'의 메모리 서브시스템 분석 기사는 제게 큰 위로와 동시에 날카로운 통찰을 주었습니다. 오늘은 이 하드웨어의 설계 방식이 우리 소프트웨어 엔지니어들에게 어떤 시사점을 주는지 이야기해보려 합니다.

GB10은 엔비디아의 블랙웰(Blackwell) GPU와 Arm의 고성능 CPU 코어(Cortex X925, A725)를 결합한 괴물 같은 칩입니다. 언뜻 보면 모든 스펙이 최상급일 것 같지만, CPU 측면의 메모리 구조를 뜯어보면 의외로 냉철한 '타협'의 흔적이 보입니다.

가장 눈에 띄는 점은 캐시 메모리 설계입니다. 효율 코어인 A725의 L2 캐시 용량은 512KB에 불과합니다. 게다가 L3 캐시의 지연 시간(latency)은 21ns 이상으로 꽤 느린 편이죠. 솔직히 말해, 처음 이 수치를 봤을 때는 고개를 갸웃했습니다. "최고의 칩이라면서 왜 이렇게 느리게 만들었지?"라는 의문이 들었거든요. 하지만 그 이면을 들여다보면 명확한 의도가 보입니다. A725의 L2 캐시를 줄인 것은 코어 면적을 아껴 칩 하나에 더 많은 코어를 집어넣기 위함이었습니다. 단일 스레드 성능이 중요한 작업은 고성능 코어인 X925에게 맡기고, A725는 집적도를 높이는 쪽으로 역할을 확실히 나눈 것입니다.

더 흥미로운 것은 클러스터 구성의 비대칭성입니다. GB10의 CPU는 두 개의 클러스터로 나뉘는데, 첫 번째 클러스터는 8MB L3 캐시를, 두 번째 클러스터는 16MB L3 캐시를 가집니다. 대역폭 역시 두 번째 클러스터가 훨씬 넓습니다. 우리는 흔히 시스템을 설계할 때 '통일성'에 집착하곤 합니다. 모든 서버가 같은 스펙이어야 하고, 모든 코드가 같은 패턴이어야 마음이 편하죠. 하지만 GB10은 한쪽은 '밀도(Density)'를, 다른 한쪽은 '성능(Performance)'을 선택했습니다. 면적이라는 한정된 리소스 안에서 최적의 효율을 내기 위한 과감한 결단입니다.

이러한 하드웨어 설계는 우리 소프트웨어 개발 문화에도 시사하는 바가 큽니다. 저는 과거에 모든 마이크로서비스가 10ms 이내의 응답 속도를 보장해야 한다는 강박에 시달린 적이 있습니다. 결과적으로 불필요한 캐싱 레이어를 덕지덕지 붙이다가 정합성 문제만 일으키고 실패했었죠. GB10이 보여주듯, 모든 컴포넌트가 '주인공'일 필요는 없습니다. 어떤 서비스는 빠릿한 응답 속도가 생명이고, 어떤 서비스는 대량의 데이터를 묵묵히 처리하는 처리량이 더 중요합니다. 각자의 역할에 맞게 리소스를 비대칭적으로 분배하는 것이야말로 시니어 엔지니어가 갖춰야 할 안목입니다.

또한 GB10은 CPU와 GPU 사이의 데이터 교환을 위해 시스템 레벨 캐시(SLC)를 활용합니다. CPU 자체의 L3 성능이 다소 희생되더라도, 전체 칩 차원에서 전력 효율적인 데이터 공유가 가능하다면 그것을 택한 것입니다. 부분의 최적화보다 전체 시스템의 흐름을 우선시한 결과입니다. 저 역시 팀원들에게 항상 강조합니다. "내 코드의 퍼포먼스도 중요하지만, 전체 트랜잭션의 병목이 어디인지 먼저 보라"고 말이죠.

물론 GB10의 LPDDR5X 기반 DRAM 지연 시간이 113ns 수준으로 매우 훌륭하다는 점은 놓치면 안 될 포인트입니다. 트레이드오프를 하더라도, 사용자 경험에 직결되는 핵심 성능(여기서는 메모리 반응성)은 타협하지 않았다는 뜻입니다.

막막했던 프로젝트 회의로 돌아가, 저는 팀원들에게 "완벽함을 포기하자"고 제안했습니다. 대신 우리가 진짜 집중해야 할 'X925' 같은 핵심 기능이 무엇인지, 그리고 조금 희생해도 되는 'A725' 같은 영역은 어디인지 구분하기 시작했습니다. 그러자 복잡하게 꼬여있던 아키텍처가 비로소 단순해지더군요.

엔지니어링은 결국 제약 조건과의 싸움입니다. 무한한 자원과 시간이 있다면 누구나 좋은 시스템을 만들 수 있습니다. 하지만 한정된 리소스 안에서 무엇을 취하고 무엇을 버릴지 결정하는 그 치열한 고민 속에 진짜 기술력이 싹틉니다. 지금 여러분이 마주한 기술적 난제 앞에서, 너무 완벽해지려 애쓰지 마세요. 엔비디아조차도 모든 것을 다 가질 수는 없었으니까요. 중요한 건 '무엇을 위해' 포기하느냐입니다.