코드멘더는 회의론자 없이는 작동하지 않는다.

발행: (2026년 5월 24일 AM 07:52 GMT+9)
12 분 소요
원문: Dev.to

Source: Dev.to

Google I/O 2026의 헤드라인은 예상대로 진행되었습니다 — Gemini 3.5, 가을에 출시될 새로운 지능형 안경, 새로운 CLI와 서브에이전트를 갖춘 Antigravity 2.0. Google DeepMind의 자율 코드 보안 에이전트인 CodeMender는 거의 각주 수준으로 Agent Platform에 통합되었습니다. 대부분의 보도는 곧 넘어갔습니다.
그것은 실수입니다. CodeMender는 이번 행사에서 가장 구조적으로 중요한 발표이며, 버그를 찾는 것이 이유가 아닙니다. 수십 년 동안 도구들은 버그를 찾아왔습니다. 중요한 점은 그것이 버그를 찾는 방식그 아키텍처가 AI 보안이 실제로 어디로 향하고 있는지를 조용히 드러낸다는 점입니다.

Google이 직접 설명한 CodeMender 작동 방식은 다음과 같습니다:

CodeMender는 우리의 Gemini 모델이 가진 고급 추론 능력을 활용해 중요한 코드 취약점을 자동으로 수정하는 AI 기반 에이전트입니다. […] 이러한 패치는 이후 특화된 “비평” 에이전트에게 전달되며, 비평 에이전트는 자동화된 동료 검토자 역할을 수행해 패치가 정확성, 보안 영향 및 코드 표준 준수를 충족하는지 엄격히 검증한 뒤 최종 인간 승인에 제안합니다.

두 번 읽어보세요. 추론 모델이 패치를 제안합니다. 별도의 “비평” 에이전트—Google이 직접 부른 용어—가 그 뒤에서 인간에게 전달되기 전에 철저히 검증합니다. CodeMender는 모델이 아니라 루프이며, 비평 에이전트가 실제 하중을 담당합니다.

2024년 이후 모든 AI 보안 벤더는 대략 같은 이야기를 팔아왔습니다: 대형 언어 모델이 인간보다 빠르고 넓은 범위, 저렴한 비용으로 취약점을 찾아낸다. 데모는 마법처럼 보입니다 — 모델이 함수를 읽고 CWE‑89에 대해 중얼거리며 패치를 만들어냅니다.

데모가 보여주지 못하는 것은 규모에서 일어나는 일입니다. 이 도구들이 포착하는 진짜 신호는 실제로 유용합니다 — 이것이 카테고리를 살아 있게 하는 장점이죠. 하지만 보안 분석가의 주의는 기업 내 가장 희소한 자원입니다. 두세 번의 발견이 잡음으로 판명되면, 분석가는 다음 발견도 잡음이라고 표시합니다 — 실제 여부와 무관하게. 신뢰는 절벽에서 떨어져 회복되지 않습니다. 이는 추측이 아니라, 어떤 스캐너든 채택 곡선을 제한하는 핵심 제약입니다.

정적 분석기는 20년 넘게 잘 알려진 false‑positive 문제와 함께 제공되었습니다; LLM‑on‑top 파동은 이를 물려받아 종종 증폭시켰습니다. Snyk의 DeepCode AI는 “심볼릭 및 생성 AI, 여러 머신러닝 방법, 그리고 Snyk 보안 연구원의 전문성을 결합”한다고 명시하며—명시적으로 하이브리드 스택이며 단일 모델이 아닙니다. GitHub의 Copilot Autofix는 “CodeQL 엔진, GPT‑4o, 그리고 여러 휴리스틱을 활용”한다고 밝히며—다시 말해, 결정론적 파이프라인에 삽입된 LLM이며 모델 하나만이 아닙니다. 단일 LLM만을 스캐폴딩 없이 배포한 제품이 고전했고, 스캐폴딩이 문제라는 것을 깨달은 제품이 살아남았습니다.

모델 자체가 병목이 된 적은 없습니다. 신뢰 보정이 병목이었습니다.

아키텍처 설명은 구조적 양보입니다. 자동 패치는 false‑positive 문제를 악화시킵니다 — 잘못된 패치는 분석가 시간을 낭비할 뿐 아니라 코드베이스를 바꾸고, 빌드를 깨뜨리며, 때로는 새로운 버그를 유발합니다. “버그 찾기”가 충분히 정밀하게 배포되기 어렵다면, “버그 찾고 고치기”는 그보다 훨씬 더 어려워집니다.

더 나은 생성기를 훈련시킨다고 해결되지 않습니다. 모델을 더 보수적으로 훈련하면 재현율이 붕괴하고, 더 공격적으로 훈련하면 정밀도가 붕괴합니다. 단일 모델의 재현율‑정밀도 경계는 프롬프트와 훈련 분포에 의해 근본적으로 제한됩니다.

