모든 클라우드 보안 도구 카테고리를 분석했습니다. 모두 동일한 격차를 가지고 있습니다.

우리는 모든 주요 클라우드 보안 도구 카테고리에 체계적인 진단 방법론인 TRIZ의 기능-실패 분석 (Function-Failure Analysis, FFA)을 적용하며 수주를 보냈습니다. 이는 모두가 느끼지만 아무도 명명하지 못하는 그 격차가 정확한 구조적 설명을 가질 수 있는지 알아내기 위함이었습니다.

결과는 그렇습니다. 그리고 그 격차는 6개 카테고리 모두에서 동일하게 나타났습니다. 결과적으로 드러난 것은, 현재 AI 지원 소프트웨어 개발 (AI-assisted software development) 분야에서도 나타나고 있는 바로 그 동일한 격차였습니다. 결여된 기능은 같지만, 도메인(Domain)만 다를 뿐입니다.

진단 방법론

기능-실패 분석 (Function-Failure Analysis, FFA)은 시스템에서 무엇이 빠져 있는지를 찾아내기 위한 TRIZ의 학문 분야입니다. 이는 사후 분석이 아닙니다. 즉, "무엇이 잘못되었는가?"를 묻지 않습니다. 이는 구조적입니다. 즉, "여기에 존재해야 하지만 존재하지 않는 기능은 무엇인가?"를 묻습니다.

이 방법론은 네 단계로 구성됩니다:

시스템 경계를 정의합니다. 구성 요소를 열거합니다.
모든 관계를 주체(Subject) → 동사(Verb) → 객체(Object)로 매핑합니다. 엄격한 명사-동사-명사 구조를 따릅니다. 형용사, 수식어, 모호한 표현은 허용되지 않습니다.
각 기능을 분류합니다: 유용-충분 (useful-sufficient), 유용-불충분 (useful-insufficient), 유용-과잉 (useful-excessive), 유해 (harmful), 또는 누락 (missing).
누락된 화살표가 설계 지침 (design brief)이 됩니다.

이 학문이 추측이 아닌 엄격함을 유지하게 만드는 원칙은 다음과 같습니다: 가상의 이상향이 아니라, 현재 문제를 해결하려고 시도하는 도구들에 분석을 적용하는 것입니다. 분석을 통해 해당 도구들이 어디에서 실패하는지를 드러냅니다. 그 실패가 다음에 올 것을 정의합니다.

우리는 이를 네 가지 중첩된 범위(scope)에서 실행했습니다: 전체 클라우드 전달 생태계, 그다음 클라우드 제어 시스템의 16개 구성 요소, 그다음 각 기존 도구 카테고리 개별적으로, 마지막으로 모든 엔지니어링 분야에 걸친 피드백 및 제어 트렌드입니다. 각 범위에서 동일한 구조적 격차가 도출되었습니다.

6가지 도구 카테고리, 동일하게 누락된 기능

다음은 FFA가 각 카테고리에 대해 찾아낸 결과이며, 핵심적인 주체(Subject) → 동사(Verb) → 객체(Object) 구조로 요약한 것입니다:

CSPM (Cloud Security Posture Management, 클라우드 보안 태세 관리)
수행하는 기능: 스캐너 (Scanner) → 탐지 (detects) → 알려진 설정 오류 (known misconfiguration).
누락된 기능: 스캐너 (Scanner) → 방지 (prevents) → 알려지지 않은 설정 오류 (unknown misconfiguration). 규칙 라이브러리(Rule library)는 외연적 (extensional)입니다. 즉, 특정된 알려진 악성 패턴들을 나열합니다. 새로운 설정 오류는 일치하는 규칙이 없기 때문에 통과됩니다. 이 도구는 인지하는 것에 대해서만 반응합니다. 본 적이 없는 것에 대해서는 규제할 수 없습니다.

