1. 무엇이 달라졌나

앤트로픽 기술 스태프인 발표자가 지난 몇 달을 보안 팀들과 함께 취약점을 찾고 고치는 데 썼다고 말한다. 자막이 이름 뒷부분을 뭉갠다.

먼저 모델 쪽 추세를 든다. 모델이 얼마나 긴 작업을 해내는지 사람과 견줘 재는 벤치마크에 사이버보안 판이 있고, 영국 AI 보안 연구소가 그것을 갖고 있다. 대상 시스템의 약점을 찾아 파고드는 과제라 역공학이나 웹 공격 같은 능력을 본다. 이 그림에서 모델이 점점 더 긴 보안 과제를 해내고 있으며, 앞선 회귀선에 견주면 한 계단 뛴 자국이 보인다고 말한다.

다음이 파이어폭스다. 모질라가 달마다 만든 보안 버그 수정 건수를 공개했는데 2025년 평균이 20건대였다. 2월과 3월에 60~70건으로 세 배가 되고 4월에 400건으로 일곱 배가 됐다. 4월 수치는 작년 평균의 20배다. 모질라는 이 증가분의 3분의 2쯤을 특정 모델 덕으로 돌렸다. 자막이 모델 이름을 뭉개 어느 판인지 원문에서 갈린다.

발표자는 청중에게 로그4쉘을 기억하느냐고 묻는다. 자바 로깅 라이브러리의 버그라 공격자가 문자열 하나를 로그에 남기면 시스템에서 코드가 돌았다. 벨기에 국방부가 며칠 만에 뚫렸고 한 핀테크에서 200만 명 데이터가 샜다. 그 전에는 오픈SSL의 하트블리드가 있었다.

자기네가 한 일도 낸다. 오픈소스 저장소 1,000곳 넘게 훑어 후보 2만 3천 개를 얻었고, 그중 6,200개가 높음 또는 치명으로 매겨졌다. 갱신 시점에 1,600개를 유지관리자에게 알렸고 100개쯤이 업스트림에서 고쳐졌다. 이제 취약점을 찾는 일 자체는 꽤 쉬워졌다는 것이 여기서 나온 관찰이다.

무엇이 그 문턱을 낮췄느냐는 물음에는 두 낱말로 답한다. *에이전틱 하네스다. 모질라를 다시 인용하는데, 초기 실험은 가능성만 보이고 오탐이 많아 넓히기 어려웠는데 보안 이슈를 안정적으로 잡아내는 하네스가 들어오면서 그것이 바뀌었다는 것이다.

2. 여섯 걸음은 무엇인가

여러 팀과 일해 보니 대체로 여섯 걸음으로 모이더라고 말한다. 앞 둘이 셋업이고 뒤 넷이 도는 고리다.

셋업 둘은 코드베이스마다 미리 들이는 품이다. 하나는 *위협모델이고 하나는 샌드박스다.

고리 넷은 이렇다. 발견이 취약점을 집어내고, 검증이 그것이 진짜인지 확인하고, 분류가 개발자가 붙을 열댓 개로 좁히고, 패치가 고친다.

설명은 주문 서비스 하나로 관통한다. 아이디를 넣으면 주문을 찾아 주는 가상의 시스템이다.

3. 앞 둘이 뒤 넷을 좌우한다

위협모델은 코드베이스나 시스템을 놓고 그리는 설계도인데, 무엇이 위협 벡터인지, 그러니까 어떤 취약점을 신경 써야 하는지를 정해 준다.

발표가 낸 진양성률 값

셋 다 발표자가 말로 댄 값이고 어떤 표본에서 어떻게 쟀는지는 밝히지 않는다.

한 CISO의 말을 옮긴다. 모델은 코드에 대한 맥락은 훌륭한데 시스템에 대한 맥락은 빈약하다는 것이다.

위협모델을 처음 만드는 방법도 준다. 문서와 코드는 물론 지난 커밋과 지난 패치, 그 패치가 무슨 CVE를 막은 것인지까지 모델에 열어 주고, 아직 안 막힌 CVE가 무엇일지 짚어 보게 한다. 그다음에 모델더러 그 시스템을 아는 사람을 인터뷰하게 한다. 계획에 없던 일로 무엇이 일어날 수 있는지, 반대로 무엇은 안 걱정해도 되는지를 묻는 것이다. 주문 서비스의 위협모델에서는 지켜야 할 것이 고객 개인정보가 든 데이터고 들어오는 문이 주문 API이며, 모델은 SQL 인젝션과 인증 없이 API를 부르는 길을 위협 벡터로 짚었다.

