지난 20년 동안 우리는 더 나은 연기 감지기를 만들었습니다. 이제 우리는 마침내 소방관을 만들고 있습니다.

우리는 문제를 찾는 데 믿기 힘들 정도로 능숙해졌습니다.

당신의 IDE는 타이핑을 마치기도 전에 취약점(vulnerability)에 밑줄을 긋습니다. 당신의 CI 파이프라인은 3단계 깊이에 있는 전이 의존성(transitive dependency)이 2019년의 CVE를 가지고 있다는 이유로 실패합니다. 당신의 편지함에는 매주 화요일마다 Dependabot PR이 도착하며, 당신은 목요일까지 이를 정중하게 무시할 것입니다. GitHub Advanced Security, Snyk, Semgrep, Wiz, Orca, Lacework와 같은 스캐너들의 알파벳 수프(alphabet soup)는 보안을 불타는 건물을 매우 고해상도로 찍은 사진처럼 만들어 놓았습니다.

우리는 불이 어디에 있는지 정확히 알고 있습니다. 우리는 히트맵(heat map)을 가지고 있습니다. 우리는 심각도 점수(severity score)를 가지고 있습니다. 우리는 아무도 읽지 않는 CVSS 벡터(CVSS vector)를 가지고 있습니다.

단지 불을 끄지 못할 뿐입니다.

그것이 우리가 벗어나고 있는 기묘한 시대입니다.

발견 경제(Finding Economy)는 수익성이 있었습니다

지난 10년간의 앱 보안(AppSec)은 암묵적인 합의 위에 구축되었습니다: 도구는 찾고, 인간은 고친다. 발견하는 것이 어려웠던 시절에는 이는 합리적인 분업이었습니다. 추상 구문 트리(abstract syntax trees), 오염 분석(taint analysis), 심볼릭 실행(symbolic execution), 그리고 당신의 Python 문자열 연결이 왜 실제로 원격 코드 실행(remote code execution)이 되는지 설명할 박사 학위가 필요했습니다.

그래서 우리는 탐지(detection)를 중심으로 한 전체 경제를 구축했습니다. 취약점의 개수를 세는 대시보드. 팀이 충분히 빠르게 분류(triage)하지 못한다고 망신을 주는 리더보드. 버그를 고쳤는지 여부가 아니라 버그에 대해 _알고 있는지_를 묻는 컴플라이언스 프레임워크(Compliance frameworks). 성공의 지표는 평균 복구 시간(mean time to remediate)이 아니라 평균 탐지 시간(mean time to detect)이 되었습니다.

결과는 예측 가능합니다. 평균적인 기업은 50일에서 100일 정도의 미해결 심각한 취약점(open critical vulnerabilities)을 보유하고 있습니다. 이는 엔지니어들이 게을러서가 아니라, 깔때기(funnel) 자체가 근본적으로 고장 났기 때문입니다. 단 한 번의 스캔으로 만 개의 탐지 결과(findings)를 생성할 수 있습니다. 하지만 단 한 명의 엔지니어로 만 개의 수정 사항을 만들어낼 수는 없습니다.

발견은 컴퓨팅 자원(compute)에 따라 확장됩니다. 수정은 인간에 따라 확장됩니다. 그리고 인간은 확장되지 않습니다.

오픈 소스 프로젝트를 유지 관리해 본 사람이라면 누구나 이 고통을 뼈저리게 알고 있습니다. 개념 증명(Proof of Concept, PoC), CVSS 점수, 그리고 당신이 인터넷을 위험에 빠뜨리고 있다는 정중한 메모가 포함된 아름답고 상세한 이슈 리포트를 받게 됩니다. 하지만 당신이 받지 못하는 것은, 당신의 테스트를 통과하고, 당신의 아키텍처(architecture)를 존중하며, 오직 당신만이 알고 있는 세 가지 기묘한 엣지 케이스(edge cases)를 망가뜨리지 않는 패치(patch)입니다.

우리는 발견자(finder)를 찬양했습니다. 하지만 수정자(fixer)는 번아웃(burnout)되었습니다.

