Agent Swarms for Cyber Defense: 수십 개 에이전트가 동시에 코드·인프라 위험을 뒤지는 보안 자동화

Box CEO Aaron Levie는 여러 AI 에이전트를 한꺼번에 돌리는 agent swarm(에이전트 스웜)의 대표 용도가 사이버 방어가 될 것이라고 봅니다. 공격 경로를 지치지 않고 전부 시험하는 일은 잘게 쪼개 병렬로 돌리기 좋고, 그래서 보안이 대기업의 가장 큰 토큰 소비처가 됩니다. 우리 조직에 옮기려면 점검할 자산 범위, 읽기 전용 권한, 자산당 토큰 상한, 재현 검증 단계를 먼저 정해야 합니다.

요약

Aaron Levie는 2026년 10월 23일 X에 짧은 글을 올려, 사이버 방어용 agent swarm이 곧 AI의 가장 큰 범주 가운데 하나가 된다고 썼습니다. 그가 그린 모습은 셋입니다. 에이전트가 회사의 코드와 인프라를 검토하고, 가능한 위험의 조합을 빠짐없이 시험하고, 방대한 데이터를 처리하는 것입니다. 이 글은 같은 달 그가 이어 온 주장의 결론에 해당합니다. 10월 8일에는 앞으로 필요한 컴퓨트가 자릿수 단위로 늘어난다고 썼고, 13일에는 agent swarm이 기업 워크플로우의 핵심이 되며 그 가장 큰 수혜 영역이 사이버라고 썼습니다. 19일 CNBC 인터뷰에서는 스웜이 산업을 바꿀 수 있다고 말했습니다. 이 노트는 X 글 네 편과 인터뷰를 함께 읽어 정리했습니다. X 원문은 직접 열 수 없어 검색 결과에 노출된 본문과 Benzinga·Yahoo Finance 보도로 확인했고, 인터뷰는 공개된 요약 글을 기준으로 삼았습니다.

Levie의 주장: 보호할 자산과 공격 경로가 많을수록 스웜이 맞는 일이 됩니다.

보안이 스웜에 맞는 이유는 일의 모양에 있습니다. 보호할 자산은 IT 시스템, 소프트웨어, 물리 설비, 데이터로 넓고, 공격은 작은 틈을 여러 개 이어야 성립합니다. 그래서 점검은 자산과 경로마다 독립적으로 쪼갤 수 있고, 쪼갠 과제는 지치지 않는 에이전트 여러 개에 나눠 줄 수 있습니다. 사람이 고른 몇 개 시나리오만 보던 점검이 컴퓨트를 쓰는 만큼 넓어진다는 것이 요지입니다. 그 대가로 보안은 대기업에서 가장 많은 토큰을 쓰는 영역이 됩니다. 아래에서는 이 주장을 이루는 개념을 풀고, 통념과 다른 점과 사례를 정리한 뒤, 우리 보안팀이 코드·인프라 점검 스웜을 6주 안에 시범 운영하는 방법을 덧붙였습니다.

점검 범위를 사람의 시간이 아니라 컴퓨트가 정하게 된다는 것이 요지입니다.

핵심 메커니즘

Agent Swarm: 한 문제를 나눠 함께 푸는 에이전트 묶음

agent swarm은 에이전트가 많다는 뜻이 아니라, 여러 에이전트가 하나의 공유 문제를 나눠 맡고 결과를 서로 참고하며 푸는 방식입니다. Levie는 CNBC 인터뷰에서 이를 하나의 문제에 함께 달라붙는 에이전트 집단으로 설명하고, OpenAI가 한 과제에 약 10,000개 에이전트를 투입한 예를 들었습니다(인터뷰 요약 기준). 작동은 세 단계입니다. 큰 문제를 작은 과제로 분해하고, 과제마다 에이전트를 붙이고, 결과를 합쳐 다음 과제를 정합니다. 그는 이것이 6~12개월 전에는 실용적이지 않았고, 모델이 서로 협업할 만큼 똑똑해진 것이 최근의 변화라고 말합니다.

