다음 세대의 클라우드 추상화가 더 큰 데이터 센터가 아니라, 모든 AI 워크로드(workload)를 사용 가능한 최적의 컴퓨트로 라우팅할 수 있는 지능형 패브릭(fabric)이라면 어떨까요?

탈중앙화된 GPU 이야기는 이전에도 많이 다뤄졌습니다.

마켓플레이스를 만듭니다.

GPU를 등록합니다.

구매자와 공급자를 매칭합니다.

결제 기능을 추가합니다.

아마 토큰을 추가할 수도 있겠죠.

하지만 그것은 흥미로운 엔지니어링 문제가 아닙니다.

진짜 어려운 문제는 다음과 같습니다:

수천 또는 수백만 개의 이기종(heterogeneous) GPU를 어떻게 하나의 프로그래밍 가능한 AI 실행 계층(execution layer)처럼 동작하게 만들 것인가?

이를 위해서는 마켓플레이스 그 이상의 것이 필요합니다.

**런타임(runtime), 스케줄러(scheduler), 신뢰 시스템(trust system), 검증 계층(verification layer), 그리고 경제적 프로토콜(economic protocol)**이 필요합니다.

이 글은 바로 그것을 구축하기 위한 기술적 아키텍처를 제안합니다.

1. 핵심 추상화 (The Core Abstraction)

근본적인 추상화는 다음과 같아서는 안 됩니다:

GPU → 대여 (Rental)

다음과 같아야 합니다:

AI 의도 (Intent) → 최적의 컴퓨트 (Optimal Compute) → 검증된 결과 (Verified Result)

개발자는 요구 사항을 지정합니다:

result = fabric.infer(
    model="llama-70b",
    input=request,
...

개발자는 다음 사항을 지정하지 않습니다:

• GPU 모델
• 공급자 (provider)
• 지역 (region)
• IP 주소
• 드라이버 버전
• CUDA 버전
• 큐 (queue)
• 배포 메커니즘 (deployment mechanism)

패브릭이 이를 자동으로 결정합니다.

이것이 핵심적인 아키텍처의 전환입니다.

2. 상위 수준 아키텍처 (High-Level Architecture)

시스템은 7개의 계층으로 나눌 수 있습니다:

┌─────────────────────────────────────────────┐
│              AI APPLICATIONS                │
├─────────────────────────────────────────────┤
...

각 계층은 서로 다른 문제를 해결합니다.

3. 노드 아키텍처 (Node Architecture)

모든 컴퓨트 공급자는 경량 에이전트를 실행합니다.

이를 다음과 같이 부릅니다:

Fabric Node Agent

그 책임은 다음과 같습니다:

• GPU 발견 (discovery)
• 기능 보고 (capability reporting)
• 상태 모니터링 (health monitoring)
• 워크로드 실행 (workload execution)
• 샌드박싱 (sandboxing)
• 텔레메트리 (telemetry)
• 결과 제출 (result submission)
• 암호화된 신원 (cryptographic identity)
• 리소스 회계 (resource accounting)

노드는 다음과 같이 광고할 수 있습니다:

{
  "node_id": "node_8f29",
  "gpu": {
...

하지만 정적 메타데이터만으로는 충분하지 않습니다.

스케줄러에는 **관측된 성능 (observed performance)**이 필요합니다.

4. 역량은 성능이 아니다

두 대의 RTX 4090 머신은 매우 다르게 동작할 수 있습니다.

한 대는 다음과 같을 수 있습니다:

우수한 냉각 (Excellent cooling)
빠른 NVMe
낮은 지연 시간 (Low latency)
...

다른 한 대는 다음과 같을 수 있습니다:

서멀 스로틀링 (Thermal throttling)
느린 스토리지
불안정한 연결
...

따라서 네트워크에는 두 가지 별개의 개념이 필요합니다:

역량 (Capability)

노드가 자신이 할 수 있다고 주장하는 것.

평판 (Reputation)

노드가 실제로 입증한 것.

이러한 구분이 근간이 됩니다.

5. GPU 평판 그래프 (The GPU Reputation Graph)

단순히 다음과 같은 점수를 사용하는 대신:

노드 평판 = 97/100

다차원적인 평판 프로필을 구축하십시오.

예를 들어:

노드 A

가용성 (Availability)        99.7%
...

이제 스케줄러는 노드에 대해 추론할 수 있습니다.

노드는 단순히 다음과 같지 않습니다:

“좋음.”

노드는 다음과 같습니다:

“이러한 유형의 워크로드 (workload)에 좋음.”

이러한 구분은 매우 중요합니다.

6. 워크로드 지문 (Workload Fingerprints)

모든 추론 (inference) 요청은 워크로드 지문을 생성해야 합니다.

예를 들어:

모델 (Model):
Llama-70B

...

그러면 스케줄러는 해당 지문을 과거의 실행 기록과 비교할 수 있습니다.

시간이 흐름에 따라:

워크로드 지문 (Workload Fingerprint)
        ↓
과거 성능 (Historical Performance)
...

이것이 첫 번째 주요 데이터 해자 (data moat)를 형성합니다.

7. 스케줄러 (The Scheduler)

스케줄러는 시스템의 심장입니다.

단순한 스케줄러는 다음과 같이 선택할 것입니다:

가장 저렴한 GPU

약간 더 나은 스케줄러는 다음과 같이 선택합니다:

가장 빠른 GPU

프로덕션급 스케줄러는 여러 변수를 동시에 최적화해야 합니다.

개념적으로는 다음과 같습니다:

Score(node) =
    w1 × latency_score
  + w2 × reliability_score
...

다음과 같은 엄격한 제약 조건 (hard constraints)을 따릅니다:

지연 시간 (latency) ≤ 요청된 제한 (requested_limit)
비용 (cost) ≤ 예산 (budget)
개인정보 보호 (privacy) ≥ 요구 수준 (required_level)
...

이것은 제약 조건이 있는 최적화 문제 (constrained optimization problem)가 됩니다.

8. 예측 스케줄링 (Predictive Scheduling)

스케줄러는 다음과 같이 물어서는 안 됩니다:

“지금 당장 어떤 노드가 가장 빠른가?”

스케줄러는 다음과 같이 물어야 합니다:

“실행되는 동안 최적의 상태를 유지할 가능성이 높은 노드는 무엇인가?”

가정해 봅시다:

노드 A
현재 지연 시간: 35ms
큐 (Queue): 낮음
...

노드 A가 더 좋아 보일 수 있습니다.

하지만 과거 데이터가 향후 몇 분 동안 노드 A가 빈번하게 연결이 끊어질 것임을 보여준다면, 노드 B가 실제로 최적의 선택일 수 있습니다.

따라서:

현재 상태 (Current State)
      +
과거 상태 (Historical State)
...

이것이 바로 머신러닝 (Machine Learning)이 궁극적으로 스케줄러 (Scheduler)를 개선할 수 있는 지점입니다.

9. 2단계 스케줄링 (Two-Stage Scheduling)

실제적인 구현에서는 모든 요청에 대해 모든 GPU를 평가하는 것을 피해야 합니다.

대신 다음과 같이 수행합니다:

1단계 — 후보 필터링 (Stage 1 — Candidate Filtering)

1,000,000개 노드
       ↓
역량 필터 (Capability filter)
...

2단계 — 지능적 순위 지정 (Stage 2 — Intelligent Ranking)

1,000개 후보
       ↓
성능 예측 (Performance prediction)
...

그 다음 선택합니다:

주요 (Primary)
백업 (Backup)
폴백 (Fallback)

이러한 방식은 대규모 스케줄링을 계산적으로 실행 가능하게(computationally feasible) 만듭니다.

10. 3배의 컴퓨팅 낭비 없는 중복성 (Redundancy Without Wasting 3× Compute)

단순한 설계는 모든 요청을 세 개의 GPU에서 실행할 수도 있습니다.

그것은 비용이 많이 듭니다.

대신, 중복성 (Redundancy)은 적응형(adaptive)이어야 합니다.

예를 들어:

저위험 워크로드 (Low-risk workload)
→ 1개 노드

...

네트워크는 필요한 중복성을 동적으로 결정할 수 있습니다.

이것은 경제적 최적화 (Economic optimization)가 중요한 또 다른 지점입니다.

11. 보안 실행 (Secure Execution)

탈중앙화 컴퓨팅 (Decentralized compute)의 가장 큰 장애물은 하드웨어가 아닙니다.

그것은 신뢰 (Trust)입니다.

개발자는 사실상 다음과 같이 말하고 있는 것입니다:

“내가 제어하지 않는 머신에 내 연산을 보낼 것이다.”

이는 여러 가지 문제를 야기합니다:

• 데이터 노출 (Data exposure)
• 악의적인 노드 (Malicious nodes)
• 모델 도난 (Model theft)
• 결과 조작 (Result manipulation)
• 프롬프트 유출 (Prompt leakage)
• 멀웨어 (Malware)
• 사이드 채널 공격 (Side-channel attacks)

따라서 런타임 (Runtime)에는 계층화된 보안이 필요합니다.

12. 데이터는 자동으로 장치를 떠나서는 안 된다 (Data Should Not Automatically Leave the Device)

가장 강력한 아키텍처는 다음과 같습니다:

사용자 장치 (User Device)
     ↓
개인정보 보호 정책 (Privacy Policy)
...

이는 **로컬 우선 추론 모델 (Local-first inference model)**을 생성합니다.

민감한 워크로드의 경우, 스케줄러는 다음과 같은 조건을 요구할 수 있습니다:

privacy = "trusted-only"

또는:

privacy = "TEE-required"

또는:

privacy = "local-only"

스케줄러는 정책을 인식(policy-aware)하게 됩니다.

13. 기밀 컴퓨팅 (Confidential Computing)

더 높은 보안이 필요한 워크로드의 경우, 지원되는 환경에서는 신뢰 실행 환경 (Trusted Execution Environments, TEE)을 사용할 수 있습니다.

아키텍처는 다음과 같습니다:

암호화된 입력 (Encrypted Input)
      ↓
신뢰 실행 환경 (Trusted Execution Environment)
...

공급자(Provider)는 하드웨어를 운영합니다.

하지만 실행 환경은 호스트가 무엇을 관찰할 수 있는지에 대해 더 강력한 보장을 제공합니다.

이것이 모든 보안 문제를 해결하는 것은 아니지만, 분산 실행 (Distributed Execution)에 적합한 워크로드의 범위를 크게 확장할 수 있습니다.

14. 결과 검증 (Result Verification)

탈중앙화 네트워크는 단순히 다음과 같은 상황을 신뢰할 수 없습니다:

노드(Node) → "여기 결과가 있습니다."

노드는 다음과 같은 행위를 할 수 있습니다:

• 쓰레기 값 (Garbage) 반환
• 계산 생략
• 오래된 출력값 재사용 (Replay)
• 결과 조작

따라서 검증 (Verification)이 필요합니다.

계층적 검증 모델은 다음과 같을 수 있습니다:

실행 (Execution)
   ↓
기본 검증 (Basic validation)
...

모든 워크로드가 동일한 검증 비용을 필요로 하지는 않습니다.

다시 강조하자면:

검증은 리스크에 비례해야 합니다.

15. 확률적 검증 (Probabilistic Verification)

한 노드가 가치가 낮은 10,000개의 추론 (Inference) 요청을 처리한다고 가정해 봅시다.

모든 요청을 두 번씩 실행하는 것은 비용을 두 배로 만듭니다.

대신 다음과 같이 수행합니다:

99%의 요청
→ 일반 실행 (Normal execution)

...

만약 공급자가 의심스러운 결과를 생성하기 시작하면:

검증률 (Verification rate)
1%
 ↓
...

시스템은 효과적으로 격리 (Quarantine) 모드에 진입합니다.

이는 적응형 신뢰 메커니즘 (Adaptive trust mechanism)을 생성합니다.

16. 평판은 경제적으로 의미가 있어야 한다 (Reputation Must Be Economically Meaningful)

공급자는 단순히 배지를 받는 것에 그쳐서는 안 됩니다.

평판은 경제적 요소에 영향을 미쳐야 합니다.

예를 들어:

높은 평판 (High reputation)
→ 더 가치 있는 워크로드
→ 더 높은 가동률 (Utilization)
...

이는 다음과 같은 피드백 루프를 생성합니다:

선량한 행동 (Good behavior)
   ↓
더 나은 평판 (Better reputation)
...

이는 단순히 토큰을 추가하는 것보다 더 강력합니다.

17. 토큰이 나중에 도입되어야 하는 이유 (Why the Token Should Come Later)

토큰 우선 아키텍처는 위험한 인센티브를 만듭니다:

토큰 가격 (Token price)
    ↓
투기 (Speculation)
...

유틸리티 우선 아키텍처가 더 건강합니다:

실제 워크로드 (Real workloads)
    ↓
실제 컴퓨팅 (Real compute)
...

네트워크가 실제 경제 활동을 입증한 후에야 토큰이 진지하게 관련될 수 있습니다.

잠재적인 미래 용도에는 다음과 같은 것들이 포함될 수 있습니다:

• 스테이킹 (staking)
• 거버넌스 (governance)
• 평판 담보 (reputation collateral)
• 리소스 예약 (resource reservation)
• 우선 접근권 (priority access)

하지만 네트워크는 투기 없이 작동해야 합니다.

18. 프로토콜 (The Protocol)

최소한의 프로토콜은 다음과 같은 6가지 연산으로 생각할 수 있습니다:

DISCOVER
ANNOUNCE
BID
...

예시:

Developer
   │
   ├── REQUEST
...

이것만으로도 MVP (Minimum Viable Product, 최소 기능 제품)를 구축하기에 충분합니다.

19. 모든 것을 온체인 (On-Chain)에 올리지 마세요

또 다른 흔한 실수는 탈중앙화가 모든 연산을 블록체인 위에 올리는 것을 의미한다고 가정하는 것입니다.

그렇지 않습니다.

지연 시간 (Latency)에 민감한 연산은 오프체인 (off-chain)에 머물러야 합니다:

추론 (Inference)
스케줄링 (Scheduling)
텔레메트리 (Telemetry)
...

블록체인을 사용한다면, 공유된 결제 (settlement)로부터 실제로 이득을 얻는 항목들을 처리해야 합니다:

결제 (Payments)
스테이킹 (Staking)
공급자 신원 (Provider identity)
...

추론 경로 (inference path)는 결코 블록체인 합의 (consensus)를 기다려서는 안 됩니다.

20. 네트워크는 하이브리드 (Hybrid) 형태여야 합니다

가장 현실적인 아키텍처는 다음과 같습니다:

                 제어 평면 (Control Plane)
              ┌─────────────────┐
              │ 신원 (Identity)  │
...

이는 이데올로기적인 탈중앙화를 피하게 해줍니다.

목표는 다음과 같은 것이 아닙니다:

“모든 것이 탈중앙화되어야 한다.”

목표는 다음과 같습니다:

“모든 워크로드 (workload)는 사용 가능한 최상의 실행 환경에 접근할 수 있어야 한다.”

21. 킬러 기능: 정책 기반 컴퓨팅 (Policy-Based Compute)

가장 강력한 개발자 추상화는 궁극적으로 정책 언어 (policy language)가 될 수 있습니다.

상상해 보세요:

workload:
  model: llama-70b

...

스케줄러는 이를 실행 계획 (execution plan)으로 컴파일합니다.

이는 개발자가 인프라를 프로그래밍하는 것이 아님을 의미합니다.

그들은 **제약 조건 (constraints)**을 프로그래밍하는 것입니다.

22. MVP

백만 개의 GPU로 시작하지 마세요.

다음과 같은 네트워크를 구축하세요:

100–1,000개의 GPU.

하나의 워크로드에 집중하세요.

예를 들어:

AI 크리에이터를 위한 이미지 생성.

왜일까요?

그 이유는 다음과 같습니다:

• 워크로드가 비교적 독립적임
• GPU 가속이 명확함
• 지연 시간 요구사항이 관리 가능함
• 워크로드가 경제적으로 측정 가능함
• 품질을 검증할 수 있음
• 크리에이터들이 GPU 비용을 이해하고 있음

MVP에는 다음과 같은 것들이 포함될 수 있습니다:

1. 노드 에이전트 (Node Agent)
2. Python/TypeScript SDK
3. 스케줄러 (Scheduler)
   ...

토큰이 필요하지 않음.

블록체인이 필요하지 않음.

백만 개의 노드로 구성된 네트워크가 필요하지 않음.

23. MVP 아키텍처 (MVP Architecture)

개발자 (Developer)
   │
   ▼
...

이는 어떠한 탈중앙화 정산 레이어 (decentralized settlement layer)를 도입하기 전에도 구축될 수 있습니다.

24. 2단계 — 지능형 스케줄링 (Intelligent Scheduling)

충분한 텔레메트리 (telemetry) 데이터가 존재하게 되면:

과거 데이터 (Historical Data)
       ↓
성능 모델 (Performance Model)
...

스케줄러는 다음과 같이 진화합니다:

규칙 기반 (Rule-based)

에서:

예측 기반 (Prediction-based)

을 거쳐 최종적으로:

학습 기반 (Learning-based)

로 발전합니다.

시스템은 더 많은 실행 데이터를 가질수록 더 나아집니다.

25. 3단계 — 개방형 제공자 네트워크 (Open Provider Network)

이제 외부 GPU 제공자 (GPU providers)를 허용합니다.

아키텍처는 다음과 같이 구성됩니다:

제공자 (Provider)
   ↓
에이전트 설치 (Install Agent)
...

제공자는 전체 프로토콜을 이해할 필요가 없습니다.

그들은 에이전트를 설치하기만 하면 됩니다.

나머지는 네트워크가 처리합니다.

26. 4단계 — 엣지 라우팅 (Edge Routing)

이제 지리적 지능 (geographic intelligence)을 도입합니다.

스케줄러는 다음과 같은 요소들을 고려하기 시작합니다:

사용자 위치 (User location)
+
네트워크 토폴로지 (Network topology)
...

네트워크는 다음과 같은 것 처럼 동작하기 시작합니다:

AI 추론 (inference)을 위한 CDN.

하지만 파일을 캐싱하는 대신:

연산을 라우팅합니다.

이는 이 아키텍처의 가장 흥미로운 장기적 특성 중 하나가 될 수 있습니다.

27. 5단계 — 클라우드 통합 (Cloud Integration)

이 시점에서 중앙 집중형 클라우드 제공자들은 경쟁 상대가 아닙니다.

그들은 공급자입니다.

스케줄러는 다음과 같은 상황을 선택할 수 있습니다:

개인 GPU (Home GPU)
   ↓
사용 불가 (Unavailable)
...

애플리케이션은 상관하지 않습니다.

패브릭 (fabric)이 복잡성을 흡수합니다.

이것이 진정한 추상화 (abstraction)입니다.

28. 유닛 이코노믹스 (Unit Economics)

비즈니스는 탈중앙화된 컴퓨팅이 자동으로 더 저렴할 것이라는 가정에 의존해서는 안 됩니다.

시스템은 다음과 같은 항목을 최적화해야 합니다:

제공자 지급액 (Provider payout)
+
네트워크 비용 (Network cost)
...

예를 들어:

개발자 지불액       $1.00

제공자             $0.65
...

이 수치들은 예시일 뿐, 예측치가 아닙니다.

중요한 점은 경제성이 워크로드 (workload) 수준에서 작동해야 한다는 것입니다.

29. 무엇이 이 아이디어를 망칠 수 있는가?

진지한 인프라 가설에는 진지한 실패 모드 (failure modes)가 필요합니다.

실패 #1 — 지연 시간 (Latency)

무작위적인 소비자용 GPU (consumer GPUs)는 모든 워크로드 (workload)에 대해 하이퍼스케일러 (hyperscaler)의 네트워킹과 경쟁할 수 없습니다.

대응 방안:

지연 시간 허용 범위가 존재하는 추론 (inference) 워크로드를 타겟팅합니다.

실패 #2 — 신뢰성 (Reliability)

소비자용 하드웨어는 예고 없이 사라질 수 있습니다.

대응 방안:

예측 스케줄링 (Predictive scheduling) + 중복성 (redundancy) + 평판 (reputation).

실패 #3 — 보안 (Security)

알 수 없는 하드웨어는 민감한 워크로드를 노출시킬 수 있습니다.

대응 방안:

로컬 우선 실행 (Local-first execution) + 샌드박싱 (sandboxing) + 신뢰할 수 있는 환경 (trusted environments) + 워크로드 정책 (workload policies).

실패 #4 — 대역폭 (Bandwidth)

대규모 데이터셋을 무작위 GPU로 이동시키는 것은 경제적 이점을 상쇄할 수 있습니다.

대응 방안: