DEVOCEAN

배치 튜닝을 마치고 GPU 수십 개를 투입해 대규모 언어 모델 학습을 시작했는데 연산 속도가 이상하게 바닥을 칩니다. GPU 유틸리티 그래프를 보면 연산 장치는 놀고 있고 노드 간 데이터 송수신 병목만 가득합니다. 한편에서는 'AI 워크로드 최적화'와 'Full ACID 지원'을 내세운 최신 데이터베이스를 도입해 단일 클라이언트 테스트를 돌렸는데, 데이터베이스가 장애나 충돌도 없는 상태에서 쿼리 결과에 구멍을 내고 트랜잭션 순서를 꼬아버립니다.

AI 시스템 개발자가 프로덕션 현장에서 자주 겪는 파편화된 실패 장면들입니다. 화려한 수치와 AI 최적화라는 마케팅 문구 뒤에는 랙 단위 물리 토폴로지와 동시성 제어라는 고전적인 컴퓨팅 기초가 버티고 있습니다. 최신 인프라 소식 두 가지를 통해 AI 워크로드가 부딪히는 하부 인프라의 진짜 문제와 대응 방안을 살펴보겠습니다.

랙 토폴로지를 무시한 스케줄링은 GPU 연산력을 낭비시킵니다

Grace Blackwell에는 새 스케줄러가 필요하다: 같은 랙에서 사용 가능한 GPU 27% 확대 원문에 따르면, 엔비디아의 NVL72 시스템은 단일 랙 안에서 72개의 GPU를 NVLink로 묶어 고속 통신을 지원합니다. 하지만 대규모 다중 노드 훈련 작업이 여러 랙으로 분산 배치되는 순간, 통신 병목은 NVLink가 아닌 랙 간 통신을 담당하는 인피니밴드(InfiniBand) 구간에서 발생합니다.

원문은 학습 알고리즘에서 사용되는 텐서 병렬화(Tensor Parallelism)와 전문가 병렬화(Expert Parallelism)가 연산 뒤로 통신 시간을 숨기도록 설계되어 있지만, 하드웨어의 물리적 배치가 이를 뒷받침하지 못하면 상위 프레임워크의 최적화 노력이 무용지물이 된다고 지적합니다. 랙 내부 GPU 간 통신 대역폭과 랙 외부 통신 대역폭 사이의 현격한 차이 때문입니다.

그림 1. 랙 내부 NVLink와 랙 간 InfiniBand 통신 구간의 차이

DEVOTEE의 해석을 덧붙이자면, AI 인프라 엔지니어링의 중심이 단순히 'GPU를 몇 개 확보했는가'에서 '스케줄러가 물리적 랙 배치를 얼마나 정교하게 계산하는가'로 옮겨가고 있습니다. 딥러닝 프레임워크 수준에서 아무리 텐서 병렬화 셰이딩을 구현해도, 쿠버네티스나 슬룸(Slurm) 같은 스케줄러가 랙 경계를 무시하고 노드를 무작위로 할당하면 네트워크 대기 시간이 전체 연산 시간을 삼켜버립니다.

실무에서 대규모 GPU 클러스터를 운영한다면 쿠버네티스 기본 스케줄러 대신 랙 토폴로지 인지형(Topology-Aware) 스케줄러 플러그인을 도입해야 합니다. 쿠버네티스 환경에서는 노드의 라벨에 랙 위치 정보를 명시하고 podAffinity와 topologySpreadConstraints를 구성하여 텐서 병렬화 그룹이 동일 랙 내부 NVLink 영역을 벗어나지 않도록 강제할 수 있습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: distributed-training-worker
spec:
  replicas: 8
  template:
    metadata:
      labels:
        app: tensor-parallel-job
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - tensor-parallel-job
            topologyKey: "topology.kubernetes.io/rack"
      containers:
      - name: trainer
        image: pytorch/pytorch:2.4.0-cuda12.4-cudnn9-runtime
        resources:
          limits:
            nvidia.com/gpu: "8"

위 설정은 분산 학습 파드가 동일한 랙(topology.kubernetes.io/rack) 라벨을 가진 노드들에 우선적으로 집적되도록 강제하는 단순 예시입니다. 랙 단위 배치를 고수하면 랙 내 GPU 활용도를 27%까지 끌어올릴 수 있습니다.

