AI 기업들은 그 어느 때보다 컴퓨팅 자원에 접근할 수 있는 다양한 방법을 가지고 있습니다. 하지만 여전히 부족한 것은 워크로드 의도(workload intent)를 신뢰할 수 있는 완료된 실행(completed execution)으로 전환해 주는 중립적인 계층입니다.

AI 인프라는 보통 공급의 문제로 논의됩니다.

누가 GPU를 보유하고 있는가? 어떤 클라우드에 용량이 있는가? 어떤 팀이 가장 낮은 시간당 비용으로 H100을 대여할 수 있는가? 어떤 제공업체가 가장 낮은 지연 시간(latency)으로 모델을 서비스할 수 있는가?

이러한 질문들은 중요하지만, 스택(stack)의 단 한 가지 계층만을 설명할 뿐입니다.

AI 애플리케이션은 궁극적으로 GPU에 대한 접근을 필요로 하는 것이 아닙니다. 워크로드가 완료되는 것을 필요로 합니다.

그 워크로드는 추론(inference) 요청, 이미지 생성 파이프라인, 미세 조정(fine-tuning) 실행, 모델 평가, 배치 처리(batch-processing) 작업, 학습(training) 워크로드, 또는 에이전트(agent)에 의해 실행된 임의의 컨테이너일 수 있습니다.

결과가 사용자에게 도달하기 전에, 작업은 검증(validated), 크기 산정(sized), 배치(placed), 시작(started), 모니터링(monitored), 적절한 시점의 재시도(retried), 그리고 이를 요청한 애플리케이션과의 재연결이 이루어져야 합니다.

하드웨어는 그 프로세스의 일부분일 뿐입니다.

더 중요한 인프라 질문은 다음과 같이 변하고 있습니다:

무엇이 워크로드 의도를 신뢰할 수 있는 실행으로 전환하는가?

해당 기능 주변으로 별도의 카테고리가 형성되기 시작하고 있습니다: 바로 **AI 워크로드 실행 계층 (AI workload execution layer)**입니다.

이 계층은 하이퍼스케일러(hyperscalers), GPU 클라우드, 마켓플레이스(marketplaces), 그리고 추론 제공업체(inference providers)의 상위에 위치합니다.

또한 AI 애플리케이션, 워크플로 시스템(workflow systems), 그리고 자율 에이전트(autonomous agents)의 하위에 위치합니다.

이 계층의 역할은 단순히 머신을 노출하는 것이 아닙니다. 작업에 대한 설명을 수락하고 완료된 결과로 가는 경로를 관리하는 것이 그 역할입니다.

이 카테고리는 아직 초기 단계입니다. 경계가 확정되지 않았으며, 이미 여러 인접 인프라 기업들이 그 조각들을 해결하고 있습니다.

하지만 근본적인 기능은 모든 AI 기업 내부의 스크립트 모음으로 남아 있기에는 너무 중요해졌고, 운영적으로 너무 복잡해졌습니다.

이것이 바로 Jungle Grid가 진입하기 위해 구축되고 있는 인프라 카테고리입니다.

더 많은 컴퓨팅 공급이 실행 복잡성을 제거하지는 않는다

AI 시장은 이제 불과 몇 년 전보다 컴퓨팅에 접근할 수 있는 더 많은 방법을 제공하고 있습니다.

하이퍼스케일러 (Hyperscalers)는 성숙한 클라우드 프리미티브 (cloud primitives)와 관리형 배치 시스템 (managed batch systems)을 제공합니다.

특화된 GPU 클라우드는 가속기 용량에 대한 빠른 접근을 제공합니다.

마켓플레이스 (Marketplaces)는 분산된 운영사들로부터 머신을 집계합니다.

서버리스 AI 플랫폼 (Serverless AI platforms)은 더 높은 수준의 프로그래밍 모델을 통해 컴퓨팅을 노출합니다.

호스팅된 추론 제공업체 (Hosted inference providers)는 간단한 API를 통해 선택된 모델을 사용할 수 있게 합니다.

이러한 확장은 빌더 (builders)들에게 유익합니다. 이는 더 많은 용량, 더 다양한 가격 모델, 그리고 더 많은 경쟁을 창출합니다.

