Mythos 를 해부하다 – My AI Smarteasy와 책 읽기 – 제19장. 가르치지 않은 능력
수십 년 묵은 자물쇠가 단돈 50달러에 열린 이유: 장기 미발견 취약점과 방어의 시간표
안녕하세요, 저스틴입니다! 다시 만나서 반가워요.
오늘 다룰 주제는 보안 분야에서 가장 오랫동안 믿어왔던 안도감 하나를 완전히 무너뜨린 사건, 바로 ‘장기 미발견 취약점(오랫동안 숨겨져 있던 코드 속 약점)’입니다.
제공해주신 교재 자료에서 저자는 우리의 관점을 완전히 바꿔야 한다며 이렇게 말합니다.
“바뀐 것은 공포가 아니라 시간표다.”
AI가 갑자기 마술 같은 새로운 공격 기법을 발명했다는 뜻이 아닙니다. 지난 수십 년 동안 내로라하는 전문가들과 자동화 도구가 검토하고 지나쳤던 아주 깊은 곳의 결함들을, 엄청나게 싸고 빠르고 집요하게 찾아내기 시작했다는 뜻입니다.
무슨 일이 일어났는지, 그리고 왜 이것이 우리의 보안 시간표를 바꿔놓았는지 같이 풀어볼까요?
STAGE 1 — 왜 이 개념이 중요할까요? (Why It Matters)
여러분, 만약 어떤 소프트웨어가 20년이 넘는 시간 동안 수백만 명의 개발자와 전문가들에 의해 검토되었고, 보안으로 가장 유명한 시스템이라면 안전하다고 믿으실 건가요?
과거에는 “오래되고 유명한 코드는 수많은 눈이 거쳐 갔으니 깨끗할 것이다”라는 확률적 안도감이 존재했습니다. 하지만 최근 AI 모델이 이 법칙을 깼습니다.
- OpenBSD (27년 된 결함): 가장 엄격한 보안을 자랑하는 시스템에서 1998년에 작성된 결함을 단 1회 실행(비용 50달러 미만)으로 찾아냈습니다.
- FFmpeg (16년 된 결함): 우리가 보는 대부분의 영상 플랫폼에 쓰이는 부품 코드에서 2003년에 심어진 결함을 찾아냈습니다. 자동 시험 도구가 무려 500만 번이나 통과했던 코드였습니다.
이 사건들이 주는 메시지는 명확합니다. “오래되었다고 해서 안전한 코드라는 증거는 어디에도 없다”는 것입니다. AI 덕분에 숨어있는 약점을 찾아내는 비용과 시간이 폭락했습니다. 이제 방어자는 “우리는 오래된 안전한 코드를 쓰니 안심이다”라는 생각을 버려야 합니다.
STAGE 2 — 핵심 개념 풀어보기: 수십 년을 숨어있던 ‘4가지 장벽’ (Unpacking the Core Concept)
그렇다면 이 버그들은 도대체 어떻게 20년이 넘도록 사람과 자동 도구의 눈을 피해 숨어있을 수 있었을까요? 개발자들이 게을러서가 아닙니다. 구조적으로 잘 안 보이는 4가지 장벽이 있었기 때문입니다.
1. 퍼징(Fuzzing)의 사각지대
- 설명: 퍼징은 무작위 데이터를 대량으로 쏟아부어 프로그램이 터지는지 보는 시험 방식입니다. 무작위 대입이다 보니, 아주 특정한 조건이 딱 맞아떨어져야만 터지는 깊은 골목은 건드리지 못합니다.
2. 센티넬(Sentinel) 값과의 충돌
- 비유: 아파트 입구 출입증에 ‘예외 통과용 특별 번호(9999)’를 정해두었는데, 하드웨어 착오로 하필 실제로 살고 있는 주민의 동호수가 ‘9999’였던 상황입니다.
- 설명: FFmpeg의 결함이 바로 이것이었습니다. 데이터의 끝을 나타내는 ‘특수 표시 값(센티넬)’이 정상적인 데이터 값과 정확히 겹치면서 프로그램이 옆 메모리를 침범하게 된 것입니다. 무작위 대입(퍼징)으로는 이 기막힌 우연의 충돌을 500만 번 동안 맞춰내지 못했습니다.
3. ‘오래되었으니 안전하다’는 심리적 장벽
- 수많은 전문가가 이미 거쳐 갔다는 안도감 때문에, 역설적으로 그 코드를 가장 덜 들여다보게 만든 인간의 심리적 블라인드입니다.
4. 메모리 안전 언어에 대한 과신
- Rust 같은 최신 메모리 안전 언어를 썼더라도, 하드웨어와 대화하기 위해 어쩔 수 없이 보안 검사를 끄는 구간(
unsafe블록)이 남습니다. 공격자는 바로 이 틈새를 찔렀습니다.
|
1 2 3 |
<span class="hljs-selector-attr">[기존 방식]</span> 무작위 대입 <span class="hljs-number">500</span>만 번 ──> 특수 조건에 막혀 버그 못 찾음 ❌ <span class="hljs-selector-attr">[AI 방식]</span> 코드의 논리와 의미 추론 ──> <span class="hljs-number">27</span>년 묵은 결함 바로 짚어냄 ($<span class="hljs-number">50</span>) 🎯 |
STAGE 3 — 증거와 실전 적용: 마술이 아닌 경제학, 그리고 패치 시간표 (Evidence & Application)
“이거 특정 AI 회사(미토스 등)의 일회성 과장 발표 아닌가요?”라고 물으실 수 있습니다. 하지만 이는 한 회사의 주장이 아니라 산업 전체에서 나타나는 ‘발견의 경제학’ 현상입니다.
대표적인 독립적 증거가 구글의 ‘Big Sleep’ 프로젝트입니다. 구글 연구진은 AI 에이전트를 이용해 세계적으로 가장 널리 쓰이는 데이터베이스인 SQLite에서 기존 자동화 도구들이 끝내 잡지 못했던 미공개 결함(Zero-Day)을 찾아냈습니다. 심지어 2025년에는 공격자들이 몰래 악용하려던 실제 움직임을 AI가 미리 읽어내어 사전에 차단하기도 했습니다.
📊 수십 년을 버틴 3가지 자물쇠 비교
| 대상 시스템 | 버그 나이 | 결함의 종류 | 위험의 성격 및 특징 |
|---|---|---|---|
| FreeBSD | 17년 | 파일 공유 서버 결함 | 최고 권한을 넘겨줄 수 있는 원격 코드 실행(RCE) 위험 |
| OpenBSD | 27년 | TCP 통신 규약 결함 | 숫자가 뒤집히는 정수 오버플로로 인한 시스템 마비(DoS) |
| FFmpeg | 16년 | H.264 코덱 센티넬 결함 | 자동 도구가 500만 번 지나쳐 간 메모리 범위 밖 침범 |
🛡️ 방어자의 대응: 공포가 아닌 ‘시간표’를 바꿔라
공격자가 약점을 찾아내는 시간이 하루~수시간 단위로 줄어들었습니다. 그런데 우리 조직이 보안 패치를 적용하는 데 두 달(60일)이 걸린다면 그 사이의 시간 격차가 곧 거대한 위험이 됩니다.
따라서 방어자의 실전 대응은 다음 3가지로 전환되어야 합니다.
- 사전 차단에서 ‘시간 단축’으로: 모든 결함을 사전에 없애는 것은 불가능합니다. 취약점이 발견된 후 패치하여 실제 시스템에 배포하기까지의 시간(Time-to-Patch)을 최대한 줄여야 합니다.
- SBOM (소프트웨어 부품 명세서) 도입: 내 시스템 안에 어떤 외부 부품 라이브러리가 들어있는지 성분표를 만들어두어, 약점이 터졌을 때 즉시 내 시스템의 적용 여부를 확인합니다.
- 들쭉날쭉한 경계(Jagged Frontier) 인정: AI의 능력이 어디서 갑자기 솟구칠지 예측할 수 없으므로, 오래된 부품이나 외부 노출 접점부터 우선순위를 두어 사전에 점검(SSDF)합니다.
STAGE 4 — 요약 및 스스로 점검하기 (Summary & Extension)
오늘 배운 내용을 3가지로 정리해 드립니다.
- AI는 새로운 공격법을 창조한 것이 아니라, 숨어있는 버그를 찾는 ‘발견의 비용과 시간’을 대폭 낮추었습니다.
- 20년 넘게 검증받은 구형 코드라도 퍼징의 사각지대나 센티넬 충돌 같은 결함이 숨어있을 수 있습니다.
- 따라서 방어의 핵심은 “모든 버그를 없애는 것”이 아니라, “발견된 후 패치하고 탐지하기까지의 시간을 단축하는 것”입니다.