언제 쓰고 언제 안 쓰나는 분명합니다. 과제를 독립적으로 쪼갤 수 있고 쪼갠 조각이 많을 때 씁니다. 반대로 한 사람의 판단이 처음부터 끝까지 이어져야 하는 일, 또는 조각이 서로 강하게 얽혀 순서를 바꿀 수 없는 일에는 맞지 않습니다. 가상 예시로, 제조 기업이 공장 50곳의 OT 네트워크 설정을 점검한다면 공장마다 에이전트 하나를 붙이는 스웜이 맞지만, 한 공장의 사고 원인을 추적하는 일은 에이전트 하나가 끝까지 맡는 편이 낫습니다.

swarm은 에이전트 수가 아니라 "한 문제를 나눠 함께 푼다"는 점이 핵심입니다.

Parallelizable Problem: 보안이 스웜에 맞는 네 가지 조건

Levie가 10월 13일 글에서 든 이유는 보안이 병렬로 풀 수 있는 문제라는 점입니다(보도 기준). 첫째, 점검 대상이 자산과 경로마다 독립적이어서 쪼개기 쉽습니다. 둘째, 가능한 공격 경로를 하나하나 시험하는 일은 사람은 금세 지치지만 에이전트는 지치지 않습니다. 셋째, 실제 침투는 작은 시나리오를 여러 개 이어야 성립하는데, 에이전트는 그 연결을 반복해 시험할 수 있습니다. 넷째, 시험한 경로가 많을수록 안전의 폭이 넓어지므로 컴퓨트를 더 쓰면 결과가 곧바로 좋아집니다. 이 넷째 조건은 10월 23일 글의 뒷부분에 해당하는데, 검색 노출 본문이 잘려 있어 그 글을 인용한 다른 이용자의 글로 취지만 확인했습니다.

이 네 조건이 우리 조직의 어느 보안 업무에 맞는지 먼저 따져야 합니다. 코드 취약점 점검, 클라우드 설정 점검, 권한 조합 점검은 네 조건을 다 만족합니다. 반면 보안 정책 수립이나 사고 뒤 책임 판단은 쪼갤 수 없고 컴퓨트를 더 써도 좋아지지 않습니다.

네 조건이 모두 맞는 영역이 드물다는 것이 Levie의 관찰입니다.

Three Swarm Workloads: 코드·인프라 검토, 위험 조합 전수 시험, 대량 데이터 처리

10월 23일 글이 꼽은 세 가지 작업은 입력과 출력이 다릅니다. 코드·인프라 검토는 소스 저장소, IaC(infrastructure as code, 서버·네트워크 설정을 코드로 적어 둔 것), 클라우드 설정을 읽어 취약한 코드와 잘못된 권한을 냅니다. 위험 조합 전수 시험은 알려진 약점과 설정 상태를 입력으로 받아 침투가 성립하는 연결 경로를 냅니다. 대량 데이터 처리는 로그, 이벤트, 자산 목록을 읽어 이상 징후와 노출된 자산을 냅니다. 셋을 한 스웜에 섞지 않고, 작업마다 과제 분해 기준과 출력 형식을 따로 두는 것이 운영의 시작입니다.

세 작업은 입력이 다르고 출력도 다르므로 따로 설계합니다.

Token Budget: 보안이 대기업 최대 토큰 소비처가 되는 이유

Levie는 10월 8일 글에서 다가오는 단계의 컴퓨트 수요를 여러 워크로드로 나열했습니다. 개인 에이전트, 기업을 방어하는 스웜, 모든 코드를 보안 관점에서 검토하는 에이전트, 거의 모든 기업 데이터를 워크플로우 안에서 처리하는 에이전트, 24시간 돌아가는 배경 에이전트입니다. 추론 양이 자릿수 단위로 커지고, 에이전트에는 토큰 말고도 컴퓨터, 네트워크, 파일 시스템 같은 인프라가 따로 붙는다고 썼습니다. 13일 글에서는 보안이 대기업의 가장 큰 토큰 소비처 가운데 하나가 된다고 했습니다. 보호할 자산이 많고 점검이 상시로 돌기 때문입니다.

경영자 관점에서 이 메커니즘은 보안 예산의 모양을 바꿉니다. 지금까지 보안 예산은 라이선스와 인력, 연 1~2회 외주 점검이었습니다. 스웜은 사용량 비례 비용이고, 점검 범위를 넓히는 결정이 곧 비용을 늘리는 결정이 됩니다. 그래서 자산당 토큰 상한과 일일 총상한을 처음부터 두어야 합니다.

Levie는 보안이 대기업에서 가장 큰 토큰 소비처 가운데 하나가 된다고 봅니다.