하지만 이는 파편화 (fragmentation) 또한 초래합니다.

기존의 네 가지 접근 방식을 살펴보겠습니다:

• AWS Batch는 작업 큐 (job queues)와 관련 컴퓨팅 환경을 통해 작업을 스케줄링합니다.
• RunPod Serverless는 AI 및 기타 컴퓨팅 집약적인 워크로드를 위해 큐 기반 및 부하 분산 (load-balancing) 엔드포인트를 제공합니다.
• Vast.ai는 분산 GPU 마켓플레이스와 인스턴스 및 서버리스 실행 제품을 결합합니다.
• Modal은 기본 인프라 관리의 상당 부분을 숨기도록 설계된 서버리스 컴퓨팅 환경을 제공합니다.

각 제품은 문제의 의미 있는 부분을 해결합니다.

또한 각 제품은 고유의 실행 모델 (execution model), 구성 시스템 (configuration system), 라이프사이클 상태 (lifecycle states), 가격 모델 (pricing model), 그리고 운영상의 가정 (operational assumptions)을 노출합니다.

하나의 제공업체를 통합하는 팀은 해당 제공업체가 작업을 표현하는 방식을 이해해야 합니다.

여러 제공업체를 통합하는 팀은 그들 모두를 이해해야 합니다.

팀은 다음 사항들을 정규화 (normalize)해야 합니다:

• 인증 (authentication);
• 리소스 이름 (resource names);
• GPU 성능 (GPU capabilities);
• 컨테이너 요구사항 (container requirements);
• 워크로드 제출 (workload submission);
• 큐잉 동작 (queueing behavior);
• 작업 상태 (job states);
• 로그 (logs);
• 재시도 (retries);
• 취소 (cancellation);
• 아티팩트 전달 (artifact delivery);
• 가격 (pricing);
• 용량 제한 (capacity limits);
• 실패 조건 (failure conditions).

첫 번째 제공업체 통합은 단순한 API 프로젝트처럼 보일 수 있습니다.

하지만 세 번째나 네 번째가 되면 인프라 플랫폼 (infrastructure platform)이 됩니다.

그 시점에서 AI 기업은 더 이상 자신의 제품만을 구축하고 있는 것이 아닙니다.

또한 스케줄러 (scheduler), 프로바이더 추상화 계층 (provider abstraction layer), 작업 상태 데이터베이스 (job-state database), 관측성 파이프라인 (observability pipeline), 아티팩트 시스템 (artifact system), 그리고 일련의 장애 복구 절차 (failure-recovery procedures)를 유지 관리하고 있습니다.

그러한 작업은 필요하지만, 회사가 구축하고자 의도했던 제품인 경우는 드뭅니다.

이것이 실행 계층 (execution layer)이 하나의 카테고리가 되고 있는 첫 번째 이유입니다:

컴퓨팅 자원의 풍요는 조정 (coordination)의 필요성을 증가시킵니다.

AI 인프라 스택에서 누락된 계층

시장을 이해하는 유용한 방법은 스택을 세 가지 계층으로 분리하는 것입니다.

1. 애플리케이션 및 에이전트 계층 (The application and agent layer)

이곳은 워크로드의 의도 (workload intent)가 시작되는 곳입니다.

여기에는 AI 제품, 코딩 에이전트 (coding agents), 기업 내부 시스템, 자동화 플랫폼, 연구 도구, 그리고 개발자 워크플로 (developer workflows)가 포함됩니다.

이 시스템들은 무엇이 일어나야 하는지를 결정합니다.

코딩 에이전트는 테스트 스위트 (test suite)를 실행해야 할 수도 있습니다.

미디어 제품은 수백 개의 이미지를 생성해야 할 수도 있습니다.

지원 플랫폼은 밀려 있는 문서들을 분류해야 할 수도 있습니다.

머신러닝 (machine-learning) 팀은 모델을 미세 조정 (fine-tune)해야 할 수도 있습니다.

연구 에이전트는 장시간 실행되는 컨테이너 (container)를 실행하고, 그 진행 상황을 추적하며, 로그를 검사하고, 결과물을 수집해야 할 수도 있습니다.