샌드박스는 둘을 준다. 격리와 재현이다. 격리는 데이터가 새거나 운영 환경이 더럽혀지는 것을 막는 자리라 바깥으로 나가는 통신도 클라우드 자격증명도 없는 가상머신에서 돌린다. 재현은 모든 에이전트가 같은 기준 컨테이너에서 출발하게 하는 것이다. 함께 일한 한 팀은 가장 큰 지렛대가 실제 시스템을 올린 샌드박스였다고 말했다. 거기서 개념증명을 실제로 터뜨려 진짜인지 확인할 수 있기 때문이다. 주문 서비스 샌드박스는 도커 이미지 셋을 이어 붙인 것이다. 앱, 포스트그레스, 캐시 하나씩이고, 보안 에이전트는 대상 경계 밖에 앉아 HTTP로 앱을 찔러 본다.

4. 고리 넷이 도는 법

발견에서 중요한 것 셋을 꼽는다. 맥락을 어떻게 넣느냐, 프롬프트를 얼마나 단순하게 쓰느냐, 도구를 주느냐다. 적어서 모델에 건네면 모델이 그것을 찾아낸다는 것이 첫째다. 둘째는 반대 방향이다. 새 모델이 나올 때마다 프롬프트를 절반쯤 줄여야 했다고 말한다. 요즘 모델에는 신뢰되지 않은 데이터가 신뢰 경계에 닿는 자리를 찾으라고만 해도 알아서 짚는다. 셋째가 앞 표의 마지막 줄이다.

주문 서비스의 조회 API는 다섯 줄인데, 발견 에이전트가 넷째 줄을 짚었다. 파이썬 문자열을 이어 붙여 SQL 질의를 만드는 자리라 사용자가 넣은 값이 곧장 질의로 흘러든다.

발견과 검증은 최적화하는 것이 다르다고 말한다. 발견은 재현율을 올리고 검증은 정밀도를 올린다. 그래서 검증 에이전트는 독립적이고 적대적이어야 한다. 독립은 발견 에이전트가 남긴 추론 자국을 안 본다는 뜻이고, 적대는 이 취약점이 가짜라고 가정하고 가짜임을 확인하려 든다는 뜻이다. 발견 에이전트가 제 일을 스스로 검증하면 자기 검열이 들어가 재현율을 깎는다.

주문 서비스에서 검증 에이전트는 넷째 줄이라는 위치만 받고 새 컨테이너에서 curl 한 줄을 날려 고객 개인정보가 빠져나오는 것을 눈으로 확인한다.

분류는 참인 것 중에서 고를 것을 고르는 자리다. 실제로 발동하지만 사업에 미치는 영향이 낮은 정확성 문제도 섞여 있다. 여러 팀이 같은 말을 했다고 한다. 참인 취약점을 중간·낮음까지 다 제품 엔지니어에게 보내면 그 엔지니어들이 감당을 못 해 신뢰를 잃는다는 것이다. 그래서 중복을 걷어내고, 터졌을 때의 크기와 실제로 일어날 만한지를 함께 본다. 공격자가 몇 단계를 거쳐야 하는지가 뒤쪽 기준이다. 방화벽 같은 보완 통제가 있으면 처음에 높음이던 것이 낮아지고, 반대로 데이터베이스에 고객 개인정보나 의료 데이터가 몰려 있으면 모델이 중간으로 매긴 것이 실제로는 높음이 된다. 주문 서비스에서는 에이전트가 높음으로 봤는데, 사람이 보고 낮음으로 내렸다. 애플리케이션 방화벽이 SQL 인젝션을 막고 있고 이 서비스가 안쪽 전용이라 인터넷에 안 붙어 있다는 이유다.

패치가 고리를 닫는다. 고친 뒤 확인하는 사다리가 있고, 패치 에이전트에 그 결과를 돌려주면 패치 품질이 크게 올라간다고 팀들이 밝혔다고 한다. 발표자는 이것을 생성적 검증자 고리라고 부른다. 병합 전에는 사람이 본다.

