두 가지 문제와 두 가지 도구: AI 기반 스캐닝과 구성 검증이 다르게 해결하는 이유

클라우드 보안 분야에서는 AI 지원 도구가 무엇을 할 수 있는지에 대해 혼란이 커지고 있습니다. 이러한 혼란 중 일부는 AI 기반 취약점 발견에 대한 과장된 주장에서 비롯됩니다. 또 다른 부분은 다양한 도구들이 어디에 적합한지에 대한 진정한 불확실성 때문입니다. 하지만 대부분의 혼란은 보안을 하나의 문제로 취급하는 데서 오는데, 실제로는 두 가지 문제입니다. 이 두 문제는 근본적으로 다른 접근 방식을 필요로 합니다. 어떤 도구를 평가하기 전에, 문제를 분리해야 합니다.

두 가지 유형의 보안 문제

클래스 1: 패턴 인식 가능 문제 (Pattern Recognizable Problems)
SQL 인젝션은 운영자(operator)와 관계없이 취약점입니다. SQL 쿼리에 정제되지 않은 사용자 입력이 연결되는 것은 모든 애플리케이션, 모든 배포 환경, 모든 조직에서 위험합니다. 운영자의 의도가 판결을 바꾸지 않습니다. 아무도 자신의 애플리케이션이 인젝터블(injectable)하기를 의도하지 않습니다.

이는 XSS (Cross-Site Scripting), 버퍼 오버플로우(buffer overflows), 커맨드 인젝션(command injection), 안전하지 않은 역직렬화(insecure deserialization) 및 웹 애플리케이션의 OWASP Top 10 대부분에도 적용됩니다. 이들은 보편적인 패턴입니다. 취약점은 운영자가 무엇을 의도했는지 때문이 아니라 코드가 작동하는 방식 때문에 존재합니다. 사용자 입력을 eval()에 전달하는 함수는 해당 애플리케이션이 의료 포털인지 레시피 블로그인지와 관계없이 안전하지 않습니다.

핵심 속성: 판결은 운영자의 의도와 독립적입니다. 패턴은 배포 환경 전반에 걸쳐 일반화됩니다. SQL 인젝션을 한 번 본 적이 있다면, 다음 것도 인식할 수 있습니다.

클래스 2: 의도 의존 문제 (Intent Dependent Problems)
CSS 파일을 호스팅하는 정적 웹사이트의 경우 공개 S3 버킷은 올바릅니다.

같은 설정이라도 버킷에 환자 기록이 포함되어 있다면 HIPAA 위반입니다. 버킷 설정은 동일합니다. 판단은 전적으로 운영자가 데이터 내용물에 대해 무엇이라고 선언했는지에 달려 있습니다. 리소스: * 에 대한 lambda:InvokeFunction을 가진 Bedrock 에이전트는 임의의 워크플로우를 오케스트레이션해야 하는 내부 개발자 도구에는 적절합니다. 하지만 이 권한이 고객 대면 쿼리를 처리하는 에이전트가 되고, 그중 하나의 Lambda 함수가 PHI(Protected Health Information) 태그가 지정된 버킷에서 읽어온다면 치명적입니다. IAM 정책은 동일합니다. 판단은 정책, 에이전트의 목적, 그리고 도구 체인이 접근할 수 있는 리소스의 데이터 분류 간의 상호 작용에 달려 있습니다. 핵심 속성: 판단은 운영자가 선언한 의도에 따라 달라집니다. 이 패턴은 배포 전반에 걸쳐 일반화되지 않습니다. 모든 조직의 태그, 정책 및 신뢰 관계는 고유합니다. '이 설정은 안전하지 않다'는 수천 가지 예시를 본다고 해서 다음 설정 역시 안전하지 않은지 알려주지는 못합니다. 왜냐하면 다음 운영자의 의도가 다르기 때문입니다. 이 구분이 중요한 이유 두 클래스를 혼합하여 사용하면 문제에 대한 잘못된 도구와 결과에 대한 잘못된 기대를 갖게 됩니다. Class 2 문제에 AI가 학습한 스캐너를 사용하면 IDOR(Insecure Direct Object Reference) 오탐이 발생합니다. 스캐너는 해당 엔드포인트가 열려 있어야 하는 것임에도 불구하고 공용 엔드포인트에서 심각한 IDOR을 플래그 지정하기 때문입니다. 이는 패턴이 일반화되지 않는 문제에 패턴 인식을 적용하는 것입니다.

