단순히 강력한 GPU만으로 AI 시대를 주도할 수 있을까요? 이제 경쟁의 무게중심은 “얼마나 많은 연산을 갖췄는가”에서 “얼마나 잘 운영되는 플랫폼을 갖췄는가”로 이동하고 있습니다. 특히 에이전틱 AI(Agentic AI)는 모델 1개를 잘 돌리는 수준을 넘어, 여러 에이전트가 스스로 계획을 세우고 코드를 작성·수정하며 시스템을 운영하는 패턴으로 확장됩니다. 이 순간부터 AI의 성능과 비용, 안정성은 GPU 스펙보다 Software Infra(소프트웨어 인프라), 즉 AI PaaS의 설계와 운영 자동화 수준에 의해 결정되기 시작합니다.
Software Infra의 게임 체인저: 에이전틱 AI + AI PaaS는 무엇이 다른가
에이전틱 AI 환경에서 워크로드는 더 이상 “모델 추론 요청”만이 아닙니다. 에이전트는 다음을 동시에 요구합니다.
- 다단계 작업 실행: 계획 수립 → 도구 호출 → 코드 변경 → 테스트 → 배포 같은 파이프라인을 반복
- 복합 리소스 사용: GPU뿐 아니라 CPU, 메모리, 스토리지 I/O, 네트워크 대역폭을 불규칙하게 소비
- 지속적 운영: 일회성 요청이 아니라, 상시 실행되는 에이전트 군집이 시스템을 “계속” 만짐
이런 특성 때문에 “GPU를 많이 확보했다”는 사실만으로는 부족합니다. AI PaaS는 GPU·스토리지·네트워크 위에 소프트웨어 계층을 올려 에이전트 친화적인 실행·운영 환경을 제공하고, 이를 통해 인프라 복잡성을 플랫폼 뒤로 숨깁니다. 결과적으로 서비스 팀은 인프라 튜닝 대신 에이전트 설계, 데이터 품질, 정책(가드레일)에 집중할 수 있습니다.
Software Infra 핵심 구성요소: GPU 스케줄링·LLMOps·AIOps의 통합
AI PaaS가 “혁신”인 이유는 단순 관리 콘솔이 아니라, 에이전틱 워크로드에 맞춘 운영 시스템을 통합 제공하기 때문입니다. 특히 다음 3가지 축이 핵심입니다.
1) GPU 지능형 스케줄링과 자원 최적화
전통적인 스케줄링이 GPU 사용률 중심이었다면, 에이전틱 AI에서는 워크로드 특성을 더 깊게 이해해야 합니다.
- 에이전트 그래프(작업 의존성)와 실행 단계에 따라 적절한 자원 배치
- 긴 컨텍스트 처리, 빈번한 I/O, 도구 호출 등 패턴을 반영한 워크로드-어웨어 스케줄링
- 멀티모달/LLM/추론·미세학습 워크로드가 섞인 환경에서 QoS와 비용 최적화를 동시에 달성
즉, AI PaaS는 “GPU를 빌려주는” 수준이 아니라, GPU를 가장 효율적으로 쓰게 만드는 Software Infra입니다.
2) End-to-End MLOps·LLMOps로 모델 운영을 자동화
에이전틱 AI에서는 모델이 자주 바뀌고(버전), 에이전트 구성이 바뀌며(툴/정책), 배포 단위도 더 촘촘해집니다. 따라서 운영 자동화는 선택이 아니라 필수입니다.
- 데이터 수집·전처리, 학습/미세조정, 배포, 롤백, 버전 관리
- 프롬프트/정책/도구 연결까지 포함하는 LLMOps 파이프라인
- 실험 추적, 평가(작업 성공률 중심), 모니터링을 한 흐름으로 통합
이 통합이 없다면 에이전트는 빠르게 늘어나는데, 운영은 수동 절차에 묶여 전체 속도가 급락합니다.
3) AIOps로 장애 대응과 용량 계획까지 “자동 운영”
에이전트가 상시 실행되는 환경에서는 로그·메트릭·트레이스가 폭증하고, 장애 원인도 복합적입니다. AIOps는 관제 데이터를 AI로 분석해 운영 비용을 줄입니다.
- 이상 징후 탐지, 장애 예측, 원인 후보 자동 제시
- 자동 티켓 생성, 런북(복구 스크립트) 실행 같은 셀프-힐링
- 수요 예측 기반 용량 계획으로 과잉 구축을 줄이고 비용 통제
결국 AI PaaS는 “AI를 돌리는 플랫폼”이 아니라, AI가 운영을 돕는 플랫폼으로 진화하고 있습니다.
Software Infra 관점의 안전장치: 에이전트가 ‘만지는’ 시스템을 어떻게 지킬 것인가
에이전트가 코드 저장소와 운영 환경을 직접 다루는 순간, 보안은 IAM만으로는 부족해집니다. 소프트웨어 인프라는 에이전트의 행동 자체를 제어·검증하는 방향으로 확장됩니다.
- Harness Engineering(하니스 엔지니어링): 에이전트가 할 수 있는 작업 범위, 접근 리소스, 변경 권한을 세밀하게 제한해 예측 가능성과 안전성을 확보
- Micro-Sandbox(마이크로 샌드박스): 에이전트가 생성한 코드를 실행할 때 일회성 경량 VM/컨테이너로 격리해, 사고 반경을 최소화
- 작업 기반 벤치마크: “출력 문장 품질”이 아니라 “업무를 성공했는가”로 테스트 체계를 전환해, 실제 운영 리스크를 낮춤
즉, 에이전틱 AI 시대의 Software Infra는 성능뿐 아니라 통제 가능한 자동화를 설계하는 기술로 재정의됩니다.
Software Infra의 결론: “GPU 경쟁”에서 “플랫폼 경쟁”으로
에이전틱 AI와 AI PaaS의 결합이 만들어내는 미래는 명확합니다. 앞으로 AI 경쟁력은 모델 하나의 성능이 아니라, 에이전트가 안전하고 효율적으로 일하도록 만드는 플랫폼, 그리고 이를 지속적으로 최적화하는 AI‑네이티브 Software Infra 역량에서 결정됩니다. 강력한 GPU는 출발점일 뿐이고, 승부는 그 위에서 돌아가는 AI PaaS가 가릅니다.
Software Infra 기반 AI‑네이티브 인프라 아키텍처의 기술적 심층 분석
AI 중심 데이터센터부터 자율 네트워크까지—에이전틱 AI가 “여러 에이전트가 계획→실행→검증→롤백”을 반복하는 순간, AI PaaS는 더 이상 GPU 임대 서비스가 아닙니다. 분산 인프라 위에서 GPU 스케줄링, MLOps/LLMOps, AIOps, 그리고 Micro‑Sandbox를 한 덩어리로 엮어 복잡한 에이전트를 통제 가능한 시스템으로 만드는 것이 핵심입니다. 이 섹션에서는 그 아키텍처를 레이어별로 분해해 봅니다.
Software Infra 관점의 컴퓨트 레이어: GPU 패브릭과 AI‑네이티브 데이터센터
에이전틱 워크로드는 “GPU를 많이”보다 “GPU를 잘 연결하고 잘 먹이는” 문제가 더 큽니다. 그래서 컴퓨트 레이어는 단순 서버 풀에서 AI‑네이티브 데이터센터로 이동합니다.
GPU 패브릭(고대역폭/저지연 네트워크) 중심 설계
대규모 모델 학습뿐 아니라, 다수 에이전트가 동시에 추론·툴콜·RAG·코드실행을 수행하면 통신 패턴이 급격히 복잡해집니다. 이때 병목은 GPU 자체보다 노드 간 통신, 스토리지 I/O, 동기화 지연에서 터집니다. AI 패브릭은 이런 병목을 줄이기 위해 네트워크를 “옵션”이 아니라 “코어 컴퓨트 자원”으로 취급합니다.전력·냉각·랙 구성까지 워크로드 기준으로 최적화
GPU 고밀도 랙과 액체냉각 같은 물리 혁신은 선택이 아니라, 장기적으로는 비용과 안정성을 좌우하는 변수입니다. 중요한 점은 AI PaaS가 이를 추상화하더라도, 플랫폼 팀은 물리 레이아웃과 배치 전략(예: 동일 랙/동일 포드 우선 배치)까지 고려한 스케줄링 정책을 가져야 한다는 것입니다.분산 배치(엣지/온프렘/멀티클라우드)로 확장되는 컴퓨트 도메인
추론은 엣지·온프렘으로 내려가고, 학습/파인튜닝은 중앙 클러스터에 남는 하이브리드가 늘어납니다. 즉, AI PaaS는 단일 클러스터가 아니라 여러 위치의 실행 환경을 묶는 분산 Software Infra로 진화합니다.
Software Infra 핵심인 GPU 지능형 스케줄링: “사용률”이 아니라 “에이전트 그래프”를 본다
전통적 스케줄링이 “남는 GPU 찾아 배치”라면, 에이전틱 시대 스케줄러는 워크로드의 구조를 이해해야 합니다. 이유는 간단합니다. 에이전트는 단일 추론 요청이 아니라, 연쇄적인 작업 그래프(DAG)로 움직이며 시스템 자원을 비동기적으로 잡아먹기 때문입니다.
스케줄러가 고려해야 하는 신호(예시)
- 컨텍스트 길이와 KV 캐시 압력: 긴 컨텍스트는 메모리 상주 비용이 커서 동시성 전략이 달라집니다.
- I/O 패턴: RAG가 많은 에이전트는 GPU보다 벡터DB/스토리지/네트워크 대역폭이 병목이 됩니다.
- 에이전트 단계별 우선순위: “계획 수립→코드 생성→테스트→배포” 중 어디가 지연되면 전체 리드타임이 폭발하는지에 따라 우선순위를 다르게 줘야 합니다.
- QoS/SLO 기반 할당: 서비스 등급(실시간/배치/실험)에 따라 프리엠션, 예약, 버스트 정책을 분리합니다.
결과적으로 달라지는 운영
- GPU는 하나의 리소스가 아니라 GPU + 네트워크 + 스토리지 + 캐시로 묶인 복합 자원으로 스케줄링됩니다.
- “최대 처리량”뿐 아니라 비용 대비 작업 성공률이 최적화 목표가 됩니다. (에이전트는 실패/재시도가 빈번하므로 단순 TPS 최적화가 무의미해지기 쉽습니다.)
Software Infra 플랫폼 레이어: MLOps·LLMOps·AIOps의 통합이 ‘에이전트 운영’의 본체
에이전틱 AI가 확산될수록 운영의 중심은 모델이 아니라 파이프라인과 거버넌스로 이동합니다. 플랫폼 레이어는 크게 세 축이 하나로 결합되는 형태로 발전합니다.
MLOps/LLMOps: 모델 수명주기의 “자동화된 기본값”
- 버전/실험 추적: 모델, 프롬프트, 툴 스펙, 데이터 스냅샷을 함께 고정하지 않으면 재현이 불가능합니다.
- 배포/롤백: 에이전트는 릴리즈 후에도 정책·툴·프롬프트 변경이 잦아 작은 변경의 빠른 롤백이 중요해집니다.
- 관측(Observability): 단순 응답 로그가 아니라, 에이전트 단계별 실행 기록(Plan/Act/Observe), 툴 호출, 외부 I/O까지 추적해야 합니다.
AIOps: 인프라가 스스로 이상을 감지하고 복구한다
에이전트 워크로드는 트래픽이 “예측 불가”하게 튀는 경우가 많습니다. AIOps는 로그·메트릭·트레이스를 학습해 다음을 자동화합니다.
- 장애 징후 조기 탐지(예: 특정 모델/노드에서만 지연 증가)
- 원인 후보 상관분석(네트워크 지연 ↔ 스토리지 큐 ↔ 특정 에이전트 툴콜)
- 자동 티켓/런북 실행(재시작, 격리, 스케일 아웃, 라우팅 변경)
요점은, AI PaaS가 제공하는 운영 자동화가 곧 에이전트 시스템의 안정성 엔진이라는 것입니다.
Software Infra 안전성 레이어: Harness Engineering과 Micro‑Sandbox로 ‘행동’ 자체를 제어
에이전트가 코드 저장소와 배포 파이프라인을 만지는 순간, 보안의 단위는 계정(IAM)이 아니라 행동(Action)으로 바뀝니다. 여기서 등장하는 표준 패턴이 Harness Engineering과 Micro‑Sandbox입니다.
Harness Engineering: “가능한 행동”을 설계한다
- 에이전트가 사용할 수 있는 툴, 접근 가능한 리포지토리 경로, 네트워크 egress, 파일시스템 권한을 작업 단위로 제한합니다.
- 승인 워크플로(예: PR 머지, 프로덕션 배포)는 자동화하되 사람 또는 정책 엔진의 게이트를 남깁니다.
- 에이전트의 출력이 아니라 행동 경로(어떤 파일을 수정했고 어떤 커맨드를 실행했는지)를 감사 가능하게 남깁니다.
Micro‑Sandbox: 실행을 “일회성 격리”로 표준화한다
에이전트가 생성한 코드를 실행하거나 패키지를 설치하는 순간, 공급망 공격/정보 유출/내부망 스캔 위험이 커집니다. Micro‑Sandbox는 이를 줄이기 위한 실행 기반입니다.
- 에페메랄(일회성) VM/컨테이너에서 코드 실행
- 최소 권한 네트워크(기본 egress 차단, 허용 목록 기반)
- 비밀정보는 런타임에만 주입하고 종료 시 폐기
- 아티팩트(로그, 테스트 결과, 변경 diff)만 외부로 반출
결과적으로 “에이전트가 무엇을 했는지”를 통제하는 Software Infra가 갖춰져야, 에이전틱 AI가 실제 운영 환경으로 들어갈 수 있습니다.
Software Infra 확장 포인트: 자율 네트워크와 브라우저 기반 실행 환경(Computer Use)
마지막으로 인프라는 더 넓어집니다.
자율 네트워크(Autonomous Ethernet)
QoS와 보안을 네트워크 패브릭에 내재화하고, 혼잡/지연을 AI가 자동 튜닝하는 방향이 강화됩니다. 에이전트 워크로드처럼 변동성이 큰 트래픽에서 특히 효과가 큽니다.브라우저‑기반 통합(Computer Use)
에이전트가 GUI를 직접 조작하면 레거시 시스템 통합이 “API 개발”에서 “브라우저 제어”로 이동합니다. 이때 필요한 것은 기능 개발이 아니라 샌드박스 브라우저 인프라(격리된 세션, DOM/네트워크/콘솔 제어, 녹화·감사)입니다. 즉, 브라우저조차 AI PaaS의 실행 런타임으로 편입됩니다.
AI‑네이티브 인프라 아키텍처의 결론은 단순합니다. 에이전틱 AI를 운영 가능한 제품으로 만들려면, AI PaaS는 분산 컴퓨트 + 지능형 스케줄링 + 통합 운영(MLOps/LLMOps/AIOps) + 행동 통제(Harness/Micro‑Sandbox)까지 포함하는 “Software Infra 스택”으로 완성되어야 합니다.
Software Infra 관점에서 본 에이전틱 AI 시대, 국내외 주요 플레이어의 혁신 전략
국내 클라우드 사업자부터 글로벌 벤더까지 공통적으로 던지는 메시지는 분명합니다. AI 인프라의 승부처가 ‘GPU를 얼마나 많이 보유했는가’에서 ‘에이전트를 얼마나 안정적으로 굴릴 플랫폼을 갖췄는가’로 이동하고 있다는 점입니다. 왜 이런 변화가 생겼을까요? 에이전틱 AI는 단일 모델 호출이 아니라, 여러 에이전트가 계획→실행→검증→롤백을 반복하며 시스템을 “운영”하기 때문에, 하드웨어 성능만으로는 비용·안정성·보안·운영 속도를 통제하기 어렵습니다. 결국 경쟁력의 중심은 AI PaaS와 AI‑네이티브 Software Infra(운영 자동화, 스케줄링, 안전성 레이어)로 옮겨갑니다.
Software Infra 트렌드: 하드웨어 중심에서 플랫폼 중심으로 이동하는 이유
플랫폼 중심 전환은 단순한 유행이 아니라 구조적 변화입니다.
- 워크로드가 ‘모델’에서 ‘에이전트 그래프’로 확장
에이전트는 LLM 호출뿐 아니라 코드 실행, 외부 도구 호출, 파일/DB I/O, 브라우저 조작까지 엮입니다. 그래서 인프라는 “GPU 사용률”이 아니라 전체 작업 흐름(그래프)의 병목을 기준으로 최적화해야 합니다. - 운영 비용의 대부분이 ‘자원 배치+장애 대응+품질 관리’로 이동
대규모 추론/에이전트 워크로드에서 비용 폭탄을 만드는 건 단순 GPU 단가가 아니라, 잘못된 스케줄링, 과도한 오토스케일, 반복 실패 작업입니다. 이를 잡는 핵심이 GPU 스케줄러, LLMOps, AIOps 같은 플랫폼 기능입니다. - 보안 경계가 ‘네트워크’에서 ‘행동 제어’로 확장
에이전트가 리포지토리와 프로덕션을 만지는 순간, 권한/IAM만으로는 부족합니다. Harness Engineering(허용 작업을 하니스로 제한) + Micro‑Sandbox(실행 격리)가 플랫폼 표준 레이어로 편입됩니다.
Software Infra의 국내 플레이어: “플랫폼·운영 역량이 모델보다 중요”로 재정의
국내에서는 에이전틱 AI 확산을 계기로, 클라우드 인프라의 무게중심이 HW에서 PaaS로 급격히 이동한다는 분석이 나옵니다. 특히 AI PaaS 논의에서 반복되는 핵심 축은 다음 3가지입니다.
- GPU 지능형 스케줄링: 멀티 모델/멀티 테넌시 환경에서 워크로드 특성(I/O 패턴, 컨텍스트 길이, 에이전트 단계)을 반영해 배치 최적화
- MLOps·LLMOps 통합 운영: 학습/배포/버전/롤백/실험 추적을 한 흐름으로 묶어 “모델 운영”을 제품화
- AIOps 기반 관제 자동화: 로그·메트릭·트레이스를 AI가 분석해 장애 예측, 자동 티켓, 복구 스크립트 실행까지 연결
또한 오케스트로가 제시한 AI 인프라 풀스택(가상화–클라우드 네이티브 운영–추론 운영의 체계화)처럼, 국내도 “인프라 구성요소를 개별 도입”하는 단계에서 벗어나 운영 표준을 포함한 풀스택 패키징으로 경쟁력을 만들려는 흐름이 강해지고 있습니다. 요지는 하나입니다. 에이전트가 늘어날수록, 결국 남는 차별점은 운영 자동화의 깊이입니다.
Software Infra의 글로벌 플레이어: AI‑네이티브 데이터센터와 ‘AI 패브릭’으로 풀스택 재설계
글로벌 벤더는 한 단계 더 아래(물리·네트워크)까지 내려가, AI를 기준으로 데이터센터 자체를 재설계합니다.
- AI‑네이티브 데이터센터: 랙·전력·냉각(액체냉각 포함)·네트워크를 AI 워크로드 전제로 최적화
- AI 패브릭 전환: 대규모 에이전트/초대형 모델을 위한 고대역폭·저지연 패브릭(개방형 고성능 이더넷 등) 요구 증가
- 자율형 네트워크: 보안과 QoS를 패브릭에 내재화하고, AI가 네트워크를 자율 튜닝하는 방향
Arm이 강조하는 엣지 AI·전력 효율·모듈화·원활한 연결 역시 같은 맥락입니다. AI PaaS가 클라우드 한 곳에만 존재하는 게 아니라, 엣지/온프렘/멀티 클라우드로 퍼지면서 분산 Software Infra로 진화하기 때문입니다.
Software Infra의 ‘풀스택 솔루션’이 감추는 비밀: 레이어 통합이 곧 성능과 비용
플레이어들이 말하는 “풀스택”의 본질은 단순 번들 판매가 아닙니다. 각 레이어가 서로의 신호를 공유하도록 통합하는 것이 핵심입니다.
- 스케줄러가 모델/에이전트 상태를 알아야 낭비를 줄이고,
- LLMOps가 배포/롤백 정책을 알아야 장애를 빠르게 줄이며,
- AIOps가 인프라 텔레메트리(로그·메트릭·트레이스)를 학습해 사전 대응하고,
- 안전성 레이어(하니스·샌드박스)가 에이전트의 실행 경로를 통제해야 사고를 막습니다.
즉, 에이전틱 AI 시대의 승자는 “GPU를 많이 가진 쪽”이 아니라, AI PaaS를 중심으로 Software Infra를 통합해 운영 표준을 만든 쪽입니다. 이 변화가 바로 지금, 하드웨어 중심에서 플랫폼 중심으로 시장의 축이 이동하는 이유입니다.
AI PaaS 도입을 가로막는 Software Infra 기술·운영적 쟁점과 해법
에이전틱 AI 환경에서 AI PaaS는 “모델을 띄우는 도구”가 아니라 비용·보안·운영 안정성의 승패를 가르는 Software Infra의 중심축입니다. 문제는, 이 전환이 생각보다 거칠다는 점입니다. GPU는 비싸고, 에이전트는 예측 불가능하며, 운영 복잡성은 급증합니다. 여기서는 현장에서 가장 자주 부딪히는 4가지 쟁점과, 이를 해결하기 위한 실전형 아키텍처/운영 메커니즘을 정리합니다.
Software Infra 쟁점 1: 비용 폭주 — “GPU를 더 사는 것”이 답이 아닌 이유
에이전틱 AI는 단발성 추론이 아니라 장시간 실행·반복 호출·다단계 툴 사용(검색/코드/브라우저/DB)을 전제로 합니다. 이때 비용은 GPU 사용률만으로 설명되지 않습니다. 병목은 대개 다음에서 발생합니다.
- 워크로드 변동성: 에이전트가 작업을 “계획→실행→검증”으로 반복하면서 토큰/컨텍스트/I/O가 요동
- I/O 및 네트워크 비용: 멀티모달·브라우저 제어·대규모 벡터 검색이 늘며 스토리지/패브릭 부하가 상승
- 낭비되는 GPU 시간: 대기, 재시도, 잘못된 계획으로 인한 루프가 누적되어 GPU 시간만 새는 구조
해법: 비용 최적화는 ‘스케줄러+정책’ 문제로 풀어야 합니다.
AI PaaS에서 핵심은 “GPU를 얼마나 쓰는가”가 아니라 “어떤 작업을 어떤 품질로 언제 실행할지”를 플랫폼이 결정하는 것입니다.
- 워크로드‑어웨어 GPU 스케줄링: GPU 점유율 중심이 아니라 컨텍스트 길이, KV 캐시 압력, 배치 가능성, I/O 패턴을 반영해 배치/우선순위 조정
- QoS/등급제 운영: 실시간(고우선)·배치(저비용)·실험(제한) 등으로 워크로드 등급을 나누고, 에이전트별 예산(토큰·시간·툴 호출)을 정책으로 강제
- 자동 스케일링의 기준 재정의: CPU/GPU 사용률이 아니라 작업 큐 지연, 에이전트 성공률, 재시도율 같은 “업무 지표”로 스케일 결정을 내림
- 서빙/추론 운영 최적화: 모델 라우팅(작은 모델→큰 모델로 단계적 승급), 캐싱, 프롬프트/컨텍스트 절감 정책을 플랫폼 레벨에서 제공
결론적으로 비용 통제는 애플리케이션 팀이 매번 튜닝하는 게 아니라, AI PaaS가 공통 정책으로 흡수해야 할 Software Infra 기능입니다.
Software Infra 쟁점 2: 보안과 프라이버시 — 에이전트는 “권한 있는 자동화”가 된다
에이전틱 AI의 가장 위험한 지점은, 에이전트가 리포지토리·CI/CD·클라우드 리소스·프로덕션 데이터까지 “행동”으로 건드릴 수 있다는 점입니다. 기존 IAM과 네트워크 경계만으로는 부족합니다. 왜냐하면 사고는 대개 접근이 아니라 행동(예: 잘못된 배포, 과도한 삭제, 데이터 유출성 쿼리)에서 발생하기 때문입니다.
해법: ‘에이전트 행동을 제어’하는 안전성 레이어가 필요합니다. 핵심은 Harness Engineering + Micro‑Sandbox입니다.
Harness Engineering(하니스 엔지니어링)
에이전트가 할 수 있는 일을 “프롬프트 지시”가 아니라 정책/제약/검증 루프로 구조화합니다. 예를 들면:- 툴 호출 화이트리스트(허용 API/도메인/명령만)
- 리포지토리 접근 범위 제한(읽기 전용, 특정 경로만 수정 가능)
- 변경 영향 분석(배포 전 diff 검사, 위험 파일 수정 차단)
- 승인 게이트(고위험 작업은 인간 또는 2차 에이전트 검토 후 진행)
Micro‑Sandbox(마이크로 샌드박스)
에이전트가 생성한 코드를 실행할 때 일회성 경량 VM/컨테이너에서 격리 실행하고, 실행 결과만 반출합니다.- 네트워크 egress 제한(데이터 유출 방지)
- 파일시스템/시크릿 최소 노출(최소권한)
- 실행 시간/리소스 상한(무한 루프·채굴형 악용 방지)
- 감사 로그/재현성 확보(사고 원인 추적 가능)