수정이 왜 다른 종류의 문제인가

수정을 '발견 + 한 단계 더'라고 생각하기 쉽습니다. 하지만 그렇지 않습니다. 그것은 완전히 다른 인지적 작업(cognitive task)입니다.

발견은 패턴 매칭(pattern matching) 문제입니다. 이 코드가 이전에 보았던 그 나쁜 코드와 닮았는가? 사용자 입력이 정화(sanitization) 없이 민감한 싱크(sink)로 흘러 들어가는가? LLM(대규모 언어 모델)은 이 작업에 놀라울 정도로 능숙합니다. 왜냐하면 양질의 코드와 나쁜 코드의 수백만 가지 사례를 이미 보았기 때문입니다.

수정은 계획(planning)과 컨텍스트(context)의 문제입니다. 버그를 올바르게 수정하려면 단순히 구문(syntax)뿐만 아니라 의도(intent)를 이해해야 합니다. 원래 작성자가 무엇을 하려고 했는지, 코드베이스의 나머지 부분이 어떤 불변성(invariants)에 의존하는지, 테스트 스위트(test suite)가 실제로 무엇을 커버하는지 아니면 무엇을 커버하는 척하는지, 그리고 두 개의 새로운 구멍을 만들지 않으면서 기존의 구멍을 메울 수 있는 가장 작은 변경을 어떻게 수행할지를 알아야 합니다.

잘못된 수정은 수정하지 않는 것보다 더 나쁩니다. 잘못된 수정은 당신에게 거짓된 확신을 주고, 다른 이름을 가진 새로운 CVE를 안겨줄 뿐입니다.

이것이 초기 자동 복구(auto remediation) 시도들이 보안 분야의 클리피(Clippy)처럼 느껴졌던 이유입니다. "SQL 인젝션(SQL injection)이 있는 것 같습니다. ORM을 추가해 드릴까요?" 아니요, 괜찮습니다.

변화한 것은 모델이 코드를 더 잘 쓰게 되었다는 점이 아닙니다(물론 그 점도 개선되었습니다). 변화한 것은 모델이 도구(tools)를 다루는 능력이 좋아졌다는 점입니다. 새로운 세대는 단순히 diff를 작성하는 챗봇이 아닙니다. 버그를 재현하고, 그로 인해 실패하는 테스트를 작성하며, 소스 코드를 편집하고, 관련 테스트를 실행하고, 실패를 관찰하고, 다시 시도하며, 초록색 체크 표시가 다시 나타날 때까지 반복할 수 있는 에이전트(agent)입니다.

다시 말해, 인간 엔지니어가 무언가를 수정할 때 실제로 수행하는 지루하고, 체계적이며, 화려하지 않은 반복 작업을 수행할 수 있다는 뜻입니다. 단지 새벽 2시에도 지치지 않을 뿐입니다.

우리는 패치 에이전트(Patch Agent) 시대에 진입하고 있습니다

가장자리(edges)에서 일어나고 있는 일들을 살펴보십시오.

오픈 소스(open source) 분야에서는 이제 종속성(dependencies)에서 새로운 CVE(Common Vulnerabilities and Exposures)를 감시하고, 실제로 취약점이 공격 가능한지 확인하며, 최소한의 업그레이드 또는 패치(patch)를 생성하고, CI(지속적 통합)를 실행한 뒤, 적절한 설명과 함께 PR(Pull Request)을 생성하는 에이전트(agent)가 존재합니다. 단순한 버전 업(version bump)이 아니라, 실제 수정(fix)입니다.

기업 보안(enterprise security) 분야에서는 퍼플 팀(purple teams)이 에이전트를 사용하여 자신들의 애플리케이션을 지속적으로 공격하고, 즉시 이를 차단할 수 있는 가드레일(guardrail)을 작성합니다. 이전에는 분기 단위로 걸리던 피드백 루프(feedback loop)가 이제는 몇 분 만에 완료됩니다.

