Chrome DevTools에서 AI 엔지니어링까지: Addy Osmani가 말하는 개발자의 다음 역할

URL: https://www.youtube.com/watch?v=2fyPnxKu8ZM 날짜: 2026-08-21 발행일: 2026-08-19 채널: The Pragmatic Engineer 원문 제목: From Chrome DevTools to AI Engineering, with Addy Osmani

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI가 코드 작성 비용을 낮추는 시대에 개발자의 경쟁력은 구현 속도가 아니라 문제를 고르는 취향(taste), 시스템을 이해하는 인지적 깊이(cognitive depth), 품질을 검증하고 결과에 책임지는 능력(accountability)으로 이동한다.==

• 브라우저를 직접 만들던 10대의 호기심이 jQuery, TodoMVC, Speedometer, Chrome DevTools와 Core Web Vitals로 이어졌다.
• AI 에이전트는 조사·코딩·테스트를 자동화하지만, 에이전트의 판단을 맹목적으로 받아들이는 인지적 항복(cognitive surrender)과 이해력의 침식인 인지 부채(cognitive debt)를 만든다.
• 소프트웨어 팩토리(software factory)와 루프 엔지니어링(loop engineering)은 프롬프트 한 번의 결과가 아니라 요구사항·구현·테스트·텔레메트리·사용자 피드백을 잇는 시스템을 만드는 일이다.
• 코드의 상당 부분이 에이전트가 작성하더라도 특정 시스템 영역을 이해하고 무엇을 출시할지 결정하며 안정성을 보증하는 사람은 계속 필요하다.

Addy Osmani의 경력은 한 계층 더 깊이 파고드는 습관이 장기적인 기술 영향력으로 연결되는 사례다. 다이얼업 인터넷을 쓰던 아일랜드의 학생은 다운로드 관리자의 병렬 청크 처리에서 브라우저 성능을 개선할 아이디어를 얻었고, 직접 브라우저를 만든 뒤 오픈소스와 Google Chrome의 개발자 도구를 거쳐 AI 에이전트 시대의 개발 방식까지 확장했다. 핵심 전환은 ‘코드를 누가 타이핑하는가’가 아니라 ‘어떤 문제를 선택하고, 어떻게 검증하며, 결과에 누가 책임지는가’다.

1. 에이전트가 바꾼 일상과 출발점

1.1. 에이전트가 시간의 제약을 풀어 놓은 방식

1. AI World Fair 발표 준비를 연구 프로젝트로 바꾸다

   1. Addy는 샌프란시스코에서 열린 AI World Fair의 폐막 기조연설을 준비하면서 다른 발표자들이 이미 깊이 다룬 논점을 반복하고 싶지 않았다.
   2. 예전에는 발표 자료가 온라인에 올라오기를 기대하거나 초록을 직접 훑어야 했지만, 여러 에이전트에게 최근 며칠간의 세션 초록·소셜 게시물·관련 자료를 조사하게 했다.
   3. 조사 결과를 기존 발표 아이디어와 연결해 다른 세션에서 폐막 연설로 자연스럽게 이어지는 구조를 만들 수 있었다. 과거라면 가능했더라도 매우 오래 걸렸을 작업이 실행 가능한 범위로 들어왔다.

2. 해방과 혼돈이 동시에 커지는 작업 환경

   1. 에이전트는 아이디어가 많아도 시간과 실행 능력 때문에 포기해야 했던 일을 시도하게 한다.
   2. 줄어든 시간을 쉬는 데 쓰기보다 더 많은 실험과 작업에 다시 투자하는 이유는 그 과정 자체가 재미있기 때문이다.
   3. 생산성 증가는 여유를 자동으로 보장하지 않는다. 더 많은 가능성이 열린 만큼 매일 재미와 혼돈이 함께 커진다.

1.2. 다이얼업 인터넷에서 브라우저를 만들기까지

1. 어떻게 작동하는지 알고 싶었던 어린 시절

   1. 아일랜드 시골에서 자라며 인터넷 연결이 좋지 않았고, 첫 컴퓨터를 접한 나이는 여덟아홉 살 무렵이었다.
   2. 주소창에 무언가를 입력하면 텍스트·사진·동영상이 렌더링되는 과정이 신기해 웹사이트를 만들고 프로그래밍을 시작했다.
   3. 첫 언어는 Pascal이었고 Borland 도구 모음을 좋아했으며, 어린 나이에 C++도 배웠다.

2. 다운로드 관리자의 병렬 처리에서 브라우저 아이디어를 얻다

   1. 노래 하나를 받는 데 몇 시간, 뮤직비디오 하나를 받는 데 하룻밤이나 이틀이 걸리던 시절이었다.
   2. 다운로드 관리자는 서버에 연결 하나만 만드는 대신 여러 스레드로 여러 연결을 만들고 파일을 청크(chunk)로 나눠 동시에 받았다.
   3. 서버가 청크 처리를 지원하면 파일을 더 빨리 받을 수 있었고, 문제를 작은 조각으로 나누는 고전적인 컴퓨터 과학 기법을 웹페이지 탐색에도 적용할 수 있겠다는 발상이 나왔다.

3. 15~16세에 브라우저의 계층을 직접 구현하다

   1. HTML, CSS, JavaScript 사양을 읽으며 브라우저를 만들기 시작했다.
   2. 문서와 이미지를 파싱하고 불러오는 것보다 어려운 일은 사양을 느슨하게 해석하는 현실의 웹페이지를 처리하는 일이었다. 브라우저는 개발자가 온갖 이상한 코드를 던져도 무언가를 렌더링해야 한다.
   3. JavaScript 상호작용을 붙이는 일은 특히 어려웠고, 완전한 브라우저를 만들겠다는 욕심으로 당시의 애플릿(applet), Flash, Windows Media Player 임베드까지 지원했다.

4. 도서관의 빠른 인터넷과 화물바지의 플로피 디스크

   1. 집에 좋은 인터넷이 생기기 전에는 매주 주머니가 많은 화물바지에 플로피 디스크를 가득 넣고 조금 더 빠른 인터넷이 있는 동네 도서관까지 걸어갔다.
   2. 도서관에서 최대한 많은 자료를 저장한 뒤 집으로 돌아와 자신의 컴퓨터에서 확인하는 일이 개인적인 성능 개선 프로젝트의 출발점이었다.
   3. 서버가 병렬 청크 다운로드를 지원하는 경우 실제로 속도가 빨라졌고, 자신에게 필요한 브라우저를 만들어냈다.

5. 국가 과학 경진대회 우승이 남긴 교훈

   1. 컴퓨팅을 진지하게 다루기 시작한 첫 해의 국가 과학 경진대회에 프로젝트를 제출했다.
   2. 우승을 전혀 예상하지 못한 평범한 학생이었지만 생방송 무대에서 전체 우승자로 불렸고, 다음 주말 휴대전화가 계속 울렸다.
   3. 첫 전화는 Wall Street Journal이었고 CNN 등에서도 연락이 왔다. 소셜미디어가 없던 시절에 갑자기 바이럴이 된 셈이었다.
   4. 한 대의 컴퓨터에서 목표를 달성하는 앱을 만들었다고 해서 그 아래의 모든 계층을 이해하는 것은 아니었다. 이 경험은 문제의 내부 작동 원리와 해결 방법을 계속 파고드는 평생의 지식 욕구로 이어졌다.

1.3. 계층을 벗겨 보는 습관과 초기 경력