왜냐하면 판정은 오직 이 연산자만이 아는 의도에 달려 있기 때문입니다. 클래스 1 문제에 구성 일관성 검사기(configuration consistency checker)를 사용하는 것도 마찬가지로 잘못된 방법입니다. SQL 인젝션은 구성 모순이 아니기 때문에, 구성 일관성 검사기는 이를 찾을 수 없습니다. SQL 인젝션은 연산자가 선언한 내용과 관계없이 존재하는 코드 결함이기 때문입니다. 이 도구들은 상호 교환할 수 없습니다. 각각 다른 문제 클래스를 해결합니다. 클래스 1의 경우: 패턴 인식 기반 AI 지원 취약점 발견 — LLM 기반 모의 해킹(pen testing), 퍼징(fuzzing), SAST, 에이전트형 보안 스캐너가 클래스 1 문제를 잘 처리합니다. 스캐너는 학습 데이터에서 패턴을 학습합니다: '이 코드 형태는 인젝션으로 이어진다', '이 API 동작은 접근 제어 오류를 나타낸다'. 취약점 자체가 보편적이기 때문에 패턴이 일반화됩니다. AI 지원 스캐닝이 과장된 결과를 낳는다는 커뮤니티의 비판은 클래스 1 내에서는 타당합니다. 일부 발견 사항은 낮은 등급의 목표물에 있고, 일부 버그는 악용할 수 없으며, 일부 결과는 소스 기반으로 보조됩니다. 커뮤니티가 검증을 요구하는 것은 옳습니다. 하지만 접근 방식 자체는 건전합니다: 패턴 인식이 일반화될 때 작동하기 때문입니다. 이 접근 방식이 무너지는 지점은 클래스 1과 클래스 2 사이의 경계에서 발생합니다. IDOR 예시가 바로 그 경계에 놓여 있습니다. 일부 IDOR은 보편적입니다(다른 사용자의 개인 데이터에 접근하는 것은 항상 잘못된 것입니다). 하지만 일부는 의도에 따라 달라집니다(예측 가능한 ID를 통해 공개 기록에 접근하는 것은 설계상 허용될 수 있습니다). 스캐너가 이 둘을 구별하지 못할 때, 노이즈를 생성합니다. 해결책은 더 나은 AI가 아닙니다.

문제는 이제 운영자의 의도가 판결을 결정하는 Class 2 영역으로 넘어갔다는 것을 인식하는 것입니다. 왜 더 많은 학습이 Class 2를 해결하지 못할까요? 이유는 구조적입니다. Class 1에서는 판결이 코드의 함수에 달려 있습니다: verdict = f(code). 이 함수는 모든 배포에서 동일합니다. 충분한 예제로 학습시키면 모델은 이를 잘 근사화합니다. 하지만 Class 2에서는 의도가 변수입니다: verdict = f(configuration, intent). 구성(configuration)은 보입니다. 그것은 IAM 정책, S3 태그, Bedrock 에이전트 설정 등입니다. 그러나 의도(intent)는 운영자가 제공하며, 그 값은 시나리오마다 달라집니다. 공용 버킷은 의도가 '정적 자산 서비스'일 때 올바릅니다. 같은 공용 버킷이라도 의도가 '환자 기록 저장'일 때는 위반입니다. 구성은 동일합니다. 의도는 다릅니다. 판결이 뒤집힙니다. 왜냐하면 의도가 그 함수의 변수이기 때문에, 학습 과정에서 모델에 내장될 수 없기 때문입니다. 이는 학습 전에 알려지지 않습니다—어떤 데이터셋도 이 운영자의 미래 결정을 담고 있지 않습니다. 또한 학습 중에도 알려지지 않습니다—모델은 다른 운영자들의 구성을 통해 패턴을 학습하지만, 그 어떤 것도 이 운영자의 의도를 포함하고 있지 않습니다. 그리고 학습 후에도 알려지지 않습니다—모델이 새로운 배포를 만날 때, 의도 변수는 모델이 한 번도 본 적 없는 값을 가지기 때문입니다. 왜냐하면 그 값은 이 특정 운영자가 이 특정 버킷에 태그를 지정하고 이 특정 에이전트를 구성할 때 생성되었기 때문입니다. 따라서 변수는 모델이 학습될 때 아직 존재하지 않습니다.

