블록의 보안 자동화 사례와 패치 제안 18분이 가리키는 검증 조건

오픈AI는 10월 14일 Square와 Cash App, Afterpay를 운영하는 블록의 인공지능 기반 보안 자동화 업무 사례를 공개했다. 블록은 최근 수행한 레드팀 연습 과정에서 상위 수준의 취약점 정보를 제출한 뒤 시스템이 자동 패치 제안을 완성하기까지 18분이 걸렸다고 보고했다. 이 18분이라는 시간은 취약점을 탐지하고 수정 코드를 초안 형태로 만들어내는 단계까지를 가리키며, 실제 상용 운영 환경에 코드를 배포하고 사후 검증까지 완료한 전체 처리 시간은 아니다.

블록의 최고정보보호책임자 제임스 네테스하임은 자동화 구조 속에서도 사람이 결과를 직접 확인하고 조직의 맥락을 제공하는 역할을 수행한다고 설명했다. 전체 처리 절차는 시스템이 발견한 문제의 구체적인 위치와 소관 담당자를 찾아내고 수정안을 제시한 뒤 실제 해소 여부를 확인하며, 최종적으로 사람이 코드 변경 사항을 검토해 배포를 결정하는 흐름으로 이어진다. 따라서 공개된 시간 수치는 이 여러 단계 중에서 정확히 어느 구간을 측정한 것인지와 결합해 해석해야 한다.

보안 업무의 자동화는 단순히 도구가 사람의 개입 없이 독립적으로 문제를 해결하는 형태가 아니라, 정해진 구간에서 사람의 검토를 지원하는 방식으로 구성된다. 레드팀 시험에서 제시된 수치는 자동화된 분석 도구가 취약점 분석과 패치 작성에 소요되는 사전 작업 시간을 크게 단축할 수 있음을 보여주지만, 운영 시스템에 미치는 영향을 평가하고 최종 배포를 승인하는 책임은 여전히 사람 분석가와 엔지니어의 몫으로 남아 있다.

원시 쿼리 증거 보존과 과거 7개월 텔레메트리 재평가

탐지 규칙 조정 사례에서는 각 조사 과정마다 원시 쿼리 증거를 온전히 보존하는 설계를 채택했다고 밝혔다. 이러한 기록 방식을 통해 새로 제안된 탐지 변경안을 과거 7개월간 누적된 실제 운영 텔레메트리에 1시간 미만의 시간으로 재적용해 평가할 수 있었다고 설명했다. 이는 새로운 보안 위협이나 탐지 로직이 등장했을 때 분석가가 과거의 수많은 사건 기록을 일일이 수동으로 재조회해야 하던 작업 부담을 덜어내기 위한 구체적인 활용 방식이다.

사건 발생 당시의 원시 데이터와 조사 증거를 체계적으로 보존하는 아키텍처는 제안된 규칙의 타당성을 과거 데이터에 비추어 사후 검증할 수 있는 기술적 전제가 된다. 다만 7개월 치 자료에 대한 재평가가 1시간 미만에 끝난다고 해서 새로 만든 탐지 규칙을 곧바로 실제 운영 환경에 배포해도 안전하다는 뜻은 아니다. 빠른 처리 속도와 별개로 해당 규칙이 과거 기록에서 어떤 추가 경보를 생성하거나 기존 경보를 누락시키는지 그 분포를 철저히 확인해야 한다.

운영 환경의 다양한 로그 패턴을 충분히 반영하지 못한 탐지 규칙은 현장에 오탐을 유발하거나 실제 위협을 놓치는 원인이 될 수 있다. 결국 과거 텔레메트리에 대한 신속한 재적용이 지니는 본질적 가치는 검증 절차 자체를 건너뛰는 데 있는 것이 아니라, 이전에는 막대한 작업 비용과 시간 소모 때문에 엄두를 내지 못했던 대규모 비교 검증을 일상적으로 수행할 수 있게 만든 점에 있다.

작업별 모델 분배와 성과 지표의 다각적 해석

블록은 모든 보안 업무에 최신 대형 모델 하나만을 획일적으로 적용하지 않고, 작업의 세부 특성과 요구 수준에 맞추어 모델을 분배하는 방식을 취했다고 설명했다. Daybreak 기반 위에 구축된 블록의 자체 실행 체계는 적절한 모델로 작업을 분기해 라우팅하며, 사람이 직접 업무를 인계받아야 하는 지점과 여러 에이전트 간에 상호 교차 검토를 수행하는 절차를 긴밀하게 결합해 운영된다. 블록은 내부 평가 기준과 실제 업무 성과를 지속적으로 확인하며 이 모델 배치 구성을 점진적으로 조정하고 있다.

