AI 거버넌스 - 초지능 AI도 모든 보안 버그를 간단히 고칠 수는 없다

https://joshuasaxe181906.substack.com/p/even-superintelligent-ai-cant-just

2026.10.7
[Even superintelligent AI can’t just fix all the security bugs]

초인공지능의 발전에도 불구하고 사이버 보안 취약점을 완전히 해결하는 것은 불가능하다는 주장을 담고 있습니다. 저자는 소프트웨어 보안에 대한 흔한 오해들을 반박하며, 인간의 사회적 맥락 부족과 복잡한 시스템 구조 등 기술적·사회적 한계로 인해 모든 버그를 찾아내는 것은 근본적으로 어렵다고 설명합니다. 또한, 코드 자체의 결함을 모두 고치더라도 사회공학적 해킹이나 비정상적인 접근과 같은 다른 위협은 여전히 존재합니다. 따라서 보안은 완벽한 해결책에 의존하기보다 다양한 방어 수단을 겹겹이 쌓아 관리해야 하는 다층적인 과정임을 강조합니다.

 

 

 

 

 

 

「초지능 AI도 모든 보안 버그를 간단히 고칠 수는 없다」 챕터별 분석

저자: Joshua Saxe
원문: Even superintelligent AI can’t just fix all the security bugs

핵심 논지: AI가 코드 분석·수정 능력을 극도로 높이더라도, 조직의 의도와 권한 규칙, 검증 명세의 한계, 시스템 간 상호작용, 사람을 통한 공격까지 자동으로 해결하지는 못한다. 따라서 목표는 ‘모든 버그의 제거’가 아니라 제한된 자원으로 피해를 가장 많이 줄이는 다층 방어여야 한다.[1]

이 글은 실험 논문이 아니라 보안 전략에 관한 논증형 글입니다. 아래는 원문의 실제 절 구성을 따르며, 저자의 주장·도표 수치·분석적 평가·실무 제언을 구분합니다. 도표에 인용된 기초 보고서와 저자의 모델 코드는 이번 분석에서 독립적으로 검증하지 않았습니다.

 

1. 서론 — 코드 보안과 사이버 안정을 동일시하지 말라

핵심 내용

저자는 다음 두 가지 기대가 혼동되고 있다고 지적합니다.

• AI의 능력이 높아지고 비용이 낮아지면 모든 코드를 안전하게 만들 수 있다는 기대
• 코드가 안전해지면 인터넷의 공격·방어 관계도 안정화된다는 기대

이에 대해 두 가지 구조적 병목을 제시합니다.[1]

병목	원문의 의미	분석상 중요성
사회기술적 병목	프로그램과 검증 명세는 사람이 실제로 원하는 바를 완벽하게 표현하지 못함	구현 정확성 이전에 요구사항·정책의 정확성이 문제
프로그램 이론·시스템 병목	현대 프로그램은 여러 조직에 걸친 부분 관측 가능한 분산 시스템의 구성요소임	개별 코드 검증과 전체 운영환경의 안전성을 구분해야 함

분석

이 글의 출발점은 ‘AI가 얼마나 똑똑한가’보다 ‘무엇을 알아야 안전성을 판단할 수 있는가’입니다.

예를 들어 코드가 문서에 충실하게 구현되었더라도, 문서에 잘못된 권한 규칙이 있거나 외부 기관과의 책임 경계가 빠져 있다면 시스템은 안전하지 않을 수 있습니다.

평가: 문제 설정은 타당합니다. 다만 제목의 “모든 버그를 고칠 수 없다”를 특정 시스템의 특정 속성도 검증할 수 없다는 뜻으로 읽으면 안 됩니다. 본문은 실제로 명시된 속성을 정해진 가정 아래 증명하는 것의 가치를 인정합니다.[1]

 

2. 오해 ① — “AI는 사회적 맥락 없이 모든 버그를 자동으로 고칠 수 있다”

핵심 주장

저자는 보안 버그를 사회적 맥락 의존성에 따라 나눕니다.[1]

