미터링 용량을 세 가지 제약을 함께 놓고 역산한 이유 - 단일 관점만 보면 틀린다

TL;DR
단일 제약(GPU 장비 수)만 보면 인프라가 견딜 수 있는 규모와 시스템이 실제 견딜 수 있는 규모가 다릅니다.
RDS 자동 확장 2TB · 사업 라이프사이클 1년 · GPU 인프라 최종 예상치를 함께 놓고 역산하면 5,000 인스턴스 / 1년 보존 / 2억 건 / 2TB가 의도적으로 수렴합니다.
이 설계는 저장 전략(UPSERT → DELETE+INSERT) 의사결정의 근거이자, MIG 도입 같은 미래 변경 시점을 재검토 트리거로 명시하는 경계가 됩니다.

GPU 클라우드 미터링 시스템을 만들면서 가장 먼저 답해야 했던 질문은 단순했습니다. “어디까지 견뎌야 하나?”

처음에는 인프라 상한, 즉 GPU 장비 수를 기준으로 잡으면 충분하다고 생각했습니다. 하지만 그 가정으로 설계한 수치가 실제 운영에서 의미를 가지려면, 인프라 외 다른 제약이 먼저 병목이 되지 않아야 합니다. 그게 보장되지 않는다는 것을 깨닫고 나서, 단일 제약만 본 설계가 위험하다는 사실을 받아들였습니다.

문제: 단일 제약만 보면 실제 운영 한계가 안 보인다

미터링 시스템의 용량 설계는 보통 다음 중 하나로 시작합니다.

1. 인프라 상한에서 출발 (GPU/노드/CPU 코어 수)
2. 트래픽 예측에서 출발 (TPS, 요청 수, 활성 사용자 수)
3. 데이터 보존 요구에서 출발 (보존 기간, 조회 패턴)

운영하는 환경에서는 1번에서 출발하기 쉬웠습니다. GPU 장비 수가 곧 인스턴스 상한이고, 인스턴스 수가 곧 미터링 데이터의 발생량과 직결되기 때문입니다.

하지만 1번만 보면 두 가지 문제가 생깁니다.

문제 1: 데이터가 적재되는 RDB의 스토리지 상한이 GPU 인프라 상한보다 먼저 도달할 수 있습니다. 당장은 여유가 있어 보여도, 인스턴스가 늘면 누적 레코드가 RDB 자동 확장 한계에 부딪힙니다.

문제 2: 보존 기간이 결정되어야 누적량이 정해지는데, 보존 기간을 무엇에 맞출지가 인프라 관점에서는 보이지 않습니다. “몇 년 치 데이터를 가지고 있어야 하나?”라는 질문에 인프라 상한은 답을 주지 않습니다.

이 두 문제를 동시에 풀려면, 인프라·스토리지·사업 라이프사이클을 같은 축에 놓고 함께 검토해야 했습니다.

분석: 세 가지 제약을 함께 놓고 검토

설계 근거는 세 제약이 동시에 만족되는 지점에서 나왔습니다.

┌─ GPU 인프라 상한 (보유 장비)
│
├─ 스토리지 상한 (RDS 자동 확장 최대치)
│
└─ 사업 라이프사이클 (계약 단위, 보존 기간)

세 제약이 동시에 만족되는 지점이 설계 수치입니다. 제약 중 하나라도 변경되면 그 시점이 재검토 트리거가 됩니다.

제약 1. GPU 인프라 상한

운영 환경의 GPU 인프라 최종 예상치를 이론적 상한으로 잡았습니다. 이 수치는 사업 단계별로 실제 가용 시점과 활용 범위가 달라지기 때문에, 현 시점에서 모두 사용 가능하지는 않습니다.

시점	실제 가용 규모 (1차 단계 기준 환산)
1차 사업 (2025-09 ~ 2025-12 말)	노드 약 29대 × GPU 8장 (= 1차 단계 규모)
2026년 현재 (1.1 버전)	진행 중
최종 예상 (공개 보도 기준)	1차 단계 대비 약 30배 규모

설계는 미래 대비 관점에서 최종 예상치를 기준으로 잡았습니다. 실제 가용은 1차 단계에서 시작했지만, 사업 확장으로 늘어날 인스턴스를 미리 흡수할 수 있는 인프라 상한 가정이 필요했기 때문입니다.

최종 예상치도 그대로 인스턴스 상한이 되지는 않습니다.

• B2B 환경의 워크로드당 GPU 8장 구성이 기본 — 단일 GPU 인스턴스가 아니라 다중 GPU 워크로드가 표준
• 1차 사업 실측 환산: 약 29 인스턴스
• 최종 예상치 환산: 약 957 인스턴스 (1차 대비 약 30배)
• B2C 폭증 가능성 X — GPU 단가 특성상 개인 사용자가 감당하지 않는 시장

