그녀가 진단한 애프터마켓(Aftermarket)은 그녀가 처방한 애프터마켓이다

Jen Easterly의 Glasswing 분석은 이번 10년 동안 발표된 사이버 보안(cybersecurity) 진단 중 가장 날카로운 통찰로 시작합니다:

"우리는 실제로 사이버 보안 문제를 겪고 있는 것이 아니라, 소프트웨어 품질 문제를 겪고 있는 것입니다. 수십 년 동안 우리는 애초에 존재하지 않았어야 할 취약점(vulnerabilities) — 즉 소프트웨어의 결함(flaws)과 결함(defects) — 을 방어하고, 탐지하고, 대응하기 위해 거대한 글로벌 산업을 구축해 왔습니다."

그리고 나중에 다음과 같이 언급합니다:

"장기적인 목표는 단순히 어제의 불안전한 코드를 더 효율적으로 정리하기 위해 AI를 사용하는 것이 되어서는 안 됩니다. AI를 사용하여 보안을 생성 시점으로 이동시켜야 합니다. 즉, 개발자가 처음부터 더 나은, 더 안전하고, 더 탄력적인(resilient) 소프트웨어를 작성할 수 있도록 도와야 합니다. 사이버 보안의 애프터마켓(aftermarket)에서 보안이 다운스트림(downstream)에 덧붙여지는 것이 아니라 업스트림(upstream)에서 구축되는 세상으로 전환해야 합니다."

진단은 정확합니다. 목적지도 정확합니다.

하지만 처방은 그 둘 중 어느 것과도 일치하지 않습니다.

Glasswing이란 무엇인가

Anthropic의 Project Glasswing은 코드베이스(codebases)에서 취약점을 찾아내고 수정(remediation)을 지원합니다. Easterly의 표현을 빌리자면, 이는 "취약점을 더 빠르게 식별"하고 "수정 비용, 시간 및 복잡성을 줄이는" 잠재력을 제공합니다. 즉, "근본 원인 분석(root cause analysis)을 지원하고, 후보 패치(candidate patches)를 생성하며, 위험의 우선순위를 정하고, 테스트 및 배포를 가속화"하는 것입니다.

이것이 바로 그녀가 진단한, AI에 의해 가속화된 애프터마켓(aftermarket)입니다.

취약점을 더 빨리 찾는 것은 여전히 '찾는 것'입니다. 더 저렴하게 수정하는 것은 여전히 '수정하는 것'입니다. 후보 패치를 생성하는 것은 여전히 '수정(remediating)'하는 것입니다. 이러한 모든 활동은 취약점이 존재한 '이후'에 발생합니다. 코드 내에서, 운영 환경(production)에서, 혹은 시스템적으로 중요한 금융 기관의 코드베이스 내에서 말입니다. 취약점은 이미 생성되었습니다. 배포되었습니다. 지속되었습니다. 그러고 나서야 AI가 그것을 찾아낸 것입니다.

그것은 더 빠른 애프터마켓일 뿐입니다. 애프터마켓의 종말이 아닙니다.

그녀가 명명했지만 처방하지는 않은 치료법

"업스트림에서 내장된 보안(Security built in upstream), 다운스트림에 부착된 것이 아닌 것(not bolted on downstream)." 이 문장은 오늘날 존재하며, 수십 년 동안 입증되었고, 최첨단 AI 모델을 구현할 필요가 없는 특정 아키텍처를 설명합니다.

**업스트림에서 내장된다는 것(Built in upstream)**은 다음을 의미합니다. 코드가 작성되거나 설정이 배포되기 전에 무엇이 참이어야 하는지 선언하는 것입니다. 나중에가 아닙니다. 전에요. "운영 환경에 공개 S3 버킷이 없어야 한다." "어떤 IAM 역할도 MFA 없이 크로스 계정 액세스를 가정할 수 없도록 해야 한다." "어떤 API 엔드포인트도 인증되지 않은 요청을 허용해서는 안 된다." "알려진 심각한 CVE를 가진 의존성은 배포될 수 없다." 이것들은 선언입니다. 시스템이 충족해야 할 조건을 명시하는, 인간이 작성한 진술이며 기계가 확인할 수 있는 형태로 표현됩니다.