이러한 값은 운영자가 배포 결정을 내릴 때 존재하게 됩니다. AI 스캐너는 구성(configuration)을 봅니다. 의도(intent)를 보지는 못합니다. 이는 모델의 수명 주기 어느 단계에서도 값이 없는 변수를 가진 방정식을 푸는 것과 같습니다. 아무리 많은 학습 데이터가 이 간극을 채울 수 없습니다. 왜냐하면 이 간극은 데이터 문제가 아니라 타이밍 문제이기 때문입니다. 그 값은 모델이 배포된 후에, 모델이 한 번도 관찰하지 못한 운영자에 의해, 그리고 모델이 구성만으로는 추론할 수 없는 목적에 의해 생성됩니다. 이것이 바로 거짓 양성(false-positive) IDOR가 학습으로 해결될 수 없는 이유입니다. 스캐너는 엔드포인트와 응답을 봅니다. 해당 데이터가 공개되기를 운영자가 의도했는지 여부는 볼 수 없습니다. 그 의도는 모델이 학습되었을 때 존재하지 않았습니다. 이 운영자가 이 애플리케이션을 설계했을 때 비로소 존재하게 된 것입니다. 모델은 추론(inference) 단계에서 처음으로 이 값에 직면하며, 일반화할 사전 예시가 없습니다. 클래스 2: 제약 조건 만족 (Constraint satisfaction) 구성 일관성 검사(Configuration consistency checking)는

이것은 만족 가능성 질의(satisfiability query)입니다. Z3와 같은 SMT 솔버는 2007년 이래로 항공 소프트웨어, CPU 검증 및 컴파일러 정확도 등에서 정확히 이러한 문제를 해결해 왔습니다. 솔버는 학습 데이터가 필요하지 않습니다. 조직 전반에 걸쳐 일반화할 필요도 없습니다. 이 솔버는 THIS 연산자의 단언(assertions)을 읽고 그것들이 서로 모순되는지 확인합니다. 논리는 모든 배포에서 동일합니다. 사실만 다릅니다. 이것이 바로 제약 조건 솔버가 만들어진 목적입니다—동일한 엔진, 다른 입력값, 결정론적 답변. 같은 질문에 답하는 학습된 모델은 “이 구성은 안전하다”와 “이 구성은 안전하지 않다”라는 수천 개의 레이블링된 예시를 필요로 할 것입니다. 그것은 증명(proof)이 아닌 확률을 산출할 것입니다. 훈련에서 본 적 없는 새로운 조합에는 어려움을 겪을 것입니다. 그리고 결정적으로, 의도(intent)에 대해서는 실패합니다—왜냐하면 모든 조직의 태그, 정책 및 분류는 고유하기 때문입니다. 모델에게 수천 개의 IDOR(Insecure Direct Object Reference) 발견 사례를 보여주더라도, 엔드포인트 /api/records/123이 열려야 하는지 여부를 여전히 판단할 수 없습니다. 왜냐하면 그것은 THIS 연산자가 THIS 애플리케이션을 위해 의도한 바에 달려있고, 그 의도는 어떤 훈련 코퍼스에도 없기 때문입니다. 그것은 오직 이 연산자만이 제어하는 태그, 정책 및 구성에 있습니다.

각 클래스에 맞는 올바른 도구

속성 (Property)	클래스 1 (보편적 패턴)	클래스 2 (의도 의존적)	예시
SQL 주입, XSS, 버퍼 오버플로우	PHI가 공개적으로 인덱싱된 버킷	RAG 파이프라인 검증은 연산자의 의도에 따라 달라짐?

아닙니다. 항상 취약점입니다. 예. 선언된 데이터 분류에 따라 다릅니다. 패턴이 일반화되나요? 예. 하나의 SQLi가 다음 SQLi와 유사합니다. 아니요. 모든 연산자의 의도는 다르습니다. 학습 데이터가 도움이 되나요? 예. 더 많은 예시는 탐지 성능을 향상시킵니다. 아니요. 각 배포의 의도는 고유합니다. 올바른 접근 방식은 패턴 인식(Pattern recognition) (AI/ML)과 제약 만족(Constraint satisfaction) (SMT solvers)입니다. 적절한 도구는 SAST, DAST, 퍼징(fuzzing), AI 스캐너와 구성 일관성 검증입니다. 스캐너가 보는 것 vs. 일관성 검증이 보는 것을 생각해 봅시다. 이제 클래스가 분리되었으므로 격차가 눈에 보이기 시작합니다. AWS의 Bedrock 에이전트를 고려해 보세요. 컴포넌트 수준 스캐너는 각 리소스를 개별적으로 확인합니다: Bedrock 암호화: ✅ 통과 (PASS) Bedrock VPC: ✅ 통과 (PASS) Bedrock 모델 액세스: ✅ 통과 (PASS) S3 암호화: ✅ 통과 (PASS) S3 공개 액세스: ✅ 통과 (PASS) Lambda 암호화: ✅ 통과 (PASS). 6가지 확인. 6개 모두 통과했습니다. 규정 준수(COMPLIANT)입니다. 이것들은 구성에 적용된 클래스 1 검사입니다: '암호화가 활성화되어 있는가?'는 보편적인 패턴입니다. 그 답은 연산자의 의도에 달려있지 않습니다. 암호화는 되어 있어야 합니다. 하지만 에이전트의 실행 역할에는 lambda:InvokeFunction on Resource: *가 있습니다. 이는 계정 내 모든 Lambda를 호출할 수 있다는 의미입니다. 이 Lambda 함수 중 하나는 data_classification: phi 태그가 지정된 버킷에서 읽어옵니다. 지식 기반(knowledge base)은 RAG 검색을 위해 동일한 PHI 버킷을 인덱싱합니다. 이것들은 클래스 2 문제입니다. 판결은 에이전트의 권한, Lambda의 액세스, 그리고 버킷의 데이터 분류 간의 상호 작용에 달려 있습니다. 이 세 가지 모두 의도적인 구성입니다.