Grace Blackwell 스케줄러 도입에 대해 DEVOTEE는 조건부로 유효하다는 판단을 내립니다. NVL72처럼 랙 단위 분산 구조가 극대화된 하드웨어를 직접 소유하거나, 다중 노드 기반 파라미터 병렬화 훈련을 자체 클러스터에서 수행하는 팀에게는 필수 검토 과제입니다. 하지만 클러스터 규모가 단일 노드 수준이거나, 클라우드 제공업체가 완성형으로 제공하는 호스팅 서빙 API만 사용하는 팀이라면 당장 적용할 실익이 적습니다.

Full ACID 표방 뒤에 숨은 96개 정합성 오류: ParticleDB 분석 소식

Jepsen: ParticleDB 1.1.4 - AI용 데이터베이스의 정합성 검증에서 96개 문제 발견 소식은 AI 인프라의 또 다른 축인 데이터베이스 영역에서 충격적인 사실을 보여줍니다. 분산 시스템 정합성 검증 도구인 Jepsen이 AI 워크로드용 데이터베이스를 표방하는 ParticleDB 1.1.4부터 1.1.18.11.rc-22 버전까지 검사한 결과, 무려 96개의 정합성 문제를 찾아냈습니다.

원문에 따르면 발견된 정합성 오류들 중 다수는 네트워크 분할이나 노드 다운 같은 고도의 분산 장애 상황이 아니라, 서버 1대와 클라이언트 1개만 존재하는 무장애 환경에서도 발생했습니다. 제품 설명서에는 "Full ACID 지원"이라고 명시되어 있었지만, 실제 동작에서는 쿼리 결과에 데이터가 누락되거나 동시 트랜잭션 충돌 및 교착 상태가 제대로 처리되지 않은 채 잘못된 SQL 결과가 반환되었습니다.

DEVOTEE의 해석으로는, 최근 AI 열풍을 타고 급조된 'AI 최적화 DB' 또는 'AI 전용 벡터/트랜잭션 데이터베이스' 상당수가 고전적인 데이터베이스 엔지니어링의 정밀한 동시성 제어 검증을 건너뛰었을 가능성을 시사합니다. 트랜잭션 격리 수준(Isolation Level)과 MVCC(Multi-Version Concurrency Control)를 정합성 테스트 없이 서둘러 구현하다 보니, 부하가 없는 최선의 조건에서조차 기본 ACID 약속이 깨지는 것입니다.

실무 데이터베이스를 선택할 때 'AI 최적화'나 'Full ACID Support'라는 마케팅 문구만 믿고 검증되지 않은 신생 DB를 메인 트랜잭션 저장소로 채택하는 판단은 보류해야 합니다. 데이터베이스 정합성이 무너지면 애플리케이션 레이어에서 이를 보정하기 위해 수십 배의 공수가 들어갑니다.

데이터베이스 정합성을 검증하기 위해서는 원문의 Jepsen처럼 클러스터 상태 변경 및 동시 트랜잭션 수행 시 직렬 가능성(Serializability)이 유지되는지 체크하는 통합 테스트를 직접 돌려봐야 합니다. 간단하게는 Node.js 환경에서 동시성 충돌을 일으키는 인메모리 트랜잭션 테스트 스크립트를 만들어 데이터 유실 여부를 검증할 수 있습니다.

import { Client } from 'pg';

interface AccountBalance {
  id: number;
  balance: number;
}

async function verifyStrictConcurrency(connectionString: string): Promise<void> {
  const clientA = new Client({ connectionString });
  const clientB = new Client({ connectionString });

  await clientA.connect();
  await clientB.connect();

  try {
    await clientA.query('BEGIN ISOLATION LEVEL SERIALIZABLE');
    await clientB.query('BEGIN ISOLATION LEVEL SERIALIZABLE');

    const resA = await clientA.query<AccountBalance>('SELECT balance FROM accounts WHERE id = $1', [1]);
    const currentBalance = resA.rows[0].balance;

    await clientA.query('UPDATE accounts SET balance = $1 WHERE id = $2', [currentBalance + 100, 1]);
    await clientB.query('UPDATE accounts SET balance = $1 WHERE id = $2', [currentBalance + 200, 1]);

    await clientA.query('COMMIT');
    
    // Strict Serializable 환경에서는 clientB의 커밋이 실패하거나 직렬화 오류를 반환해야 함
    await clientB.query('COMMIT');
    console.warn('경고: 동시 트랜잭션 직렬화 오류가 발생하지 않았습니다. 격리 수준을 재점검하세요.');
  } catch (error) {
    console.log('정상 동작: 직렬화 충돌이 올바르게 감지되어 트랜잭션이 롤백되었습니다.', (error as Error).message);
    await clientA.query('ROLLBACK').catch(() => {});
    await clientB.query('ROLLBACK').catch(() => {});
  } finally {
    await clientA.end();
    await clientB.end();
  }
}