1. 컴퓨팅이라는 양파의 층

   1. 브라우저를 이해하려면 네트워크, 합성(compositing), JavaScript 엔진, 칩, 메모리, GPU까지 차례로 내려가야 한다.
   2. 각 계층을 더 많이 알수록 느린 휴대전화나 제한된 환경에서 왜 성능이 나쁜지 이해하고 다른 설계를 선택할 수 있다.
   3. 표면적인 렌더링 결과만 보는 대신 실제 제약을 만드는 기반 요소를 이해하는 것이 최적화의 출발점이다.

2. AOL에서 겪은 시대의 농담

   1. 브라우저 관련 일을 계속하다 AOL에 합류한 첫날, 매니저가 업무용 브라우저에 로그인해 팀을 도우라고 했다.
   2. AOL 브라우저를 실행하자 디버깅보다 먼저 신용카드 번호를 입력하라는 화면이 나왔다. 매니저가 바빠 우회 방법을 물어볼 수도 없어 ‘이게 일을 시작하는 절차인가 보다’ 하고 입력할 뻔한 순간이었다.
   3. 당시의 제품·업무 환경이 지금과 얼마나 달랐는지를 보여주는 일화다.

2. 오픈소스 실험이 웹 플랫폼의 기준이 되다

2.1. jQuery에서 배운 커뮤니티와 유지보수

1. 첫 대형 오픈소스 경험

   1. jQuery는 John Resig가 만든 프로젝트로, Addy에게 큰 커뮤니티 오픈소스에 기여한 첫 경험이었다.
   2. 처음에는 이슈 트리아지와 관리부터 시작해 블로그 글, 코드, 여러 형태의 기여로 확장했다.
   3. John Resig는 새 참여자가 배우고 성장할 수 있는 환영하는 환경을 만들었다.

2. 커뮤니티의 요구와 장기 유지보수 사이의 균형

   1. jQuery가 널리 쓰이면서 사용 사례가 폭발했고, 어떤 기능을 핵심 라이브러리에 넣을지 플러그인으로 둘지를 두고 강한 의견이 충돌했다.
   2. 모든 요구를 받아들이는 대신 장기적인 유지보수성을 기준으로 선을 긋는 일이 중요했다.
   3. 커뮤니티와 협력하면서도 장기적으로 감당할 수 있는 결정을 내리는 법을 배웠고, 이후 자신의 오픈소스 프로젝트에도 이 원칙을 적용했다.

2.2. TodoMVC와 프레임워크 비교라는 교육 장치

1. 프레임워크가 넘쳐나던 JavaScript의 암흑기

   1. 프레임워크와 라이브러리가 거의 없던 시기를 지나 Angular, Backbone, YUI, X.js 등 서로 겹치거나 인접한 목표를 가진 도구가 빠르게 늘어났다.
   2. 각 프로젝트의 랜딩 페이지는 모두 앱을 쉽게 만든다고 말했지만 아키텍처 철학과 실제 문법의 차이는 한눈에 비교하기 어려웠다.
   3. Addy는 같은 기능의 애플리케이션을 각 프레임워크로 구현해 컴포넌트·UI·상태 관리·라우팅에 대한 각자의 입장을 비교하는 실험을 시작했다.

2. 간단하지만 충분히 스트레스가 되는 Todo 앱

   1. 거의 누구나 이해할 수 있을 만큼 단순하면서도 상태 관리, 라우팅, 상호작용을 시험할 수 있을 만큼 기능이 있는 할 일 앱을 공통 기준으로 삼았다.
   2. 프로젝트는 빠르게 수천 개의 별(star)을 얻었고, 새 프레임워크를 만드는 사람들이 직접 Pull Request를 보내 자신의 구현을 추가해 달라고 요청했다.
   3. Cindresorhus를 비롯해 훗날 각자 유명해진 오픈소스 동료를 만났고, TodoMVC는 여러 해 동안 프레임워크 튜토리얼의 사실상 표준 예제가 됐다.
   4. 시작 후 오랜 시간이 지난 뒤에도 연구실이나 도구 제작자가 기능을 시험할 때 TodoMVC를 사용한다는 점이 프로젝트의 가장 놀라운 장수 기록으로 남았다.

2.3. Speedometer로 이어진 브라우저 응답성 연구

1. Apple과의 협업

   1. 프로젝트가 성장하자 Safari와 WebKit을 만드는 Apple 팀이 브라우저가 얼마나 반응성 있게 동작하는지 평가할 벤치마크 협업을 제안했다.
   2. 여기서 말하는 반응성은 모바일 레이아웃이 아니라 클릭과 탭에 얼마나 빨리 반응하는가를 뜻했다.
   3. 협업의 결과가 Speedometer가 됐고, 이후 모든 브라우저의 웹 애플리케이션 반응성 벤치마크로 자리 잡았다.

2. 변하는 웹을 계속 측정하는 기준

   1. 브라우저 업체들이 함께 Speedometer를 유지하고 새 프레임워크와 아키텍처 패러다임이 나올 때마다 내용을 갱신했다.
   2. 단순한 개인 프로젝트가 브라우저 생태계 전체가 공유하는 측정 기준으로 확장된 사례다.
   3. 도구와 기준은 고정된 정답이 아니라 실제 개발 방식의 변화를 따라가며 갱신돼야 한다.

3. Chrome DevTools가 브라우저 안의 IDE가 된 과정

3.1. 2012~2013년 웹 개발 도구의 전환기

1. Google과 Chrome으로 들어간 계기

   1. 미국 중서부에서 아내의 부모를 방문하던 시절 Google 엔지니어의 이야기를 다룬 다큐멘터리를 보고 언젠가 그런 곳에서 일하고 싶다고 생각했다.
   2. 수년간 프런트엔드·JavaScript·웹 앱 교육 자료를 무료로 공개했고, Google이 그 영향력을 알아보면서 Developer Relations(DevRel) 및 builder 역할 면접을 제안했다.
   3. 개발자 교육과 실제 도구 제작을 함께 하는 역할로 Chrome 팀에 합류했다.

2. Chrome이 아직 시장을 지배하기 전의 개발자 중심 문화

   1. 2012~2013년 Chrome 팀은 개발자가 플랫폼의 가능성과 빈틈을 직접 보여주기를 원했다.
   2. Chrome Experiments 사이트에서 스튜디오와 개발자가 만든 WebGL 사례를 선보였고, 이를 본 사람들이 셰이더와 관련 라이브러리를 더 배울 수 있도록 영감을 제공했다.
   3. 당시에는 Next.js 같은 메타 프레임워크가 없었고, 브라우저마다 표준 JavaScript 모듈이 정착되지 않아 AMD, UMD, CommonJS가 함께 쓰였다.
   4. Grunt 같은 빌드·스캐폴딩 도구가 발전하는 중이었고, 이후 Gulp, Webpack, Vite, Rollup으로 도구 체계가 계속 바뀌었다. 최근 들어서야 이 생태계가 어느 정도 안정됐다.

3. Yeoman과 Firebug 시대

   1. Google은 Yeoman이라는 CLI 스캐폴딩 도구를 만들어 프로젝트 시작점을 정리했다. 사용자는 마법사에서 UI 라이브러리, 테스트 라이브러리, 배포 대상을 선택할 수 있었다.
   2. 지금은 거의 모든 도구에 들어 있는 이런 초기화·선택·생성 개념이 당시에는 새로웠고, 그때 만든 모듈이 오늘날 도구의 내부에서 여전히 사용될 가능성도 있다.
   3. 브라우저 디버깅은 Firefox의 Firebug에 의존했고, Internet Explorer에서 같은 코드가 동작할지 기대하는 수준이었다. IE의 개발자 도구는 나중에 좋아졌지만 당시에는 선택지가 적었다.

