Google, AI로 6월에 지난 2년치보다 많은 Chrome 버그 수정

 (blog.google)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Chrome은 Gemini 기반 에이전트로 취약점 발견부터 분류·수정·배포·업데이트 적용까지 자동화하며, Chrome 149와 150에서 이전 23개 마일스톤을 합친 것보다 많은 보안 버그 1,072개를 수정함
  • 취약점 탐지 시스템은 여러 모델과 Chrome의 CVE·Git 이력 지식 기반, SECURITY.md, 별도 비평 에이전트를 결합하고 인터넷과 로컬 시스템 접근을 엄격히 제한한 환경에서 작동함
  • 자동 분류는 스팸·중복 제거, 재현과 스택 추적 수집, 심각도 등 메타데이터 추가, 담당자 배정을 수행해 매달 수백 시간의 개발자 작업을 줄이는 것으로 추산됨
  • 수정 공개 후 악용까지의 패치 격차를 줄이기 위해 주 2회 보안 릴리스를 시험하고, 재시작 없이 자식 프로세스를 교체하는 동적 패치와 macOS 자동 재시작을 개발함
  • 개별 버그 수정에 그치지 않고 MiraclePtr·std::span·Rust로 메모리 안전성을 높이며, 제출 시점 AI 검사와 2,300개 이상의 외부 의존성 자동 업데이트로 취약점 유입을 예방함

AI가 바꾼 보안 버그의 생애주기

  • LLM은 사람의 보안 전문성만으로 처리할 수 있는 규모를 넘어 자동 취약점 탐지를 확장했으며, Chrome은 수백 개의 보안 버그를 더 빠르게 찾고 수정하는 데 AI를 활용함
  • 일반 기능 버그가 UI 멈춤 같은 문제를 일으키는 데 비해 보안 버그는 공격자가 개인 데이터를 읽거나 사용자 몰래 컴퓨터를 제어하는 익스플로잇에 이용될 수 있음
  • 보안 버그는 발견, 분류, 수정, 수정본이 포함된 Chrome 배포, 브라우저 재시작과 적용 순서로 처리되며 모든 단계를 최대한 단축하는 것이 목표임

취약점 탐지의 확장

  • Chrome 보안팀은 여러 해에 걸쳐 LLM 기반 탐지 기술을 발전시킴
  • 2026년 초 구축한 Gemini 에이전트 하네스는 더 넓은 Chrome 코드베이스에서 탐지 효율을 높이고 오탐을 줄임
    • 발견된 샌드박스 탈출 버그는 침해된 렌더러가 브라우저를 속여 로컬 파일을 읽게 할 수 있었으며, 코드에 13년 넘게 남아 있었음
  • 탐지 하네스에는 다음 기능이 추가됨
    • 오픈 웨이트 모델과 독점 모델 각각의 강점을 이용하는 모델 상호운용성
    • 기존 CVE 전체와 Chrome의 전체 Git 이력을 포함한 지식 기반
    • 신뢰 경계와 위협 모델을 명확히 전달하는 SECURITY.md 작성 지침
    • 별도 컨텍스트에서 SECURITY.md를 읽는 비평 에이전트
    • 모델의 비결정성과 시간에 따른 개선을 반영하기 위한 코드베이스 반복 검사
  • AI는 일반 인터넷에 접근할 수 없는 잠금 장비에서 저장된 소스 코드만 분석함
    • 모든 네트워크 요청을 가로채 애플리케이션과 목적지 기반 허용 목록을 적용함
    • 모델을 무제한 모드로 실행하지 않으며, 하위 에이전트의 시스템 변경과 지정된 소스 디렉터리 외부 파일 접근을 제한함
  • AI 탐지는 기존 보안 테스트를 대체하지 않음
    • 퍼징은 서로 떨어진 코드 영역의 장거리 상호작용이나 무관해 보이는 여러 연산의 조합에서 발생하는 버그에 특히 효과적임
  • 외부 연구자는 Chrome Vulnerability Reward Program을 통해 어렵고 영향력 큰 취약점을 계속 찾도록 보상받음
    • 2026년 초 모든 유형의 신고가 증가했고, 3월에는 2025년 전체보다 많은 버그 신고가 접수됨
    • 이에 따라 VRP를 변경해 내부 탐지 결과에 추가 가치를 제공하고 자동 처리 파이프라인이 쉽게 수용할 수 있는 신고에 집중함

