AI 에이전트(AI agent)는 요청을 받고, 사용 가능한 컨텍스트(context)를 검토하며, 계획을 수립하고, 적절한 도구(tools)를 선택한 뒤, 다음 단계가 새로 업로드된 데이터셋으로 모델을 미세 조정(fine-tune)하는 것이라고 결정합니다.

추론은 정확합니다.

계획은 유효합니다.

도구 호출(tool call)이 생성됩니다.

그다음 현실이 시작됩니다.

어떤 GPU가 워크로드(workload)를 실행해야 할까요? 해당 GPU는 현재 사용 가능한 상태인가요? 어떤 제공업체(provider)가 작업을 받아야 할까요? 선택된 머신이 컨테이너 이미지(container image)를 실행할 수 있나요? 데이터셋은 어디에 저장되어야 할까요? 제출 후 용량(capacity)이 사라지면 어떻게 되나요? 로그는 에이전트에게 어떻게 반환되나요? 2시간 후에 프로세스가 충돌하면 재시작해야 할까요, 재개해야 할까요, 아니면 종료해야 할까요? 최종 아티팩트(artifact)는 어디에 배치되나요?

에이전트는 무엇이 일어나야 하는지 결정할 수 있습니다.

하지만 단순히 결정하는 것만으로 기저의 인프라(infrastructure)를 신뢰할 수 있게 만들 수는 없습니다.

이것이 많은 에이전트 아키텍처(agent architectures)에서 누락된 계층입니다. 바로 에이전트의 의도를 실제 인프라에서 실행되는 관찰 가능하고(observable) 복구 가능한(recoverable) 작업으로 변환하는 **AI 에이전트 실행 계층(AI agent execution layer)**입니다.

추론은 실행이 아닙니다.
도구 호출은 워크로드가 아닙니다.
API가 200 OK를 반환했다고 해서 워크로드가 완료된 것은 아닙니다.

에이전트 동작 뒤에 숨겨진 4가지 계층

현대적인 에이전트 시스템은 네 가지 뚜렷한 계층으로 나눌 수 있습니다.

1. 추론 계층 (The reasoning layer)

추론 계층은 목표를 해석하고 다음에 무엇이 일어나야 하는지를 결정합니다.

이 계층은 다음과 같은 결정을 내릴 수 있습니다:

• 정보 검색
• 데이터베이스 쿼리(Query)
• 코드 생성
• 데이터셋 처리
• 추론(inference) 실행
• 모델 미세 조정 (fine-tune)
• 컨테이너 실행
• 아티팩트 생성

이 계층의 책임은 의사 결정입니다.

2. 도구 또는 오케스트레이션 계층 (The tool or orchestration layer)

오케스트레이션 계층은 결정을 구조화된 동작으로 변환합니다.

이 계층은 다음과 같은 함수를 노출할 수 있습니다:

