취약점 89% 자동 해결이라는 수치 뒤에 숨은 진실: AWS 보안 에이전트 콘티넘 팩트체크

소프트웨어 개발 조직에서 보안 취약점을 고치는 일은 늘 밀려드는 빚더미와 같다. 새로운 기능을 배포하기 바쁜 엔지니어링 조직에 보안 결함을 메우는 일은 생산성을 갉아먹는 부담으로 다가오기 일쑤였다. 아마존웹서비스(AWS)가 코드 저장소의 취약점을 알아서 찾아내고, 검증을 거친 뒤, 스스로 수정 코드(Pull Request)까지 올리는 인공지능 에이전트 ‘콘티넘(Continuum)‘을 정식 출시했다.

맷 가먼 AWS 최고경영자는 개인 소셜 미디어를 통해 방어자 입장에서 진정한 게임체인저가 등장했다고 밝히며, 콘티넘이 보안 에이전트 벤치마크에서 종전 최고 기록을 갈아치웠다고 선언했다. 하지만 보안 실무진이 숫자의 겉면만 보고 전사 시스템의 열쇠를 인공지능에 넘기기에는 숨은 조건이 적지 않다.

오픈소스 920개 과제와 89% 성공률: AWS 콘티넘의 등장 배경과 거시적 파장

보안 업계에서는 그동안 공격자가 인공지능을 활용해 취약점을 찾는 속도가 수비자가 방어벽을 치는 속도를 압도한다는 우려가 지배적이었다. 최근 일어난 PHP2Shell 사태만 보더라도 취약점을 발견하는 일은 인공지능 덕분에 극적으로 쉬워졌지만, 기존 비즈니스 로직을 깨뜨리지 않고 정교하게 수습하는 일은 여전히 인간 시니어 엔지니어의 손길을 거쳐야 했다. 콘티넘은 바로 이 병목을 풀겠다는 목적으로 무대에 올랐다.

AWS가 공개한 핵심 지표는 사이버짐 종단간 벤치마크(CyberGym-E2E) 결과다. 이 테스트는 139개 오픈소스 프로젝트에서 추출한 920개 작업으로 구성된다. 에이전트에게 버그에 대한 사전 설명, 공격 증명 코드(PoC), 충돌 로그, 기존 패치 데이터를 일절 주지 않는다. 백지상태의 에이전트는 90분 안에 코드베이스 안에서 취약점을 찾아내고, 이를 직접 실행시켜 프로그램이 멈추는 현상을 재현한 뒤, 기존 단위 테스트를 단 하나도 깨뜨리지 않는 수정 패치를 제출해야 한다.

콘티넘은 이 920개 과제 중 819개를 통과해 89.0%의 종단간 성공률을 기록했다. 이전까지 공개된 인공지능 모델들의 최고 기록이 65.9%에 머물렀던 점을 감안하면 수치상으로는 상당한 진전이다. 90분의 제한 시간을 더 늘릴 경우 성공률은 93.7%까지 치솟는다는 것이 AWS의 설명이다.

그러나 클라우드 인프라 업계 일각에서는 발표 시점을 두고 의문을 제기하기도 했다. 매년 11월 말 열리는 연례 기술 컨퍼런스인 re:Invent를 앞두고 굳이 10월 말에 서둘러 출시를 공식화한 배경에 경쟁사들의 보안 에이전트 공세를 의식한 조급함이 섞여 있다는 시각이다. 무엇보다 이 숫자가 실제 프로덕션 환경의 안전을 100% 보장하는지에 대해서는 벤치마크 평가 구조를 단계별로 뜯어볼 필요가 있다.

4단계 평가로 검증한 실제 패치 성공률: 전체 통과와 지정 결함 해결의 괴리

AWS가 밝힌 89%라는 숫자는 네 단계의 누적 평가를 거쳐 산출되었다. 각 단계별 성공률을 분해해 보면 콘티넘이 잘하는 영역과 현재의 명확한 한계선이 뚜렷하게 갈린다.