Governed Data Layer: 스웜과 회사 데이터 사이의 통제 층

CNBC 인터뷰 요약에 따르면 Levie는 에이전트가 다루는 회사 데이터를 통제하는 층으로 Box를 자리매김하고, 사람이 판단 고리 안에 남는다고 말했습니다. 스웜은 수십에서 수천 개 에이전트가 회사 데이터를 읽고 쓰는 일이므로, 누가 어떤 데이터를 볼 수 있고 무엇을 했는지 기록하는 층이 없으면 방어 도구가 새 공격 표면이 됩니다. 이 층은 에이전트의 자격 증명, 접근 범위, 행동 기록을 한곳에서 관리하고, 최종 조치는 사람이 승인하는 구조입니다. 우리 조직에서는 기존 IAM(identity and access management, 계정과 권한 관리)과 데이터 플랫폼의 권한 체계를 에이전트에도 그대로 적용하는 것이 출발점입니다.

CNBC 인터뷰 요약 기준: Box는 에이전트가 다루는 회사 데이터를 통제하는 층을 자처합니다.

통념과 다른 주장

흔히 이렇게 봅니다AI는 공격자에게 먼저 유리하다. 에이전트가 모든 틈을 뒤질 수 있으니 공격 표면이 폭발하고 방어는 뒤따라갈 뿐이다.

저자는 이렇게 봅니다같은 힘이 방어에도 작동하며, 사이버 방어용 스웜이 AI의 가장 큰 범주 가운데 하나가 됩니다.

근거Levie 자신도 10월 13일 글에서 에이전트 때문에 공격 표면이 100배로 늘어난다고 썼습니다. 그러나 지치지 않고 모든 경로를 시험하는 능력은 방어 쪽이 더 많은 자산에 걸쳐 쓸 수 있고, 컴퓨트를 더 쓰면 안전의 폭이 바로 넓어진다고 봅니다(검색 노출 본문, 보도, 그 글을 인용한 다른 이용자의 글 기준).

Levie 자신도 공격 표면이 늘어난다고 보지만, 같은 힘이 방어에도 작동한다고 봅니다.

흔히 이렇게 봅니다AI 에이전트는 사람 한 명을 돕는 비서다. 한 번에 하나씩 일하고, 돈을 내는 쪽은 소비자다.

저자는 이렇게 봅니다에이전트의 단위는 개인 비서가 아니라 스웜이고, 스웜은 기업 워크플로우의 핵심이 됩니다. 돈을 내는 쪽도 기업입니다.

근거CNBC 인터뷰 요약 기준으로, OpenAI가 한 과제에 약 10,000개 에이전트를 협업시킨 예와, 소비자는 에이전트에 직접 돈을 내지 않겠지만 기업은 가치가 분명해지면 낼 것이라는 그의 전망입니다.

CNBC 인터뷰 요약 기준: 모델이 협업할 만큼 똑똑해진 것은 최근 6~12개월의 변화라고 말합니다.

저자가 든 사례

OpenAI의 10,000개 에이전트 협업

상황: 여러 에이전트가 한 과제를 함께 푸는 일은 6~12개월 전에는 실용적이지 않았습니다. 모델이 그만큼 똑똑하지 않았기 때문입니다.
한 일: Levie는 OpenAI가 하나의 공동 과제에 약 10,000개 에이전트를 투입해 서로 협업시킨 예를 들었습니다.
결과: 에이전트끼리 실제로 협업할 수 있음을 보여 준 사례로 소개했습니다. 과제의 내용과 결과 수치는 요약에서 밝히지 않았습니다.
연결: Agent Swarm의 사례이자, 통념과 다른 주장 2(에이전트의 단위)의 근거입니다. CNBC 인터뷰의 공개 요약을 기준으로 재구성했습니다.

CNBC 인터뷰 요약 기준으로 재구성했습니다.

2026년 10월, 네 편의 글로 좁혀진 주장

상황: AI 컴퓨트 투자가 과하다는 논쟁이 이어지던 10월 초, Levie는 한 기술 임원의 컴퓨트 추정 글에 답하는 형식으로 글을 시작했습니다(Yahoo Finance 보도 기준).
한 일: 10월 8일 컴퓨트 수요, 13일 스웜과 사이버, 19일 CNBC 인터뷰, 23일 사이버 방어 스웜으로 주장을 좁혀 갔습니다.
결과: 사이버 방어가 스웜의 대표 용도이자 대기업 최대 토큰 소비처라는 결론에 이르렀습니다. 각 글의 반응 수치와 시장 영향은 이 노트에서 다루지 않습니다.
연결: Token Budget과 Three Swarm Workloads의 사례입니다.