즉 인프라 관점에서 이론(최종 예상치) / 미래 환산 약 957 / 현 실측 약 29라는 세 수치가 나오고, 그 사이에서 설계 여유를 어디에 둘지를 정해야 합니다.

제약 2. 스토리지 상한 (RDS 2TB)

미터링 데이터는 사용 중인 관리형 MySQL RDS에 적재됩니다. 이 RDS의 데이터 스토리지는 20GB ~ 2TB 범위이며, 자동 스토리지 확장 기능으로 사용률 임계치 도달 시 설정한 최대 크기까지 자동 확장됩니다.

이 2TB가 설계의 핵심 역산 기준이 되었습니다.

역산 절차:

1. 테이블별 로우당 최대 크기를 DB 스키마와 코드 기준으로 계산
2. (로우당 최대 크기) × (예상 레코드 수) ≤ 2TB가 되는 레코드 상한 도출
3. 레코드 상한을 5분/10분/1일 3단계 파이프라인 × 보존 기간에 대입해 인스턴스 상한을 역산

결과: 인터벌 집계 1년 보존 기준 약 2억 건이 RDS 2TB에 안전하게 수용되는 상한이었습니다.

이 시점에서 한 가지가 분명해졌습니다. GPU 인프라 최종 예상치만 보면 충분히 견딜 것 같지만, 실제로는 RDS 2TB가 먼저 병목이 될 수 있습니다. 인스턴스가 늘면 누적 레코드가 2TB 한계에 도달하고, 그 시점부터는 저장 전략 자체를 재평가해야 하기 때문입니다.

제약 3. 사업 라이프사이클 (1년)

세 번째 제약은 인프라가 아닌 사업 측면입니다.

운영하는 GPU 서비스는 사업 계약 1년 단위가 기본이었습니다. 계약 만료 시 자원이 회수되고, 재계약을 통해 재할당됩니다.

설계 함의:

• 서비스가 수년 이상 누적되는 영속 라이프사이클이 아님
• 사업 단위 라이프사이클 = 1년 보존이 자연스러운 경계
• 영속 서비스라면 “데이터를 계속 쌓아야 하나?”라는 질문이 생기지만, 사업 단위면 1년 후 회수와 함께 과거 데이터의 조회 요구가 사실상 소멸
• 소프트웨어 생명주기(SDLC)와 사업 라이프사이클을 동기화하는 설계

이것이 미터링 보존 기간을 1년으로 확정한 근거였습니다. 스펙 정의에도 “보존 기간이 지난 데이터는 자동으로 삭제”라고 못 박았습니다.

행동: 세 제약이 동시에 만족되는 지점에서 수치를 고정

세 제약을 함께 놓고 도출한 설계 수치는 다음과 같습니다.

항목	값	근거
인스턴스 설계 상한	5,000	최종 예상치 환산(약 957)의 5배+ 여유 + B2B 미래 사용 패턴
인터벌 집계 레코드	5,000 × 144 × 365 ≈ 2.63억	10분 주기 × 1년 보존
보수 표기	1.5배 여유	설계 2억 건의 1.5배(3억)도 RDS 2TB 내 흡수 가능
스토리지 예상	≈ 2TB 언저리	로우당 최대 크기 × 레코드 수 역산

설계의 정교함이 여기서 나옵니다:

• GPU 장비만 봤으면 최종 예상치가 상한이지만, 실제로는 RDS 2TB가 먼저 병목이 될 수 있어 역산이 필요
• 사업 라이프사이클 반영으로 1년 보존이 자연스럽게 결정
• 세 제약이 동시에 충족되는 지점에서 5,000 인스턴스 / 2억 건 / 2TB가 의도적으로 수렴

5,000은 실측이 아니라 설계 가정입니다

여기서 짚어야 할 부분이 있습니다. 5,000 인스턴스는 실측이 아니라 설계 가정입니다.

근거는:

• 공개 보도의 최종 예상치를 기반으로 한 환산 (약 957 인스턴스의 5배+)
• 현재 운영 모델에서 향후 운영 모델로 전환할 경우의 상한 시나리오
• 가능성은 낮지만 대비가 필요한 미래 시점
• 적용 시점은 미정

크게 잡은 의도:

• 변동 흡수: 도입 단계별 인스턴스 변동을 모두 포괄
• 확장 시나리오 대비: 운영 모델이 변경될 때의 상한도 흡수
• 재설계 부담 최소화: 실제 도입 시 인프라 확장에 따른 재설계 비용 절감

즉 5,000은 “확정된 운영 수치”가 아니라 “가능한 최대 시나리오에서의 설계 가정” 입니다. 이 가정 위에서 RDS 2TB · 1년 보존이라는 다른 제약과 함께 검토한 결과가 2억 건입니다.

설계는 보수적일수록 안전하지만, 너무 보수적이면 오버 엔지니어링이 됩니다. 세 가지 제약을 함께 놓고 5,000 / 2억 건 / 2TB가 동시에 충족되는 지점을 찾았기 때문에, 이 수치들이 상호 검증된 합리적 보수입니다. 완전한 가짜는 아니되, 실측보다 상당히 크게 잡혔다는 사실은 정직하게 인정합니다.