애플리케이션은 비즈니스 태스크 (business task)를 이해해야 합니다.

애플리케이션이 이를 수행할 수 있는 모든 인프라 프로바이더 (infrastructure provider)에 대해 깊은 지식을 가질 필요는 없습니다.

2. 컴퓨팅 공급 계층 (The compute-supply layer)

이곳은 물리적 및 가상적 용량 (capacity)이 존재하는 곳입니다.

여기에는 하이퍼스케일러 (hyperscalers), 특화된 GPU 클라우드, 분산 마켓플레이스, 서버리스 GPU 플랫폼, 추론 프로바이더 (inference providers), 그리고 프라이빗 클러스터 (private clusters)가 포함됩니다.

이 비즈니스들은 필수적인 질문에 답합니다:

연산 (computation)이 어디에서 일어날 수 있는가?

이들의 인센티브는 대개 고객이 자신의 인프라를 효율적으로 소비하도록 돕는 것과 일치합니다.

하이퍼스케일러는 워크로드가 자신의 클라우드 내에 머물기를 원합니다.

GPU 클라우드는 고객이 자신의 머신을 사용하기를 원합니다.

마켓플레이스는 수요가 네트워크 내에서 사용 가능한 공급과 맞물려 해소되기를 원합니다.

그렇다고 해서 이 프로바이더들이 부적절하다는 뜻은 아닙니다.

이는 그들이 스택(stack) 내에서 다른 위치를 차지하고 있음을 의미합니다.

3. 실행 계층 (The execution layer)

실행 계층은 다음 질문에 답합니다:

이 워크로드(workload)를 어떻게 완료해야 하는가?

실행 계층은 워크로드 의도(intent)를 수신하고, 요구 사항을 평가하며, 실행 가능한 경로를 식별하고, 작업을 배정(dispatch)하며, 내구성이 있는 라이프사이클(lifecycle)을 통해 작업을 관리합니다.

성숙한 실행 계층은 다음 사항을 책임져야 합니다:

1. 워크로드가 무엇을 필요로 하는지 이해하기
2. 비용이 지출되기 전에 잘못된 요청을 거부하거나 수정하기
3. 비용을 추정하고 실행 가능한 용량(capacity) 식별하기
4. 실행 대상(execution target) 선택하기
5. 작업을 안전하게 제출하기
6. 프로바이더(provider) 및 애플리케이션 상태 추적하기
7. 로그 및 런타임(runtime) 이벤트 노출하기
8. 적절한 실패 상황으로부터 복구하기
9. 출력물 및 아티팩트(artifacts) 수집하기
10. 안정적인 최종 결과 반환하기

이는 단순한 멀티 클라우드 라우팅(multi-cloud routing) 그 이상입니다.

라우팅은 더 큰 실행 계약(execution contract) 내의 하나의 결정일 뿐입니다.

개발자들이 다음과 같은 질문을 멈출 수 있을 때 이 카테고리는 중요해집니다:

어떤 프로바이더를 호출해야 하는가?

대신 다음과 같이 질문하게 될 때입니다:

이러한 제약 조건 하에서 어떻게 이 작업을 완료할 수 있는가?

왜 지금 이 카테고리가 형성되고 있는가

네 가지 구조적 변화가 실행 기능(execution function)을 내부 인프라 팀에서 분리하여 독자적인 시장으로 밀어내고 있습니다.

컴퓨팅 공급이 더욱 이질화(heterogeneous)되고 있음

AI 컴퓨팅이 하나의 균일한 프로바이더로 통합될 기미는 보이지 않습니다.

서로 다른 공급업체들은 다양한 차원에서 계속해서 각자의 강점을 가질 것입니다:

• 가속기(accelerator) 유형
• 메모리 용량
• 지역적 가용성
• 인터커넥트(interconnect) 성능
• 프로비저닝(provisioning) 속도
• 신뢰성
• 컴플라이언스 (compliance)
• 가격
• 특정 모델 또는 런타임(runtime) 지원

어떤 프로바이더는 짧고 지연 시간(latency)에 민감한 추론(inference) 작업에 적합한 선택일 수 있습니다.