2주 사이에 컴퓨트 → 스웜 → 보안으로 주장이 좁혀집니다. 날짜는 미국 기준입니다.

기술 디테일: 코드·인프라 점검 스웜을 돌리려면

아래는 Levie의 주장을 우리 조직에서 실제로 돌릴 때 필요한 구조와 설정으로, AX Review가 새로 작성했습니다. 숫자는 모두 가상 예시입니다.

Agent Swarm을 보안 점검에 돌리려면 네 층으로 나눕니다. 오케스트레이터가 자산 목록(저장소, IaC 모듈, 클라우드 계정, 권한 역할)을 과제 단위로 분해하고 과제마다 범위, 자격 증명, 토큰 예산을 배정합니다. 워커 에이전트는 과제 하나를 받아 점검하고 아래 형식의 finding을 냅니다. 검증 에이전트는 finding을 샌드박스에서 재현해 verified를 붙입니다. 트리아지 단계는 asset·finding_type·location이 같은 finding을 하나로 묶고 심각도를 매겨 사람에게 넘깁니다. 한 과제가 한 에이전트, 한 finding 묶음으로 이어지게 두면 비용과 결과를 과제 단위로 추적할 수 있습니다.

{
  "finding_id": "F-2026-1105-0042",
  "task_id": "T-repo-payments-api",
  "asset": "github.com/acme/payments-api",
  "finding_type": "secret_in_code | iam_overpermission | injection | misconfig | exposed_asset",
  "location": "src/billing/client.py:88",
  "severity": "critical | high | medium | low",
  "evidence": "하드코딩된 결제 API 키가 로그에 출력됨",
  "reproduction": ["샌드박스에서 키 유효성 확인", "읽기 전용 호출 1회 성공"],
  "status": "candidate | verified | false_positive",
  "confidence": 0.82,
  "tokens_used": 41200,
  "model": "fast | strong",
  "checked_at": "2026-11-05T02:10:00Z"
}

한 과제 = 한 에이전트 = 한 finding 묶음으로 두면 비용과 결과를 추적하기 쉽습니다.

Parallelizable Problem의 네 조건을 설정값으로 옮기면 모델은 두 단으로 둡니다. 1차 전수 스캔은 빠르고 싼 모델로 temperature 0에서 돌리고, 침투 경로를 잇는 2차 탐색은 강한 모델로 temperature 0.3~0.7에서 3회 반복해 서로 다른 경로를 찾게 합니다. 3회 결과가 모두 다른 finding이면 경로가 많다는 뜻이므로 반복을 5회로 늘리고, 3회가 모두 같으면 멈춥니다. 자산당 토큰 상한(예: 저장소 하나 50만 토큰)과 일일 총상한을 두고, 초과하면 과제를 중단하고 tokens_used를 기록합니다. 모든 자격 증명은 읽기 전용이고, 재현은 운영 환경을 복제한 샌드박스에서만 합니다. 재현에 성공한 finding만 verified로 올리고, 나머지는 candidate로 남겨 주 1회 묶어 봅니다.

숫자는 가상 예시이며, 조직의 자산 수와 예산에 맞춰 정합니다.

Three Swarm Workloads 가운데 어디서 시작하나. 코드·인프라 검토가 가장 쉽습니다. 입력이 저장소와 IaC로 정해져 있고, 기존 정적 분석 도구(SAST, 소스 코드를 실행하지 않고 취약점을 찾는 도구)의 결과와 바로 비교할 수 있기 때문입니다. 위험 조합 전수 시험은 두 번째입니다. 1차 검토의 finding과 권한 그래프를 입력으로 받아 “이 틈과 저 틈을 이으면 어디까지 가나”를 탐색하므로 1차가 있어야 돌아갑니다. 대량 데이터(로그) 처리는 데이터 양이 커서 비용이 가장 빨리 늘어나니 마지막에 둡니다.