그리고 연구실에서는 연구자들이 자가 치유 코드베이스(self healing codebases)를 구축하고 있습니다. 매일 밤 에이전트가 최신 취약점 피드(vulnerability feeds)를 가져오고, 저장소(repos)를 복제하며, 침입을 시도하고, 만약 성공하면 스스로 패치하고, 테스트하며, 대부분의 인턴보다 더 철저한 커밋 메시지(commit message)를 남기는 시스템입니다. 이것은 더 이상 공상 과학이 아닙니다. 단지 도입 단계보다 약간 앞서 있는 엔지니어링일 뿐입니다.

이는 은유(metaphor)의 심오한 변화입니다. 우리는 보안을 '카메라'로서의 보안에서 '면역 체계(immune system)'로서의 보안으로 이동시키고 있습니다. 카메라는 침입자를 기록할 뿐입니다. 면역 체계는 침입자를 무력화하고, 기억하며, 다음번에 더 나아집니다.

면역 체계 모델은 카메라 모델이 결코 이해하지 못했던 사실을 이해합니다. 바로 모든 것을 고칠 수는 없다는 점입니다. 공격 가능성(exploitability), 폭발 반경(blast radius), 그리고 이 서비스가 실제로 인터넷에 노출되어 있는지 아니면 당신이 분명히 존재한다고 주장하는 세 단계의 인증(auth) 뒤에 숨겨져 있는지에 따라 우선순위를 정해야 합니다. 에이전트 기반의 수정 도구(Agentic fixers)는 이러한 트리아지(triage, 우선순위 분류)에 능숙합니다. 왜냐하면 트리아지는 단순한 순위 매기기가 아니라 추론(reasoning)이기 때문입니다.

아무도 말하고 싶어 하지 않는 신뢰 문제

물론 함정이 있습니다. 그리고 그 함정은 바로 신뢰입니다.

당신은 AI가 메인(main) 브랜치에 코드를 푸시(push)하도록 허용하시겠습니까?

대부분의 팀은 올바르게 '아니오'라고 답할 것입니다. 초기 도입자들은 가드레일 (guardrails)을 갖출 것입니다. 인간 참여형 승인 (Human in the loop approval), 제한된 파일 경로 (Restricted file paths), 인간의 검토 없는 인증 로직 (auth logic) 변경 금지, 전체 테스트 실행과 더불어 임시 프리뷰 환경 (ephemeral preview environments) 및 의미론적 차이 검사 (semantic diff checks) 등이 그것입니다.

하지만 그 경계는 이동할 것입니다. 우리는 이미 테스트를 통과하면 Dependabot이 패치 업데이트를 자동으로 병합(merge)하도록 허용하고 있습니다. 우리는 이미 Copilot이 우리 코드의 40%를 작성하도록 허용하고 있습니다. 어느 시점이 되면 리스크 계산 (risk calculus)이 뒤집힙니다. 에이전트 (agent)가 잘 테스트된 유틸리티 함수 내의 잘 알려진 경로 탐색 (path traversal) 취약점을 패치하도록 허용하는 것과, 인간이 한가한 오후를 기다리는 동안 그 경로 탐색 취약점을 87일 동안 열어두는 것 중 무엇이 더 위험할까요?

우리는 컴파일러 (compiler)를 신뢰하는 법을 배웠던 것과 같은 방식으로 수정 도구 (fixers)를 신뢰하는 법을 배우게 될 것입니다. 처음에는 사람들이 어셈블리 (assembly) 출력물을 검사했습니다. 그러다 컴파일러가 자신들보다 실수를 덜 한다는 것을 깨닫고 검사를 멈췄습니다. 보안 패치에 있어서는 아직 그 단계에 도달하지 못했지만, 우리는 그 길을 걷고 있습니다.

승리하는 팀은 생성 (generation)보다 검증 (verification)을 더 잘 구축하는 팀이 될 것입니다. 이제 수정 (fix) 자체가 어려운 부분이 아닙니다. 수정 사항이 정확하고, 안전하며, 최소한의 변경인지 증명하는 것, 그것이 바로 제품 (product)입니다.