모순은 그 조합에 있습니다. 일관성 검증(Consistency verification)은 세 서비스 모두에서 사실을 추출하고, 이들이 금지된 상태로 구성되는지 확인한 다음, 다음과 같이 보고합니다: "귀하의 고객 대면 챗봇이 Lambda 도구 체인을 통해 환자 기록을 반환할 수 있습니다." 다섯 가지 개별 발견 사항(individual findings)은 세 가지 CRITICAL 복합 사슬(compound chains)로 구성됩니다. 스캐너의 6/6 PASS와 일관성 검사기의 3 CRITICAL 사슬 모두 정확합니다. 왜냐하면 이들은 서로 다른 문제 클래스에 대해 서로 다른 질문에 답하고 있기 때문입니다. 일관성 검증은 서비스 전반에 걸친 복합 탐지(Compound detection)를 제공합니다. 개별 확인만으로는 서비스 간의 조합을 찾을 수 없습니다. 에이전트의 역할이 과도하게 권한을 가지고 있고(overpermissioned) AND Lambda가 PHI를 읽고 AND 지식 기반이 PHI를 인덱싱할 때, 복합 사슬은 단일 체인으로 발생하며 특정 공격 경로를 명시하는 설명과 함께 보고됩니다. 의도 인식 평가(Intent-aware evaluation). IDOR 문제는 여기에서 존재하지 않습니다. 왜냐하면 작업자의 의도가 구성에 인코딩되어 있기 때문입니다. 태그는 민감도를 선언합니다. 정책은 접근을 선언합니다. 이 도구는 데이터가 민감한지 추측하지 않습니다. 작업자가 태그를 지정했기 때문입니다. "귀하의 PHI-태그가 지정된 버킷이 공개 대면 지식 기반에 인덱싱되어 있다"는 추측이 아닙니다. 태그와 구성 모두 명시적인 작업자 결정 사항입니다. 이 발견 사항은 분류 연습(triage exercise)으로 해결되는 것이 아니라 구체적인 결정(태그 제거 또는 데이터 소스 변경)으로 해결됩니다. 수학적 증명(Mathematical proof). Z3는 sat (금지된 상태가 도달 가능함) 또는 unsat (수학적으로 불가능함)을 반환합니다. 신뢰도 점수가 아닙니다. 확률이 아닙니다.

동일한 쿼리를 다시 실행하거나 다른 솔버를 통해 검증할 수 있는 증명입니다. 규정 준수 증거(compliance evidence)의 경우, 증명이 신뢰도 점수보다 우월합니다. 추적성(Traceability). 복합 체인의 모든 단계는 결정론적 식별자(deterministic identifier)를 통해 특정 구성 파일의 특정 속성으로 거슬러 올라갑니다. grep 하나가 관찰 파일(observation file), 속성 경로(property path), 그리고 타임스탬프를 반환합니다. 팀이 근본 원인을 검색할 필요가 없습니다. 도구가 이름을 붙여줍니다. 에어 갭 운영(Air-gapped operation). 자격 증명, API 호출, 네트워크 접근이 전혀 없습니다. 노트북에서의 정적 스냅샷 분석입니다. GDPR, HIPAA 또는 FedRAMP와 같은 규제를 받는 조직에게 이는 기능이 아니라 필수 전제 조건입니다. 일관성 검증(consistency verification)이 수행하지 않는 것들. SQL 인젝션(SQL injection)을 찾아내지 못합니다. XSS를 발견하지 못합니다. API 엔드포인트를 퍼징(fuzz)하지 못합니다. 종속성을 스캔하여