3.2. DevTools의 설계 철학과 어려운 문제

1. Pavle Feldman과 개발자 중심의 방향

   1. Chrome DevTools의 기술 리드였던 Pavle Feldman은 초기 방향을 잡는 데 큰 역할을 했다.
   2. Chrome은 WebKit의 Safari Inspector와 차별화하면서 개발자 생태계를 중심에 둔 도구를 만들려 했다.
   3. Paul Irish, Paul Bakaus 등 웹 개발자 유형의 빌더가 DevTools 팀과 긴밀히 일하며 실제로 겪는 마찰을 전달했다. 단순히 도구 화면을 만드는 것만으로 해결되지 않고 기저 계측(instrumentation)이 필요한 문제도 많았다.

2. Performance 패널의 추적과 메모리 디버깅

   1. Performance 패널에서 Record를 누르고 페이지와 상호작용하면 flame graph와 어디에서 시간이 쓰였는지 보여주는 깊은 트레이스가 생성된다.
   2. 메모리 관리는 개발자가 충분히 이해하지 못하는 경우가 많아 메모리 문제를 디버깅하기 더 어렵다.
   3. 힙의 변수와 증가하는 영역, 스택과 루프를 시각화할 수는 있지만 메모리가 왜 계속 커지는지 일반화해 설명하는 일은 여전히 어렵다. 메모리 디버깅의 최첨단은 여러 해 동안 크게 발전하지 못한 난제다.

3. 프레임워크 시대의 소스맵과 블랙박스

   1. 복잡한 웹 앱에서는 프레임워크 코드, 플러그인·컴포넌트, 직접 작성한 코드가 뒤섞인다. 개발자가 실제로 고치고 싶은 부분이 무엇인지 구분해야 한다.
   2. 소스맵(source map)은 긴 빌드 도구 체인을 거쳐 생성된 코드에서 원래의 파일과 위치로 되돌아가게 한다. Uber, Netflix, Twitter 같은 대형 사이트가 한 작업에 사용하는 도구 수와 복잡성은 외부에서 생각하는 것보다 훨씬 크다.
   3. DevTools는 블랙박스(blackbox) 뷰와 토글을 제공해 React 라이브러리 자체의 문제는 숨기고 개발자가 작성한 React 코드의 문제만 보게 했다. 어떤 계층을 보고 어떤 계층을 무시할지 선택권을 준 것이 핵심이다.

3.3. 모바일, PWA, AI 시대의 DevTools

1. 모바일 기기 모드

   1. 모바일에서는 뷰포트 너비, 탭 대상의 크기, 다양한 센서와 터치 상호작용을 확인해야 하지만 초기에는 이를 위한 도구가 거의 없었다.
   2. Device Mode로 iPhone이나 Pixel에 가까운 여러 뷰포트에서 페이지를 빠르게 미리 보고 방향이 맞는지 판단하게 했다. 정확한 기기에서 테스트하는 것만큼 완벽하진 않지만 초기 피드백에는 매우 유용했다.

2. PWA와 Application 패널

   1. 웹이 네이티브 앱과 경쟁하려면 오프라인 캐시, Push Notification, Background Sync 같은 기능이 필요했다.
   2. 이런 기능은 구현만큼 디버깅이 중요하므로 service worker, cache, 각종 PWA 동작을 확인할 Application 패널을 만들었다.
   3. 브라우저 API가 발전할 때마다 도구도 함께 확장해 새로운 개발 흐름을 따라갔다.

3. IDE가 아니라 개발자가 있는 곳을 보완하는 도구

   1. Chrome DevTools는 Visual Studio처럼 브레이크포인트·조건부 브레이크포인트·성능·메모리·시뮬레이션·인라인 편집을 제공해 브라우저 안의 IDE처럼 보이게 됐다.
   2. 팀 내부에서는 DevTools를 IDE라고 부를지 논쟁이 있었지만, 개발자는 각자 선호하는 에디터를 계속 사용할 것이므로 특정 IDE를 대체하기보다 필요한 순간에 유용한 표면이 되는 방향을 택했다.
   3. 이 원칙은 에이전트의 control plane이 새 작업 표면이 된 지금도 같다. 중요한 것은 개발자가 일하는 위치에서 유용한 계측과 제어를 제공하는 일이다.

4. LLM과 Chrome의 결합

   1. Yong Gao가 다음 기술 리드로 일하며 AI가 DevTools의 새로운 시대를 열었다.
   2. 브라우저가 생성하는 방대한 데이터를 사람이 이해하도록 돕고, 에이전트가 Chrome과 DevTools에 연결돼 탐색·디버깅 여정을 자동화하도록 하는 두 문제가 동시에 등장했다.
   3. 큰 사이트의 성능 트레이스를 사람이 처음부터 읽으면 수정 코드를 쓰기도 전에 반나절이 지나갈 수 있지만, LLM은 거대한 스택 트레이스를 빠르게 요약하고 고칠 수 있는 지점까지 좁혀 준다.

4. 사용자의 체감과 수치를 연결한 Core Web Vitals

4.1. ‘페이지가 로드됐다’에서 ‘사용할 수 있다’로

1. 모호한 로딩 시간을 사용자 여정의 순간으로 분해하다

   1. 예전에는 페이지가 얼마나 빨리 렌더링되거나 다운로드되는지 정도로 성능을 측정했다.
   2. 그러나 ‘준비됐다’는 말은 화면에 보인다는 뜻인지, 클릭할 수 있다는 뜻인지, 클릭했을 때 실제로 무언가 일어난다는 뜻인지 불명확했다.
   3. 팀은 사용자가 실제로 신경 쓰는 순간을 분리했다. 무언가 진행되고 있는가, 헤더나 스피너가 보이는가, 유용한 헤더·히어로 이미지·히어로 동영상·핵심 텍스트가 보이는가, 바로 조작할 수 있는가를 각각 측정해야 했다.

2. Core Web Vitals의 주요 지표

   1. LCP(Largest Contentful Paint)는 페이지에서 가장 큰 핵심 콘텐츠가 표시되는 시점을 측정한다. 페이지에 따라 히어로 이미지가 될 수도 있고 기사의 본문 텍스트가 될 수도 있다.
   2. CLS(Cumulative Layout Shift)는 콘텐츠가 늦게 로드되면서 이미 읽고 있던 화면이 움직이는 정도를 측정한다.
   3. FID(First Input Delay)는 첫 입력에 대한 지연을 다뤘고, 이후 INP(Interaction to Next Paint)가 상호작용 전반의 반응성을 더 잘 포착하는 지표로 이어졌다.
   4. 이 지표들은 단순한 기술 숫자가 아니라 사용자가 느끼는 ‘보인다·쓸 수 있다·안정적이다’를 수치로 연결한다.

4.2. 클릭 무반응과 레이아웃 이동의 실제 경험

1. 장바구니 버튼을 눌렀는데 아무 일도 일어나지 않는 경우

   1. 사용자가 쇼핑 중 Add to Cart를 눌렀는데 JavaScript가 아직 로드되지 않았거나 이벤트 핸들러가 붙지 않았다면 화면에는 아무 반응도 없다.
   2. 엔지니어는 스크립트나 핸들러의 상태를 알지만 사용자는 ‘무슨 일이 일어나고 있지?’라고 생각한다.
   3. 반응이 없어 같은 버튼을 두세 번 누르면 핸들러가 나중에 붙어 장바구니에 중복 추가될 수도 있다.