CNAPP (Cloud-Native Application Protection Platform, 클라우드 네이티브 애플리케이션 보호 플랫폼)
수행하는 기능: 플랫폼 (Platform) → 상관관계 분석 (correlates) → 런타임 (runtime) 및 태세 (posture) 전반의 시그널 (signals).
누락된 기능: 플랫폼 (Platform) → 차단 (blocks) → 배포 전의 안전하지 않은 설정 (unsafe configuration). CNAPP은 CSPM, CWPP, CIEM을 통합된 뷰로 통합하며, 이는 우선순위 선정 (triage)에는 유용하지만 방지 (prevention)에는 불충분합니다. 이 상관관계 분석은 사후적 (retrospective)입니다. 누락된 기능은 사전적 (prospective)인 기능입니다.

SIEM (Security Information and Event Management, 보안 정보 및 이벤트 관리)
수행하는 기능: 집계기 (Aggregator) → 탐지 (detects) → 알려진 이벤트 패턴 (known event pattern).
누락된 기능: 집계기 (Aggregator) → 예측 (predicts) → 설정 상태 (configuration state)로부터의 이벤트 (event). SIEM은 이벤트, 즉 이미 발생한 일들을 대상으로 작동합니다. 승인되지 않은 접근이 발생했다는 사실은 알려줄 수 있습니다. 하지만 누군가 악용하기 전, 현재 승인되지 않은 접근을 허용하는 설정이 존재한다는 사실은 알려줄 수 없습니다.

SOAR (Security Orchestration, Automation and Response, 보안 오케스트레이션, 자동화 및 대응)
수행하는 기능: 오케스트레이터 (Orchestrator) → 조치 (remediates) → 탐지된 사고 (detected incident).
누락된 기능: 오케스트레이터 (Orchestrator) → 방지 (prevents) → 사고 전제 조건 (incident precondition). SOAR는 이미 발생한 사고에 대한 대응을 자동화합니다. 누락된 기능은 사고가 발생할 수 없도록 전제 조건을 제거하는 것입니다.

IaC Scanners (Infrastructure as Code, 코드형 인프라 스캐너)
수행하는 기능: 스캐너 (Scanner) → 플래그 표시 (flags) → 알려진 악성 IaC 패턴 (known-bad IaC pattern).
누락된 기능: 스캐너 (Scanner) → 검증 (verifies) → IaC가 선언된 불변량 (declared invariant)을 충족하는지 여부. IaC 스캐너는 규칙 라이브러리(rule libraries)를 기준으로 템플릿을 점검하며, 이는 실행 중인 인프라 대신 코드에 적용된 CSPM과 동일한 외연적 (extensional) 접근 방식입니다. 목록에 없는 속성에 대한 새로운 위반 사항은 통과됩니다.

ML 탐지 (ML Detection)
기능: 모델 → 인식 → 학습 분포 (training distribution)와 일치하는 이상 행동을 인식함.
부족한 점: 모델 → 보장 → 결정론적 판결 (deterministic verdict). ML 탐지는 확률적 (probabilistic)이며, 알려진 실패 사례의 학습 데이터가 필요하고, 증명 (proof) 대신 신뢰 점수 (confidence scores)를 생성합니다. 누락된 기능은 이전에 해당 실패 모드 (failure mode)를 본 적이 있는지 여부에 의존하지 않는, 배포 전의 결정론적 판결입니다.

여섯 가지 카테고리 모두에서 격차는 동일합니다:

리소스당 기계 검증 가능하며, 배포 전 단계에서 이루어지는, 결정론적 판결 — 이전에 무엇이 잘못되었는가가 아니라, 항상 참이어야 하는 것에 기반하여 평가됨.

기존의 모든 카테고리는 동일한 동사군을 사용합니다: 탐지(detect), 인식(recognize), 상관관계 분석(correlate), 플래그 표시(flag), 경고(alert). 모두 사후 대응적 (reactive)입니다. 모두 소급적 (retrospective)입니다. 모두 이전에 실패 모드를 본 적이 있는지에 의존합니다. 누락된 동사는 검증 (verify) 입니다 — 선제적 (proactive)이고, 전망적 (prospective)이며, 결정론적 (deterministic)이고, 원인에 독립적 (cause-independent)입니다.

왜 "원인을 이해하지 않고도"가 결정적인 속성인가

이 격차를 통합하는 기능 정의는 다음과 같습니다:

시스템은 실패의 원인을 완전히 이해하지 않고도 변화하는 환경에서 스스로를 규제해야 한다.

기존의 모든 도구는 원인이 열거 가능 (enumerable)해야 합니다. CSPM은 설정 오류 (misconfiguration) 패턴을 열거합니다. SIEM은 공격 시그니처 (attack signatures)를 열거합니다. ML 모델은 학습 데이터 내의 실패 모드를 열거합니다. 이 세 가지 모두 원인이 새로운 것이 되는 순간 무너집니다.

불변량 (invariant) 기반 접근 방식은 이를 뒤집습니다. 규제자 (regulator)는 어떤 속성이 유지되어야 하는지만 알면 됩니다. 위반을 생성하는 인과 기제 (causal mechanism)는 완전히 새로운 것일 수 있습니다 — 아무도 목록화하지 않은 설정 오류, 아무도 발표하지 않은 공격 기법, 아무도 관찰하지 않은 드리프트 (drift) 패턴 등 — 그럼에도 규제자는 이를 잡아냅니다. 왜냐하면 위반 사항은 원인이 아니라 상태 (state)에서 관찰 가능하기 때문입니다.

이는 이 문제를 해결한 모든 도메인에서 나타나는 동일한 아키텍처적 움직임입니다:

도메인 (Domain)	선언된 속성 (Property declared)	원인 불필요 (Cause not needed)
Fly-by-wire	"비행 한계 영역(flight envelope) 내에 머무를 것"	조종사의 입력이 왜 한계를 벗어나는지는 중요하지 않음
...

속성은 선언됩니다. 상태는 관찰됩니다. 판결은 결정론적 (deterministic)입니다. 원인은 탐지 (detection)에는 무관하며, 오직 사후에 이루어지는 조치 (remediation)에만 관련이 있습니다.

AI 지원 개발에서도 동일한 기능이 누락되어 있습니다

이 지점에서 우리의 분석은 예상치 못한 방식으로 도메인을 가로질렀습니다.

AI 코딩 에이전트 (AI coding agents)는 개발자가 이해할 수 있는 속도보다 더 빠르게 코드를 생성합니다. 이를 관리하기 위해 구축된 도구들 — 린터 (linters), 코드 리뷰 봇 (code review bots), 품질 게이트 (quality gates), 문서 생성기 (documentation generators) — 는 위에서 분석한 클라우드 보안 도구들과 구조적으로 동일합니다. 이들은 모두 동일한 동사군을 사용합니다: 탐지 (detect), 플래그 표시 (flag), 보고 (report), 상관관계 분석 (correlate). 모두 반응적 (reactive)이며, 모두 알려진 패턴을 인식하는 것에 의존합니다.

누락된 기능은 동일합니다:

개발 시스템은 명세 (specification)를 위반하는 코드의 원인을 완전히 이해하지 못하더라도, 빠르게 변화하는 코드베이스 (codebase) 내에서 스스로를 규제할 수 있어야 한다.

린터는 알려진 코드 스멜 (code smells)을 탐지합니다. 하지만 확인하도록 프로그래밍되지 않은 아키텍처 불변량 (architectural invariant)의 새로운 위반은 탐지할 수 없습니다. 코드 리뷰 봇은 의심스러운 패턴에 플래그를 표시합니다. 하지만 AI가 생성한 코드가 타입 명세 (typed specification)를 충족하는지는 검증할 수 없습니다. 품질 게이트는 기준치 미달의 커버리지를 차단합니다. 하지만 코드가 시스템이 의존하는 인터페이스 계약 (interface contract)을 보존하는지는 검증할 수 없습니다.

누락된 동사는 동일합니다: 검증 (verify). 선언된 속성에 대해 머지(merge) 전 단계에서 이루어지는, 결정론적이며 원인에 독립적인 검증입니다. 코드는 어떤 프롬프트(prompt)로부터, 어떤 모델을 사용하여, 어떤 AI 에이전트에 의해 생성될 수 있습니다. 원인은 중요하지 않습니다. 명세가 유지되느냐 그렇지 않느냐의 문제일 뿐입니다.