가능한 접근법은 작업을 분할하는 것입니다.

  • 하나의 모델은 제안하고, 다른 모델은 폐기합니다.
  • 제안자는 재현율 편향: 넓은 그물을 던져 취약점처럼 보이는 모든 것을 표면에 올리고, 놓치지 않는 것을 최적화합니다.
  • 비평 에이전트는 정밀도 편향: 각 발견을 받아들여 “이 취약점은 실제로 이용 가능한가?”, “제안자가 놓친 상위 가드가 있는가?”, “이미 알려진 false‑positive 패턴인가?”, “제안된 패치가 기존 테스트를 깨뜨리는가?” 등을 판단합니다.

비평 에이전트가 바로 아키텍처이며, 없으면 제안자의 출력은 배포 불가능합니다. 비평 에이전트가 있기에 시스템은 CodeMender가 주장하는 바—“사람 검토를 위한 검증된 패치를 제공하고, 추측의 물줄기가 아니라”—를 실현할 수 있습니다.

분리—버그를 찾는 모델이 버그가 실제인지 판단하는 모델이 아니다—가 바로 전체 게임의 핵심입니다.

제안자‑회의론자 분해는 새로운 개념이 아닙니다. 수학적 추론은 제안자‑검증자 루프를 사용합니다. 다중 에이전트 토론도 같은 아이디어를 프레임합니다. RLHF에서 적대적 비평자를 두는 것이 훈련 시 버전이며, 고전 머신러닝의 앙상블 방법은 오래전부터 다양한 약학습자가 비대칭 오류 비용이 있는 작업에서 강력한 단일 모델을 능가한다는 것을 입증했습니다.

보안에 특화된 점은 비대칭성이 선택 사항이 아니라 구조적 제약이라는 것입니다. 오류 비용이 비대칭이면, 하나의 모델이 정밀도와 재현율을 한 축에서 절충하도록 원하지 않습니다. 서로 다른 축에서 절충하는 두 모델이 필요합니다.

분해에서 얻을 수 있는 네 가지 구체적 이점:

  1. 역할별 모델 차별화

    • 탐지 모델은 파일당 한 번 실행되므로 가장 크고 비싼 추론 모델을 사용할 수 있습니다.
    • 비평 모델은 작고 빠르며 저렴하게 여러 번 실행됩니다. 비용‑지연이 조정 가능한 노브가 됩니다.
  2. 훈련 후 독립성

    • 시스템이 새로운 false‑positive 패턴을 계속해서 표면에 올린다면, 거대한 탐지 모델을 재훈련할 필요가 없습니다. 비평 모델에 적대적 예시를 추가하고 배포하면 됩니다.
  3. 핫스와핑 가능한 기반 모델

    • 기반 모델이 개선되면 루프를 재구성하지 않고 교체할 수 있습니다.
  4. 감사 가능한 의견 차이

    • 제안자가 “취약점”이라고 하고 비평자가 “아니다”라고 하면, 구조화된 논쟁 기록—즉, 대화 전사—이 남습니다. 인간이 이를 검토할 수 있어 설명 가능성(story) 측면에서 단일 모델이 제공하지 못하는 장점을 가집니다.

두 해 동안 데모를 이끌어온 단일 패스 설정:

findings = discovery_model.scan(code)
return findings  # FP가 포화, 두 번의 발견만으로 분석가 신뢰 상실

분해된 루프:

candidates = discovery_model.scan(
    code,
    prompt=DISCOVERY_PROMPT,  # 재현율 편향: "뭔가 이상한 건 다 찾아라"
)

validated = []
for finding in candidates:
    if finding.confidence > PRECISION_THRESHOLD:
        validated.append(finding.with_verdict(verdict))

patches = [patch_model.propose(f) for f in validated]
return [p for p in patches if regression_tests_pass(p)]

Google의 가장 강력한 추론 모델로 구동되는 CodeMender도 여전히 비평 단계가 필요합니다. 구조적 분해는 기반 모델 파라미터를 한 단계 늘리는 것보다 배포 가능성을 크게 향상시킵니다.

이 패턴은 심각한 보안 도구가 배포되는 모든 곳에서 나타납니다. Purdue의 LLMSCAN은 명시적으로 관심사를 분리합니다: 구문적 사실은 Tree‑sitter 파싱(검증 가능, 결정론적)에서 나오고, LLM은 파싱이 도달하지 못하는 의미적 사실만을 처리합니다. 여기서 핵심은 “제안자‑회의론자”가 아니라 “LLM이 환각할 수 없는 구조에 제안자를 기반을 두는” 것입니다. 동일한 재현율‑정밀도 경계가 한 단계 앞

0 조회
Back to Blog

관련 글

더 보기 »

내 스킬

프로젝트를 위한 AI 지시문을 만들고, 설치하고, 관리하세요 — 코딩이 필요 없습니다. CREATE 이름을 정하고, 카테고리를 선택하고, 원하는 것을 설명하세요 — 마법사가 자동으로 구성합니다.