구분	예시	필요한 정보
맥락 의존성이 낮은 버그	버퍼 오버플로 등 메모리 손상	코드·실행 구조 중심
맥락 의존성이 높은 버그	잘못된 접근권한, 조직 규칙 위반	업무 목적·정책·권한·사람의 결정

원문은 가상의 의료정보 시스템을 예로 듭니다. 정책상 특정 조건을 충족하는 의사만 진료기록을 볼 수 있어야 하는데, 프로그램이 다른 직군에도 접근을 허용한다면 버그입니다. 그런데 그 정책이 코드나 AI가 접근 가능한 문서에 없다면, 코드만 분석해서 잘못을 확정하기 어렵습니다.[1]

주의: 이 사례의 직군·국적 조건은 논점을 설명하기 위한 가정이지, 실제 의료정보 접근 법규를 설명하는 내용은 아닙니다.

도표가 제시하는 수치

저자의 베이지안 모델 기반 시뮬레이션은 다음과 같이 추정합니다.[1]

항목	도표 수치	근거 수준
전 세계 배포 소프트웨어의 미발견 보안 버그	약 4억 5천만 개	시뮬레이션 중앙값
맥락 의존성이 낮은 버그	약 3억 개	모델 추정
맥락 의존성이 높은 버그	약 1억 5천만 개	모델 추정
어려운 버그 중 조직 내부 업무 소프트웨어 비중	69%	모델 추정
전체 버그 수의 제시 범위	1억 8천만~12억 개	도표의 ‘그럴듯한 범위’
어려운 버그의 내부 소프트웨어 비중 범위	48~88%	도표의 ‘그럴듯한 범위’

분석 및 한계

이 절의 강점은 버그 탐지를 ‘코드 패턴 탐지’와 ‘업무 규칙의 위반 판단’으로 분리한다는 점입니다.

다만 ‘쉬운 버그’라는 표현은 주의가 필요합니다. 이는 저자의 분류상 사회적 맥락이 덜 필요한 버그이지, 수정과 배포가 항상 쉽다는 뜻은 아닙니다. 수정 후 호환성·성능·회귀 검증은 별도 문제입니다.

또한 수치는 전 세계 버그를 직접 센 결과가 아닙니다.

[확인 필요: 원문 첫 번째 도표] 모델의 입력자료, 분류 기준, 사전분포, 추정 코드가 공개 본문에 제시되지 않아 수치를 재현하거나 독립 검증할 수 없습니다. ‘어려운 버그가 정확히 3분의 1’이라는 확정 통계로 인용하기보다 모델 추정으로 표시해야 합니다.

실무 시사점 — 분석자 제언

AI 보안 에이전트에는 소스코드만이 아니라 다음 맥락이 필요합니다.

• 승인된 업무·보안 요구사항
• 역할별 접근권한표
• 데이터 이용 목적과 기관 간 제공 조건
• 예외 승인·위임·권한 회수 규칙
• 정책 충돌 시 최종 결정권자

핵심: AI가 정책을 찾아내거나 모순을 제안할 수는 있어도, 정책의 정당성과 승인 권한까지 자동으로 확보하는 것은 아닙니다.

 

3. 오해 ② — “모든 버그를 고쳤다는 사실을 알 수 있다”

핵심 주장

저자는 더 이상 버그가 발견되지 않는다는 사실만으로 버그가 없다고 결론 내릴 수 없다고 말합니다.[1]

탁한 호수에서 낚시를 하는 비유를 사용합니다. 물고기가 잡히지 않는 이유는 실제로 물고기가 없어서일 수도 있지만, 낚싯대가 부적합하거나 다른 도구가 필요해서일 수도 있습니다.

프로그램의 상태를 전부 탐색하는 것은 대체로 실용적이지 않으며, 증명은 전수 탐색을 대신할 수 있어도 명시된 속성과 가정에 대해서만 성립합니다.[1]

분석

이 절은 보안 평가에서 다음 세 문장을 구분하도록 요구합니다.

1. “이번 검사에서 취약점을 발견하지 못했다.”

1. “정해진 범위와 가정 아래 특정 속성이 성립함을 검증했다.”

1. “이 시스템에는 취약점이 없다.”