기능 명제는 다음과 같이 일대일로 매핑됩니다:

용어 (Term)	클라우드 보안 (Cloud security)	AI 지원 개발 (AI-assisted development)
시스템 (A system)	클라우드 인프라 (Cloud infrastructure)	코드베이스 (The codebase)
...

두 개의 도메인. 하나의 누락된 기능. 동일한 동사. 동일한 아키텍처적 해결책.

이름이 계속 바뀌는 이유

이 분석을 수행하는 동안, 명명(naming)에 관한 유익한 사실을 관찰했습니다. 새로운 기능(capability)이 출시될 때마다, 해당 카테고리에 적합하다고 느껴지는 이름이 바뀌었습니다.

출시된 기능 (Capability shipped)	적절하다고 느껴진 이름
S3 복합 위험 탐지 (S3 compound risk detection)	"복합 위험 엔진 (Compound Risk Engine)"
...

각 이름은 '마지막으로 출시된 것'을 추적합니다. 이는 당신이 문제를 명명하는 것이 아니라, 기능을 명명하고 있다는 신호입니다. 기능은 출시함에 따라 변하지만, 문제는 변하지 않습니다.

FFA(Functional Gap Analysis)가 식별한 누락된 기능은 이러한 기능 확장 과정 전반에 걸쳐 결코 변하지 않았습니다.

리소스당 기계 검증 가능하며(Machine-verifiable), 배포 전(pre-deployment)에 이루어지는, 결정론적인(deterministic) 판결 — 항상 참이어야 하는 것에 대한 스테이지 4 피드포워드 제어 (Stage 4 feed-forward control).

구현 방식이 복합 위험 체인(compound risk chains), CEL 술어(predicates), SMT 솔버(solvers), AI 에이전트 가드레일(guardrails), 의도 명세(intent specifications), 또는 안전 검증(safety verification)을 통해 해당 기능을 표현하든 관계없이, 그 기능은 동일합니다. 새로운 기능은 카탈로그를 확장할 뿐, 카테고리를 확장하지 않습니다.

이름을 안정적으로 만드는 계보

결국 하나의 계보를 통해 안정적인 이름이 등장했습니다.

코드로서의 인프라 (IaC)  →  코드로서의 정책 (PaC)  →  코드로서의 불변량 (Invariants as Code)
       방법 (HOW)             허용 여부 (WHAT)          항상 참이어야 하는 것 (WHAT MUST ALWAYS BE TRUE)

IaC (Terraform, Pulumi, CloudFormation)는 프로비저닝(provisioning)을 코드화했습니다. 산출물(artifact)은 원하는 상태(desired state)를 선언하는 템플릿입니다. 동사는 프로비저닝하다 (provision) — 명시된 대로 인프라를 생성하는 것입니다.

코드로서의 정책 (Policy as Code) (OPA/Rego, Cedar, Sentinel)는 권한 부여(authorization)와 승인(admission)을 코드화했습니다. 산출물은 무엇이 허용되는지를 선언하는 규칙입니다. 동사는 강제하다 (enforce) — 정책에 따라 동작을 허용하거나 거부하는 것입니다.

**코드로서의 불변량 (Invariants as Code)**은 안전 속성(safety properties)을 코드화합니다. 산출물은 항상 참이어야 하는 것을 선언하는 술어(predicate)입니다. 동사는 검증하다 (verify) — 배포 전에 상태가 불변량(invariant)을 충족하는지 결정론적으로 판단하는 것입니다.

이 계보의 각 단계는 추상화 수준을 높입니다:

세대 (Generation)	산출물 (Artifact)	범위 (Scope)	동사 (Verb)
IaC	템플릿 (Template)	단일 배포 (One deployment)	프로비저닝 (Provision)
...

IaC는 "이러한 설정으로 이 버킷을 생성하라"고 말합니다. Policy as Code (PaC)는 "이러한 조건이 충족되면 이 동작을 허용하라"고 말합니다. Invariants as Code는 "어떤 동작이 취해지든, 어떤 템플릿이 적용되든, 어떤 정책이 평가되든 상관없이, 결과 상태에서는 반드시 이 속성이 유지되어야 한다"라고 말합니다.