이 수치는 다른 의사결정의 근거가 됩니다. 저장 전략을 UPSERT에서 DELETE + INSERT로 전환한 결정도 “이 규모에서는 성능이 결정 변수가 아니다”라는 판단에서 출발했고, 그 판단의 근거가 바로 이 세 제약을 함께 놓고 본 결정이었습니다.

결과: 운영 실측과 설계 가정의 분리

운영 실측 (1차 사업 단계 기준):

• 5분 배치 약 10초 실행, 하루 288회 안정적 운영
• 1차 사업 232 GPU = 약 29 인스턴스 환경에서 검증된 파이프라인 동작
• 1년 보존 자동 삭제 정책 동작

설계 가정 (미래 대비):

• 5,000 인스턴스 / 2억 건 / 1년 보존 / RDS 2TB 한계까지 1.5배 보수 여유
• 5,000은 보도 기준 최종 예상치와 운영 모델 변경 시나리오의 가능한 최대 환산
• 적용 시점은 미정. 사업 단계별로 단계적 도달

명시된 재검토 트리거:

시점	상황	저장 전략
현재	5,000 인스턴스 / 2억 건 / 2TB 내	DELETE+INSERT 유효
MIG 부분 도입	인스턴스 증가, RDS 2TB 병목 근접	재검토 트리거
MIG 전면 도입 / 장기 증설	2TB 초과 예상	저장 전략 + 스토리지 아키텍처 전면 재평가 (파티셔닝 고도화, 샤딩, 외부 저장소)

이 경계는 의사결정의 정직한 부분입니다. 현 설계는 “세 가지 제약이 모두 유효한 기간 동안” 성립하고, 제약 중 하나라도 변경(MIG 확산, RDS 상품 스펙 변경, 사업 라이프사이클 확장)되면 재평가가 필요합니다.

MIG(Multi-Instance GPU)는 단일 GPU를 최대 7개 독립 인스턴스로 분할하는 기술입니다. 최신 GPU 모델을 지원하고, GPU 수익성 개선 목적으로 도입이 검토되고 있습니다. 다만 MIG는 설계 시점의 근거가 아니라 사후 고려 사항이었습니다. 현 설계는 MIG 없는 가정에서 세 가지 제약으로 귀결되었고, MIG 확산은 위 표의 재평가 트리거입니다.

MIG POC를 직접 수행한 경험이 있어 적용 가능성과 한계를 파악하고 있고, 이것이 “MIG 도입 시점이 저장 전략 재평가 트리거”라는 판단을 blind optimism이 아닌 구체적 경계로 만드는 근거가 됩니다.

의의: 한 축이 아닌 여러 축에서 본 설계

이 설계 과정에서 얻은 가장 큰 학습은 다음과 같습니다.

1. 단일 제약(GPU 장비 수)만 본 설계는 실제 운영 한계를 놓칠 수 있다
   • 이론적 상한과 운영 가능 상한은 다름
   • 어떤 제약이 먼저 병목이 되는지를 함께 봐야 의사결정이 정교해짐
2. 사업 라이프사이클을 설계 변수에 넣는다
   • “왜 1년 보존인가?”라는 질문에 원칙 있는 답을 줌
   • SDLC와 사업 라이프사이클의 동기화는 영속 서비스가 아닌 환경에서 자연스러운 경계
3. 재검토 시점을 미리 명시한다
   • 현 설계의 유효 기간을 정직하게 인정
   • MIG·RDS 변경·라이프사이클 확장 등 변경 트리거를 사전에 정의
   • “blind optimism이 아닌 구체적 경계”로서 의사결정의 신뢰성을 확보

같은 시계열 데이터를 다루더라도, 단일 제약 관점에서 5,000을 잡는 것과 세 가지 제약을 함께 놓고 5,000을 잡는 것은 결과 수치는 같아 보여도 의사결정의 깊이가 다릅니다. 면접에서 “이 수치는 어떻게 산정했나요?”라는 질문을 받았을 때, 단일 관점 설계는 한 가지 근거만 제시하지만, 여러 제약을 함께 본 설계는 세 가지 제약을 모두 함께 답할 수 있습니다.

좋은 의사결정은 결과 수치보다 그 수치에 도달한 분석에서 갈린다고 봅니다. 얼마나 많은 제약을 같은 축에서 함께 놓고 보았는가가 설계의 정교함을 결정합니다.

참고 출처

• 사용 중인 관리형 MySQL RDS 공식 가이드 — 데이터 스토리지 20GB ~ 2TB 범위, 자동 확장 기능
• 공개 보도 기준 GPU 인프라 최종 예상치
• 1차 사업 단계 (2025-09 ~ 2025-12 말) 노드 약 29대 × GPU 8장 규모는 운영 실측. 2026년 현재 1.1 버전 진행 중