첫 번째와 두 번째는 검증 범위를 명시하면 의미 있는 결론입니다. 세 번째는 훨씬 강한 주장입니다.

또한 환경 변화가 중요합니다. 기존에 안전했던 시스템도 권한 정책, 연계 API, 외부 의존성, 운영설정이 바뀌면 이전 검증의 전제가 유지되지 않을 수 있습니다.

실무 시사점 — 분석자 제언

감리·보안 보고서에서는 ‘취약점 0건’보다 ‘검증 범위와 잔여 위험’을 함께 제시해야 합니다.

보고 항목	필요한 내용
검증 대상	저장소·버전·구성요소·운영환경
검증 방법	정적 분석·동적 분석·퍼징·정형검증 등
검증 속성	메모리 안전성·권한 통제·정보흐름 등
제외 범위	외부 시스템·수동 업무·접근 불가능한 코드
잔여 불확실성	미탐 가능성·가정 변화·미정의 정책

핵심: ‘미발견’은 검사 결과이지, 보안의 완결성을 뜻하지 않습니다.

 

4. 오해 ③ — “정형검증은 모든 버그가 사라졌음을 보장한다”

핵심 주장

저자는 정형검증 자체를 부정하지 않습니다. 증명된 보장과 실제 시스템이 그 보장의 조건을 충족하는지는 다른 문제라고 설명합니다.[1]

원문의 논리 구조는 다음과 같습니다.

textCopy

검증된 보장:

입력이 안전하다면,

실행은 비밀정보 접근·보호파일 수정·권한 상승을 하지 않는다.

 

실제 프로그램:

신뢰하는 웹사이트에서 데이터를 다운로드한다.

그 데이터를 실행한다.

신뢰하던 웹사이트가 침해되면 다운로드한 데이터가 ‘안전한 입력’이라는 전제는 깨질 수 있습니다. 이때 증명이 틀린 것이 아니라, 증명을 적용하기 위한 전제조건이 충족되지 않은 것입니다.[1]

도표 분석

도표는 전 세계 코드 중 영향력이 큰 3%를 정형검증한다는 가정 아래, 취약점 악용에 따른 위험을 다음과 같이 모델링합니다.[1]

단계	위험지수
현재 취약점 악용 위험	100
증명으로 제거되는 위험	−32
공격자가 다른 표적으로 이동하며 되살아나는 위험	+10
검증 이후 남는 위험	78

산술적으로 순감소는 22%입니다. 여기에 ‘전체 침입 중 약 4분의 1이 소프트웨어 버그에서 시작한다’는 가정을 적용하면 전체 침입 감소는 약 5.5%이며, 도표는 이를 약 6%로 표현합니다.[1]

분석 및 한계

여기에는 서로 다른 한계가 들어 있습니다.

• 명세 범위의 한계: 증명하지 않은 속성은 보장되지 않음
• 환경 가정의 한계: 신뢰한 외부 요소가 바뀌면 전제가 깨짐
• 공격자 적응의 한계: 보호가 강해진 영역을 피해 다른 경로를 선택할 수 있음

다만 도표는 보안 위험지수와 침입 건수의 관계를 단순화한 시나리오입니다. 위험이 22% 줄면 실제 침입도 같은 비율로 줄어든다고 자동으로 보장되는 것은 아닙니다.

[확인 필요: 원문 정형검증 도표] ‘코드 3%’, ‘위험 32 제거’, ‘공격 전환으로 10 회복’은 저자 모델의 조건과 결과입니다. 특정 사업에서 정형검증의 효과가 정확히 22%라는 근거로 사용할 수 없습니다.

실무 시사점 — 분석자 제언

정형검증을 도입할 때는 다음 연결을 관리해야 합니다.

승인된 정책 → 검증 명세 → 증명 → 운영환경의 전제 확인 → 변경 시 재검증

핵심 질문은 “증명했는가?”뿐 아니라 “무엇을, 어떤 가정 아래 증명했고, 운영환경이 그 가정을 유지하는가?”입니다.

 

5. 오해 ④ — “모든 버그를 고치면 치명적 AI 사이버 위험도 사라진다”