2. 신호등 버튼 비유와 광고 레이아웃 이동

   1. 횡단보도 신호가 바로 바뀌지 않으면 사람은 신호 버튼을 계속 누른다. 인터넷에서도 사람은 같은 방식으로 반응한다.
   2. 광고·모달 등 수익화를 위한 요소가 늦게 로드되어 이미 읽던 기사를 아래로 밀어내면 사용자는 문장을 따라갈 수 없다.
   3. CLS는 광고를 없애자는 지표가 아니라 광고가 있더라도 페이지를 안정적으로 유지해 사용자가 좋은 경험을 하게 하자는 원칙에서 나왔다.

3. 다양한 웹을 하나의 기준으로 다루기 위한 검증

   1. 인터넷은 동질적이지 않아 어떤 페이지에서는 이미지가 중요하고 다른 페이지에서는 본문이나 즉각적인 조작이 더 중요하다.
   2. 팀은 여러 정의와 측정 방식을 실험하고 표준 커뮤니티와 개발자에게 실제 페이지의 가치 판단과 맞는지 검증했다.
   3. Core Web Vitals는 각 조직이 ‘우리 사용자에게 진짜 중요한 행동은 무엇이고, 그 행동을 빠르고 안정적으로 보장하려면 무엇을 고쳐야 하는가’를 구체적으로 대화하게 만들었다.

5. Google의 대규모 엔지니어링 문화와 Addy의 경력 전환

5.1. 수십억 사용자를 위한 실험과 개발자와의 협업

1. 스타트업과 다른 실험의 규모

   1. Chrome 성능처럼 수십억 명에게 배포되는 기능은 빠른 직감만으로 바꾸기 어렵다.
   2. 국가·시장별로 여러 해법을 시험하고, 동시에 20개 또는 100개의 실험이 돌아가는 상황에서 무엇이 성공인지 판단해야 한다.
   3. Chrome 팀은 현실 세계에서 A/B 테스트를 수행하는 안정적이고 엄격한 절차를 갖췄다.

2. 개발자에게 맞추는 플랫폼

   1. 조직이 크면 모든 팀이 항상 같은 방향으로 소통하기 어렵지만, 개발자 선호와 커뮤니티 신뢰를 중요하게 여기는 사람은 많았다.
   2. Addy는 자신의 Chrome 문화 기여를 ‘개발자가 있는 곳에서 만나는 것’으로 요약한다. 개발자가 어떤 기술을 선택할지 플랫폼이 지시할 수 없으므로, 선택한 기술로 성공하도록 돕는 것이 플랫폼의 역할이다.
   3. 프레임워크 팀과 API 요구사항을 협의하며 커뮤니티의 필요를 추측하기보다 실제 피드백을 바탕으로 플랫폼을 만들었다.

3. 내부 학습과 높은 주도성

   1. Google은 서로 다른 조직의 실험·테스트·사용자 경험 관점을 내부 문서로 공유해 수렴점을 찾을 수 있게 했다.
   2. Chrome 팀은 YouTube 팀과 협업해 YouTube의 Core App Vitals를 개선했고, 더 정교한 경험 지표가 실제 제품에 유용하다는 점을 확인했다.
   3. 이런 협업은 자동으로 생기지 않는다. 양쪽에 높은 주도성(high agency)을 가진 사람이 있어 상호 가치를 보고 오랜 시간의 조율을 감수해야 한다.

5.2. DevRel에서 대규모 엔지니어링 조직으로

1. Google UK L4에서 L6까지

   1. Google UK에서 L4 중견 소프트웨어 엔지니어에 해당하는 DevRel 엔지니어로 시작했고, builder 성격이 강한 개발자 관계 업무를 맡았다.
   2. L5와 L6으로 승진하고 DevRel 매니저가 되어 팀의 일부를 이끌었다.
   3. 약 5~6년이 지나자 개발자 관계도 좋아했지만 본질적으로 엔지니어링과 제품을 만드는 사람이라는 점을 다시 확인했다.

2. 엔지니어링 매니저로 돌아가 팀을 키우다

   1. 공식 DevRel 이전에 했던 엔지니어링 경험으로 돌아가 소프트웨어 엔지니어링과 팀 관리를 함께 하는 역할로 전환했다.
   2. 작은 팀에서 출발해 평균 45~50명 규모까지 키웠고, 여러 매니저가 다른 매니저를 관리하는 글로벌 조직에서 시간대·조정·커뮤니케이션 오버헤드를 다뤘다.
   3. 목표는 매니저가 모든 일을 직접 붙드는 것이 아니라 조직이 거의 자립적으로 작동하는 ‘기계’를 만드는 것이다. 가끔 비행선을 톡 건드리듯 상태를 확인하고, 틀어진 방향을 바로잡은 뒤 다음 큰 문제에 집중할 수 있어야 한다.

3. 조직의 자립이 개인의 빌더 역할을 되돌려 주다

   1. 조직이 안정되자 모델 품질 향상이 개발자와 도구, 벤치마크, 외부 업체와의 협업에 어떤 의미인지 깊이 생각할 시간이 생겼다.
   2. 그 학습을 다시 팀에 가져가 DevTools와 Chrome이 에이전트에 더 유용해지도록 조직을 현대화했다.
   3. 관리자의 시간은 저절로 생기지 않는다. 조직 구조와 위임, 다른 매니저를 위한 공간을 의도적으로 설계한 결과다.

5.3. L7·L8 디렉터가 맡는 일

1. 승진은 다음 단계의 일을 먼저 하는 과정

   1. L6에서 L7을 거쳐 디렉터인 L8로 이동했다.
   2. 건강하게 돌아가는 조직을 만든 뒤에는 다음 단계의 문제와 더 넓은 범위의 영향력을 맡고 싶다는 동기가 커졌다.
   3. 한 단계의 성공을 만든 방식이 다음 단계의 성공을 보장하지 않는다. 디렉터가 되려면 VP·SVP와 함께 Android, Chrome, 플랫폼 조직의 다음 1~2년을 설계해야 한다.

2. 첫 번째 임원 접점으로서의 책임

   1. 디렉터는 연간·분기 목표가 궤도에 있는지 확인하고, 큰 프로그램이나 새 프로젝트를 후원하며, 전체 조직의 방향이 틀어지면 정기적인 리뷰 포럼에서 바로잡는다.
   2. 자립적인 조직을 만든다는 것은 손을 완전히 떼는 것이 아니다. 중요한 정보와 의사결정, 장애물이 빠르게 표면화되는 시스템을 만들고 세부를 계속 확인해야 한다.
   3. 기술 작업이 사업 목표와 어떻게 연결되는지 팀이 분명히 이해하게 하는 역할도 디렉터의 책임이다.

3. Gemini와 Cloud AI에서의 주간 책임성

   1. Gemini와 Cloud AI를 맡을 때 그해 핵심 목표 중 하나를 책임졌고, 매주 또는 격주로 진행 상황을 보고하며 숫자와 목표가 계속 올바른 방향으로 가는지 설명해야 했다.
   2. 디렉터는 더 큰 팀 운영, 위로의 커뮤니케이션, 사업 목표, 기술 세부사항을 동시에 다룬다. 단순히 일을 놓아버리는 승진이 아니라 더 넓은 범위의 책임을 짊어지는 승진이다.