불변량 (Invariant)은 IaC와 Policy as Code 모두보다 상위(upstream)에 있습니다. 불변량을 위반하는 템플릿은 프로비저닝 전에 거부되어야 합니다. 불변량 위반을 허용하는 정책은 불일치(inconsistent) 상태로 표시되어야 합니다. 불변량이 IaC나 PaC를 대체하는 것은 아닙니다. 그것은 두 요소가 공동으로 충족해야 하는 속성으로서 그들 위에 존재합니다.

다른 모든 것이 변할 때 유지되는 기능

FFA 진단은 분석의 모든 단계에서 반복되는 패턴을 발견했습니다: 기능은 안정적이지만 구현은 변하며, 이름은 그 기능을 따라가야 한다는 것입니다.

클라우드 보안 도구 카테고리에서 모든 도구의 구현 방식은 달랐습니다 (규칙 매칭 (rule matching), ML 스코어링 (ML scoring), 이벤트 상관관계 (event correlation), 조치 오케스트레이션 (remediation orchestration)). 하지만 누락된 기능은 6가지 카테고리 모두에서 동일했습니다.

그 간극을 메우기 위해 우리가 구축한 도구의 기능 확장 과정에서, 새로운 기능이 추가될 때마다 도구가 할 수 있는 일은 변했습니다. 하지만 그것이 수행하는 기능 — 기계 검증 가능하고 (machine-verifiable), 배포 전 단계이며 (pre-deployment), 결정론적인 판결 (deterministic verdict) — 은 결코 변하지 않았습니다.

이름 표류 (name-drift) 표를 보면, 기능을 추적하는 이름이 아닌 기능을 추적하지 않는 모든 이름은 한 달 동안은 적절해 보이다가도 다음 달에는 틀린 것처럼 느껴졌습니다. 반면 기능을 추적하는 이름 ("Invariants as Code")은 그것이 식별된 이후로 안정적으로 유지되었습니다. 왜냐하면 그것은 제품이 아닌 관행 (practice)을 명명하기 때문입니다.

FFA가 답하는 진단적 질문은 "무엇을 만들어야 하는가?"가 아닙니다. 그것은 바로 "어떤 기능이 누락되었는가?"입니다. 첫 번째 질문에 대한 답은 분기마다 바뀌지만, 두 번째 질문에 대한 답은 첫 번째 분석이 수행된 2025년 12월 이후로 동일했습니다. 그리고 알고 보니, Parnas가 인간의 인지 능력 (cognitive capacity)을 병목 현상으로 식별한 1972년 이후로, 그리고 Lamport가 안전성 속성 (safety properties)이 기계적으로 검증 가능하다는 것을 증명한 1977년 이후로도 동일했습니다.

그 기능은 언제나 누락되어 있었습니다. 변화의 속도가 그것을 가시화했을 뿐입니다.

"배포 전 (Pre-deployment)"의 뉘앙스: 이 글은 배포 전 단계를 강조하지만, 불변량 (invariants)은 **지속적인 런타임 검증 (continuous runtime verification)**에도 똑같이 강력합니다. 검증은 단순한 게이트 (gate)가 아니라 지속적인 상태입니다.
불변량과 정책 (Policies)의 분리: 코드로서의 정책 (Policy as Code, 예: OPA)은 불변량을 표현할 수 있습니다. 정책은 종종 요청 (Request) (승인 제어, admission control)에 적용되는 반면, 불변량은 결과 상태 (Resultant State) (전체 그래프)에 적용됩니다.

기능-실패 분석 (Function-Failure Analysis, FFA)은 TRIZ 방법론에 포함된 12가지 분석 도구 중 하나입니다. 여기서 설명된 4가지 범위의 진단은 서비스 및 소프트웨어 시스템을 위해 고전적 FFA를 변형한 Darrell Mann의 연구를 바탕으로 합니다. 언급된 피드백 제어 (feedback-control) 트렌드는 Mann의 저작물과 Altshuller의 독창적인 특허 분석 전반에 걸쳐 기록되어 있습니다.