핵심 주장

저자는 모든 프로그램 보안 버그를 없애더라도 사이버 범죄가 상당 부분 남을 수 있다고 말합니다.[1]

대표적인 경로는 사람을 설득해 자격증명이나 결제정보를 확보하고, 이를 정상 인증 절차에 사용해 자원에 접근하는 방식입니다. 원문은 이런 경로로 확산하는 AI 웜을 가상 시나리오로 제시합니다. 실제 관측된 자율 확산 사건을 보고하는 것은 아닙니다.[1]

도표가 보여주는 내용

도표는 두 가지 다른 모집단을 구분합니다.[1]

구분	버그 관련 또는 관련 가능	버그 없음	불명확·혼합·기타
2024~2025년 침해대응 보고서 7개의 초기 침입경로 평균	25%	54%	21%
2025년 FBI 신고 사이버범죄 손실의 저자 분류	8%	76%	16%

버그를 필요로 하지 않는 초기 침입경로 54%는 도표상 다음 항목으로 구성됩니다.

• 피싱: 26%
• 탈취되었거나 유효한 비밀번호: 16%
• 내부자 및 잘못된 설정: 8%
• 비밀번호 추측: 4%[1]

분석 및 한계

이 절의 중요한 메시지는 인증 성공과 정당한 행위가 같지 않다는 것입니다.

유효한 자격증명으로 시스템이 정상 동작하더라도, 계정을 탈취한 공격자가 사용했다면 보안 사고가 될 수 있습니다.

다만 도표 해석에는 제약이 있습니다.

• 보고서별 초기 침입경로 정의가 다릅니다.
• 도표의 ‘버그 관련’에는 실제 관련이 확인된 경우뿐 아니라 관련될 수 있는 경우도 포함됩니다.
• FBI 손실 분류는 저자의 재분류이며, 초기 침입 건수 통계와 같은 지표가 아닙니다.
• 초기 침입에 버그가 필요 없었다고 해서 공격 전체 과정에서도 버그가 전혀 쓰이지 않았다고 단정할 수는 없습니다.

따라서 이 도표는 ‘코드 수정만으로 전체 위험을 제거할 수 없다’는 주장을 뒷받침하지만, 모든 환경의 정확한 공격 비중을 확정하지는 않습니다.

실무 시사점 — 분석자 제언

코드 보안과 함께 다음을 별도 통제해야 합니다.

• 계정·인증·권한 수명주기
• 민감 행위의 승인 및 재확인
• 외부 자원 생성·비용 지출 제한
• 이상행위 탐지와 접근 회수
• 사람·에이전트가 수행한 행위의 추적성

핵심: 버그 없는 코드도 탈취된 권한이나 부적절한 정상 기능 사용까지 저절로 막지는 못합니다.

 

6. 대응 전략 — “그래도 가능한 한 많은 버그를 고쳐야 한다”

핵심 주장

저자의 결론은 비관론이 아닙니다. 공격자가 선택할 수 있는 경로를 어렵게 만들기 위해 여러 방어 수단을 포트폴리오로 운영하고, AI 능력과 잔여 취약점의 변화에 따라 재조정하자는 것입니다. 우선순위 기준은 투입 비용당 기대 피해 감소입니다.[1]

원문이 제시한 세 가지 전략

전략	원문의 취지	남는 한계
바이너리 재작성	컴파일된 프로그램에 제어흐름 등 실행상 보호를 추가	의도된 흐름 추론의 불확실성, 제한된 방어 범위
코드 재작성	C·C++ 등을 Rust와 같은 메모리 안전 언어로 전환	업무 규칙·권한·논리 오류는 남음
개별 버그 탐지·수정	재작성하기 어렵거나 비싼 코드의 취약점을 지속적으로 제거	모든 버그 제거를 보장하지는 못함

도표 분석

별도 도표는 실제로 악용된 취약점 100개를 대상으로, 관련 코드 전체에 각 전략을 적용한다면 차단할 수 있는 수를 모델 추정합니다.[1]

전략	차단 추정	남아 악용 가능한 취약점
바이너리 재작성	6개	94개
메모리 안전 언어로 코드 재작성	21개	79개
현실적 명세에 대한 정형검증	48개	52개