자동 분류와 다중 에이전트 수정

  • 과거에는 보안 신고 하나를 분류하는 데 5분에서 30분 이상이 걸리고 주로 사람의 전문성에 의존했지만, 현재는 규칙 기반 시스템과 AI를 결합해 처리량과 정확도를 높임
  • 자동 분류는 네 단계로 진행됨
    1. 스팸과 중복을 제거하고 접수 기준 충족 여부와 Chrome 보안 취약점에 대한 명확한 설명이 있는지 검사함
    2. 개념 증명과 재현 가능성을 확인하고 해당 운영체제·브라우저 버전에서 시험한 뒤 스택 추적 같은 정보를 첨부함
    3. 버그가 처음 유입된 시점과 심각도를 추가함
      • 자동 적용이 쉽도록 심각도 지침을 명확하게 정비함
      • 개발자는 잘못된 심각도 등급을 변경하고 SECURITY.md로 보안 경계 정보를 보충할 수 있음
    4. 문제를 올바른 구성요소와 담당자에게 자동 배정함
  • 정확한 측정은 어렵지만 자동 분류로 매달 수백 시간의 개발자 작업을 줄이는 것으로 추산함
  • 취약점 수정에는 다중 에이전트 작업 흐름을 적용함
    • 수정 에이전트가 문제별 컨텍스트를 받아 여러 후보 패치를 생성함
    • 비평 에이전트가 가장 적합한 후보를 평가하고 개발자의 검토에 필요한 산출물을 만듦
    • 두 에이전트가 코드 리뷰와 유사한 반복 작업을 수행해 기능 동작, Chromium·Google 스타일, 로컬 코드 관례 준수를 검사함
    • 테스트 작성 에이전트가 개발자 검토 전에 Chrome 지원 플랫폼과 구성 전반에서 테스트를 확인해 최대 수주의 시간을 절약함
  • 현재 대부분의 취약점에 LLM이 후보 수정을 생성함
    • Chrome 149와 150에서는 보안 버그 1,072개를 수정해 앞선 23개 마일스톤의 합계를 넘어섬
  • DeepMind·Project Zero와 협력한 Big Sleep과 CodeMender는 CI에 통합돼 모든 CL을 24시간마다 검사함
    • 5월 한 달 동안 치명적인 S1+ 문제를 포함해 20개 넘는 취약점이 프로덕션에 도달하기 전에 차단됨

