트리아지가 곧 제품이다: 이더리움 프로토콜 코드에 AI 에이전트 실행하기

이더리움 재단의 프로토콜 보안 팀이 실제 프로토콜 코드에 대해 조정된 AI 에이전트를 실행한 경험을 정리한 노트입니다. 여기에는 작업 구성 방식, 정밀 조사에도 견뎌내는 요소, 클라이언트 팀과 보안 연구원들이 얻을 수 있는 시사점이 포함되어 있습니다. 이 글은 독립적인 내용을 다루며, 개별 클라이언트에 대한 더 깊은 내용은 향후 게시물에서 다룰 예정입니다.

우리가 실행해 온 것과 우리를 놀라게 한 것

이더리움 재단의 프로토콜 보안 팀에서는 시스템 소프트웨어, 암호화 코드, 그리고 반드시 정확해야 하는 컨트랙트 등 네트워크가 의존하는 시스템 유형에 대해 조정된 AI 에이전트를 실행해 왔습니다. 이 에이전트들은 실제 버그를 찾아냈습니다. 그중 하나는 현재 공개되어 있습니다. 이더리움 합의 클라이언트가 실행되는 피어 투 피어 레이어의 핵심 부분인 libp2p의 gossipsub에서 원격으로 트리거할 수 있는 패닉 현상으로, 팀의 공로를 인정받아 CVE-2026-34219로 수정 및 공개되었습니다.

에이전트가 버그를 찾았다는 사실 자체가 놀라운 것은 아니었습니다. 놀라운 점은 버그를 찾는 데 들어간 노력은 아주 적었던 반면, 진짜 버그와 진짜처럼 보이는 버그를 구별하는 데 엄청난 노력이 들어갔다는 것입니다.

이 글은 동일한 작업을 수행하고자 하는 클라이언트 팀과 보안 연구원들을 위한 것입니다. 에이전트를 구성하는 방법, 후보가 실제 발견으로 인정받기 위해 넘어야 하는 기준, 그리고 결과의 신뢰성을 유지하는 습관에 대해 다룹니다.

다른 곳의 팀들도 동일한 방법으로 수렴하고 있습니다. Anthropic의 프론티어 레드 팀(Frontier Red Team)은 속성 기반 테스트를 작성하고 Python 생태계 전반에서 실제 버그를 찾아내는 에이전트를 구축했습니다. Cloudflare는 자체 시스템을 대상으로 보안 연구 하네스를 통해 프론티어 모델을 실행했습니다. 모두가 동일한 루프에 도달합니다. 뛰어난 모델을 코드베이스에 지정하고, 검색하게 한 다음, 반환된 결과를 트리아지(선별)하는 것입니다. 따라서 진짜 문제는 확신에 찬 듯한 노이즈에 파묻히지 않고 이 작업을 수행하는 방법입니다.

미리 말씀드릴 주의 사항이 하나 있습니다. 에이전트 기반 감사를 위한 도구는 빠르게 발전하며, 특정 설정은 몇 주만 지나도 구식이 됩니다. 따라서 이 글은 도구보다는 지속적으로 적용할 수 있는 방법론에 의도적으로 초점을 맞추고 있습니다. 취약점 공개(Disclosure)는 그 자체로 별도의 주제이며, 아마도 별도의 게시물로 다뤄질 것입니다.

에이전트는 오라클이 아니라 검색 도구입니다

코드베이스에 지정된 에이전트는 퍼저(fuzzer)와 매우 유사한 검색 도구입니다. 차이점은 반환되는 결과에 있습니다. 퍼저는 크래시와 스택 트레이스를 제공합니다. 반면 에이전트는 보고서(호출 체인, 영향도 주장, 제안된 심각도)와 실제 코드에 대해 실행할 수 있는 개념 증명(proof-of-concept)과 같이 이를 뒷받침하는 아티팩트를 포함하여 훨씬 더 많은 것을 제공합니다.

이 모든 요소 덕분에 결과를 쉽게 읽고 신뢰할 수 있으며, 무엇보다도 실행 가능한 개념 증명이 큰 역할을 합니다. 따라서 에이전트가 얼마나 많은 후보를 생성하는지 세지 마십시오. 그중 얼마나 많은 것이 진짜로 밝혀지는지 세십시오.

작업 구성 방식