콘티넘은 전체 과제의 92.5%에서 취약점을 성공적으로 찾아내고 충돌을 유발하는 데 성공했다. 이어 89.6%의 과제에서 프로그램 다운 현상을 막아내는 패치를 만들었고, 89.0%에서는 프로젝트에 원래 포함되어 있던 기존 테스트들을 통과시켰다. 즉, ‘어디선가 결함을 찾아내 충돌을 멈추고 기존 빌드를 깨지 않는 코드’를 작성하는 능력은 89%에 달한다.

문제는 네 번째 평가 단계인 ‘원래 벤치마크가 의도했던 과거의 특정 취약점(Historical Vulnerability)‘을 정확히 맞혀서 해결했는가에 있다. 이 단계에서 콘티넘의 성공률은 37.8%로 급락한다.

평가 단계	측정 항목 및 합격 조건	콘티넘 달성률	업계 기존 최고치	실무적 의미
1단계: 버그 발견 및 재현	충돌 유발 PoC 없이 스스로 결함 찾아내기	92.5%	미공개	코드 분석 및 크래시 유발 능력 우수
2단계: 충돌 방지 패치	프로그램 셧다운을 멈추는 방어 코드 작성	89.6%	72.4%	단순 크래시 회피 로직 구현 완성도 높음
3단계: 기존 테스트 통과	기존 단위 테스트 스위트를 깨뜨리지 않기	89.0%	65.9%	사이드 이펙트 없는 일반 패치 작성 성공률
4단계: 타깃 결함 일치율	벤치마크가 출제한 특정 과거 CVE와 일치	37.8%	26.2%	보안팀이 지목한 특정 취약점 해결력의 한계

이 격차를 무조건 콘티넘의 실패로 몰아세울 수는 없다. 복잡한 오픈소스 저장소 안에는 수많은 잠재적 취약점이 널려 있다. 콘티넘은 사전에 특정 CVE 번호나 버그 설명을 받지 못한 채 투입되었기 때문에, 벤치마크 출제자가 의도한 결함 A 대신 저장소 구석에 숨어 있던 다른 진짜 결함 B를 찾아내 완벽히 고쳤을 가능성이 높기 때문이다. 고친 버그가 다른 버그라고 해서 그 패치의 가치가 사라지는 것은 아니다.

하지만 이 구조는 보안 실무진에게 중대한 질문을 던진다. 실무에서 보안팀이 AI 에이전트에 기대하는 역할은 저장소를 무작위로 뒤져 아무 결함이나 찾아내는 것뿐만 아니라, 외부 감사나 고객사로부터 지적받은 ‘특정 CVE 취약점을 콕 집어서 정확히 해결하는 일’이다. 지정된 과녁을 명중시키는 성능이 37.8% 수준에 머문다면, 엔지니어는 에이전트가 올린 풀 리퀘스트가 지금 당장 해결해야 할 그 문제인지 일일이 대조 검증해야 한다.

개발 운영 환경과 공급망에 미치는 3대 직접적 파급력

콘티넘의 등장은 소프트웨어 배포 주기와 보안 운영 전반에 상당한 변화를 예고한다. 엔지니어링 리더십은 이 도구를 도입하기에 앞서 운영 비용, 작업 대기 시간, 그리고 시스템 신뢰성이라는 세 가지 측면에서 손익을 명확히 계산해야 한다.

운영 비용: 보안 엔지니어 인건비 절감과 PR 검토 피로도의 교환

전통적인 방식에서 보안 패치 한 건을 처리하는 비용은 적지 않다. 사내 시니어 엔지니어가 취약점을 재현하고, 영향도를 파악하며, 안전한 코드를 작성해 스테이징 서버에서 검증하는 데 평균 12–20시간의 공수가 투입된다. 시간당 100달러 선의 개발 인건비를 감안하면 취약점당 1,200–2,000달러의 비용이 빠져나간다.

콘티넘이 89% 확률로 유효한 풀 리퀘스트를 올려준다면 초도 패치 작성 시간은 90분 이내로 줄어든다. 하지만 여기서 새로운 숨은 비용이 발생한다. 에이전트가 올린 코드가 원래 고치려던 취약점을 수정한 것인지, 아니면 엉뚱한 결함을 건드려 비즈니스 규칙을 비틀어 놓지는 않았는지 검증하는 ‘코드 리뷰 피로도’다. 타깃 일치율이 37.8%에 불과한 상황에서 무분별하게 쏟아지는 풀 리퀘스트는 개발팀의 검토 업무를 마비시키는 역효과를 낼 수 있다.