이 테스트 코드는 동일한 행에 대해 두 개의 직렬화 가능 트랜잭션이 동시 쓰기를 시도할 때 데이터베이스가 충돌을 정확히 감지하고 하나를 롤백시키는지 확인하는 최소한의 검증 로직입니다. ParticleDB 사례처럼 단일 클라이언트에서도 결과가 꼬이는 시스템이라면 이러한 기본 트랜잭션 테스트조차 통과하지 못합니다.

ParticleDB의 Jepsen 검증 결과에 대해 DEVOTEE는 과대평가된 면이 있다고 판단합니다. 'AI 최적화' 타이틀을 달았다고 해서 40년 이상 검증되어 온 PostgreSQL이나 MySQL 수준의 정합성을 보장한다고 착각해서는 안 됩니다. 데이터의 완전성이 중요한 서비스에서는 검증된 데이터베이스 엔진을 기본 트랜잭션 저장소로 두고, AI 검색용 벡터 인덱스는 보조 데이터 저장소로 분리하는 아키텍처 패턴이 여전히 안전합니다.

물리 배치와 트랜잭션 검증: AI 인프라 구축의 기본 실무

앞서 다룬 소식 두 가지는 전혀 다른 계층의 이야기처럼 보이지만 실상은 하나의 결론을 가리킵니다. AI 추론 및 학습 인프라 구축 시 '상위 수준의 화려한 기능'보다 '하부 레이어의 정밀한 검증'이 전체 시스템 안정성과 성능을 결정한다는 점입니다.

실무 개발자가 당장 적용할 수 있는 아키텍처 점검 포인트는 다음과 같습니다.

단일 동시성 모델은 하드웨어 토폴로지와 결합될 때만 제 성능을 발휘합니다. GPU 인프라를 확장할 때 단순히 카드 수를 늘리는 데 집중하지 말고, 랙 내부 통신(NVLink)과 랙 간 통신(InfiniBand)의 경로가 스케줄러 정책에 반영되었는지 점검해야 합니다.

과금 방식이나 처리 속도 향상 문구에 혹해 데이터베이스를 교체할 때는 반드시 Jepsen 분석 보고서나 독립적인 동시성 검증 결과가 존재하는지 확인해야 합니다. "Full ACID"라는 서술을 믿기 전에 최소한 단일 노드 다중 스레드 환경에서 데이터 누락 및 SQL 직렬성 검증을 직접 수행하는 프로세스를 팀 내에 구축하는 것이 바람직합니다.

직접 해 볼 수 있는 한 가지

운영 중이거나 도입을 검토 중인 데이터베이스 및 AI 벡터 저장소를 대상으로, 오늘 당장 단일 노드 기반의 동시성 경합 테스트 스크립트를 작성해 실행해 보세요.

동일 식별자를 가진 1,000개의 레코드에 대해 10개의 비동기 클라이언트 루프가 동시에 무작위 읽기 및 쓰기 트랜잭션을 5분간 수행하도록 만드는 것입니다. 작업 완료 후 최종 수량 및 상태 값이 모든 클라이언트의 트랜잭션 이력 합계와 정확히 일치하는지 확인하는 것만으로도, 해당 DB가 기본적인 동시성 정합성을 지키고 있는지 일차적으로 검증할 수 있습니다.

그 밖의 소식

• CJ대한통운 해외 IDC의 AWS 전환기 2편: 컷오버와 안정화: 해외 거점 IDC 마이그레이션의 최종 컷오버 과정과 안정화 단계를 정리한 사례 공유 글입니다.