우리는 하나의 대상을 향해 여러 에이전트를 병렬로 실행합니다. 이들은 작업을 분배하는 중앙 프로세스 없이, 버전 관리 시스템에서 공유된 상태를 통해 리포지토리 자체를 매개로 조정됩니다. 한 에이전트가 다른 에이전트들이 볼 수 있는 곳에 주장을 작성하고, 작업을 수행한 뒤 커밋합니다.

우리는 동일한 방식으로 조정되는 에이전트 플릿으로 C 컴파일러 구축하기에 대한 Anthropic의 글에서 이 접근 방식을 얻었습니다. 구축하거나 유지 관리할 중앙 조정자가 없으므로 문제가 발생할 여지도 적습니다.

역할은 발견된 작업에 따라 생성됩니다.

• 정찰(Recon)은 공격 표면을 구체적이고 테스트 가능한 가설로 바꿉니다. "디코더 감사"가 아니라 "이 필드는 이 지점을 지나면 신뢰됩니다. 유지해야 할 속성, 손상될 수 있는 방식, 그리고 이를 해결할 증명은 다음과 같습니다"와 같은 식입니다.
• 헌팅(Hunting)은 하나의 가설을 취해 코드 경로를 추적하고 재현 도구(reproducer)를 구축하려고 시도합니다.
• 갭 채우기(Gap-filling)는 승인된 것과 거부된 것을 살펴보고, 다음 가설 배치를 작성하며, 에이전트가 동일한 영역을 계속 반복하지 않도록 커버리지를 추적합니다.
• 검증(Validation)은 각 후보를 독립적으로 재확인하고, 중복을 제거하며, 결정을 내립니다.

우리가 이 파이프라인을 발명한 것은 아닙니다. Cloudflare도 정찰, 병렬 헌팅, 독립적 검증, 중복 제거, 보고라는 동일한 단계를 설명하고 있으며, 그들의 글이 우리의 파이프라인을 형성하는 데 도움이 되었습니다.

후보가 실제 발견으로 인정받기 전의 모습은 다음과 같습니다.

대상:        공격자가 실제로 도달할 수 있는 컴포넌트 및 진입점
불변성:      반드시 유지되어야 하는 속성
메커니즘:    손상될 수 있는 구체적인 방식
성공:        관찰 가능한 증명: 패닉, 지연, 허용된 잘못된 입력
재현 도구:   실제 코드에 대해 실행되는 독립적인 아티팩트
중복 제거:   두 에이전트가 동일한 것을 쫓지 않도록 하는 키

스키마가 존재하는 데는 이유가 있습니다. 이는 구체적이고 테스트 가능한 주장과 명확한 완료 정의를 강제합니다. 관찰 가능한 증명을 작성해야 하는 에이전트는 "이것은 위험해 보입니다"라는 말로 얼버무릴 수 없습니다.

재현할 수 없다면 일어난 일이 아닙니다

다른 어떤 것보다 중요한 규칙이 하나 있습니다. 실제 코드에 대해 실패를 재현하고, 이를 작성하지 않은 사람도 실행할 수 있는 독립적인 아티팩트가 존재하기 전까지는 후보를 실제 발견으로 간주하지 않습니다.

재현 도구는 보고서를 읽지 않으며, 모델이 얼마나 확신에 차 있었는지 신경 쓰지 않습니다. 실행되거나 실행되지 않거나 둘 중 하나일 뿐입니다.

재현 도구의 가치 대부분은 오탐(false positive)을 잡아내는 데 있습니다. 그중 세 가지가 반복해서 나타나며, 각각은 에이전트가 잘못된 이유로 통과 판정을 받는 경우입니다.

• 디버그 빌드에서만 발생하는 패닉. 소프트웨어가 실제로 배포되는 방식으로 컴파일하고 실행하면 값이 단순히 래핑(wrap around)될 뿐입니다. 아무것도 크래시되지 않습니다. 크래시처럼 보이지만 실제로는 아닙니다.
• 공격자가 제어하는 모든 경로에서 사전에 거부되기 때문에 실제 입력으로는 절대 생성할 수 없는 내부 값을 수동으로 구축하는 재현 도구. 이 버그는 도달 가능한 어떤 것도 그런 식으로 호출하지 않는 함수에 대해서만 "재현"됩니다.
• 정형 검증(formal-verification) 작업에서, 통과되지만 원하는 의미를 갖지 않는 증명. 해당 구문은 코드가 수행하는 작업과 관계없이 자명하게 참이거나, 캡처하려던 속성보다 약합니다. 검증자는 만족하지만, 정리는 실제로 신경 썼던 동작을 제약하지 못합니다.

