최초의 에이전트 중심 (Agent-Centric) 클라우드 보안 플랫폼 — 그리고 왜 우리가 의도적으로 그렇게 만들지 않았는가

Stave의 파이프라인에 있는 모든 경계에는 기계가 검증 가능한 계약 (Contract)이 존재합니다. 우리는 이를 1인 개발자의 생산성을 위해 구축했습니다. 그런데 이것이 정확히 에이전트 (Agents)가 필요로 하는 것이 되었습니다. CLI 도구가 플랫폼이 된 것입니다. 이것이 왜 클라우드 보안 프로그램을 운영할 수 있는 사람의 범위를 바꾸는지 설명하겠습니다.

저는 에이전트를 위한 클라우드 보안 플랫폼을 만들려고 시작한 것이 아니었습니다. 제 목표는 한 사람이 유지 관리할 수 있는 CLI 도구를 만드는 것이었습니다. 그 이후에 내려진 결정들 — 독자적인 포맷 대신 표준 JSON Schema 사용, 산문 형태의 출력 대신 종료 코드 (Exit codes) 사용, 확률적 점수 산정 대신 결정론적 평가 (Deterministic evaluation) 사용, 모놀리스 (Monolith) 대신 작고 조합 가능한 도구 사용 — 은 모두 인간의 생산성을 위해 내려진 결정이었습니다. 한 사람이 독자적인 스키마를 유지 관리하거나, 비결정론적 출력을 디버깅하거나, 모놀리스를 관리할 수는 없기 때문입니다.

14개월 후, 저는 다섯 번의 독립적인 실험을 진행했습니다. 에이전트들에게 추론 사양 (Reasoning specification)과 Stave의 데이터 내보내기 (Data export)를 제공했습니다. 구현 코드는 주지 않았습니다. 사양 외의 문서도 제공하지 않았습니다. 힌트도 없었습니다. 에이전트들은 다섯 가지 서로 다른 추론 엔진 — Z3 (수학적 증명), Soufflé (영향 범위 열거), Clingo (위반 탐지), Prolog (증명 트리), 그리고 PRISM (리스크 확률) — 에 대해 정확한 보안 판결을 내렸습니다. 범위: 이 증명은 내보내진 SIR 사실 (Facts)의 범위 내에서 유효합니다; Fact Export는 SIR이 현재 커버하는 속성 도메인을 참조합니다. 두 번의 실험은 완전히 블라인드 테스트였습니다 — 사전 맥락이 전혀 없는 새로운 에이전트들이었습니다. 둘 다 통과했습니다.

저는 첫날부터 에이전트 지원을 목표로 하지 않았습니다. 아키텍처가 그것을 만들어냈습니다.

에이전트 중심 (Agent-centric)이 의미하는 것
모든 보안 벤더가 AI를 추가하고 있습니다. 발견 사항을 요약하는 코파일럿 (Copilots). 보안 태세에 관한 질문에 답하는 챗봇 (Chatbots). 해결 단계를 제안하는 LLM (Large Language Models). 이것들은 유용한 기능들입니다. 하지만 동시에 기존 아키텍처 위에 얹어진 장식들이기도 합니다. 에이전트 중심이라는 것은 에이전트가 단순히 그것에 대해 질문에 답하는 것을 넘어, 파이프라인을 직접 구축할 수 있음을 의미합니다. 이 차이는 AI를 탑재한 도구와, 에이전트가 그 위에서 개발할 수 있는 도구 사이의 차이입니다.

테스트는 간단합니다. 귀하의 소스 코드를 한 번도 본 적 없는 에이전트가 귀하가 공개한 계약(contracts)만으로 정확한 결과를 생성할 수 있는가? 만약 그렇다면, 그 도구는 에이전트 중심(agent-centric)입니다. 만약 에이전트가 구현 코드(implementation code), 내부 문서, 또는 인간의 가이드가 필요하다면, 그 도구는 인간 의존적인 아키텍처에 AI 기능이 덧붙여진(bolted onto) 것에 불과합니다. stave는 이 테스트를 통과했습니다. 그것도 다섯 번이나, 두 번의 블라인드 테스트(blind runs)를 통해 말이죠.