Token Budget을 미리 재려면 비용은 “자산 수 × 자산당 평균 토큰 × 점검 주기 × 토큰 단가”입니다. 가상 예시로 저장소 200개, 저장소당 30만 토큰, 주 1회 점검, 100만 토큰당 3달러면 주 180달러, 연 약 9,400달러입니다. 2차 경로 탐색은 강한 모델이라 단가가 5~10배이므로 1차에서 severity가 high 이상인 자산에만 돌립니다. 이 계산을 시범 운영 뒤 실제 tokens_used 합계로 바꿔 넣으면 확대 비용이 나옵니다.

실패 양상과 대응. 스웜의 위험은 놓치는 것보다 쏟아지는 것에 있습니다. 같은 버그를 수십 개 에이전트가 따로 보고하면 묶음 규칙으로 하나로 합칩니다. 재현되지 않는 추정 보고가 쌓이면 verified만 사람에게 올립니다. 에이전트가 운영 시스템을 건드리는 일은 읽기 전용 권한과 샌드박스로 막고, 접근 기록을 Governed Data Layer에서 남깁니다. 비용 초과는 자산당 상한과 일일 총상한으로 끊습니다.

스웜의 위험은 놓치는 것보다 쏟아지는 것에 있습니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	6주 동안 하는 일
스폰서	CISO	범위·권한 원칙 승인, 판정 보고 수령
점검 운영	AppSec 또는 보안 엔지니어 1~2명	스웜 구성, 과제 분해, finding 검증
플랫폼	클라우드·DevOps 담당 1명	읽기 전용 자격 증명, 샌드박스 준비
데이터·권한	IAM 담당 1명	에이전트 계정 발급, 접근 기록 확인
비용	FinOps 또는 재무 1명	토큰 상한 설정, 비용 집계
법무·컴플라이언스	담당 1명	코드·로그를 외부 모델에 보내는 조건 확인

시작 전 준비물: 점검 대상 저장소·IaC·클라우드 계정 목록(처음엔 50~200개), 기존 SAST·클라우드 설정 점검 도구의 최근 결과(비교 기준), 읽기 전용 자격 증명과 샌드박스 환경, 외부 모델에 보낼 수 있는 데이터 범위 결정, 자산당·일일 토큰 상한.

주차	할 일	산출물
1주	자산 목록 확정, 데이터 반출 조건 확인	범위 문서
2주	읽기 전용 계정·샌드박스·토큰 상한 설정	권한·예산 설정표
3주	1차 전수 스캔 1회 실행	finding 목록(candidate)
4주	2차 경로 탐색, 기존 도구 결과와 비교	비교표, 신규 발견 목록
5주	재현 검증, 중복 묶기, 비용 집계	verified 목록, 비용표
6주	판정 보고, 확대 범위 결정	판정 보고서

6주 시범 운영 일정. 첫 실행 전에 범위와 권한을 먼저 고정합니다.

확인 질문(보안팀장용): 지난 1년 외주 점검이 찾은 취약점 가운데 우리 스캐너가 놓친 것은 몇 건입니까? 저장소와 클라우드 계정 가운데 소유자가 불분명한 자산은 몇 개입니까? 코드와 로그를 외부 모델에 보내도 되는 범위를 정한 문서가 있습니까? 에이전트 전용 계정을 발급하고 기록을 남길 수 있습니까? 재현용 샌드박스를 2주 안에 만들 수 있습니까? 보안 예산에 사용량 비례 항목을 둘 수 있습니까?

진행 판정 기준(예시): 기존 도구가 못 찾은 verified finding이 3건 이상이고, 중복 제거 뒤 사람이 검토한 건수가 50건 이하이고, 자산당 비용이 외주 점검 단가의 절반 이하면 범위를 늘립니다. verified가 0~2건이거나 미재현 보고가 70%를 넘으면 과제 분해와 모델 설정을 고쳐 한 번 더 돌립니다. 운영 환경 접근 기록이 1건이라도 나오면 권한 설계를 다시 하기 전까지 멈춥니다.

판정 기준(예시). 숫자는 조직에 맞게 정합니다.

