최근 업무가 바쁜 동안 성능 최적화에 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 주제에서는 현실을 억지로 구성하려는 태도가 유난히 많이 보임