"이 AI는 보안 코드를 작성합니다"라는 말의 문제점

현재 모든 AI 코딩 도구들은 저마다의 방식으로 보안 인지 능력을 갖추고 있다고 주장합니다. 하지만 그중 거의 어떤 도구도 방금 작성한 코드가 실제로 얼마나 탄력적(resilient)인지 수치로 알려주지 않으며, 사후에 그 수치를 직접 검증할 수 있게 해주는 도구는 더욱 드뭅니다.

그것이 바로 제가 Adversarial Resilience Score (ARS)를 구축하여 메우고자 하는 간극입니다. 이는 GAUNTLEX의 핵심 지표이며, 저는 이것이 정확히 어떻게 계산되는지 — 마케팅용 버전이 아닌 실제 공식 — 설명하고자 합니다. 왜냐하면 아무도 감사(audit)할 수 없는 보안 지표는 지표가 아니라 단순한 주장일 뿐이기 때문입니다.

공식

ARS = Σ(attack_scores) / N

여기서 N은 특정 실행 시 생성된 코드에 가해진 적대적 공격(adversarial attacks)의 횟수이며 (Quick 모드 5회, Standard 모드 20회, Thorough 모드 50회), 각 개별 attack_score는 정확히 다음 세 가지 값 중 하나입니다:

• 1.0 — 완화됨 (mitigated). 공격에 대해 완전히 방어되었습니다.
• 0.5 — 부분적 (partial). 방어 기제는 존재하지만 우회 가능하거나 불완전합니다.
• 0.0 — 놓침 (missed). 방어가 전혀 없으며, 공격이 깨끗하게 성공했습니다.

각 공격은 GAUNTLEX의 Arbiter에 의해 독립적으로 점수가 매겨집니다. Arbiter는 별도의 모델 호출을 통해 판결(mitigated / partial / missed)과 한 줄의 이유를 제공하므로, 모든 점수에는 단순한 숫자가 아닌 설명이 함께 따라붙습니다. ARS는 이 점수들의 평균이며, 따라서 [0.0, 1.0] 사이의 값을 가집니다.

왜 통과율(pass rate)이 아닌 평균인가

이것이 제가 가장 중요하다고 생각하면서도 가장 흔히 간과되는 세부 사항입니다. ARS는 "차단된 공격의 백분율"이 아닙니다. 합격/불합격(pass/fail) 방식의 카운팅은 정보를 버리는 행위입니다. 이는 90% 완성된 방어 체계와 방어 체계가 전혀 없는 상태를 동일하게 취급하며, 간신히 우회(bypass)를 막아낸 공격과 아예 시도조차 되지 않은 공격을 동일하게 취급합니다. 공격별 연속적인 점수(continuous per-attack scores)를 평균 내는 방식은 그 기울기(gradient)를 유지합니다. 대부분의 공격을 깔끔하게 완화하지만 부분적으로 우회 가능한 방어 체계가 두 개 있는 코드베이스는, 비록 원시 카운트(raw counts)가 비슷해 보일지라도 일부 공격은 완전히 차단하고 일부는 완전히 실패하는 코드베이스와는 다르게, 그리고 더 유익하게 점수가 산출됩니다.

또한 이는 ARS가 테스트 선택을 통한 점수 조작(gaming)에 저항력이 있음을 의미합니다. 아주 쉽게 차단되는 공격들을 잔뜩 집어넣는다고 해서 점수를 부풀릴 수 없습니다. 왜냐하면 심각한 대상(예: 인증 우회 (auth bypass))에 대해 단 하나의 공격이라도 완전히 놓치게 되면, 주변에 얼마나 많은 쉬운 공격들이 있느냐에 상관없이 평균 점수가 크게 떨어지기 때문입니다.

제안이 아닌 관문 (The gate, not a suggestion)

