사막 한가운데서 조개껍데기를 찾다 — 사우디 데이터센터에서 AI 학습이 멈춘 사연

사막에서 조개를 찾았다는 게 무슨 말이냐면

제목만 보면 무슨 시 같지만, 이건 한 엔지니어가 사우디아라비아 사막 한가운데에 있는 데이터센터에서 대규모 AI 학습 잡(job)을 돌리다가, 어느 날 GPU가 갑자기 모자라기 시작한 미스터리를 추적해 들어간 이야기예요. 결국 그가 찾아낸 "범인"이 너무 의외라서, 코드의 어딘가 깊숙한 곳에 박힌 조개껍데기에 비유한 거죠. 이 글이 흥미로운 건 단순 디버깅 무용담이 아니라, 현대 AI 인프라가 얼마나 거대한 추상 위에 쌓여 있고, 그 추상이 무너졌을 때 추적하는 게 얼마나 어려운지 를 한 편의 추리극처럼 보여줘서예요.

발단 — "왜 학습이 점점 느려지지?"

그는 수백 장의 H100 GPU 클러스터에서 LLM 파인튜닝을 돌리고 있었어요. 잘 돌아가다가 며칠이 지나면 어느 순간부터 학습 속도가 떨어지고, GPU 사용률이 출렁이며, 어떤 노드는 통째로 응답이 끊기는 일이 생겼습니다. 일반적인 분산 학습에서는 노드 한두 개가 멈춰도 다른 노드들이 다음 step을 기다리느라 전체가 늦어지는 "스트래글러(straggler)" 현상이 생기는데, 그 양상이 평소와 좀 달랐어요. 처음엔 네트워크나 NVLink, InfiniBand 쪽 문제를 의심하면서 흔히 보는 곳들을 다 뒤졌다고 합니다.

추적 — 추상의 층을 한 칸씩 벗기기

현대 GPU 학습은 정말 양파처럼 층이 많아요. PyTorch가 가장 위에 있고, 그 아래에 NCCL(노드 간 통신 라이브러리), CUDA, GPU 드라이버, 펌웨어, 다시 그 아래에 RDMA를 통한 InfiniBand, 그리고 데이터센터 차원의 토폴로지(스파인-리프 스위치, 케이블링)가 있어요. 어디에서 병목이 생기든 위쪽 레이어에서는 "그냥 GPU가 한가해진 것"처럼 보이는 거죠. 그는 nvidia-smi로 GPU 활용률을 보고, NCCL의 디버그 로그를 켜고, dmesg에서 커널 에러를 뒤지고, perf로 CPU 프로파일까지 떴어요. 그러다 "all-reduce 통신 시간이 특정 노드에서 비정상적으로 길게 잡힌다"는 패턴을 발견합니다. all-reduce가 뭐냐면, 여러 GPU가 각자 계산한 그래디언트(모델이 얼마나 틀렸는지를 알려주는 값)를 서로 합쳐서 평균 내는 연산이에요. 모든 GPU가 같은 결과를 가져야 다음 step으로 갈 수 있어서, 한 곳이 늦으면 모두가 기다립니다.

진짜 범인 — 의외의 "조개껍데기"

그가 결국 도달한 결론은 단순한 코드 버그가 아니었어요. 글에서 그는 문제의 근원을 하드웨어와 소프트웨어 경계 어딘가에 숨어 있던, 누구도 의심하지 않은 작은 비정상 상태 로 묘사합니다. 특정 GPU의 ECC 메모리 오류, 또는 InfiniBand 케이블의 미세한 결함, 또는 펌웨어 버전이 미묘하게 안 맞아서 생기는 RDMA 처리 지연 같은 것들이요. 핵심은 그게 항상 발생하지 않고, 특정 패턴의 통신이 들어올 때만 살짝 늦어진다는 점이에요. 그 작은 지연이 동기화 연산을 통해 수백 노드의 학습 step 전체를 끌어내리고, 결과적으로 "수억 원짜리 클러스터가 절반의 효율로 돌아가는" 상황을 만들어냅니다.