4. 리더도 직접 모델을 써 봐야 한다

   1. 최근에는 디렉터·VP·SVP급 리더가 직접 소매를 걷어붙이고 주말에 무엇을 만들었는지, 어떤 모델을 시험했는지, 어떤 워크플로와 마찰을 겪었는지 이야기하는 장면이 늘었다.
   2. 과거의 임원 대화가 큰 회사 문제에 집중했다면, 모델과 하네스(harness)가 좋아진 지금은 리더가 직접 사용해 현실적인 판단을 내릴 수 있다.

6. AI 시대의 인지적 깊이와 루프 엔지니어링

6.1. 인지 부채와 인지적 항복

1. 인지 부채(cognitive debt)

   1. AI 사용이 늘면 문제의 세부사항을 직접 기억하고 이해하는 능력이 서서히 약해질 수 있다.
   2. 개발자는 답을 얻는 대신 문제를 학습하고 내부 구조를 기억해야 하는데, 결과만 소비하면 그 이해의 기반이 침식된다.
   3. 이 현상은 단순한 생산성 문제가 아니라 나중에 장애가 발생했을 때 원인을 추적하고 고칠 수 있는 능력의 감소다.

2. 인지적 항복(cognitive surrender)

   1. AI가 제시한 답을 검토하지 않고 그대로 자신의 답으로 받아들이는 상태다.
   2. AI의 답이 곧 자신의 답이 되면 비판적 사고와 문제 해결 능력을 포기하게 된다.
   3. 에이전트·하네스 엔지니어링·루프 엔지니어링·소프트웨어 팩토리를 긍정적으로 보더라도, 문제가 생겼을 때 에이전트가 해결해 주기를 기도하는 수준으로 이해를 놓아서는 안 된다.

6.2. 강력한 에이전트를 따라잡는 검토 방식

1. 모든 토큰을 읽을 수 없는 현실

   1. 1년 전에는 에이전트가 한 번에 보여주는 사고 메시지를 펼쳐 몇 초마다 갱신되는 추론 흐름을 따라갈 수 있었다.
   2. 이제 Claude Code나 Codex에서 20~30개의 서브에이전트가 동시에 실행될 수 있어 모든 에이전트의 trajectory를 클릭해 읽는 것은 불가능하다.
   3. 에이전트가 빨라졌다는 이유로 검토를 포기하는 것이 아니라 검토 단위를 세부 토큰에서 중요한 결정으로 바꿔야 한다.

2. 최종 결정 요약을 끝까지 읽기

   1. 작업이 끝났을 때 어떤 결정이 내려졌는지 정리한 요약이 있으면 처음부터 끝까지 읽는다.
   2. 요약이 없으면 에이전트에게 결정 과정을 다시 정리하게 한다.
   3. 모델이 결정을 실제로 기록한 것이 아니라 그럴듯하게 지어내는 경우가 있으므로 요약도 무비판적으로 믿지 않고 핵심 판단을 검증해야 한다.

3. 상호 증폭(mutual amplification)

   1. 에이전트가 매일 더 좋아지는 동시에 엔지니어도 더 좋아지도록 세션과 프로젝트 안에 학습을 기록한다.
   2. 결정, 실패와 마찰, 문제를 접근한 독특한 방식, 다음에 기억해야 할 맥락을 남기면 에이전트의 미래 작업 품질과 사람의 이해가 함께 높아진다.
   3. 중요한 것은 모든 코드 생성 과정을 감시하는 것이 아니라, 시스템의 핵심 결정과 그 이유를 계속 이해하는 의도성(intentionality)과 호기심을 보존하는 것이다.

6.3. 소프트웨어 팩토리와 루프의 의미

1. 프롬프트가 아니라 프롬프트를 실행하는 시스템

   1. 소프트웨어 팩토리는 ‘자동차 한 대를 만들어 달라’고 지시하면 완성된 자동차가 나오는 공장처럼 요구사항을 결과물로 바꾸는 자동화 시스템이다.
   2. 단일 프롬프트로 결과를 얻는 데 집중하지 않고, 시스템이 프롬프트를 만들고 코드를 생성하며 테스트·검증까지 수행하도록 만든다.
   3. 이는 소프트웨어 발전이 추상화를 계속 높여 온 다음 단계다. 다만 품질과 통제에 대한 질문이 사라지는 것이 아니라 더 중요해진다.

2. 루프에 사람과 가드레일을 남기기

   1. 시스템이 핵심 파일이나 중요한 영역을 건드리면 사람의 리뷰가 필요하다고 플래그해야 한다.
   2. 변경의 폭(blast radius), 품질 기준, 출시 조건을 명시하지 않은 채 루프가 모든 것을 만들게 하면 재앙의 레시피가 된다.
   3. 자동화의 목표는 사람을 제거하는 것이 아니라 사람의 판단이 필요한 지점을 더 선명하게 드러내는 것이다.

3. 다크 팩토리 비유의 한계

   1. 다크 팩토리는 로봇에게 조명이 필요 없으므로 불을 끄고 에너지를 절약하는 완전 자동화 공장을 뜻한다.
   2. 자동차나 나사처럼 공장에서 나온 물건은 생산이 끝나면 완성되지만, SaaS 소프트웨어는 출시된 뒤에야 실제 장애·버그·사용자 반응이 나타난다.
   3. 따라서 소프트웨어 팩토리는 빌드와 테스트에서 끝나지 않고 프로덕션의 실행 데이터와 연결된 피드백 공장이어야 한다.

4. 텔레메트리와 백로그를 연결한 능동적 제품 개선

   1. 시스템을 텔레메트리, 로그, 오류, 사용자 피드백, 제품 백로그와 연결하면 무엇을 만들고 어떻게 검증할지 결정하는 신호가 늘어난다.
   2. 충분한 신호가 쌓이면 제품이 개선될 기회를 스스로 찾아 우선순위를 제안하는 능동적인 시스템에 가까워질 수 있다.
   3. ‘루프’라는 이름은 시각적으로 생산과 피드백이 순환한다는 뜻을 잘 보여주지만, 실제 조직에서는 workflow나 feedback loop가 더 정확한 표현일 수도 있다. 빠르게 생기는 용어는 계속 다듬어질 가능성이 크다.

6.4. 실제 루프 사례와 사람의 최종 판단

1. 오류에서 코드 수정까지 이어지는 루프

   1. Sentry에 새로운 오류가 발생하면 훅(hook)이 선호하는 코딩 에이전트를 호출해 수정안을 한 번에 만들고 리뷰 대기 상태로 둘 수 있다.
   2. 오늘 당장 자동 병합까지 허용하는 것은 위험하지만, 오류를 감지하고 원인 분석·수정·리뷰로 보내는 루프는 이미 현실적인 자동화다.
   3. 오픈소스 프로젝트에서도 이슈가 올라오면 봇이 재현을 시도하는 흐름이 확산되고 있다.

2. 버그 리포트와 제품 신호를 함께 우선순위화하기

   1. Addy의 앱에서는 사용자가 문제를 제출하고, 예전에는 시간이 날 때마다 버그 리포트를 수동으로 읽어 일부만 골랐다.
   2. 이제 Google Analytics, 호스팅 제공자의 로그, 사용자 오류와 배포 정보 등을 연결해 한 차원의 피드백이 아니라 여러 신호를 바탕으로 결정할 수 있다.
   3. 예를 들어 인도 사용자의 특정 화면이 매우 느리고 인도에서 유입되는 트래픽도 많다면 그 성능 문제의 우선순위를 높일 수 있다.