다른 프로바이더는 중단 가능한 배치 처리(batch processing)에 더 나을 수 있습니다.

또 다른 프로바이더는 특정 모델에 필요한 충분한 메모리를 갖춘, 즉시 사용 가능한 유일한 GPU를 보유하고 있을 수도 있습니다.

민감한 데이터의 경우 프라이빗 클러스터 (Private Cluster)가 선호될 수 있는 반면, 재시도 가능한 공개 워크로드 (Public Workload)의 경우 마켓플레이스 (Marketplace)를 사용하는 것도 수용 가능할 수 있습니다.

경제적으로 합리적인 아키텍처는 항상 다음과 같지는 않습니다:

하나의 클라우드를 선택하여 모든 것에 사용하는 것.

대신 다음과 같을 수 있습니다:

하나의 워크로드 인터페이스 (Workload Interface)를 사용하고, 정책 (Policy)에 따라 각 작업 (Job)이 어디에 속할지를 결정하는 것.

이러한 패턴은 이전에도 나타난 적이 있습니다.

데이터베이스가 많아지면서 데이터 통합 (Data Integration) 및 오케스트레이션 (Orchestration)에 대한 수요가 증가했습니다.

SaaS 제품이 많아지면서 워크플로 자동화 (Workflow Automation)에 대한 수요가 증가했습니다.

클라우드 서비스가 많아지면서 관측성 (Observability) 및 인프라 관리 (Infrastructure Management)에 대한 수요가 증가했습니다.

컴퓨팅 프로바이더 (Compute Provider)가 많아지면서 이들을 조정하는 계층 (Layer)이 들어설 자리가 생겨나고 있습니다.

AI 워크로드는 점점 덜 균일해지고 있다

"AI 워크로드 (AI Workload)"라는 문구는 이제 근본적으로 다른 요구사항을 가진 실행 패턴들을 포괄합니다.

대화형 추론 (Interactive Inference) 요청은 몇 초 이내에 응답이 필요할 수 있습니다.

배치 추론 (Batch Inference) 작업은 몇 시간 동안 실행될 수 있으며 큐잉 (Queueing)을 허용할 수 있습니다.

파인튜닝 (Fine-tuning) 워크로드는 특정 GPU 메모리 임계값, 업로드된 데이터셋, 체크포인트 처리 (Checkpoint Handling), 그리고 내구성이 있는 아티팩트 (Durable Artifacts)를 필요로 할 수 있습니다.

이미지 파이프라인 (Image Pipeline)은 버스트성 (Bursty)을 띠며 병렬적일 수 있습니다.

학습 실행 (Training Run)은 적절한 네트워킹을 갖춘 여러 개의 GPU를 필요로 할 수 있습니다.

에이전트 (Agent)에 의해 실행된 컨테이너는 지속 가능한 파일 시스템 (Persistent Filesystem), 외부 스토리지, 그리고 명확한 취소 정책 (Cancellation Policy)이 필요할 수 있습니다.

이러한 작업들을 하나의 단순한 규칙으로 배치해서는 안 됩니다.

나열된 가장 낮은 시간당 가격이 반드시 성공적인 워크로드당 가장 낮은 비용을 의미하지는 않습니다.

초기화 후 실패하거나, 호환되지 않는 이미지를 가져오거나, 요구되는 시간 내에 완료할 수 없는 더 저렴한 머신은, 가격은 더 높더라도 신뢰할 수 있는 경로보다 더 비용이 많이 들 수 있습니다.

실행 계층 (Execution Layer)이 가치 있는 이유는 **워크로드 적합성 (Workload Fit)**에 대해 추론할 수 있기 때문입니다.

이는 단순히 머신 카탈로그를 노출하는 것과는 다릅니다.

컴퓨팅 마켓플레이스 (Compute Marketplace)는 고객이 하드웨어를 찾는 것을 돕습니다.

실행 플랫폼 (Execution Platform)은 고객이 작업을 완료하는 것을 돕습니다.

에이전트가 직접적인 인프라 소비자가 되고 있다

다음 중요한 인프라 고객은 대시보드에서 옵션을 선택하는 인간이 아닐 수도 있습니다.