**다운스트림에 부착되지 않는다는 것(Not bolted on downstream)**은 다음을 의미합니다. 생성 지점에서 선언을 기계적으로 검증하는 것입니다. 코드가 배포되기 전, 설정이 전파되기 전, 취약점이 발견될 수 있기 전에요. 컴파일 시간에 버퍼 오버플로우를 방지하는 타입 체커(type checker). 선언된 불변성(invariant)을 위반하는 설정을 운영 환경에 도달하기 전에 거부하는 정책 엔진(policy engine). 선언된 인터페이스를 깨뜨리는 API 변경을 차단하는 계약 테스트(contract test). 이것들은 결정론적 검증 게이트입니다. 의견을 형성하는 모델이 아니라, 패스 또는 실패라는 이진 판결을 내리는 기계적인 점검입니다.

이 아키텍처는 다음과 같습니다:

인간이 무엇이 참이어야 하는지 선언합니다 (명세(specification) — 업스트림, 느리고, 도메인 판단이 필요함)
기계가 모든 변경 사항을 선언에 따라 검증합니다 (게이트(gate) — 다운스트림, 빠르고, 결정론적이며, 모든 커밋마다 실행됨)
**래칫(ratchet)**은 새로 발견된 취약점 클래스를 새로운 선언으로 변환하여 — 해당 클래스가 단지 다음번에 더 빨리 발견되고 수정되는 것뿐만 아니라 영구적으로 방지되도록 합니다.

이것은 이론적인 것이 아닙니다. 모든 안전 필수 도메인(safety-critical domain)에서 이렇게 수행합니다:

도메인 (Domain)	인간이 선언 (Human declares)	기계가 강제 (Machine enforces)
항공 (Aviation)	조종사가 방향과 고도를 설정함	비행 컴퓨터가 엔벨로프 (envelope)를 강제하여 — 기계의 속도로 안전하지 않은 상태를 방지함
...

항공 규제 기관은 조종사에게 비행 후에 엔벨로프 위반 사항을 찾아내어 다음번에 수정하라고 요구하지 않습니다. 비행 컴퓨터가 위반이 발생하는 것을 방지합니다. 이것이 바로 "상류에서 구축된 (built in upstream)" 방식입니다. Glasswing은 비행기가 착륙한 후에 위반 사항을 찾아내어 비행기를 패치하는 것을 돕겠다고 제안합니다. 그것은 "하류에 덧붙여진 (bolted on downstream)" 방식입니다. AI를 통해 더 빠르긴 하지만, 여전히 하류(downstream)에 머물러 있습니다.

"우리가 수십 년 동안 보아온 것과 동일한 범주의 결함들"

Easterly는 이 점을 직접 강조합니다. 이는 발견(discovery) 방식보다 선언(declaration) 방식이 우월하다는 것을 보여주는 가장 결정적인 증거입니다:

"이 시스템들이 밝혀내고 있는 것은 이색적인 것이 아닙니다. 이들은 AI가 발견한 어떤 근본적으로 새로운 클래스의 약점을 드러내는 것이 아니라, 오히려 저품질 설계에 대한 추가적인 증거를 강조하고 있습니다. 즉, 우리가 수십 년 동안 보아온 것과 동일한 범주의 결함들 — 우리의 인센티브가 이를 제거하는 방향으로 정렬된 적이 없었기 때문에 지속되어 온, 예측 가능하고 예방 가능한 취약점들입니다."