{
  "tool": "run_training_job",
  "arguments": {
...

이 계층은 어떤 도구를 호출해야 하는지 결정하고, 관련 매개변수(parameters)를 전달하며, 여러 단계를 순차적으로 조정할 수 있습니다.

이 계층의 책임은 워크플로(workflow) 조정입니다.

3. 워크로드 실행 계층 (The workload execution layer)

실행 계층 (execution layer)은 워크로드 (workload)를 수락하고 그 생명주기 (lifecycle)를 관리합니다.

이 계층은 다음과 같은 질문에 답해야 합니다:

• 이 워크로드는 어디에서 실행되어야 하는가?
• 어떤 하드웨어 (hardware)가 필요한가?
• 호환 가능한 용량 (capacity)이 사용 가능한가?
• 워크로드를 어떻게 스케줄링 (scheduling)해야 하는가?
• 로그 (logs)는 어떻게 수집되는가?
• 실행이 실패하면 어떤 일이 발생하는가?
• 워크로드를 안전하게 재시도 (retry)할 수 있는가?
• 출력값 (outputs)은 어디에 저장되는가?
• 에이전트 (agent)가 나중에 결과를 어떻게 검사하는가?

이 계층의 책임은 신뢰할 수 있는 실행 (reliable execution)입니다.

4. 하부 컴퓨팅 제공자 (The underlying compute providers)

컴퓨팅 제공자 (compute providers)는 작업이 궁극적으로 실행되는 CPU, GPU, 스토리지 (storage), 네트워킹 (networking) 및 머신 (machines)을 공급합니다.

이들의 책임은 용량 (capacity)입니다.

이 네 가지 계층은 서로 연관되어 있지만, 서로 대체될 수는 없습니다.

추론 계층 (reasoning layer)은 제공자별 GPU 인벤토리 (inventory)를 이해할 필요가 없어야 합니다. 오케스트레이션 계층 (orchestration layer)은 컨테이너 스케줄링 (container scheduling) 및 장애 복구 (failure recovery)를 구현할 필요가 없어야 합니다. 컴퓨팅 제공자 (compute provider)는 워크로드 이면에 있는 비즈니스 의도 (business intent)를 이해할 필요가 없어야 합니다.

**AI 워크로드 실행 계층 (AI workload execution layer)**은 의도 (intent)를 인프라 (infrastructure)에 연결합니다.

아키텍처 다이어그램을 위한 Mermaid 소스

flowchart TD
    A[AI Agent<br/>Reasoning Layer] --> B[Tools and Orchestration]
    B --> C[AI Workload Execution Layer]
...

도구 호출 (Tool Calling)이 워크로드 실행이 아닌 이유

도구 호출 (tool calling)은 에이전트 (agent)에게 외부 동작을 요청하는 구조화된 방법을 제공합니다.

가벼운 작업 (lightweight operations)의 경우, 이는 잘 작동합니다. 에이전트가 요청을 보내면, 서비스가 동작을 수행하고, 결과가 예측 가능한 시간 범위 내에 반환됩니다.

검색 쿼리 (search query), 데이터베이스 조회 (database lookup) 또는 단순한 API 요청은 종종 하나의 추론 사이클 (reasoning cycle) 안에 포함될 수 있습니다.

연산 집약적인 워크로드 (compute-heavy workloads)는 다르게 동작합니다.

모델을 미세 조정(fine-tune)하거나, 대규모 데이터셋을 처리하거나, 컨테이너를 실행하거나, 배치 추론(batch inference)을 수행하거나, 복잡한 아티팩트(artifact)를 생성하라는 요청은 몇 분 또는 몇 시간이 걸릴 수 있습니다.

요청된 하드웨어를 즉시 사용할 수 없을 수도 있습니다.

워크로드가 부분적으로 완료된 후 실패할 수도 있습니다.

지속적인 로그, 중간 체크포인트(intermediate checkpoints), 그리고 여러 개의 출력 파일을 생성할 수 있습니다.

이를 제출한 에이전트 프로세스가 중단된 후에도 작업이 여전히 실행 중일 수 있습니다.

그 시점에서 에이전트는 더 이상 단순한 함수 호출(function call)을 수행하는 것이 아닙니다. 에이전트는 분산 시스템 워크플로(distributed systems workflow)를 개시하고 있는 것입니다.

함수 호출(function invocation)은 인프라에 시작을 알릴 수는 있지만, 다음과 같은 것들을 자동으로 제공하지는 않습니다:

• 내구성 있는 상태 (Durable state)
• 하드웨어 인식 스케줄링 (Hardware-aware scheduling)
• 용량 관리 (Capacity management)
• 로그 지속성 (Log persistence)
• 실패 분류 (Failure classification)
• 안전한 재시도 (Safe retries)
• 취소 (Cancellation)
• 아티팩트 저장 (Artifact storage)
• 제공자 장애 조치 (Provider failover)
• 라이프사이클 관측 가능성 (Lifecycle observability)

에이전트에게 run_gpu_job 도구를 준다고 해서 이러한 문제들이 해결되지는 않습니다.

그것은 단지 에이전트에게 문제에 대한 이름 하나를 부여할 뿐입니다.

에이전트가 연산 집약적인 작업을 요청한 후에는 어떤 일이 발생할까요?

에이전트가 컨테이너화된 GPU 워크로드를 실행하기로 결정했다고 가정해 봅시다.

에이전트의 요청에는 다음과 같은 내용이 포함될 수 있습니다:

image: registry.example.com/training-worker:v3
command:
  - python
...

에이전트의 관점에서 지침은 간단합니다:

이 워크로드를 실행하라.

인프라의 관점에서 보면, 이 요청은 일련의 결정 과정을 시작합니다.

시스템은 먼저 워크로드 정의를 검증해야 합니다.

컨테이너, 명령, 입력값 및 리소스 요구 사항이 유효한지 판단해야 합니다. 실행 전에 비용을 추정해야 할 수도 있습니다. 호환 가능한 하드웨어를 식별하고, 사용 가능한 용량을 확인하며, 제공자를 선택하고, 실행 환경을 준비하고, 필요한 입력을 스테이징(stage)하며, 컨테이너를 시작해야 합니다.

컨테이너가 실행되기 시작한 후에도 인프라는 계속 작동해야 합니다.

로그를 수집하고, 상태를 보존하며, 실패를 감지하고, 타임아웃을 강제하며, 취소 요청을 수신하고, 출력을 모으고, 진행 상황을 보고해야 합니다.

선택된 제공자(provider)를 사용할 수 없게 되면, 실행 시스템은 중복 작업이나 일관성 없는 아티팩트(artifacts)를 생성하지 않고 작업을 재시도할 수 있는지 여부를 결정해야 합니다.

초기 스케줄링(scheduling) 결정은 AI 워크로드 실행의 일부분일 뿐입니다.

더 어려운 문제는 전체 라이프사이클(lifecycle) 동안 정확성(correctness)을 유지하는 것입니다.

개발자들이 과소평가하는 인프라의 책임

프로토타입은 셸 명령어나 특정 제공자 전용 API 요청으로 워크로드를 실행할 수 있습니다.

하지만 프로덕션 시스템은 훨씬 더 많은 것을 처리해야 합니다.

하드웨어 호환성 (Hardware compatibility)

GPU는 서로 호환되지 않습니다.

워크로드는 다음과 같은 특정 요구사항을 가질 수 있습니다:

• GPU 메모리
• 가속기 아키텍처 (Accelerator architecture)
• 드라이버 (Drivers)
• CUDA 또는 ROCm 버전
• 프레임워크 호환성 (Framework compatibility)
• 컨테이너 런타임 지원 (Container runtime support)
• CPU 및 시스템 메모리
• 스토리지 용량

워크로드가 해당 머신에서 시작하거나 완료할 수 없다면, 단순히 가장 저렴한 가용 머신을 선택하는 것은 무의미합니다.

실행 시스템은 워크로드 요구사항을 호환 가능한 인프라와 일치시켜야 합니다.

동적 용량 (Dynamic capacity)

제공자가 특정 GPU를 지원하더라도, 필요한 리전(region)에서 즉시 사용 가능한 상태가 아닐 수 있습니다.

또한 용량은 추정 단계와 제출 단계 사이에서 변할 수 있습니다.

따라서 실행 계층(execution layer)은 이전의 가용성 확인이 실행을 보장한다고 가정하기보다는, 용량을 동적인 것으로 취급해야 합니다.

스케줄링 및 배치 (Scheduling and placement)

배치(Placement)는 워크로드가 어디에서 실행될지를 결정합니다.

이 결정에는 다음과 같은 요소들이 고려될 수 있습니다:

• 하드웨어 호환성
• 현재 가용성
• 예상 비용
• 제공자 신뢰성
• 데이터 위치
• 보안 정책
• 지리적 제한
• 실행 긴급도
• 워크로드 우선순위

인프라가 여러 제공자에 걸쳐 확장됨에 따라, 배치는 단일 API 통합의 문제가 아닌 라우팅(routing) 문제로 변모합니다.

지속 가능한 상태 (Durable state)

에이전트에게는 started와 finished 이상의 상태가 필요합니다.

실제적인 워크플로(workflow)는 다음과 같은 상태들을 포함할 수 있습니다:

queued
  |
  v
...

각 상태는 특정한 의미를 갖습니다:

• queued: 워크로드 (workload)가 수락되었으나 인프라 (infrastructure)를 할당받지 못한 상태입니다.
• running: 인프라가 할당되었으며 실행이 시작된 상태입니다.
• retrying: 복구 가능한 실패가 발생하여 재시도를 준비 중인 상태입니다.
• completed: 실행이 성공하였고 예상된 출력값 (outputs)이 수집된 상태입니다.
• failed: 워크로드가 개입이나 재제출이 필요한 최종 실패 상태에 도달한 상태입니다.

지속적인 상태 (durable state)가 없다면, 개발자도 에이전트도 실제로 어떤 일이 일어났는지 판단할 수 없습니다.

로그 및 이벤트 (Logs and events)

장시간 실행되는 워크로드의 경우, 관찰 가능성 (observability)은 제품 인터페이스의 일부입니다.

에이전트에게는 다음과 같은 것들이 필요할 수 있습니다:

• 시작 로그 (Startup logs)
• 진행 상황 업데이트 (Progress updates)
• 경고 이벤트 (Warning events)
• 리소스 정보 (Resource information)
• 제공자 이벤트 (Provider events)
• 재시도 알림 (Retry notifications)
• 실패 메시지 (Failure messages)
• 아티팩트 알림 (Artifact notifications)

이러한 로그들은 기반이 되는 머신 (machine)이 종료된 후에도 계속 사용할 수 있어야 합니다.

실패 복구 (Failure recovery)

재시도 (Retries)는 단순히 API 호출을 반복하는 것이 아닙니다.

재시도하기 전에 시스템은 다음 사항들을 결정해야 합니다:

• 이전 시도가 실제로 시작되었는가?
• 부수 효과 (side effects)를 발생시켰는가?
• 부분적인 출력값 (partial outputs)이 존재하는가?
• 워크로드를 안전하게 다시 실행할 수 있는가?
• 두 번째 시도가 중복을 생성할 수 있는가?
• 동일한 제공자 (provider)를 사용해야 하는가?
• 다른 호환 가능한 실행 경로가 있는가?

또한 시스템은 잘못된 입력 (invalid input), 애플리케이션 실패 (application failure), 용량 손실 (capacity loss), 인프라 실패 (infrastructure failure), 타임아웃 (timeout), 그리고 취소 (cancellation)를 구분해야 합니다.

각 실패 유형은 서로 다른 대응을 필요로 합니다.

아티팩트 처리 (Artifact handling)

많은 AI 워크로드는 HTTP 응답에 결과를 직접 반환하지 않습니다.

이들은 다음과 같은 것들을 생성합니다:

• 모델 체크포인트 (Model checkpoints)
• 평가 보고서 (Evaluation reports)
• 생성된 파일 (Generated files)
• 변환된 데이터셋 (Transformed datasets)
• 로그 (Logs)
• 이미지 (Images)
• 비디오 (Videos)
• 임베딩 (Embeddings)
• 중간 결과 (Intermediate results)

실행 계층 (execution layer)은 이러한 출력값들을 수집하고, 이를 올바른 워크로드와 연결하며, 보존하고, 에이전트나 개발자가 접근할 수 있도록 만들어야 합니다.

추론은 동기적입니다. 실제 작업은 그렇지 않은 경우가 많습니다.

대부분의 에이전트 상호작용은 다음과 같은 대화형 루프 (conversational loop)를 따릅니다:

1. 컨텍스트 (context) 수신.
2. 다음 행동에 대해 추론.
3. 도구 (tool) 호출.
4. 결과 수신.
5. 추론 지속.

이 모델은 행동이 루프 내에 들어올 수 있을 만큼 충분히 빠르게 완료된다고 가정합니다.

하지만 실행 시간이 긴 AI 워크로드 (workloads)는 그 가정을 위반합니다.

파인튜닝 (fine-tuning) 작업은 이를 시작한 프로세스보다 더 오래 지속될 수 있습니다. 데이터셋 처리 작업은 사용자가 애플리케이션을 종료한 후에도 계속될 수 있습니다. 에이전트가 다른 작업을 수행하는 동안 GPU를 사용할 수 없게 될 수도 있습니다. 워크로드는 몇 시간 후에 완료되어 워크플로 (workflow)의 다음 단계를 트리거해야 하는 아티팩트 (artifact)를 생성할 수도 있습니다.

따라서 실행은 비동기적 (asynchronous)이어야 합니다.

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

1. 워크로드 제출.
2. 영구적인 워크로드 식별자 (identifier) 수신.
3. 다른 행동을 계속 수행.
4. 나중에 워크로드의 상태 조사.
5. 로그 스트리밍 또는 검색.
6. 필요 시 워크로드 취소.
7. 완료 후 출력물 검색.

워크로드는 원래의 대화가 열려 있는 상태에 의존해서는 안 됩니다.

비동기 실행에는 관측성 (observability) 또한 필요합니다. 에이전트는 조사할 수 없는 작업에 대해 좋은 결정을 내릴 수 없습니다.

마지막으로, 실행은 복구 가능 (recoverable)해야 합니다.

기계는 고장 납니다. 컨테이너 (containers)는 종료됩니다. 제공업체는 용량을 상실합니다. 네트워크는 타임아웃 (time out)됩니다. 프로세스는 비정상 상태 (unhealthy)가 됩니다.

복구는 출시 후에 추가되는 선택적인 기능이 아닙니다. 이는 실행 시간이 긴 AI 워크로드의 정상적인 라이프사이클 (lifecycle)의 일부입니다.

AI 워크로드 실행 계층이 제공해야 하는 것

프로덕션급 **AI 에이전트 실행 계층 (AI agent execution layer)**은 에이전트와 이기종 인프라 (heterogeneous infrastructure) 사이의 안정적인 인터페이스를 구축해야 합니다.

최소한 다음과 같은 것들을 제공해야 합니다:

• 구조화된 워크로드 제출 (Structured workload submission)
• 실행 전 검증 (Validation before execution)
• 가능한 경우 리소스 또는 비용 추정 (Resource or cost estimation where possible)
• 하드웨어 인지 배치 (Hardware-aware placement)
• GPU 및 CPU 라우팅 (GPU and CPU routing)
• 내구성이 있는 워크로드 상태 (Durable workload state)
• 비동기 실행 (Asynchronous execution)
• 로그 및 실행 이벤트 (Logs and execution events)
• 실패 분류 (Failure classification)
• 재시도 및 복구 메커니즘 (Retry and recovery mechanisms)
• 워크로드 취소 (Workload cancellation)
• 아티팩트 수집 (Artifact collection)
• 제공자 추상화 (Provider abstraction)
• 액세스 제어 및 격리 (Access control and isolation)

인터페이스는 모든 제공자별 구현 세부 사항을 노출하기보다는 워크로드를 기술해야 합니다.

에이전트는 무엇을 실행해야 하는지, 필요한 리소스, 관련 입력값, 그리고 예상되는 출력값을 명시해야 합니다.

실행 계층 (Execution layer)은 해당 요청을 제공자별 실행 계획 (Provider-specific execution plan)으로 변환해야 합니다.