GAUNTLEX는 설정 가능한 최소 ARS(기본값 0.80)와 함께 CI(지속적 통합) 환경에서 실행됩니다. 실행 결과가 해당 임계값(threshold) 미만이면 빌드는 실패합니다. 이는 경고나 나중에 검토하라는 Slack 알림이 아닙니다. 테스트 스위트(test suite)가 실패했을 때 머지(merge)가 차단되는 것과 동일한 방식으로 머지가 차단됩니다. fail_open의 기본값은 false입니다. 즉, 어떤 이유로 GAUNTLEX 자체가 실행을 완료할 수 없는 경우에도 이는 조용한 통과가 아니라 실패 상태로 간주됩니다.

그 이유는 다음과 같습니다. 권고 사항(advisory)에 불과한 보안 점수는 마감 압박이 있을 때마다 매번 무시됩니다. 머지를 차단하는 점수는 그런 문제를 겪지 않습니다.

범용이 아닌 도메인 특화 (Domain-specific, not generic)

실행당 5/20/50회의 공격은 일반적인 퍼징 (Fuzzing)이 아닙니다. 이는 특정 규제 또는 보안 도메인에 맞춰진 정책 플레이북 (Policy playbooks)에서 추출되었습니다: OWASP Top 10, HIPAA, FINRA, PCI DSS, SOC 2 (NIST SSDF 및 OWASP API Security는 설치 가능한 확장 기능으로 제공됨). 각 도메인 플레이북은 해당 도메인의 실제 실패 모드 (Failure modes)에 특화된 시나리오 세트로 큐레이션되어 있습니다. 예를 들어, HIPAA 플레이북은 PHI (개인 건강 정보) 처리 실패 모드를 조사하고, FINRA 플레이북은 단순히 이름만 바꾼 OWASP 목록이 아니라 해당 규제들이 실제로 중요하게 여기는 기록 보존 및 감사 추적 (Audit-trail) 패턴을 조사합니다.

GAUNTLEX가 생성하는 모든 결과물은 CWE 태그를 포함하며 제어 프레임워크 (Control frameworks: NIST SSDF, OWASP SAMM, SOC 2, ISO 27001)에 매핑됩니다. 따라서 보고서는 단순히 "여기에 점수가 있습니다"라고 말하는 것이 아니라, 컴플라이언스 검토자 (Compliance reviewer)가 특정 제어 항목으로 실제로 추적할 수 있는 정보를 제공합니다.

설계 단계부터 고려된 변조 방지 (Tamper-evident by construction)

자가 보고된 보안 점수는 그것을 생성한 대상에 대해 당신이 부여하는 신뢰만큼의 가치만을 가집니다. 아직 신뢰를 쌓지 못한 도구의 경우 그 가치는 거의 제로에 가깝습니다. 따라서 모든 GAUNTLEX 보고서에는 공격 결과의 정렬된 배열에 대해 계산된 SHA-256 해시가 포함됩니다. 누구나 gauntlex verify <run_id>를 실행하여 보고하고 있는 내용이 사후에 편집되지 않았음을 확인할 수 있습니다. 이것이 점수가 "좋다"는 것을 증명하는 것은 아닙니다. 다만 당신이 읽고 있는 점수가 수정된 버전이 아니라 실제로 계산된 점수임을 증명합니다.

증명 가능한 것 (Provable) 대 주장하는 것 (Claimed) 사이의 이러한 차이가 GAUNTLEX의 전체 설계 철학이며, 제가 ARS를 블랙박스 형태의 "보안 등급" 대신 감사 가능한 공식 (Auditable formula)으로 구축한 이유입니다.

사용해 보기

pip install gauntlex-ai
gauntlex run --spec your_spec.md --mode quick

Quick mode는 1분 이내에 5가지 공격을 실행하며, 지정한 사양(spec)에 대한 ARS를 출력합니다. 전체 기술 문서, 컴플라이언스 도메인 목록, 그리고 MCP 서버 통합(Claude Code, Cursor, Windsurf, Zed 내에서 작동)에 대한 정보는 repo와 Deep Dive doc에서 확인할 수 있습니다.

여러분이 직접 구축한 결과물에 대해 이 도구를 테스트해 보신다면, 어떤 결과가 나오는지 진심으로 알고 싶습니다. 이를 위해 Discussions를 마련해 두었습니다.