패치 격차 단축과 업데이트 적용

  • 수정 코드가 공개 오픈소스 저장소에 들어간 뒤 사용자에게 배포되기 전까지 공격자가 이를 역공학해 악용할 수 있는 N-day 공격 구간을 패치 격차라고 함
  • 메인 트리에 반영된 수정이 대다수 사용자가 이용하는 Stable 채널에 도달하기까지 보통 수주가 걸림
    • 심각도에 따라 수정 사항을 현재 Stable 릴리스 브랜치에 직접 병합하고 새로운 충돌이나 회귀를 계속 감시함
    • 주요 Chrome 마일스톤을 2주 주기로 전환하면서 매주 보안 업데이트를 제공하고 있음
    • AI 기반 공격 속도에 대응하기 위해 주 2회 보안 릴리스도 시험 중임
  • Stable에 도달한 모든 보안 버그는 내부·외부 발견 여부와 관계없이 공개 문서화함
    • 수동 병목을 없애고 발견부터 공개까지의 시간을 줄이기 위해 패치에서 릴리스 노트와 CVE 설명을 자동 생성하는 작업을 진행함
  • Chrome은 2008년부터 새 바이너리를 백그라운드에서 내려받아 준비하고 다음 재시작 때 적용하는 자동 업데이트를 사용함
    • 분류·수정·테스트·배포에는 1~2일이 걸리지만, 사용자가 재시작할 때까지의 대기도 N-day 악용 위험에 크게 기여할 수 있음
    • 재시작은 작업을 방해하고 별도 일정을 잡아야 하므로 사용자가 미루기 쉬움
  • 사용자에게 재시작 부담을 넘기지 않기 위한 기능을 개발 중임
    • 동적 패치는 Chrome의 다중 프로세스 구조를 이용해 Renderer·GPU 같은 백그라운드 자식 프로세스를 새 바이너리로 순차 교체하며, 대부분의 경우 전체 브라우저 재시작을 없애는 것이 목표임
    • 복잡한 상황에서도 세션을 복원할 수 있도록 더 많은 상태를 로컬에 저장하는 방법을 검토함
    • 완전한 세션 복원이 보장되는 시점에 자동으로 재시작함
    • Chrome 150은 macOS에서 창이 모두 닫혔지만 앱이 백그라운드에 남아 있는 상태를 감지하고, 대기 중인 업데이트가 있으면 자동 재시작함
  • 장기적으로 지속적인 동적 패치와 방해가 적은 시점의 자동 재시작을 결합한 항상 최신 상태의 브라우저를 목표로 함
  • 기업 IT 관리자를 위한 권장 사항은 다음과 같음
    • RelaunchNotification 정책을 이용해 알림부터 정해진 기간 후 강제 재시작까지 단계적으로 적용함
    • 변경 사항을 검증해야 하는 민감한 환경에서는 Chrome Extended Stable Channel을 사용함
    • Chrome Enterprise Core 또는 Premium의 운영체제 독립 대시보드로 전체 브라우저 버전을 추적하고 업데이트를 세밀하게 관리함

C++ 방어와 Rust 전환

  • Chrome은 기존 C++ 취약점을 런타임에서 무력화하는 동시에 장기적으로 메모리 안전 언어로 전환하는 이중 전략을 사용함
  • Chromium 코드 대부분이 C++이므로 도구 체인과 런타임 완화가 즉각적인 1차 방어선임
    • 강화된 표준 템플릿 라이브러리와 MiraclePtr 계열 기술로 Use-After-Free(UAF) 취약점을 줄여 왔음
  • C++ 방어 로드맵은 세 축으로 구성됨
    • MiraclePtr·MiracleObject 확대
      • MiraclePtr를 Skia, ANGLE, Dawn, C++ 반복자, std:: 컨테이너로 확대함
      • MiracleObject는 국소적인 런타임 성능을 시간적 안전성과 교환해 GPU 메인 스레드 UAF 취약점의 최대 90%를 무력화하는 것이 목표임
    • std::span 전환
      • 포인터와 크기를 함께 사용하는 기존 구조를 컴파일러가 검사하는 std::span으로 바꿔 범위 밖 접근(OOB)을 제거함
      • Chrome 자체 코드의 97%가 엄격한 unsafe-buffer 경고와 함께 문제없이 컴파일되며, Skia·ANGLE·Dawn에도 요구 사항을 확대하고 있음
    • 구조·할당 강화
      • 메모리 할당 계산에 checked math를 적용해 정수 오버플로 경로를 막음
      • 포인터 포함 타입과 비포인터 타입을 엄격히 분리하는 추가 힙 파티셔닝으로 UAF 악용을 어렵게 함
  • C++ 런타임 완화는 향후 수년 안에 한계효용이 줄어들 것으로 봄
    • 런타임 검사는 컴파일 시점 보장보다 비용이 크며, 강하게 완화된 C++ 바이너리도 Rule of Two를 지키려면 성능을 제한하는 엄격한 샌드박스가 필요함
  • 장기적으로는 Rust 전환을 추진함
    • Rust 플라이휠: Chromium 기반 API와 도구를 Rust에 직접 제공하는 중앙 SDK를 구축해 새 구성요소에서 일상적으로 선택할 수 있게 함
    • 버그 밀집 영역 제거: 복잡한 데이터 파서, 이미지 코덱, 폰트 스택처럼 과거 버그 밀도가 높은 코드를 전략적으로 교체함
    • 고권한 모듈화: 새 모듈을 Rust로 작성해 브라우저 프로세스 같은 고권한 영역에서도 샌드박스 성능 비용 없이 복잡한 기능을 실행하도록 함
  • 브라우저 최상위 UI를 HTML·CSS·TypeScript로 구현해 기존 C++ 프레임워크 의존성을 더 줄이는 방안도 검토함