작동을 가능하게 하는 계약(contracts)
파이프라인의 모든 경계(boundary)는 세 가지 속성을 가집니다:

1. 기계 판독 가능 사양 (Machine-readable specification). 문서가 아닙니다. 에이전트가 파싱하고, 이해하며, 이에 부합하는 출력을 생성할 수 있는 JSON Schema 또는 YAML 파일입니다.
2. 이진 단언 (Binary assertion). 해당 단계는 성공했거나, 그렇지 않거나 둘 중 하나입니다. stave validate --strict는 0 또는 0이 아닌 값으로 종료됩니다. stave apply는 결과(findings)를 생성하거나 생성하지 않습니다. 주관적인 품질 판단은 없습니다. "이게 맞아 보이나요?"와 같은 질문도 없습니다. 코드를 작성하는 에이전트는 확률적(probabilistic)이지만, 에이전트가 목표로 하는 계약은 결정론적(deterministic)입니다. 플랫폼은 엄격한 피드백 루프를 제공합니다. 에이전트는 계약에 의해 정의된 이진 "성공(success)" 상태에 도달할 때까지 반복합니다. 플랫폼은 확률적인 에이전트를 위한 결정론적인 샌드박스(sandbox)입니다.
3. 실패 시 실행 가능한 오류 (Actionable error on failure). 단언(assertion)이 실패하면, 오류는 잘못된 특정 필드와 기대되었던 값이 무엇인지 명시합니다. 에이전트는 오류를 읽고, 필드를 수정하고, 다시 시도합니다. 인간의 해석이 필요하지 않습니다.

이러한 계약들을 적용한 파이프라인의 모습은 다음과 같습니다:

Steampipe 테이블 스키마 → 공개된 매핑 YAML (에이전트가 컬럼명 읽음) (에이전트가 field_map 읽음)
↓
stave validate --strict (단언: exit 0인가?)
↓
stave apply (단언: 결정론적 결과 생성 여부)
↓
stave export-sir (SIR: Stave Intermediate Representation — JSONL triples / SMT-LIB 단언)
↓
reasoning-spec YAML (에이전트가 로직을 엔진 코드로 매핑)
↓
정답 비교 (golden answer comparison) (단언: 일치하는가?)

모든 화살표는 계약입니다. 모든 계약은 기계 판독이 가능합니다. 모든 단언은 이진적입니다.

에이전트는 개발자가 수행하는 것과 동일한 방식으로 이 파이프라인을 통과합니다. 다만 에이전트는 "이것이 맞는가?"라고 물을 필요가 없는데, 계약 (contracts)이 그 질문에 자동으로 답하기 때문입니다.

다섯 번의 실험이 증명한 것
우리는 추론 명세 (reasoning specifications)를 작성했습니다. 이는 보안 질문, 입력 데이터, 단계별 추론 체인 (reasoning chain), 그리고 예상 출력 형식을 기술하는 YAML 파일입니다. 추론 명세는 구현 코드 (implementation code)가 아닌 논리적 제약 조건 (logic constraints)을 정의합니다 (예: "정책이 AllUsers 주체를 허용하면 버킷은 공개 상태이다"). 에이전트의 역할은 이러한 논리적 제약 조건을 대상 엔진 (target engine)의 특정 구문(syntax) — Soufflé Datalog, Z3 SMT-LIB, Clingo ASP 원자 (atoms) — 으로 변환하는 것이었습니다. 우리는 예상 정답을 제거했습니다. 그리고 우리 코드베이스에 접근 권한이 없는 에이전트들에게 명세와 입력 데이터만을 제공했습니다.