이 중 어느 것도 새로운 것은 아닙니다. 실제로 아무것도 확인하지 않기 때문에 통과하는 테스트와 동일합니다. 새로운 점은 그 규모입니다. 에이전트는 쓸모없는 버전을 진짜 버전만큼이나 빠르고 확신에 차서 작성합니다. 따라서 확인 과정은 자동화되어야 합니다. 에이전트가 스스로 오류를 잡아낼 것이라고 기대할 수는 없습니다.

신호 대 잡음비 관리가 작업의 대부분입니다

대부분의 후보는 잘못되었거나, 중복되거나, 범위를 벗어납니다. 이는 방법론의 문제가 아니라 원래 그렇게 작동하는 것입니다. 목표는 잘못된 것을 빠르게 거부하고, 진짜 발견을 반박하기 어려운 증명으로 뒷받침하는 것입니다.

살아남은 모든 후보는 두 가지 독립적인 확인을 거칩니다. 실제 공격자가 정상적인 구성에서 실제로 도달할 수 있는가? 그리고 공격이 성공했을 때 네트워크가 치러야 할 비용과 비교하여 공격자가 이를 수행하는 데 드는 비용은 얼마인가? 단일 피어가 트리거할 수 있는 버그는 특별한 액세스나 막대한 리소스가 필요한 버그와는 매우 다릅니다.

모든 항목은 이미 알려졌거나, 수정되었거나, 거부된 항목의 실행 목록과 대조하여 확인됩니다. 이 과정이 없다면 에이전트는 이미 닫힌 동일한 이슈를 계속해서 재발견하고 반복해서 보고할 것입니다.

승인률은 대상에 따라 크게 다르며, 이러한 편차 자체도 유용합니다. 성숙하고 철저한 감사를 거친 코드에 대해 이를 실행하면 살아남는 것이 거의 없지만, 이 역시 알아둘 가치가 있습니다. "열심히 찾아보았지만 아무것도 발견하지 못했다"는 것도 실제 결과입니다. 덜 탐색된 코드나, 기계가 확인한 증명이 모델을 포괄하고 배포된 바이트코드가 이와 일치한다고 가정만 하는 정형 검증된 코드에 대해 실행하면 더 많은 것이 통과됩니다.

트리아지가 어려운 부분이라는 것을 발견한 것은 우리뿐만이 아닙니다. Cloudflare의 주요 결론은 좁은 범위가 광범위한 스캐닝보다 낫다는 것이었습니다. Anthropic의 속성 기반 테스트 에이전트는 약 1,000개의 후보 보고서를 생성한 다음, 순위 매기기와 전문가 검토를 사용하여 약 86%의 확률로 유지되는 최상위 계층으로 추려냈습니다. 생성은 쉬운 부분이었습니다. 여기서 우리 자체의 수치를 공개하지는 않겠습니다. 특정 대상과 연결된 수치는 방법론보다는 대상에 대해 더 많은 것을 말해줄 것이기 때문입니다.

에이전트가 잘하는 것과 오해를 일으키는 부분

양쪽 모두에 과장이 존재하므로, 에이전트가 잘하는 것과 오해를 일으키는 부분에 대한 명확한 목록을 아래에 정리했습니다.

이러한 구분조차 작업마다 일정하지 않습니다. 실제 취약점에 대해 다양한 모델을 테스트한 스타니슬라프 포트(Stanislav Fort)는 이를 들쭉날쭉한 프론티어(jagged frontier)라고 부릅니다. 즉, 한 코드베이스에서 전체 익스플로잇 체인을 복구하는 모델이 다른 코드베이스에서는 기본적인 데이터 흐름 추적에 실패할 수 있습니다. 하나의 좋은 결과가 다음 결과도 유효할 것이라고 가정할 수 없으며, 이것이 모든 후보를 개별적으로 확인해야 하는 또 다른 이유입니다.