코드 제출 전에 취약점 차단

  • 전체 코드베이스를 주기적으로 스캔하는 방식만으로는 Chrome의 빠른 개발 속도를 따라가기 어려워 AI 검사를 코드 제출 시점 가까이에 배치함
  • CI와 커밋 큐(CQ)의 방어 모델은 변경분을 자동 검사함
    • std::span 전환 수정을 제안함
    • 댕글링 포인터를 표시함
    • 숫자 연산 안전성을 강제함
  • 독립적으로는 안전한 코드도 다른 위치의 작은 논리 변경과 결합하면 심각한 잠재 보안 문제가 될 수 있음
  • CQ 내의 지속적인 LLM 의미 분석은 전통적인 정적 분석이 놓치는 미묘하거나 복잡한 상호작용을 찾아 코드가 트리에 들어오기 전에 차단함

오픈소스 생태계와 외부 의존성

  • 웹 보안은 Chrome 자체뿐 아니라 오픈소스 프로젝트와 유지관리자의 대응 역량에도 의존함
    • Google은 유지관리자가 취약점 신고에 빠르게 대응할 도구와 지원을 확보하도록 Alpha-Omega 프로젝트에 다른 참여자들과 함께 1,250만 달러를 기부함
    • Akrites 프로젝트의 창립 회원으로 참여했으며, 중앙 취약점 신고 창구와 보안 사고 대응팀을 제공해 업스트림 유지관리자의 부담을 줄이는 것이 목표임
  • Chromium과 V8, BoringSSL, Skia, ANGLE, Dawn 같은 관련 프로젝트에는 2,300개가 넘는 외부 의존성이 있음
    • 이 가운데 약 1,700개가 Android 기기, 엣지 컴퓨팅 플랫폼, 대규모 클라우드 기업 스택 등 다양한 제품을 통해 사용자에게 배포됨
  • 자동 취약점 검사 파이프라인은 Google 내부 피드와 미국 정부의 NVD, 오픈소스 중심의 OSV 데이터를 수집함
  • 사후 모니터링만으로는 위험 격차가 남을 수 있어 모든 Chrome 외부 의존성을 최신 업스트림 버전으로 선제 갱신하는 자동 업데이트 파이프라인으로 옮기기 시작함
  • 자동화 과정에서는 GOSSIP 같은 프로젝트의 안전 신호를 이용해 외부 오픈소스 생태계의 다른 위험도 반영함