3. 자동 구현 이후에도 검토가 필요한 이유

   1. 에이전트가 백로그 전체를 구현할 수 있어도 사람이 결과를 보고 무엇이 실제로 바뀌었는지, 특정 기기에서 얼마나 수동 테스트해야 하는지 판단해야 한다.
   2. 에뮬레이션 테스트는 도움이 되지만 실제 사용 환경을 완전히 대신하지 않는다.
   3. 루프의 가치는 모든 신호를 사람이 직접 훑지 않아도 더 정교한 제품 결정을 내리게 하는 데 있으며, 책임을 없애는 데 있지 않다.

7. 코드를 덜 쓰는 시대의 엔지니어 정체성

7.1. 사라지는 타이핑과 남는 ‘알파’

1. Ryan Dahl의 선언

   1. Node.js 창시자 Ryan Dahl은 “인간이 코드를 작성하는 시대는 끝났다. 소프트웨어 엔지니어에게 충격적이지만 사실이다. 엔지니어에게 할 일이 없다는 뜻은 아니지만 문법을 직접 쓰는 일은 아니다”라고 말했다.
   2. 과거 Uber 면접에서는 지원자에게 업무의 최소 50%를 코드 작성에 쓸 것이라고 말하고 직접 코딩을 평가했지만, 이 비중은 빠르게 사라지고 있다.

2. 알파(alpha)는 모델이 못하는 이점

   1. 알파는 여기서 경쟁 우위(advantage)를 뜻하며, 모델이 잘하지 못하는 영역이 모델 릴리스마다 바뀌므로 엔지니어의 알파도 계속 이동한다.
   2. 현재 인간의 알파는 무엇을 만들지, 어디에 에너지를 쓸지, 결과물이 정말 좋은지 판단하는 취향(taste)에 있다.
   3. 에이전트는 명세와 일치해 겉보기로 올바른지 말할 수 있지만, 사용자가 다시 찾아오고 싶을 만큼 유용하고 즐거운지는 자동으로 보증하지 못한다.
   4. 사용자 경험과 제품의 ‘좋음’은 충분히 미묘해 모델이 완전히 따라잡기까지 시간이 필요하다. 판단과 검증은 계속 중요하다.

7.2. 코드 소유권과 책임성

1. Chromium의 OWNERS 모델

   1. Chromium은 세계에서 가장 큰 코드베이스 중 하나이며, 핵심 영역마다 디렉터리와 OWNERS 파일이 있다.
   2. OWNERS에 적힌 소수의 사람은 모든 코드를 직접 작성하지 않았더라도 그 영역을 이해하고, 변경을 게이트하고, 무엇을 출시·차단·연기할지 결정한다.
   3. 에이전트가 많은 코드를 만들수록 이런 영역별 책임자는 더 중요해진다. 결과가 안정적이고 신뢰할 수 있으며 실제로 사용 가능한지 최종적으로 답해야 하기 때문이다.

2. 책임성이 전문직의 가치를 만든다

   1. 법률가는 규정과 판례를 이해하고 고객을 대변한 결과에 일정한 책임을 지므로 자동화 시대에도 필요하다.
   2. 집을 직접 고칠 수 있는 작은 일은 스스로 처리하지만 큰 공사는 전문가를 부르는 것처럼, 위험과 가치가 큰 소프트웨어에는 시스템을 이해하고 책임질 전문가가 필요하다.
   3. 코드 생성이 쉬워져도 책임을 질 수 있는 이해와 신뢰는 하루아침에 생기지 않는다.

7.3. 더 많은 빌더와 새 직업의 탄생

1. 생산 비용 하락이 공급을 폭발시키다

   1. 소프트웨어를 만드는 일이 쉬워질 때마다 소프트웨어의 총량은 기하급수적으로 늘었다.
   2. 모바일 앱, iOS 앱, 웹사이트 출시가 빠르게 늘고 있으며, 한 번의 프롬프트로 복제 가능한 앱과 깊은 차별화가 있는 제품의 가치는 다를 수 있다.
   3. 그렇더라도 더 많은 사람이 만들 수 있게 된 사실은 더 많은 사업과 스타트업이 생기고 성공할 가능성을 넓힌다.

2. 자동화가 없애는 일과 새로 만드는 일

   1. 역사적으로 자동화는 특정 유형의 일을 없애는 동시에 다른 유형의 일을 만들어 왔다.
   2. 지식 경제에서 새 역할의 정확한 형태는 아직 정해지지 않았지만, 사라지는 작업만큼 새로운 책임과 조정·검증·제품 판단 역할이 생길 가능성이 크다.

8. AI를 활용한 글쓰기와 인간적인 목소리

8.1. 텍스트 생성보다 가치 있는 아이디어

1. 읽을 가치가 있는 주장부터 만들기

   1. 에이전트가 누구나 긴 글을 만들 수 있게 된 만큼, 독자에게 5분·10분·15분을 요구할 만한 아이디어인지 확인하는 일이 더욱 중요해졌다.
   2. Addy는 O’Reilly와 함께 약 18권의 책을 출판했고, 소프트웨어 엔지니어링의 소프트한 부분을 다룬 약 50쪽의 무료 책, Leading Effective Engineering Teams, Vibe Coding 등을 썼다.
   3. 에이전트의 가장 큰 도움은 문장을 대신 쓰는 것이 아니라 머릿속 생각을 관련 문제를 다룬 다른 사람들의 관점과 연결해 논지를 세우는 일이다.

2. 리서치 에이전트의 활용

   1. Loop Engineering 글을 준비할 때 Hacker News, Twitter 등에서 사람들이 시도한 것, 강한 찬반 의견, 논쟁적인 부분, 기대와 질문을 여러 에이전트에게 조사하게 했다.
   2. 목적은 에이전트에게 글을 통째로 쓰게 하는 것이 아니라 독자가 무엇으로 어려움을 겪는지에 대한 가설과 교육적 논지를 만드는 것이다.
   3. 사람이 주제의 핵심과 가치 판단을 결정하고, 에이전트는 넓은 탐색과 관점 수집을 맡는다.

8.2. 손글씨 초안과 모델 초안의 비교

1. 두 방향으로 초안을 만들다

   1. 아이디어가 생기면 개인적인 손글씨 버전을 먼저 쓰고, 한편으로 에이전트나 여러 모델에게 같은 주제의 버전을 쓰게 한다.
   2. 모델들이 초기 논지를 어떻게 해석했는지, 전혀 다른 방향으로 갔는지, 모두 비슷한 결론에 수렴했는지 비교한다.
   3. 아이디어가 굳은 뒤에는 자신의 글을 가져와 구조와 가독성을 개선하는 데 모델을 사용한다.

2. 가독성과 AI 문체 사이의 긴장

   1. Addy는 구조적인 글쓰기를 좋아하지만, 모델이 만든 문장은 사람처럼 보이기보다 삼단 구조와 반복적인 패턴을 가진 AI 문체가 되기 쉽다고 느낀다.
   2. 가독성을 개선하려고 실험하다가 모델이 계속 비슷한 패턴을 생성해 세 시간을 낭비한 적도 있다.
   3. Loop Engineering 글은 손글씨 초안과 여러 차례의 편집 뒤 모델에 가독성 수정을 맡겼고, 전체를 관통하는 선명한 흐름은 얻었지만 구체성이 줄고 지나치게 구조화됐다는 평가를 받을 여지도 남겼다.