작업 처리 시간: 발견에서 패치 배포까지 리드타임 90분 압축

가장 확실한 이득은 취약점 조치 시간의 단축이다. 기존 오픈소스 기반 프로젝트에서 새로운 제로데이 취약점이 보고되었을 때, 팀이 상황을 인지하고 패치를 배포하기까지 걸리는 평균 시간(MTTR)은 수일에서 수주일에 달했다.

콘티넘은 사람이 잠든 심야 시간대에도 90분 단위로 저장소를 탐색하고 가상 환경에서 결함을 직접 트리거해 본다. 실제로 작동하는 PoC를 확보한 상태에서 패치를 만들기 때문에, 적어도 패치가 충돌을 막아낸다는 점만큼은 검증된 상태로 전달된다. 이는 외부 위협 행위자가 취약점을 악용하기 전에 방어벽을 세우는 데 큰 시간적 완충재가 된다.

시스템 신뢰성: C/C++ 언어 편중과 클라우드 웹 스택 간의 괴리

가장 주의 깊게 보아야 할 대목은 지원 언어의 편중이다. 사이버짐 벤치마크에 포함된 920개 작업은 100% C 및 C++ 언어로 작성된 메모리 안전성(Memory-safety) 결함에 집중되어 있다. 버퍼 오버플로우나 유즈 애프터 프리(Use-after-free) 같은 결함은 메모리 주소를 정교하게 조작해야 하므로 사람이 고치기 대단히 까다롭고, 인공지능이 컴파일러 출력과 메모리 크래시 덤프를 보며 기계적으로 역추적하기에 가장 적합한 영역이다.

하지만 대다수 기업의 현대 웹 애플리케이션과 클라우드 백엔드는 Java, Python, Go, TypeScript 등으로 구축되어 있다. 이들 환경에서 빈번하게 터지는 문제는 메모리 누수가 아니라 SQL 인젝션, 잘못된 권한 인가(BOLA), 비즈니스 로직 취약점이다. 콘티넘이 C/C++ 벤치마크에서 89%를 찍었다고 해서, 복잡한 엔터프라이즈 결제 모듈이나 웹 서비스의 보안 결함을 같은 수준으로 고쳐낼 것이라 기대하는 것은 무리다.

대체 기술 완충벽과 상용 모니터링 체계 대조

자동 패치 에이전트를 프로덕션 파이프라인에 들이기 전, 엔지니어링 조직은 기존의 정적 애플리케이션 보안 테스트(SAST), 런타임 보안 분석 도구와 어떻게 역할을 분담할지 정의해야 한다.

완전 자율형 보안 에이전트는 아직 초기 단계다. 현재 실무 현장에서는 코드를 직접 고치는 에이전트보다 런타임 위협을 실시간 감시하는 시스템이 훨씬 높은 안정성을 제공한다. 예를 들어 Datadog 같은 모니터링 환경을 통해 운영 중인 애플리케이션의 메모리 이상 징후와 비정상적인 호출 패턴을 먼저 감지하고, 이를 인공지능 에이전트의 입력값으로 전달하는 2단계 방어 체계가 현실적이다.

또한 개발자가 실시간으로 코드를 작성하는 단계에서는 Cursor 같은 도구를 활용해 보안 코딩 규칙을 사전에 준수하도록 강제하는 편이, 나중에 에이전트가 뒤늦게 들어와 코드를 뜯어고치게 만드는 것보다 전체 수명주기 비용을 낮추는 길이다.

구분	AWS 콘티넘	정적 코드 분석 도구 (SAST)	런타임 보안 모니터링
핵심 동작 방식	자율 탐색 후 수정 코드(PR) 작성	코드 규칙 대조 후 취약점 경고 리포트	실행 중인 프로세스 위협 감지 및 차단
검증 방식	가상 환경에서 결함 재현 및 테스트 검증	정적 룰셋 기반 패턴 매칭	실제 트래픽 및 메모리 호출 분석
운영 개입 수준	완전 자동 탐색 (인간 리뷰 필요)	개발자가 직접 코드 수정	보안팀이 룰셋 설정 및 인시던트 대응
주요 한계	타깃 CVE 일치율 37.8%, C/C++ 위주	높은 오탐률(False Positive), 패치 미제공	사후 대응 중심, 코드 결함 자체 미수정
실무 적합 영역	레거시 C/C++ 인프라 취약점 보강	CI/CD 파이프라인 초기 게이트키핑	상용 클라우드 프로덕션 실시간 방어