마지막 행이 중요합니다. 단일 에이전트 세션은 단발성 추론에는 능하지만, 각 단계는 유효하고 순서만 잘못된 일련의 단계에 걸쳐 있는 버그에는 취약합니다. 이러한 경우 에이전트는 검색 도구가 아닙니다. 에이전트의 역할은 상태 저장 테스트 하네스(stateful test harness)를 통해 실행할 가치가 있는 시퀀스를 제안하는 것입니다. 그런 방식으로 사용하면 잘 작동합니다. 하네스를 대체하는 용도로 사용하면, 시퀀스 전반에 걸쳐서만 나타나는 가장 치명적인 버그들을 놓치게 됩니다.

정직성 유지하기

몇 가지 습관이 에이전트의 발견을 신뢰할 수 있게 만드는 작업의 대부분을 수행하며, 그중 어느 것도 복잡하지 않습니다.

• 모든 아티팩트의 출처(Provenance): 무엇이, 어떤 컨텍스트에서, 어떤 리비전에 대해 생성했는지 기록합니다. 발견된 내용은 몇 달 후에도 다시 실행할 수 있어야 합니다.
• 중요한 곳에서의 결정론(Determinism): 단일 환경, 단일 빌드 및 실행 방식을 사용하여 "재현된다"는 것이 발견된 머신뿐만 아니라 모든 머신에서 동일한 의미를 갖도록 합니다.
• 스크립트가 아닌 규범(Norms): 번호가 매겨진 절차 대신, 불변성과 실제 발견을 위한 기준 등 무엇이 중요한지 에이전트에게 알려줍니다. 과도하게 스크립트화된 에이전트는 과도하게 지정된 테스트가 실패하는 것과 같은 방식으로 실패합니다. 즉, 단계가 더 이상 의미가 없어진 후에도 계속해서 단계를 따릅니다. 리포지토리 컨텍스트 파일에 대한 연구에서도 동일한 사실을 발견했습니다. 추가 요구 사항은 작업 성공률을 낮추고 비용을 20% 이상 높였으며, 저자들은 컨텍스트를 최소한의 요구 사항으로 유지할 것을 권장합니다.
• 최종 결정은 사람이 내립니다: 에이전트는 제안만 할 뿐입니다. 무엇이 진짜인지, 무엇이 알려진 이슈의 중복인지, 또는 무엇을 언제 공개할지는 에이전트가 결정하지 않습니다.

병목 현상의 이동

AI는 보안 연구원을 대체하지 않았습니다. 단지 작업을 이동시켰을 뿐입니다. 가설을 세우고 추적하는 데 쓰이던 시간은 이제 오라클 구축, 트리아지 실행, 알려진 이슈 목록 유지, 취약점 공개 처리 등 대규모로 가설을 판단하는 데 쓰입니다.

병목 현상은 사라지지 않았습니다. 버그를 찾는 것에서 결과를 신뢰하는 것으로 이동했을 뿐입니다. 인간의 판단이 실제로 중요한 부분이기 때문에 이는 더 나은 위치입니다. 하지만 여전히 병목 현상이며, 이를 무시하면 결국 잘못된 "문제없음" 판정을 내린 채 배포하게 됩니다.

이 작업을 가능하게 하는 관행은 새로운 것이 아닙니다. 재현 가능한 실패, 실제 오라클, 그리고 신중한 트리아지는 지난 15년 동안 퍼징(fuzzing)을 연구 주제에서 표준 관행으로 바꾼 것과 동일한 관행입니다. 도구는 새롭지만, 관행은 그렇지 않습니다.

도구가 얼마나 빠르게 계속 변화할지는 미지수입니다. 신중한 성격이자 한때 회의론자였던 니콜라스 칼리니(Nicholas Carlini)는 넓은 오차 범위를 유지하면서도 기하급수적인 발전 가능성을 진지하게 받아들일 가치가 있다고 주장합니다. 생성 측면이 그렇게 빠르게 상승한다면 판단 측면도 함께 상승해야 합니다. 그렇지 않으면 생성되는 것과 실제로 검증되는 것 사이의 격차는 벌어질 뿐입니다.

이더리움이 의존하는 시스템의 경우, 바로 이 부분이 중요합니다. 에이전트를 사용하면 수작업으로 할 수 있는 것보다 훨씬 더 넓은 영역을 다룰 수 있습니다. 그 대가로 에이전트는 확신에 찬 듯한 훨씬 더 많은 주장들 속에서 더 신중한 판단을 요구합니다. 판단이 곧 진짜 제품이라는 사실을 기억하는 한, 이는 충분히 가치 있는 교환입니다.