에이전트가 패치와 함께 생성하는 속성 기반 테스트 (property based tests)를 생각해 보십시오. 작은 핵심 함수들을 위한 형식 검증 (formal verification)을 생각해 보십시오. 오직 첫 번째 에이전트의 패치를 깨뜨리는 것만을 임무로 하는 두 번째 에이전트 모델을 생각해 보십시오. 이는 마치 면역 체계와 매우 유사한 적대적 시스템 (adversarial system)과 같습니다. 즉, 당신의 CI 내부에서 공격자와 방어자가 함께 진화하는 것입니다.

이것이 인간에게 의미하는 바

AI가 버그를 찾는 단계에서 수정하는 단계로 이동한다면, 인간은 무엇을 하게 될까요?

우리는 처음부터 마땅히 해야 했던 일을 하게 될 것입니다. 우리는 매우 값비싼 린터 (linters)처럼 행동하는 것을 멈추고, 아키텍트 (architects)처럼 행동하기 시작할 것입니다.

인간은 정책을 설정할 것입니다. 무엇이 자동 수정(auto fixed)될 수 있는지, 무엇이 검토(review)를 필요로 하는지, 그리고 서로 다른 시스템에 대해 우리가 어느 정도의 위험 허용 범위(risk tolerance)를 가질 것인지를 결정할 것입니다. 인간은 수정하기 더 쉽고, 폭발 반경(blast radius)이 작으며, 더 잘 테스트되고, 불변량(invariants)에 대해 더 명시적인 시스템을 설계할 것입니다. 인간은 에이전트(agents)가 여전히 서툰, 시스템 간의 기묘한 추론을 수행할 것입니다. 예를 들어, 서비스 A의 이 버그를 수정하는 것이 매 분기 말에 재무 부서가 의존하는 서비스 B의 문서화되지 않은 가정(undocumented assumption)을 깨뜨릴 것이라는 사실을 깨닫는 것과 같은 일 말입니다.

그리고 아마도 가장 중요한 것은, 인간이 사후 대응적인 티켓 종결(reactive ticket closure) 대신 선제적인 보안(proactive security)을 수행할 수 있도록 자유로워질 것이라는 점입니다. 위협 모델링(Threat modeling). 설계 단계부터의 보안(Secure by design). 끝없이 패치(patching)를 하는 대신 실제로 코드를 삭제하는 것 말입니다.

우리의 꿈은 발견된 문제(findings)가 0개인 대시보드를 갖는 것이 아니었습니다. 우리의 꿈은 안전을 유지하기 위해 대시보드가 필요하지 않은 시스템을 갖는 것이었습니다.

우리는 지난 20년 동안 화재에 대해 더 크게 소리 높여 외치는 데 시간을 보냈습니다. 다음 10년은 불타지 않는 건물을 만드는 것에 관한 시간이 될 것입니다.

저는 바로 이러한 미래를 위해 방어, 회복 탄력성(resilience), 그리고 스스로를 수정하는 시스템에 초점을 맞춘 작고 실용적인 도구들을 만들고 있습니다.

이 포스트의 아이디어들을 직접 시도해보고 싶다면:

The $20 SOC: Build a Tiny Defensive Network Monitor는 홈 랩(home labs)과 소규모 팀을 위한 저렴한 탐지(detection)에 대한 저의 생각입니다.

Build the Blackbox: An Offline AI Field Terminal That Works When Nothing Else Does는 완전히 오프라인 상태에서도 작동하는 AI 시스템을 구축하기 위한 저의 가이드이며, 이는 적대적인 환경(hostile environments)에서 패치를 수행할 때 매우 중요합니다.

Synthetic Corporation Defense: Purple-Team Your HR Before 500 Fake Employees Do는 공격자 또한 AI로 생성되는 경우, 즉 동전의 다른 면을 다룹니다.

그리고 Self-Healing Legion: AI That Finds and Patches Its Own CVEs While You Sleep는 제가 여기서 설명한 내용의 완전한 구현체로, 자율적으로 자신의 취약점 (vulnerabilities)을 사냥하고 수정하는 에이전트 군단 (agentic legion)입니다.