실험	엔진	질문	Blind 여부	결과
1	Z3	"익명 사용자가 이 S3 버킷에 접근할 수 있는가?"	동일 세션	통과 (PASS) — 정확한 판결 + SAT 증거 (attack path)
2	Soufflé	"익명 ID가 접근할 수 있는 리소스는 몇 개인가?"	동일 세션	통과 (PASS) — 개수: 12 (바이트 단위 일치)
3	Clingo	"이 설정에서 어떤 위반 규칙이 실행되는가?"	Blind	통과 (PASS) — 4개의 위반 사항 모두 정확함
4	Prolog	"이 공격 경로 (attack path)에 대한 증명 트리 (proof tree)는 무엇인가?"	Blind	통과 (PASS) — 12개의 증명 트리 모두 정확함
5	PRISM	"성공적인 공격 (exploitation)의 확률은 얼마인가?"	동일 세션	통과 (PASS) — 0.412 (±0.005 이내)

다섯 번의 실험 중 두 번은 실제 결함을 잡아냈습니다. 하나는 명세 (spec)에서, 다른 하나는 우리의 테스트 스위트 (test suite)에서 발생한 것이었습니다. 프레임워크는 이를 자동으로 분류했습니다. 엔진과 에이전트의 의견은 일치하지만 정답 (golden answer)이 다를 경우, 우리는 테스트 스위트에서 인간의 전사 오류 (human transcription error)를 발견했습니다 (정확한 개수는 12인데 6으로 작성되어 있었습니다). 에이전트의 출력이 엔진의 실제 어휘 (vocabulary)와 일치하지 않을 경우, 우리는 명세의 모호성 (spec ambiguity)을 발견했습니다 (명세에는 mfa_enforced라고 되어 있었으나, export에서는 has_mfa_enforced를 사용하고 있었습니다). 계약 (contracts) 덕분에 에이전트가 우리의 테스트 방법론 자체를 디버깅할 수 있었습니다. 공개된 계약만으로 에이전트가 정확한 보안 추론을 생성할 수 있다는 증거를 발표한 보안 플랫폼은 아직 없습니다.

이것이 기업에 가져오는 변화

이전: 팀의 문제
전통적으로 클라우드 보안 태세 관리 (CSPM)를 배포하려면 다음이 필요합니다:

• 스캐너를 구성할 보안 엔지니어 (Security Engineer)
• 발견된 결과(findings)를 해석할 클라우드 아키텍트 (Cloud Architect)
• 발견된 결과를 프레임워크에 매핑할 컴플라이언스 분석가 (Compliance Analyst)
• CI/CD에 통합할 DevOps 엔지니어 (DevOps Engineer)
• 조치 우선순위를 정할 관리자 (Manager)

다섯 개의 역할. 매달 발생하는 지속적인 비용. 비용에서 도구가 차지하는 비중은 가장 작습니다. 이를 운영하는 팀이 실제 비용입니다. 스타트업이 CSPM을 건너뛰는 이유가 바로 이것입니다. 도구 비용이 5만 달러라서가 아니라, 이를 운영할 팀 비용이 50만 달러이기 때문입니다.

이후: 에이전트의 문제
에이전트 중심 (Agent-centric) 아키텍처를 사용하면, 한 명의 엔지니어가 에이전트들을 지시하며 동일한 파이프라인을 실행할 수 있습니다:

엔지니어: "Steampipe를 우리 AWS 계정에 연결하고 S3 및 IAM에 대한 Stave 관찰값(observations)을 생성해줘."
에이전트 1:

• contracts/steampipe/aws_s3_bucket.yaml 읽기
• contracts/steampipe/aws_iam_role.yaml 읽기
• Steampipe에 쿼리하고, 출력을 변환하며, 검증하여 → 유효한 관찰값 생성

엔지니어: "복합 위험(compound risks)을 평가해서 보여줘."
에이전트 2:

• stave apply 실행 → 결과 도출
• stave gaps 실행 → 누락된 사항 확인 → 우선순위가 지정된 결과 + 격차 보고서(gap report) 생성

엔지니어: "PHI(개인 건강 정보)에 대한 익명 접근이 가능한지 증명해봐."
에이전트 3:

• reasoning-specs/z3-public-read-bucket/spec.yaml 읽기
• stave export-sir 실행 → SMT-LIB 사실(facts) 생성
• 추론 단계 수행 → SAT/UNSAT 판정 → 수학적 증명

엔지니어: "발견된 결과를 HIPAA 기술적 보호 조치(Technical Safeguards)에 매핑해줘.
에이전트 4:

• 컴플라이언스 프로필 읽기 → 요구사항 매핑
• 요구사항별로 결과를 집계하여 → 컴플라이언스 상태 보고서 생성

한 명의 엔지니어. 네 명의 에이전트. 모든 단계에 기계로 검증 가능한 계약(contract)이 있기 때문에 에이전트들이 작동하는 것입니다. 엔지니어의 업무는 도구를 운영하는 것에서 에이전트를 지시하고 결과를 검토하는 것으로 전환됩니다. 보안 전문 지식은 여전히 인간의 영역입니다. 즉, 어떤 질문을 던질지, 어떤 결과가 가장 중요한지, 그리고 비즈니스 맥락을 판단하는 일입니다. 수집, 변환, 평가, 내보내기, 추론과 같은 기계적인 작업은 에이전트가 실행합니다.

인력 산정 방식이 변화합니다:

구분	전통적인 CSPM	에이전트 중심 (Agent-centric) CSPM
인력 비용	5개 역할 × $150K = $750K/년	1명의 보안 아키텍트 (에이전트 오케스트레이터) × $200K = $200K/년
도구 비용	$50K-$100K	$0 (오픈 소스)
가치 실현 시간 (Time to value)	3-6개월	며칠
확장 방식	채용을 통한 확장	에이전트 추가를 통한 확장

이는 이론적인 이야기가 아닙니다. 계약은 이미 존재하며, 테스트도 통과했습니다. 에이전트 템플릿은 리포지토리(repo)에 포함되어 배포됩니다. 오늘 데모를 실행하는 엔지니어는 내일 바로 자신의 인프라를 대상으로 에이전트를 지시할 수 있습니다.

왜 모놀리식 (Monolithic) 도구는 이러한 역량을 따라올 수 없는가

수집, 평가, 보고가 하나의 바이너리와 하나의 독점적 형식으로 이루어진 모놀리식 보안 도구는 AI 챗봇을 추가할 수 있습니다. LLM (Large Language Model) 기반의 요약을 추가할 수도 있고, 코파일럿 (Copilot) 사이드바를 추가할 수도 있습니다. 하지만 추가할 수 없는 것은 '에이전트가 개발 가능한 구성 (agent-developable composition)'입니다. 왜냐하면 구성을 위해서는 다음과 같은 요소가 필요하기 때문입니다:

• 독립적인 계약 (contracts)을 가진 분리된 단계 (모놀리식은 하나의 단계만 가짐)
• 어떤 에이전트 프레임워크라도 읽을 수 있는 단계 간의 표준 형식 (모놀리식은 독점적인 내부 형식을 가짐)
• 각 경계에서의 기계 검증 가능한 어설션 (machine-verifiable assertions) (모놀리식은 내부적으로 불투명하게 검증함)
• 에이전트가 독립적으로 실행할 수 있도록 공개된 추론 사양 (published reasoning specs) (모놀리식의 추론은 코드 내에 내장되어 있음)

이러한 속성들을 사후에 적용한다는 것은 모놀리식을 분해해야 함을 의미하며, 이는 곧 아키텍처를 포기해야 함을 의미합니다. 유닉스 철학 (Unix philosophy)은 하나의 기능이 아닙니다. 그것은 나중에 추가할 수 없는 창발적 속성 (emergent properties)을 만들어내는 구조적 결정입니다.

모든 기업 고객은 자신만의 도구 — 자신만의 CMDB, 자신만의 수집기 (collector), 자신만의 SIEM, 자신만의 컴플라이언스 프레임워크를 가지고 있습니다. 모놀리식 스캐너는 다음과 같이 말합니다: "우리의 수집기, 우리의 평가기, 우리의 대시보드를 사용하십시오."