그것은 에이전트 (Agent)일 수 있습니다.

Model Context Protocol은 AI 애플리케이션이 외부 시스템에 연결할 수 있는 표준화된 방법을 제공합니다.

MCP 서버는 모델이 시스템을 쿼리하거나, API를 호출하거나, 연산을 수행하기 위해 호출할 수 있는 도구 (Tools)를 노출할 수 있습니다.

이는 새로운 인터페이스 요구사항을 만들어냅니다.

에이전트는 다음과 같은 작업을 수행할 수 있어야 합니다:

• 작업 (Job) 제출
• 식별자 (Identifier) 획득
• 작업의 라이프사이클 (Lifecycle) 추적
• 관련 로그 (Logs) 조사
• 출력값 (Outputs) 회수
• 실행 실패 시 적절한 대응

에이전트가 클라우드 인프라 전문가가 될 필요는 없어야 합니다.

자율 시스템에 프로바이더 (Provider)의 로우 API (Raw API)에 대한 직접적인 접근 권한을 부여하는 것은 너무 많은 인프라 복잡성을 에이전트 루프 (Agent loop)로 전이시킵니다.

에이전트는 인스턴스 패밀리 (Instance families), 지역별 용량 (Regional capacity), 스팟 (Spot) 동작, 큐 정책 (Queue policies), 이미지 호환성 (Image compatibility), 자격 증명 (Credentials), 그리고 프로바이더별 상태 모델 (Provider-specific status models)에 대해 추론해야 합니다.

더 나은 추상화는 다음과 것에 가깝습니다:

이 요구사항에 맞춰 이 워크로드 (Workload)를 실행해줘. 비용이 얼마인지 알려주고, 진행 상황을 계속 알려주며, 결과를 반환해줘.

실행 계층 (Execution layer)은 이러한 의도를 인프라 운영 (Infrastructure operations)으로 번역합니다.

이는 단순히 개발자 경험 (Developer experience)의 개선만이 아닙니다.

이는 신뢰할 수 있는 에이전트 시스템 (Agentic systems)을 위한 전제 조건입니다.

기계는 구조화되어 있고, 예측 가능하며, 관찰 가능하고, 반복적으로 호출하기에 안전한 인터페이스를 필요로 합니다.

신뢰성 (Reliability)이 제품 표면으로 이동하고 있다

실험 단계에서 작업 실패는 불편함에 불과합니다.

하지만 프로덕션 (Production) 환경에서 실패는 고객 경험의 일부입니다.

AI 제품이 결과물을 약속할 때, 사용자는 실패의 원인이 애플리케이션인지, 스케줄러 (Scheduler)인지, 프로바이더 API인지, GPU 부족인지, 깨진 컨테이너 (Container)인지, 혹은 아티팩트 (Artifact) 업로드 문제인지 신경 쓰지 않습니다.

그들은 단 한 가지만을 경험합니다:

제품이 작업을 완료하지 못했다.

따라서 애플리케이션은 다음과 같은 어려운 질문들에 대해 신뢰할 수 있는 답변을 제공해야 합니다:

• 요청이 수락되었는가?
• 용량(Capacity)이 실제로 확보되었는가?
• 실행이 시작되었는가?
• 작업이 여전히 대기열(Queue)에 있는가, 아니면 제공업체가 이를 분실했는가?
• 재시도(Retry)를 해도 안전한가?
• 재시도가 중복 작업이나 중복 비용을 발생시키지는 않는가?
• 아티팩트(Artifact) 전달은 실패했지만 계산(Computation)은 완료되었는가?
• 사용자가 기다려야 하는가, 취소해야 하는가, 아니면 다시 제출해야 하는가?
• 최종 상태(Final state)를 관리하는 시스템은 무엇인가?

Raw compute(원시 컴퓨팅)에 대한 접근만으로는 이러한 질문들을 해결할 수 없습니다.

실행 계층(Execution layer)은 지연되거나, 모호하거나, 혹은 일관되지 않은 정보를 반환할 수 있는 시스템 전반에서 발생한 일들에 대해 내구성이 있는 기록(Durable account)을 유지해야 합니다.