만약 취약점 범주가 알려져 있고, 예측 가능하며, 예방 가능하다면 — 그렇다면 선언문(declarations)은 오늘 당장이라도 작성될 수 있습니다. "버퍼 오버플로 (buffer overflow) 없음"은 Rust가 구조적으로(by construction) 강제하는 속성입니다. "SQL 인젝션 (SQL injection) 없음"은 매개변수화된 쿼리 (parameterized queries)가 구조적으로 강제하는 속성입니다. "공개된 S3 버킷 (public S3 bucket) 없음"은 배포 전에 3줄짜리 정책 체크가 강제하는 속성입니다. "MFA 없는 교차 계정 IAM 신뢰 (cross-account IAM trust without MFA) 없음"은 CEL 술어 (predicate)가 구성 스냅샷에 대해 평가하는 속성입니다.

이것들은 프런티어 모델 (frontier model)이 발견해야 하는 새로운 문제들이 아닙니다. 이것들은 예방을 위해 선언이 필요한 알려진 문제들입니다. Glasswing이 "예측 가능하고 예방 가능한" 범주에서 찾아내는 모든 취약점은, 선언된 불변량 (declared invariant)이 존재했다면 발생하기 전에 차단했을 취약점들입니다.

운영 코드(production code)에서 SQL 인젝션(SQL injection)을 찾아내는 AI는 유용한 일을 하고 있는 것입니다. 하지만 구조적으로(by construction) SQL 인젝션을 불가능하게 만드는 매개변수화된 쿼리(parameterized query)는 토큰 비용 제로, 수정 시간(remediation time) 제로, 인간 개입(human-in-the-loop) 오버헤드 제로라는 조건 하에 훨씬 더 나은 일을 수행하고 있는 것입니다.

"수정(Remediation)이 진정한 과제다"

Easterly는 발견(discovery)이 병목 현상의 원인이 아니었으며, 수정(remediation)이 병목이었다고 주장합니다. 취약점을 찾는 것은 쉬운 부분입니다. 근본 원인(root cause)을 이해하고, 수정 사항을 개발하고, 이를 테스트하고, 기능이 망가지지 않도록 보장하며, 복잡한 시스템 전체에 배포하는 것 — 이것이 어렵고, 비용이 많이 들며, 인력이 많이 투입되는 부분입니다. Glasswing은 그 부분을 더 빠르게 만듭니다.

이는 이미 존재하는 취약점에 대해서는 맞는 말입니다. 하지만 존재 자체가 방지된 취약점에 대해서는 무의미합니다.

생성 시점에 특정 범주의 취약점을 방지하는 선언된 불변량(declared invariant)은 수정 비용이 전혀 들지 않습니다. 취약점이 아예 생성되지 않았기 때문입니다. 근본 원인을 파악할 것도, 패치할 것도, 테스트할 것도, 배포할 것도 없습니다. Easterly가 정확히 지적한 수정의 과제는 선언(declaration)을 통해 그 필요성이 사라졌기에 소멸합니다.

이 기사가 놓치고 있는 차이점은 다음과 같습니다: 가장 효과적인 수정은 예방(prevention)입니다. 가장 비용 효율적인 패치는 필요하지 않았던 패치입니다. 가장 효율적인 취약점 공개(vulnerability disclosure)는 해당 범주가 불가능하다고 선언되었기에 아예 발생하지 않은 것입니다.

"미션으로서의 사이버 보안의 끝은 아니다"

Easterly의 결론은 옳습니다. Glasswing이 있더라도 사이버 보안은 끝나지 않습니다. 선언된 불변량이 있더라도 사이버 보안은 끝나지 않습니다. 유한한 선언 세트가 모든 것을 잡아낼 수는 없습니다. 이는 Gödel의 불완전성 정리(incompleteness theorems)를 AI 및 보안 시스템으로 확장한 Vassilev의 NIST 증명(2026년 6월)을 통해 수학적으로 공식화되었습니다.

이 아키텍처는 "모든 것을 선언하면 안전하다"가 아닙니다. 그것은 다음과 같습니다:

알고 있는 것을 선언하라 (Declare what you know) — 알려진 카테고리, 예측 가능한 결함, 예방 가능한 취약점들입니다. 이것들은 Easterly 본인이 우리가 수십 년 동안 알고 있었다고 말하는 클래스(classes)들입니다. 그것들을 선언하십시오. 검증하십시오. 예방하십시오.
모르는 것을 탐지하라 (Detect what you don't know) — 행동 모니터링 (behavioral monitoring), AI 보조 탐지 (AI-assisted discovery), Glasswing급 도구들입니다. 이것들은 아직 어떤 선언도 작성되지 않은 취약점들을 찾아냅니다. 이것이 애프터마켓 (aftermarket)의 영구적인 역할입니다 — 선언들이 커버하지 못하는 것들을 잡아내는 것입니다.
래칫 (The ratchet) — 애프터마켓이 발견하는 모든 취약점은 새로운 선언이 됩니다. 해당 클래스는 영구적으로 예방됩니다. 애프터마켓의 역할은 축소됩니다. 선언 계층 (declaration layer)은 성장합니다. 각 사이클은 다음 사이클을 더 작게 만듭니다.

Glasswing은 레이어 2 (layer 2)에서 가치가 있습니다 — 즉, 선언들이 아직 커버하지 못하는 것을 발견하는 것입니다. 하지만 레이어 1 (layer 1)이 없다면, Glasswing은 Easterly가 우리가 수십 년 동안 알고 있었다고 말하는 동일하고 예측 가능하며 예방 가능한 카테고리들을 찾아내며 동일한 속도로 영원히 실행될 뿐입니다. 레이어 1이 있다면, Glasswing은 오직 새로운 것(novel)에만 집중할 수 있습니다. 아직 아무도 선언하지 않은 클래스들, 즉 훨씬 더 작고 훨씬 더 가치 있는 집합에 집중하게 됩니다.

Glasswing의 진짜 신호

Easterly의 프레임워크에는 치료법이 적용되는 곳과 적용되지 않는 곳을 모호하게 만드는 혼동이 있습니다.

"소프트웨어 품질"은 네 가지 서로 다른 문제이다

Easterly는 이 위기를 "소프트웨어 품질 문제"로 규정합니다. 이러한 프레임워크는 네 가지 별개의 영역을 하나의 바구니로 붕괴시킵니다. 각 영역은 서로 다른 탐지 메커니즘, 서로 다른 예방 도구, 그리고 서로 다른 검증 접근 방식을 가집니다:

	코드 (Code)	설정 (Configuration)
애플리케이션 (Application)	소스 코드 버그 — 버퍼 오버플로 (buffer overflows), SQL 인젝션 (SQL injection), 로직 오류 (logic errors)	앱 수준 설정 — 인증 설정 (authentication config), 세션 관리 (session management), API 권한 (API permissions)
인프라스트럭처 (Infrastructure)	IaC 템플릿 — Terraform, CloudFormation, Kubernetes 매니페스트 (manifests)	런타임 클라우드 설정 — IAM 정책 (IAM policies), S3 버킷 정책 (S3 bucket policies), 보안 그룹 (security groups), 네트워크 ACL (network ACLs)

Glasswing은 하나의 사분면, 즉 Application × Code (애플리케이션 × 코드) 영역에서 작동합니다. 이는 버퍼 오버플로 (buffer overflows), 인젝션 결함 (injection flaws), 로직 에러 (logic errors)와 같은 소스 코드 취약점을 찾아냅니다. 이는 실제적이고 가치 있는 작업입니다. 하지만 이는 문제의 4분의 1에 불과합니다.

Mythos는 소스 코드를 읽습니다. 소스 코드에 대해 추론합니다. 알려진 취약점 클래스 (vulnerability classes)와 일치하는 소스 코드 내 패턴을 찾아냅니다. 소스 코드를 위한 패치 (patches)를 생성합니다. 모든 기능은 그리드의 한 셀인 Application × Code 영역으로 제한됩니다. Mythos는 귀하의 IAM 정책이 과도한 교차 계정 액세스 (cross-account access)를 허용하는지 평가할 수 없습니다. 그것은 Infrastructure × Configuration (인프라 × 설정)의 영역입니다. Mythos는 귀하의 S3 버킷 정책 (S3 bucket policy)이 Cognito ID 풀 (identity pool)과 결합되어 권한 상승 경로 (privilege escalation path)를 생성하는지 감지할 수 없습니다. 그것은 Infrastructure × Configuration 리소스에 걸친 복합 위험 (compound risk)입니다. Mythos는 귀하의 Terraform 템플릿이 조직의 보안 정책을 위반하는지 검증할 수 없습니다. 그것은 Infrastructure × Code (인프라 × 코드)의 영역입니다. Mythos는 귀하의 애플리케이션 인증 설정 (authentication configuration)이 보안 요구 사항과 일치하는지 확인할 수 없습니다. 그것은 Application × Configuration (애플리케이션 × 설정)의 영역입니다.

Mythos는 지금까지 구축된 모델 중 가장 강력한 소스 코드 분석 모델입니다. 하지만 소스 코드는 하나의 셀일 뿐입니다. 그리드에는 네 개의 셀이 있습니다. 클라우드 침해 사고의 대부분이 발생하는 나머지 세 개의 셀은 Mythos에게 보이지 않습니다. 과장된 광고(hype)는 Mythos를 사이버 보안의 미래로 포지셔닝합니다. 하지만 그리드는 Mythos를 사이버 보안의 4분의 1을 담당할 미래로 포지셔닝합니다. 나머지 4분의 3은 다른 도구가 필요합니다. 즉, 소스 코드를 읽는 모델이 아니라, 설정 (configuration)에 대해 검증된 선언된 불변량 (declared invariants)이 필요합니다.

DDP 법률 위반 — 랜섬웨어 공격 이후 ICO로부터 60,000파운드의 벌금을 부과받은 사건 — 의 근본 원인은 오로지 인프라(Infrastructure) × 설정(Configuration) 사분면에 있었습니다: 방화벽 없음, MFA(다요소 인증) 없음, 패치되지 않은 시스템, 수년간 활성화되어 있던 휴면 사용자 계정. 모든 근본 원인은 선언된 규칙에 대한 불리언(boolean) 체크 문제였습니다. AI는 필요하지 않았습니다. 소스 코드 스캐닝(source code scanning)으로도 이를 찾아낼 수 없었을 것입니다. 이것들은 코드 품질 문제가 아닙니다. 인프라 자체에서 추론할 수 있는 설정 포스처(configuration posture) 문제입니다.

**복합적인 교차 리소스 리스크(Compound cross-resource risk)**는 사분면의 교차점에 존재합니다. Cognito ID 풀(Identity pool, 애플리케이션(Application) × 설정(Configuration))이 IAM 신뢰 정책(trust policy, 인프라(Infrastructure) × 설정(Configuration)) 및 S3 버킷 정책(S3 bucket policy, 인프라(Infrastructure) × 설정(Configuration))과 결합되면, 단일 사분면 도구는 포착할 수 없는 권한 상승(privilege escalation) 경로를 생성합니다. 리스크는 노드(node)가 아니라 리소스 사이의 에지(edge), 즉 결합 관계에 있습니다. Glasswing이 소스 코드를 스캔하더라도 이를 발견하지 못하는데, 그 이유는 취약점이 특정 소스 코드에 있는 것이 아니라 두 사분면에 걸친 세 가지 설정 간의 관계에 있기 때문입니다.

익스플로잇 체인(exploit chain)은 하나의 사분면에 머물지 않습니다

데이터 침해 사고는 사분면의 경계를 존중하지 않습니다. 전형적인 2026년의 침해 사고는 이 모든 경계를 가로지릅니다:

인프라(Infrastructure) × 설정(Configuration): 약간 과도한 권한이 부여된 IAM 역할(role) — 의도보다 넓은 신뢰 범위, 초기 설정 이후 검토되지 않음
애플리케이션(Application) × 설정(Configuration): 잘못 설정된 OIDC 제공자(provider) — 의도하지 않은 흐름을 허용하는 인증 설정
애플리케이션(Application) × 코드(Code): 세션 하이재킹(session hijacking)을 허용하는 로직 결함 — 소스 코드 취약점