이 수치는 앞 절의 ‘핵심 코드 3%를 검증했을 때의 위험 감소’와 대상·분모가 다릅니다. 또한 세 전략의 효과는 메모리 오류 등에서 겹치므로 단순 합산할 수 없습니다.[1]

기술적 보완점

[보완 필요: 원문 “Binary rewriting” 절] 본문은 메모리 손상 검사와 제어흐름 무결성(CFI)을 다소 넓게 묶어 설명합니다. 이를 실무 설계에 옮길 때는 메모리 접근 검사, 제어흐름 보호, 하드웨어 보호기법을 구분해야 합니다. CFI 적용이 모든 메모리 손상 버그의 제거를 뜻하지는 않습니다.

실무 시사점 — 분석자 제언

방어 수단 선정 시 다음 질문을 함께 평가하는 편이 적절합니다.

1. 해당 취약점이 실제로 악용될 가능성은 얼마나 큰가?

1. 악용되면 어떤 데이터·업무·기관에 피해가 발생하는가?

1. 보호 효과가 여러 시스템에 확산되는 공통 구성요소인가?

1. 수정·검증·배포·운영 비용은 얼마인가?

1. 수정에 따른 회귀 위험과 공격자의 대체 경로는 무엇인가?

핵심: ‘몇 개의 버그를 제거했는가’보다 ‘어떤 피해를 얼마나 줄였는가’가 전략적 성과지표입니다.

 

7. 결론 — 보안은 구멍이 있는 방어층을 겹치는 일이다

핵심 주장

저자는 보안을 스위스 치즈 모델로 설명합니다. 모든 방어층에는 구멍이 있으며, 소프트웨어 보안은 중요한 한 층이지만 유일한 층은 아닙니다.[1]

문을 잠가도 창문으로 들어올 수 있고, 창문을 막아도 다른 경로가 남는다는 비유는 다음을 뜻합니다.

• 어떤 통제도 보안 전체를 대신하지 못한다.
• 그렇다고 개별 통제를 포기할 이유도 없다.
• 공격경로가 여러 통제의 빈틈을 연속으로 통과하지 못하도록 설계해야 한다.

분석

결론의 강점은 ‘완전한 보장은 어렵다’와 ‘개선은 필요하다’를 함께 유지한다는 점입니다.

다만 방어층은 단순히 많이 쌓는 것만으로 충분하지 않습니다. 여러 층이 같은 계정, 같은 정책 오류, 같은 외부 의존성에 기대면 한 번의 실패로 함께 무너질 수 있습니다. 이는 원문의 결론을 실무 설계로 확장한 분석입니다.

 

종합 평가

평가 항목	판단
논리적 강점	코드의 정확성, 정책의 적절성, 운영환경의 안전성, 전체 사이버 위험을 분리
실무적 강점	완전 제거보다 비용당 피해 감소와 방어 포트폴리오를 강조
근거상 한계	주요 도표에 저자 모델·재분류가 포함되며 공개 본문만으로 재현하기 어려움
해석상 주의	정형검증 무용론, AI 보안 자동화 무용론으로 읽어서는 안 됨
추가 검토 과제	AI 생성 코드의 신규 결함, 패치 회귀, 배포 지연 등 동적 위험은 별도 평가 필요

최종 판단: 이 글은 “AI의 코드 수정 능력만으로 보안 문제가 종결된다”는 과도한 기대를 교정하는 데 유용합니다. 다만 도표의 수치는 확정된 보편 법칙이 아니라, 통계 재분류와 모델 가정에 따른 결과로 인용해야 합니다.

AI는 보안 결함을 줄이는 강력한 수단이 될 수 있지만, 무엇을 보호할지 정하는 정책과 권한, 검증 전제를 유지하는 운영, 사람과 시스템을 함께 보호하는 다층 통제를 대신하지는 못합니다.

출처

[1] https://joshuasaxe181906.substack.com/p/even-superintelligent-ai-cant-just — Joshua Saxe — Even superintelligent AI can’t just fix all the security bugs