3. 진정성 대 구조

   1. 정리되지 않은 초안이 더 진정성 있게 느껴질 수도 있고, 명확한 구조와 일관된 흐름이 독자에게 더 좋은 경험을 줄 수도 있다.
   2. Michael Novati는 AI처럼 들린다는 비판을 받은 글 이후 출력물을 훨씬 더 많이 직접 다듬어 다음 글의 인간적인 느낌을 개선했다.
   3. Addy는 좋은 글 하나를 보통 3~7일 동안 숙성시키며, 출판 전에 모든 문장을 여러 번 읽는다. 빨리 나온 글은 처음부터 매우 선명한 비전이 있었던 예외에 가깝다.

8.3. 인간적인 글의 기준을 다시 찾기

1. 모델이 만드는 동질적인 문체

   1. AI 도구를 많이 쓰면 모델이 제안하는 글의 평균적인 형태에 영향을 받아 자신의 문체가 무엇이었는지 되묻게 된다.
   2. 오래된 글로 맞춤 모델을 만들자는 제안도 있지만, 과거의 자신은 다른 관점과 관심사를 가진 사람이었으므로 옛 문체를 그대로 새 글에 입히는 일도 조심스럽다.
   3. 인간적인 글의 기준과 AI를 활용한 최선의 편집 방식은 아직 실험 중이다.

2. AI 탐지기의 역설

   1. Addy는 Pangram이나 GPTZero 같은 도구가 자신의 인간적인 문장을 인간이 쓴 글이 아니라고 판정하는지 궁금해 직접 시험했다.
   2. 실제로 직접 쓴 문단을 넣었는데도 ‘인간이 쓴 글처럼 보이지 않는다’는 결과가 나와 답답함을 느꼈다.
   3. 탐지기는 처벌용 판정기보다 문체의 특징을 알려주고 사람이 자신의 자연스러운 표현으로 돌아가도록 돕는 피드백 도구가 되는 편이 유용하다.

9. Google을 떠난 뒤의 방향과 경력 조언

9.1. 다음 단계에서 풀고 싶은 문제

1. 14년을 마치고도 개발자 생태계에 남다

   1. Addy는 Google에서 14년을 보낸 뒤 회사를 떠나기로 했고, 결정 자체가 큰 선택이었다고 말한다.
   2. 모든 회사가 AI 시대의 소프트웨어 엔지니어링이 어떻게 바뀔지 많은 질문을 갖고 있으므로, 개발자와 기업이 그 답을 함께 찾아가도록 돕는 일을 가장 기대한다.
   3. 다음 구체적인 행보는 몇 달 동안 더 공유할 예정이지만 개발자와 생태계와 계속 일할 수 있는 역할에 남을 계획이다.

2. 일하는 방식의 변화에 참여하기

   1. 관심사는 특정 회사의 직함보다 개발자가 다음 소프트웨어 엔지니어링의 순간을 이해하고 활용하도록 돕는 것이다.
   2. 열린 질문이 많다는 것은 불확실성만 뜻하지 않는다. 새로운 도구·표준·제품·교육이 생길 수 있는 기회이기도 하다.

9.2. 커리어의 언번들링과 역할의 수렴

1. 엔지니어링을 좁은 직무로 보지 않기

   1. 엔지니어링·제품·UX를 분리된 직무로만 보던 경계가 풀리고(unbundling), 서로 다른 역할이 더 많이 겹치게 된다.
   2. 제품 감각이 있는 엔지니어, 엔지니어링 감각이 있는 제품 담당자, 제품을 이해하는 UX 담당자가 모두 더 강한 조합이 된다.
   3. 시니어라면 이미 제품 성공·전도·마케팅·조직 운영 같은 여러 퍼즐 조각을 다뤄 봤을 가능성이 크다.

2. 비엔지니어링 영역까지 학습하기

   1. 제품, 기술 전도(technical evangelism), 마케팅, 비즈니스가 성공하는 방식에 관심을 넓히면 단순한 빌더 이상의 가치를 보여줄 수 있다.
   2. 역할의 경계가 흐려질수록 여러 기능 사이를 연결하고 무엇이 중요한지 판단하는 사람이 유리하다.
   3. 핵심 조언은 ‘엔지니어로만 머물지 말라’는 것이다. 평생 학습하고 끝없이 호기심을 유지하면 미래의 역할을 발견할 가능성이 높다.

스폰서 제품 및 에피소드 중간 언급

Antithesis와 에이전트 코드 검증

1. 에이전트 시대의 직무 정의

   1. 에이전트를 쓰면 직무는 코드를 작성하는 일에서 코드의 사양을 정하고 테스트하는 일로 이동한다.
   2. Antithesis는 전체 시스템을 적대적 시뮬레이션(hostile simulation)에 넣어 사용자가 만나기 전에 버그를 찾고, 결정론적 실행으로 모든 문제를 재현할 수 있게 한다.

2. 버그 확률 그래프와 로그 시각화

   1. 버그 확률 그래프에서 x축은 가상 시간, y축은 확률이다. 시뮬레이션 중 버그 확률이 높아지는 시간대를 표시해 원인 추적을 돕는다.
   2. 로그 시각화의 세로선은 같은 상태에서 갈라진 사건을, 보라색 점은 버그가 발생한 지점을 나타낸다.
   3. Jane Street, Fly.io, etcd 커뮤니티가 에이전트가 작성한 코드를 자신 있게 출시하기 위해 사용하는 도구로 소개됐다.

Google Cloud Run Sandboxes

1. AI 애플리케이션에서 신뢰할 수 없는 코드 실행
   1. 모델이 생성한 Python을 실행하거나, 웹에서 데이터를 가져오기 위해 headless browser를 구동하거나, 사용자가 제출한 코드를 실행할 때 격리된 실행 환경이 필요하다.
   2. Cloud Run Sandboxes는 빠르게 생성되고 사라지는(ephemeral) 격리된 gVisor 환경으로 설계됐다.
   3. 서비스·환경 변수·비밀정보에 접근하지 못하도록 자격 증명과 환경을 격리하고, 인터넷 네트워크 송신(egress)을 기본 거부로 잠근다.

Sentry Seer의 오류 수정 흐름

1. 오류 목록에서 Pull Request까지

   1. Sentry는 오류뿐 아니라 로그, 리플레이, 스팬, 프로필, 메트릭을 하나의 트레이스로 연결한다.
   2. Seer에게 자동 수정을 요청하면 먼저 HTTP와 HTTPS URL 문제 같은 근본 원인 분석을 만들고, 수정 계획을 제시한다.
   3. 계획을 검토·수정한 뒤 코드 수정안을 생성하고 Pull Request를 초안으로 만든다.

2. 사람이 계속 통제하는 자동화

   1. 오류 감지부터 원인 분석·계획·코드 수정·PR 생성까지 빨라지지만, 최종 병합 판단은 사람이 한다.
   2. 자동화가 닫힌 루프를 만들어도 사람은 버그 수정의 책임과 통제권을 유지한다.

주요 발언 모음

“에이전트는 불가능해 보이던 일을 가능한 일로 바꿔 놓았다.”

“인지적 항복은 AI가 말하는 것을 맹목적으로 답으로 받아들이는 것이고, AI의 답이 자신의 답이 되는 상태다.”

“에이전트와 일할 때 직업은 더 이상 코드를 쓰는 일이 아니라 코드를 명세하고 테스트하는 일이다.”