실제 적용 사례에서는 단일 엔드포인트 경보에서 파악된 단서를 다른 신원 로그와 교차 연결함으로써 더 큰 잠재적 보안 문제를 탐지해 낸 과정도 함께 소개되었다. 개별 제품이나 보안 도구에서 발생하는 단편적인 경보를 독립적으로 확인하는 일과, 서로 다른 출처의 다중 로그를 결합해 복합적인 공격 가설을 수립하는 작업은 질적으로 완전히 다른 접근이다. 다만 분산된 단서들을 하나로 엮는 과정에서 도출된 결론이 실제 위협과 일치하는지는 여전히 구체적인 증거 검토를 거쳐야 한다.

공개된 정량적 성과에 따르면 블록은 오탐 분류 영역에서 분기당 약 600시간에 달하는 분석가 시간을 돌려받았다고 설명했다. 이와 별개로 시스템이 분기당 약 1100 분석가 시간에 상당하는 규모의 조사 작업을 자동으로 수행했다고 보고했다. 전자의 약 600시간은 기존 인력의 실제 작업 시간을 아낀 절감량이며, 후자의 약 1100시간은 자동화 시스템이 처리한 전체 조사 업무량을 시간 단위로 환산한 수치다. 이 두 지표는 기준이 다르므로 단순히 합산해 인건비 절감액으로 계산할 수 없다.

18분과 1시간 미만은 같은 작업의 속도가 아니다

18분은 주어진 취약점 정보에서 패치 제안을 얻은 사례이고, 1시간 미만은 변경한 탐지를 과거 7개월 텔레메트리에 다시 적용한 사례다. 두 숫자는 시작점과 산출물이 달라 어느 기능이 더 빠른지 순위를 매길 수 없다.

분기당 약 600시간의 분류 부담 절감과 약 1,100시간에 상당하는 조사 수행량도 합계로 묶기 어렵다. 줄어든 기존 업무와 새로 수행한 깊은 조사는 다른 기준이다. 어떤 일을 덜었고 어떤 범위까지 새로 조사했는지를 남겨야 자동화의 효과를 실제 운영과 연결할 수 있다.

블록은 경보 분류 처리량과 정보 수집 및 조사 수행량이 각각 50% 증가했다고 보고했으나, 공개된 자료에서는 전체 조사 대상 표본의 크기나 이전 기간과의 구체적인 비교 조건이 상세히 공개되지 않았다. 따라서 이 수치는 블록이라는 특정 기업의 인프라와 운영 조건 아래서 측정된 개별 성과로 보아야 하며, 다른 조직에 도입했을 때 동일한 50%의 생산성 향상이 나타난다고 보장하는 일반화된 지표로 해석할 수 없다.

오픈AI의 별도 Defense Factory 설계 문서는 기존 보안 및 개발 도구들을 에이전트 작업 단위로 연계하고, 격리된 안전한 재현 환경에서 문제를 면밀히 조사해 테스트를 마친 수정안만을 사람의 검토 단계로 넘기는 구조를 제시한다. 자동화 단계가 고도화될수록 시스템이 어떤 코드 베이스와 원시 증거를 근거로 삼아 판단을 내렸는지를 투명하게 남기는 것이 핵심이며, 승인 후 배포 결과를 다시 검증하는 분리 체계가 요구된다.

ARCH.B 의견

레드팀 연습에서 보고된 패치 제안 18분은 취약점 분석부터 코드 제안까지의 속도를 측정한 결과일 뿐 운영 환경 배포와 안전성 검증까지 끝난 시간을 뜻하지 않는다. 인공지능 모델은 개별 조직이 오랜 기간 축적해 온 사업적 맥락과 과거의 예외적 기술 결정을 온전히 파악하지 못하므로, 제안된 코드와 탐지 규칙을 최종 승인하는 권한은 여전히 사람의 책임 영역으로 엄격하게 남겨두어야 한다.

원시 쿼리 증거를 보존해 과거 7개월 치 텔레메트리를 1시간 미만에 재평가하는 방식은 검증 비용을 낮추는 실질적인 접근이다. 다만 다른 조직이 이 방식을 도입하려면 문제를 안전하게 재현할 격리 인프라와 텔레메트리 보존 체계가 선행되어야 하며, Daybreak 공식 안내가 명시하듯 접근 승인 권한이 무제한으로 확장되지 않도록 작업별 권한 경계를 단계적으로 관리하는 설계가 필수적이다.