주문 서비스의 패치는 두 덩이다. 첫 덩이는 변수를 파이썬 문자열 밖으로 빼는 한 줄짜리 수정이다. 둘째 덩이가 고리를 닫는 자리인데, 코드만 고치는 것이 아니라 보완 통제를 적어 둔다. 방화벽이 막고 있고 안쪽 전용이라는 사실을 남겨 다음 스캔에서 같은 것이 다시 올라오지 않게 한다.

고리를 안 닫으면 이 일이 매달 나가는 운영비인데, 닫으면 한 번 쌓아 두고 쓰는 자산이 되어 돌릴 때마다 나아진다고 말한다.

5. 진짜 병목은 사람 쪽이다

앞 전임 상사의 말을 옮긴다. 기술적이지 않은 문제가 기술적인 문제보다 한 자릿수 어렵다는 것이다.

들어오는 양이 열 배 백 배가 되면 하네스 쪽은 엔지니어링을 더 하고 컴퓨트를 더 쓰고 돈을 더 내면 된다. 돈으로 풀리는 것은 진짜 문제가 아니라고 말한다. 사람 주의력은 그렇게 안 늘어난다.

구체적인 자리를 셋 든다. 하나는 심각도 합의다. 제품 엔지니어와 보안 엔지니어가 무엇이 높음이고 치명인지에서 갈릴 수 있고, 이것은 사업 맥락이 많이 드는 일이다. 한 방에 몰아넣고 규칙을 적어 모두가 같은 것을 보게 만들어야 한다. 위협모델도 지금은 다 사람들 머릿속에 있으니 모델이든 사람이든 누군가 인터뷰해서 적어 내려야 한다.

둘은 어디로 보내느냐다. 한 달에 열댓 건이면 손으로 골라 메일을 돌리고 지라 티켓을 붙일 수 있는데 수백 건이면 못 한다. 이 일은 코드 주인이나 서비스 주인에게 보내는 정도로 단순해질 수 있고 굳이 언어 모델이 낄 자리가 아니라고 말한다.

셋은 고치는 손이다. 취약점을 받아 놓고 패치를 짜는 일은 모델의 도움을 받아도 여전히 어렵다. AI가 만든 패치 쪽으로 가되 사람이 고리 안에서 확인하라고 말한다. 완전 자동 패치 검토까지 간 회사는 아직 많이 알지 못한다고 덧붙인다.

기억할 것 셋으로 발표를 닫는다. 오픈소스 의존성부터 시작할 것, 자동화를 바로 노리지 말고 손을 얹은 채 배울 것, 스캐닝을 목표로 삼지 말 것이다. 병목은 검증과 분류와 패치, 그리고 조직의 절차라는 것이다. 마지막에 자기네 도구와 블로그, 대화형 스킬과 자율 하네스가 든 오픈소스 저장소를 소개하며 다섯째 걸음의 하네스를 가져다 고쳐 쓰라고 말한다.

6. 발표가 밝히지 않은 것

값의 출처가 얇다. 진양성률 90%도, 도구를 준 팀의 거의 100%도 표본이 얼마이고 무엇을 정답으로 놓고 잰 것인지 대지 않는다. 오탐이 준 만큼 놓친 것이 늘지는 않았는지, 그러니까 재현율 쪽이 어떻게 됐는지는 아예 나오지 않는다.

자기네 스캔 결과도 앞쪽만 있다. 후보 2만 3천에서 고·치명 6,200으로 좁힌 기준이 무엇인지, 알린 1,600건 중 100건만 고쳐진 나머지 1,500건이 어떤 상태인지가 없다. 유지관리자 쪽에서 무엇이 걸렸는지가 이 이야기의 절반인데 발표는 그 자리를 다루지 않는다.

파이어폭스 숫자도 남의 발표에서 온 것이다. 4월 400건이 무엇을 센 것인지, 심각도 분포가 어떻게 되는지, 3분의 2를 모델 덕으로 돌린 근거가 무엇인지는 이 발표에 없다.

비용도 없다. 저장소마다 위협모델을 만들고 샌드박스를 세우는 데 드는 품, 발견과 검증을 따로 돌리는 데 드는 컴퓨트가 얼마인지 나오지 않는다. 돈으로 풀리는 것은 문제가 아니라는 말이 그 자리를 대신한다.

발표자가 스스로 밝힌 한계는 하나다. 보안 이슈를 고칠 때 패치 검토까지 완전히 자동으로 돌린 회사를 많이 알지 못한다는 것이다.