지속적으로 보호되는 브라우저

  • LLM으로 발견·수정되는 버그 수가 늘어나는 것은 실패가 아니며, 수정된 버그 하나마다 공격자가 이용할 발판이 하나씩 줄어듦
  • 발견과 수정만으로는 충분하지 않으며, 공격자가 악용하기 전에 수정본을 배포하고 사용자 환경에 적용해야 함
  • 더 빠른 릴리스, 동적 패치, 방해가 적은 시점의 자동 재시작과 구조적 방어를 결합해 사용자를 방해하지 않으면서 지속적으로 보호되는 Chrome을 지향함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 최근 업무가 바쁜 동안 성능 최적화에 AI를 많이 써봤지만, 상위 수준의 방향을 잡는 데는 거의 쓸모없었음. SQL 쿼리에서 의심스러운 부분을 짚어도 전후 성능 차이가 거의 없었고, 쓸데없는 제안에 시간을 빼앗겼으며 다른 사람들이 가공하지 않은 AI 출력을 의미 있는 기여처럼 던지는 일까지 감당해야 했음
    다만 직접 찾아낸 변경 사항을 구현하거나 조인을 CTE로 옮기는 작업은 훨씬 쉬워졌음

    • 쓸모없는 장문 제안은 정말 피곤함. 동료 한 명은 Slack, Jira, 코드 리뷰, 이메일을 포함한 모든 비동기 소통에 Claude를 사용해, 간단한 질문에도 범위가 계속 불어나는 거대한 글벽으로 답함
      AI 도구에 “간결하게”, “질문에만 답해”, “요청하지 않은 정보는 주지 마”라고 반복해도 필요 이상으로 출력하는데, 토큰을 더 소비하려는 미묘한 시도처럼 보임
    • AI가 자신의 가설을 검증할 도구를 모두 제공하고 전체 생명주기를 반복 실행하게 하면 놀랄 만큼 잘 작동함
    • 쿼리와 함께 EXPLAIN ANALYZE 출력을 주면 AI가 최적화하는 데 큰 어려움이 없어서, 쿼리 최적화에 쓸모없었다는 평가는 의외임
    • 어떤 모델을 사용했는지도 밝혀야 함. 최전선 모델끼리도 차이가 매우 크며, 벤치마크상 차이보다 실제로는 Opus 5.0이 Cursor Grok 4.5와 전혀 다른 급이고 Sonnet이나 Composer와도 비교하기 어려움
    • 코드만 보여주고 성능 최적화를 찾게 한 것이 잘못임. 성능 프로파일, 쿼리 계획, 원격 측정 자료를 제공하고 변경 전후를 측정해야 함
      코드 텍스트만으로는 캐시 크기, 데이터베이스 용량, 네트워크 지연 시간을 알 수 없으므로 이런 맥락을 줘야 더 나은 결과를 얻을 수 있음

  • 지난 5월 베를린 Pwn2Own에서 Firefox가 상금을 전혀 지급하지 않았다는 사실이 핵심 자료임. 2007년 이후 모든 행사에서 상금을 지급해왔는데 확인된 취약점이 하나도 없었다는 것은 이제 손쉬운 취약점이 거의 사라졌고, 이런 모델이 어느 정도 유용하다는 신호로 보임

  • 많은 버그를 고칠 수 있다는 점은 믿지만 실제 과정이 궁금함. Google이 블로그를 내고 관리자가 상부에 AI 도입 성과를 보여주도록 몇 차례 스프린트 동안 버그 수정을 독려해, 팀이 평소보다 훨씬 많이 일했을 가능성도 있음

    • Google은 수십 년 동안 모든 것을 자동화해왔고 퍼저와 Project Zero도 그 흐름에 속함. 그 위에 LLM을 추가하고, 하니스와 개발 도구를 개선해 탐지·분류·수정·확인을 종단 간으로 연결하는 것은 자연스러운 다음 단계임
      LLM의 성능은 실행되는 반복 구조에 달렸고, 그 구조는 검증기의 품질에 달렸으므로 관리자의 성과 과시가 없어도 충분히 설명 가능함
    • 정적 분석이나 퍼징 같은 새 분석 도구를 도입할 때마다 새로 발견된 버그가 처음에는 폭증하고, 이를 처리한 뒤에는 발견 빈도가 다시 낮아졌을 가능성이 큼
    • 2026년 초 모든 범주의 버그 보고가 늘어 3월에는 2025년 전체보다 많아졌다면, AI 사용이 버그 수 자체도 크게 늘렸을 수 있음. 가령 2025년에는 50개를 찾아 45개를 고쳤지만 2026년에는 500개를 찾아 450개를 고친 그림일 수 있음
    • AI가 코드를 빠르게 해석해 버그 적체를 더 빨리 처리하고, 코드 및 보안 리뷰도 빨라져 더 많은 문제를 찾을 수 있음. Linux 커널을 비롯해 Windows와 Apple에서도 비슷한 현상이 나타나는 듯함
    • Chrome 엔지니어링 조직에는 지난 10여 년간 Google 고위층이 사업적 가치를 인정하지 않으면 버그를 고치지 않는 무기력한 문화가 있었을 수 있음. 지금은 AI를 더 팔기 위해 버그를 고치고 그 공을 AI에 돌릴 사업적 동기가 생긴 것으로 의심함

  • AI를 무작정 일하게 두는 대신 가속 도구로 활용해야 하는데, 비판자들은 이를 혼동하는 듯함. 투자 수익이 나쁘다고 Excel에 화내는 것과 비슷한 허수아비 논법이라 더 논쟁하기보다 제대로 효율적으로 쓰려는 사람들과 조용히 활용법을 나누고 싶음

    • 정작 AI를 어떻게 써야 하는지 명확하지 않음. 한쪽은 모든 맥락을 주고 마음껏 실행시키라 하고, 다른 쪽은 세심하게 안내하며 모든 결과를 검토하라고 하며 양쪽 모두 지지를 받음
      방치하면 몇 번의 반복 만에 결과가 나빠지고, 꼼꼼히 안내하면 가치가 생기지만 그 노력은 특히 반복 작업이 있을 때 직접 코드를 작성하는 것과 비슷하게 듦
    • 실제로는 AI가 개발자를 가속하는 도구지만, 경영진과 최전선 연구소는 곧 코드를 읽을 필요도 없고 프로그래머도 사라질 것처럼 홍보하고 있음
    • AI가 이제 국제 안보와 정치의 문제가 된 만큼 이 분야에는 선전이 많을 수 있으며, 현재 논쟁은 10년 전 정치 논쟁과 비슷한 형태를 띰
    • Bitcoin이 내 문제를 해결한 용도를 설명해도 모두 불가능하다고 하던 논쟁이 떠오름. 그렇다고 AI가 Bitcoin과 같다는 뜻은 아님
    • 버그 수정, 코드 개선, 리팩터링은 AI에 가장 잘 맞는 작업임. 오래된 소프트웨어를 마침내 다듬을 수 있으리라 기대했지만, 계속 빨라지는 새 기능 개발만 요구받던 사람들은 배치된 환경에 따라 환호하거나 냉소하게 됨

  • 자동 수정 중 몇 개가 되돌려졌는지, 새 버그를 몇 개 만들었는지, 탐지 에이전트의 거짓 양성률은 얼마인지 알 수 없음. 게시물에는 성공한 수치만 있고 잘못될 수 있는 부분은 전혀 없음

    • 실제로는 AI 덕분에 버그를 많이 찾고 고쳤다고 홍보하지만, AI로 최대한 많은 버그를 수정하는 것이 핵심 성과 지표가 되어 오래되고 쉬운 적체 항목을 AI로 찾아 사람이 고쳤을 가능성이 큼
    • M146 이후 버그 발견량 급증이 더 나은 테스트 때문인지, 애초에 새 버그가 더 많이 들어갔기 때문인지 설명하지 않음
    • Amazon에는 AI 성공 사례를 공유하는 공간은 많지만 실패나 실망을 공유할 곳은 없음. 경영진이 일방적인 이야기만 듣고 AI에 관해 잘못된 결정을 내리는 것도 당연함
    • 그 버그 중 AI가 새로 만든 것은 몇 개인지도 궁금함
    • 브라우저 보안에서는 새 버그가 조금 생기는 것이 큰 문제는 아닐 수 있음. 2012년 Pinkie Pie 공격도 6개 버그를 연결해야 했고 이후에는 10개 이상을 연결해야 하는 공격도 등장했으므로, 그중 하나만 고쳐도 공격 전체가 무력화됨
      버그 10개를 고치면서 2개를 새로 만들더라도 단독 악용 가능한 심각한 버그만 아니라면 순이익이 큼. 브라우저 공격은 갈수록 더 긴 취약점 연결 고리를 요구하므로 AI로 잠재적 버그를 찾는 이점은 무시하기 어려움
      https://blog.chromium.org/2012/05/tale-of-two-pwnies-part-1....

  • 앞으로 Google이 Chromium에 공개적인 집단 버그 탐색이 필요 없다고 판단해 공개 개발을 중단할까 우려됨. 그러면 현재 Chromium 계열은 마지막 공개 버전의 사실상 포크가 되고, Gemini의 지원을 받는 Chrome만큼 유지할 자원이 없어 각 포크의 관리 난이도가 달라질 수 있음

    • Google이 이미 Chrome과 Chromium의 방향을 강하게 통제하므로 열린 웹을 중시한다면 Firefox를 써야 함

  • AI 비판은 흔히 코드를 맹목적으로 생성하는 것이 나쁘다는 좁은 범주에 집중되며, 그 점은 쉽게 인정할 수 있음. 하지만 적대적 테스트, 개발자 가정 검증, 리팩터링 제안, 작은 개발 도구, 안내를 곁들인 코딩, 대규모 코드베이스의 의존성과 동작 추적은 반대편에 있으며 큰 도움을 받을 수 있음
    맹목적 코드 생성에 해당하는 비판을 이런 활용 전체와 너무 쉽게 뒤섞고 있음

    • AI는 특정 방식으로 사용해야 하는 도구임. 원하는 방향을 지정해야 하며 모든 문제를 마법처럼 해결하길 기대하면 안 됨
    • AI에는 개인이 모두 갖출 수 없는 능력이 있지만 사용자보다 더 똑똑한 것은 아니며, 사용자가 교정하지 않으면 잘못된 결정을 자주 내림

  • 애초에 이 버그 중 몇 개가 LLM이 작성한 코드에서 생겼는지가 핵심임. 버그를 100배 더 만들고 100배 더 고치는 것은 자랑할 일이 아님

    • Chrome은 20년 넘은 프로젝트이고 LLM은 최근에 등장했으며, LLM 코드 생성기가 나왔다고 코드 리뷰와 테스트를 느슨하게 하지도 않았음. 13년 된 이슈도 언급된 만큼 영향을 받은 영역에서 최근 개발이 많지 않았을 가능성이 큼
      오픈 소스 프로젝트이므로 실제로 LLM이 만든 버그인지 직접 확인할 수도 있음
    • 코딩을 AI에 점점 넘기면 사람이 잠재적 버그를 식별하는 능력도 떨어질 수 있음. AI 작성 기능을 커밋 전에 다시 AI로 검사하다 보면 기반 시설을 실행하는 코드조차 인간이 이해할 수 없는 세계에 가까워짐
    • Git 통계를 보면 제출된 코드 줄 수가 극적으로 변하지 않았음. 모두가 저품질 AI 코드를 그대로 병합하는 것은 아니며, 기존 주요 조직들은 무책임한 바이브 코딩 결과물을 대체로 병합하지 않음
    • AI가 더 적은 버그로 코드를 만들 수 있다고 가정하면 새 버그가 100배 늘었다는 것은 신규 기능 개발 속도가 100배 이상 빨라졌다는 의미임. 모델이 13년 된 치명적 버그를 찾는다면 같은 역량으로 그런 버그가 없는 새 코드도 작성할 수 있을 것임
    • 프로젝트의 연혁과 규모를 무시하고 근거 없이 버그가 100배 늘었다는 수치를 만들어 이를 핵심 문제라고 부르는 것은 비합리적임. AI 주제에서는 현실을 억지로 구성하려는 태도가 유난히 많이 보임

  • Chrome이 어디서 무엇을 하든 사용자를 추적하려는 행동 추적 버그도 고쳤는지 궁금함

답변달기