그가 비유한 "사막의 조개껍데기"는 그래서 의미심장해요. 원래 그 자리에 있을 리 없는 작은 흔적인데, 그것이 거기 있다는 사실 자체가 과거의 어떤 사건(잘못된 펌웨어, 빠뜨린 검수, 출고 시점의 작은 결함)을 가리키는 화석 같은 단서거든요. 코드는 멀쩡한데, 하드웨어와 펌웨어의 작은 흔적이 모든 걸 망치고 있었다는 거죠.

왜 이 이야기가 지금 의미가 있을까

2025~2026년의 AI 인프라는 "수천 장 GPU 클러스터를 한 덩어리처럼 돌린다"는 가정 위에 서 있어요. 메타가 24,000장 H100 클러스터에서 Llama를 학습시키며 발표한 보고서를 보면, 수 시간에 한 번꼴로 하드웨어 장애가 발생하고, 그중 절반 이상이 GPU 자체 문제라고 합니다. 즉 이런 "조개껍데기"는 사실 이상한 게 아니라 새로운 정상(new normal) 이에요. 그래서 요즘 AI 인프라 팀들은 (1) 결함 노드를 빨리 격리하는 헬스체크, (2) 학습 잡 자체에 체크포인트와 자동 재시작을 깊게 내장하는 elastic training, (3) 통신 패턴의 outlier를 실시간으로 잡아내는 텔레메트리에 어마어마한 공을 들이고 있습니다.

경쟁 진영을 보면, NVIDIA는 NCCL과 DCGM, NVSwitch 진단 도구를 강화하고 있고, AWS는 Trainium 클러스터에 자체 헬스체크를 깊게 박았으며, 구글 TPU는 아예 "네트워크 결함을 미리 예측해서 회피 라우팅한다"는 방향으로 갔어요. 결국 모두가 같은 문제를 풀고 있는 거예요. "빠른 한 칩" 보다 "느려지지 않는 거대한 시스템" 이 더 중요해진 시대인 거죠.

한국 개발자에게 주는 의미

국내에서도 LLM이나 대형 모델을 직접 학습/파인튜닝하는 팀이 빠르게 늘고 있어요. 네이버, 카카오, LG, 통신사들의 자체 모델뿐 아니라 스타트업들도 H100/H200 임대 GPU 클러스터에서 수십~수백 장 단위 학습을 돌리는 게 흔해졌습니다. 이 글이 던지는 메시지는 분명해요. "잘 돌아가는 것 같다"와 "정말 잘 돌아간다" 사이에는 거대한 간극이 있다. GPU 사용률 50%로 며칠을 더 돌리는 비용이, 잡 시작 전에 헬스체크 한 시간 돌리는 비용보다 훨씬 비쌉니다.

실무적으로 챙겨볼 만한 것들은 (1) 클러스터를 빌릴 때 벤더에게 NCCL 벤치마크와 ib_send_bw 같은 기본 진단 리포트를 요청하기, (2) 학습 시작 직후 small all-reduce 테스트를 자동으로 돌리고 outlier 노드를 빼기, (3) PyTorch elastic이나 torchrun --rdzv\_backend를 활용해 노드가 죽었을 때 자동 복구되도록 만들기, (4) 텔레메트리로 step time 분포를 지속 모니터링하기 같은 것들이에요.

마무리

한 줄로 정리하면 "대규모 AI 학습에서 가장 비싼 비용은 GPU가 아니라, 보이지 않는 곳에서 효율을 갉아먹는 작은 결함을 찾지 못한 시간이다" 라는 이야기예요. 사막에서 조개껍데기를 발견하는 것 같은 황당한 순간이, 사실은 가장 흔한 디버깅 풍경이 되고 있죠. 여러분 팀에서 GPU 클러스터(혹은 큰 분산 시스템)를 운영해본 경험이 있다면, 가장 의외의 곳에서 찾아낸 "조개껍데기"는 무엇이었는지 한번 공유해 보면 좋겠어요.