반면 에이전트 중심의 파이프라인은 다음과 같이 말합니다: "당신의 도구를 가져오십시오. 우리의 계약(contracts)을 대상으로 삼으십시오. 에이전트가 파이프라인을 구성할 것입니다."

• 고객 A: Steampipe → Stave → Z3 → Splunk
• 고객 B: AWS Config → Stave → Soufflé → Jira
• 고객 C: Terraform state → Stave → Clingo → PagerDuty
• 고객 D: Custom CMDB → Stave → Prolog → Neo4j

네 명의 고객. 네 개의 서로 다른 수집기. 네 개의 서로 다른 추론 엔진 (reasoning engines).

네 개의 서로 다른 다운스트림 소비자 (downstream consumers). 중간에는 동일한 평가 계약 (evaluation contracts). 커스텀 통합 코드 제로. 변동성은 도구 내부의 어댑터가 아니라 경계면에 있는 계약에 의해 흡수됩니다.

에이전트 중심 시대 (Agentic era)를 위한 클라우드 보안
변화는 이미 일어나고 있습니다. Google의 방어 로드맵은 에이전트 기반의 SOC (agentic SOC)를 요구하고 있습니다. AWS는 Security Hub에 에이전트 기능을 추가하고 있습니다. 모든 벤더가 기존 도구에 AI를 추가하기 위해 경쟁하고 있습니다. 질문은 에이전트가 보안 플랫폼을 운영할 것인가가 아닙니다. 도구가 에이전트가 운영할 수 있도록 구축되었는가, 아니면 에이전트가 인간을 위해 구축된 도구 위에 하나의 레이어로 추가되었는가 하는 점입니다.

Stave는 에이전트가 운영할 수 있도록 구축되었습니다. 우리가 그것을 계획했기 때문이 아닙니다. 도구를 한 사람이 유지 관리할 수 있게 만드는 아키텍처 결정이 곧 에이전트가 운영할 수 있게 만드는 결정과 동일하기 때문입니다: 표준 계약 (standard contracts), 바이너리 단언 (binary assertions), 결정론적 평가 (deterministic evaluation), 조합 가능한 단계 (composable steps), 공개된 추론 사양 (published reasoning specs).

랜딩 페이지에는 이렇게 적혀 있습니다: 에이전트 중심 시대를 위한 클라우드 보안 (Cloud Security for the Agentic Era). 이는 곧, 에이전트를 사용하는 한 명의 엔지니어가 과거에 팀 단위가 필요했던 클라우드 보안 프로그램을 운영한다는 것을 의미합니다.

계약은 공개되어 있습니다. 테스트는 통과되었습니다. 아키텍처는 증명되었습니다. 클라우드 보안을 위해 도구를 운영할 팀이 필요했던 시대는 끝나가고 있습니다. 한 명의 엔지니어가 공개된 계약 플랫폼을 대상으로 에이전트를 지휘하는 시대가 시작되고 있습니다.

한 명의 개발자의 제약 사항 — 작은 도구, 표준 형식, 결정론적 평가 — 을 위해 구축된 CLI 도구로 시작된 것이 에이전트 중심 시대에 필요한 플랫폼이 되었습니다. 그것은 계획된 것이 아니었습니다. 하지만 그 어떤 계획보다 더 훌륭합니다.

Stave는 오픈 소스 클라우드 보안 플랫폼입니다. 2,650개 이상의 컨트롤 (controls), 585개의 복합 체인 (compound chains), 자산 유형별 109개의 JSON 스키마 (JSON Schemas), 17개의 Steampipe 매핑, 5개의 검증된 추론 사양 (reasoning specs), 9개의 독립적인 추론 엔진 (reasoning engines). 모든 파이프라인 경계에는 에이전트가 이를 바탕으로 개발할 수 있는 기계 검증 가능한 계약 (machine-verifiable contract)이 존재합니다.

직접 시도해 보세요: bash examples/demo-ai-security/run.sh