“프롬프트를 잘 쓰는 데만 집중하는 대신, 프롬프트를 실행하고 결과를 생성하며 테스트와 검증을 수행하는 시스템을 만든다.”

“가드레일 없이 루프가 모든 것을 만들게 하고 변경의 폭을 제한하지 않는 것은 재앙의 레시피다.”

“모델은 무언가가 명세와 맞는지 말할 수 있지만, 그것이 정말 좋은지까지 말할 수 있는 것은 아니다.”

“엔지니어는 모든 코드를 직접 쓰지 않더라도 자신의 영역을 이해하고 무엇을 출시할지 결정하며 책임져야 한다.”

“엔지니어로만 머물지 말고 평생 학습하며 끝없이 호기심을 가져라.”

핵심 데이터 & 수치

• 14년: Addy Osmani가 Google에서 보낸 기간이며 대부분 Chrome 조직에서 일했다.
• 15~16세: HTML·CSS·JavaScript 사양을 읽으며 자체 웹 브라우저를 만들기 시작한 시기다.
• 8~9세: 첫 컴퓨터를 접하고 주소창·웹 렌더링의 내부 작동을 궁금해하기 시작한 나이다.
• 2012~2013년: Chrome DevTools와 웹 빌드 생태계가 현재와 달랐던 시기다. Next.js 같은 메타 프레임워크와 표준화된 브라우저 모듈이 없었다.
• 수천 개 이상의 GitHub stars: TodoMVC가 짧은 기간에 얻은 관심 규모다.
• 45~50명: Addy가 한때 이끌었던 조직의 평균적인 규모다.
• L4 → L5 → L6 → L7 → L8: Google UK DevRel 엔지니어에서 디렉터까지 이어진 경력 단계다.
• 20~100개 실험: 대규모 Google 제품에서 동시에 고려할 수 있는 A/B 실험의 규모를 설명한 수치다.
• 20~30개 서브에이전트: 현대 코딩 에이전트 작업에서 동시에 실행될 수 있어 전부의 사고 과정을 읽기 어려운 규모다.
• 최소 50%: 과거 Uber 기술 면접에서 지원자가 업무 중 코드를 직접 작성할 것으로 설명하던 비중이다.
• 3~7일: Addy가 AI 도구를 사용하면서도 글 하나를 숙성하고 모든 문장을 검토하는 데 쓰는 일반적인 기간이다.
• 약 18권: Addy가 출판했다고 언급한 책의 수다.
• 약 50쪽: Software Engineering: The Soft Parts 무료 단행본의 분량이다.
• 5·10·15분: 독자에게 글을 읽도록 요구할 때 정당화해야 하는 시간의 예시다.

결론 및 시사점

1. AI의 생산성은 시간을 비워 주는 동시에 만들 수 있는 일의 수를 폭발시킨다. 무엇을 더 할지 고르는 기준이 없으면 해방감이 곧 혼돈으로 바뀐다.
2. 브라우저를 직접 만들던 태도처럼 시스템을 네트워크·엔진·메모리·GPU까지 한 계층씩 이해하는 습관은 에이전트 시대에도 유효하다.
3. Core Web Vitals의 교훈은 기술 지표가 사용자의 체감인 보임·조작성·안정성과 연결될 때 조직의 실행 기준이 된다는 것이다.
4. 인지 부채를 줄이려면 에이전트가 만든 코드의 모든 토큰을 읽을 수 없더라도 핵심 결정·근거·특이한 선택·학습을 기록해야 한다.
5. 상호 증폭은 에이전트가 더 좋아지는 만큼 엔지니어의 문제 이해와 판단력도 함께 좋아지도록 설계하는 작업 방식이다.
6. 소프트웨어 팩토리는 자동 생성 파이프라인이 아니라 테스트·품질 게이트·사람의 검토·프로덕션 피드백까지 포함한 폐쇄 루프다.
7. 에이전트가 코드를 많이 작성할수록 변경의 폭과 위험을 관리하는 가드레일, 영역별 오너, 출시·차단·연기 판단이 중요해진다.
8. 인간의 현재 알파는 코드를 빠르게 타이핑하는 능력보다 좋은 문제를 고르고 사용자가 다시 찾을 제품을 판단하는 취향에 있다.
9. 쉬운 소프트웨어 제작은 개발자를 없애기보다 더 많은 빌더와 제품을 만들고, 책임·검증·조정이라는 새 업무를 만든다.
10. 엔지니어링·제품·UX·마케팅의 경계가 풀리므로 좁은 직무 정의보다 여러 기능을 연결하고 사업 가치를 이해하는 능력에 투자해야 한다.

핵심 요약 (20줄)

Addy Osmani는 다이얼업 인터넷의 제약을 해결하려고 10대에 직접 웹 브라우저를 만들었다.

다운로드 관리자의 병렬 청크 처리는 웹페이지를 더 빠르게 만들겠다는 발상으로 이어졌다.

국가 과학 경진대회 우승과 Wall Street Journal·CNN의 취재는 한 번의 프로젝트가 가져온 뜻밖의 전환점이었다.

브라우저의 네트워크·렌더링·JavaScript·메모리·GPU 계층을 이해하는 습관이 장기적인 최적화 능력을 만들었다.

jQuery와 TodoMVC는 커뮤니티 협업과 프레임워크 차이를 직접 비교하는 교육의 가치를 보여줬다.

TodoMVC의 단순한 할 일 앱은 수천 개의 별을 얻고 프레임워크 비교의 사실상 표준이 됐다.

Speedometer는 브라우저가 클릭과 탭에 얼마나 빠르게 반응하는지 측정하는 공동 벤치마크로 성장했다.

Chrome DevTools는 성능 트레이스·소스맵·블랙박스·모바일 기기 모드·PWA 디버깅을 한곳에 모았다.

메모리 디버깅은 여전히 많은 개발자가 어려워하는 브라우저 도구의 난제다.

Core Web Vitals는 로딩 시간을 사용자의 보임·조작성·안정성이라는 체감과 연결했다.

광고가 늦게 로드되어 읽던 내용이 밀리는 문제는 CLS가 해결하려는 대표적인 사용자 경험이다.

Google의 대규모 제품은 수십 개에서 백 개에 이르는 실험을 엄격한 A/B 테스트로 검증한다.

Addy는 DevRel에서 엔지니어링 매니저로 이동해 45~50명 규모의 자립적인 글로벌 조직을 만들었다.

디렉터의 핵심 책임은 조직을 방치하는 것이 아니라 정보·장애물·사업 목표를 연결하고 방향을 교정하는 일이다.

인지 부채는 AI 의존으로 문제 기억과 이해가 약해지는 현상이며 인지적 항복은 AI의 답을 자신의 답으로 받아들이는 상태다.

모든 서브에이전트의 추론을 읽는 대신 최종 결정과 근거를 기록하고 검토하는 상호 증폭이 필요하다.

루프 엔지니어링은 프롬프트가 아니라 구현·테스트·텔레메트리·피드백을 잇는 소프트웨어 팩토리를 만드는 일이다.

에이전트가 코드를 작성해도 핵심 영역의 오너는 무엇을 출시하고 안정성을 보증할지 책임져야 한다.

AI 글쓰기의 가치는 문장을 대량 생산하는 데보다 독자가 읽을 가치가 있는 논지와 인간적인 목소리를 찾는 데 있다.

미래의 엔지니어는 제품·UX·마케팅까지 호기심을 넓히고 평생 학습하며 역할의 경계가 풀리는 시장에 대응해야 한다.