외부 독립 기관이 동일한 벤치마크를 재현 검증하지 않았다는 점도 고려해야 한다. 이번 데이터는 AWS 내부 테스트 환경에서 측정되었으며, 인터넷 접근 차단과 기공개 패치 유출 방지 장치를 적용했다고 밝혔으나 상용 환경의 수많은 예외 케이스를 모두 담아내지는 못했다. 따라서 콘티넘을 단독 해결사로 두기보다는 기존 분석 도구의 경고를 받아 실제 패치 초안을 떠주는 보조 작업자로 배치하는 것이 안전하다.

도입 적합 대상 vs 보류 대상 판정

AWS 콘티넘의 기술적 성과는 분명하다. 사람이 일일이 로그를 뒤지지 않아도 89%의 성공률로 충돌을 방지하는 패치를 스스로 짜낸다는 점은 소프트웨어 보안 자동화의 중대한 이정표다. 그러나 이 도구가 모든 개발팀의 구원투수가 될 수는 없다.

지금 즉시 도입을 검토해야 할 기업

• C/C++ 기반 핵심 인프라나 임베디드 모듈을 유지보수하는 조직: 수십만 줄에 달하는 레거시 C/C++ 코드베이스를 안고 있으면서 전담 보안 엔지니어가 부족한 기업이라면 즉각적인 효용을 얻을 수 있다. 콘티넘은 메모리 안전성 버그를 찾고 기존 빌드를 깨지 않는 패치를 만드는 데 최적화되어 있다.
• 이미 정교한 단위 테스트 자동화 체계를 갖춘 엔지니어링 팀: 콘티넘이 제시한 패치가 안전한지 판단하는 기준은 3단계인 ‘기존 테스트 통과’다. 사내 코드 커버리지가 80% 이상으로 촘촘히 짜여 있다면, 에이전트가 올린 PR이 비즈니스 로직을 망가뜨렸는지 파이프라인에서 자동으로 걸러낼 수 있으므로 안심하고 파일럿을 돌릴 수 있다.
• AWS 환경과 코드 저장소가 완벽히 통합되어 있는 클라우드 조직: 콘티넘은 결함을 찾은 뒤 사용자의 AWS 환경과 대조하여 실제 영향도를 검증한다. 인프라 전체가 AWS 위에 구축되어 있어 격리된 환경에서 안전하게 결함을 재현(Sandbox Replay)할 수 있는 인프라 여건을 갖춘 팀에 유리하다.

도입을 보류하고 지켜봐야 할 기업

• Java, Python, TypeScript 중심의 웹 애플리케이션 서비스 기업: 현재 벤치마크는 C/C++ 메모리 안전성에 한정되어 있다. 모던 웹 서비스에서 발생하는 취약점의 대다수는 비즈니스 권한 체계와 API 보안 문제다. 언어 확장이 공식 발표되고 타깃 언어에 대한 벤치마크가 검증될 때까지는 성급한 도입을 미뤄야 한다.
• 특정 CVE 지정 패치가 급선무인 규제 준수 대상 기업: 금융, 의료 등 컴플라이언스 이슈로 인해 특정 감사 결함 목록을 기한 내에 정확히 털어내야 하는 조직이라면 실망할 수 있다. 콘티넘의 특정 취약점 일치율은 37.8%에 불과하므로, 에이전트에 맡겨두었다가 정작 고쳐야 할 감사 대상 버그가 방치될 위험이 있다.
• 사내 테스트 코드가 부실한 스타트업: 테스트 코드가 빈약한 상태에서 콘티넘을 도입하면 재앙이 될 수 있다. 에이전트는 ‘기존 테스트가 깨지지 않는 것’을 성공 기준으로 삼기 때문에, 검증할 테스트 자체가 없다면 충돌만 안 날 뿐 엉뚱하게 동작하는 위험한 패치를 그대로 승인해 상용 서버에 배포할 우려가 크다.