AX 적용 제언. 이 주장이 가장 쓸모 있는 곳은 저장소와 클라우드 계정이 수백 개 넘게 흩어진 금융·제조 대기업과, 고객사 시스템을 대신 운영하는 SI·MSP 기업입니다. 두 곳 모두 외주 점검은 연 12회에 그치고 사이 기간은 스캐너에 맡기고 있습니다. 순서는 코드·인프라 검토 → 위험 조합 탐색 → 로그 처리가 무난하고, 첫 범위는 결제·인증처럼 사고 비용이 큰 시스템 2050개로 좁힙니다. CISO 혼자 결정하기 어려운 지점이 둘 있습니다. 코드와 로그를 외부 모델에 보내는 조건은 법무가, 사용량 비례 예산 항목은 CFO가 같이 들어와야 합니다. 그래서 이 과제는 보안팀 도구 도입이 아니라 CISO·CFO·법무가 함께 서명하는 6주 시범 운영으로 올리는 편이 통과가 빠릅니다.

원문 사례

항목	내용
원문	Aaron Levie(Box CEO) X 게시물, 2026.10.23(미국 기준). 검색 결과에 노출된 본문으로 확인, 끝부분은 잘림
핵심 주장	사이버 방어용 agent swarm이 AI의 가장 큰 범주 가운데 하나가 된다
세 가지 작업	코드·인프라 검토, 위험 조합 전수 시험, 대량 데이터 처리
앞선 글 10.13	스웜은 기업 워크플로우의 핵심. 병렬로 쪼갤 수 있는 문제에 맞음. 사이버가 최대 수혜, 대기업 최대 토큰 소비처(Benzinga 보도 기준)
앞선 글 10.8	컴퓨트 수요가 자릿수 단위로 증가. 방어 스웜, 코드 검토, 기업 데이터 처리, 24시간 배경 에이전트. 토큰 외에 컴퓨터·네트워크·파일 시스템 필요(Yahoo Finance 보도 기준)
CNBC 인터뷰 10.19	스웜 = 한 문제에 함께 붙는 에이전트 집단. 6~12개월 전엔 모델이 부족. OpenAI 약 10,000개 에이전트 예. 스웜은 공격에도 먼저 쓰일 수 있음. 신약 탐색·트레이딩도 초기 용도. 돈은 기업이 냄. Box는 데이터 통제 층(공개 요약 기준, 영상은 보지 않음)
수치	약 10,000개 에이전트, 6~12개월, 공격 표면 100배(10.13 글)
밝히지 않은 것	구체 제품, 고객 사례, 비용 수치

핵심 개념

agent swarm: 여러 AI 에이전트가 하나의 문제를 나눠 맡고 결과를 주고받으며 함께 푸는 방식.
permutation of risk(위험 조합): 약점과 설정 상태를 여러 개 이어 만들 수 있는 공격 경로의 모든 조합.
token(토큰): 모델이 읽고 쓰는 글자 단위. 사용량 비례 비용의 기준.
IaC(infrastructure as code): 서버·네트워크·권한 설정을 코드로 적어 저장소에서 관리하는 방식. 에이전트가 읽어 점검할 수 있다.
SAST: 소스 코드를 실행하지 않고 취약점을 찾는 정적 분석 도구. 스웜 결과의 비교 기준.
IAM: 계정과 권한을 관리하는 체계. 에이전트에도 사람과 같은 기준을 적용한다.
sandbox(샌드박스): 운영 환경을 복제해 격리한 시험 환경. finding 재현은 여기서만 한다.
triage(트리아지): 쏟아진 finding을 묶고 심각도를 매겨 사람이 볼 순서를 정하는 단계.

내 메모

TODO: 내 생각 추가

원문: Aaron Levie(Box CEO), X 게시물(2026.10.23). X는 직접 열 수 없어 검색 결과에 노출된 본문으로 확인했으며 끝부분은 잘려 있습니다. 10월 13일·8일 글은 Benzinga(Snigdha Gairola, 2026.10.13)와 Yahoo Finance(Brian Sozzi, 2026.10.8) 보도로, 10월 19일 CNBC Closing Bell Overtime 인터뷰는 공개된 요약 글(Scuttlebutt, 2026.10.20)로 확인했고 영상은 보지 않았습니다. 요약·메커니즘·통념과 다른 주장·사례는 이 자료에 실린 Levie의 발언을 AX Review가 다시 정리한 것입니다. 기술·현업 디테일, JSON 예시, 비용 계산, 일정·판정 기준, 인포그래픽, 표는 새로 작성한 것이며 숫자는 가상 예시입니다. 원문 전체는 X와 CNBC에서 볼 수 있습니다.